Re: A note from the maintainer

Jeff King wrote: > I collected the message-ids from my archive. Interestingly, I had a > dozen or so that did not have message-ids at all. I think most of them > are from patches that put the "From " line in the body, like this one: > >

Re: storing cover letter of a patch series?

On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen wrote: > On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller wrote: >> is what you want. Maybe we want to see a patch that adds the reverse >> functionality as well, i.e. git-am will store the the cover letter as the

Re: [PATCH v1 1/2] t0027: Correct raciness in NNO test

On Sat, Aug 13, 2016 at 06:50:19PM +0200, Johannes Sixt wrote: > Am 12.08.2016 um 18:51 schrieb tbo...@web.de: > >From: Torsten Bögershausen > > > >When a non-reversible CRLF conversion is done in "git add", > >a warning is printed on stderr (or Git dies, depending on checksafe) >

[PATCH v2 1/1] convert: Correct NNO tests and missing `LF will be replaced by CRLF`

From: Torsten Bögershausen When a non-reversible CRLF conversion is done in "git add", a warning is printed on stderr (or Git dies, depending on checksafe) The function commit_chk_wrnNNO() in t0027 was written to test this, but did the wrong thing: Instead of looking at the

Re: [PATCH] difftool: always honor "command not found" exit code

John Keeping writes: > At the moment difftool's "trust exit code" logic always suppresses the > exit status of the diff utility we invoke. This is useful because we > don't want to exit just because diff returned "1" because the files > differ, but it's confusing if the

[PATCH] squash! diff: add --diff-line-prefix option for passing in a prefix

The '>' character is not a legal part of filenames on Windows. So let's just not use it in Git's source code. This poses a challenge in the test script t4013 which distills command-lines into file names (so that the expected outcome can be stored in files with said names). We have to take

Re: [PATCH] difftool: always honor "command not found" exit code

On Sat, Aug 13, 2016 at 12:30:28PM +0100, John Keeping wrote: > At the moment difftool's "trust exit code" logic always suppresses the > exit status of the diff utility we invoke. This is useful because we > don't want to exit just because diff returned "1" because the files > differ, but it's

Re: [PATCH] correct FLEXPTR_* example in comment

On Sat, Aug 13, 2016 at 07:26:02PM +0200, René Scharfe wrote: > > I suppose it could assert(sizeof((x)->flexname) == FLEX_ALLOC) or > > something, but I'm not sure if it is worth worrying about. > > You can't use sizeof with an actual flexible array. It only works if > FLEX_ARRAY is defined as

Re: A note from the maintainer

Eric Wong wrote: > Thanks, should all be imported. Oops, missed one which was missing X-Mailing-List (causing it to not get imported) and had "X-No-Archive: yes" set; which meant I couldn't get it from gmane this year. Hmm... XNAY defeats the point of public-inbox (and probably

Re: [PATCH] receive-pack: use FLEX_ALLOC_MEM in queue_command()

On Sat, Aug 13, 2016 at 05:38:56PM +0200, René Scharfe wrote: > Use the macro FLEX_ALLOC_MEM instead of open-coding it. This shortens > and simplifies the code a bit. Thanks, looks good (I obviously missed a few opportunities for conversion during the initial introduction of FLEX_ALLOC simply

Re: git-mergetool reverse file ordering

On Wed, Jul 27, 2016 at 11:14:28AM +0100, Luis Gutierrez wrote: > Hi, > > Attached is a potential patch for reversing the order on which > git-mergetool presents the files to merge. > > Currently, when running git-mergetool, it performs a sort of the files > to merge by alphabetical ordering.

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

On Sat, Aug 13, 2016 at 8:59 AM, Junio C Hamano wrote: > Jeff King writes: > >> So assuming everything I just said isn't complete bollocks, I think we >> can move to a future where nobody uses the compaction heuristic. And >> there are three ways to deal with

Re: git-mergetool reverse file ordering

On Sat, Aug 13, 2016 at 08:42:21PM -0700, David Aguilar wrote: > This use case makes me wonder whether the sorting we do here is > something that should be opened up a bit so that the it's not > quite so set in stone. > > For example, an extension to the approach taken by this patch > would be to

Re: [PATCH 1/8] xdl_change_compact(): rename some local variables for clarity

On 08/04/2016 09:06 AM, Jeff King wrote: > On Thu, Aug 04, 2016 at 12:00:29AM +0200, Michael Haggerty wrote: > >> * ix -> i >> * ixo -> io >> * ixs -> start >> * grpsiz -> groupsize > > After your change, I immediately understand three of them. But what is > "io"? The (pre-existing) convention

Re: A note from the maintainer

On Sun, Aug 14, 2016 at 01:27:06AM +, Eric Wong wrote: > What's also interesting about the thread you highlighed is the > extra '<>' when you started that thread; and I have a bug where > I strip off an extra '>' which needs to be fixed... Oh, that's interesting. It's not in the message that

[PATCH] make rebase respect core.hooksPath if set

when looking for pre-rebase and post-rewrite hooks, git-rebase only looks for hooks dir using `git rev-parse --git-path hooks`, which didn't consider the path overridden by core.hooksPath. Signed-off-by: ryenus --- git-rebase--interactive.sh | 14 +-

Re: [PATCH] make rebase respect core.hooksPath if set

Patch attached. It seems gmail ruined the white spaces. Not sure how to stop gmail from doing that. Sorry for me, and for Gmail. 0001-make-rebase-respect-core.hooksPath-if-set.patch Description: Binary data

Getting the "message" given a branch designation and conversely

I am learning how to use git. I would like to know how: Given a branch's designation, such as "master~4", how can I see the message I furnished when I created the branch using "git commit"? Conversely, given the message I furnished to "git commit", when I created a branch, how can I see the

Re: [PATCH 1/8] xdl_change_compact(): rename some local variables for clarity

On Sat, Aug 13, 2016 at 09:38:33PM +0200, Michael Haggerty wrote: > On 08/04/2016 09:06 AM, Jeff King wrote: > > On Thu, Aug 04, 2016 at 12:00:29AM +0200, Michael Haggerty wrote: > > > >> * ix -> i > >> * ixo -> io > >> * ixs -> start > >> * grpsiz -> groupsize > > > > After your change, I

[PATCH v2 0/1] convert: Correct NNO tests and missing `LF will be replaced by CRLF`

From: Torsten Bögershausen Change since v1: - The changes done in 1/2 in t0027 needed to be reverted in 2/2. Put both changes for convert.c and t0027 into a single commit Thanks to Johannes Sixt. Torsten Bögershausen (1): convert: Correct NNO tests and missing `LF will be

Re: A note from the maintainer

On Sun, Aug 14, 2016 at 02:12:34AM +, Eric Wong wrote: > Eric Wong wrote: > > Thanks, should all be imported. > > Oops, missed one which was missing X-Mailing-List (causing > it to not get imported) and had "X-No-Archive: yes" set; > which meant I couldn't get it from gmane

Re: A note from the maintainer

From: "Eric Wong" Yes, I was somewhat careful to check for proper mboxes from gmane; I just missed entire ranges :x There were a number of messages that were listed by gmane as being in the various Git for Windows lists such as msysgit, especially when the messages went to

Draft of Git Rev News edition 18

Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-18.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub

Re: Getting the "message" given a branch designation and conversely

From: I am learning how to use git. I would like to know how: Given a branch's designation, such as "master~4", how can I see the message I furnished when I created the branch using "git commit"? Conversely, given the message I furnished to "git commit", when I created a

[PATCH] submodule: mark a file-local symbol as static

Signed-off-by: Ramsay Jones --- Hi Stefan, If you need to re-roll your 'sb/submodule-clone-rr' branch, could you please squash this into the relevant patch (commit 7bcd1d17, "clone: recursive and reference option triggers submodule alternates", 11-08-2016).

Re: git cherry-pick conflict error message is deceptive when cherry-picking multiple commits

Hi Stephen, On Wed, Aug 10, 2016 at 9:21 PM, Stephen Morton wrote: > > Formatting on previous email was terrible, plus the diff wasn't performed > against origin. Re-sending. Thanks for working on this... > (Finally getting back to this.) > > Something like the diff

Re: [ANNOUNCE] tig-2.2

On Wed, Aug 10, 2016 at 11:23:56PM -0400, Jonas Fonseca wrote: > It's crazy to think that Tig has happily browsed Git repos for more than 10 > years! Thanks to everybody who contributed and made that possible. Looking > forward to the next 10 years ... Thanks for all your work on tig. I have

Re: [PATCH] make rebase respect core.hooksPath if set

On Sun, Aug 14, 2016 at 12:29 PM, ryenus wrote: > Patch attached. > > It seems gmail ruined the white spaces. > Not sure how to stop gmail from doing that. > Sorry for me, and for Gmail. Did you use git-send-email? I don't think that the gmail ui works. If you have 2-factor

Re: Draft of Git Rev News edition 18

Christian Couder writes: > You can also reply to this email. I am not sure that is to be recommended, as that ends up going to the list, but anyway, these - Michael's "finding better -/+ assignment in diff using indent heuristic" - Philip Oakley's updates to

Re: Draft of Git Rev News edition 18

From: "Christian Couder" Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-18.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and

Re: [PATCH v1 3/3] doc: rebase: clarify fixup! fixup! constraint

Philip Oakley writes: > 22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27) That's a noun that names a commit object. What about it? > I certainly misunderstood what this meant. It sounded like only one fixup! was > allowed per commit (i.e. one mistake)

[PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision

Be clearer that the --fixup/--squash options can take any of the gitrevisions methods of specifying a commit, not just a 'hash'. Signed-off-by: Philip Oakley --- v1 It's not immediately obvious what different forms the option can take. Spell out, and refer to the git

[PATCH v1 3/3] doc: rebase: clarify fixup! fixup! constraint

22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27) Signed-off-by: Philip Oakley --- v1 the historical discussion about this is here https://public-inbox.org/git/20130611180530.GA18488%40oinkpad.pimlott.net/ I certainly misunderstood what this meant. It

[PATCH v1 2/3] doc: rebase: fixup! can take an object name

Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition to message, 2010-11-04) the commit subject can refer directly to the destination object hash as a single word.)... Signed-off-by: Philip Oakley --- v1 This is about the actual commit subject line, rather

[PATCH v1 0/3] fixup fixup documenation

With the review of the list's workflow, and failings in my personal workflow, I asked a couple of questions about fixup and discovered that my reading of the man pages hadn't provided the illumination they hope to give. Here's three little documenation patches, and some queries to go with them.

Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision

Philip Oakley writes: > Be clearer that the --fixup/--squash options can take any of the > gitrevisions methods of specifying a commit, not just a 'hash'. > > Signed-off-by: Philip Oakley > --- > ... > @@ -81,15 +81,15 @@ OPTIONS > --fixup=:: >

What's cooking in git.git (Aug 2016, #06; Sun, 14)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. The preview for the upcoming 2.10

Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision

From: "Junio C Hamano" Philip Oakley writes: Be clearer that the --fixup/--squash options can take any of the gitrevisions methods of specifying a commit, not just a 'hash'. Signed-off-by: Philip Oakley --- ... @@ -81,15 +81,15

Re: [PATCH v1 3/3] doc: rebase: clarify fixup! fixup! constraint

From: "Junio C Hamano" Philip Oakley writes: 22c5b13 (rebase -i: handle fixup! fixup! in --autosquash, 2013-06-27) That's a noun that names a commit object. What about it? It's the commit that introduced the original change that's being

Re: Draft of Git Rev News edition 18

From: "Eric Wong" Philip Oakley wrote: From: "Christian Couder" >You can also reply to this email. I see you mention in passing (weel in the small headings near the bottom) that gmane web interface has gone away. It may be

[ANNOUNCE] Git v2.10.0-rc0

An early preview release Git v2.10.0-rc0 is now available for testing at the usual places. It is comprised of 589 non-merge commits since v2.9.0, contributed by 67 people, 20 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The

Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision

From: "Junio C Hamano" "Philip Oakley" writes: I think the use of "commit" in an angle-bracket-pair in the label for the section, i.e. "--fixup=", has been considered to be clear enough to tell that you can use usual extended SHA-1 syntax to specify

Re: [PATCH v1 2/3] doc: rebase: fixup! can take an object name

From: "Junio C Hamano" "Philip Oakley" writes: the 'standalone' is that it must be a single (standalone) word on the subject line immediately after the "fixup! "(s). communicationg that one cannot have any extra textual notes after that word was the

Re: Draft of Git Rev News edition 18

Philip Oakley wrote: > From: "Eric Wong" > >Philip Oakley wrote: > >>From: "Christian Couder" > >>>You can also reply to this email. > >> > >>I see you mention in passing (weel in the small headings near

Re: A note from the maintainer

Philip Oakley wrote: > From: "Eric Wong" > > > >Yes, I was somewhat careful to check for proper mboxes from gmane; > >I just missed entire ranges :x > > > > There were a number of messages that were listed by gmane as being in the > various Git for Windows

Re: [PATCH v1 1/3] doc: commit: --fixup/--squash can take a commit revision

"Philip Oakley" writes: >> I think the >> use of "commit" in an angle-bracket-pair in the label for the >> section, i.e. "--fixup=", has been considered to be clear >> enough to tell that you can use usual extended SHA-1 syntax to >> specify the commit you want to talk

Re: [PATCH v1 2/3] doc: rebase: fixup! can take an object name

From: "Junio C Hamano" Philip Oakley writes: Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition to message, 2010-11-04) the commit subject can refer directly to the destination object hash as a single word.)... That's not an

Re: [PATCH v1 2/3] doc: rebase: fixup! can take an object name

"Philip Oakley" writes: > the 'standalone' is that it must be a single (standalone) word on the > subject line immediately after the "fixup! "(s). > > communicationg that one cannot have any extra textual notes after that > word was the issue that 'standalone' tried to

Re: Draft of Git Rev News edition 18

Philip Oakley wrote: > From: "Christian Couder" > >You can also reply to this email. > > I see you mention in passing (weel in the small headings near the bottom) > that gmane web interface has gone away. It may be worth noting a few of the >

[PATCH] t1410: remove superfluous 'git reflog' from the 'walk past root' test

The test added in 71abeb753fa8 (reflog: continue walking the reflog past root commits, 2016-06-03) contains an unnecessary 'git reflog' execution, which was part of my debug/tracing instrumentation that I somehow didn't manage to remove before submitting. Signed-off-by: SZEDER Gábor

Re: [PATCH v1 1/2] t0027: Correct raciness in NNO test

Torsten Bögershausen writes: > Looking at t0027, it turns out that the changes in the test matrix done in 1/2 > are reverted in 2/2. > This is not a good thing. > Either (a) they should be marked as test_expect_failure in 1/2 and > corrected in 2/2, > or (b) 1/2 and 2/2 are

Re: [PATCH v5 2/3] diff: add --diff-line-prefix option for passing in a prefix

Jacob Keller writes: > On Fri, Aug 12, 2016 at 2:58 PM, Junio C Hamano wrote: >> On Fri, Aug 12, 2016 at 2:43 PM, Jacob Keller wrote: >>> Ok so the big problem here is that unlike with diff which has support >>> for

Re: [PATCH] squash! diff: add --diff-line-prefix option for passing in a prefix

Johannes Schindelin writes: > - test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g') > + test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g' -e 'y/>/_/') The existing sed scriptlet says "we cannot have slash and do not want to have space in filename, so we squash runs of

Re: [PATCH v1 2/3] doc: rebase: fixup! can take an object name

Philip Oakley writes: > Since 68d5d03 (rebase: teach --autosquash to match on sha1 in addition > to message, 2010-11-04) the commit subject can refer directly to the > destination object hash as a single word.)... That's not an object hash but an object name (see

Minor bug: git config ignores empty sections

Looks like there's a problem with setting a config with an empty section, making it create a new section. The result is: $ git --version git version 2.9.2 $ git init Initialized empty Git repository in /home/eli/t/.git/ $ t() { git config x.y x; git config --unset x.y; }

[PATCH v2] help: make option --help open man pages only for Git commands

If option --help is passed to a Git command, we try to open the man page of that command. However, we do it even for commands we don't know. Make sure the command is known to Git before try to open the man page. If we don't know the command, give the usual advice. Signed-off-by: Ralf Thielow

Re: [PATCH v5 2/3] diff: add --diff-line-prefix option for passing in a prefix

On Sun, Aug 14, 2016 at 2:21 PM, Junio C Hamano wrote: > Jacob Keller writes: > >> On Fri, Aug 12, 2016 at 2:58 PM, Junio C Hamano wrote: >>> On Fri, Aug 12, 2016 at 2:43 PM, Jacob Keller >>> wrote: Ok