On Sat, Apr 27, 2019 at 02:06:55PM +0900, Junio C Hamano wrote:
> 2019年4月27日(土) 2:58 Kaartic Sivaraam :
> >
> > May be you are searching for the following view which lists (similar to git
> > log --one-line) the commits starting from 97dd512 which is the last in the
> > tb/unexpected series?
>
On Thu, Apr 25, 2019 at 03:16:57PM -0700, Josh Steadmon wrote:
> On 2019.04.25 19:15, Junio C Hamano wrote:
> > * js/partial-clone-connectivity-check (2019-04-21) 1 commit
> > (merged to 'next' on 2019-04-25 at ebd8b4bffd)
> > + clone: do faster object check for partial clones
> >
> > During
On Tue, Apr 30, 2019 at 11:59:23AM -0700, Josh Steadmon wrote:
> Just a couple typo fixes listed below:
>
Thanks for the review, Josh.
I'll hold these fixes locally until I either get something more
significant to fix or Junio asks for them before a merge to next, to
reduce spam to the list.
-
Hi Brian,
brian m. carlson 於 2019年5月2日 週四 上午7:45寫道：
>
> On Tue, Apr 30, 2019 at 12:15:37PM +0100, Phillip Wood wrote:
> > Hi John
> >
> > On 30/04/2019 07:02, John Lin wrote:
> > > When typing "git status", there is an empty line between
> > > the "Changes not staged for commit:" block and the li
On Wed, May 01, 2019 at 06:01:08AM -0400, Denton Liu wrote:
> > Is it not possible to exclude certain directories for certain semantic
> > patches?
> >
> > I guess we could also simply declare that *all* Coccinelle patches should
> > leave `compat/` alone, on the basis that those files are likely
On Tue, Apr 30, 2019 at 12:15:37PM +0100, Phillip Wood wrote:
> Hi John
>
> On 30/04/2019 07:02, John Lin wrote:
> > When typing "git status", there is an empty line between
> > the "Changes not staged for commit:" block and the list
> > of changed files.
>
> I'm a bit confused by this as you cha
On Wed, May 01, 2019 at 08:39:22PM +0200, Alban Gruin wrote:
> -Og also exists to debug[0], even if it’s far less known. Perhaps it’s
> better to check for -g (and its variants[1]) as the user clearly states
> their intent to debug the resulting binary, rather than checking for
> special cases.
I
On Tue, Apr 30, 2019 at 06:16:48PM -0400, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 30 Apr 2019, SZEDER Gábor wrote:
>
> > Since e7e9f5e7a1 (travis-ci: enable Git SVN tests t91xx on Linux,
> > 2016-05-19) some of our Travis CI build jobs install the 'git-svn'
> > package, because it was a conv
On Tue, Apr 30, 2019 at 06:25:35PM -0400, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 30 Apr 2019, SZEDER Gábor wrote:
>
> > When running a command with the 'exec' instruction during an
> > interactive rebase session, or for a range of commits using 'git
> > rebase -x', the output can be a bit g
On Wed, May 1, 2019 at 6:30 PM Jonathan Nieder wrote:
> ...
> > install -m 755 gitweb.cgi '/usr/local/share/gitweb'
> > find: cycle detected for /lib/secure/32/
> [...]
> > install: gitweb.cgi was not found anywhere!
>
> Sounds like it's using "install" when it should be using "ginstall".
> config
Hi,
Jeffrey Walton wrote:
> I'm attempting to install Git 2.21.0 on Solaris 11.3 x86_64.
> /usr/gnu/bin is on-path.
[...]
> gmake -C gitweb install
> gmake[1]: Entering directory `/export/home/build/git-2.21.0/gitw
> eb'
> gmake[2]: Entering directory `/export/home/build/git-2.21.0'
> gmake[2]: `
Hi,
Jeff King wrote:
> I wonder if this points to this patch touching the wrong level. These
> compiler flags are a thing that _some_ builds want (i.e., production
> builds where people care most about security and not about debugging),
> but not necessarily all.
>
> I'd have expected this to be
Hi Everyone,
I'm attempting to install Git 2.21.0 on Solaris 11.3 x86_64.
/usr/gnu/bin is on-path.
'make' was OK, 'make check' had a few failures. 'make install' has troubles.
$ sudo gmake install
...
gmake -C gitweb install
gmake[1]: Entering directory `/export/home/build/git-2.21.0/gitw
eb'
g
On Wed, May 01, 2019 at 02:18:34PM +0200, Ævar Arnfjörð Bjarmason wrote:
> We can make it fancier, but we already deal with this, e.g. if you do
> "git config -l" we'll show "include{,if}" directives at the same "level"
> as other "normal" keys.
We show them, but we _do_ interpret them if the cal
On Wed, May 01, 2019 at 07:32:20PM +0700, Duy Nguyen wrote:
> > We also provide no way in "git config" to properly interpret a
> > value. E.g. does a "user.email" showing up twice for me mean I have two
> > E-Mails at the same time, or does the last one win?
>
> Actually --get knows this. Single-
On Wed, May 01, 2019 at 01:32:17PM -0700, Emily Shaffer wrote:
> There appears to be a bug in the toolchain generating manpages from
> lettered lists. When a list is enumerated with letters, the resulting
> nroff shows numbers instead. Mostly this is harmless, but in the case of
> gitsubmodules, t
On Tue, Apr 30, 2019 at 06:41:29PM -0400, Johannes Schindelin wrote:
> > I'm a bit concerned that this breaks my debug sessions where I use -O0.
> > But I'll test without -O0 before I really complain.
>
> Weird. Jameson Miller also mentioned this very concern in an internal
> review.
>
> I guess
On Wed, May 01, 2019 at 05:11:38PM +0700, Duy Nguyen wrote:
> On Wed, May 1, 2019 at 1:10 AM Priscila Gutierres
> wrote:
> >
> > Hi
> > I want to contribute to git by creating and/or translating
> > documentation. Where may I find the info to do this?
>
> For translation, you could start at po/R
There appears to be a bug in the toolchain generating manpages from
lettered lists. When a list is enumerated with letters, the resulting
nroff shows numbers instead. Mostly this is harmless, but in the case of
gitsubmodules, the paragraph following the list refers back to each
bullet by letter. As
On Wed, May 01 2019, Derrick Stolee via GitGitGadget wrote:
> The commit-graph file format has some shortcomings that were discussed
> on-list:
>
> 1. It doesn't use the 4-byte format ID from the_hash_algo.
>
> 2. There is no way to change the reachability index from generation numbers
> t
On 5/1/2019 10:58 AM, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, May 01 2019, Derrick Stolee via GitGitGadget wrote:
>
>> The commit-graph feature began with a long list of planned
>> benefits, most of which are now complete. The future work
>> section has only a few items left.
>>
>> As for maki
On 5/1/2019 3:12 PM, Ævar Arnfjörð Bjarmason wrote:
>
> OK, let's try that then, on top of this series:
>
> diff --git a/commit-graph.c b/commit-graph.c
> index 5eebba6a0f..36c8cdb950 100644
> --- a/commit-graph.c
> +++ b/commit-graph.c
> @@ -1127,7 +1127,7 @@ int write_commit
On Wed, May 01 2019, Derrick Stolee via GitGitGadget wrote:
> 3. Git did not fail with error if the unused eighth byte was
> non-zero, so we could not use that to indicate an incremental
> file format without breaking compatibility across versions.
This isn't new, I just missed this
On Wed, May 01, 2019 at 06:01:08AM -0400, Denton Liu wrote:
> > I guess we could also simply declare that *all* Coccinelle patches should
> > leave `compat/` alone, on the basis that those files are likely coming
> > from some sort of upstream. But then, `compat/mingw.c` and `compat/win32/`
> > se
On Wed, May 01, 2019 at 04:53:44PM +0700, Duy Nguyen wrote:
> > > > I just noticed that this commit message is missing more than just a
> > > > trailing period. It does not explain the change of behavior: previously,
> > > > `GIT_EXTERNAL_DIFF=heya git diff --no-index a b` would silently ignore
>
On Wed, May 01, 2019 at 05:56:35PM +0900, Mike Hommey wrote:
> The fread/fwrite-like functions in http.c, namely fread_buffer,
> fwrite_buffer, fwrite_null, fwrite_sha1_file all return the
> multiplication of the size and number of items they are being given.
>
> Practically speaking, it doesn't
On Sun, Nov 4, 2018 at 2:34 PM _g e r r y _ _l o w r y _
wrote:
>
> [1a] Which do you prefer: Git GUI, Git command line?
git cli
>
> [1b] What is your reason for your [1a] preference?
I'm a cli guy, I know git well, and it gives me all the power.
However, understanding history/branch struct
Hi Johannes,
Le 01/05/2019 à 00:41, Johannes Schindelin a écrit :
> Hi Hannes,
>
> On Tue, 30 Apr 2019, Johannes Sixt wrote:
>
>> [had to add Dscho as recipient manually, mind you]
>
> I usually pick up responses to GitGitGadget patch series even if I am not
> on explicit Cc: (but it might take
On Wed, May 01, 2019 at 10:15:19AM +0300, Aleksey Midenkov wrote:
> > Usually when we see racy contention on index.lock, the culprit turns out
> > to be another unrelated git process refreshing the index. Do you have
> > anything else running which might be using "git status" (e.g., magit in
> > e
On Mon, Apr 29, 2019 at 08:48:51AM -0400, Derrick Stolee wrote:
> Q: How should we handle a detectably-invalid commit-graph?
>
> I think most of your patches have done a good job so far of detecting
> an invalid header, and responding by ignoring the commit-graph. This case
> of a detectable erro
On Fri, Apr 26, 2019 at 12:32:51PM -0700, Bryan Turner wrote:
> > $ git ls-remote -n1 --tags --sort=v:refname origin "v*"
> [...]
> With the v2 wire protocol, the client could provide a prefix (like
> `refs/tags/`, or potentially `refs/tags/v`) to reduce what the server
> included in the r
On Wed, May 01, 2019 at 07:45:05PM +0200, René Scharfe wrote:
> > But since the performance is still not quite on par with `gzip`, I would
> > actually rather not, and really, just punt on that one, stating that
> > people interested in higher performance should use `pigz`.
>
> Here are my perfor
"_g e r r y _ _l o w r y _"
writes:
>
>
> QUESTION: if YOU use a Windows GUI for Git, i would appreciate knowing which
> one and why
>
> i have been asked to look at GUI versions of Git for Windows.
>
> https://git-scm.com/download/gui/windows currently
On Mon, Apr 29, 2019 at 05:32:50PM -0400, Johannes Schindelin wrote:
> > Another is that I am not sure how your "fixed format" argument
> > meshes with the "-b blocksize" parameter to affect the tar/pax
> > output. The format may be fixed, but it is parameterized. If
> > we ever need to grow the
On Fri, Apr 26, 2019 at 10:28:12AM -0400, Johannes Schindelin wrote:
> > > +static gzFile gzip;
> > > [...]
> > > + if (gzip) {
> >
> > Is it OK for us to ask about the truthiness of this opaque type? That
> > works if it's really a pointer behind the scenes, but it seems like it
> > would b
Hello Dscho,
Am 29.04.19 um 23:25 schrieb Johannes Schindelin:
> On Sat, 27 Apr 2019, René Scharfe wrote:
>> The simplest solution is of course to not touch the archive code.
>
> We could do that, of course, and we could avoid adding a new command that
> we have to support for eternity by introduc
Hi Dscho
On 30/04/2019 23:49, Johannes Schindelin wrote:
Hi Phillip,
On Tue, 30 Apr 2019, Phillip Wood wrote:
On 29/04/2019 17:07, Johannes Schindelin wrote:
On Fri, 26 Apr 2019, Phillip Wood wrote:
From: Phillip Wood
When `rebase -r` finishes it removes any refs under refs/rewritten
th
On Wed, May 01 2019, Derrick Stolee via GitGitGadget wrote:
> The commit-graph feature began with a long list of planned
> benefits, most of which are now complete. The future work
> section has only a few items left.
>
> As for making more algorithms aware of generation numbers,
> some are only
On 01/05/2019 11:31, Duy Nguyen wrote:
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
From: Phillip Wood
These two patches teach read-tree how to avoid overwriting untracked
files when doing '--reset -u' and also how to respect all of git's
standard excludes files. I'd like to see the
On Wed, May 01 2019, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The write_commit_graph() method uses die() to report failure and
> exit when confronted with an unexpected condition. This use of
> die() in a library function is incorrect and is now replaced by
> error() st
Both remove_branch_state() and drop_save() delete almost the same set of
files about the current merge state. The only difference is MERGE_RR but
it should also be cleaned up after a successful merge, which is what
drop_save() is for.
Make a new function that deletes all merge-related state files
This allows to cancel the current merge without reseting worktree/index,
which is what --abort is for. Like other --quit(s), this is often used
when you forgot that you're in the middle of a merge and already
switched away, doing different things. By the time you're realize, you
can't even continue
nd/switch-and-restore suggests 'git merge --quit' to get out of a merge
even though this option is not implemented [1]. It's a soft dependency, no
actual functionality is broken by the lack of --quit, so I'm sending
it separately.
[1] https://public-inbox.org/git/78c7c281-82ec-2ba9-a607-dd2ecba54.
From: Derrick Stolee
The commit-graph feature began with a long list of planned
benefits, most of which are now complete. The future work
section has only a few items left.
As for making more algorithms aware of generation numbers,
some are only waiting for generation number v2 to ensure the
per
From: Derrick Stolee
The write_commit_graph() and write_commit_graph_reachable() methods
currently take two boolean parameters: 'append' and 'report_progress'.
We will soon expand the possible options to send to these methods, so
instead of complicating the parameter list, first simplify it.
Col
From: Derrick Stolee
The commit-graph file format had some shortcomings which we now
correct:
1. The hash algorithm was determined by a single byte, instead
of the 4-byte format identifier.
2. There was no way to update the reachability index we used.
We currently only support gen
The commit-graph file format has some shortcomings that were discussed
on-list:
1. It doesn't use the 4-byte format ID from the_hash_algo.
2. There is no way to change the reachability index from generation numbers
to corrected commit date [1].
3. The unused byte in the
From: Derrick Stolee
Allow the commit-graph builtin to specify the file format version
using the '--version=' option. Specify the version exactly in
the verification tests as using a different version would change
the offsets used in those tests.
Signed-off-by: Derrick Stolee
---
Documentation
From: Derrick Stolee
In anticipation of a new commit-graph file format version, create
a parameter for the write_commit_graph() and write_commit_graph_reachable()
methods to take a version number.
When the given version is zero, the implementation selects a
default value. Currently, the only val
From: Derrick Stolee
The write_commit_graph() method uses die() to report failure and
exit when confronted with an unexpected condition. This use of
die() in a library function is incorrect and is now replaced by
error() statements and an int return type.
Now that we use 'goto cleanup' to jump t
On Wed, May 1, 2019 at 7:18 PM Ævar Arnfjörð Bjarmason wrote:
>
>
> On Wed, May 01 2019, Duy Nguyen wrote:
>
> > On Wed, May 1, 2019 at 4:14 AM Jeff King wrote:
> >> It's definitely not implemented universally; each consumer of the config
> >> option must decide on it (and it will probably always
On Wed, May 01 2019, Duy Nguyen wrote:
> On Wed, May 1, 2019 at 4:14 AM Jeff King wrote:
>> It's definitely not implemented universally; each consumer of the config
>> option must decide on it (and it will probably always be that way to
>> some degree, since we don't know the semantics of each
On Wed, May 1, 2019 at 4:14 AM Jeff King wrote:
> It's definitely not implemented universally; each consumer of the config
> option must decide on it (and it will probably always be that way to
> some degree, since we don't know the semantics of each options; recall
> that we may be holding config
On Wed, May 1, 2019 at 5:18 PM Duy Nguyen wrote:
>
> On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
> > diff --git a/unpack-trees.h b/unpack-trees.h
> > index d344d7d296..732b262c4d 100644
> > --- a/unpack-trees.h
> > +++ b/unpack-trees.h
> > @@ -41,9 +41,15 @@ void setup_unpack_trees_porcela
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
>
> From: Phillip Wood
>
> These two patches teach read-tree how to avoid overwriting untracked
> files when doing '--reset -u' and also how to respect all of git's
> standard excludes files. I'd like to see the porcelain commands stop
> overwrit
On Wed, May 1, 2019 at 5:14 PM Phillip Wood wrote:
> diff --git a/unpack-trees.h b/unpack-trees.h
> index d344d7d296..732b262c4d 100644
> --- a/unpack-trees.h
> +++ b/unpack-trees.h
> @@ -41,9 +41,15 @@ void setup_unpack_trees_porcelain(struct
> unpack_trees_options *opts,
> */
> void clear_un
From: Phillip Wood
Currently there is no way to get read-tree to respect
.git/info/exclude or core.excludesFile so scripts using `read-tree -u`
have subtly different behavior to porcelain commands like checkout
even when they use --exclude-per-directory. This new option is copied
from ls-tree's -
From: Phillip Wood
These two patches teach read-tree how to avoid overwriting untracked
files when doing '--reset -u' and also how to respect all of git's
standard excludes files. I'd like to see the porcelain commands stop
overwriting untracked files, this is a first step on the way. I'm not
sur
From: Phillip Wood
Currently there is no way to get git to discard changes to the
worktree without overwriting untracked files. `reset --hard`,
`checkout --force`, `checkout :/` and `read-tree --reset -u`
will all overwrite untracked files. unpack_trees() has known how to
avoid overwriting untra
On Wed, May 1, 2019 at 1:10 AM Priscila Gutierres
wrote:
>
> Hi
> I want to contribute to git by creating and/or translating
> documentation. Where may I find the info to do this?
For translation, you could start at po/README. That's mostly UI
translation. I think some team actually started docum
Hi Johannes,
On Tue, Apr 30, 2019 at 07:21:40PM -0400, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 25 Apr 2019, SZEDER Gábor wrote:
>
> > On Mon, Apr 22, 2019 at 05:49:01PM -0400, Jeff King wrote:
> > > On Wed, Apr 17, 2019 at 12:58:31AM -0700, Denton Liu wrote:
> >
> > > > compat/mingw.c
On Tue, Apr 30, 2019 at 11:40 PM Derrick Stolee wrote:
>
> On 12/27/2018 10:56 AM, Nguyễn Thái Ngọc Duy wrote:
> > diff --git a/config.h b/config.h
> > index ee5d3fa7b4..62204dc252 100644
> > --- a/config.h
> > +++ b/config.h
> > @@ -103,6 +103,9 @@ extern int git_config_color(char *, const char *
On Wed, May 1, 2019 at 5:12 AM Johannes Schindelin
wrote:>
> Hi Duy,
>
> On Tue, 30 Apr 2019, Duy Nguyen wrote:
>
> > On Tue, Apr 30, 2019 at 8:02 AM Johannes Schindelin
> > wrote:
> > >
> > > Hi Duy,
> > >
> > > On Sun, 24 Mar 2019, Nguyễn Thái Ngọc Duy wrote:
> > >
> > > > While at there, move
The fread/fwrite-like functions in http.c, namely fread_buffer,
fwrite_buffer, fwrite_null, fwrite_sha1_file all return the
multiplication of the size and number of items they are being given.
Practically speaking, it doesn't matter, because in all contexts where
those functions are used, size is
Junio C Hamano:
Using interactive rebase has one flaw IMHO and that is the way it
handles dating its commit. Can you add an option to interactive rebase
that would make it use the date from the commit that is most recent
and not the date from the commit that is the oldest?
I am not sure what y
On Tue, Apr 30, 2019 at 8:41 PM Jeff King wrote:
>
> On Tue, Apr 30, 2019 at 02:19:11PM +0300, Aleksey Midenkov wrote:
>
> > > I gave it about 2000 commits (from v2.20.1 to master on git.git) to
> > > rebase. No luck.
> >
> > Please, try on this repo: g...@github.com:tempesta-tech/mariadb
> >
> >
66 matches
Mail list logo
