Re: Strange bug with "git log" - pdftotext?
I discovered it was an issue with the version of Git for Windows I was using. Upgraded to the latest version and it works now. -- Best regards, Jeremy Morton (Jez) On 30/07/2018 16:37, Jeff King wrote: On Mon, Jul 30, 2018 at 01:49:46PM +0100, Jeremy Morton wrote: I'm trying to search my git log history for a particular term - "unobtrusive" - so I run this command: git log -S unobtrusive --oneline When I do this, this is displayed and I'm in an interactive less terminal or something: pdftotext version 4.00 [...] That's definitely weird. My guess is that the repository has some .gitattributes set up to diff pdf files in a particular way, and you have some matching config that tries to call pdftotext. What does: git config --list | grep ^diff say? I'd expect to see an external or textconv option there running pdftotext. Another option is that your pager is somehow set up to call pdftotext, but that seems much more nonsensical to use the tool there (but try "git var GIT_PAGER" and "git config pager.log" to check). -Peff
Strange bug with "git log" - pdftotext?
I'm trying to search my git log history for a particular term - "unobtrusive" - so I run this command: git log -S unobtrusive --oneline When I do this, this is displayed and I'm in an interactive less terminal or something: pdftotext version 4.00 Copyright 1996-2017 Glyph & Cog, LLC Usage: pdftotext [options] [] -f : first page to convert -l : last page to convert -layout : maintain original physical layout -simple : simple one-column page layout -table : similar to -layout, but optimized for tables -lineprinter : use strict fixed-pitch/height layout -raw : keep strings in content stream order -fixed : assume fixed-pitch (or tabular) text -linespacing : fixed line spacing for LinePrinter mode -clip: separate clipped text -nodiag : discard diagonal text -enc : output text encoding name -eol : output end-of-line convention (unix, dos, or mac) -nopgbrk : don't insert page breaks between pages -bom : insert a Unicode BOM at the start of the text file -opw : owner password (for encrypted files) -upw : user password (for encrypted files) -q : don't print any messages or errors -cfg : configuration file to use in place of .xpdfrc -v : print copyright and version info : When I hit the down arrow, it scrolls down, repeating this output infinitely until I hit 'q'. What is going on here?? -- Best regards, Jeremy Morton (Jez)
editing for your photos
How are you doing today? We have not heard from you yet. Are you still interested in our photo retouching services? We mainly do: e-commerce products photo retouching jewelry photos retouching model beauty/skin retouching wedding photo editing also photo cutting out, clipping path You may choose to send us a photo for testing which you can check our quality. Regards, Jeremy
Re: Subscribing Apple people to git-secur...@googlegroups.com
> On Jul 10, 2018, at 5:27 AM, Ævar Arnfjörð Bjarmason wrote: > > On Tue, Jul 3, 2018 at 3:36 PM, Jeff King wrote: >> On Mon, Jul 02, 2018 at 01:15:19PM -0700, Jeremy Huddleston Sequoia wrote: >> >>>> I hope that maybe they're also interested in reducing the overall >>>> diff between upstream Git and what ships with XCode. Last time I >>>> looked (which was admittedly a while ago), a lot of the changes >>>> seemed like things that could probably be considered upstream. >>> >>> I'm very very interested in having reduced differences between what we >>> ship in Xcode and what is upstream. I've been maintaining a repo with >>> our patches that I rebase as we move forward, in the hope that these >>> changes might be useful to others and a derivative of them might >>> eventually be accepted upstream. See >>> https://github.com/jeremyhu/git/commits/master for the current set of >>> changes that are in our shipping git (currently on top of 2.17.1). >> >> Thanks for sharing. Skimming over it, I see: >> >> - several of the changes look related to run-time relocation. There was >> a series that shipped in v2.18.0 related to this, so that may reduce >> your diff once you rebase. >> >> - The xcode_gitattributes() bits aren't likely to go upstream as-is. >> But possibly these could ship as a default $sysconfdir/gitattributes? >> >> - the rest look like assorted little fixes that probably could go >> upstream > > Jeremy, could you elaborate on what > https://github.com/jeremyhu/git/commit/61b42bc5d2 was about? I.e. > where was this discussed & tests for this refused? > > Seems sensible to me to have this in some form, but the test as-is > seems to be a general regression test, not Apple-specific, so it would > need to be changed somewhat, or does it only happen with some other > custom patch of yours? It was a bug in upstream git and not a bug specific to an Apple change. We haven't traditionally had many custom changes on our end. The few we have, we didn't feel they were appropriate or were often rejected when we tried (eg: using CommonCrypto and Security.framework, this one, etc.). For this particular case, I discussed the bug with the committer (Carlo) and reviewer (Junio) of the commit (18e051a3981f38db08521bb61ccf7e4571335353) via email back in October 2011. My proposed fix and test were never accepted. As such, we continued to ship my patch in Xcode's git and MacPorts' git until the underlying bug was actually fixed by someone else in 2014 (ddc2a6281595fd24ea01497c496f88c40a59562f + 655ee9ea3e6c0af57d320e84723ec3bf656cdbf7). I kept the test in our test suite to ensure we didn't regress. Here's the final post from that thread after the fix in 2014: --- Begin Message --- FWIW, it seems that this bug was addressed by ddc2a6281595fd24ea01497c496f88c40a59562f Thanks Martin, now we're no longer carrying around an extra patch for our build of git ;) --Jeremy > On Oct 17, 2011, at 14:55, Jeremy Huddleston wrote: > > ping. Did you get my response below with extra details? I just got a > duplicate bug report, so it apparently effects people... > > Please let me know if I can be of further assistance. > > On Oct 11, 2011, at 2:17 PM, Jeremy Huddleston wrote: > >> Thanks for your response Junio. The text of the original bug report is >> below. >> >> I created a git bisect test script which bisected the problem and found out >> that the difference was that the trailing / was removed by your code change. >> git treats paths with a trailing / differently. I don't know *why* it >> treats them differently, but it does. >> >> There's nothing "special" about JustDoItGit.tar.bz2 except that it contains >> a .git dir and has a file layout that works with the bisect script I wrote. >> You can test this yourself by: >> >> mkdir -p ~/tmp/PR-10238070 >> cd ~/tmp/PR-10238070 >> tar xjf JustDoItGit.tar.bz2 >> cd ~/git-checkout >> /path/to/test_10238070.sh >> >> Here's the original report: >> >> I've tracked the cause of ' ##snipped title##' down >> to a regression in git. >> >> Unzip the attached JustDoItGit.zip project and replace the path in the >> following commands to the unzipped location on your system: >> >> #delete git in /usr/bin/git >> sudo rm -r /usr/bin/git >> #link it to /usr/local/bin/git since that's where ditto will place the new >> bits >> sudo ln -s /usr/local/bin/git /usr/bin/git >> >> # first, install git 1.7.3.2 to verify that the bug does not reproduce >> sud
Re: Subscribing Apple people to git-secur...@googlegroups.com
+Akila Hi, Replies inline. > On Jul 2, 2018, at 12:50, Jeff King wrote: > > On Mon, Jul 02, 2018 at 09:29:41PM +0200, Christian Couder wrote: > >> When people complained a month ago about the MacOS package on >> https://git-scm.com/ not being up-to-date after the Git security >> release, I got in touch with Apple people GitLab has been working with >> to see if they could help on this. > > Unfortunately I don't think this will quite solve the issue we had, just > because people get their copy of Git in various ways. So Homebrew > updated pretty promptly, but people going to git-scm.com to find a > binary package were left without help. Likewise, this will help people > getting Git as part of XCode, but not people gettin the package from > git-scm.com. > > All that said, I'm happy to get as many binary packagers into the loop > as early as possible. It can only help, even if it doesn't solve all > problems. :) > >> Please add these addresses to the git-security mailing list: >>jerem...@apple.com >>akils...@apple.com >>dt-...@group.apple.com > > Done. > >> Please add these GitHub accounts to the cabal repo: >>jeremyhu > > Done. > >>productsecurityOSSapple > > I couldn't find that account. Is it maybe a team name within the apple > org or something? This is the account name I got from Akila. Akila, can you please work with Jeff to get this sorted? In the mean time, I have access. > I am also personally very happy with the Apple developers' willingness >> to get involved and help. > > Yes, welcome aboard! > > I hope that maybe they're also interested in reducing the overall diff > between upstream Git and what ships with XCode. Last time I looked > (which was admittedly a while ago), a lot of the changes seemed like > things that could probably be considered upstream. I'm very very interested in having reduced differences between what we ship in Xcode and what is upstream. I've been maintaining a repo with our patches that I rebase as we move forward, in the hope that these changes might be useful to others and a derivative of them might eventually be accepted upstream. See https://github.com/jeremyhu/git/commits/master for the current set of changes that are in our shipping git (currently on top of 2.17.1). Thanks, Jeremy > > -Peff
Re: [PATCH v2] packfile: Correct zlib buffer handling
Hi, On Wed, Jun 13, 2018 at 1:38 PM, Junio C Hamano wrote: > Eric Sunshine writes: > >>> + buffer[size] = 0; /* assure that the buffer is still terminated */ >> >> I think we normally use '\0' for NUL on this project rather than simply 0. >> >> The comment is also effectively pure noise since it merely repeats >> what the code already states clearly (especially when the code says >> "buffer[size] = '\0';"), so dropping the comment altogether would be >> reasonable. > > Actually, I'd prefer to have comment there, but not about "what this > line does" (which is useless, as you pointed out) but about "why do > we do this seemingly redundant clearing". > > Here is what I tentatively came up with. > > -- >8 -- > From: Jeremy Linton > Date: Wed, 13 Jun 2018 09:22:07 -0500 > Subject: [PATCH] packfile: correct zlib buffer handling > > The buffer being passed to zlib includes a NUL terminator that git > needs to keep in place. unpack_compressed_entry() attempts to detect > the case that the source buffer hasn't been fully consumed by > checking to see if the destination buffer has been over consumed. > > This causes a problem, that more recent zlib patches have been > poisoning the unconsumed portions of the buffer which overwrites > the NUL byte, while correctly returning length and status. > > Let's place the NUL at the end of the buffer after inflate returns > to assure that it doesn't result in problems for git even if its > been overwritten by zlib. > > Signed-off-by: Jeremy Linton > Signed-off-by: Junio C Hamano > --- > packfile.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/packfile.c b/packfile.c > index 4a5fe7ab18..d555699217 100644 > --- a/packfile.c > +++ b/packfile.c > @@ -1422,6 +1422,9 @@ static void *unpack_compressed_entry(struct packed_git > *p, > return NULL; > } > > + /* versions of zlib can clobber unconsumed portion of outbuf */ > + buffer[size] = '\0'; > + > return buffer; > } > > -- > 2.18.0-rc1-1-g6f333ff2fb This is all fine with me, the original comment was an attempt to indicate that the original null may not have been there anymore too.. Shall I resubmit it as above, or can it be picked up like this?
[PATCH v2] packfile: Correct zlib buffer handling
The buffer being passed to zlib includes a null terminator that git needs to keep in place. unpack_compressed_entry() attempts to detect the case that the source buffer hasn't been fully consumed by checking to see if the destination buffer has been over consumed. This causes a problem, that more recent zlib patches have been poisoning the unconsumed portions of the buffer which overwrites the null, while correctly returning length and status. Let's replace the null at the end of the buffer to assure that if its been overwritten by zlib it doesn't result in problems for git. Signed-off-by: Jeremy Linton --- packfile.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/packfile.c b/packfile.c index 7c1a2519f..8db5d90ca 100644 --- a/packfile.c +++ b/packfile.c @@ -1433,6 +1433,8 @@ static void *unpack_compressed_entry(struct packed_git *p, return NULL; } + buffer[size] = 0; /* assure that the buffer is still terminated */ + return buffer; } -- 2.13.6
Re: [PATCH] packfile: Correct zlib buffer handling
Hi,
Sorry about the delay here (bit of a mix-up and didn't reply to the list).
(see inline )
On Sun, May 27, 2018 at 9:41 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Duy Nguyen writes:
>>
>>> On Sun, May 27, 2018 at 1:57 AM, Junio C Hamano wrote:
(trimming)
>
> Specifically, I was worried about this assertion:
>
> Lets rely on the fact that the source buffer will only be fully
> consumed when the when the destination buffer is inflated to the
> correct size.
>
> which I think is the exact bad thinking that caused troubles for us
> in the past; isn't the explanation in 456cdf6e ("Fix loose object
> uncompression check.", 2007-03-19) relevant here?
>
> - stream.avail_out = size + 1;
> + stream.avail_out = size;
> ...
> stream.next_in = in;
> st = git_inflate(, Z_FINISH);
> if (!stream.avail_out)
> - break; /* the payload is larger than it should be */
> + break; /* done, st indicates if source fully consumed
> */
> curpos += stream.next_in - in;
> } while (st == Z_OK || st == Z_BUF_ERROR);
> git_inflate_end();
> if ((st != Z_STREAM_END) || stream.total_out != size) {
> free(buffer);
> return NULL;
> }
>
> With minimum stream.avail_out without slack, when !avail_out, i.e.
> when we fully filled the output buffer, it could be that we had
> correct input that deflates to the correct size, in which case we
> are happy---st would say Z_STREAM_END, we would leave the loop
> because it is neither OK nor BUF_ERROR, and total_out would report
> the size we expected. Or the input zlib stream may have ended with
> bytes that express "this concludes the stream", and the input bytes
> before that was sufficient to construct the original payload fully,
> and we may have just fed the bytes before that "this concludes the
> stream" to git_inflate().
>
> In such a case, we haven't consumed all the avail_in. We may
> already have all the correct output, i.e. !avail_out, but because we
> haven't consumed the "this concludes the stream", st is not
> STREAM_END in such a case.
If I understand correctly your concerned the avail_in is longer than
what is required to fill the output buffer..
I'm fairly sure that won't result in a Z_STREAM_END, as you rightfully
point out, but the loop _will_ terminate due to the output buffer
being full and then since its not Z_STREAM_END the
unpack_compressed_entry fails, as it should.
>
> Our existing while() loop, with one-byte slack in avail_out, would
> have let us continue and the next iteration of the loop would have
> consumed the input without producing any more output (i.e. avail_out
> would have been left to 1 in both of these final two rounds) and we
> would have exited the loop. After calling inflate_end(), we would
> have noticed STREAM_END and correct size and we would have been
> happy.
Your assuming that zlib will terminate with an error, but a fully
decompressed buffer, because it hasn't consumed the entire input
buffer. I don't think that is how it works (its not how the
documentation is written, nor the bits of code i've looked at seem to
work, which granted i'm not a zlib maintainer).
>
> The updated code would handle this latter case rather badly, no? We
> leave the loop early, notice st is not STREAM_END, and be very
> unhappy, because this patch did not give us to consume the very end
> of the input stream and left the loop early.
Your correct if the above case is a valid zlib behavior then there
would be a problem. But, I don't think the termination is dicated by
insufficient output space until there is an attempt to utilize that
space.
>
>>> This yields two problems, first a single byte overrun won't be detected
>>> properly because the Z_STREAM_END will then be set, but the null
>>> terminator will have been overwritten.
>
> Because we compare total_out and size at the end, we would detect it
> as an error in this function, no? Then zlib overwriting NUL would
> not be a problem, as we would free the buffer and return NULL, no?
>
>>> The other problem is that
>>> more recent zlib patches have been poisoning the unconsumed portions
>>> of the buffers which also overwrites the null, while correctly
>>> returning length and status.
>
> Isn't that a bug in zlib, though? Or do they do that deliberately?
>
> I think a workaround with lower impact would be to manually restore
> NUL at the end of the buffer.
I agree, just resetting the NULL its likely safer, and I will repost a
patch soon which if nothing else makes git more robust to errant zlib
behavior.
[PATCH] packfile: Correct zlib buffer handling
The buffer being passed to zlib includes a null terminator that
git needs to keep in place. unpack_compressed_entry() attempts to
detect the case that the source buffer hasn't been fully consumed
by checking to see if the destination buffer has been over consumed.
This yields two problems, first a single byte overrun won't be detected
properly because the Z_STREAM_END will then be set, but the null
terminator will have been overwritten. The other problem is that
more recent zlib patches have been poisoning the unconsumed portions
of the buffers which also overwrites the null, while correctly
returning length and status.
Lets rely on the fact that the source buffer will only be fully
consumed when the when the destination buffer is inflated to the
correct size. We can do this by passing zlib the correct buffer size
and properly checking the return status. The latter check actually
already exists if the buffer size is correct.
Signed-off-by: Jeremy Linton <lintonrjer...@gmail.com>
---
packfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/packfile.c b/packfile.c
index 7c1a2519f..245eb3204 100644
--- a/packfile.c
+++ b/packfile.c
@@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
return NULL;
memset(, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size + 1;
+ stream.avail_out = size;
git_inflate_init();
do {
@@ -1424,7 +1424,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
stream.next_in = in;
st = git_inflate(, Z_FINISH);
if (!stream.avail_out)
- break; /* the payload is larger than it should be */
+ break; /* done, st indicates if source fully consumed */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end();
--
2.13.6
[PATCH] packfile: Correct zlib buffer handling
The buffer being passed to zlib includes a null terminator that
git needs to keep in place. unpack_compressed_entry() attempts to
detect the case that the source buffer hasn't been fully consumed
by checking to see if the destination buffer has been over consumed.
This yields two problems, first a single byte overrun won't be detected
properly because the Z_STREAM_END will then be set, but the null
terminator will have been overwritten. The other problem is that
more recent zlib patches have been poisoning the unconsumed portions
of the buffers which also overwrites the null, while correctly
returning length and status.
Lets rely on the fact that the source buffer will only be fully
consumed when the when the destination buffer is inflated to the
correct size. We can do this by passing zlib the correct buffer size
and properly checking the return status. The latter check actually
already exists if the buffer size is correct.
Signed-off-by: Jeremy Linton <lintonrjer...@gmail.com>
---
packfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/packfile.c b/packfile.c
index 7c1a2519f..245eb3204 100644
--- a/packfile.c
+++ b/packfile.c
@@ -1416,7 +1416,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
return NULL;
memset(, 0, sizeof(stream));
stream.next_out = buffer;
- stream.avail_out = size + 1;
+ stream.avail_out = size;
git_inflate_init();
do {
@@ -1424,7 +1424,7 @@ static void *unpack_compressed_entry(struct packed_git *p,
stream.next_in = in;
st = git_inflate(, Z_FINISH);
if (!stream.avail_out)
- break; /* the payload is larger than it should be */
+ break; /* done, st indicates if source fully consumed */
curpos += stream.next_in - in;
} while (st == Z_OK || st == Z_BUF_ERROR);
git_inflate_end();
--
2.13.6
Re: Null pointer dereference in git-submodule
Reply-To:
Hmm... That's weird. I can reproduce it on 3 independant systems with
versions 2.16.2 up, although it does not work with version 2.11.0.
Anyway, I figured out how to reproduce this bug. It is caused when a
submodule is added and then the directory it resides in is moved or
deleted without commiting. For example:
git init
git submodule add https://github.com/git/git git
mv git git.BAK
git submodule status #this command segfaults
cheers
Jeremy
In-Reply-To: <a7ad9dbf-1b0f-efc6-3a17-51cf25381...@web.de>
On Sat, Mar 24, 2018 at 09:42:57PM +0100, René Scharfe wrote:
> Am 24.03.2018 um 18:42 schrieb Jeremy Feusi:
> > Hi,
> > While bootstrapping a gnu repository I noticed that git segfaulted when
> > called as "git submodule status". After compiling git with address
> > sanitizer and minimizing the directory I finally narrowed it down to the
> > files which I have attached as a tar archive. Here is a detailed backtrace:
> >
> > AddressSanitizer:DEADLYSIGNAL
> > =
> > ==63400==ERROR: AddressSanitizer: SEGV on unknown address 0x
> > (pc 0x00c27a93 bp 0x7ffdcb4eec10 sp 0x7ffdcb4eeb80 T0)
> > ==63400==The signal is caused by a READ memory access.
> > ==63400==Hint: address points to the zero page.
> > #0 0xc27a92 in refs_read_raw_ref /home/jfe/git/refs.c:1451:20
> > #1 0xc174a6 in refs_resolve_ref_unsafe /home/jfe/git/refs.c:1493:7
> > #2 0xc1826a in refs_read_ref_full /home/jfe/git/refs.c:224:6
> > #3 0xc26d53 in refs_head_ref /home/jfe/git/refs.c:1314:7
> > #4 0x8071e6 in status_submodule
> > /home/jfe/git/builtin/submodule--helper.c:658:7
> > #5 0x806a89 in status_submodule_cb
> > /home/jfe/git/builtin/submodule--helper.c:699:2
> > #6 0x80523e in for_each_listed_submodule
> > /home/jfe/git/builtin/submodule--helper.c:438:3
> > #7 0x7f7e9a in module_status
> > /home/jfe/git/builtin/submodule--helper.c:732:2
> > #8 0x7efd69 in cmd_submodule__helper
> > /home/jfe/git/builtin/submodule--helper.c:1859:11
> > #9 0x51e024 in run_builtin /home/jfe/git/git.c:346:11
> > #10 0x5192c2 in handle_builtin /home/jfe/git/git.c:554:8
> > #11 0x51d0f0 in run_argv /home/jfe/git/git.c:606:4
> > #12 0x518600 in cmd_main /home/jfe/git/git.c:683:19
> > #13 0x8501d6 in main /home/jfe/git/common-main.c:43:9
> > #14 0x7f49fdaf2f29 in __libc_start_main
> > (/lib/x86_64-linux-gnu/libc.so.6+0x20f29)
> > #15 0x41f4b9 in _start
> > (/home/jfe/git/inst/libexec/git-core/git+0x41f4b9)
> >
> > AddressSanitizer can not provide additional info.
> > SUMMARY: AddressSanitizer: SEGV /home/jfe/git/refs.c:1451:20 in
> > refs_read_raw_ref
> > ==63400==ABORTING
> >
> > As mentioned above, this bug is triggered by issuing the command
> > "git submodule status" while in the attached directory.
> >
> > This bug was confirmed on Debian with version 2.16.1 and
> > 2.17.0.rc1.35.g90bbd502d as well as on Arch Linux with version 2.16.2
> > where further output is given by git:
> >
> > /usr/lib/git-core/git-submodule: line 979: 8119 Segmentation fault
> > (core dumped) git ${wt_prefix:+-C "$wt_prefix"} ${prefix:+--super-prefix
> > "$prefix"} submodule--helper status ${GIT_QUIET:+--quiet}
> > ${cached:+--cached} ${recursive:+--recursive} "$@"
> >
>
> You may have minimized too much. With the patch below I get:
>
> fatal: no ref store in submodule 'gnulib'
>
> I guess you'll get a different one in your original repo.
>
> The patch seems like a good idea in any case, though.
>
> -- >8 --
> Subject: [PATCH] submodule: check for NULL return of get_submodule_ref_store()
>
> refs_head_ref() requires a valid ref_store pointer to be given as its
> first argument. get_submodule_ref_store() can return NULL. Exit and
> report the failure to find a ref store in that case instead of
> segfaulting.
>
> Reported-by: Jeremy Feusi <jer...@feusi.co>
> Signed-off-by: Rene Scharfe <l@web.de>
> ---
> builtin/submodule--helper.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/builtin/submodule--helper.c b/builtin/submodule--helper.c
> index ee020d4749..0f74e81005 100644
> --- a/builtin/submodule--helper.c
> +++ b/builtin/submodule--helper.c
> @@ -654,9 +654,11 @@ static void status_submodule(const char *path, const
> struct object_id *ce_oid,
>displaypath);
> } else if (!(flags & OP
Null pointer dereference in git-submodule
Hi,
While bootstrapping a gnu repository I noticed that git segfaulted when
called as "git submodule status". After compiling git with address
sanitizer and minimizing the directory I finally narrowed it down to the
files which I have attached as a tar archive. Here is a detailed backtrace:
AddressSanitizer:DEADLYSIGNAL
=
==63400==ERROR: AddressSanitizer: SEGV on unknown address 0x (pc
0x00c27a93 bp 0x7ffdcb4eec10 sp 0x7ffdcb4eeb80 T0)
==63400==The signal is caused by a READ memory access.
==63400==Hint: address points to the zero page.
#0 0xc27a92 in refs_read_raw_ref /home/jfe/git/refs.c:1451:20
#1 0xc174a6 in refs_resolve_ref_unsafe /home/jfe/git/refs.c:1493:7
#2 0xc1826a in refs_read_ref_full /home/jfe/git/refs.c:224:6
#3 0xc26d53 in refs_head_ref /home/jfe/git/refs.c:1314:7
#4 0x8071e6 in status_submodule
/home/jfe/git/builtin/submodule--helper.c:658:7
#5 0x806a89 in status_submodule_cb
/home/jfe/git/builtin/submodule--helper.c:699:2
#6 0x80523e in for_each_listed_submodule
/home/jfe/git/builtin/submodule--helper.c:438:3
#7 0x7f7e9a in module_status /home/jfe/git/builtin/submodule--helper.c:732:2
#8 0x7efd69 in cmd_submodule__helper
/home/jfe/git/builtin/submodule--helper.c:1859:11
#9 0x51e024 in run_builtin /home/jfe/git/git.c:346:11
#10 0x5192c2 in handle_builtin /home/jfe/git/git.c:554:8
#11 0x51d0f0 in run_argv /home/jfe/git/git.c:606:4
#12 0x518600 in cmd_main /home/jfe/git/git.c:683:19
#13 0x8501d6 in main /home/jfe/git/common-main.c:43:9
#14 0x7f49fdaf2f29 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x20f29)
#15 0x41f4b9 in _start (/home/jfe/git/inst/libexec/git-core/git+0x41f4b9)
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /home/jfe/git/refs.c:1451:20 in
refs_read_raw_ref
==63400==ABORTING
As mentioned above, this bug is triggered by issuing the command
"git submodule status" while in the attached directory.
This bug was confirmed on Debian with version 2.16.1 and
2.17.0.rc1.35.g90bbd502d as well as on Arch Linux with version 2.16.2
where further output is given by git:
/usr/lib/git-core/git-submodule: line 979: 8119 Segmentation fault (core
dumped) git ${wt_prefix:+-C "$wt_prefix"} ${prefix:+--super-prefix "$prefix"}
submodule--helper status ${GIT_QUIET:+--quiet} ${cached:+--cached}
${recursive:+--recursive} "$@"
cheers
Jeremy
min-man.tar.gz
Description: application/gzip
feature request: git-config: Add conditional include for gitbranch
Use Case == Jeremy is a developer for Debian and Ubuntu. The same repository is used for both Debian and Ubuntu packaging but with different branches. For commits to the debian/master branch, Jeremy wants to use his @debian.org email address. For commits to the ubuntu/master branch, Jeremy wants to use his @ubuntu.com email. Proposal === The includeIf feature of git-config could be extended to offer a gitbranch conditional include in addition to the gitdir conditional include it already offers. Thanks, Jeremy Bicha
Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Did this ever get anywhere? If not why not? It would be very useful to me to be able to clone recursively by default, especially considering you can't use 'alias' to override the existing 'clone' command. -- Best regards, Jeremy Morton (Jez) On 06/06/2014 06:26, Heiko Voigt wrote: On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote: Jens Lehmann<jens.lehm...@web.de> writes: We had two settings in mind,... So what if clone would just do an "git submodule init" for now when "submodule.autoinit" is set but "submodule.autoupdate" isn't [?] ... and a single "submodule.auto" setting would be what users really want? I do not offhand think of a sensible scenario where you want to init a submodule once but do not want to update it when the superproject changes. Even if the user uses the mode to detach the submodule HEAD, i.e. the branches in submodules do not matter and the whole tree is described by the superproject's commit and gitlinks recorded in it, the user would want the new objects necessary for the updated superproject, which means a submodule that is init'ed (whether it is via "git submodule init" or the submodule.autoinit variable) must be updated. So I am not sure why a user wants to disable autoupdate in the first place. For the same reason, setting submodule.*.update to none would not make much sense, either. Perhaps I am missing something. Unless the user is very conservative and suspects that these recursive behaviour we are going to bolt on to various commands could be buggy and untrustworthy, in which case the user might want to manually run "git submodule update", or even run "git fetch" after going there while bypassing the whole "git submodule". But I do not think that is healthy in the longer run. I think autoupdate is mainly there for the transition phase. Since submodule can e.g. contain a lot of files a checkout would take much longer. Similar to when Jens implemented the recursive diff, many people were annoyed by the new files showing up and some with the impact on performance (thats why we have the --ignore-submodules option). In case of very big submodules and people already ignore their diff it might even be necessary that the update is only done manually. E.g. for a big media repository. Cheers Heiko -- 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 http://vger.kernel.org/majordomo-info.html
Re: git 2.10.1 test regression in t3700-add.sh
> On Oct 10, 2016, at 10:41, Junio C Hamano <gits...@pobox.com> wrote:
>
> Jeremy Huddleston Sequoia <jerem...@freedesktop.org> writes:
>
>> Actually, looks like that as just a rabbit hole. The real issue
>> looks to be because an earlier test drops down xfoo3 as a symlink,
>> which causes this test to fail due to the collision. I'll get out
>> a patch in a bit.
>
> [administrivia: please don't top-post, it is extremely hard to
> follow what is going on]
>
> There indeed is a test that creates xfoo3 as a symbolic link and
> leaves it in the filesystem pointing at xfoo2 much earlier in the
> sequence. It seems that later one of the "add ignore-errors" tests
> (there are two back-to-back) runs "git reset --hard" to make it (and
> other symbolic links that are similarly named) go away, namely this
> part of the code:
>
>test_expect_success POSIXPERM,SANITY 'git add --ignore-errors' '
>git reset --hard &&
>date >foo1 &&
>date >foo2 &&
>chmod 0 foo2 &&
>test_must_fail git add --verbose --ignore-errors . &&
>git ls-files foo1 | grep foo1
>'
>
>rm -f foo2
>
>test_expect_success POSIXPERM,SANITY 'git add (add.ignore-errors)' '
>git config add.ignore-errors 1 &&
>git reset --hard &&
>date >foo1 &&
>date >foo2 &&
>chmod 0 foo2 &&
>test_must_fail git add --verbose . &&
>git ls-files foo1 | grep foo1
>'
>rm -f foo2
>
> "git reset --hard" in the first one, because these symbolic links
> are not in the index at that point in the sequence, would leave them
> untracked and in the working tree. Then "add" is told to be
> non-atomic with "--ignore-errors", adding them to the index while
> reporting a failure. When the test after that runs "git reset --hard"
> again, because these symlinks are in the index (and not in HEAD),
> they are removed from the working tree.
>
> And that is why normal people won't see xfoo3 in later tests, like
> the one you had trouble with.
>
> Are you running without SANITY by any chance (I am not saying that
> you are doing a wrong thing--just trying to make sure I am guessing
> along the correct route)?
Ah, yep. That's the ticket:
ok 23 # skip git add should fail atomically upon an unreadable file (missing
SANITY of POSIXPERM,SANITY)
ok 24 # skip git add --ignore-errors (missing SANITY of POSIXPERM,SANITY)
ok 25 # skip git add (add.ignore-errors) (missing SANITY of POSIXPERM,SANITY)
ok 26 # skip git add (add.ignore-errors = false) (missing SANITY of
POSIXPERM,SANITY)
ok 27 # skip --no-ignore-errors overrides config (missing SANITY of
POSIXPERM,SANITY)
I dug into it a bit, and since I'm running the tests during a staging phase
which runs as root, !SANITY gets set. Should be solvable by essentially
breaking test out into post-build instead of pre-install. Thanks for the
pointer there.
> If that is the issue, then I think the right correction would be to
> make sure that the files that an individual test expects to be
> missing from the file system is indeed missing by explicitly
> removing it, perhaps like this.
>
> I also notice that the problematic test uses "chmod 755"; don't we
> need POSIXPERM prerequisite on this test, too, I wonder?
>
> Thanks.
>
> -- >8 --
> t3700: fix broken test under !SANITY
>
> An "add --chmod=+x" test recently added by 610d55af0f ("add: modify
> already added files when --chmod is given", 2016-09-14) used "xfoo3"
> as a test file. The paths xfoo[1-3] were used by earlier tests for
> symbolic links but they were expected to have been removed by the
> test script reached this new test.
>
> The removal with "git reset --hard" however happened in tests that
> are protected by POSIXPERM,SANITY prerequisites. Platforms and test
> environments that lacked these would have seen xfoo3 as a leftover
> symbolic link, pointing somewhere else, and chmod test would have
> given a wrong result.
>
>
>
> t/t3700-add.sh | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/t/t3700-add.sh b/t/t3700-add.sh
> index 924a266126..53c0cb6dea 100755
> --- a/t/t3700-add.sh
> +++ b/t/t3700-add.sh
> @@ -350,6 +350,7 @@ test_expect_success POSIXPERM,SYMLINKS 'git add
> --chmod=+x with symlinks' '
> '
>
> test_expect_success 'git add --chmod=[+-]x changes index with already added
> file' '
> + rm -f foo3 xfoo3 &&
> echo foo >foo
Re: [PATCH] t3700-add.sh: Avoid filename collission between tests which could lead to test failure
> On Oct 10, 2016, at 09:44, Junio C Hamano <gits...@pobox.com> wrote: > > Jeremy Huddleston Sequoia <jerem...@apple.com> writes: > >> Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c >> Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com> >> CC: Thomas Gummerer <t.gumme...@gmail.com> >> CC: Junio C Hamano <gits...@pobox.com> > > This is also under-explained. Was the test broken for everybody and > you are the first to report, or was your environment somehow different > that the existing problem was revealed there first? There is nothing obviously different about my environment. I'd expect this test to fail for everyone that runs the entire test because xfoo3 is not cleaned up after this earlier test: test_expect_success \ 'git update-index --add: Test that executable bit is not used...' \ 'git config core.filemode 0 && test_ln_s_add xfoo2 xfoo3 && # runs git update-index --add test_mode_in_index 12 xfoo3' If anyone ran the test by itself or otherwise skipped the 'git update-index --add: Test that executable bit is not used...' test, they would not encounter the issue. However, the normal case is to run all of the tests, so I would expect everyone to be tripping over this issue. If they're not, then that itself might be indicative of another bug because clearly that previous test just added xfoo3 as a symlink. --Jeremy smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER
> On Oct 10, 2016, at 09:42, Junio C Hamano <gits...@pobox.com> wrote:
>
> Jeremy Huddleston Sequoia <jerem...@apple.com> writes:
>
>> Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae
>
> Please be considerate to future readers of "git log" to help them
> avoid mistakes earlier commits made that caused you troubles.
>
> This line by itself without any explanation of what was broken is
> quite useless as a commit message. What can the readers do? They'd
> go back and say "git show 480871e09" and then what? The test added
> or modified by the commit has been working quite well for others
> since it was made, so it is very likely the reader wouldn't be able
> to tell if anything is wrong in it.
>
> You would help if you said what is different in _your_ environment
> from others who have happily been running and passing this test for
> others to understand and learn from your fix. What is it?
>
> The "Adjust ... distro changes" in the title offers some hint but it
> could be more explicit. Please write something along this line
> instead.
>
>Subject: t4014: git --version can have SP in it
>
>480871e09e ("format-patch: show base info before email
>signature", 2016-09-07) added a helper function to recreate the
>signature at the end of the e-mail, i.e. "-- " line followed by
>the version string of Git, using output from "git --version" and
>stripping everything before the last SP.
>
>Because the default Git version string looks like "git version
>2.10.0-1-g480871e09e", this was mostly OK, but people can change
>this version string to arbitrary thing while compiling, which
>can break the assumption if they had SP in it. Notably, Apple
>ships modified Git with " (Apple Git-xx)" appended to its
> version number.
>
>Instead, come up with the version string by stripping the "git
>version " from the beginning.
Ok, I'll add that explanation to the commit message, thanks.
>
>> Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
>
> Good.
>
>> CC: Josh Triplett <j...@joshtriplett.org>
>> CC: Junio C Hamano <gits...@pobox.com>
>
> Please don't do this in your log message. These belong to your
> e-mail headers, not here.
Sorry, we do that consistently on other projects during the review process, so
git send-email picks them up and adds them automatically for each patch being
sent out. It's quite useful, actually.
>
>> ---
>> t/t4014-format-patch.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
>> index 8d90a6e..33f6940 100755
>> --- a/t/t4014-format-patch.sh
>> +++ b/t/t4014-format-patch.sh
>> @@ -754,7 +754,7 @@ test_expect_success 'format-patch
>> --ignore-if-in-upstream HEAD' '
>> git format-patch --ignore-if-in-upstream HEAD
>> '
>>
>> -git_version="$(git --version | sed "s/.* //")"
>> +git_version="$(git --version | sed "s/git version //")"
>
> Anchor the fixed prefix to the beginning, so that we can protect
> ourselves from another distro that would add "git version" in the
> middle of their arbitrary versioning scheme ;-). I.e.
>
>sed "s/^git version //"
Ok.
>
>>
>> signature() {
>> printf "%s\n%s\n\n" "-- " "${1:-$git_version}"
smime.p7s
Description: S/MIME cryptographic signature
Re: [PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER
> On Oct 10, 2016, at 06:10, Jeff King <p...@peff.net> wrote: > > On Sun, Oct 09, 2016 at 07:53:23PM -0700, Jeremy Huddleston Sequoia wrote: > >> Subject: Re: [PATCH] t4014-format-patch: Adjust git_version regex to better >> handle distro changes to DEF_VER >> >> Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae >> Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com> > > I see there was a discussion elsewhere on the list about exactly what > you are putting into DEF_VAR that causes the problem. Perhaps the commit > message here would be a good place to mention that, why the current > regex breaks it, and why your new version fixes not only it, but other > possible values of DEF_VAR. Thanks, I've added this blurb: For example, git distributed with Apple's Xcode reports a version like: git version 2.9.3 (Apple Git-75) Apple started doing this to help customers distinguish between different versions of their packaged git which have the same base version (eg: with different patches applied). smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER
> On Oct 9, 2016, at 20:04, Josh Triplett <j...@joshtriplett.org> wrote:
>
> On October 9, 2016 7:53:23 PM PDT, Jeremy Huddleston Sequoia
> <jerem...@apple.com> wrote:
>> Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae
>> Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
>> CC: Josh Triplett <j...@joshtriplett.org>
>> CC: Junio C Hamano <gits...@pobox.com>
>
> Looks reasonable to me. Didn't realize git versions could have spaces.
> Reviewed-by: Josh Triplett <j...@joshtriplett.org>
Thanks, Josh.
If anyone feels strongly that they shouldn't, I'd be happy to change our
DEF_VER patch to play nicer.
cf
https://github.com/jeremyhu/git/commit/f99905d0752d923e5ec61e14c675a300c6d04284
>
>> t/t4014-format-patch.sh | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
>> index 8d90a6e..33f6940 100755
>> --- a/t/t4014-format-patch.sh
>> +++ b/t/t4014-format-patch.sh
>> @@ -754,7 +754,7 @@ test_expect_success 'format-patch
>> --ignore-if-in-upstream HEAD' '
>> git format-patch --ignore-if-in-upstream HEAD
>> '
>>
>> -git_version="$(git --version | sed "s/.* //")"
>> +git_version="$(git --version | sed "s/git version //")"
>>
>> signature() {
>> printf "%s\n%s\n\n" "-- " "${1:-$git_version}"
>
>
smime.p7s
Description: S/MIME cryptographic signature
[PATCH] t3700-add.sh: Avoid filename collission between tests which could lead to test failure
Regressed-in: 610d55af0f082f6b866dc858e144c03d8ed4424c Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com> CC: Thomas Gummerer <t.gumme...@gmail.com> CC: Junio C Hamano <gits...@pobox.com> --- t/t3700-add.sh | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/t/t3700-add.sh b/t/t3700-add.sh index 924a266..3ccb19b 100755 --- a/t/t3700-add.sh +++ b/t/t3700-add.sh @@ -354,11 +354,11 @@ test_expect_success 'git add --chmod=[+-]x changes index with already added file git add foo3 && git add --chmod=+x foo3 && test_mode_in_index 100755 foo3 && - echo foo >xfoo3 && - chmod 755 xfoo3 && - git add xfoo3 && - git add --chmod=-x xfoo3 && - test_mode_in_index 100644 xfoo3 + echo foo >xfoo4 && + chmod 755 xfoo4 && + git add xfoo4 && + git add --chmod=-x xfoo4 && + test_mode_in_index 100644 xfoo4 ' test_expect_success POSIXPERM 'git add --chmod=[+-]x does not change the working tree' ' -- 2.10.1
Re: git 2.10.1 test regression in t3700-add.sh
> On Oct 9, 2016, at 20:22, Jeremy Huddleston Sequoia > <jerem...@freedesktop.org> wrote: > > The issue is that the whitespace before the filename in $(git ls-files -s > "$2") is a tab, and test_mode_in_index only looks for a space. Actually, looks like that as just a rabbit hole. The real issue looks to be because an earlier test drops down xfoo3 as a symlink, which causes this test to fail due to the collision. I'll get out a patch in a bit. > >> < > >> On Oct 9, 2016, at 19:51, Jeremy Huddleston Sequoia >> <jerem...@freedesktop.org> wrote: >> >> >>> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia >>> <jerem...@freedesktop.org> wrote: >>> >>> Hi Thomas, >>> >>> I wanted to let you know that this patch of yours, which landed in git >>> 2.10.1, introduced some test failures, seen on macOS. >>> >>> Let me know if you need any additional information to track these down. >>> >>> Thanks, >>> Jeremy >>> >>> not ok 40 - git add --chmod=[+-]x changes index with already added file >>> # >>> # echo foo >foo3 && >>> # git add foo3 && >>> # git add --chmod=+x foo3 && >>> # test_mode_in_index 100755 foo3 && >>> # echo foo >xfoo3 && >>> # chmod 755 xfoo3 && >>> # git add xfoo3 && >>> # git add --chmod=-x xfoo3 && >>> # test_mode_in_index 100644 xfoo3 >>> # >>> >>> commit 610d55af0f082f6b866dc858e144c03d8ed4424c >>> Author: Thomas Gummerer <t.gumme...@gmail.com> >>> Date: Wed Sep 14 22:07:47 2016 +0100 >>> >>> add: modify already added files when --chmod is given >>> >>> When the chmod option was added to git add, it was hooked up to the diff >>> machinery, meaning that it only works when the version in the index >>> differs from the version on disk. >>> >>> As the option was supposed to mirror the chmod option in update-index, >>> which always changes the mode in the index, regardless of the status of >>> the file, make sure the option behaves the same way in git add. >>> >>> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> >>> Signed-off-by: Junio C Hamano <gits...@pobox.com> >> >> >> This failure looks odd. I'll dig into it a bit more as it looks like >> something odd is going on here... >> >> expecting success: >> echo foo >foo3 && >> git add foo3 && >> git add --chmod=+x foo3 && >> test_mode_in_index 100755 foo3 && >> echo foo >xfoo3 && >> chmod 755 xfoo3 && >> git add xfoo3 && >> git add --chmod=-x xfoo3 && >> test_mode_in_index 100644 xfoo3 >> >> pass >> cannot chmod 'xfoo3'fail >> 12 c5c4ca97a3a080c32920941b665e94a997901491 0xfoo3 >> not ok 40 - git add --chmod=[+-]x changes index with already added file >> # >> #echo foo >foo3 && >> #git add foo3 && >> #git add --chmod=+x foo3 && >> #test_mode_in_index 100755 foo3 && >> #echo foo >xfoo3 && >> #chmod 755 xfoo3 && >> #git add xfoo3 && >> #git add --chmod=-x xfoo3 && >> #test_mode_in_index 100644 xfoo3 >> # >> > smime.p7s Description: S/MIME cryptographic signature
Re: git 2.10.1 test regression in t3700-add.sh
The issue is that the whitespace before the filename in $(git ls-files -s "$2") is a tab, and test_mode_in_index only looks for a space. >< > On Oct 9, 2016, at 19:51, Jeremy Huddleston Sequoia > <jerem...@freedesktop.org> wrote: > > >> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia >> <jerem...@freedesktop.org> wrote: >> >> Hi Thomas, >> >> I wanted to let you know that this patch of yours, which landed in git >> 2.10.1, introduced some test failures, seen on macOS. >> >> Let me know if you need any additional information to track these down. >> >> Thanks, >> Jeremy >> >> not ok 40 - git add --chmod=[+-]x changes index with already added file >> # >> #echo foo >foo3 && >> #git add foo3 && >> #git add --chmod=+x foo3 && >> #test_mode_in_index 100755 foo3 && >> #echo foo >xfoo3 && >> #chmod 755 xfoo3 && >> #git add xfoo3 && >> #git add --chmod=-x xfoo3 && >> #test_mode_in_index 100644 xfoo3 >> # >> >> commit 610d55af0f082f6b866dc858e144c03d8ed4424c >> Author: Thomas Gummerer <t.gumme...@gmail.com> >> Date: Wed Sep 14 22:07:47 2016 +0100 >> >> add: modify already added files when --chmod is given >> >> When the chmod option was added to git add, it was hooked up to the diff >> machinery, meaning that it only works when the version in the index >> differs from the version on disk. >> >> As the option was supposed to mirror the chmod option in update-index, >> which always changes the mode in the index, regardless of the status of >> the file, make sure the option behaves the same way in git add. >> >> Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> >> Signed-off-by: Junio C Hamano <gits...@pobox.com> > > > This failure looks odd. I'll dig into it a bit more as it looks like > something odd is going on here... > > expecting success: > echo foo >foo3 && > git add foo3 && > git add --chmod=+x foo3 && > test_mode_in_index 100755 foo3 && > echo foo >xfoo3 && > chmod 755 xfoo3 && > git add xfoo3 && > git add --chmod=-x xfoo3 && > test_mode_in_index 100644 xfoo3 > > pass > cannot chmod 'xfoo3'fail > 12 c5c4ca97a3a080c32920941b665e94a997901491 0 xfoo3 > not ok 40 - git add --chmod=[+-]x changes index with already added file > # > # echo foo >foo3 && > # git add foo3 && > # git add --chmod=+x foo3 && > # test_mode_in_index 100755 foo3 && > # echo foo >xfoo3 && > # chmod 755 xfoo3 && > # git add xfoo3 && > # git add --chmod=-x xfoo3 && > # test_mode_in_index 100644 xfoo3 > # > smime.p7s Description: S/MIME cryptographic signature
[PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER
Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae
Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com>
CC: Josh Triplett <j...@joshtriplett.org>
CC: Junio C Hamano <gits...@pobox.com>
---
t/t4014-format-patch.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
index 8d90a6e..33f6940 100755
--- a/t/t4014-format-patch.sh
+++ b/t/t4014-format-patch.sh
@@ -754,7 +754,7 @@ test_expect_success 'format-patch --ignore-if-in-upstream
HEAD' '
git format-patch --ignore-if-in-upstream HEAD
'
-git_version="$(git --version | sed "s/.* //")"
+git_version="$(git --version | sed "s/git version //")"
signature() {
printf "%s\n%s\n\n" "-- " "${1:-$git_version}"
--
2.10.1 (Apple Git-99)
Re: git 2.10.1 test regression in t4014-format-patch.sh
> On Oct 9, 2016, at 17:18, Josh Triplett <j...@joshtriplett.org> wrote:
>
> On October 9, 2016 5:15:22 PM PDT, Jeremy Huddleston Sequoia
> <jerem...@freedesktop.org> wrote:
>> Hey Josh,
>>
>> Hope you're doing well.
>>
>> I wanted to let you know that this patch of yours, which landed in git
>> 2.10.1, introduced some test failures, seen on macOS.
>>
>> Let me know if you need any additional information to track these down.
>>
>> Thanks,
>> Jeremy
>>
>>
>> not ok 65 - format-patch default signature
>> #
>> #git format-patch --stdout -1 | tail -n 3 >output &&
>> #signature >expect &&
>> #test_cmp expect output
>> #
>>
>> not ok 132 - format-patch --base
>> #
>> #git checkout side &&
>> #git format-patch --stdout --base=HEAD~3 -1 | tail -n 7 >actual
>> &&
>> #echo >expected &&
>> #echo "base-commit: $(git rev-parse HEAD~3)" >>expected &&
>> #echo "prerequisite-patch-id: $(git show --patch HEAD~2 | git
>> patch-id --stable | awk "{print \$1}")" >>expected &&
>> #echo "prerequisite-patch-id: $(git show --patch HEAD~1 | git
>> patch-id --stable | awk "{print \$1}")" >>expected &&
>> #signature >> expected &&
>> #test_cmp expected actual
>> #
>
> Can you run the test with the option to show the expected and actual strings?
> Did the testsuite run with the wrong git somehow?
Nope, it's the right version being tested. The failure seems due to your
git_version change not liking our formatting
$ git --version
git version 2.10.1 (Apple Git-99)
(the 'Apple Git-XX' being added because this was from a build that had Apple's
patch series, including
https://github.com/jeremyhu/git/commit/f99905d0752d923e5ec61e14c675a300c6d04284)
We modify DEF_VER, which confused your regex. Simple patch inc in a separate
email.
Thanks,
Jeremy
smime.p7s
Description: S/MIME cryptographic signature
Re: git 2.10.1 test regression in t3700-add.sh
> On Oct 9, 2016, at 17:15, Jeremy Huddleston Sequoia > <jerem...@freedesktop.org> wrote: > > Hi Thomas, > > I wanted to let you know that this patch of yours, which landed in git > 2.10.1, introduced some test failures, seen on macOS. > > Let me know if you need any additional information to track these down. > > Thanks, > Jeremy > > not ok 40 - git add --chmod=[+-]x changes index with already added file > # > # echo foo >foo3 && > # git add foo3 && > # git add --chmod=+x foo3 && > # test_mode_in_index 100755 foo3 && > # echo foo >xfoo3 && > # chmod 755 xfoo3 && > # git add xfoo3 && > # git add --chmod=-x xfoo3 && > # test_mode_in_index 100644 xfoo3 > # > > commit 610d55af0f082f6b866dc858e144c03d8ed4424c > Author: Thomas Gummerer <t.gumme...@gmail.com> > Date: Wed Sep 14 22:07:47 2016 +0100 > >add: modify already added files when --chmod is given > >When the chmod option was added to git add, it was hooked up to the diff >machinery, meaning that it only works when the version in the index >differs from the version on disk. > >As the option was supposed to mirror the chmod option in update-index, >which always changes the mode in the index, regardless of the status of >the file, make sure the option behaves the same way in git add. > >Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> >Signed-off-by: Junio C Hamano <gits...@pobox.com> This failure looks odd. I'll dig into it a bit more as it looks like something odd is going on here... expecting success: echo foo >foo3 && git add foo3 && git add --chmod=+x foo3 && test_mode_in_index 100755 foo3 && echo foo >xfoo3 && chmod 755 xfoo3 && git add xfoo3 && git add --chmod=-x xfoo3 && test_mode_in_index 100644 xfoo3 pass cannot chmod 'xfoo3'fail 12 c5c4ca97a3a080c32920941b665e94a997901491 0 xfoo3 not ok 40 - git add --chmod=[+-]x changes index with already added file # # echo foo >foo3 && # git add foo3 && # git add --chmod=+x foo3 && # test_mode_in_index 100755 foo3 && # echo foo >xfoo3 && # chmod 755 xfoo3 && # git add xfoo3 && # git add --chmod=-x xfoo3 && # test_mode_in_index 100644 xfoo3 # smime.p7s Description: S/MIME cryptographic signature
git 2.10.1 test regression in t3700-add.sh
Hi Thomas, I wanted to let you know that this patch of yours, which landed in git 2.10.1, introduced some test failures, seen on macOS. Let me know if you need any additional information to track these down. Thanks, Jeremy not ok 40 - git add --chmod=[+-]x changes index with already added file # # echo foo >foo3 && # git add foo3 && # git add --chmod=+x foo3 && # test_mode_in_index 100755 foo3 && # echo foo >xfoo3 && # chmod 755 xfoo3 && # git add xfoo3 && # git add --chmod=-x xfoo3 && # test_mode_in_index 100644 xfoo3 # commit 610d55af0f082f6b866dc858e144c03d8ed4424c Author: Thomas Gummerer <t.gumme...@gmail.com> Date: Wed Sep 14 22:07:47 2016 +0100 add: modify already added files when --chmod is given When the chmod option was added to git add, it was hooked up to the diff machinery, meaning that it only works when the version in the index differs from the version on disk. As the option was supposed to mirror the chmod option in update-index, which always changes the mode in the index, regardless of the status of the file, make sure the option behaves the same way in git add. Signed-off-by: Thomas Gummerer <t.gumme...@gmail.com> Signed-off-by: Junio C Hamano <gits...@pobox.com> smime.p7s Description: S/MIME cryptographic signature
git 2.10.1 test regression in t4014-format-patch.sh
Hey Josh,
Hope you're doing well.
I wanted to let you know that this patch of yours, which landed in git 2.10.1,
introduced some test failures, seen on macOS.
Let me know if you need any additional information to track these down.
Thanks,
Jeremy
not ok 65 - format-patch default signature
#
# git format-patch --stdout -1 | tail -n 3 >output &&
# signature >expect &&
# test_cmp expect output
#
not ok 132 - format-patch --base
#
# git checkout side &&
# git format-patch --stdout --base=HEAD~3 -1 | tail -n 7 >actual
&&
# echo >expected &&
# echo "base-commit: $(git rev-parse HEAD~3)" >>expected &&
# echo "prerequisite-patch-id: $(git show --patch HEAD~2 | git
patch-id --stable | awk "{print \$1}")" >>expected &&
# echo "prerequisite-patch-id: $(git show --patch HEAD~1 | git
patch-id --stable | awk "{print \$1}")" >>expected &&
# signature >> expected &&
# test_cmp expected actual
#
commit 480871e09ed2e5275b4ba16b278681e5a8c122ae
Author: Josh Triplett <j...@joshtriplett.org>
Date: Wed Sep 7 18:12:01 2016 -0700
format-patch: show base info before email signature
Any text below the "-- " for the email signature gets treated as part of
the signature, and many mail clients will trim it from the quoted text
for a reply. Move it above the signature, so people can reply to it
more easily.
Similarly, when producing the patch as a MIME attachment, the
original code placed the base info after the attached part, which
would be discarded. Move the base info to the end of the part,
still inside the part boundary.
Add tests for the exact format of the email signature, and add tests
to ensure that the base info appears before the email signature when
producing a plain-text output, and that it appears before the part
boundary when producing a MIME attachment.
Signed-off-by: Josh Triplett <j...@joshtriplett.org>
Signed-off-by: Junio C Hamano <gits...@pobox.com>
smime.p7s
Description: S/MIME cryptographic signature
Reference a submodule branch instead of a commit
At the moment, supermodules must reference a given commit in each of its submodules. If one is in control of a submodule and it changes on a regular basis, this can cause a lot of overhead with "submodule updated" commits in the supermodule. It would be useful of git allows the option of referencing a submodule's branch instead of a given submodule commit. How about adding this functionality? -- Best regards, Jeremy Morton (Jez)
Re: [RFC PATCH] clone: add clone.recursesubmodules config option
Did this ever get anywhere? Can we recursively update submodules with
"git pull" in the supermodule now?
--
Best regards,
Jeremy Morton (Jez)
On 04/06/2014 10:30, Chris Packham wrote:
Add a config option that will cause clone to recurse into submodules as
if the --recurse-submodules option had been specified on the command
line. This can be overridden with the --no-recurse-submodules option.
Signed-off-by: Chris Packham<judge.pack...@gmail.com>
---
On 04/06/14 09:05, Junio C Hamano wrote:
Mara Kim<mara@vanderbilt.edu> writes:
Apologies if this question has been asked already, but what is the
reasoning behind making git clone not recursive (--recursive) by
default?
The primary reason why submodules are separate repositories is not
to require people to have everything. Some people want recursive,
some others don't, and the world is not always "majority wins" (not
that I am saying that majority will want recursive).
Inertia, aka backward compatibility and not surprising existing
users, plays some role when deciding the default.
Also, going --recursive when the user did not want is a lot more
expensive mistake to fix than not being --recursive when the user
wanted to.
Having said all that, I do not mean to say that I am opposed to
introduce some mechanism to let the users express their preference
between recursive and non-recursive better, so that "git clone"
without an explicit --recursive (or --no-recursive) can work to
their taste. A configuration in $HOME/.gitconfig might be a place
to start, even though that has the downside of assuming that the
given user would want to use the same settings for all his projects,
which may not be the case in practice.
And here's a quick proof of concept. Not sure about the config variable name
and it could probably do with a negative test as well.
builtin/clone.c | 9 +
t/t7407-submodule-foreach.sh | 17 +
2 files changed, 26 insertions(+)
diff --git a/builtin/clone.c b/builtin/clone.c
index b12989d..92aea81 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -734,6 +734,14 @@ static void write_refspec_config(const char*
src_ref_prefix,
strbuf_release();
}
+static int git_clone_config(const char *key, const char *value, void *data)
+{
+ if (!strcmp(key, "clone.recursesubmodules"))
+ option_recursive = git_config_bool(key, value);
+
+ return 0;
+}
+
int cmd_clone(int argc, const char **argv, const char *prefix)
{
int is_bundle = 0, is_local;
@@ -759,6 +767,7 @@ int cmd_clone(int argc, const char **argv, const char
*prefix)
junk_pid = getpid();
packet_trace_identity("clone");
+ git_config(git_clone_config, NULL);
argc = parse_options(argc, argv, prefix, builtin_clone_options,
builtin_clone_usage, 0);
diff --git a/t/t7407-submodule-foreach.sh b/t/t7407-submodule-foreach.sh
index 7ca10b8..fc2c189 100755
--- a/t/t7407-submodule-foreach.sh
+++ b/t/t7407-submodule-foreach.sh
@@ -307,6 +307,23 @@ test_expect_success 'use "update --recursive nested1" to
checkout all submodules
)
'
+test_expect_success 'use "git clone" with clone.recursesubmodules to checkout
all submodules' '
+ git config --local clone.recursesubmodules true&&
+ git clone super clone7&&
+ (
+ cd clone7&&
+ git rev-parse --resolve-git-dir .git&&
+ git rev-parse --resolve-git-dir sub1/.git&&
+ git rev-parse --resolve-git-dir sub2/.git&&
+ git rev-parse --resolve-git-dir sub3/.git&&
+ git rev-parse --resolve-git-dir nested1/.git&&
+ git rev-parse --resolve-git-dir nested1/nested2/.git&&
+ git rev-parse --resolve-git-dir nested1/nested2/nested3/.git&&
+ git rev-parse --resolve-git-dir
nested1/nested2/nested3/submodule/.git
+ )&&
+ git config --local --unset clone.recursesubmodules
+'
+
test_expect_success 'command passed to foreach retains notion of stdin' '
(
cd super&&
Autoupdate / autoinit submodules?
Apologies if this has already been discussed, but did any of the proposed patches to allow .gitmodules to be configured for a submodule to be automatically recursive cloned and/or automatically updated on pull make it in yet? My use-case for submodules - which is shared libraries - almost always requires a recursive clone, so having to remember the --recursive param (or to use an alias) is annoying (and I usually forget), and it usually requires pulling the latest master on a "git pull", too. I think both of these things should be able to be automated through git module configuration. -- Best regards, Jeremy Morton (Jez)
Re: 2.9.2 test failures on macOS
> On Aug 3, 2016, at 07:35, Johannes Schindelin <johannes.schinde...@gmx.de>
> wrote:
>
> Hi Jeremy,
>
> On Wed, 3 Aug 2016, Jeremy Huddleston Sequoia wrote:
>
>> I have two test failures to report in git 2.9.2 on macOS:
>>
>>
>> t3210-pack-refs.sh has not changed between 2.8.4 and 2.9.2. This test
>> passed fine with 2.8.4, but it now fails with 2.9.2 at:
>>
>> not ok 26 - retry acquiring packed-refs.lock
>> #
>> #LOCK=.git/packed-refs.lock &&
>> #>"$LOCK" &&
>> #test_when_finished "wait; rm -f $LOCK" &&
>> #{
>> #( sleep 1 ; rm -f $LOCK ) &
>> #} &&
>> #git -c core.packedrefstimeout=3000 pack-refs --all --prune
>> #
>>
>> ===
>>
>> t3700-add.sh recently added the 'git add --chmod=-x stages an executable
>> file with -x' test. This test passes when run as a normal user but fails
>> when run as root:
>>
>> $ ./t3700-add.sh
>> ...
>> # passed all 40 test(s)
>> 1..40
>>
>> $ sudo ./t3700-add.sh
>> ...
>> not ok 39 - git add --chmod=-x stages an executable file with -x
>> #
>> #echo foo >xfoo1 &&
>> #chmod 755 xfoo1 &&
>> #git add --chmod=-x xfoo1 &&
>> #case "$(git ls-files --stage xfoo1)" in
>> #100644" "*xfoo1) echo pass;;
>> #*) echo fail; git ls-files --stage xfoo1; (exit 1);;
>> #esac
>> #
>> # failed 1 among 40 test(s)
>> 1..40
>
> I tried to write up all I know about debugging test failures here:
>
> https://github.com/git-for-windows/git/wiki/Running-Git's-regression-tests#running-individual-tests
>
> Could you give it a try and diagnose the breakage further? (The output you
> provided is unfortunately not enough to determine what went wrong.)
Another report indicates that the second was a known failure already. As for
the first one:
~/tmp/test $ git init
Initialized empty Git repository in /Users/jeremy/tmp/test/.git/
~/tmp/test (master) $ touch .git/packed-refs.lock
~/tmp/test (master) $ git -c core.packedrefstimeout=3000 pack-refs --all --prune
fatal: Unable to create '/Users/jeremy/tmp/test/.git/packed-refs.lock': File
exists.
Another git process seems to be running in this repository, e.g.
an editor opened by 'git commit'. Please make sure all processes
are terminated then try again. If it still fails, a git process
may have crashed in this repository earlier:
remove the file manually to continue.
--
I just tried this again with 2.8.4, and I see the same failure. I could've
sworn that 2.8.4 passed all tests when I tested it back in June.
smime.p7s
Description: S/MIME cryptographic signature
2.9.2 test failures on macOS
I have two test failures to report in git 2.9.2 on macOS:
t3210-pack-refs.sh has not changed between 2.8.4 and 2.9.2. This test passed
fine with 2.8.4, but it now fails with 2.9.2 at:
not ok 26 - retry acquiring packed-refs.lock
#
# LOCK=.git/packed-refs.lock &&
# >"$LOCK" &&
# test_when_finished "wait; rm -f $LOCK" &&
# {
# ( sleep 1 ; rm -f $LOCK ) &
# } &&
# git -c core.packedrefstimeout=3000 pack-refs --all --prune
#
===
t3700-add.sh recently added the 'git add --chmod=-x stages an executable file
with -x' test. This test passes when run as a normal user but fails when run
as root:
$ ./t3700-add.sh
...
# passed all 40 test(s)
1..40
$ sudo ./t3700-add.sh
...
not ok 39 - git add --chmod=-x stages an executable file with -x
#
# echo foo >xfoo1 &&
# chmod 755 xfoo1 &&
# git add --chmod=-x xfoo1 &&
# case "$(git ls-files --stage xfoo1)" in
# 100644" "*xfoo1) echo pass;;
# *) echo fail; git ls-files --stage xfoo1; (exit 1);;
# esac
#
# failed 1 among 40 test(s)
1..40
smime.p7s
Description: S/MIME cryptographic signature
Re: Allow git alias to override existing Git commands
On 11/11/2015 04:48, Sitaram Chamarty wrote: A lot of things in Unix do follow that "give you rope to hang yourself" philosophy. I used to (and to *some* extent still do) think like that, but some years of supporting normal users trying to do stuff has taught me it's not always that simple. I can easily see someone blogging some cool way to do something, and a less savvy user uses that in his gitconfig, and gets burned later (possibly much later, enough that he does not easily make the connection!) We're not talking about "normal users" here, that's what Google Chrome is for. We're talking about Git users using the commandline client. They ought to know what they're doing and if they don't, they're screwed anyway because there are quite a few gotchas with Git. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Allow git alias to override existing Git commands
On 11/11/2015 09:51, Sitaram Chamarty wrote: I can only repeat what I said before: it's not all black and white. Reducing the opportunity to make mistakes is useful for everyone, even expetrs. Especially stuff that you may have setup aeons ago and hits you only aeons later when something (supposedly unrelated) somewhere else changes and you didn't remember and you tear your hair out. Not when it reduces useful functionality for experts, it's not. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Allow git alias to override existing Git commands
It's recently come to my attention that the "git alias" config functionality ignores all aliases that would override existing Git commands. This seems like a bad idea to me. For example, I wanted to setup "git clone" to automatically act as "git clone --recursive". Sure I could do it in the shell, but it's more of a pain - any tutorial I set up about doing it would have to worry about what shell the user was using - and if you're going to make that argument, why have "git alias" at all? It can all be done from the shell. Obviously I could also use a different alias that wasn't an existing Git command for this behaviour, but that would rather defeat the point: I want "git clone" to have different functionality. If I remembered to use a different Git command, I might as well remember to type "git clone --recursive". Also, if a future Git command were introduced with the same name as my alias, my alias's functionality would suddenly be ignored, giving unexpected behaviour. The reasoning behind this that it's "to avoid confusion and troubles with script usage" seems to be at odds with the general Git mentality that the user is given lots of power, and if they screw it up it's basically just user error. For example, Git doesn't *have* to allow you to rebase. It's a potentially dangerous operation, so why is it allowed? It might "cause confusion and troubles". On the other hand, by disallowing the overriding of existing Git commands through aliases you are preventing a lot of useful functionality that those aliases might be used for. So I think you should either allow Git aliases to override existing Git commands by default, or at least provide a config option that allows the user to say that this should happen. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Allow git alias to override existing Git commands
On 10/11/2015 18:12, Stefan Beller wrote: On Tue, Nov 10, 2015 at 8:31 AM, Jeremy Morton<ad...@game-point.net> wrote: It's recently come to my attention that the "git alias" config functionality ignores all aliases that would override existing Git commands. This seems like a bad idea to me. This ensures that the plumbing commands always work as expected. As scripts *should* only use plumbing commands, the scripts should work with high probability despite all the crazy user configuration/aliases. I just disagree with this. If a user chooses to override their Git commands, it's their problem. Why should Git care about this? It should provide the user with the option to do this, and if the user ruins scripts because of their aliases, it is not Git's problem. What you are doing is taking away power from users to use git aliases to their full potential. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Running interpret-trailers automatically on each commit?
I see that interpret-trailers has been added by default in git 2.5.0. However the documentation isn't that great and I can't tell whether it gets run automatically when I do a git commit. My guess is that it doesn't - that you have to set up a hook to get it to run each commit. As far as I can tell, there is no way to configure global git hooks. Sure, you can set init.templatedir but that only applies for newly-init'ed or cloned repos. So if I have 50 repos on my hard drive I still have to go through every one of them and set up a hook for it. Basically, am I right in thinking that there is *still* no way for me to configure git (on a global, not per-repo basis) to automatically tack a trailer onto every commit message? For the record, I want that trailer to be the current branch name. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Running interpret-trailers automatically on each commit?
Yeah but it's kind of useless to me having it on each commit on a per-repo basis (and even then, only with hooks). -- Best regards, Jeremy Morton (Jez) On 28/08/2015 18:06, Junio C Hamano wrote: Jeremy Mortonad...@game-point.net writes: I see that interpret-trailers has been added by default in git 2.5.0. However the documentation isn't that great and I can't tell whether it gets run automatically when I do a git commit. My guess is that it doesn't - that you have to set up a hook to get it to run each commit. All correct, except that it happend in 2.2 timeframe. A new experimental feature is shipped, so that people can gain experience with it and come up with the best practice in their hooks, and then laster we may fold the best practice into somewhere deeper in the system. We are still in the early ship an experimental feature to let people play with it stage. Thanks. -- 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 http://vger.kernel.org/majordomo-info.html -- 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 http://vger.kernel.org/majordomo-info.html
utf-8 filename woes
Hi, I have a git version 1.7.1 running on Scientific Linux 6. When a filename with UTF-8 is present in a tree-ish the git archive command crashes: %% *** buffer overflow detected ***: git terminated === Backtrace: = /lib64/libc.so.6(__fortify_fail+0x37)[0x32c1502527] /lib64/libc.so.6[0x32c1500410] /lib64/libc.so.6[0x32c14ff869] /lib64/libc.so.6(_IO_default_xsputn+0xc9)[0x32c1474639] /lib64/libc.so.6(_IO_vfprintf+0x11d8)[0x32c14451a8] /lib64/libc.so.6(__vsprintf_chk+0x9d)[0x32c14ff90d] /lib64/libc.so.6(__sprintf_chk+0x7f)[0x32c14ff84f] git[0x4620bc] git[0x4616bc] git[0x4bd832] git[0x4bda79] git[0x4bda79] git[0x4613e1] git[0x4623ed] git[0x4612ed] git[0x40caf3] git[0x4041a1] git[0x404382] /lib64/libc.so.6(__libc_start_main+0xfd)[0x32c141ed5d] git[0x403ba9] === Memory map: 0040-0051 r-xp fd:00 4121 /usr/bin/git %% Installing the git-debuginfo package gave no additional information. The symptom does not show on a Fedora 21 system with git 2.1.0 (and I note that gitk properly shows those filenames on f21, and does not on sl6). Is this a known and fixed issue, or something my sl6 system needs installing? -- Thanks, Jeremy -- 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 http://vger.kernel.org/majordomo-info.html
Branch list by date
I built this terribly-written alias because I wanted to see a list of branches by date of commit. The output looks like this: $ git bbd 11 months ago pipette_editor 7 weeks ago ensure-ie-rendering-edge 6 weeks ago strings-yml 5 weeks ago message-when-validation-fails 4 weeks ago new-parsers 11 days ago tax 8 hours ago search 7 hours ago browse 16 minutes ago master 8 seconds ago org-read And the alias, in all its glory: [alias] bbd = !export head=$(git symbolic-ref HEAD); git for-each-ref --sort=committerdate --format 'color=$(if [[ %(refname) = $head ]]; then printf \\\e[32m\; fi); printf \\\e[01;30m%%15s\\e(B\\e[m %%s%%s\\n\ %(committerdate:relative) $color %(refname:short)' refs/heads/ --shell | sh I write this missive with dual purpose: firstly to share a potentially useful tool, and secondly to suggest that this feature (with a less mind-wrenchingly disgusting implementation) might be included in mainline git, as for example `git branch [-t] | [--by-time]`. Until the ocean swallows us all, j -- 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 http://vger.kernel.org/majordomo-info.html
Re: files deleted with no record?
Hi. Thanks for getting back to me. here is a screenshot from source tree to visualise the scenario: https://drive.google.com/file/d/0B-Wn7DfHsuhyTEVkRHAzeGVZelpMWjFxZW1kbVBKVlNab3pR/edit?usp=sharing I will attempt a script to reproduce this later today. Thanks On Fri, Jun 27, 2014 at 5:53 AM, Philip Oakley philipoak...@iee.org wrote: From: Phil Hord phil.h...@gmail.com On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott jer...@great-scotts.org wrote: I just encountered a situation where a merge was made, with no apparent changes in files (ie no log), but the result was that some files were deleted. person A adds some files person B adds some files from the same point You mean from the same point in history, right? Not files with the same filename or path? person B commits and pushes. person A commits -- now merge is required a few more commits on top of person B's commit I don't understand this step. Who adds a few more commits on top of B and why? person A merges - this removes the files that B added. There is no log of the files being deleted A similar issue, by reference, just came up on the [git-users] list. The reference was: 1. http://randyfay.com/content/avoiding-git-disasters-gory-story In that case the problem was a mixture of tools and misunderstandings. It may not be the same as your case, but could give insights into what's happening between different developers. Which Tools are You, person A and Person B using, with --version? This sounds like an evil merge (see man gitglossary, and google), but it's not clear to me how you arrived here. When I tried to reproduce your issue with this script, it did not remove any files unexpectedly: ---8--- #!/bin/sh set -e mkdir foo cd foo git init echo foo foo git add foo git commit -mfoo git checkout -b PersonA master echo bar bar git add bar git commit -mPersonA: bar git checkout -b PersonB master echo baz baz git add baz git commit -mPersonB: baz echo foo-conflict foo git add foo git commit -mPersonB: foo git checkout PersonA echo foo-different foo git add foo git commit -mPersonA: foo (conflicts with PersonB) git log --oneline --all --stat if ! git merge PersonB ; then git checkout PersonA foo git commit --no-edit fi git log --oneline --graph --stat ---8--- A sneaky issue with merges is that they do not have a clear way to show patch information -- the diff between the commit and its ancestor -- because they have multiple ancestors. You can show diffs for a merge relative to each of its parents, but it is not usually done for you automatically. This is why making changes in a merge which are not actually required for the merge is bad (evil). Clearly this is possible - was this a user error? Probably, but we'd need to see how the user got there. -- Philip -- 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 http://vger.kernel.org/majordomo-info.html
Re: files deleted with no record?
we're all using source tree. I'm really interested to try and reproduce this so I'll find some time today to do it. Thanks again On Fri, Jun 27, 2014 at 6:56 AM, Jeremy Scott jer...@great-scotts.org wrote: Hi. Thanks for getting back to me. here is a screenshot from source tree to visualise the scenario: https://drive.google.com/file/d/0B-Wn7DfHsuhyTEVkRHAzeGVZelpMWjFxZW1kbVBKVlNab3pR/edit?usp=sharing I will attempt a script to reproduce this later today. Thanks On Fri, Jun 27, 2014 at 5:53 AM, Philip Oakley philipoak...@iee.org wrote: From: Phil Hord phil.h...@gmail.com On Mon, Jun 23, 2014 at 9:15 PM, Jeremy Scott jer...@great-scotts.org wrote: I just encountered a situation where a merge was made, with no apparent changes in files (ie no log), but the result was that some files were deleted. person A adds some files person B adds some files from the same point You mean from the same point in history, right? Not files with the same filename or path? person B commits and pushes. person A commits -- now merge is required a few more commits on top of person B's commit I don't understand this step. Who adds a few more commits on top of B and why? person A merges - this removes the files that B added. There is no log of the files being deleted A similar issue, by reference, just came up on the [git-users] list. The reference was: 1. http://randyfay.com/content/avoiding-git-disasters-gory-story In that case the problem was a mixture of tools and misunderstandings. It may not be the same as your case, but could give insights into what's happening between different developers. Which Tools are You, person A and Person B using, with --version? This sounds like an evil merge (see man gitglossary, and google), but it's not clear to me how you arrived here. When I tried to reproduce your issue with this script, it did not remove any files unexpectedly: ---8--- #!/bin/sh set -e mkdir foo cd foo git init echo foo foo git add foo git commit -mfoo git checkout -b PersonA master echo bar bar git add bar git commit -mPersonA: bar git checkout -b PersonB master echo baz baz git add baz git commit -mPersonB: baz echo foo-conflict foo git add foo git commit -mPersonB: foo git checkout PersonA echo foo-different foo git add foo git commit -mPersonA: foo (conflicts with PersonB) git log --oneline --all --stat if ! git merge PersonB ; then git checkout PersonA foo git commit --no-edit fi git log --oneline --graph --stat ---8--- A sneaky issue with merges is that they do not have a clear way to show patch information -- the diff between the commit and its ancestor -- because they have multiple ancestors. You can show diffs for a merge relative to each of its parents, but it is not usually done for you automatically. This is why making changes in a merge which are not actually required for the merge is bad (evil). Clearly this is possible - was this a user error? Probably, but we'd need to see how the user got there. -- Philip -- 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 http://vger.kernel.org/majordomo-info.html
files deleted with no record?
I just encountered a situation where a merge was made, with no apparent changes in files (ie no log), but the result was that some files were deleted. person A adds some files person B adds some files from the same point person B commits and pushes. person A commits -- now merge is required a few more commits on top of person B's commit person A merges - this removes the files that B added. There is no log of the files being deleted Clearly this is possible - was this a user error? Thanks -- 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 http://vger.kernel.org/majordomo-info.html
Re: gitk's truncated tags
On 27/05/14 13:12, Ondrej Oprala wrote: Hi, is there any way to display full tag names in gitk, for tag names longer than 16 characters? The way 1.8.x did things? The offending commit is 4399fe3 and reverting it restores my preferred view, too (there was slight entanglement with 76d64ca which I ignored). -- Cheers, Jeremy -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 28/04/2014 17:37, Junio C Hamano wrote: Christian Couderchrisc...@tuxfamily.org writes: From: Junio C Hamanogits...@pobox.com Christian Couderchrisc...@tuxfamily.org writes: ... + trailer. After some alphanumeric characters, it can contain + some non alphanumeric characters like ':', '=' or '#' that will + be used instead of ':' to separate the token from the value in + the trailer, though the default ':' is more standard. I assume that this is for things like bug #538 and the configuration would say something like: [trailer bug] key = bug # For completeness (of this example), the bog-standard s-o-b would look like Signed-off-by: Christian Couderchrisc...@tuxfamily.org and the configuration for it that spell the redundant key would be: [trailer Signed-off-by] key = Signed-off-by: Yeah, but you can use the following instead: [trailer s-o-b] key = Signed-off-by: One thing I'm not quite understanding is where the Christian Couderchrisc...@tuxfamily.org bit comes from. So you've defined the trailer token and key, but interpret-trailers then needs to get the value it will give for the key from somewhere. Does it have to just be hardcoded in? We probably want some way to get various variables like current branch name, current git version, etc. So in the case of always adding a trailer for the branch that the commit was checked in to at the time (Developed-on, Made-on-branch, Author-branch, etc. [I think my favourite is Made-on-branch]), you'd want something like: [trailer m-o-b] key = Made-on-branch: value = $currentBranch ... resulting in the trailer (for example): Made-on-branch: pacman-minigame Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) ... or whatever. And also how about some logic to be able to say that if you're committing to the master branch, the trailer doesn't get inserted at all? -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 29/04/2014 12:47, Christian Couder wrote: Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) You may need to write a small script for that. Then you just need the trailer.m-o-b.command config value to point to your script. ... or whatever. And also how about some logic to be able to say that if you're committing to the master branch, the trailer doesn't get inserted at all? You can script that too. But it would be nicer if the logic were built-in, then you wouldn't have to share some script with your work colleagues. :-) -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v10 11/12] Documentation: add documentation for 'git interpret-trailers'
On 29/04/2014 12:47, Christian Couder wrote: Also, if there were no current branch name because you're committing in a detached head state, it would be nice if you could have some logic to determine that, and instead write the trailer as: Made-on-branch: (detached HEAD: AB12CD34) You may need to write a small script for that. Then you just need the trailer.m-o-b.command config value to point to your script. ... or whatever. And also how about some logic to be able to say that if you're committing to the master branch, the trailer doesn't get inserted at all? You can script that too. But it would be nicer if the logic were built-in, then you wouldn't have to share some script with your work colleagues. :-) -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. But why do you need that information? As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. I might include a bug# in the branch name so I don't have to keep typing it in every commit message, or I might just have a handy short description of what part of the application this branch is modifying (like my pacman-minigame example). -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 03:30, Sitaram Chamarty wrote: On 04/28/2014 01:03 AM, Johan Herland wrote: Yeah, sure. Author and Date (and Committer, for that matter) is just metadata, and the current branch name is simply just another kind of metadata. All of them are more-or-less free-form text fields, and off no they're not. In strictly controlled environments they form part of the audit record for the source code. Yes they can be faked (explicitly), but -- again in strictly controlled environments -- that can be limited to before it was first pushed. Why these specific headers as part of the audit record, though? Aren't you just arbitrarily defining them as part of the audit record? -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat.git/hooks/commit-msgEOF #!/bin/sh git interpret-trailers --trim-empty --trailer git-version: \$(git describe) \$1 \$1.new mv \$1.new \$1 EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer git-branch: \$(git name-rev --name-only HEAD) \$1 \$1.new It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv \$1.new \$1' command. Best, Christian. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:02, David Kastrup wrote: Jeremy Mortonad...@game-point.net writes: On 28/04/2014 09:32, Felipe Contreras wrote: some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Nope. Different people have different needs, there's no recommendation. If anything, the recommendation is to do a ff merge, because that's the default. That's what I'm saying. With an ff merge, you don't get the merge commit message telling you the branch name. And I don't _want_ that branch name to be recorded. The whole point of a distributed version control system is that it's nobody else's business how I organize my work before submitting it. Well it would be optional, so obviously you wouldn't be forced to share the branch name. It's not like we're trying to pry in to your private development. It's a way of choosing to share what you may consider to be useful contextual information about the commit. I don't want to have people tell me when submitting patches but can't you give this a better branch name? and then have to use git filter-branch or whatever else to get the branch name removed. As I said before, I usually consider my branch names useful information worth keeping around - I'm not sure why you don't. It is _totally_ useless information in a distributed development model. Why would or should anybody be concerned what private branches some submitter has developed his patches in? Why should anybody be concerned about what commit message some submitter has typed in for his commit? They could just read the source code to see what has changed, right? Because the commit message is a way for the submitter to try and make it easier for the people looking at the commit to understand what the commit is doing. In the same way, a meaningful branch name may also make it easier for people looking at the commit to understand what it is doing, or what part of the application it is affecting, or what group of commits it is a part of. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:09, Johan Herland wrote: On Mon, Apr 28, 2014 at 11:01 AM, Jeremy Mortonad...@game-point.net wrote: On 28/04/2014 07:45, Christian Couder wrote: Yes, it's possible. Yesterday, I sent the following patch: [RFC/PATCH 2/2] trailer: add examples to the documentation and it shows a commit-msg hook to do something like that: $ cat.git/hooks/commit-msgEOF #!/bin/sh git interpret-trailers --trim-empty --trailer git-version: \$(git describe) \$1 \$1.new mv \$1.new \$1 EOF $ chmod +x .git/hooks/commit-msg I think you just need to use the following if you want the branch instead of the git version: git interpret-trailers --trim-empty --trailer git-branch: \$(git name-rev --name-only HEAD) \$1 \$1.new It could even be simpler if there was an option (which has already been discussed) that made it possible to modify the file in place. This way one would not need the 'mv \$1.new \$1' command. This is certainly going in the right direction, but it's still implemented as a hook on a per-repo basis. Do you foresee a point in the future where these trailers could be added through simple one-liners in someone's global .gitconfig file? That's where I'd really like to get to. It's a hack, but it works surprisingly well in practice (assuming that you and your co-workers all agree that this is an acceptable approach): 1. Write the hook script and add it to your project (in a git-hooks subdir or something) 2. Add a post-checkout hook to install the first hook and the post-checkout hook itself into the user's .git/hooks/ dir. 3. Tell your co-workers to run the post-checkout hook script manually the first time. After that, the script should take care of updating itself and any hooks that you add to the project. ...Johan I don't understand why the co-workers need to run the post-checkout hook script manually the first time? -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:01, Felipe Contreras wrote: Jeremy Morton wrote: On 27/04/2014 20:33, Johan Herland wrote: The problem is not really less tidy commit trees - by which I gather you mean history graphs that are non-linear. IMHO, the history graph should reflect parallel/branched development when that is useful. Blindly rebasing everything into a single line is IMHO just as bad as doing all your work directly on master and blindly running git pull between each of your own commits (which results in a lot of useless merges). The merge commits themselves are not the problem. Merge commits are a tool, and when used properly (to introduce topics to the master branch like described above) they are a good tool. When abused (like blindly running git pull and accepting useless merge bubbles) they create more problems than they solve. Sounds like the default behaviour of git pull might not be ideal if it easily causes these problems. It's not idea. Virtually everyone agrees with that, even Linus Torvalds, and we have the patches to fix it, but it's not going to change. The Git project doesn't welcome change. Well, you sure don't seem to. Why are there so many no-can-do people on this list? :-) -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 28/04/2014 10:17, Felipe Contreras wrote: I don't seem to what? I'm the one arguing for change, and I sent the patches to fix this default behavior. Well maybe you should work on phrasing things better - you come across as quite negative. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 27/04/2014 09:51, Robin Rosenberg wrote: Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? Branch names are usually poorly named, so often you don't lose much. One way Speak for yourself - I give my branches useful names. :-) I definitely feel that I am often losing useful contextual information by throwing away the branch name. some people to is to always merge with --no-ff, that way you see the branch name in the merge commit. But surely, it's recommended with Git that you try to avoid doing --no-ff merges to avoid commit noise? Also, it is a lot more hassle (and no doubt, CPU cycles) to track down where a branch was merged to try and figure out which branch name a commit pertained to, not to mention the fact that the commit could've been moved since. Nothing short of tagging the commit with the branch name when the commit is made will definitely record the branch name at the time of committing. A very popular way of tracking context is to add some id, such as a bugzilla issue number, to the header or footer of the commit message. Often a branch contains many issues, but the branch itself isn't very interesting. Tools like gitblit, gitweb, gerrit etc can easily be configured to link to the issue using a regular expression. Yes, and I have done this kind of thing in the past. However you really don't want to put the bug# on every single commit pertaining to that bug; you have to go to the effort of looking the bug# up every time, you'll sometimes forget, and besides it takes up space that could be used for a commit message. As short commit messages are valued in Git, it's particularly bad to waste space this way. Much better would be to include the bug# as part of the branch name, and then if you record the branch name upon checkin you always get a reference to the bug#. Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Recording the current branch on each commit?
On 27/04/2014 20:33, Johan Herland wrote: On Sun, Apr 27, 2014 at 7:38 PM, Jeremy Mortonad...@game-point.net wrote: On 27/04/2014 10:09, Johan Herland wrote: As far as I can tell from that discussion, the general opposition to encoding the branch name as a structural part of the commit object is that, for some people's workflows, it would be unhelpful and/or misleading. Well fair enough then - why don't we make it a setting that is off by default, and can easily be switched on? That way the people for whom tagging the branch name would be useful have a very easy way to switch it on. Therefore, the most pragmatic and constructive thing to do at this point, is IMHO to work within the confines of the existing commit object structure. I actually believe using commit message trailers like Made-on-branch: frotz in addition to some helpful infrastructure (hooks, templates, git-interpret-trailers, etc.) should get you pretty much exactly what you want. And if this feature turns out to be extremely useful for a lot of users, we can certainly consider changing the commit object format in the future. OK, fair enough. So I guess what I'd like to see, then, is good built-in functionality in Git for these commit message trailers, so that they are very easy to turn on. I'd like to be able to tell co-developers to add a one-liner to their git config file rather than some post-commit script. I know that for the workflows I personally have used in the past, such tagging would be very useful. Quite often I have been looking through the Git log and wondered what feature a commit was part of, because I have feature branches. Just knowing that branch name would be really useful, but the branch has since been deleted... and in the case of a ff-merge (which I thought was recommended in Git if possible), the branch name is completely gone. True. The branch name is - for better or worse - simply not considered very important by Git, and a Git commit is simply not considered (by Git at least) to be part of or otherwise belong to any branch. Please understand that I know this full well. :-) I'm saying that the 'ephemeral' pointers' names are, in themselves, useful - if, like me, you give them meaningful names. What I'm proposing is pretty much an automatic tagging (somehow...) of each commit with the current branch name (if one is available); information that carries roughly the same weight as the commit message. It could be crap, but equally it could be very useful, in some workflows. I think most of us can agree on that. seems to only have come up a few times on the mailing list. This is But it has come up more than once, which would seem to indicate that I'm not the only one with this request. ;-) IINM, Mercurial does this differently, so that may be a better fit for If I'm Not Mistaken - I had to look that one up. the workflows where keeping track of branch names is very important. Nah, I had a look at Mercurial and I think I prefer Git - this branch name thing is just my one bugbear. I definitely prefer Git's concept of a staging area rather than just committing all changes. To do that in Mercurial you have to use mq and all the different (IMHO unintuative) commands that entails, and if you accidentally mq commit then you screw everything up. :-) Mercurial also discourages history rewriting (ie. cleaning up of messy commits), which Git doesn't. I prefer Git's approach here too. Yeah, sure. Author and Date (and Committer, for that matter) is just metadata, and the current branch name is simply just another kind of metadata. All of them are more-or-less free-form text fields, and off the top of my head, I can't really say that if we were to design Git from scratch today, they wouldn't all become optional trailers (or headers, or what-have-you). However, we're not designing Git from scratch, and we have to work with what is already there... Fair point. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. In that partcular case, ISTM that the context (pacman-minigame) would actually be better preserved elsewhere. E.g. the commits touch files in a particular minigames/pacman subdir, or you prefix the context in the commit message (pacman-minigame: Added basic options dialog). Also, such a topic branch is often tied to a specific Again, this is a pain because you have to remember to manually tag every commit message with pacman-minigame, and it takes up precious space in the (already short) commit message. Yes, which is why I advise you to look at commit message templates, hooks, and interpret-trailers to see if you can find a way to automate this for you and your co-workers. What I'd like
Re: Recording the current branch on each commit?
On 27/04/2014 22:40, James Denholm wrote: Also, you don't always have something you can link a commit to in an issue tracker. You may just be implementing a feature that has been agreed upon, independently of any such tracker. In that case, there's no bug# to link to. In which case, refer to whatever system you use. If you aren't using a ticketing system, have the line Relates-to: Water cooler conversation with Bob on July 28th or whatever the patches relate to. (Arguably, though, the better solution is to use a ticketing system, or anything that allows discussion to be easily referenced.) Well, as I said elsewhere in this discussion, Git should provide that functionality built-in, IMHO. It would be good to be able to set a one-liner in my .gitconfig to tag each commit with a branch checked into trailer. -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Recording the current branch on each commit?
Currently, git records a checksum, author, commit date/time, and commit message with every commit (as get be seen from 'git log'). I think it would be useful if, along with the Author and Date, git recorded the name of the current branch on each commit. The branch name can provide useful contextual information. For instance, let's say I'm developing a suite of games. If the commit message says Added basic options dialog, it might be useful to see that the branch name is pacman-minigame indicating that the commit pertains to the options dialog in the Pacman minigame. Basically, I'm saying that well-named branches can and do carry useful contextual information that oughtn't to be thrown away. Currently, when you delete that branch, you lose the branch name altogether. So what do you think? Would it be good to have a patch to add this feature? -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Bad git log behavior with multiple glob path arguments
On Wed, Mar 5, 2014 at 3:01 AM, Duy Nguyen pclo...@gmail.com wrote: On Wed, Mar 5, 2014 at 12:56 PM, Jeremy Nickurak jer...@nickurak.ca wrote: git log seems to understand globs in the last path argument, and the last path argument only. I didn't see anything in the git log man page expressly saying this was to be expected, but it does seem like it ought to work for all the arguments or none of them. What version did you use? We have a fix in the same area, e4ddb05 (tree_entry_interesting: match against all pathspecs - 2014-01-25), and it's in v1.8.5.5 and v1.9.0 So close! :) 1.8.5.3 Note that glob matching doesn't seem to occur unless '--' is included. do you mean git log does not run at all and complains about disambiguation, or it runs but nothing is filtered? It complains about disambiguation: $ mkdir -p ~/tmp; cd ~/tmp; git init; echo hello hello.txt; git add hello.txt; git commit -m hello; echo Without --:; git log --oneline '*.txt'; echo With --:; git log --oneline -- '*.txt'; Reinitialized existing Git repository in /home/nickuj/tmp/.git/ On branch master nothing to commit, working directory clean Without --: fatal: ambiguous argument '*.txt': unknown revision or path not in the working tree. Use '--' to separate paths from revisions, like this: 'git command [revision...] -- [file...]' With --: 78ff378 hello -- 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 http://vger.kernel.org/majordomo-info.html
Bad git log behavior with multiple glob path arguments
git log seems to understand globs in the last path argument, and the last path argument only. I didn't see anything in the git log man page expressly saying this was to be expected, but it does seem like it ought to work for all the arguments or none of them. Here's a little shell script I ended up using to convince myself I wasn't going crazy. I'd expect the same output for all of the git log test, since they all specify (either with globs or not) all the files added to the repository. Alternatively, if globs aren't expected to work, I'd at least expect all the glob tests to return nothing. Note that glob matching doesn't seem to occur unless '--' is included. I'm not exactly clear on why that is. #!/bin/sh TESTREPO=$(pwd)/bad-glob-test-repo rm -rf $TESTREPO echo Running tests in $TESTREPO mkdir $TESTREPO cd $TESTREPO mkdir subdira mkdir subdirb mkdir subdirc git init echo a subdira/file.txt echo b subdirb/file.txt echo c subdirc/file.txt git add subdira/file.txt git commit -m 'a' git add subdirb/file.txt git commit -m 'b' git add subdirc/file.txt git commit -m 'c' echo Glob Test 1: git log --oneline -- 'subdira/*.txt' 'subdirb/*.txt' 'subdirc/*.txt' git log --oneline -- 'subdira/*.txt' 'subdirb/*.txt' 'subdirc/*.txt' echo Glob Test 2: git log --oneline -- 'subdira/*.txt' 'subdirc/*.txt' 'subdirb/*.txt' git log --oneline -- 'subdira/*.txt' 'subdirc/*.txt' 'subdirb/*.txt' echo Glob Test 3: git log --oneline -- 'subdirb/*.txt' 'subdira/*.txt' 'subdirc/*.txt' git log --oneline -- 'subdirb/*.txt' 'subdira/*.txt' 'subdirc/*.txt' echo Glob Test 4: git log --oneline -- 'subdirb/*.txt' 'subdirc/*.txt' 'subdira/*.txt' git log --oneline -- 'subdirb/*.txt' 'subdirc/*.txt' 'subdira/*.txt' echo Glob Test 5: git log --oneline -- 'subdirc/*.txt' 'subdira/*.txt' 'subdirb/*.txt' git log --oneline -- 'subdirc/*.txt' 'subdira/*.txt' 'subdirb/*.txt' echo Glob Test 6: git log --oneline -- 'subdirc/*.txt' 'subdirb/*.txt' 'subdira/*.txt' git log --oneline -- 'subdirc/*.txt' 'subdirb/*.txt' 'subdira/*.txt' echo Explicit Test 1: git log --oneline -- 'subdira/file.txt' 'subdirb/file.txt' 'subdirc/file.txt' git log --oneline -- 'subdira/file.txt' 'subdirb/file.txt' 'subdirc/file.txt' echo Explicit Test 2: git log --oneline -- 'subdira/file.txt' 'subdirc/file.txt' 'subdirb/file.txt' git log --oneline -- 'subdira/file.txt' 'subdirc/file.txt' 'subdirb/file.txt' echo Explicit Test 3: git log --oneline -- 'subdirb/file.txt' 'subdira/file.txt' 'subdirc/file.txt' git log --oneline -- 'subdirb/file.txt' 'subdira/file.txt' 'subdirc/file.txt' echo Explicit Test 4: git log --oneline -- 'subdirb/file.txt' 'subdirc/file.txt' 'subdira/file.txt' git log --oneline -- 'subdirb/file.txt' 'subdirc/file.txt' 'subdira/file.txt' echo Explicit Test 5: git log --oneline -- 'subdirc/file.txt' 'subdira/file.txt' 'subdirb/file.txt' git log --oneline -- 'subdirc/file.txt' 'subdira/file.txt' 'subdirb/file.txt' echo Explicit Test 6: git log --oneline -- 'subdirc/file.txt' 'subdirb/file.txt' 'subdira/file.txt' git log --oneline -- 'subdirc/file.txt' 'subdirb/file.txt' 'subdira/file.txt' -- Jeremy Nickurak -= Email/XMPP: -= jer...@nickurak.ca =- -- 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 http://vger.kernel.org/majordomo-info.html
Setting per-repository configuration for git
Hello everybody I am looking into the git configuration mechanism and there seem to be a hole in use cases I'm trying to figure out... git configurations can be saved at various places * /etc/gitconfig : system-wide configuration * ~/.gitconfig : user-wide configuration * .git/config : repository-wide configuration however I can't find a way to have the repository's configuration saved and transmited with the repository in a way similar to how .gitignore is transmitted... Saving some configuration information within a repository is not unknown in git. .gitignore does it, and submodule configuration does it to. I think it's important to have a way to have configuration options be saved in a repository (and overridable with .git/config which is local-repository only) because a lot of configurationoptions are meant to express repository policies (triangular workflows, merge vs rebase, mail vs push) and it would make sense to have them transmitted that way. Knowing how mature git is I can only assume that this has already been discussed and that there is a good reason not to do it. Is it because of hooks ? would it break something I don't see in git ? git (the project) shouldn't enforce policies on repositories, but I think it makes sense for repositories to have a way to set default policies on their clone... Thx Cordialement Jérémy Rosen +33 (0)1 42 68 28 04 fight key loggers : write some perl using vim Open Wide Ingenierie 23, rue Daviel 75012 Paris - France www.openwide.fr -- 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 http://vger.kernel.org/majordomo-info.html
Re: RFE: support change-id generation natively
for those of us that are not using gerrit... what is a change-id (semantically, I got from your mail that it is some sort of unit id set at commit time) and in what way is it different from the commit-id ? Cordialement Jérémy Rosen +33 (0)1 42 68 28 04 fight key loggers : write some perl using vim Open Wide Ingenierie 23, rue Daviel 75012 Paris - France www.openwide.fr - Mail original - Hello Git Community, TL;DR: It would be a really nice enhancement if the commit command natively supported _optionally_ injecting a Change-Id: I000... footer in the last paragraph of the commit message template and then substituting the I000... value, on commit, with a generated value _without_ having to rely on a per-repository, native hook or a global hook that affects every local repository. Full Request: Gerrit has established the change-id footer as a prominent and wide-spread collaboration identifier. For those contributing new patches to a Gerrit server, it is required to either use EGit/JGit (Eclipse) to generate commits [1] OR to use a commit hook script with native git to insert a change-id footer during the commit process [2]. This per-repository hook script requirement is an obstacle. These communities would be better served and it would lower the contribution barrier for many open source projects if native git supported change-id generation injection. I acknowledge that not everyone uses nor wants to use Gerrit and the change-id footer. That is fine, but it would be a _tremendous_ usability improvement for those contributing to open source projects (myself included) if something like a --change-id flag was implemented and maybe even a config setting to always generate a change-id on commit (EGit currently supports this as gerrit.createchangeid=true). Sadly, my C skills are lacking as I live mostly in the world of managed code, but I'd be very happy to cheer for a change-id champion; I suspect there are some out there who might rally to this cause. Thanks for your consideration. James Moger gitblit.com [1] https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/api/CommitCommand.java?h=stable-3.1#n288 [2] http://gerrit-documentation.googlecode.com/svn/Documentation/2.0/cmd-hook-commit-msg.html -- 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 http://vger.kernel.org/majordomo-info.html -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v8 2/2] status: always show tracking branch even no change
But this will not work if there is no change between the current branch and its upstream. Always report upstream tracking info even if there is no difference, so that git status is consistent for checking tracking info for current branch. E.g. $ git status # On branch feature1 # Your branch is identical to 'github/feature1'. ... $ git status -bs ## feature1...github/feature1 ... $ git checkout feature1 Already on 'feature1' Your branch is identical to 'github/feature1'. ... nitpicking, but shouldn't this be worded as up to date rather than identical ? The reason is that identical gives the idea that the two branch happen to be on the same commit wheras up to date gives the idea that there is a special relationship between these two particular branches. We are not just listing all branches on the same commit as us, we are actively telling you about this branch because it's interesting to you. -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] OS X: Fix redeclaration of die warning
Thanks Brian, Reviewed-by: Jeremy Huddleston Sequoia jerem...@apple.com On Aug 5, 2013, at 8:59, Brian Gernhardt br...@gernhardtsoftware.com wrote: compat/apple-common-crypto.h uses die() in one of its macros, but was included in git-compat-util.h before the definition of die. Fix by simply moving the relevant block after the die/error/warning declarations. Signed-off-by: Brian Gernhardt br...@gernhardtsoftware.com --- Not sure if this is the best place to move it to, but it's the earliest it can be in the file without causing errors. (Namely that clang has to guess what die() means in apple-common-crypto.h and guesses differently than the actual definition.) git-compat-util.h | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/git-compat-util.h b/git-compat-util.h index af5f6bb..d60e28d 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -129,16 +129,6 @@ #include poll.h #endif -#ifndef NO_OPENSSL -#ifdef APPLE_COMMON_CRYPTO -#include compat/apple-common-crypto.h -#else -#include openssl/evp.h -#include openssl/hmac.h -#endif /* APPLE_COMMON_CRYPTO */ -#include openssl/x509v3.h -#endif /* NO_OPENSSL */ - #if defined(__MINGW32__) /* pull in Windows compatibility stuff */ #include compat/mingw.h @@ -340,6 +330,16 @@ extern NORETURN void die_errno(const char *err, ...) __attribute__((format (prin extern int error(const char *err, ...) __attribute__((format (printf, 1, 2))); extern void warning(const char *err, ...) __attribute__((format (printf, 1, 2))); +#ifndef NO_OPENSSL +#ifdef APPLE_COMMON_CRYPTO +#include compat/apple-common-crypto.h +#else +#include openssl/evp.h +#include openssl/hmac.h +#endif /* APPLE_COMMON_CRYPTO */ +#include openssl/x509v3.h +#endif /* NO_OPENSSL */ + /* * Let callers be aware of the constant return value; this can help * gcc with -Wuninitialized analysis. We restrict this trick to gcc, though, -- 1.8.4.rc1.384.g0976a17.dirty smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 1/3] Makefile: Fix APPLE_COMMON_CRYPTO with BLK_SHA1
Thanks Brian, Reviewed-by: Jeremy Huddleston Sequoia jerem...@apple.com On Aug 5, 2013, at 8:59, Brian Gernhardt br...@gernhardtsoftware.com wrote: It used to be that APPLE_COMMON_CRYPTO did nothing when BLK_SHA1 was set. But APPLE_COMMON_CRYPTO is now used for more than just SHA1 (see 3ef2bca) so make sure that the appropriate libraries are always set. Signed-off-by: Brian Gernhardt br...@gernhardtsoftware.com --- Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Makefile b/Makefile index 82f2e22..7051956 100644 --- a/Makefile +++ b/Makefile @@ -1182,6 +1182,9 @@ ifdef NEEDS_SSL_WITH_CRYPTO else LIB_4_CRYPTO = $(OPENSSL_LINK) -lcrypto endif +ifdef APPLE_COMMON_CRYPTO + LIB_4_CRYPTO += -framework Security -framework CoreFoundation +endif endif ifdef NEEDS_LIBICONV ifdef ICONVDIR @@ -1413,7 +1416,6 @@ ifdef PPC_SHA1 LIB_H += ppc/sha1.h else ifdef APPLE_COMMON_CRYPTO - LIB_4_CRYPTO += -framework Security -framework CoreFoundation COMPAT_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL SHA1_HEADER = CommonCrypto/CommonDigest.h else -- 1.8.4.rc1.384.g0976a17.dirty smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH] imap-send: use Apple's Security framework for base64 encoding
Hi David,
Thanks for massaging it to apply to master and cleaning up the style conflicts.
On Jul 27, 2013, at 13:31, David Aguilar dav...@gmail.com wrote:
From: Jeremy Huddleston jerem...@apple.com
Use Apple's supported functions for base64 encoding instead
of the deprecated OpenSSL functions.
Signed-off-by: Jeremy Huddleston jerem...@apple.com
Signed-off-by: David Aguilar dav...@gmail.com
---
This is Jeremy's original patch rebased onto the latest master.
Jeremy, the only way I could get this to work was to suppress inclusion of
openssl/sha.h by defining HEADER_SHA_H. This can be removed when we have
replacements for openssl/x509v3.h.
Makefile| 1 +
imap-send.c | 85 ++---
2 files changed, 82 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 0600eb4..4c40665 100644
--- a/Makefile
+++ b/Makefile
@@ -1413,6 +1413,7 @@ ifdef PPC_SHA1
LIB_H += ppc/sha1.h
else
ifdef APPLE_COMMON_CRYPTO
+ LIB_4_CRYPTO += -framework Security -framework CoreFoundation
COMPAT_CFLAGS += -DCOMMON_DIGEST_FOR_OPENSSL
SHA1_HEADER = CommonCrypto/CommonDigest.h
else
diff --git a/imap-send.c b/imap-send.c
index d6b65e2..3fd9c0e 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -22,14 +22,11 @@
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
*/
-#include cache.h
-#include exec_cmd.h
-#include run-command.h
-#include prompt.h
#ifdef NO_OPENSSL
typedef void *SSL;
#else
#ifdef APPLE_COMMON_CRYPTO
+/* git-compat-util.h overwrites ctype.h; this must be included first */
#include CommonCrypto/CommonHMAC.h
#define HMAC_CTX CCHmacContext
#define HMAC_Init(hmac, key, len, algo) CCHmacInit(hmac, algo, key, len)
@@ -37,12 +34,23 @@ typedef void *SSL;
#define HMAC_Final(hmac, hash, ptr) CCHmacFinal(hmac, hash)
#define HMAC_CTX_cleanup(ignore)
#define EVP_md5() kCCHmacAlgMD5
+
+#if __MAC_OS_X_VERSION_MIN_REQUIRED = 1070
+#define APPLE_LION_OR_NEWER
+#include Security/Security.h
+#define HEADER_SHA_H /* suppress inclusion of openssl/sha.h */
+#endif
+
#else
#include openssl/evp.h
#include openssl/hmac.h
#endif
#include openssl/x509v3.h
#endif
+#include cache.h
+#include exec_cmd.h
+#include run-command.h
+#include prompt.h
static const char imap_send_usage[] = git imap-send mbox;
@@ -877,6 +885,75 @@ static void imap_close_store(struct imap_store *ctx)
free(ctx);
}
+#ifdef APPLE_LION_OR_NEWER
+#define EVP_DecodeBlock git_CC_EVP_DecodeBlock
+#define EVP_EncodeBlock git_CC_EVP_EncodeBlock
+#define error_check(pattern, err) \
+ do { \
+ if (err) { \
+ die(pattern, (long)CFErrorGetCode(err)); \
+ } \
+ } while(0)
+
+static int git_CC_EVP_EncodeBlock(unsigned char *out,
+ const unsigned char *in, int inlen)
+{
+ CFErrorRef err;
+ SecTransformRef encoder;
+ CFDataRef input, output;
+ CFIndex length;
+
+ encoder = SecEncodeTransformCreate(kSecBase64Encoding, err);
+ error_check(SecEncodeTransformCreate failed: %ld, err);
+
+ input = CFDataCreate(kCFAllocatorDefault, in, inlen);
+ SecTransformSetAttribute(encoder, kSecTransformInputAttributeName,
+ input, err);
+ error_check(SecTransformSetAttribute failed: %ld, err);
+
+ output = SecTransformExecute(encoder, err);
+ error_check(SecTransformExecute failed: %ld, err);
+
+ length = CFDataGetLength(output);
+ CFDataGetBytes(output, CFRangeMake(0, length), out);
+
+ CFRelease(output);
+ CFRelease(input);
+ CFRelease(encoder);
+
+ return (int)strlen((const char *)out);
+}
+
+static int git_CC_EVP_DecodeBlock(unsigned char *out,
+ const unsigned char *in, int inlen)
+{
+ CFErrorRef err;
+ SecTransformRef decoder;
+ CFDataRef input, output;
+ CFIndex length;
+
+ decoder = SecDecodeTransformCreate(kSecBase64Encoding, err);
+ error_check(SecEncodeTransformCreate failed: %ld, err);
+
+ input = CFDataCreate(kCFAllocatorDefault, in, inlen);
+ SecTransformSetAttribute(decoder, kSecTransformInputAttributeName,
+ input, err);
+ error_check(SecTransformSetAttribute failed: %ld, err);
+
+ output = SecTransformExecute(decoder, err);
+ error_check(SecTransformExecute failed: %ld, err);
+
+ length = CFDataGetLength(output);
+ CFDataGetBytes(output, CFRangeMake(0, length), out);
+
+ CFRelease(output);
+ CFRelease(input);
+ CFRelease(decoder);
+
+ return (int)strlen((const char *)out);
+}
+#endif /* APPLE_LION_OR_NEWER */
+
#ifndef NO_OPENSSL
/*
--
1.8.3.2.804.g0da7a53.dirty
smime.p7s
Description: S/MIME cryptographic signature
Re: first parent, commit graph layout, and pull merge direction
- Mail original - On Thu, May 23, 2013 at 5:06 AM, Andreas Krey a.k...@gmx.de wrote: [snip] ... Don't do that, then. :-) Problem is, in this case 'I' expands to about 17 people I need to educate on this. This is a feature of `git pull` that I really despise. I really wish `git pull` treated the remote as the first parent in its merge operation. seconded... github's network pages (which display the commit graph of projects) seems to follow the first parent at the top rule and the pull merges are standing out as wrong because of that... -- 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 http://vger.kernel.org/majordomo-info.html
Re: Subtree: My Status
- Mail original - Hi folks, I apologize for being off the grid for a while. We had a baby and unexpectedly ended up in the NICU. We just got him home a week ago. Everyone is doing fine but I had to pretty much drop all non-essential work for a month or so. Good to here that everything is well on your side and congratulation for the baby, Rest assured that I have all of the git-subtree-related mail sitting in my inbox. It will take me some time to process it all -- looks ike there has been a lot of good work! no worries, there is no emergency here... Please remember that I don't consider myself a gatekeeper to git subtree. In fact I could use some help reviewing and approving patches. If anyone thinks a patch looks good, let Junio know. It's my responsibility to object to things, not your responsibility to wait for I guess it's more or less everybody's responsability to review patches, but it seems to me that for the actual gate-keeping, Junio considers you in charge of git-subtree... Maybe there is an organisational quirk to sort- out here... Junio ? -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/8] Add new git-cc-cmd helper to contrib
Would it make sense to integrate this in git shortlog, which already does something similar? Conceptually, yes, but the end result will be much larger in scope. I am not sure if shortlog is still a good label for it. since we are throwing ideas around... The first place where I would logically look for such a feature would be in git-blame --cc-list or something like that. git-blame seems to me as a logical place for all look at history and give me a list of names type commands -- 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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/6] show: obey --textconv for blobs
git show --textconv HEAD~4:binary-gob | less but I doubt it is a good idea to turn it on by default this late in the game. Exactly. I certainly do not mind it as an option, and I am on the fence regarding it as a default (I think it might have been a sane thing to do from the start, but at this point the change-of-behavior makes me hesitate). So I am perfectly willing to go either way, depending on what others think. some features detect if they are piping to a terminal... couldn't we do something like that ? -- 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 http://vger.kernel.org/majordomo-info.html
git rebase : knowing where I am...
Hello is there some way to know how far you are within a rebase when the rebase is interupted by a conflict other than the message given by git rebase when it was interrupted ? I would have expected a git rebase --status or something similar... Regards Jérémy Rosen fight key loggers : write some perl using vim -- 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 http://vger.kernel.org/majordomo-info.html
Re: RFC: Very useful script to SVG graph the git commits from a file orientated view
looking a little bit more into this, I was very suprised there seems to be little/no tools in the git ecosystem that studies the dependencies between commits based on the file they modified and/or the conflict they would cause. Is there any pre-existing tool to do that ? It can be done with git-log --name-only(the graph_git.pl is just a graphing layer above that command) but i'm suprised that I couldn't find anything else And that was at the file level, is there any tool to help find what commits can be reordered without causing conflicts ? I am not sure if there is an easy way to extract potential conflict information from git... Regards Jérémy Rosen fight key loggers : write some perl using vim - Mail original - Hi Jeremy, It would be great if you could send your email again to the list, so that other people can see that there is interest in my script :) Makes it easier for me to get it included. * The tooltips are very handy, but it would be nice if the tooltip would activate on the whole commit ellipsis, not just the text inside the ellipsis Yes, tooltips are a real pain. I don't know how to do that. * I would love to have tooltips on the arrows too. when trying to follow what arrow is what file it makes things really handi Actually they do have tooltips - it's just that the arrows are really thin so you have to be very accurate with your mouse pointing! It would be nice if there were a way to filter only some files in the output... there probably is with the git-log like syntax but i'm not a master of that... hints would be welcome Try just specifying the files: $ graph_git.pl -10 filename1 filename2 I haven't tested, but it should work is there a public repo for this script so I can point other people to it ? No - any suggestions as to where to put it are welcome :) John -- 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 http://vger.kernel.org/majordomo-info.html
Re: Teaching rerere about existing merges
thanks a lot, that solves my problem. I'm a bit suprised that it's not part of the git-rerere command but that's good enough for me... Cordialement Jérémy Rosen fight key loggers : write some perl using vim - Mail original - Jeremy Rosen jeremy.ro...@openwide.fr writes: is there a way to teach rerere about existing merge commits, or do I have to re-solve all the existing merge manually once ? See src/contrib/rerere-train.sh and Junio's blog. http://git-blame.blogspot.com/2012/04/rebuilding-git-integration-environment.html -- 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 http://vger.kernel.org/majordomo-info.html
Re: RFC: Very useful script to SVG graph the git commits from a file orientated view
so, I started using it this WE for my big rebase I had aproximately 130 non-merge commits in my branch, a feature branch in which I had regularly merged master, but I needed to rebase everything and then reorganise most commits to make the whole thing reviewable * merge bug-fix with the commit that introduced the bug * change sloppy commit messages * separate sloppy commit into multiple commits I did my initial rebase and I am now doing repetitive git rebase -i to get everything going your script is very usefull to me because it allows me to easily see the overall layout of things and figure what commit are suspect (touching files from different areas that have no reasons to be touched at the same time) it also allows me to easily find commits that are highly connected to other ones and are the most likely to be problematic when reordering commits. Overall that script is awesome. couple of ideas to refine things * The tooltips are very handy, but it would be nice if the tooltip would activate on the whole commit ellipsis, not just the text inside the ellipsis * I would love to have tooltips on the arrows too. when trying to follow what arrow is what file it makes things really handi It would be nice if there were a way to filter only some files in the output... there probably is with the git-log like syntax but i'm not a master of that... hints would be welcome is there a public repo for this script so I can point other people to it ? Cordialement Jérémy Rosen fight key loggers : write some perl using vim - Mail original - Opps, somehow I forgot to actually attach it. It's now attached -- 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 http://vger.kernel.org/majordomo-info.html
Re: RFC: Very useful script to SVG graph the git commits from a file orientated view
very usefull indeed, where can I find it ? I have a big rebase/merge/reorganise work that is comming soon and that is going to be tremendously usefull... Cordialement Jérémy Rosen fight key loggers : write some perl using vim - Mail original - Hi, I made this script to help me see the logical connections between commits. It produces a .svg graph showing the commits that affected a file. For example, say you have the commits: commit1 - modify hello.c commit2 - modify goodbye.c commit3 - modify hello.c and goodbye.c It will draw a graph showing the first two commits as siblings, and commit3 as a child of commit1 and commit2. I have found this very useful when squashing and rebasing development branches that have got a lot of fix typo and fix type commit messages. From the graph you can quickly see which commit they were fixing (the parent, in the graph). Here is an example output, running it on kwin for the last 100 commits: $ graph_git.pl --nofiles -100 http://imagebin.org/252754 And again with files for the last 10 commits: $ graph_git.pl -10 http://imagebin.org/252756 (Note that it has tooltips) JohnFlux -- 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 http://vger.kernel.org/majordomo-info.html -- 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 http://vger.kernel.org/majordomo-info.html
Re: git subtree oddity
I am starting to regret that I caved in and started carrying a copy of it in contrib/. It probably is a good idea to drop it from my tree and let it mature and eventually flourish outside. that's a shame... it solves a real problem, is simple to use, and really powerfull. but unfortunately, I have sent a patch that solves a serious bug... which had already been reported and patched but had received no answer, and nobody replied to it. Is there anything that can be done to get this rolling, or a way to have the use-case it covers better handle by git-submodule ? currently the problem of a git repo in a git repo is very complicated to deal with in a clean way... Regards Jérémy -- 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 http://vger.kernel.org/majordomo-info.html
Re: Questions/investigations on git-subtree and tags
Paul, I'm not quite sure where I should go from here...
should I send you a patch so you make it a V3 of your patch ? should I
send a patch superseeding yours ?
I have also found a similar problem in git-subtree pull, which needs
the same fix.
in the mean time, attached is the current version of my changes
Cordialement
Jérémy Rosen
fight key loggers : write some perl using vim
From 12490724ae955719694d825dff4fa9e0d2709c1c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= jeremy.ro...@openwide.fr
Date: Tue, 12 Mar 2013 10:56:54 +0100
Subject: [PATCH 1/2] git-subtree: make sure the SHA saved as ancestor is a
commit
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
When adding or merging the first parameter might not be a commit, it can also be a tag SHA.
This needs to be fixed by using the underlying commit or the ancestor finding code will croak at split time
Signed-off-by: Jérémy Rosen jeremy.ro...@openwide.fr
---
contrib/subtree/git-subtree.sh |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8a23f58..8b9d114 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -531,7 +531,7 @@ cmd_add_repository()
cmd_add_commit()
{
- revs=$(git rev-parse $default --revs-only $@) || exit $?
+ revs=$(git rev-parse $default --revs-only $1^{commit}) || exit $?
set -- $revs
rev=$1
@@ -655,7 +655,7 @@ cmd_split()
cmd_merge()
{
- revs=$(git rev-parse $default --revs-only $@) || exit $?
+ revs=$(git rev-parse $default --revs-only $1^{commit}) || exit $?
ensure_clean
set -- $revs
--
1.7.10.4
From 05d1dd56217be59d69952a41d97e204cc7821948 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=A9my=20Rosen?= jeremy.ro...@openwide.fr
Date: Tue, 12 Mar 2013 10:57:56 +0100
Subject: [PATCH 2/2] git-subtree: use ls-remote to check the refspec passed
to pull and add
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
ls-remote is the correct way to check that a parameter is a valid fetchable target
Signed-off-by: Jérémy Rosen jeremy.ro...@openwide.fr
---
contrib/subtree/git-subtree.sh | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/contrib/subtree/git-subtree.sh b/contrib/subtree/git-subtree.sh
index 8b9d114..61d4eab 100755
--- a/contrib/subtree/git-subtree.sh
+++ b/contrib/subtree/git-subtree.sh
@@ -503,13 +503,8 @@ cmd_add()
cmd_add_commit $@
elif [ $# -eq 2 ]; then
- # Technically we could accept a refspec here but we're
- # just going to turn around and add FETCH_HEAD under the
- # specified directory. Allowing a refspec might be
- # misleading because we won't do anything with any other
- # branches fetched via the refspec.
- git rev-parse -q --verify $2^{commit} /dev/null ||
- die '$2' does not refer to a commit
+ git ls-remote --exit-code $1 $2 ||
+ die '$2' is not a correct reference on '$1'
cmd_add_repository $@
else
@@ -700,6 +695,8 @@ cmd_merge()
cmd_pull()
{
ensure_clean
+ git ls-remote --exit-code $1 $2 ||
+ die '$2' is not a correct reference on '$1'
git fetch $@ || exit $?
revs=FETCH_HEAD
set -- $revs
--
1.7.10.4
Re: Questions/investigations on git-subtree and tags
ok, attached is a patch on top of your patch that solves my particular
problem
I am not formally submitting it since its on top of your part and i'd
really like your input before submitting.
It solves my problem and afaict does what your fix did and what git-subtree
originally intended to do...
tell me what you think
Cordialement
Jérémy Rosen
fight key loggers : write some perl using vim
- Mail original -
I think I tried adding the ^{} syntax, but I don't think it works
on
remote repos. Or I couldn't get the right syntax.
indeed, it doesn't work on fetch, but it could be used somewhere
between the fetch and the commit-tree to move from the ref to the
associated commit
Latest patch:
http://thread.gmane.org/gmane.comp.version-control.git/217257
oh, that patch, yes I found it while looking around it is a step in
the right direction but it doesn't help in my case since i'm using a
valid remote ref that can be fetched
(on a side note you could use git ls-remote to check for the remote
ref and avoid a fetch in case of an incorrect ref, but that's just a
detail)
I just tested with it and here is what happens
git subtree add --squash -P br2 git://git.buildroot.net/buildroot
2013.02 = works ok, br2 is created
however the message of the squash commit is
Squashed 'br2/' content from commit f1d2c19
git-subtree-dir: br2
git-subtree-split: f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948
which is not correct :
git ls-remote git://git.buildroot.net/buildroot 2013.02
f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948 refs/tags/2013.02
git ls-remote git://git.buildroot.net/buildroot 2013.02^{}
15ace1a845c9e7fc65b648bbaf4dd14e03d938fd refs/tags/2013.02^{}
as you can see git subtee thinks it splited from the tag SHA instead
of the tag's commit SHA
this is incorrect because the tag isn't here, and at split time git
subtree won't be able to find the correct ancestor. We just need to
make sure we use the tag's commit instead
of the tag
changing
revs=FETCH_HEAD
to
revs=FETCH_HEAD^{}
in cmd_add_repository
seems to fix it, both for remote branch pull and remote tag pull
we still have a bug lurking around it's the case where the user does
the fetch himself then use subtree add with a tag SHA. but let's
discuss problems one at a time :)
--
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 http://vger.kernel.org/majordomo-info.html
506,513c506,507
case $2 in
*\**) # Avoid pulling in multiple branches
die '$2' contains a wildcard
;;
*:*) # Don't create a local branch for the subtree
die '$2' contains a local branch name
;;
esac
---
git ls-remote --exit-code $1 $2 ||
die '$2' is not a correct reference on '$1'
535c529
revs=$(git rev-parse $default --revs-only $@) || exit $?
---
revs=$(git rev-parse $default --revs-only $1^{commit}) || exit $?
Re: Questions/investigations on git-subtree and tags
- Mail original -
Jeremy Rosen jeremy.ro...@openwide.fr writes:
506,513c506,507
case $2 in
*\**) # Avoid pulling in multiple branches
die '$2' contains a wildcard
;;
*:*) # Don't create a local branch for the subtree
die '$2' contains a local branch name
;;
esac
---
git ls-remote --exit-code $1 $2 ||
You would need to quote $1 and $2 properly to prevent the shell from
splitting them into words, no?
yes... I'm not very good at shell programming, good catch
die '$2' is not a correct reference on '$1'
535c529
revs=$(git rev-parse $default --revs-only $@) || exit $?
---
revs=$(git rev-parse $default --revs-only $1^{commit}) || exit
$?
Is it guaranteed that your $# is 1 at this point, or is it something
you would also need to check here, or perhaps in the caller of this
function (I cannot tell offhand in a patch without any context)?
I have checked the call sites and yes we can only have one arguement at
this point. so the $@ to $1 is more about future-proofing and readability
thx for proofreading
--
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 http://vger.kernel.org/majordomo-info.html
Questions/investigations on git-subtree and tags
Hello everybody
I am trying to use git-subtree to follow a subproject but I have a couple of
problems and I am not sure if I am doing something wrong
Basically I am trying to use a tag on the subproject as my base for the
subproject but subtree doesn't seem to handle that properly
my first attempt was to simply do
git subtree add --squash git://git.buildroot.net/buildroot 2013.02
but subtree refused, telling me that the SHA of the tag is not a valid commit.
Ok it makes sense, though I think this is a very valid use-case...
so I tried
git subtree add git://git.buildroot.net/buildroot 2013.02^{commit}
which was refused because git fetch can't parse the ^{commit} marker.
Again it makes sense, but I really want to start from that tag.
so I tried
git fetch git://git.buildroot.net/buildroot 2013.02
git subtree add --squash FETCH_HEAD
which worked. Ok at that point I am slightly abusing git subtree, but it seems
a valid usage
except that this last attempt causes serious problems when trying to split out
the tree again
the call to git commit-tree within git subtree split complains that the SHA
of the parent
is not a valid commit SHA. Which is true, it's the SHA of the tag.
At this point I am not sure if I am abusing subtree, if I have a legitimate but
unimplemented use-case and how to
fix/implement it.
the squash-commit message only contains the SHA of the tag, should it contain
the SHA of the commit ?
subtree split can only handle commit SHA, should it somehow follow tag SHA
too ? how ?
this is probably a trivial fix for someone with good knowledge of git-subtree
but i'm not there yet, so any hint would be welcomed
Regards
Jérémy Rosen
fight key loggers : write some perl using vim
--
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 http://vger.kernel.org/majordomo-info.html
Re: Questions/investigations on git-subtree and tags
Hi Jérémy, Git subtree ignores tags from the remote repo. is that a design decision or a case of not implemented yet To follow a project in a subdirectory I would use git-subtree add selecting a branch, not a tag, from the other repo. Then use git-subtree pull to keep yourself updated. well... yes, but releases are marked by tags, not branches so what I really want is a tag. I still use git so I have the possibility to update and can traceback what happened later e.g. To add: git subtree add --prefix=$subdir $repo $branch Then to update: git subtree pull --prefix=$subdir $repo $branch ok, that probably works with branches (didn't test) If you make any changes on the branch and wanted to push them back you could do that with: git subtree pull --prefix=$subdir $repo2 $branch2 $repo2 and $branch2 would be different from $repo and $branch if you wanted to push to your own fork before submitting a pull request. shouldn't there be a subtree split somewhere ? IIUC pull is only merge from the remote to my local repo, not the other way round -- Paul [W] Campbell -- 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 http://vger.kernel.org/majordomo-info.html
Re: Questions/investigations on git-subtree and tags
Ok, I can understand that you don't want to import tags for
namespace reason, but in that case shouldn't
git subtree add refuse to create a subtree when the tag isn't a
commit
It shouldn't and tries not to, but is limited in it's ability to
identify if a refspec points to a commit or not in the remote repo.
ok, i've studied a little more
* the target for git subtree add url refspec can only be a remote branch
or tag, since we git fetch
can only target remote refs.
* in case of a branch, git subtree forgets the branch and only use the commit
linked to the branch. for
tags, the fetch part is ok, it's the merge part that fail. adding ^{} at the
right place would probably fix that
I've posted a patch (which is pending a lot of other changes to
git-subtree that I'm corralling) that tries to prevent some obvious
errors in the refspec. But letting the git fetch used by git-subtree
add and git-subtree pull catch the error and report it may be the
best
option.
that's interesting... do you have a link ?
I've never really tried using --squash, I don't see that it adds any
value for me.
my project has a git subtree for a linux kernel and another subtree for
buildroot,
a default .git is about 1.5G, squashing it reduces it to 200M so it's worth it
for me :)
--
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 http://vger.kernel.org/majordomo-info.html
Re: Questions/investigations on git-subtree and tags
I think I tried adding the ^{} syntax, but I don't think it works on
remote repos. Or I couldn't get the right syntax.
indeed, it doesn't work on fetch, but it could be used somewhere between the
fetch and the commit-tree to move from the ref to the associated commit
Latest patch:
http://thread.gmane.org/gmane.comp.version-control.git/217257
oh, that patch, yes I found it while looking around it is a step in the right
direction but it doesn't help in my case since i'm using a valid remote ref
that can be fetched
(on a side note you could use git ls-remote to check for the remote ref and
avoid a fetch in case of an incorrect ref, but that's just a detail)
I just tested with it and here is what happens
git subtree add --squash -P br2 git://git.buildroot.net/buildroot 2013.02 =
works ok, br2 is created
however the message of the squash commit is
Squashed 'br2/' content from commit f1d2c19
git-subtree-dir: br2
git-subtree-split: f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948
which is not correct :
git ls-remote git://git.buildroot.net/buildroot 2013.02
f1d2c19091e1c2ef803ec3267fe71cf6ce7dd948refs/tags/2013.02
git ls-remote git://git.buildroot.net/buildroot 2013.02^{}
15ace1a845c9e7fc65b648bbaf4dd14e03d938fdrefs/tags/2013.02^{}
as you can see git subtee thinks it splited from the tag SHA instead of the
tag's commit SHA
this is incorrect because the tag isn't here, and at split time git subtree
won't be able to find the correct ancestor. We just need to make sure we use
the tag's commit instead
of the tag
changing
revs=FETCH_HEAD
to
revs=FETCH_HEAD^{}
in cmd_add_repository
seems to fix it, both for remote branch pull and remote tag pull
we still have a bug lurking around it's the case where the user does the fetch
himself then use subtree add with a tag SHA. but let's discuss problems one at
a time :)
--
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 http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mergetools/p4merge: Handle /dev/null
Sorry to be replying to this so late; I hadn't noticed the post until now!
I've tried putting that code in my p4merge script and yes it does indeed
work fine. However, it puts a temporary file in the working directory
which I'm not sure is a good idea? If we look at this patch which
actually solved pretty much the same problem, but when merging and,
during a merge conflict, a file was created in both branches:
https://github.com/git/git/commit/ec245ba
... it is creating a temp file in a proper temp dir, rather than in the
working dir. I think that would be the proper solution here. However,
I really want to get this fixed so I'd be happy for this band-aid fix of
the p4merge script to be checked in until we could get a patch more like
the aforementioned one, at a later date, to create empty files in a
proper temp dir and pass them as $LOCAL and $REMOTE. :-)
--
Best regards,
Jeremy Morton (Jez)
On 11/10/2012 04:22, David Aguilar wrote:
p4merge does not properly handle the case where /dev/null
is passed as a filename.
Workaround it by creating a temporary file for this purpose.
Reported-by: Jeremy Mortonad...@game-point.net
Signed-off-by: David Aguilardav...@gmail.com
---
Jeremy, can you test this?
mergetools/p4merge | 25 +
1 file changed, 25 insertions(+)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 1a45c1b..295361a 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -1,5 +1,30 @@
diff_cmd () {
+ # p4merge does not like /dev/null
+ rm_local=
+ rm_remote=
+ if test /dev/null = $LOCAL
+ then
+ LOCAL=./p4merge-dev-null.LOCAL.$$
+ $LOCAL
+ rm_local=true
+ fi
+ if test /dev/null = $REMOTE
+ then
+ REMOTE=./p4merge-dev-null.REMOTE.$$
+ $REMOTE
+ rm_remote=true
+ fi
+
$merge_tool_path $LOCAL $REMOTE
+
+ if test -n $rm_local
+ then
+ rm -f $LOCAL
+ fi
+ if test -n $rm_remote
+ then
+ rm -f $REMOTE
+ fi
}
merge_cmd () {
--
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 http://vger.kernel.org/majordomo-info.html
Bizarre problem cloning repo from Codeplex
I'm trying to clone the following repository from Codeplex: https://git01.codeplex.com/entityframework.git git downloads all the objects, creates the directory entityframework, then displays error: RPC failed; result=56, HTTP code = 200 and immediately deletes the directory. I can clone other HTTPS repos with this git installation, for example from Bitbucket and Github. It's git 1.7.10.4 on Debian. I can also clone this codeplex repo OK on my windows git installation (1.7.11.msysgit.1). I'm totally perplexed; anyone have any idea what is going wrong with the Debian git installation here? -- Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Re: Fixing the p4merge launch shell script
Junio C Hamano gitster at pobox.com writes: Jeremy Morton admin at game-point.net writes: I've noticed that the p4merge shell script could do with some improvement when it comes to merging. Because p4merge throws up an error when one of the files it's given to diff is /dev/null, git needs to create a temporary empty file and pass that to p4merge when diffing a file that has been created/deleted (eg. create file, git add ., git diff --cached). ... Thoughts? Is there an easier way to do this? Which version of git? Perhaps you do not have ec245ba (mergetool: Provide an empty file when needed, 2012-01-19) yet? That patch fixes the mergetool part, but the part I was referring to was the difftool part, which still has this problem. Best regards, Jeremy Morton (Jez) -- 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 http://vger.kernel.org/majordomo-info.html
Fixing the p4merge launch shell script
Hi,
I've noticed that the p4merge shell script could do with some
improvement when it comes to merging. Because p4merge throws up an
error when one of the files it's given to diff is /dev/null, git needs
to create a temporary empty file and pass that to p4merge when diffing a
file that has been created/deleted (eg. create file, git add ., git diff
--cached).
At the moment, the hack I'm using, which works, is to create a
c:/blank.txt file which is an empty file, and modify
libexec/git-core/mergetools/p4merge to start with this:
diff_cmd () {
if [ ! -f $LOCAL ]
then
LOCAL=C:/blank.txt
fi
if [ ! -f $REMOTE ]
then
REMOTE=C:/blank.txt
fi
$merge_tool_path $LOCAL $REMOTE
}
Obviously, this isn't good enough because c:/blank.txt probably won't
exist on the system. It would be nice for the temporary blank file to
have the same extension as the one that's been added, so we could diff
(say) c:/users/jez/Temp/abc123_newFile.foo
c:/development/bar/newfile.foo. However, I can't see a way to do this
purely from within the shell script (even `mktemp` doesn't exist on all
systems so that isn't good enough). I believe git needs to create this
temporary blank file itself, much like it creates a temporary file for
the previous version of a file that's been modified when it's being
diff'd. It then needs to expose the location of this temporary file as
a variable; say $LOCALBLANK. So, we would be able to modify the shell
script to this:
diff_cmd () {
if [ ! -f $LOCAL ]
then
LOCAL=$LOCALBLANK
fi
if [ ! -f $REMOTE ]
then
REMOTE=$REMOTEBLANK
fi
$merge_tool_path $LOCAL $REMOTE
}
Thoughts? Is there an easier way to do this?
--
Best regards,
Jeremy Morton (Jez)
--
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 http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation: Use 'First Paragraph' instead of 'First Line'.
The discussion of email subject throughout the documentation is misleading; it indicates that the first line will become the subject. In fact, the first and second and third lines will become the subject, up until the first full blank line. Describing it as the first paragraph is more accurate. Signed-off-by: Jeremy White jwh...@codeweavers.com --- Documentation/git-commit.txt |2 +- Documentation/git-for-each-ref.txt |2 +- Documentation/git-format-patch.txt |8 +--- Documentation/git-shortlog.txt |2 +- Documentation/gitcore-tutorial.txt |2 +- Documentation/gittutorial.txt |2 +- Documentation/user-manual.txt |2 +- 7 files changed, 11 insertions(+), 9 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index e99bb14..a61bca9 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -349,7 +349,7 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line +Tools that turn commits into email, for example, use the first paragraph on the Subject: line and the rest of the commit in the body. include::i18n.txt[] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index 7e83288..499c26a 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -100,7 +100,7 @@ Fields that have name-email-date tuple as its value (`author`, `committer`, and `tagger`) can be suffixed with `name`, `email`, and `date` to extract the named component. -The first line of the message in a commit and tag object is +The first paragraph of the message in a commit and tag object is `subject`, the remaining lines are `body`. The whole message is `contents`. diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 9674f9d..e6f6d0e 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -57,10 +57,12 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in dir. Otherwise they are created in the current working directory. -By default, the subject of a single patch is [PATCH] First Line and +By default, the subject of a single patch is [PATCH] First Paragraph and the subject when multiple patches are output is [PATCH n/m] First -Line. To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +Paragraph. Note that First Paragraph consists of text in the commit message +prior to the first completely blank line (see the DISCUSSION section +in linkgit:git-commit[1]). To force 1/1 to be added for a single patch, +use `-n`. To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index dfd4d0c..9464932 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -15,7 +15,7 @@ DESCRIPTION --- Summarizes 'git log' output in a format suitable for inclusion in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +the first paragraph of the commit message will be shown. Additionally, [PATCH] will be stripped from the commit description. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index f7815e9..92f97e6 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their +and the first paragraph of the commit log message from their top-of-the-tree commits, you are currently on `master` branch (notice the asterisk `\*` character), and the first column for the later output lines is used to show commits contained in the diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index 1c16066..a1bc56c 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -139,7 +139,7 @@ A note on commit messages: Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. Tools that turn commits into email, for -example, use the first line on the Subject: line and the rest of the +example, use the first paragraph on the Subject: line and the rest of the commit
[PATCH v2] Documentation: describe subject more precisely
The discussion of email subject throughout the documentation is misleading; it indicates that the first line will always become the subject. In fact, the subject is generally all lines up until the first full blank line. Signed-off-by: Jeremy White jwh...@codeweavers.com --- Documentation/git-commit.txt |2 +- Documentation/git-for-each-ref.txt |7 --- Documentation/git-format-patch.txt | 11 +++ Documentation/git-shortlog.txt |2 +- Documentation/gitcore-tutorial.txt |2 +- Documentation/gittutorial.txt |2 +- Documentation/user-manual.txt |2 +- 7 files changed, 16 insertions(+), 12 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 4622297..6b9ba20 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -389,7 +389,7 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line +Tools that turn commits into email, for example, use the first paragraph on the Subject: line and the rest of the commit in the body. include::i18n.txt[] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index c872b88..db55a4e 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -102,9 +102,10 @@ Fields that have name-email-date tuple as its value (`author`, and `date` to extract the named component. The complete message in a commit and tag object is `contents`. -Its first line is `contents:subject`, the remaining lines -are `contents:body` and the optional GPG signature -is `contents:signature`. +Its first line is `contents:subject`, where subject is the concatenation +of all lines of the commit message up to the first blank line. The next +line is 'contents:body', where body is all of the lines after the first +blank line. Finally, the optional GPG signature is `contents:signature`. For sorting purposes, fields with numeric values sort in numeric order (`objectsize`, `authordate`, `committerdate`, `taggerdate`). diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 04c7346..6d43f56 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -58,10 +58,13 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in dir. Otherwise they are created in the current working directory. -By default, the subject of a single patch is [PATCH] First Line and -the subject when multiple patches are output is [PATCH n/m] First -Line. To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +By default, the subject of a single patch is [PATCH] followed by +the concatenation of lines from the commit message up to the first blank +line (see the DISCUSSION section of linkgit:git-commit[1]). + +When multiple patches are output, the subject prefix will instead be +[PATCH n/m] . To force 1/1 to be added for a single patch, use `-n`. +To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 01d8417..6ec30e3 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -15,7 +15,7 @@ DESCRIPTION --- Summarizes 'git log' output in a format suitable for inclusion in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +all text from the commit message up to the first blank line will be shown. Additionally, [PATCH] will be stripped from the commit description. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 9d89336..b5b3534 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -956,7 +956,7 @@ $ git show-branch --topo-order --more=1 master mybranch The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their +and the first part of the commit log message from their top-of-the-tree commits, you are currently on `master` branch (notice the asterisk `*` character), and the first column for the later output lines is used to show commits contained in the diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt index dee0505..76aba59 100644 --- a/Documentation/gittutorial.txt +++ b/Documentation/gittutorial.txt @@ -140,7 +140,7 @@ A note on commit messages: Though not required, it's a good idea to begin the commit
Re: [PATCH] Documentation: Use 'First Paragraph' instead of 'First Line'.
For that kind of casual wording, we have used title on this list for quite a long time, I think. So I'd rather see a change that just says title (if we are making such a change to the documentation, that is). This is not a very strong preference, though. Ah, I was unaware of the use of title, and I rather like it. v3 inbound making more use of title, and hopefully addressing your other points as well. Cheers, Jeremy -- 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 http://vger.kernel.org/majordomo-info.html
[PATCH v3] Documentation: describe subject more precisely
The discussion of email subject throughout the documentation is misleading; it indicates that the first line will always become the subject. In fact, the subject is generally all lines up until the first full blank line. This patch refines that, and makes more use of the concept of a commit title, with the title being all text up to the first blank line. Signed-off-by: Jeremy White jwh...@codeweavers.com --- Documentation/git-commit.txt |6 -- Documentation/git-for-each-ref.txt |7 --- Documentation/git-format-patch.txt | 11 +++ Documentation/git-shortlog.txt |3 +-- Documentation/gitcore-tutorial.txt |9 - Documentation/gittutorial.txt |8 +--- Documentation/user-manual.txt |9 ++--- 7 files changed, 31 insertions(+), 22 deletions(-) diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt index 4622297..9594ac8 100644 --- a/Documentation/git-commit.txt +++ b/Documentation/git-commit.txt @@ -389,8 +389,10 @@ DISCUSSION Though not required, it's a good idea to begin the commit message with a single short (less than 50 character) line summarizing the change, followed by a blank line and then a more thorough description. -Tools that turn commits into email, for example, use the first line -on the Subject: line and the rest of the commit in the body. +The text up to the first blank line in a commit message is treated +as the commit title, and that title is used throughout git. +For example, linkgit:git-format-patch[1] turns a commit into email, and it uses +the title on the Subject line and the rest of the commit in the body. include::i18n.txt[] diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt index c872b88..db55a4e 100644 --- a/Documentation/git-for-each-ref.txt +++ b/Documentation/git-for-each-ref.txt @@ -102,9 +102,10 @@ Fields that have name-email-date tuple as its value (`author`, and `date` to extract the named component. The complete message in a commit and tag object is `contents`. -Its first line is `contents:subject`, the remaining lines -are `contents:body` and the optional GPG signature -is `contents:signature`. +Its first line is `contents:subject`, where subject is the concatenation +of all lines of the commit message up to the first blank line. The next +line is 'contents:body', where body is all of the lines after the first +blank line. Finally, the optional GPG signature is `contents:signature`. For sorting purposes, fields with numeric values sort in numeric order (`objectsize`, `authordate`, `committerdate`, `taggerdate`). diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt index 04c7346..6d43f56 100644 --- a/Documentation/git-format-patch.txt +++ b/Documentation/git-format-patch.txt @@ -58,10 +58,13 @@ output, unless the `--stdout` option is specified. If `-o` is specified, output files are created in dir. Otherwise they are created in the current working directory. -By default, the subject of a single patch is [PATCH] First Line and -the subject when multiple patches are output is [PATCH n/m] First -Line. To force 1/1 to be added for a single patch, use `-n`. To omit -patch numbers from the subject, use `-N`. +By default, the subject of a single patch is [PATCH] followed by +the concatenation of lines from the commit message up to the first blank +line (see the DISCUSSION section of linkgit:git-commit[1]). + +When multiple patches are output, the subject prefix will instead be +[PATCH n/m] . To force 1/1 to be added for a single patch, use `-n`. +To omit patch numbers from the subject, use `-N`. If given `--thread`, `git-format-patch` will generate `In-Reply-To` and `References` headers to make the second and subsequent patch mails appear diff --git a/Documentation/git-shortlog.txt b/Documentation/git-shortlog.txt index 01d8417..afeb4cd 100644 --- a/Documentation/git-shortlog.txt +++ b/Documentation/git-shortlog.txt @@ -14,8 +14,7 @@ git log --pretty=short | 'git shortlog' [-h] [-n] [-s] [-e] [-w] DESCRIPTION --- Summarizes 'git log' output in a format suitable for inclusion -in release announcements. Each commit will be grouped by author and -the first line of the commit message will be shown. +in release announcements. Each commit will be grouped by author and title. Additionally, [PATCH] will be stripped from the commit description. diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt index 9d89336..5325c5a 100644 --- a/Documentation/gitcore-tutorial.txt +++ b/Documentation/gitcore-tutorial.txt @@ -956,12 +956,11 @@ $ git show-branch --topo-order --more=1 master mybranch The first two lines indicate that it is showing the two branches -and the first line of the commit log message from their -top-of-the-tree commits, you are currently on `master` branch -(notice the asterisk
