[PATCH] t7610-mergetool: add test cases for tempfile behavior

Ensure that mergetool.keepTemporaries is honored when resolving delete/delete conflicts. Ensure that stderr stays empty, and that worktree directories created by mergetool to are removed. Signed-off-by: David Aguilar --- t/t7610-mergetool.sh | 34

[PATCH v7 1/2] git-pull.c: introduce git_pull_config()

git-pull makes a seperate call to git_config_get_bool() to read the value of "rebase.autostash", this can be reduced as a call to git_config() is already there in the code. Introduce a callback function git_pull_config() to read "rebase.autostash" along with other variables. Helped-by: Junio C

[PATCH v7 2/2] pull --rebase: add --[no-]autostash flag

If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line. Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the

Re: [PATCH] rebase -p: avoid grep on potentailly non-ASCII data

The autoconf support you committed as 67f1790a has a small bug (the else cause should omit -a): +if grep -a ascii configure.ac >/dev/null; then + AC_MSG_RESULT([Using 'grep -a' for sane_grep]) + SANE_TEXT_GREP=-a +else + SANE_TEXT_GREP=-a +fi +GIT_CONF_SUBST([SANE_TEXT_GREP]) Anders -- To

Re: Resumable clone

Junio, > Yes, that is very close to what I said in the "what remains?" > section, but with a crucial difference in a detail. Perhaps reading > the message you are respoinding to again more carefully will clear > the confusion. This is what we want to allow the server to say > (from the message

Re: [PATCH v4 0/7] replacing strbuf_getline_lf() by strbuf_getline()

On Tue, Mar 8, 2016 at 7:25 PM, Moritz Neeb wrote: > how to deal with patches during the v2.8.0 rc freeze? Will they wait on > the mailing list until the feature release cycle is finished? > > Or if it's me who should act on this series, because it got below the > radar

Re: [PATCH v4 0/7] replacing strbuf_getline_lf() by strbuf_getline()

On 03/09/2016 01:39 AM, Junio C Hamano wrote: > Moritz Neeb writes: > >> how to deal with patches during the v2.8.0 rc freeze? Will they wait on >> the mailing list until the feature release cycle is finished? > > Because people are expected to stop getting distracted by

Re: Change in .gitignore handling: intended or bug?

Duy Nguyen writes: > On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano wrote: >> So what do we want to do for the upcoming release? > > I don't know. Befoire 2.8.0, all three matching cases are broken. With > the current changes on 2.8.0, one case is fixed

Response Required

Good day, I wish to contact you personally for an important proposal that might be of interest to you. Regards, shu...@qq.com -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at

Re: Change in .gitignore handling: intended or bug?

Junio C Hamano writes: > It is between (1) the current code is good enough ... > or (2) the half-way implementation we > have does not give enough advancement ... and we > are better off reverting the whole thing to go back to 2.7.2 > behaviour, planning to do a better job in

Re: [PATCH v4 0/7] replacing strbuf_getline_lf() by strbuf_getline()

Moritz Neeb writes: > how to deal with patches during the v2.8.0 rc freeze? Will they wait on > the mailing list until the feature release cycle is finished? Because people are expected to stop getting distracted by new features and no-op clean-up changes and instead to

Re: [PATCH v4 0/7] replacing strbuf_getline_lf() by strbuf_getline()

Hi, how to deal with patches during the v2.8.0 rc freeze? Will they wait on the mailing list until the feature release cycle is finished? Or if it's me who should act on this series, because it got below the radar during the rc freeze? To my knowledge there's only minor points that have to be

Re: Change in .gitignore handling: intended or bug?

On Wed, Mar 9, 2016 at 1:10 AM, Junio C Hamano wrote: > So what do we want to do for the upcoming release? I don't know. Befoire 2.8.0, all three matching cases are broken. With the current changes on 2.8.0, one case is fixed with the other cases broken. I guess it can create

Re: [PATCH] rebase -p: avoid grep on potentailly non-ASCII data

On Tue, Mar 08, 2016 at 03:36:26PM -0800, Junio C Hamano wrote: > diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh > index c0cfe88..4cde685 100644 > --- a/git-rebase--interactive.sh > +++ b/git-rebase--interactive.sh > @@ -1233,7 +1233,8 @@ then > git rev-list $revisions

Re: [PATCH] rebase -p: avoid grep on potentailly non-ASCII data

On Tue, Mar 08, 2016 at 03:20:26PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I actually wonder if we should have a build-time knob to put "grep -a" > > into sane_grep(). We do not ever plan to feed it binary data, so that > > will do what, provided the system grep

Re: [PATCH] rebase -p: avoid grep on potentailly non-ASCII data

Subject: rebase-i: clarify "is this commit relevant" test While I was checking all the call sites of sane_grep and sane_egrep, I noticed this one is somewhat strangely written. The lines in the file sane_grep works on all begin with 40-hex object name, so there is no real risk of confusing "test

Re: [PATCH] rebase -p: avoid grep on potentailly non-ASCII data

Jeff King writes: > I actually wonder if we should have a build-time knob to put "grep -a" > into sane_grep(). We do not ever plan to feed it binary data, so that > will do what, provided the system grep handles "-a". And on those that > do not know about "-a", one imagines that

Re: Git has been accepted as a GSoC 2016 mentor organization!

On Tue, Mar 08, 2016 at 03:01:47PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I've also signed us up for Outreachy, which is an internship program > > designed to encourage open source participation by under-represented > > groups. Details are here: > > > >

Re: [BUG?] fetch into shallow sends a large number of objects

On Tue, Mar 8, 2016 at 8:30 PM, Jeff King wrote: > On Tue, Mar 08, 2016 at 08:25:24AM -0500, Jeff King wrote: > >> > Good news. We have the mechanism in place, I think. >> > get_shallow_commits_by_rev_list() (from 'pu') will produce the right >> > shallow points for sending back to

Re: Git has been accepted as a GSoC 2016 mentor organization!

Jeff King writes: > I've also signed us up for Outreachy, which is an internship program > designed to encourage open source participation by under-represented > groups. Details are here: > > https://www.gnome.org/outreachy/ > > but I'll try to summarize here what it means for

Re: Git has been accepted as a GSoC 2016 mentor organization!

On Mon, Feb 29, 2016 at 10:01:52PM +0100, Matthieu Moy wrote: > Hi, > > This is my pleasure to inform you all that Git has just been accepted as > a GSoC mentor organization. > > https://summerofcode.withgoogle.com/organizations/?sp-page=3 > > I've invited Johannes, Stefan, Christian and

Re: jc/rerere-multi

Junio C Hamano writes: > Johannes Sixt writes: > >> Generally, the patches make sense. > > Thanks. As the tip commit says, this is still incomplete in that > "record and replay" part should work reasonably well, but things > like "forget" and "gc" are areas

Re: Is there a --stat or --numstat like option that'll allow me to have my cake and eat it too?

On Tue, Mar 8, 2016 at 9:51 PM, Jeff King wrote: > On Tue, Mar 08, 2016 at 04:08:21PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> What I really want is something for git-log more like >> git-for-each-ref, so I could emit the following info for each file >> being modified delimited

Re: Is there a --stat or --numstat like option that'll allow me to have my cake and eat it too?

On Tue, Mar 08, 2016 at 04:08:21PM +0100, Ævar Arnfjörð Bjarmason wrote: > What I really want is something for git-log more like > git-for-each-ref, so I could emit the following info for each file > being modified delimited by some binary marker: > > - file name before > - file name

Re: [PATCH 08/15] ref-filter: make "%(symref)" atom work with the ':short' modifier

Karthik Nayak writes: > On Tue, Mar 8, 2016 at 7:26 AM, Jacob Keller wrote: >> On Mon, Mar 7, 2016 at 3:08 PM, Junio C Hamano wrote: >>> Karthik Nayak writes: >>> The "%(symref)" atom doesn't work

[PATCH] commit: do not lose SQUASH_MSG contents

When concluding a conflicted "git merge --squash", the command failed to read SQUASH_MSG that was prepared by "git merge", and showed only the "# Conflicts:" list of conflicted paths. Signed-off-by: Sven Strickroth --- builtin/commit.c | 20 1 file

Re: [PATCH] Also read SQUASH_MSG if a conflict on a merge squash occurred

Sven Strickroth writes: > Here hook_arg1 would be always "merge" and never "squash"... Before my > change it was only "squash" if no conflict occurred. Oh, that wasn't an intended change. It was merely an illustration of a possible restructuring of the flow to avoid having to

Re: [PATCH] Also read SQUASH_MSG if a conflict on a merge squash occurred

Am 08.03.2016 um 19:32 schrieb Junio C Hamano: >> +if (!stat(git_path_squash_msg(), )) { >> +if (strbuf_read_file(, git_path_squash_msg(), 0) < 0) >> +die_errno(_("could not read SQUASH_MSG")); >> +hook_arg1 =

Re: [PATCH] Also read SQUASH_MSG if a conflict on a merge squash occurred

Sven Strickroth writes: > Subject: Re: [PATCH] Also read SQUASH_MSG if a conflict on a merge squash > occurred A reader sees this line in the output of "git shortlog --no-merges"; does it sufficiently tell her which Git subcommand is affected by this change, if this is a

[PATCH v6 2/2] pull --rebase: add --[no-]autostash flag

If rebase.autoStash configuration variable is set, there is no way to override it for "git pull --rebase" from the command line. Teach "git pull --rebase" the --[no-]autostash command line flag which overrides the current value of rebase.autoStash, if set. As "git rebase" understands the

[PATCH v6 1/2] git-pull.c: introduce git_pull_config()

git-pull makes a seperate call to git_config_get_bool() to read the value of "rebase.autostash", this can be reduced as a call to git_config() is already there in the code. Introduce a callback function git_pull_config() to read "rebase.autostash" along with other variables. Helped-by: Junio C

Re: Change in .gitignore handling: intended or bug?

Duy Nguyen writes: > On Tue, Mar 8, 2016 at 1:14 PM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> We need documentation update to settle this one before 2.8 final >>> ships, as we seem to be seeing more and more end-user

Re: Adding RFC 3161 timestamps to git tags

Michael J Gruber writes: > Anton Wuerfel venit, vidit, dixit 07.03.2016 15:15: >> Hello, >> >> as part of an university project we plan to implement time stamp >> signatures according to RFC 3161. This enables users to create and verify >> cryptographic time stamp

Re: Is there a --stat or --numstat like option that'll allow me to have my cake and eat it too?

Ævar Arnfjörð Bjarmason writes: > What I really want is something for git-log more like > git-for-each-ref, so I could emit the following info for each file > being modified delimited by some binary marker: > > - file name before > - file name after > - is rename? >

Re: Resumable clone

Duy Nguyen writes: > Yeah the determination is tricky, it depends on server setup. Let's > start with select the pack for download first because there could be > many of them. A heuristic (*) of choosing the biggest one in > $GIT_DIR/objects/pack is probably ok for now (we

Re: Resumable clone

Kevin Wern writes: > From what I understand, a pattern exists in clone to download a > packfile when a desired object isn't found as a resource. In this > case, if no alternative is listed in http-alternatives, the client > automatically checks the pack index(es) to see

Is there a --stat or --numstat like option that'll allow me to have my cake and eat it too?

I maintain a hook for Git that allows you to block binary pushes[1], from other implementations I've seen it's the least stupid thing out there that does that. Basically on-push it parses this: git log --pretty=format:%H -M100% --stat=9000,9001 .. The --stat=9000,9001 is there to make sure

git-evtag v2016.1

A while ago, I started a discussion on stronger verification of git tags: http://permalink.gmane.org/gmane.comp.version-control.git/264533 Since then I've been maintaining: https://github.com/cgwalters/git-evtag Which I think works well. At some point I'd like to discuss merging some of the

Re: More configuration options for some commonly used command-line options

Sidhant Sharma wrote: > Hi, > > Regarding the GSoC Microproject 'Add configuration options for some commonly > used command-line options', currently the list [1] mentions only > `git commit -v`. Can the following also be candidates for configurations? > * git log -p > * git remote -v > * git

Re: [PATCH] rebase -p: avoid grep on potentailly non-ASCII data

On Tue, Mar 08, 2016 at 02:45:20PM +0100, Michael J Gruber wrote: > It may be worth noting whether other occurrences of "sane_grep" are safe > from binary input. > > After all, one my question the degree of sanity of our sane_grep, or > whether we need asane_grep and bisane_grep in our shell

Re: [PATCH] rebase -p: avoid grep on potentailly non-ASCII data

Torsten Bögershausen venit, vidit, dixit 08.03.2016 13:25: > On 03/08/2016 08:59 AM, Anders Kaseorg wrote: >> The included test case, which uses rebase -p with non-ASCII commit >> messages, was failing as follows: >> >>Warning: the command isn't recognized in the following line: >> -

Re: [BUG?] fetch into shallow sends a large number of objects

On Tue, Mar 08, 2016 at 08:25:24AM -0500, Jeff King wrote: > > Good news. We have the mechanism in place, I think. > > get_shallow_commits_by_rev_list() (from 'pu') will produce the right > > shallow points for sending back to the client if you pass "--not > > " to it. It's meant to be used for >

Re: Adding RFC 3161 timestamps to git tags

Anton Wuerfel venit, vidit, dixit 07.03.2016 15:15: > Hello, > > as part of an university project we plan to implement time stamp > signatures according to RFC 3161. This enables users to create and verify > cryptographic time stamp signatures to prove that a commit existed at a > certain point

Re: [BUG?] fetch into shallow sends a large number of objects

On Tue, Mar 08, 2016 at 07:33:43PM +0700, Duy Nguyen wrote: > On Tue, Mar 8, 2016 at 7:14 PM, Jeff King wrote: > > ... > > > > So I think the solution to both is that we need to do a _separate_ > > traversal with all of the positive tips we're going to send, and the > > parents of

Re: [BUG?] fetch into shallow sends a large number of objects

On Tue, Mar 8, 2016 at 7:14 PM, Jeff King wrote: > ... > > So I think the solution to both is that we need to do a _separate_ > traversal with all of the positive tips we're going to send, and the > parents of any shallow commits the client has, to find their fork points > (i.e.,

Re: git diff does not precompose unicode file paths (OS X)

And if not, I can put it on my TODO-stack. I have read through the official contribution guidelines and I think I can send an official patch. In this case, would you prefer to have a single commit since the change is related? Or would you prefer keeping it in separate commits, since they are

Re: [PATCH] rebase -p: avoid grep on potentailly non-ASCII data

On 03/08/2016 08:59 AM, Anders Kaseorg wrote: The included test case, which uses rebase -p with non-ASCII commit messages, was failing as follows: Warning: the command isn't recognized in the following line: - Binary file (standard input) matches You can fix this with 'git rebase

Re: [BUG?] fetch into shallow sends a large number of objects

On Tue, Mar 08, 2016 at 07:53:35AM +0700, Duy Nguyen wrote: > > I also do not offhand think of a good way to use the topology or > > timestamp to figure out the best "depth" to truncate the side branch > > at. The server side may be able to figure out that things before 'F' > > in your picture

Re: [BUG?] fetch into shallow sends a large number of objects

On Mon, Mar 07, 2016 at 03:47:53PM -0800, Junio C Hamano wrote: > > Is this user error to call "git fetch" without "--depth" in the > > subsequent cases? Or should git remember that we are in a shallow repo, > > and presume that the user by default wants to keep things shallow? > > Hmph, you

Re: Resumable clone

On Tue, Mar 8, 2016 at 10:33 AM, Kevin Wern wrote: > Hey Junio and Duy, > > Thank you for your thorough responses! I'm new to git dev, so it's > extremely helpful. > >> - The server side endpoint does not have to be, and I think it >> should not be, implemented as an

Re: Adding RFC 3161 timestamps to git tags

Hello Junio, thanks for your reply. See my comments below. "Junio C Hamano" writes: > A few random thoughts that come to mind, none of which is > rhetorical [*1*]: > > - What should happen when the timestamping service is unreachable? >The user cannot get her work done

Re: Change in .gitignore handling: intended or bug?

On Tue, Mar 8, 2016 at 1:14 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> We need documentation update to settle this one before 2.8 final >> ships, as we seem to be seeing more and more end-user confusion on >> the list. I tried to come up with a

[PATCH] rebase -p: avoid grep on potentailly non-ASCII data

The included test case, which uses rebase -p with non-ASCII commit messages, was failing as follows: Warning: the command isn't recognized in the following line: - Binary file (standard input) matches You can fix this with 'git rebase --edit-todo'. Or you can abort the rebase with 'git