Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Am 16.06.2017 um 15:49 schrieb Johannes Schindelin: On Thu, 15 Jun 2017, Junio C Hamano wrote: diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh index 325ec75353..801bce25da 100755 --- a/t/t3420-rebase-autostash.sh +++ b/t/t3420-rebase-autostash.sh @@ -45,7 +45,7 @@

Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables

Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 16 2017, SZEDER Gábor jotted: >> --- a/Documentation/git-clone.txt >> +++ b/Documentation/git-clone.txt >> @@ -186,6 +186,11 @@ objects from the source repository into a pack in the >> cloned repository. >> values are given for the same key, each

Re: [PATCHv4 1/2] clone: respect additional configured fetch refspecs during initial fetch

On Wed, Jun 14, 2017 at 2:48 AM, Jonathan Nieder wrote: >> diff --git a/remote.h b/remote.h >> index 924881169..9ad8c1085 100644 >> --- a/remote.h >> +++ b/remote.h >> @@ -164,6 +164,7 @@ struct ref *ref_remove_duplicates(struct ref *ref_map); >> >> int

Re: [PATCH] docs/pretty-formats: stress that %- removes all preceding line-feeds

SZEDER Gábor wrote: > Signed-off-by: SZEDER Gábor > --- > A mere plural "line-feeds" was too subtle for me to grasp on first > (and second...) reading. This could go in the commit message. > Documentation/pretty-formats.txt | 4 ++-- > 1 file changed, 2 insertions(+), 2

Re: [PATCH v4 4/6] coccinelle: add a rule to make "expression" code use FREE_AND_NULL()

Ævar Arnfjörð Bjarmason writes: > A follow-up to the existing "type" rule added in an earlier > change. This catches some occurrences that are missed by the previous > rule. > > Signed-off-by: Ævar Arnfjörð Bjarmason > --- Hmph, I wonder if the "type" thing

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Adam Langley writes: > However, as I'm not a git developer, I've no opinion on whether the > cost of carrying implementations of these functions is worth the speed > vs using SHA-256, which can be assumed to be supported everywhere > already. Thanks. My impression from this

[PATCH 4/5] remote.c: eliminate remote->fetch_refspec

'struct remote' stores fetch refspecs twice: once in their original string form in remote->fetch_refspecs and once in their parsed form in remote->fetch. The main reason for this is that we want to read the configuration only once, but we don't want to error out while doing so because of a bogus

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 03:24:19PM +0200, Johannes Schindelin wrote: > I have no doubt that Visual Studio Team Services, GitHub and Atlassian > will eventually end up with FPGAs for hash computation. So that's that. I actually doubt this from the GitHub side. Hash performance is not even on our

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16, 2017 at 6:24 AM, Johannes Schindelin wrote: > > And while I am really thankful that Adam chimed in, I think he would agree > that BLAKE2 is a purposefully weakened version of BLAKE, for the benefit > of speed That is correct. Although worth keeping in

[PATCHv5 1/2] clone: respect additional configured fetch refspecs during initial fetch

The initial fetch during a clone doesn't transfer refs matching additional fetch refspecs given on the command line as configuration variables. This contradicts the documentation stating that configuration variables specified via 'git clone -c = ...' "take effect immediately after the repository

[PATCHv5 0/2] clone: respect additional configured fetch refspecs during initial fetch

Only small, straightforward adjustments, mostly based on Jonathan's comments. The one exception is passing the default refspec using strbuf_detach(), because add_fetch_refspec() doesn't make a copy of it internally. It doesn't make any difference in practice, because strbuf default_refspec

[PATCHv5 2/2] Documentation/clone: document ignored configuration variables

Due to limitations/bugs in the current implementation, some configuration variables specified via 'git clone -c var=val' (or 'git -c var=val clone') are ignored during the initial fetch and checkout. Let the users know which configuration variables are known to be ignored ('remote.origin.mirror'

Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables

On Fri, Jun 16 2017, SZEDER Gábor jotted: > Due to limitations/bugs in the current implementation, some > configuration variables specified via 'git clone -c var=val' (or 'git > -c var=val clone') are ignored during the initial fetch and checkout. > > Let the users know which configuration

Re: [PATCHv5 1/2] clone: respect additional configured fetch refspecs during initial fetch

SZEDER Gábor wrote: > Helped-by: Jeff King > Signed-off-by: SZEDER Gábor > --- > builtin/clone.c | 36 +++- > remote.c| 13 + > remote.h| 1 + > t/t5611-clone-config.sh |

Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables

SZEDER Gábor wrote: > Due to limitations/bugs in the current implementation, some > configuration variables specified via 'git clone -c var=val' (or 'git > -c var=val clone') are ignored during the initial fetch and checkout. > > Let the users know which configuration variables are known to be >

[PATCH 3/5] remote.c: extract a helper function to parse a single refspec

Fetch refspecs read from the configuration are currently parsed lazily: they are collected into a string array for each remote while reading the configuration and then refspecs of a particular remote are parsed together later when the remote is accessed by remote_get() or for_each_remote(). We

[PATCH 1/5] remote: don't use remote->{fetch,push}_refspec

builtin/remote.c uses remote->fetch_refspec and remote->push_refspec, i.e. refspecs as strings, in a few places, e.g. in an error message or to set configuration variables. Since we are about to eliminate remote->{fetch,push}_refspec, recreate those strings from the corresponding

[PATCH 2/5] remote.c: don't pass copies of refspecs to add_{fetch,push}_refspec()

Currently neither add_fetch_refspec() nor add_push_refspec() duplicate the refspecs before appending them to an array of refspecs, therefore all their callers pass them copies of refspecs. Soon we won't store refspecs as strings, therefore passing duplicated strings to these functions will not be

[PATCH 5/5] remote.c: eliminate remote->push_refspec

Do the same as in the previous patch, but for push refspecs, i.e. with remote->push_refspec, remote->push and add_push_refspec(). Signed-off-by: SZEDER Gábor --- builtin/push.c | 12 +++- builtin/remote.c | 19 --- remote.c | 29

[RFC/PATCH 0/5] remote: eliminate remote->{fetch,push}_refspec and lazy parsing of refspecs

'struct remote' stores refspecs twice: once in their original string form in remote->{fetch,push}_refspecs and once in their parsed form in remote->{fetch,push}. This is necessary, because we need the refspecs for lazy parsing after we finished reading the configuration: we don't want to die()

Re: [PATCH 2/3] wt-status: add optional stash status information

Jeff King writes: > On Fri, Jun 16, 2017 at 12:30:49AM -0400, Liam Beguin wrote: > >> @@ -1642,6 +1664,8 @@ static void wt_longstatus_print(struct wt_status *s) >> } else >> printf(_("nothing to commit, working tree clean\n")); >> } >> +

Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables

SZEDER Gábor writes: > Due to limitations/bugs in the current implementation, some > configuration variables specified via 'git clone -c var=val' (or 'git > -c var=val clone') are ignored during the initial fetch and checkout. > > Let the users know which configuration

Re: [PATCH 1/3] stash: update documentation to use 'stash entries'

Liam Beguin writes: > Most of the time, a 'stash entry' is called a 'stash' > or a 'stash state'. Lets use 'stash entry' instead. > > Signed-off-by: Liam Beguin > --- > diff --git a/Documentation/git-stash.txt b/Documentation/git-stash.txt > index

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Junio C Hamano wrote: > Junio C Hamano writes: >> Adam Langley writes: >>> However, as I'm not a git developer, I've no opinion on whether the >>> cost of carrying implementations of these functions is worth the speed >>> vs using SHA-256, which can be

Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables

On Fri, Jun 16, 2017 at 11:10 PM, Ævar Arnfjörð Bjarmason wrote: > diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt > index 35cc34b2fb..2169e5c97f 100644 > --- a/Documentation/git-clone.txt > +++ b/Documentation/git-clone.txt > @@

Re: [PATCH v4 5/5] stash: implement builtin stash

Joel Teichroeb writes: > +static void stash_create_callback(struct diff_queue_struct *q, > + struct diff_options *opt, void *cbdata) > +{ > + int i; > + > + for (i = 0; i < q->nr; i++) { > + struct diff_filepair *p =

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Johannes Sixt writes: > Am 16.06.2017 um 15:49 schrieb Johannes Schindelin: >> On Thu, 15 Jun 2017, Junio C Hamano wrote: >>> diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh >>> index 325ec75353..801bce25da 100755 >>> --- a/t/t3420-rebase-autostash.sh >>>

Re: [PATCH 1/5] remote: don't use remote->{fetch,push}_refspec

SZEDER Gábor writes: > diff --git a/remote.c b/remote.c > index 336db8298..a021decee 100644 > --- a/remote.c > +++ b/remote.c > @@ -919,6 +919,26 @@ char *apply_refspecs(struct refspec *refspecs, int > nr_refspec, > return query.dst; > } > > +void

Re: [suggestion] Include commit-ish in git status output

Mahmoud Al-Qudsi writes: > I hope it is not considered too forward of me for my first post to this list > to be a suggestion on a change to git’s behavior (though not in any > functional manner); but a persistent frustration for me and everyone I’ve > worked with (so, yes,

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16 2017, Jonathan Nieder jotted: > Part of the reason I suggested previously that it would be helpful to > try to benchmark Git with various hash functions (which didn't go over > well, for some reason) is that it makes these comparisons more > concrete. Without measuring, it is hard

Re: [RFC/PATCH 0/5] remote: eliminate remote->{fetch,push}_refspec and lazy parsing of refspecs

SZEDER Gábor writes: > 'struct remote' stores refspecs twice: once in their original string > form in remote->{fetch,push}_refspecs and once in their parsed form in > remote->{fetch,push}. This is necessary, because we need the refspecs > for lazy parsing after we finished

Re: [PATCHv5 2/2] Documentation/clone: document ignored configuration variables

On Fri, Jun 16 2017, Jonathan Nieder jotted: > Ævar Arnfjörð Bjarmason wrote: >> On Fri, Jun 16 2017, SZEDER Gábor jotted: > >>> --- a/Documentation/git-clone.txt >>> +++ b/Documentation/git-clone.txt >>> @@ -186,6 +186,11 @@ objects from the source repository into a pack in the >>> cloned

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Junio C Hamano writes: > Adam Langley writes: > >> However, as I'm not a git developer, I've no opinion on whether the >> cost of carrying implementations of these functions is worth the speed >> vs using SHA-256, which can be assumed to be supported

Re: [PATCH 04/28] packed_ref_store: move `packed_refs_lock` member here

On 06/16/2017 07:39 AM, Stefan Beller wrote: > On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty > wrote: >> [...] >> @@ -125,7 +125,7 @@ static void clear_packed_ref_cache(struct >> files_ref_store *refs) >> if (refs->packed_ref_store->cache) { >>

Re: [PATCH 15/28] packed_peel_ref(): new function, extracted from `files_peel_ref()`

On 06/16/2017 07:42 AM, Stefan Beller wrote: > On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty > wrote: >> This will later become a method of `packed_ref_store`. > > Also while touching it, maybe rename sha1 to object_hash > (not saying object_id as that would be

Re: Best practices for updating old repos

On 06/15/2017 09:22 PM, Stefan Beller wrote: On Thu, Jun 15, 2017 at 5:52 PM, Michael Eager wrote: One other variant of the rebase approach I've thought of is to do this incrementally, rebasing the old repo against an upstream commit a short time after the old repo was

Re: Best practices for updating old repos

Thanks for your comments. On 06/15/2017 07:57 PM, Michael O'Cleirigh wrote: Hi Michael, In git if you don't merge often then you get these merge conflict hell situations. In my experience the main conflicts come not from the unified diff of those 130 commits but from differences in the

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

On Fri, Jun 16 2017, brian m. carlson jotted: > On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote: >> On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson >> wrote: >> > SHA-256 acceleration exists for some existing Intel platforms already. >> >

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Thu, 2017-06-15 at 09:12 -0400, Jeff King wrote: > On Thu, Jun 15, 2017 at 07:43:17AM -0400, Samuel Lijin wrote: > > > > Saying just "staged changes" is definitely accurate. I don't know > > > if > > > some users would find that too terse, too. The phrase "not staged > > > for > > > commit"

Re: [PATCH 0/3] add stash count information to git-status command

On Fri, Jun 16, 2017 at 12:30:47AM -0400, Liam Beguin wrote: > As discussed here [*1*], this allows `git status` to show the number of > entries currently stashed away. > > I also tried to update the related parts of the documentation to use > 'stash entry' instead of 'stash' as we agreed that

Re: [PATCH 3/3] glossary: define stash entries

On Fri, Jun 16, 2017 at 12:30:50AM -0400, Liam Beguin wrote: > diff --git a/Documentation/glossary-content.txt > b/Documentation/glossary-content.txt > index 6e991c246915..026f66e7240a 100644 > --- a/Documentation/glossary-content.txt > +++ b/Documentation/glossary-content.txt > @@ -570,6

Re: [BUG] GITK don't show unstaged changes

If this is an intentional change and not a bug, then gitk has become less useful to me, since I've always used it to do a quick review before committing. It's easier than using bash. Sad. :-( De: Konstantin Khomoutov Para: Clébio C.

Fwd: Best practices for updating old repos

(Sorry I sent this originally last night in gmail but not in plain text mode and it bounced) Hi Michael, In git if you don't merge often then you get these merge conflict hell situations. In my experience the main conflicts come not from the unified diff of those 130 commits but from

Re: [PATCH] wt-status.c: Modified status message shown for a parent-less branch

On Fri, Jun 16, 2017 at 04:06:48PM +0530, Kaartic Sivaraam wrote: > From what I could get from this thread, I guess the current patch > stands something like the one below. I tried building it with the below > change, it seems to be having a little issue. I'm not sure why, it > seems to be

Re: [PATCH 2/3] wt-status: add optional stash status information

On Fri, Jun 16, 2017 at 12:30:49AM -0400, Liam Beguin wrote: > @@ -1642,6 +1664,8 @@ static void wt_longstatus_print(struct wt_status *s) > } else > printf(_("nothing to commit, working tree clean\n")); > } > + if

Re: [PATCH 0/3] add stash count information to git-status command

Hi, On 16/06/17 08:16 AM, Jeff King wrote: > On Fri, Jun 16, 2017 at 12:30:47AM -0400, Liam Beguin wrote: > >> As discussed here [*1*], this allows `git status` to show the number of >> entries currently stashed away. >> >> I also tried to update the related parts of the documentation to use >>

Re: [PATCH 1/3] stash: update documentation to use 'stash entries'

On Fri, Jun 16, 2017 at 12:30:48AM -0400, Liam Beguin wrote: > Most of the time, a 'stash entry' is called a 'stash' > or a 'stash state'. Lets use 'stash entry' instead. I agree that this reads better. There is one exception: > diff --git a/git-stash.sh b/git-stash.sh > index

Re: [BUG] GITK don't show unstaged changes

On Fri, Jun 16, 2017 at 11:27:39AM +, Clébio C. Felix wrote: >>> Details: https://github.com/git-for-windows/git/issues/1203 >>> >>> Version with bug: 2.13.1 >>> Normal: 2.13.0 >> >> Attached are the pictures for those who doesn't want to browse that bug >> and dig them up. >> >>

Re: [PATCH 2/2] date: use localtime() for "-local" time formats

On Thu, Jun 15, 2017 at 06:12:31PM +0200, René Scharfe wrote: > Am 15.06.2017 um 15:52 schrieb Jeff King: > > But for the special case of the "-local" formats, we can > > just skip the adjustment and use localtime() instead of > > gmtime(). This makes --date=format-local:%Z work correctly, > >

Re: Which hash function to use, was Re: RFC: Another proposed hash function transition plan

Hi, On Fri, 16 Jun 2017, Ævar Arnfjörð Bjarmason wrote: > On Fri, Jun 16 2017, brian m. carlson jotted: > > > On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote: > > > >> So I don't follow the argument that we shouldn't weigh future HW > >> acceleration highly just because

Re: [PATCH v2 0/3] Add regression tests for rectent rebase -i fixes

Hi Junio, On Thu, 15 Jun 2017, Junio C Hamano wrote: > diff --git a/t/t3420-rebase-autostash.sh b/t/t3420-rebase-autostash.sh > index 325ec75353..801bce25da 100755 > --- a/t/t3420-rebase-autostash.sh > +++ b/t/t3420-rebase-autostash.sh > @@ -45,7 +45,7 @@ create_expected_success_am() { > } >

Re: [PATCH v5 08/10] rebase -i: skip unnecessary picks using the rebase--helper

Hi Liam, On Thu, 15 Jun 2017, Liam Beguin wrote: > On 14/06/17 09:08 AM, Johannes Schindelin wrote: > > diff --git a/sequencer.c b/sequencer.c > > index a697906d463..a0e020dab09 100644 > > --- a/sequencer.c > > +++ b/sequencer.c > > @@ -2640,3 +2640,110 @@ int check_todo_list(void) > > > >

Re: git push recurse.submodules behavior changed in 2.13

On Mon, Jun 12, 2017 at 1:27 PM, Stefan Beller wrote: > On Sat, Jun 10, 2017 at 6:28 AM, John Shahid wrote: >> bump. it's been a while and I'm still not clear what the next steps >> are. I'm happy to send a patch but I would like to get a consensus >>

Re: [PATCH v5 00/10] The final building block for a faster rebase -i

Hi Junio, On Thu, 15 Jun 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > Changes since v4: > > > > - replaced the "sha1s" part of the names by "ids", to reflect the > > current effort to move away from the cryptographically unsafe SHA-1 > > > > -

Re: [PATCH 04/28] packed_ref_store: move `packed_refs_lock` member here

On Thu, Jun 15, 2017 at 11:43 PM, Michael Haggerty wrote: > I chose that name because it is a `ref_store`, with `packed_` being a > short prefix that tells what kind of `ref_store`. > > The next question is, why `ref_store` as opposed to `refs_store`? To me > it sounds more

Re: [PATCH 15/28] packed_peel_ref(): new function, extracted from `files_peel_ref()`

On Thu, Jun 15, 2017 at 11:46 PM, Michael Haggerty wrote: > On 06/16/2017 07:42 AM, Stefan Beller wrote: >> On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty >> wrote: >>> This will later become a method of `packed_ref_store`. >> >> Also while

Re: [PATCH v4 5/5] stash: implement builtin stash

Joel Teichroeb writes: > diff --git a/builtin/stash.c b/builtin/stash.c > new file mode 100644 > index 00..a9680f2909 > --- /dev/null > +++ b/builtin/stash.c > ... > +static const char *ref_stash = "refs/stash"; > +static int quiet = 0; Let BSS take care of