* 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
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Junio C Hamano @ 2007-12-17 20:42 UTC (permalink / raw)
To: Jeff King; +Cc: Pierre Habouzit, git
In-Reply-To: <20071217203143.GA2105@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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.
> 2. Consistency with "--non-optional-arg foo"? Do we have any such
> non-optional long arguments? I didn't see any; I think we stick
> with --non-optional-arg=foo everywhere.
> 3. More convenience to the user? I don't see how " " is easier than
> "=".
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.
^ permalink raw reply
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Pierre Habouzit @ 2007-12-17 20:42 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071217203143.GA2105@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 2324 bytes --]
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.
> 2. Consistency with "--non-optional-arg foo"? Do we have any such
> non-optional long arguments? I didn't see any; I think we stick
> with --non-optional-arg=foo everywhere.
there are some, I don't recall the exact commands, but option parsing
was quite inconsistent in git (well still is), there are the very simple
loops that just do strcmp and look for the '=', there are the loops that
allow interleaving of options and arguments (and that rewrite argc/argv
a bit like parseopt does) and also the ones that allow the separate
mode, and the one that do both.
The force-stick-mode is a regression for them.
> > - if it is given as "-s", and there is a next word, and if the option
> > has long format counterpart as well, then see if the next word 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.
>
> Similarly, what is the goal here?
>
> 1. Have we ever supported "-s foo"? Not for -B/-M/-C, nor for
> shortlog's -w.
Yes for git tag -n for example, and there are some other
examples, look at maint for commands that have been migrated to
parse_options, some behave like that, and more than one for sure.
> 3. It's longer to type.
It's way more readable, but YMMV.
--
·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: Nicolas Pitre @ 2007-12-17 20:41 UTC (permalink / raw)
To: Joel Becker; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <20071217200920.GB19816@mail.oracle.com>
On Mon, 17 Dec 2007, Joel Becker wrote:
> On Fri, Dec 14, 2007 at 09:23:38PM -0500, Nicolas Pitre wrote:
> > On Fri, 14 Dec 2007, Joel Becker wrote:
> > > The relevant message is:
> > >
> > > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
> > >
> > > See the paragraphs at the bottom. The thread, started by me, begins
> > > with:
> > >
> > > Message-ID: <20070910205429.GE27837@tasint.org>
> >
> > OK. From those emails Junio forwarded to me, I don't see any case for
> > actual _corruptions_. Git does indeed refuse to work with unknown pack
> > index or unknown objects in a pack. Really old versions were not overly
> > clueful as to why they refused to work, but they should never corrupt a
> > pack which, for all purposes, is always read-only anyway.
>
> 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?
> My point is not that change is always bad, but that we should
> really look forward to what we're doing, and that "it's in the release
> notes" is not sufficient if an older git gives an incomprehensible error
> or a silent problem. I was responding to the cavalier statement "well,
> it's in the release notes, so don't worry about older versions".
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.
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.
Recent enough Git versions do suggest upgrading when they refuse to
access repositories though, and later Git versions can be configured to
remain compatible with old Git versions. And we also document it.
And when you still cannot figure it out on your own, then there is that
free support available on a public mailing list, and even an IRC
channel.
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.
Nicolas
^ permalink raw reply
* Re: [PATCH] builtin-tag: fix fallouts from recent parsopt restriction.
From: Jeff King @ 2007-12-17 20:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vy7bt6qv6.fsf@gitster.siamese.dyndns.org>
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.
2. Consistency with "--non-optional-arg foo"? Do we have any such
non-optional long arguments? I didn't see any; I think we stick
with --non-optional-arg=foo everywhere.
3. More convenience to the user? I don't see how " " is easier than
"=".
> - if it is given as "-s", and there is a next word, and if the option
> has long format counterpart as well, then see if the next word 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.
Similarly, what is the goal here?
1. Have we ever supported "-s foo"? Not for -B/-M/-C, nor for
shortlog's -w.
2. This would add consistency to non-optional arguments.
3. It's longer to type.
So I see a slight case for "-s foo", but none at all for "--long foo".
-Peff
^ permalink raw reply
* Re: [PATCH] the use of 'tr' in the test suite isn't really portable
From: Junio C Hamano @ 2007-12-17 20:25 UTC (permalink / raw)
To: H.Merijn Brand; +Cc: git
In-Reply-To: <20071217191508.79cc05e2@pc09.procura.nl>
The contents looked correct but the patch was garbled.
--
Applying the use of 'tr' in the test suite isn't really portable
.dotest/patch:11: indent with spaces.
git diff-index -r $commit | cut -f 2- | tr '\n' '\000' | \
.dotest/patch:153: indent with spaces.
dd if=/dev/zero bs=4k count=1 | tr "\\000" $i >$i &&
.dotest/patch:165: indent with spaces.
tr '\000' 'g'
.dotest/patch:174: indent with spaces.
tr '\000' 'g'
error: patch failed: git-filter-branch.sh:290
error: git-filter-branch.sh: patch does not apply
error: patch failed: t/t0020-crlf.sh:5
error: t/t0020-crlf.sh: patch does not apply
error: patch failed: t/t3300-funny-names.sh:54
error: t/t3300-funny-names.sh: patch does not apply
error: patch failed: t/t4020-diff-external.sh:99
error: t/t4020-diff-external.sh: patch does not apply
error: patch failed: t/t4116-apply-reverse.sh:12
error: t/t4116-apply-reverse.sh: patch does not apply
error: patch failed: t/t4200-rerere.sh:129
error: t/t4200-rerere.sh: patch does not apply
error: patch failed: t/t5300-pack-object.sh:15
error: t/t5300-pack-object.sh: patch does not apply
error: patch failed: test-sha1.sh:10
error: test-sha1.sh: patch does not apply
.dotest/patch:11: indent with spaces.
git diff-index -r $commit | cut -f 2- | tr '\n' '\000' | \
.dotest/patch:153: indent with spaces.
dd if=/dev/zero bs=4k count=1 | tr "\\000" $i >$i &&
.dotest/patch:165: indent with spaces.
tr '\000' 'g'
.dotest/patch:174: indent with spaces.
tr '\000' 'g'
^ permalink raw reply
* Re: [PATCH] rebase -p -i: handle "no changes" gracefully
From: Junio C Hamano @ 2007-12-17 20:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pieter de Bie, Johannes Sixt, git, gitster
In-Reply-To: <Pine.LNX.4.64.0712171649420.9446@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 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, Pieter de Bie wrote:
>
> > Ok, but what about the error in the rebase?
> >
> > On Dec 14, 2007, at 2:21 AM, Pieter de Bie wrote:
> > > Tirana:~/git pieter$ time git rebase -p -i HEAD~100
> > > cat:
> > > /Users/pieter/git/.git/.dotest-merge/rewritten/1e8df762b38e01685f3aa3613e2d61f73346fcbe:
> > > No such file or directory
>
> This buglet was not caught earlier, probably because a
> non-rewriting rebase is not really interesting ;-)
Hmph, care to add a test to t3404?
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: Joe Perches @ 2007-12-17 20:22 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20071217201219.GC13515@fieldses.org>
On Mon, 2007-12-17 at 15:12 -0500, J. Bruce Fields wrote:
> Hope you don't mind my cc'ing the git list:
Nope. Not a bit.
I had patches that were committed in word order that
I wanted to aggregate by subsystem.
I took all the patches, created a branch, committed
all the patches at once, then used these commands:
(patch_order is a directory list)
$ 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
I probably just reversed the "--thread" on
git-format-patch and send-email.
cheers, Joe
^ permalink raw reply
* Re: [PATCH 7/7] git-tag: fix -l switch handling regression.
From: Junio C Hamano @ 2007-12-17 20:13 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20071217190328.GF22554@artemis.madism.org>
Pierre Habouzit <madcoder@debian.org> writes:
> On Mon, Dec 17, 2007 at 06:56:52PM +0000, Pierre Habouzit wrote:
>> And I managed to resend the broken version, hurray myself.
>>
>> > + OPT_INTEGER('l', NULL, &list, "list tag names"),
>> OPT_BOOLEAN
>>
>>
>>
>> Both these last minute fixes are applied to my public git.git.
>>
>> Let's now write 1000 times: I will run the test-suite before I send
>> patches, I will rune the test-suite before I send patches, …
>
> oh and t7004 doesn't pass anymore because of the:
>
> git -n xxx -l or git -n "" -l tests. If we really want to allow that
> (but it _REALLY_ feels wrong to me) we have to make '-l' a callback that
> groks non integers as 0. Else the test also has to be fixed, I'm not
> sure what to do here.
I did not understand what "git tag -n xxx" was meant to do, either.
Time to run blame and ask the responsible party?
I suspect "-n ''" there might be meant as a way to spell the "no
argument here -- use our default" instruction. It looks slightly nicer
than that '{}' but not quite.
^ permalink raw reply
* Re: [PATCH] include/asm-arm/: Spelling fixes
From: J. Bruce Fields @ 2007-12-17 20:12 UTC (permalink / raw)
To: Joe Perches; +Cc: git
In-Reply-To: <1197921847.27386.16.camel@localhost>
Hope you don't mind my cc'ing the git list:
On Mon, Dec 17, 2007 at 12:04:07PM -0800, Joe Perches wrote:
> On Mon, 2007-12-17 at 14:56 -0500, J. Bruce Fields wrote:
> > My mail client seems to be flagging all your messages as duplicates of each
> > other.
> >
> > Hm. It may be that your headers have two Message-Id's...
> > Message-Id: <1197919875-5288-3-git-send-email-joe@perches.com>
> > X-Mailer: git-send-email 1.5.3.7.949.g2221a6
> > Message-Id:
> > <5703e57f925f31fc0eb38873bd7f10fc44f99cb4.1197918889.git.joe@perches.com
> > >
> >
> > ... the second of which is pretty weird (and is the same for every message. Is
> > that a git-send-email bug or something else?
>
> Dunno. I did a git-format-patch, then git-send-email.
Weird. Anyone know how that could happen?
--b.
^ permalink raw reply
* Re: [PATCH] provide advance warning of some future pack default changes
From: Joel Becker @ 2007-12-17 20:09 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jakub Narebski, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999999.0712142114400.8467@xanadu.home>
On Fri, Dec 14, 2007 at 09:23:38PM -0500, Nicolas Pitre wrote:
> On Fri, 14 Dec 2007, Joel Becker wrote:
> > The relevant message is:
> >
> > Message-ID: <7vveaindgp.fsf@gitster.siamese.dyndns.org>
> >
> > See the paragraphs at the bottom. The thread, started by me, begins
> > with:
> >
> > Message-ID: <20070910205429.GE27837@tasint.org>
>
> OK. From those emails Junio forwarded to me, I don't see any case for
> actual _corruptions_. Git does indeed refuse to work with unknown pack
> index or unknown objects in a pack. Really old versions were not overly
> clueful as to why they refused to work, but they should never corrupt a
> pack which, for all purposes, is always read-only anyway.
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).
My point is not that change is always bad, but that we should
really look forward to what we're doing, and that "it's in the release
notes" is not sufficient if an older git gives an incomprehensible error
or a silent problem. I was responding to the cavalier statement "well,
it's in the release notes, so don't worry about older versions".
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
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