* Re: git-format-patch possible regressions
From: Marco Costalba @ 2006-05-25 20:10 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605251233300.5623@g5.osdl.org>
On 5/25/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> The "x..y" format is defined to mean the same thing "y ^x", and that means
> that "HEAD^..HEAD HEAD^^..HEAD^" really does mean the same thing as
> "^HEAD^ ^HEAD^^ HEAD HEAD^", which in turn means the same thing as "^HEAD^
> HEAD" from a reachability standpoint (since HEAD^ is by definition
> reachable from HEAD, adding it won't change the revision list, and the
> same goes for ^HEAD^^ vs ^HEAD^).
>
> So thus "HEAD^..HEAD HEAD^^..HEAD^" really _is_ the same thing as
> "HEAD^..HEAD", and any tool that thought otherwise was just being
> very confused.
>
Perhaps I have chose the wrong example but it was _only_
instrumental in better explaing the regression.
The general problem is how to format patches files named with
consecutive numbers starting from a set of possible unrelated
revisions.
> Now, we could choose to try to make "a..b" mean something else (ie make
> the "^a" part only meaningful for that particular "sub-query"), and yes,
> in many ways that would be a more intuitive thing, but it's not how git
> revision descriptions work currently, and if we make that change we should
> do it across the board.
>
> (It's not an easy change to make, but it should be possible by having
> multiple separate NECESSARY/UNNECESSARY bits, and make the revision
> walking logic a whole lot more complicated than it already is).
>
> So I'd argue that you should really do something like
>
> ( git-rev-list a..b ; git-rev-list c..d ) |
> git-format-patch --stdin
>
> in qgit if you want the ranges to be truly independent.
>
> (And no, I don't think git-format-patch takes a "--stdin" argument, but it
> might not be unreasonable to add it as a generic revision walking
> argument for scripting like this).
>
To fix qgit problem could be enough to add/modify the option -nx to
make git-format-patch do not default with 0001 number but with x and
then simply call git-format-patch in a loop:
for(int i = 0; i <selectedRevisions.count(); i++)
git-format patch -n<i+1> selectedRevisions[i] ^selectedRevisions[i];
But of course it is clear your suggestion could be a solution for
much broader cases.
Marco
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Marco Costalba @ 2006-05-25 20:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vhd3dubd9.fsf@assigned-by-dhcp.cox.net>
> > Both regressions brake qgit. The first one is easy to fix (--signoff --> -s)
>
> I do not think -s does what you want. It means "do not generate
> diff" to the diff family, but format-patch overrides it and
> forces generating patch+stat output, so you do not see what it
> is doing.
>
Sorry, I was fooled by git-format-patch.txt documentation.
> > 2) Unhandled ranges list
> >
> > The second one is not so easy.
>
> This is a real regression; I was hoping Porcelain writers were
> paying attention of what are coming, but obviously the
> description in "What's in git.git" messages and discussion on
> the list were not detailed enough. My apologies.
>
Sorry also for this, normally I read "What's in git.git" but perhaps I
missed this.
>
> As an easy alternative, we could give --start-number=<n> to
> format-patch so that you can do the iteration yourself instead
> of having format-patch to iterate over the list.
>
>
You beat me for few minutes ;-)
Marco
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-25 20:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Eric W. Biederman, git
In-Reply-To: <Pine.LNX.4.64.0605251134410.5623@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Thu, 25 May 2006, Junio C Hamano wrote:
>>
>> With the limitation of the current tool, we could do:
>>
>> git-fetch master.kernel.org:/pub/scm/.../torvalds/linux-2.6.git \
>> refs/heads/master:refs/remotes/linus/master
>> git merge 'whatever merge message' HEAD b307e854
>>
>> assuming that b307e854 is reachable from your tip. So it might
>> be just a matter of giving a convenient shorthand to do the
>> above two commands, instead of mucking with upload-pack.
>
> It's not upload-pack that needs mucking with. It's simply "fetch-pack"
> that currently will refuse to say "want b307e854..", because the only
> thing it can do is say "want <headref>".
>
> So the patch would literally be to have a way to tell fetch-pack directly
> what you want, and not have the "only select from remote branches" logic.
So fixing fetch-pack is easy and pretty non-controversial.
The patch below handles that.
The problem is that I then run into the limitations in upload-pack.
(The movement of filter_refs may actually be overkill)
Eric
diff --git a/fetch-pack.c b/fetch-pack.c
index a3bcad0..c767d84 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -260,6 +260,27 @@ static void mark_recent_complete_commits
}
}
+static struct ref **get_sha1_heads(struct ref **refs, int nr_heads, char **head)
+{
+ int i;
+ for (i = 0; i < nr_heads; i++) {
+ struct ref *ref;
+ unsigned char sha1[20];
+ char *s = head[i];
+ int len = strlen(s);
+
+ if (len != 40 || get_sha1_hex(s, sha1))
+ continue;
+
+ ref = xcalloc(1, sizeof(*ref) + len + 1);
+ memcpy(ref->old_sha1, sha1, 20);
+ memcpy(ref->name, s, len + 1);
+ *refs = ref;
+ refs = &ref->next;
+ }
+ return refs;
+}
+
static void filter_refs(struct ref **refs, int nr_match, char **match)
{
struct ref *prev, *current, *next;
@@ -311,6 +332,8 @@ static int everything_local(struct ref *
if (cutoff)
mark_recent_complete_commits(cutoff);
+ filter_refs(refs, nr_match, match);
+
/*
* Mark all complete remote refs as common refs.
* Don't mark them common yet; the server has to be told so first.
@@ -329,8 +352,6 @@ static int everything_local(struct ref *
}
}
- filter_refs(refs, nr_match, match);
-
for (retval = 1, ref = *refs; ref ; ref = ref->next) {
const unsigned char *remote = ref->old_sha1;
unsigned char local[20];
@@ -373,6 +394,7 @@ static int fetch_pack(int fd[2], int nr_
packet_flush(fd[1]);
die("no matching remote head");
}
+ get_sha1_heads(&ref, nr_match, match);
if (everything_local(&ref, nr_match, match)) {
packet_flush(fd[1]);
goto all_done;
diff --git a/git-parse-remote.sh b/git-parse-remote.sh
index 187f088..2372df8 100755
--- a/git-parse-remote.sh
+++ b/git-parse-remote.sh
@@ -105,6 +105,7 @@ canon_refs_list_for_fetch () {
'') remote=HEAD ;;
refs/heads/* | refs/tags/* | refs/remotes/*) ;;
heads/* | tags/* | remotes/* ) remote="refs/$remote" ;;
+ [0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F][0-9a-fA-F]) ;;
*) remote="refs/heads/$remote" ;;
esac
case "$local" in
^ permalink raw reply related
* Re: [PATCH] Documentation/Makefile: remove extra /
From: Junio C Hamano @ 2006-05-25 20:45 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060525123746.GA14325@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> As both DESTDIR and the prefix are supposed to be absolute pathnames
> they can simply be concatenated without an extra / (like in the main Makefile).
> The extra slash may even break installation on Windows.
>
> Signed-off-by: Martin Waitz <tali@admingilde.org>
> ---
> Documentation/Makefile | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/Makefile b/Documentation/Makefile
> index 2a08f59..2b0efe7 100644
> --- a/Documentation/Makefile
> +++ b/Documentation/Makefile
> @@ -52,9 +52,9 @@ man1: $(DOC_MAN1)
> man7: $(DOC_MAN7)
>
> install: man
> - $(INSTALL) -d -m755 $(DESTDIR)/$(man1) $(DESTDIR)/$(man7)
> - $(INSTALL) $(DOC_MAN1) $(DESTDIR)/$(man1)
> - $(INSTALL) $(DOC_MAN7) $(DESTDIR)/$(man7)
> + $(INSTALL) -d -m755 $(DESTDIR)$(man1) $(DESTDIR)$(man7)
> + $(INSTALL) $(DOC_MAN1) $(DESTDIR)$(man1)
> + $(INSTALL) $(DOC_MAN7) $(DESTDIR)$(man7)
This unfortunately breaks a workaround I did in the main
Makefile for dist-doc target, but I agree it is a good change.
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Eric W. Biederman @ 2006-05-25 20:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v3beyuffg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Linus Torvalds <torvalds@osdl.org> writes:
>
>> On Thu, 25 May 2006, Eric W. Biederman wrote:
>>>
>>> My basic argument is that starting a pull with a commit that is not a
>>> reference is no worse than staring a pull from a broken repository. The
>>> same checks that protects us should work in either case.
>>
>> I think Junio reacted to the subject line, which was somewhat badly
>> phrased. You're not looking to transfer random objects, you're looking to
>> _start_ a branch at any arbitrary known point.
>
> I realize that now. From Eric's original message:
>
> To be accurate of his source Andrew records the sha1 of the commit
> and the git tree he pulled from. Which looks like:
>
> GIT b307e8548921c686d2eb948ca418ab2941876daa \
> git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>
> So I figured I would transform the above line into the obvious
> git-pull command:
>
> git-pull \
> git+ssh://master.kernel.org/pub/scm/.../torvalds/linux-2.6.git \
> b307e8548921c686d2eb948ca418ab2941876daa
>
> With the limitation of the current tool, we could do:
>
> git-fetch master.kernel.org:/pub/scm/.../torvalds/linux-2.6.git \
> refs/heads/master:refs/remotes/linus/master
> git merge 'whatever merge message' HEAD b307e854
>
> assuming that b307e854 is reachable from your tip. So it might
> be just a matter of giving a convenient shorthand to do the
> above two commands, instead of mucking with upload-pack.
If we conclude the fetch by sha1 path is not practical certainly.
There are a couple of problems with the just use the tool as
is approach.
- I don't know which branch I need to fetch.
Although it looks like Andrew has kept that information when it was not the
default branch so I can probably use that.
- Fetching a branch that I just want a subset of is wasteful.
- It feels really weird when everything else allows me to use sha1s
for git-fetch to deny them.
Then there is the big hole in my plan to get better changelog information
that it appears that after Andrew pulls a branch he resolves some
merge conflicts. If that is right I need to figure out how to address
that before I can improve git-quiltimport.sh.
To get a slightly better feel of the problem below is the complete list of git
trees that Andrew pulled in for 2.6.17-rc4-mm3.
Eric
GIT d684de2c4a498ec4edf4e6c3420b008c62be394c git+ssh://master.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git#test
GIT 34ec52e3356245e9a13dfcbc8460635e675f13cf git+ssh://master.kernel.org/pub/scm/linux/kernel/git/davej/agpgart.git
GIT 08e66777d094d93091a914a8746a9b93599e14a9 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/perex/alsa-current.git
GIT 0ef744735f0d82d90809935586a0d1043f7f09b5 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/audit-current.git#master.b13
GIT cca5d8ad1f58f188500b9fb12ba6d98643a4cf49 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#for-linus
GIT b3b6a155c2b85d436b192d74e459f837eab0944e git+ssh://master.kernel.org/pub/scm/linux/kernel/git/axboe/linux-2.6-block.git#cfq
GIT 8ba86486650c59f969c589c7d6c3dd4da734c75a git+ssh://master.kernel.org/pub/scm/linux/kernel/git/sfrench/cifs-2.6.git
GIT 2a1db55336a9e99f5dd7ee64e42fa4cbb509ea6a git+ssh://master.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git
GIT 639b4408a9e8e014878c7538859f33f852c23882 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git#devel
GIT d2f222e6310b073ae3d91b8d3d676621fae1314e git+ssh://master.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6.git
GIT 3ac6c7b44560fdf2ea8865536bd52d4ff038107e git://git.infradead.org/hdrcleanup-2.6.git
GIT 12415e45ab0429a88412f4af365515adbe0bdd68 git://git.infradead.org/hdrinstall-2.6.git
GIT 155f23d603727fcb2af6c69ff77b74d1d4eb5bde git+ssh://master.kernel.org/pub/scm/linux/kernel/git/aegl/linux-2.6.git#test
GIT ba9cfd16a13a932f0603a7f65b3881738a698ae1 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/roland/infiniband.git#for-mm
GIT 51d797474f87b375819d084f7583a2864c5656c4 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/intelfb-2.6#i915fb
GIT c32217fdc98292dbafd5f51d3f43337081b01c29 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/hpa/linux-2.6-klibc.git
GIT 9fe74aaa1dc55100d20d9b7be2ccbf84ad26ce84 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git#ALL
GIT 864fdc881dd9e0077f9ed11191055e3eabf3b2a5 git://www.linux-mips.org/pub/scm/upstream.git#for-akpm
GIT 0d25971d7c969debf76f9fab6d6b37cb62408f55 git://git.infradead.org/mtd-2.6.git
GIT b748b7167cbeb11e729c6f9c3472165903dd115e git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git#ALL
GIT c4bdea3ce8b1d9b9d8dc44223542b3ebbe3a3020 git://git.linux-nfs.org/pub/linux/nfs-2.6.git
GIT f8b4c6027275d9b2d5004726a6d1bb818a13ddef git://oss.oracle.com/home/sourcebo/git/ocfs2.git/#ALL
GIT 35b86edf75270176310cb9507745d8c02b9e6592 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git/
GIT 3c06da5ae5358e9d325d541a053e1059e9654bcc git+ssh://master.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git
GIT aa783a8f31c79f493bd49ba926b171b79b9839fb git://git.infradead.org/users/dwmw2/rbtree-2.6.git
GIT ee69d3f20b23250eae98a4cb20236196694f0b81 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jejb/aic94xx-sas-2.6.git
GIT 9f434d4f84a235f6b61aec6e691d6b07bc46fc24 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-rc-fixes-2.6.git
GIT 0df298d180556450cbe5edf12c1e890f6ac6ea97 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jejb/scsi-target-2.6.git
GIT f1d282724317895f73c4c182041ab4385126c026 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/jgarzik/misc-2.6.git#stex
GIT 19932e4d7d2002bc956d1636e1c3a1d4455049fa git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#frv.b14
GIT 6ea79eadeba9b0d0ab08dcf7ee16df13e1fdadae git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#m32r.b14
GIT c3d6ecc77e8e5d4ac82c3bf27ed02b8c0d83d41d git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#m68k.b14
GIT e7dd49b206624021c23a27512d2a31503f5207f2 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#upf.b14
GIT ea0d175136582dff6e3591368b1da472ef3870b8 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/viro/bird.git#volatile.b14
GIT b29527edccbbc53a908bc34a910df3601061c950 git+ssh://master.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git
GIT b307e8548921c686d2eb948ca418ab2941876daa git+ssh://master.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Junio C Hamano @ 2006-05-25 20:53 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m13bexetj1.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> So fixing fetch-pack is easy and pretty non-controversial.
> The patch below handles that.
I am at work so I cannot really spend time on this right now,
but I am OK with letting it send arbitrary SHA1 the caller
obtained out of band. I do not know about your implementation,
since I haven't really looked at it.
> (The movement of filter_refs may actually be overkill)
It may not just overkill but may actively be wrong, but again I
haven't looked at it yet.
Will take a look tonight.
^ permalink raw reply
* Re: [RFC][PATCH] Allow transfer of any valid sha1
From: Junio C Hamano @ 2006-05-25 21:04 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1y7wpde1w.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> - I don't know which branch I need to fetch.
As you say yourself Andrew marks which one he fetched from, so
this is a non-issue.
> - Fetching a branch that I just want a subset of is wasteful.
Generally this is true, but in practice and especially for this
particular application I do not think so. After all Andrew
pulled from the tip and got that tip, and IIUYC you are trying
to follow what Andrew did, so you'd be better doing this soon
after Andrew annouces the series, so your subset would be a
close to 100% subset. Otherwise you would have different
problem anyway -- the tree owner after seeing -mm tree has his
series may rewind and rebuild the branch in preparation of
feeding him with the next time around.
> - It feels really weird when everything else allows me to use sha1s
> for git-fetch to deny them.
That is a real argument and I am not opposed to change
fetch-pack to ask for an arbitrary SHA1 the caller obtained out
of band.
> Then there is the big hole in my plan to get better changelog information
> that it appears that after Andrew pulls a branch he resolves some
> merge conflicts. If that is right I need to figure out how to address
> that before I can improve git-quiltimport.sh.
The last time I talked with Andrew, he is not doing a merge nor
resolving merge conflicts. He treats git primarily as a
patchbomb distribution mechanism, and works on (a rough
equivalent of) the output of format-patch from merge base
between his base tree and individual subsystem tree. After that
things are normal quilt workflow outside git, whatever it is.
^ permalink raw reply
* Re: git-cvsserver wart?
From: Martin Langhoff @ 2006-05-25 21:19 UTC (permalink / raw)
To: Cameron McBride; +Cc: git
In-Reply-To: <dcedf5e20605250942g6a7417dfh5f2f26df29842def@mail.gmail.com>
On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> For reasons I won't go into, the ability to use cvs clients is darn
> near crucial. Although most development is local (where I install /
> use git), pulling down the latest updates and pushing up minor changes
> via CVS is helpful at remote locations where I don't want to maintain
> clients. Git with git-cvsserver makes this very nice. Thanks to
> all!
NP!
There's been some recent changes to cvsserver -- so version info is
crucial. What git version are you using? Can you try with the lastest
#master head from Junio? That's the latest and greatest...
If that doesn't fix it, can you post the logs? I think you have to
declare CVS_LOG=/tmp/cvslog or somesuch.
> code/ntropy> cvs -v
> Concurrent Versions System (CVS) 1.11.1p1 (client/server)
We've developed it testing against 1.12.9 from debian and 1.11.20 from
MacOSX/fink.
> so, it's an old client, a newer client doesn't have this problem. a
> bare 'cvs up' works fine on:
> Concurrent Versions System (CVS) 1.11.17 (client/server)
Ah! Then capturing the logs of the working and non-working clients,
and comparing them can probably help. Can you capture and post the
relevant parts of the log...?
> p.s. I'm assuming the following statement is harmless (it's always present):
> closing dbh with active statement handles
Yup. Harmless indeed. They way we are using prepared statements, I
don't know how to avoid it :-/ -- suggestions welcome.
cheers,
martin
^ permalink raw reply
* Re: bogus "fatal: Not a git repository"
From: Johannes Schindelin @ 2006-05-25 21:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0605250804390.5623@g5.osdl.org>
Hi,
On Thu, 25 May 2006, Linus Torvalds wrote:
> The reason is commit 73136b2e8a8ee024320c5ac6a0f14f912432bf03 by Dscho: it
> adds calls to git-repo-config in git-parse-remote.sh to get the remote
> shorthands etc.
Yes, I did not think of that special case. Sorry. If you need it, here is
Acked-By: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ciao,
Dscho
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Johannes Schindelin @ 2006-05-25 21:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git, Linus Torvalds
In-Reply-To: <7vhd3dubd9.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 25 May 2006, Junio C Hamano wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
> > 2) Unhandled ranges list
> >
> > The second one is not so easy.
>
> This is a real regression;
I was not aware of the possibility to specify several ranges, mostly
because I did not use it that way.
However, I think it is worth breaking this in that particular case, since
the range handling has become unified with the framework in revision.[ch]
> As an easy alternative, we could give --start-number=<n> to
> format-patch so that you can do the iteration yourself instead
> of having format-patch to iterate over the list.
Something like this?
---
[PATCH] format-patch: support --start-number=<n> (and --start-number <n>)
This option implicitely sets numbered mode and starts the numbering with <n>.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
builtin-log.c | 19 ++++++++++++++++---
1 files changed, 16 insertions(+), 3 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index c8feb0f..4e3388b 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -148,6 +148,7 @@ int cmd_format_patch(int argc, const cha
int nr = 0, total, i, j;
int use_stdout = 0;
int numbered = 0;
+ int start_number = -1;
int keep_subject = 0;
init_revisions(&rev);
@@ -171,7 +172,14 @@ int cmd_format_patch(int argc, const cha
else if (!strcmp(argv[i], "-n") ||
!strcmp(argv[i], "--numbered"))
numbered = 1;
- else if (!strcmp(argv[i], "-k") ||
+ else if (!strncmp(argv[i], "--start-number=", 15))
+ start_number = strtol(argv[i] + 15, NULL, 10);
+ else if (!strcmp(argv[i], "--start-number")) {
+ i++;
+ if (i == argc)
+ die("Need a number for --start-number");
+ start_number = strtol(argv[i], NULL, 10);
+ } else if (!strcmp(argv[i], "-k") ||
!strcmp(argv[i], "--keep-subject")) {
keep_subject = 1;
rev.total = -1;
@@ -193,6 +201,11 @@ int cmd_format_patch(int argc, const cha
}
argc = j;
+ if (start_number >= 0)
+ numbered = 1;
+ else if (numbered)
+ start_number = 1;
+
if (numbered && keep_subject < 0)
die ("-n and -k are mutually exclusive.");
@@ -219,11 +232,11 @@ int cmd_format_patch(int argc, const cha
}
total = nr;
if (numbered)
- rev.total = total;
+ rev.total = total + start_number - 1;
while (0 <= --nr) {
int shown;
commit = list[nr];
- rev.nr = total - nr;
+ rev.nr = rev.total - nr;
if (!use_stdout)
reopen_stdout(commit, rev.nr, keep_subject);
shown = log_tree_commit(&rev, commit);
--
1.3.3.gd515
^ permalink raw reply related
* Re: git-format-patch possible regressions
From: Johannes Schindelin @ 2006-05-25 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0605252338530.31700@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
On Thu, 25 May 2006, Johannes Schindelin wrote:
> @@ -193,6 +201,11 @@ int cmd_format_patch(int argc, const cha
> }
> argc = j;
>
> + if (start_number >= 0)
> + numbered = 1;
> + else if (numbered)
> + start_number = 1;
> +
> if (numbered && keep_subject < 0)
> die ("-n and -k are mutually exclusive.");
>
Thinking about this again, it makes more sense not to imply --numbered:
if (numbered && start_number < 0)
start_number = 1;
Ciao,
Dscho
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Junio C Hamano @ 2006-05-25 23:11 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Marco Costalba, git, Linus Torvalds
In-Reply-To: <Pine.LNX.4.63.0605260014340.13003@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Thinking about this again, it makes more sense not to imply --numbered:
Yes, that makes sense. That way you can say "Please start
naming the output files at 0032-xxxx.txt, because you gave me 31
patch series last time, but I do not want [PATCH x/y] on the
subject line, just [PATCH]".
That brings up another issue. Don't we need to have another
option --total-number that overrides the /y part above?
Hmm...
^ permalink raw reply
* Re: git-format-patch possible regressions
From: Johannes Schindelin @ 2006-05-25 23:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git, Linus Torvalds
In-Reply-To: <7vy7wpr97n.fsf@assigned-by-dhcp.cox.net>
Hi,
On Thu, 25 May 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Thinking about this again, it makes more sense not to imply --numbered:
>
> Yes, that makes sense. That way you can say "Please start
> naming the output files at 0032-xxxx.txt, because you gave me 31
> patch series last time, but I do not want [PATCH x/y] on the
> subject line, just [PATCH]".
>
> That brings up another issue. Don't we need to have another
> option --total-number that overrides the /y part above?
I thought about that, too. Isn't the --numbered only useful for submitting
a patch series via mail? And isn't it necessary to make certain that these
patches really apply in that order? Isn't it then sensible to force the
user to have a branch (at least a throw-away one) having exactly these
patches, just to make sure that the patches really, really apply in that
order?
If all that is true, then --start-number && --numbered does not make sense
at all.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Add instructions to commit template.
From: Martin Waitz @ 2006-05-25 23:42 UTC (permalink / raw)
To: git
New users can be irritated by the git status text in their editor.
Let's give them a short help.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
git-commit.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index 6785826..1983d45 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -626,6 +626,9 @@ fi
if test -z "$no_edit"
then
{
+ echo ""
+ echo "# Please enter the commit message for your changes."
+ echo "# (Comment lines starting with '#' will not be included)"
test -z "$only_include_assumed" || echo "$only_include_assumed"
run_status
} >>"$GIT_DIR"/COMMIT_EDITMSG
--
1.3.3.gc6dc-dirty
--
Martin Waitz
^ permalink raw reply related
* t8001-annotate.sh fails on Mac OS X
From: Stefan Pfetzing @ 2006-05-25 23:53 UTC (permalink / raw)
To: Git Mailing List
Hi,
for some reason I could not yet figure out, t8001-annotate.sh fails at test 18.
--- snip ---
* ok 17: some edit
* expecting success: check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
Author A (expected 1, attributed 1) good
Author B1 (expected 1, attributed 1) good
Author D (expected 1, attributed 2) bad
Author A U Thor (expected 1, attributed 1) good
Author B2 (expected 1, attributed 1) good
Author B (expected 1, attributed 1) good
* FAIL 18: some edit
check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
* failed 1 among 18 test(s)
--- snap ---
And git-annotate in the trash dir produces the following:
--- snip ---
5c085656 ( A 2006-05-25 23:13:26 +0000 1)lazy dog
3f3e26a3 ( B2 2006-05-25 23:13:29 +0000 2)4A
quick brown lazy dog fox jumps over the
3b509ebb ( B 2006-05-25 23:13:27 +0000 3)lazy dog
669d4e82 ( D 2006-05-25 23:13:35 +0000 4)99
slow green fox jumps into the
f96b8861 ( B1 2006-05-25 23:13:28 +0000 5)well.
a7bad43f ( A U Thor 2006-05-25 23:13:31 +0000 6)evil merge.
669d4e82 ( D 2006-05-25 23:13:35 +0000 7)incomplete
--- snap ---
The strange point is, git log is completely ok:
--- snip ---
commit 90ef4f653d6dc33d90ce826303563e5506d5ad31
Author: C <author@example.com>
Date: Thu May 25 23:13:34 2006 +0000
Incomplete
--- snap ---
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ permalink raw reply
* Re: [PATCH] cvsimport: introduce -L<imit> option to workaround memory leaks
From: Martin Langhoff @ 2006-05-26 0:42 UTC (permalink / raw)
To: Linus Torvalds
Cc: Martin Langhoff, Git Mailing List, Junio C Hamano,
Johannes.Schindelin, spyderous, smurf
In-Reply-To: <Pine.LNX.4.64.0605221926270.3697@g5.osdl.org>
On 5/23/06, Linus Torvalds <torvalds@osdl.org> wrote:
>
> This stupid patch on top of yours seems to make git happier. It's
> disgusting, I know, but it just repacks things every kilo-commit.
Call me slow, but I am still running and rerunning that gentoo import. ;-)
The current import has reached ~200K commits, and .git is 450MB, while
the checked out tree is 230MB (680MB with .git). At this stage, git
repack -a -d is too memory hungry. I just had to kill it after it took
2GB and was still growing fast. So I have dropped the -a in my test
import for the time being.
Other than that, we are doing ~6K commits per hour on a 2GB 2GHz Opteron.
cheers,
martin
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Shawn Pearce @ 2006-05-26 1:11 UTC (permalink / raw)
To: Stefan Pfetzing; +Cc: Git Mailing List
In-Reply-To: <f3d7535d0605251653m15db34f3j46403f4ed0c4c69f@mail.gmail.com>
Stefan Pfetzing <stefan.pfetzing@gmail.com> wrote:
> Hi,
>
> for some reason I could not yet figure out, t8001-annotate.sh fails at test
> 18.
>
> --- snip ---
> * ok 17: some edit
> * expecting success: check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
> Author A (expected 1, attributed 1) good
> Author B1 (expected 1, attributed 1) good
> Author D (expected 1, attributed 2) bad
> Author A U Thor (expected 1, attributed 1) good
> Author B2 (expected 1, attributed 1) good
> Author B (expected 1, attributed 1) good
> * FAIL 18: some edit
> check_count A 1 B 1 B1 1 B2 1 "A U Thor" 1 C 1 D 1
> * failed 1 among 18 test(s)
I've been seeing the same failed test case for a long time now on
my own Mac OS X system. I think it has to do with the "git blame"
vs. "git annotate" war which never really happened.
I think we had hoped that one of the two tools would prove to be
_the_ annotation/blame tool and would get used but thus far that
hasn't happened. Since they are two different implementations
they also differ slightly over how they attribute a change across
a merge, and in this case annotate is producing a different result
from blame - but that different result isn't considered to be wrong
so it hasn't been changed in annotate. Meanwhile the test has stayed
broken as a reminder that these two generate different results.
--
Shawn.
^ permalink raw reply
* [PATCH 1/4] t3300-funny-names: shell portability fixes
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu, Eric Wong
In-Reply-To: <1148609178788-git-send-email-normalperson@yhbt.net>
echo isn't remotely standardized for handling backslashes,
so cat + heredoc seems better
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t3300-funny-names.sh | 51 +++++++++++++++++++++++++++++++-----------------
1 files changed, 33 insertions(+), 18 deletions(-)
6b5ef54aa860b557f88084c1d642a611f7abcf4d
diff --git a/t/t3300-funny-names.sh b/t/t3300-funny-names.sh
index 72a93da..c12270e 100755
--- a/t/t3300-funny-names.sh
+++ b/t/t3300-funny-names.sh
@@ -40,9 +40,11 @@ test_expect_success 'git-ls-files no-fun
t0=`git-write-tree`
echo "$t0" >t0
-echo 'just space
+cat > expected <<\EOF
+just space
no-funny
-"tabs\t,\" (dq) and spaces"' >expected
+"tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-ls-files with-funny' \
'git-update-index --add "$p1" &&
git-ls-files >current &&
@@ -58,14 +60,18 @@ test_expect_success 'git-ls-files -z wit
t1=`git-write-tree`
echo "$t1" >t1
-echo 'just space
+cat > expected <<\EOF
+just space
no-funny
-"tabs\t,\" (dq) and spaces"' >expected
+"tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-ls-tree with funny' \
'git-ls-tree -r $t1 | sed -e "s/^[^ ]* //" >current &&
diff -u expected current'
-echo 'A "tabs\t,\" (dq) and spaces"' >expected
+cat > expected <<\EOF
+A "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-index with-funny' \
'git-diff-index --name-status $t0 >current &&
diff -u expected current'
@@ -84,53 +90,62 @@ test_expect_success 'git-diff-tree -z wi
'git-diff-tree -z --name-status $t0 $t1 | tr \\0 \\012 >current &&
diff -u expected current'
-echo 'CNUM no-funny "tabs\t,\" (dq) and spaces"' >expected
+cat > expected <<\EOF
+CNUM no-funny "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-tree -C with-funny' \
'git-diff-tree -C --find-copies-harder --name-status \
$t0 $t1 | sed -e 's/^C[0-9]*/CNUM/' >current &&
diff -u expected current'
-echo 'RNUM no-funny "tabs\t,\" (dq) and spaces"' >expected
+cat > expected <<\EOF
+RNUM no-funny "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-tree delete with-funny' \
'git-update-index --force-remove "$p0" &&
git-diff-index -M --name-status \
$t0 | sed -e 's/^R[0-9]*/RNUM/' >current &&
diff -u expected current'
-echo 'diff --git a/no-funny "b/tabs\t,\" (dq) and spaces"
+cat > expected <<\EOF
+diff --git a/no-funny "b/tabs\t,\" (dq) and spaces"
similarity index NUM%
rename from no-funny
-rename to "tabs\t,\" (dq) and spaces"' >expected
-
+rename to "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-tree delete with-funny' \
'git-diff-index -M -p $t0 |
sed -e "s/index [0-9]*%/index NUM%/" >current &&
diff -u expected current'
chmod +x "$p1"
-echo 'diff --git a/no-funny "b/tabs\t,\" (dq) and spaces"
+cat > expected <<\EOF
+diff --git a/no-funny "b/tabs\t,\" (dq) and spaces"
old mode 100644
new mode 100755
similarity index NUM%
rename from no-funny
-rename to "tabs\t,\" (dq) and spaces"' >expected
-
+rename to "tabs\t,\" (dq) and spaces"
+EOF
test_expect_success 'git-diff-tree delete with-funny' \
'git-diff-index -M -p $t0 |
sed -e "s/index [0-9]*%/index NUM%/" >current &&
diff -u expected current'
-echo >expected ' "tabs\t,\" (dq) and spaces"
- 1 files changed, 0 insertions(+), 0 deletions(-)'
+cat >expected <<\EOF
+ "tabs\t,\" (dq) and spaces"
+ 1 files changed, 0 insertions(+), 0 deletions(-)
+EOF
test_expect_success 'git-diff-tree rename with-funny applied' \
'git-diff-index -M -p $t0 |
git-apply --stat | sed -e "s/|.*//" -e "s/ *\$//" >current &&
diff -u expected current'
-echo >expected ' no-funny
+cat > expected <<\EOF
+ no-funny
"tabs\t,\" (dq) and spaces"
- 2 files changed, 3 insertions(+), 3 deletions(-)'
-
+ 2 files changed, 3 insertions(+), 3 deletions(-)
+EOF
test_expect_success 'git-diff-tree delete with-funny applied' \
'git-diff-index -p $t0 |
git-apply --stat | sed -e "s/|.*//" -e "s/ *\$//" >current &&
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH 3/4] t5500-fetch-pack: remove local (bashism) usage.
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu, Eric Wong
In-Reply-To: <11486091783808-git-send-email-normalperson@yhbt.net>
None of the variables seem to conflict, so local was unnecessary.
Also replaced ${var:pos:len} with the sed equivalent.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t5500-fetch-pack.sh | 30 +++++++++++++++---------------
1 files changed, 15 insertions(+), 15 deletions(-)
62f64e95d24f90e61af0fa42d88300e41f60c277
diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
index 92f12d9..f7625a6 100755
--- a/t/t5500-fetch-pack.sh
+++ b/t/t5500-fetch-pack.sh
@@ -12,11 +12,11 @@ # Test fetch-pack/upload-pack pair.
# Some convenience functions
-function add () {
- local name=$1
- local text="$@"
- local branch=${name:0:1}
- local parents=""
+add () {
+ name=$1
+ text="$@"
+ branch=`echo $name | sed -e 's/^\(.\).*$/\1/'`
+ parents=""
shift
while test $1; do
@@ -36,13 +36,13 @@ function add () {
eval ${branch}TIP=$commit
}
-function count_objects () {
+count_objects () {
ls .git/objects/??/* 2>>log2.txt | wc -l | tr -d " "
}
-function test_expect_object_count () {
- local message=$1
- local count=$2
+test_expect_object_count () {
+ message=$1
+ count=$2
output="$(count_objects)"
test_expect_success \
@@ -50,18 +50,18 @@ function test_expect_object_count () {
"test $count = $output"
}
-function pull_to_client () {
- local number=$1
- local heads=$2
- local count=$3
- local no_strict_count_check=$4
+pull_to_client () {
+ number=$1
+ heads=$2
+ count=$3
+ no_strict_count_check=$4
cd client
test_expect_success "$number pull" \
"git-fetch-pack -k -v .. $heads"
case "$heads" in *A*) echo $ATIP > .git/refs/heads/A;; esac
case "$heads" in *B*) echo $BTIP > .git/refs/heads/B;; esac
- git-symbolic-ref HEAD refs/heads/${heads:0:1}
+ git-symbolic-ref HEAD refs/heads/`echo $heads | sed -e 's/^\(.\).*$/\1/'`
test_expect_success "fsck" 'git-fsck-objects --full > fsck.txt 2>&1'
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH 4/4] t6000lib: workaround a possible dash bug
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu, Eric Wong
In-Reply-To: <11486091793385-git-send-email-normalperson@yhbt.net>
pdksh doesn't need this patch, of course bash works fine since
that what most users use.
Normally, 'var=val command' seems to work fine with dash, but
perhaps there's something weird going on with "$@". dash is
pretty widespread, so it'll be good to support this even though
it does seem like a bug in dash.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t6000lib.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
cba907ce0b1c0927fb15cbb5dd91a4129ff9a950
diff --git a/t/t6000lib.sh b/t/t6000lib.sh
index c6752af..d402621 100755
--- a/t/t6000lib.sh
+++ b/t/t6000lib.sh
@@ -69,7 +69,9 @@ on_committer_date()
{
_date=$1
shift 1
- GIT_COMMITTER_DATE=$_date "$@"
+ export GIT_COMMITTER_DATE="$_date"
+ "$@"
+ unset GIT_COMMITTER_DATE
}
# Execute a command and suppress any error output.
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH 2/4] tests: Remove heredoc usage inside quotes
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu, Eric Wong
In-Reply-To: <11486091783542-git-send-email-normalperson@yhbt.net>
The use of heredoc inside quoted strings doesn't seem to be
supported by dash. pdksh seems to handle it fine, however.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
t/t2101-update-index-reupdate.sh | 48 ++++++++++++++++++++------------------
t/t4012-diff-binary.sh | 17 +++++--------
2 files changed, 31 insertions(+), 34 deletions(-)
250810154c837c6999a954fc6bc4318099b67c01
diff --git a/t/t2101-update-index-reupdate.sh b/t/t2101-update-index-reupdate.sh
index 77aed8d..a78ea7f 100755
--- a/t/t2101-update-index-reupdate.sh
+++ b/t/t2101-update-index-reupdate.sh
@@ -8,15 +8,16 @@ test_description='git-update-index --aga
. ./test-lib.sh
+cat > expected <<\EOF
+100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 file1
+100644 9db8893856a8a02eaa73470054b7c1c5a7c82e47 0 file2
+EOF
test_expect_success 'update-index --add' \
'echo hello world >file1 &&
echo goodbye people >file2 &&
git-update-index --add file1 file2 &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 file1
-100644 9db8893856a8a02eaa73470054b7c1c5a7c82e47 0 file2
-EOF'
+ cmp current expected'
test_expect_success 'update-index --again' \
'rm -f file1 &&
@@ -29,20 +30,22 @@ test_expect_success 'update-index --agai
echo happy - failed as expected
fi &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 3b18e512dba79e4c8300dd08aeb37f8e728b8dad 0 file1
-100644 9db8893856a8a02eaa73470054b7c1c5a7c82e47 0 file2
-EOF'
+ cmp current expected'
+cat > expected <<\EOF
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF
test_expect_success 'update-index --remove --again' \
'git-update-index --remove --again &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
-EOF'
+ cmp current expected'
test_expect_success 'first commit' 'git-commit -m initial'
+cat > expected <<\EOF
+100644 53ab446c3f4e42ce9bb728a0ccb283a101be4979 0 dir1/file3
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF
test_expect_success 'update-index again' \
'mkdir -p dir1 &&
echo hello world >dir1/file3 &&
@@ -52,11 +55,12 @@ test_expect_success 'update-index again'
echo happy >dir1/file3 &&
git-update-index --again &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 53ab446c3f4e42ce9bb728a0ccb283a101be4979 0 dir1/file3
-100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
-EOF'
+ cmp current expected'
+cat > expected <<\EOF
+100644 d7fb3f695f06c759dbf3ab00046e7cc2da22d10f 0 dir1/file3
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF
test_expect_success 'update-index --update from subdir' \
'echo not so happy >file2 &&
cd dir1 &&
@@ -64,19 +68,17 @@ test_expect_success 'update-index --upda
git-update-index --again &&
cd .. &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 d7fb3f695f06c759dbf3ab00046e7cc2da22d10f 0 dir1/file3
-100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
-EOF'
+ cmp current expected'
+cat > expected <<\EOF
+100644 594fb5bb1759d90998e2bf2a38261ae8e243c760 0 dir1/file3
+100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
+EOF
test_expect_success 'update-index --update with pathspec' \
'echo very happy >file2 &&
cat file2 >dir1/file3 &&
git-update-index --again dir1/ &&
git-ls-files -s >current &&
- cmp current - <<\EOF
-100644 594fb5bb1759d90998e2bf2a38261ae8e243c760 0 dir1/file3
-100644 0f1ae1422c2bf43f117d3dbd715c988a9ed2103f 0 file2
-EOF'
+ cmp current expected'
test_done
diff --git a/t/t4012-diff-binary.sh b/t/t4012-diff-binary.sh
index bdd95c0..323606c 100755
--- a/t/t4012-diff-binary.sh
+++ b/t/t4012-diff-binary.sh
@@ -16,25 +16,20 @@ test_expect_success 'prepare repository'
echo git >c &&
cat b b >d'
-test_expect_success 'diff without --binary' \
- 'git-diff | git-apply --stat --summary >current &&
- cmp current - <<\EOF
+cat > expected <<\EOF
a | 2 +-
b | Bin
c | 2 +-
d | Bin
4 files changed, 2 insertions(+), 2 deletions(-)
-EOF'
+EOF
+test_expect_success 'diff without --binary' \
+ 'git-diff | git-apply --stat --summary >current &&
+ cmp current expected'
test_expect_success 'diff with --binary' \
'git-diff --binary | git-apply --stat --summary >current &&
- cmp current - <<\EOF
- a | 2 +-
- b | Bin
- c | 2 +-
- d | Bin
- 4 files changed, 2 insertions(+), 2 deletions(-)
-EOF'
+ cmp current expected'
# apply needs to be able to skip the binary material correctly
# in order to report the line number of a corrupt patch.
--
1.3.2.g7d11
^ permalink raw reply related
* [PATCH 0/4] fix tests so they run without needing bash
From: Eric Wong @ 2006-05-26 2:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Herbert Xu
I've tested these patches with bash, pdksh, and dash. dash seems
to be 7s faster than bash (28s vs 35s) when running `make test',
and just a hair faster than pdksh.
Herbert:
patches #2 and #4 are required for dash, but not for pdksh.
I'm not sure about #2, but I'm pretty certain the problem #4 works
around is a bug in dash.
[PATCH 1/4] t3300-funny-names: shell portability fixes
[PATCH 2/4] tests: Remove heredoc usage inside quotes
[PATCH 3/4] t5500-fetch-pack: remove local (bashism) usage.
[PATCH 4/4] t6000lib: workaround a possible dash bug
--
Eric Wong
^ permalink raw reply
* Re: [PATCH 0/4] fix tests so they run without needing bash
From: Junio C Hamano @ 2006-05-26 3:01 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <1148609178788-git-send-email-normalperson@yhbt.net>
You are my hero.
I've really been wanting to get rid of bashism and trying to run
everything with dash was one of my goals. Although recent trend
seems to indicate people are more interested in getting rid of
shell scripts altogether, it is nice to see somebody actually
cares.
^ permalink raw reply
* Re: t8001-annotate.sh fails on Mac OS X
From: Junio C Hamano @ 2006-05-26 3:02 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060526011153.GA27720@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> I think we had hoped that one of the two tools would prove to be
> _the_ annotation/blame tool and would get used but thus far that
> hasn't happened.
I've been taking this as an indication that annotate/blame does
not actually matter in the real world.
Or git is not yet used in the real world. Or perhaps a bit of
both.
^ permalink raw reply
* Re: git-cvsserver wart?
From: Cameron McBride @ 2006-05-26 3:11 UTC (permalink / raw)
To: Martin Langhoff, git
In-Reply-To: <46a038f90605251419kd45fbj419565eabdd63182@mail.gmail.com>
On 5/25/06, Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 5/26/06, Cameron McBride <cameron.mcbride@gmail.com> wrote:
> There's been some recent changes to cvsserver -- so version info is
> crucial. What git version are you using? Can you try with the lastest
> #master head from Junio? That's the latest and greatest...
sorry, my bad. This error was discovered using the git stable, v1.3.3.
Grabbing the latest at git://git.kernel.org/pub/scm/git/git.git
showed the same problem.
> If that doesn't fix it, can you post the logs? I think you have to
> declare CVS_LOG=/tmp/cvslog or somesuch.
I'm assuming you mean the log from git-cvsserver (set via git/config
with logfile=...)
Besides the log cutoff in the broken attempt, it appears the culprit
is a lack of arguments being passed down as that is the only
difference in the logs. Specifically, the working versions output
'Arguments : (something) ' which seemed to come from the
req_Argument()
subroutine around line 550 (in the case of newer CVS, the output is '--').
Anyhow, the error seems to be that $state->{args} is not getting
initialized. In the newer version, there seemed to be additional
uninitialized variables, e.g. $state->{prependdir}. These might be
signs of some larger problem (where the $state isn't getting set
properly).
To quiet it down and get it to run - a crude hack seemed to work
(included below). I didn't test any of this much, nor do I really
understand the whole of what's going on - my alterations just seemed
to allow 'cvs up' to complete without errors or warnings from both
clients. Not a very robust criteria, so please review.
Cameron
--
diff --git a/git-cvsserver.perl b/git-cvsserver.perl
index 5ccca4f..a52e838 100755
--- a/git-cvsserver.perl
+++ b/git-cvsserver.perl
@@ -1702,6 +1702,7 @@ sub argsfromdir
{
my $updater = shift;
+ $state->{args} = [] unless defined($state->{args});
$state->{args} = [] if ( scalar(@{$state->{args}}) == 1 and
$state->{args}[0] eq "." );
return if ( scalar ( @{$state->{args}} ) > 1 );
@@ -1729,7 +1730,11 @@ sub argsfromdir
foreach my $file ( @{$updater->gethead} )
{
next if ( $file->{filehash} eq "deleted" and not defined
( $state->{entries}{$file->{name}} ) );
- next unless ( $file->{name} =~ s/^$state->{prependdir}// );
+ if( defined($state->{prependdir} ) )
+ {
+ $file->{name} =~ s/^$state->{prependdir}//;
+ }
+ next unless ( $file->{name} );
push @{$state->{args}}, $file->{name};
}
}
@@ -1812,7 +1817,7 @@ sub filenamesplit
( $filepart, $dirpart ) = ( $2, $1 ) if ( $filename =~ /(.*)\/(.*)/ );
$dirpart .= "/";
- if ( $fixforlocaldir )
+ if ( $fixforlocaldir and defined($state->{prependdir}))
{
$dirpart =~ s/^$state->{prependdir}//;
}
@@ -1832,7 +1837,10 @@ sub filecleanup
}
$filename =~ s/^\.\///g;
- $filename = $state->{prependdir} . $filename;
+ if( defined($state->{prependdir}) )
+ {
+ $filename = $state->{prependdir} . $filename;
+ }
return $filename;
}
^ 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