* Re: git-stash: RFC: Adopt the default behavior to other commands
From: Benoit Sigoure @ 2007-12-17 22:32 UTC (permalink / raw)
To: Sebastian Harl; +Cc: git
In-Reply-To: <20071217110322.GH14889@albany.tokkee.org>
On Dec 17, 2007, at 12:03 PM, Sebastian Harl wrote:
> Hi,
>
> By default, git-stash (when called without any other arguments)
> creates a new
> stash. This is quite different to the behavior of most other Git
> commands
> (e.g. git-tag, git-branch, etc. do "list" by default). In order to
> improve
> consistency git-stash should imho adopt this as well.
>
> The creation of a new stash should not do any harm. However, I
> think that
> consistency is more important (iirc this has been mentioned in the
> current
> survey a couple of times) and doing "list" is (in general) the best
> default.
Hi Sebastian,
this topic has been brought up the ML several times already, and
there seems to be some sort of consensus on the misbehavior of git
stash and what the default should be (listing the stashes seems like
a decent default action). The current behavior of git stash is very
dangerous as the following frequently happens to new comers:
$ git stash
$ <hack on something else>
$ git commit
$ git stash apply
$ git stash clean # Oops, typo, I just stashed my changes again
$ git stash clear # Oops, I just lost my changed
Hopefully, Git gives you means to recover from this sort of error,
but most of the time new comers don't know them and just assume they
lost their work.
Whenever I use git stash, it gives me chills, because I know I can
easily screw things up (even though now I know how to recover from
this sort of "user error").
Cheers,
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: J. Bruce Fields @ 2007-12-17 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <7vtzmh55lu.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 02:17:01PM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> >> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> >>
> >> > By the way, just as a data point: I do keep some git repositories on
> >> > NFS, and access them from multiple machines with different git versions
> >> > (not on purpose--it's just that the machines don't all run the same
> >> > distro, so it'd be extra work to give them all the same version). I
> >> > don't use anything older than 1.5.0. If the repository became unusable
> >> > on one of those machines without warning it'd be annoying.
> >>
> >> What the v1.5.5 release notes will say is that you'll have to set
> >> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
> >
> > Is there any reason not to make pack.indexversion=1 the default (for
> > preexisting repositories at the very least) and suggest in the release
> > notes that people set something else if they want the features the new
> > version provides?
>
> That's a judgement call.
Sure. And I'm totally unfamiliar with the details here, so don't my let
my judgement weigh too heavily.
> Pack-idx format v2 is by design much safer in the face of bitflip (do we
> have a test case to make sure this is indeed true?). But from the end
> user's point of view, all the usual "I do not want to be forced to
> update that old box I do not want to touch" applies.
>
> And the people who needs to suffer from the dilemma are only the ones
> who access a single repository across NFS with git from different
> vintage.
Hm. We tell people to set up public repo's by doing something like:
git clone --bare ~/proj proj.git
touch proj.git/git-daemon-export-ok
scp -r proj.git example.com:
Is that going to hit the same problem if the public server has an older
git version? (Servers do tend to be on longer upgrade cycles; the
public server I use was on something 1.4ish till about a month ago.)
--b.
^ permalink raw reply
* Re: [PATCH] the use of 'tr' in the test suite isn't really portable
From: H.Merijn Brand @ 2007-12-17 22:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlk7t6pc6.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 805 bytes --]
On Mon, 17 Dec 2007 12:25:29 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> The contents looked correct but the patch was garbled.
http://www.xs4all.nl/~procura/git-tr.diff
and attached
The docs tell me to use git-diff, but I don't have a git repos for git,
because git on HP-UX doesn't work yet out of the box, so I use the
snapshots from http://www.codemonkey.org.uk/projects/git-snapshots/git/
This was based on 2007-12-17
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
[-- Attachment #2: git-tr.diff --]
[-- Type: text/x-patch, Size: 6991 bytes --]
diff -pur git-2007-12-10_01/git-filter-branch.sh git-2007-12-10/git-filter-branch.sh
--- git-2007-12-10_01/git-filter-branch.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/git-filter-branch.sh 2007-12-11 13:39:02 +0100
@@ -290,7 +290,7 @@ while read commit parents; do
eval "$filter_tree" < /dev/null ||
die "tree filter failed: $filter_tree"
- git diff-index -r $commit | cut -f 2- | tr '\n' '\0' | \
+ git diff-index -r $commit | cut -f 2- | tr '\n' '\000' | \
xargs -0 git update-index --add --replace --remove
git ls-files -z --others | \
xargs -0 git update-index --add --replace --remove
diff -pur git-2007-12-10_01/t/diff-lib.sh git-2007-12-10/t/diff-lib.sh
--- git-2007-12-10_01/t/diff-lib.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/diff-lib.sh 2007-12-11 13:39:56 +0100
@@ -21,8 +21,8 @@ compare_diff_raw_z () {
# Also we do not check SHA1 hash generation in this test, which
# is a job for t0000-basic.sh
- tr '\0' '\012' <"$1" | sed -e "$sanitize_diff_raw_z" >.tmp-1
- tr '\0' '\012' <"$2" | sed -e "$sanitize_diff_raw_z" >.tmp-2
+ tr '\000' '\012' <"$1" | sed -e "$sanitize_diff_raw_z" >.tmp-1
+ tr '\000' '\012' <"$2" | sed -e "$sanitize_diff_raw_z" >.tmp-2
git diff .tmp-1 .tmp-2 && rm -f .tmp-1 .tmp-2
}
diff -pur git-2007-12-10_01/t/t0020-crlf.sh git-2007-12-10/t/t0020-crlf.sh
--- git-2007-12-10_01/t/t0020-crlf.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t0020-crlf.sh 2007-12-10 14:25:58 +0100
@@ -5,7 +5,7 @@ test_description='CRLF conversion'
. ./test-lib.sh
q_to_nul () {
- tr Q '\0'
+ tr Q '\000'
}
append_cr () {
diff -pur git-2007-12-10_01/t/t1300-repo-config.sh git-2007-12-10/t/t1300-repo-config.sh
--- git-2007-12-10_01/t/t1300-repo-config.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t1300-repo-config.sh 2007-12-10 09:49:48 +0100
@@ -591,12 +591,12 @@ Qsection.sub=section.val4
Qsection.sub=section.val5Q
EOF
-git config --null --list | tr '[\000]' 'Q' > result
+git config --null --list | tr '\000' 'Q' > result
echo >>result
test_expect_success '--null --list' 'cmp result expect'
-git config --null --get-regexp 'val[0-9]' | tr '[\000]' 'Q' > result
+git config --null --get-regexp 'val[0-9]' | tr '\000' 'Q' > result
echo >>result
test_expect_success '--null --get-regexp' 'cmp result expect'
diff -pur git-2007-12-10_01/t/t3300-funny-names.sh git-2007-12-10/t/t3300-funny-names.sh
--- git-2007-12-10_01/t/t3300-funny-names.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t3300-funny-names.sh 2007-12-11 13:40:32 +0100
@@ -54,7 +54,7 @@ echo 'just space
no-funny
tabs ," (dq) and spaces' >expected
test_expect_success 'git ls-files -z with-funny' \
- 'git ls-files -z | tr \\0 \\012 >current &&
+ 'git ls-files -z | tr \\000 \\012 >current &&
git diff expected current'
t1=`git write-tree`
@@ -83,11 +83,11 @@ test_expect_success 'git diff-tree with-
echo 'A
tabs ," (dq) and spaces' >expected
test_expect_success 'git diff-index -z with-funny' \
- 'git diff-index -z --name-status $t0 | tr \\0 \\012 >current &&
+ 'git diff-index -z --name-status $t0 | tr \\000 \\012 >current &&
git diff expected current'
test_expect_success 'git diff-tree -z with-funny' \
- 'git diff-tree -z --name-status $t0 $t1 | tr \\0 \\012 >current &&
+ 'git diff-tree -z --name-status $t0 $t1 | tr \\000 \\012 >current &&
git diff expected current'
cat > expected <<\EOF
diff -pur git-2007-12-10_01/t/t4020-diff-external.sh git-2007-12-10/t/t4020-diff-external.sh
--- git-2007-12-10_01/t/t4020-diff-external.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4020-diff-external.sh 2007-12-11 13:40:44 +0100
@@ -99,7 +99,7 @@ test_expect_success 'no diff with -diff'
git diff | grep Binary
'
-echo NULZbetweenZwords | tr Z '\0' > file
+echo NULZbetweenZwords | tr Z '\000' > file
test_expect_success 'force diff with "diff"' '
echo >.gitattributes "file diff" &&
diff -pur git-2007-12-10_01/t/t4103-apply-binary.sh git-2007-12-10/t/t4103-apply-binary.sh
--- git-2007-12-10_01/t/t4103-apply-binary.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4103-apply-binary.sh 2007-12-11 13:40:57 +0100
@@ -24,10 +24,10 @@ git update-index --add --remove file1 fi
git-commit -m 'Initial Version' 2>/dev/null
git-checkout -b binary
-tr 'x' '\0' <file1 >file3
+tr 'x' '\000' <file1 >file3
cat file3 >file4
git add file2
-tr '\0' 'v' <file3 >file1
+tr '\000' 'v' <file3 >file1
rm -f file2
git update-index --add --remove file1 file2 file3 file4
git-commit -m 'Second Version'
diff -pur git-2007-12-10_01/t/t4116-apply-reverse.sh git-2007-12-10/t/t4116-apply-reverse.sh
--- git-2007-12-10_01/t/t4116-apply-reverse.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4116-apply-reverse.sh 2007-12-11 13:42:13 +0100
@@ -12,14 +12,14 @@ test_description='git apply in reverse
test_expect_success setup '
for i in a b c d e f g h i j k l m n; do echo $i; done >file1 &&
- tr "[ijk]" '\''[\0\1\2]'\'' <file1 >file2 &&
+ tr "ijk" '\''\000\001\002'\'' <file1 >file2 &&
git add file1 file2 &&
git commit -m initial &&
git tag initial &&
for i in a b c g h i J K L m o n p q; do echo $i; done >file1 &&
- tr "[mon]" '\''[\0\1\2]'\'' <file1 >file2 &&
+ tr "mon" '\''\000\001\002'\'' <file1 >file2 &&
git commit -a -m second &&
git tag second &&
diff -pur git-2007-12-10_01/t/t4200-rerere.sh git-2007-12-10/t/t4200-rerere.sh
--- git-2007-12-10_01/t/t4200-rerere.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t4200-rerere.sh 2007-12-11 13:42:28 +0100
@@ -129,7 +129,7 @@ test_expect_success 'rerere kicked in' "
test_expect_success 'rerere prefers first change' 'git diff a1 expect'
rm $rr/postimage
-echo "$sha1 a1" | tr '\012' '\0' > .git/rr-cache/MERGE_RR
+echo "$sha1 a1" | tr '\012' '\000' > .git/rr-cache/MERGE_RR
test_expect_success 'rerere clear' 'git rerere clear'
diff -pur git-2007-12-10_01/t/t5300-pack-object.sh git-2007-12-10/t/t5300-pack-object.sh
--- git-2007-12-10_01/t/t5300-pack-object.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/t/t5300-pack-object.sh 2007-12-11 13:42:46 +0100
@@ -15,7 +15,7 @@ test_expect_success \
'rm -f .git/index*
for i in a b c
do
- dd if=/dev/zero bs=4k count=1 | tr "\\0" $i >$i &&
+ dd if=/dev/zero bs=4k count=1 | tr "\\000" $i >$i &&
git update-index --add $i || return 1
done &&
cat c >d && echo foo >>d && git update-index --add d &&
diff -pur git-2007-12-10_01/test-sha1.sh git-2007-12-10/test-sha1.sh
--- git-2007-12-10_01/test-sha1.sh 2007-12-09 10:23:48 +0100
+++ git-2007-12-10/test-sha1.sh 2007-12-11 13:39:29 +0100
@@ -10,7 +10,7 @@ do
{
test -z "$pfx" || echo "$pfx"
dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
- tr '[\0]' '[g]'
+ tr '\000' 'g'
} | ./test-sha1 $cnt
`
if test "$expect" = "$actual"
@@ -55,7 +55,7 @@ do
{
test -z "$pfx" || echo "$pfx"
dd if=/dev/zero bs=1048576 count=$cnt 2>/dev/null |
- tr '[\0]' '[g]'
+ tr '\000' 'g'
} | sha1sum |
sed -e 's/ .*//'
`
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: H.Merijn Brand @ 2007-12-17 22:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x3t6nq1.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Dec 2007 13:00:22 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> "H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
>
> > HP-UX does not have select.h, but it offers all select () functionality.
> > The defines are in <sys/types.h> and <X11/fd.h>
>
> Will apply the patch as-is for now, only because I do not want major
> surgery during rc period, but I think is can be improved.
Probably. but there is so much to be improved :)
> POSIX.1-2001 expects <sys/select.h> declares select(2). With earlier
> standards, including <sys/time.h>, <sys/types.h> and <unistd.h> would
> have given it.
Those three are there. I have 10.20 through 11.23 on PA-RISC and
11.23 on Itanium 2.
10.20, 11.00, and 11.11 (11i v1) do not have sys/select.h. 11.23 and
on do have it. The problem for now is that git on HP-UX does not build
with HP's C-ANSI-C compiler. I need to use gcc. Up to and including
11.11, I cannot use 4.x, as that has serious problems when used in 64bit
mode, so I'm stuck with gcc-3.4.6
> HP-UX cannot be the only pre-POSIX system; "#ifndef _HPUX_SOURCE" feels
> very wrong.
HP-UX 11.23/IPC, which is rather recent, does include sys/select.h
I didn't sent my HP-UX patch yet for the Makefile, as that is still
very premature. It is OK for 11.00, but as I need 64bit on 11.23,
because I only have 64bit OpenSSL and other util libraries, the 32bit
addition would not work.
> Besides, isn't _HPUX_SOURCE a feature-test macro? Feature test macros
That is defined in GNU gcc. I did not pass it with -D...
> are for the application to define, and for the implementation (iow, the
> header files) to find out what set of names the application wants to
> see. You are making the application examine the symbol to see what
> implementation it is on, which feels backwards to me.
--
H.Merijn Brand Amsterdam Perl Mongers (http://amsterdam.pm.org/)
using & porting perl 5.6.2, 5.8.x, 5.10.x on HP-UX 10.20, 11.00, 11.11,
& 11.23, SuSE 10.1 & 10.2, AIX 5.2, and Cygwin. http://qa.perl.org
http://mirrors.develooper.com/hpux/ http://www.test-smoke.org
http://www.goldmark.org/jeff/stupid-disclaimers/
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-17 22:17 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Nicolas Pitre, Joel Becker, Jakub Narebski, git
In-Reply-To: <20071217215709.GH13515@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
>> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
>>
>> > By the way, just as a data point: I do keep some git repositories on
>> > NFS, and access them from multiple machines with different git versions
>> > (not on purpose--it's just that the machines don't all run the same
>> > distro, so it'd be extra work to give them all the same version). I
>> > don't use anything older than 1.5.0. If the repository became unusable
>> > on one of those machines without warning it'd be annoying.
>>
>> What the v1.5.5 release notes will say is that you'll have to set
>> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
>
> Is there any reason not to make pack.indexversion=1 the default (for
> preexisting repositories at the very least) and suggest in the release
> notes that people set something else if they want the features the new
> version provides?
That's a judgement call.
Pack-idx format v2 is by design much safer in the face of bitflip (do we
have a test case to make sure this is indeed true?). But from the end
user's point of view, all the usual "I do not want to be forced to
update that old box I do not want to touch" applies.
And the people who needs to suffer from the dilemma are only the ones
who access a single repository across NFS with git from different
vintage. If that is a minority and/or tends to be more clueful people,
the inconvenience factor may be outweighed by the advantage v2 offers,
and pushing adoption of v2 harder the way Nico is driving at would
generally be a good thing.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-17 22:15 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071217215709.GH13515@fieldses.org>
On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> > On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> >
> > > By the way, just as a data point: I do keep some git repositories on
> > > NFS, and access them from multiple machines with different git versions
> > > (not on purpose--it's just that the machines don't all run the same
> > > distro, so it'd be extra work to give them all the same version). I
> > > don't use anything older than 1.5.0. If the repository became unusable
> > > on one of those machines without warning it'd be annoying.
> >
> > What the v1.5.5 release notes will say is that you'll have to set
> > pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
>
> Is there any reason not to make pack.indexversion=1 the default (for
> preexisting repositories at the very least) and suggest in the release
> notes that people set something else if they want the features the new
> version provides?
That's already the case now.
But the thing is that index version 2 is better and actually plug a flaw
in the repacking process where unnoticed corruption could be repacked
otherwise. So for better repo integrity sake, it has to become the
default at some point.
Nicolas
^ permalink raw reply
* "Argument list too long" in git remote update (Was: Git and GCC)
From: Geert Bosch @ 2007-12-17 22:15 UTC (permalink / raw)
To: Harvey Harrison; +Cc: Git Mailing List
In-Reply-To: <1197572755.898.15.camel@brick>
On Dec 13, 2007, at 14:05, Harvey Harrison wrote:
> After the discussions lately regarding the gcc svn mirror. I'm coming
> up with a recipe to set up your own git-svn mirror. Suggestions on
> the
> following.
>
> // Create directory and initialize git
> mkdir gcc
> cd gcc
> git init
> // add the remote site that currently mirrors gcc
> // I have chosen the name gcc.gnu.org *1* as my local name to refer to
> // this choose something else if you like
> git remote add gcc.gnu.org git://git.infradead.org/gcc.git
> // fetching someone else's remote branches is not a standard thing
> to do
> // so we'll need to edit our .git/config file
> // you should have a section that looks like:
> [remote "gcc.gnu.org"]
> url = git://git.infradead.org/gcc.git
> fetch = +refs/heads/*:refs/remotes/gcc.gnu.org/*
> // infradead's mirror puts the gcc svn branches in its own namespace
> // refs/remotes/gcc.gnu.org/*
> // change our fetch line accordingly
> [remote "gcc.gnu.org"]
> url = git://git.infradead.org/gcc.git
> fetch = +refs/remotes/gcc.gnu.org/*:refs/remotes/gcc.gnu.org/*
> // fetch the remote data from the mirror site
> git remote update
With git version 1.5.3.6 on Mac OS X, this results in:
potomac%:~/gcc%git remote update
Updating gcc.gnu.org
/opt/git/bin/git-fetch: line 220: /opt/git/bin/git: Argument list too
long
warning: no common commits
[after a long wait and a good amount of network traffic]
fatal: index-pack died of signal 13
fetch gcc.gnu.org: command returned error: 126
potomac%:~/gcc%
Any ideas on what to do to resolve this?
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: J. Bruce Fields @ 2007-12-17 21:57 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999999.0712171646230.8467@xanadu.home>
On Mon, Dec 17, 2007 at 04:52:16PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Dec 2007, J. Bruce Fields wrote:
>
> > By the way, just as a data point: I do keep some git repositories on
> > NFS, and access them from multiple machines with different git versions
> > (not on purpose--it's just that the machines don't all run the same
> > distro, so it'd be extra work to give them all the same version). I
> > don't use anything older than 1.5.0. If the repository became unusable
> > on one of those machines without warning it'd be annoying.
>
> What the v1.5.5 release notes will say is that you'll have to set
> pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
Is there any reason not to make pack.indexversion=1 the default (for
preexisting repositories at the very least) and suggest in the release
notes that people set something else if they want the features the new
version provides?
--b.
> And even if you forget about it then there'll be a simple way to regain
> compatibility after the facts.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-17 21:52 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Joel Becker, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071217213049.GG13515@fieldses.org>
On Mon, 17 Dec 2007, J. Bruce Fields wrote:
> By the way, just as a data point: I do keep some git repositories on
> NFS, and access them from multiple machines with different git versions
> (not on purpose--it's just that the machines don't all run the same
> distro, so it'd be extra work to give them all the same version). I
> don't use anything older than 1.5.0. If the repository became unusable
> on one of those machines without warning it'd be annoying.
What the v1.5.5 release notes will say is that you'll have to set
pack.indexversion=1 to remain compatible with pre-1.5.2 Git versions.
And even if you forget about it then there'll be a simple way to regain
compatibility after the facts.
Nicolas
^ permalink raw reply
* Re: What's in git.git (stable frozen)
From: Steffen Prohaska @ 2007-12-17 21:52 UTC (permalink / raw)
To: Git Mailing List, msysGit
In-Reply-To: <7vbq8v5n0u.fsf_-_@gitster.siamese.dyndns.org>
On Dec 13, 2007, at 3:47 AM, Junio C Hamano wrote:
> The tip of 'master' is now tagged as 1.5.4-rc0. Tarballs are found in
> the usual places:
A fresh msysgit self-contained Windows setup is available from
http://msysgit.googlecode.com/files/Git-1.5.4-rc0-preview20071217.exe
Steffen
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Nicolas Pitre @ 2007-12-17 21:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Joel Becker, Jakub Narebski, git
In-Reply-To: <7v3au16myj.fsf@gitster.siamese.dyndns.org>
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> This is mostly spilt milk under the bridge now, but I have to mildly
> disagree.
>
> If we had core.usedeltabaseoffset instead of repack.usedeltabaseoffset,
> and made the format negotiation in fetch-pack protocol pay attention to
> that variable, Joel's coworker did not have to suffer if the repository
> explicitly asked OFS_DELTA not to be used.
>
> Instead we unconditionally said "if you are downloading with the new
> client, we assume you would never be using older client to access that
> repository locally, if you did so, you are screwed."
>
> IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
> native protocol use offsets to delta base when possible) could have been
> a bit more careful in this respect.
Probably. But this can hardly be called a "corruption" since nothing
was actually lost, rather an incompatibility problem.
If, on the other hand, the latest Git version wasn't able to read it
either then this is a different matter entirely.
Nicolas
^ permalink raw reply
* Re: Windows binaries for qgit 2.0
From: Abdelrazak Younes @ 2007-12-17 21:40 UTC (permalink / raw)
To: Marco Costalba
Cc: Johannes Schindelin, msysgit-/JYPxA39Uh5TLH3MbocFFw,
git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <e5bfff550712171114i40a59b11md87038a3fc13d29c-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Marco Costalba wrote:
> On Dec 17, 2007 11:44 AM, Johannes Schindelin
> <Johannes.Schindelin-Mmb7MZpHnFY@public.gmane.org> wrote:
>
>> Why would anything that has to do with MSVC2005 be interesting to msysGit?
>> Note the "msys" part of "msysGit".
>>
>> FWIW a member of our team works on compiling/including qgit into msysGit.
>> But definitely not using closed-source compilers. I would violently
>> oppose that.
>>
>>
>
> I would (violently) agree with you, but I also violently oppose to
> waste a week end fighting with Qt4 + mingw compilation. MSVC2005 is
> needed as a kind of "debug tool" to better understand if the problem
> is with Qt4 or with mingw (as I suspect).
>
> Abdel is very kind to try to help in caming out with a qgit.exe more
> or less ready to be packaged. I'm not opposed, in this phase, to
> follow different _technically_ sound paths. Then when the dust settles
> down we could do our consideration regarding open source, in which I
> belive very firmly, so firmly that I'm not scared to _test_ different
> ways if this can be useful to shed some light on this issue.
>
If you allow me to share my experience in the LyX project WRT mingw/msys
versus MSVC: We tried very hard to use it, but at the end we faced many
issues, so many issues that MSVC was the only pragmatic choice:
- autotools hell with msys: the automake version was simply too old and
we had to mix cygwin and msys environment to get something done.
- linker hell: more than 500 megs of RAM was needed to link LyX with
Qt3, the situation was better with Qt4 but still.
- compilation slowness. Mingw is just not good with C++.
- binary slowness: this is less of a problem with Qt4 but still, the
MSVC compiled LyX is much faster.
In conclusion, I guess C-compilation is fine with Mingw and you should
definitly stay with it for git, but for a heavy GUI oriented C++ program
I strongly recommend MSVC.
Abdel.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: J. Bruce Fields @ 2007-12-17 21:30 UTC (permalink / raw)
To: Joel Becker; +Cc: Nicolas Pitre, Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071217211317.GC19816@mail.oracle.com>
On Mon, Dec 17, 2007 at 01:13:18PM -0800, Joel Becker wrote:
> Sure, we're not complaining about that. We complain some about
> the fast pace (at the time he had his problem, 1.4 installs were not
> unusual, and Junio's response suggested that "I use NFS" wasn't strongly
> considered as a use case), but more we complain about the obscurity of
> the reason. If it's obvious what happened (not the specifics, just
> "please upgrade" or "repository format changed" or something), the user
> moves along.
By the way, just as a data point: I do keep some git repositories on
NFS, and access them from multiple machines with different git versions
(not on purpose--it's just that the machines don't all run the same
distro, so it'd be extra work to give them all the same version). I
don't use anything older than 1.5.0. If the repository became unusable
on one of those machines without warning it'd be annoying.
---b.
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Junio C Hamano @ 2007-12-17 21:27 UTC (permalink / raw)
To: Jeff King; +Cc: Joe Perches, J. Bruce Fields, git
In-Reply-To: <20071217205134.GB2105@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Ah. The problem is that git-send-email unconditionally adds a
> message-id. Usually git-format-patch doesn't add one, but for obvious
> reasons, it must when doing --thread. Here is a fix.
> diff --git a/git-send-email.perl b/git-send-email.perl
> index 1d6f466..083466a 100755
> --- a/git-send-email.perl
> +++ b/git-send-email.perl
> @@ -580,7 +580,7 @@ sub send_message
> $ccline = "\nCc: $cc";
> }
> my $sanitized_sender = sanitize_address($sender);
> - make_message_id();
> + make_message_id() unless defined($message_id);
Isn't this called inside a loop? If the outgoing message does not
originally have "Message-Id:", does the loop correctly reinitialize
$message_id to undef, or does this change make everybody reuse the same
$message_id over and over again?
I have a feeling that --thread to format-patch is a misfeature. Why is
it needed if you are feeding the output to send-email?
I wonder if stripping existing "Message-Id:" away just like we strip
away "Date:" from @xh would be a much saner fix.
^ permalink raw reply
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Pierre Habouzit @ 2007-12-17 21:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071217205355.GC2105@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 875 bytes --]
On Mon, Dec 17, 2007 at 08:53:55PM +0000, Jeff King wrote:
> On Mon, Dec 17, 2007 at 12:42:51PM -0800, Junio C Hamano wrote:
>
> > You forgot one case.
> >
> > 4. Everybody who does _not_ know that we traditionally did not
> > support the form would expect "--abbrev 10" and "-n 4" to work.
>
> I would expect "-n 4" to work, but not "--abbrev 10". But perhaps that
> is just me. If that is the expectation, I think the behavior you
> outlined is sensible.
FWIW that's exactly the opposite for me. -n4 is easy to type, and I
always do that. Though on a keyboard, ' ' is under the thumb, '=' is
harder to catch, so I tend to prefer when CLIs don't force me to use =.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Joel Becker @ 2007-12-17 21:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999999.0712171517320.8467@xanadu.home>
On Mon, Dec 17, 2007 at 03:41:24PM -0500, Nicolas Pitre wrote:
> On Mon, 17 Dec 2007, Joel Becker wrote:
> > You may not see a case for actual corruptions, but my coworker
> > updated his tree on a box with 1.5.x, then tried to work on a box with
> > 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
> > unusable. He had to re-clone, and I think he got lucky recovering
> > pending changes (probably using 1.5.x on the branches with the changes,
> > as master was what got broken).
>
> I still claim that there wasn't any corruptions.
>
> Just for fun, just edit some document with Microsoft Office 95, then
> open the same document with Office 2007 and save it with default
> settings. Now try to open it back with Office 95. It won't work.
> Does that mean that the document got corrupted?
No, but when you try to re-open it with Office 2007, you expect
it to work, don't you? His master was messed up even for 1.5.x. It was
now months ago, so I don't quite remember all the details, but I think
you'd agree that "1.5.x no longer works" is not correct.
> I'm telling you that there won't be any such corruption. Just like in
> the M$ Office case, it is expected that newer versions make data
> unusable by older versions at some point -- that's the inevitable side
> effect of progress.
Sure, we're not complaining about that. We complain some about
the fast pace (at the time he had his problem, 1.4 installs were not
unusual, and Junio's response suggested that "I use NFS" wasn't strongly
considered as a use case), but more we complain about the obscurity of
the reason. If it's obvious what happened (not the specifics, just
"please upgrade" or "repository format changed" or something), the user
moves along.
> And we cannot always anticipate what kind of incompatibility will be
> worth making in the future, so it is hard to come with proper error
> messages in all cases today.
How hard is it? We have core.repositoryformatversion. We
undoubtably have headers on our files. As an example, an older version
should be able to ascertain 1) this is a pack file 2) I don't know how
to read it. Thus, it should always be able to tell the user as such.
This is different from reporting "invalid pack file" or "corrupt pack
file", or "garbage in tree". Filesystems, as an example, set
compatibility bits or version levels. When an old kernel tries to mount
it, it does not say "corrupt filesystem", it says "this filesystem has a
feature I don't understand, I'm going to be nice and not do anything,
please upgrade". This is clear, even though the older kernel doesn't
have any specifics about what the new feature is.
> So I don't see how we could do better in that regard. Carving the
> repository format in stone to keep ancient versions working forever is
> _not_ a solution.
Once again, we're not asking for that. We're asking that you
think ahead to what can change, and plan for it, so you can tell the
user. If the user has a clear idea where to go next, the can solve the
rest themselves.
Look, not everyone reads this mailing list. No one outside of
this list reads the Release Notes. They get their upgrade via yum or
apt-get, along with 100 other packages. You can't assume that 3 months
of feature discussion here is going to be known to your average user.
Joel
--
"Vote early and vote often."
- Al Capone
Joel Becker
Principal Software Developer
Oracle
E-mail: joel.becker@oracle.com
Phone: (650) 506-8127
^ permalink raw reply
* Re: Windows binaries for qgit 2.0
From: Abdelrazak Younes @ 2007-12-17 21:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, git, msysgit
In-Reply-To: <Pine.LNX.4.64.0712171911070.9446@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 17 Dec 2007, Marco Costalba wrote:
>
>
>> On Dec 17, 2007 10:51 AM, Abdelrazak Younes <younes.a@free.fr> wrote:
>>
>>> I would like to help you with that but I can't retrieve the repository:
>>>
>>> $ git clone git://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
>>> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
>>> git.kernel.org[0: 130.239.17.7]: errno=Invalid argument
>>> git.kernel.org[1: 199.6.1.166]: errno=Bad file descriptor
>>> git.kernel.org[2: 204.152.191.8]: errno=Bad file descriptor
>>> git.kernel.org[3: 204.152.191.40]: errno=Bad file descriptor
>>> fatal: unable to connect a socket (Bad file descriptor)
>>> fetch-pack from 'git://git.kernel.org/pub/scm/qgit/qgit4.git' failed.
>>>
>
> This looks familiar. It happens when there was no response to the 4 IPs
> of git.kernel.org. This might be due to a firewall which blocks git://
>
Yes, I guess this is the issue. I'll try from home now and report back.
In any case I managed to clone the qgit4 repository from
http://repo.or.cz/r/qgit4.git already so I can work from here.
Abdel.
^ permalink raw reply
* Re: Windows binaries for qgit 2.0
From: Abdelrazak Younes @ 2007-12-17 21:20 UTC (permalink / raw)
To: Marco Costalba; +Cc: git-u79uwXL29TY76Z2rM5mHXA, msysgit-/JYPxA39Uh5TLH3MbocFFw
In-Reply-To: <e5bfff550712171105k62b90853w1c5eed64bd11fb23-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Marco Costalba wrote:
> On Dec 17, 2007 10:51 AM, Abdelrazak Younes <younes.a-GANU6spQydw@public.gmane.org> wrote:
>
>> $ git clone http://git.kernel.org/pub/scm/qgit/qgit4.git qgit4.git
>> Initialized empty Git repository in d:/devel/git/qgit4/qgit4.git/.git/
>> Cannot get remote repository information.
>> Perhaps git-update-server-info needs to be run there?
>>
>>
>
> Well, perhaps, but to clone with git protocol you don't need that.
>
Just for clarification, this is not my question, this is git asking.
Abdel.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Junio C Hamano @ 2007-12-17 21:16 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Joel Becker, Jakub Narebski, git
In-Reply-To: <alpine.LFD.0.999999.0712171517320.8467@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Mon, 17 Dec 2007, Joel Becker wrote:
>
>> You may not see a case for actual corruptions, but my coworker
>> updated his tree on a box with 1.5.x, then tried to work on a box with
>> 1.4.x (I think 1.4.2 back then), and ended up with a tree that was
>> unusable. He had to re-clone, and I think he got lucky recovering
>> pending changes (probably using 1.5.x on the branches with the changes,
>> as master was what got broken).
>
> I still claim that there wasn't any corruptions.
> ...
> Your allegation of corruptions is cavalier just as well.
>
> I'm telling you that there won't be any such corruption. Just like in
> the M$ Office case, it is expected that newer versions make data
> unusable by older versions at some point -- that's the inevitable side
> effect of progress.
This is mostly spilt milk under the bridge now, but I have to mildly
disagree.
If we had core.usedeltabaseoffset instead of repack.usedeltabaseoffset,
and made the format negotiation in fetch-pack protocol pay attention to
that variable, Joel's coworker did not have to suffer if the repository
explicitly asked OFS_DELTA not to be used.
Instead we unconditionally said "if you are downloading with the new
client, we assume you would never be using older client to access that
repository locally, if you did so, you are screwed."
IOW, I think e4fe4b8ef7cdde842a9e5e2594d0fba1367d9dd3 (let the GIT
native protocol use offsets to delta base when possible) could have been
a bit more careful in this respect.
^ permalink raw reply
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Pierre Habouzit @ 2007-12-17 21:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vy7bt6qv6.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1776 bytes --]
On Mon, Dec 17, 2007 at 07:52:29PM +0000, Junio C Hamano wrote:
> Pierre Habouzit <madcoder@debian.org> writes:
>
> > After having written this mail 4 time already, I came up with an idea I
> > kind of like: like find, we could make {} be a placeholder for the
> > "default" argument. For example:
> >
> > $ git foo --abbrev {} 10
> > $ git log -M {} 1
> > ...
> >
> > {} would have the same semantics as your --long-opt-default. It tells the
> > option parser that "no there isn't anything to grok for that command thank you
> > very much". Of course if for some reason you really want to pass "{}" to the
> > command, the stuck form holds:
> >
> > $ git foo --long-opt={}
> > $ git foo -o{}
> >
> > What do you think ?
>
> 1. {} means a completely different thing to find ("place the real value
> here"); there is no similarity. I would strongly oppose to it. If
okay we could make it be '_', but …
> you want to invoke opt with default but still want to pass "{}" as an
> argument unrelated to that opt, you would do "--opt={} {}". That's
> double ugly.
Actually that would be --opt {} {} (or --opt _ _) and indeed it's not
very nice (euphemism for it sucks hard).
I like the *-default idea a lot, but it's not really useful if we cannot
fix the single letter switches at the same time. I had the idea to use !
(or any other less shell-magical char) like this: --abbrev! but it
doesn't fly a lot better for single letter switches.
Well maybe it's not worth fighting any longer, we should stick to the
stuck form then :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH w/ test] rebase -p -i: handle "no changes" gracefully
From: Johannes Schindelin @ 2007-12-17 21:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pieter de Bie, Johannes Sixt, git
In-Reply-To: <7vprx56pfn.fsf@gitster.siamese.dyndns.org>
Since commit 376ccb8cbb453343998e734d8a1ce79f57a4e092, unchanged
SHA-1s are no longer mapped via $REWRITTEN. But the updating
phase was not prepared for the old head not being rewritten.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Mon, 17 Dec 2007, Junio C Hamano wrote:
> Hmph, care to add a test to t3404?
How about this?
git-rebase--interactive.sh | 7 ++++++-
t/t3404-rebase-interactive.sh | 6 ++++++
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index f83e00f..cd7e43f 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -322,7 +322,12 @@ do_next () {
test -f "$DOTEST"/current-commit &&
current_commit=$(cat "$DOTEST"/current-commit) &&
git rev-parse HEAD > "$REWRITTEN"/$current_commit
- NEWHEAD=$(cat "$REWRITTEN"/$OLDHEAD)
+ if test -f "$REWRITTEN"/$OLDHEAD
+ then
+ NEWHEAD=$(cat "$REWRITTEN"/$OLDHEAD)
+ else
+ NEWHEAD=$OLDHEAD
+ fi
else
NEWHEAD=$(git rev-parse HEAD)
fi &&
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index 907c7f9..74a7eb3 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -184,6 +184,12 @@ test_expect_success 'retain authorship when squashing' '
git show HEAD | grep "^Author: Twerp Snog"
'
+test_expect_success '-p handles "no changes" gracefully' '
+ HEAD=$(git rev-parse HEAD) &&
+ git rebase -i -p HEAD^ &&
+ test $HEAD = $(git rev-parse HEAD)
+'
+
test_expect_success 'preserve merges with -p' '
git checkout -b to-be-preserved master^ &&
: > unrelated-file &&
--
1.5.4.rc0.59.g1d10d
^ permalink raw reply related
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Pierre Habouzit @ 2007-12-17 21:01 UTC (permalink / raw)
To: Jeff King, Junio C Hamano, git
In-Reply-To: <20071217204204.GA13004@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 1189 bytes --]
On Mon, Dec 17, 2007 at 08:42:04PM +0000, Pierre Habouzit wrote:
> On Mon, Dec 17, 2007 at 08:31:43PM +0000, Jeff King wrote:
> > On Mon, Dec 17, 2007 at 11:52:29AM -0800, Junio C Hamano wrote:
> >
> > > So in short, for an option that takes optional option-argument:
> >
> > I agree with everything you said, except...
> >
> > > - if it is given as "--long-name", and there is a next word, see if
> > > that is plausible as its argument. Get it and signal the caller
> > > you consumed it, if it is. Ignore it and signal the caller you
> > > didn't, if it isn't.
> >
> > This "plausible" makes me a little nervous, and I wonder why we want to
> > support this at all. Is it
> >
> > 1. We have traditionally supported "--abbrev 10"? I don't think this
> > is the case.
>
> Yes, that's why the restriction bugs me a bit too.
Err I misread your point, _yes_ we do, see builtin-show-ref.c, or see
--start-number in builtin-log.c. There is a precedent.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] HP-UX does not have select.h
From: Junio C Hamano @ 2007-12-17 21:00 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20071217192306.5da48540@pc09.procura.nl>
"H.Merijn Brand" <h.m.brand@xs4all.nl> writes:
> HP-UX does not have select.h, but it offers all select () functionality.
> The defines are in <sys/types.h> and <X11/fd.h>
Will apply the patch as-is for now, only because I do not want major
surgery during rc period, but I think is can be improved.
POSIX.1-2001 expects <sys/select.h> declares select(2). With earlier
standards, including <sys/time.h>, <sys/types.h> and <unistd.h> would
have given it.
HP-UX cannot be the only pre-POSIX system; "#ifndef _HPUX_SOURCE" feels
very wrong.
Besides, isn't _HPUX_SOURCE a feature-test macro? Feature test macros
are for the application to define, and for the implementation (iow, the
header files) to find out what set of names the application wants to
see. You are making the application examine the symbol to see what
implementation it is on, which feels backwards to me.
^ permalink raw reply
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Jeff King @ 2007-12-17 20:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vhcih6oj8.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 17, 2007 at 12:42:51PM -0800, Junio C Hamano wrote:
> You forgot one case.
>
> 4. Everybody who does _not_ know that we traditionally did not
> support the form would expect "--abbrev 10" and "-n 4" to work.
I would expect "-n 4" to work, but not "--abbrev 10". But perhaps that
is just me. If that is the expectation, I think the behavior you
outlined is sensible.
-Peff
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Jeff King @ 2007-12-17 20:51 UTC (permalink / raw)
To: Joe Perches; +Cc: Junio C Hamano, J. Bruce Fields, git
In-Reply-To: <1197922971.27386.32.camel@localhost>
On Mon, Dec 17, 2007 at 12:22:51PM -0800, Joe Perches wrote:
> $ let count=0 ; for line in $(cat patch_order) ; do ((count++)); \
> printf -v tmp "%04u-Spelling-%s" $count $line ; \
> tmp=${tmp//\//-} ; tmp=${tmp// /}; \
> git-format-patch -N --thread --start-number $count -s \
> -o patch3 \
> --subject-prefix="[PATCH] Spelling: $line" master $line ; done
> [converted the subjects appropriately]
> $ git-send-email --smtp-server <foo> --smtp-user <bar> \
> --from "Joe Perches <joe@perches.com>" \
> --to "linux-kernel@vger.kernel.org" \
> --cc "Andrew Morton <akpm@linux-foundation.org>" \
> --cc-cmd "../get_maintainer.pl --nogit" \
> --no-thread --suppress-from patch3
Ah. The problem is that git-send-email unconditionally adds a
message-id. Usually git-format-patch doesn't add one, but for obvious
reasons, it must when doing --thread. Here is a fix.
-- >8 --
git-send-email: avoid duplicate message-ids
We used to unconditionally add a message-id to the outgoing
email without bothering to check if it already had one.
Instead, let's use the existing one.
Signed-off-by: Jeff King <peff@peff.net>
---
It will also happily add duplicate --in-reply-to and --references
headers, but those can be suppressed with --no-thread. Arguably, it
should detect this case and turn on --no-thread, but looking at
git-send-email makes me want to claw my eyes out.
git-send-email.perl | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/git-send-email.perl b/git-send-email.perl
index 1d6f466..083466a 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -580,7 +580,7 @@ sub send_message
$ccline = "\nCc: $cc";
}
my $sanitized_sender = sanitize_address($sender);
- make_message_id();
+ make_message_id() unless defined($message_id);
my $header = "From: $sanitized_sender
To: $to${ccline}
@@ -718,6 +718,9 @@ foreach my $t (@files) {
}
push @xh, $_;
}
+ elsif (/^Message-Id: (.*)/i) {
+ $message_id = $1;
+ }
elsif (!/^Date:\s/ && /^[-A-Za-z]+:\s+\S/) {
push @xh, $_;
}
--
1.5.4.rc0.1146.gc97f-dirty
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox