* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 3:09 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: PJ Hyett, Johannes Schindelin, git
In-Reply-To: <20090128020220.GE1321@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> PJ Hyett <pjhyett@gmail.com> wrote:
>>
>> Is there any possibility to have the server code in an upcoming
>> release account for clients running 1.6.1?
>
> I can't think off-hand of a way for the server to know what version
> the client is. There's nothing really different in the protocol
> between a 1.6.1 client and a v1.5.5-rc0~44^2 (introduction of
> include-tag) or later client.
Hmm, I am puzzled.
I do not know how 41fa7d2 (Teach git-fetch to exploit server side
automatic tag following, 2008-03-03), which is about the conversation
between fetch-pack and upload-pack, is relevant to the issue at hand,
which is about the conversation between send-pack and receive-pack.
In send-pack receive-pack protocol, the server talks first before
listening to the client, and the .have data is in this first part of the
conversation.
By the way, I think Documentation/technical/pack-protocol.txt needs to be
updated. send-pack receive-pack protocol uses C and S to mean receiver
and sender respectively. We should at least s/C/R/ that part, and
possibly add description about ".have" thing.
^ permalink raw reply
* How to install and use a custom merge driver
From: Alec Clews @ 2009-01-28 3:10 UTC (permalink / raw)
To: git
Background:
I want to use git to track the delivery of patch files into existing
file trees. This means that new files will need to be copied over
existing files (especially in the case of binary files or textual conflicts)
To this end I want to use a custom merge driver (actually the cp command)
Setup:
I have set up my ..git/info/gitattributes as follows
* merge=overwrite
I have defined in .git/config
[merge "overwrite"]
name = overwrite using cp
driver = cp %B %A
Problem:
However when I perform a git merge the default merge is being called. Is
there something else needed to make git perform the copy operation?
Many thanks
--
Alec Clews
Personal <alec.clews@gmail.com> Melbourne, Australia.
Jabber: alecclews@jabber.org.au PGPKey ID: 0x9BBBFC7C
Blog http://alecthegeek.wordpress.com/
^ permalink raw reply
* [PATCH v2 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Jay Soffian @ 2009-01-28 3:27 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, gitster, sverre
When git am is called w/o arguments, w/o a patch on stdin and the user hits
ctrl-c, it leaves behind a partially populated $dotest directory. After this
commit, it emits usage when called w/o arguments and w/o a patch on stdin.
Also ensure that $dotest is cleaned up if user manages to interupt mailsplit
while it is processing input, but not if mailsplit exits non-zero due to
error.
Noticed by Sverre Rabbelier
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Change from v1: don't remove $dotest if mailsplit exits non-zero
git-am.sh | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b1c05c9..65285a0 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -254,10 +254,13 @@ else
done
shift
fi
- git mailsplit -d"$prec" -o"$dotest" -b -- "$@" > "$dotest/last" || {
- rm -fr "$dotest"
+ test $# = 0 && test -t 0 && usage
+ trap 'rm -fr "$dotest"' 0
+ git mailsplit -d"$prec" -o"$dotest" -b -- "$@" > "$dotest/last" || {
+ trap - 0
exit 1
}
+ trap - 0
# -s, -u, -k, --whitespace, -3, -C and -p flags are kept
# for the resuming session after a patch failure.
--
1.6.1.224.gb56c
^ permalink raw reply related
* [PATCH v2 2/2] git-am: minor cleanups
From: Jay Soffian @ 2009-01-28 3:27 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, gitster, sverre
In-Reply-To: <1233113262-17491-1-git-send-email-jaysoffian@gmail.com>
Update usage statement to remove a no-longer supported option, and to hide two
options (one a no-op, one internal) unless --help-all is used.
Use "test -t 0" instead of deprecated "tty -s" to detect when stdin is a
terminal. (test -t 0 is used elsewhere in git-am and in other git shell
scripts, tty -s is not.)
Use "test ..." instead of "[ ... ]" and "die <msg>" instead of "echo <msg>
>&2; exit 1" to be consistent with rest of script.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
Added SoB, otherwise no change from v1.
git-am.sh | 12 ++++--------
1 files changed, 4 insertions(+), 8 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 65285a0..9653a98 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -8,9 +8,8 @@ OPTIONS_SPEC="\
git am [options] [<mbox>|<Maildir>...]
git am [options] (--resolved | --skip | --abort)
--
-d,dotest= (removed -- do not use)
i,interactive run interactively
-b,binary (historical option -- no-op)
+b,binary* (historical option -- no-op)
3,3way allow fall back on 3way merging if needed
s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
@@ -24,7 +23,7 @@ resolvemsg= override error message when patch failure occurs
r,resolved to be used after a patch failure
skip skip the current patch
abort restore the original branch and abort the patching operation.
-rebasing (internal use for git-rebase)"
+rebasing* (internal use for git-rebase)"
. git-sh-setup
prefix=$(git rev-parse --show-prefix)
@@ -204,7 +203,7 @@ then
# unreliable -- stdin could be /dev/null for example
# and the caller did not intend to feed us a patch but
# wanted to continue unattended.
- tty -s
+ test -t 0
;;
*)
false
@@ -283,10 +282,7 @@ fi
case "$resolved" in
'')
files=$(git diff-index --cached --name-only HEAD --) || exit
- if [ "$files" ]; then
- echo "Dirty index: cannot apply patches (dirty: $files)" >&2
- exit 1
- fi
+ test "$files" && die "Dirty index: cannot apply patches (dirty: $files)"
esac
if test "$(cat "$dotest/utf8")" = t
--
1.6.1.224.gb56c
^ permalink raw reply related
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Shawn O. Pearce @ 2009-01-28 3:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: PJ Hyett, Johannes Schindelin, git
In-Reply-To: <7v3af4yvmu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > PJ Hyett <pjhyett@gmail.com> wrote:
> >>
> >> Is there any possibility to have the server code in an upcoming
> >> release account for clients running 1.6.1?
> >
> > I can't think off-hand of a way for the server to know what version
> > the client is. There's nothing really different in the protocol
> > between a 1.6.1 client and a v1.5.5-rc0~44^2 (introduction of
> > include-tag) or later client.
>
> Hmm, I am puzzled.
>
> I do not know how 41fa7d2 (Teach git-fetch to exploit server side
> automatic tag following, 2008-03-03), which is about the conversation
> between fetch-pack and upload-pack, is relevant to the issue at hand,
> which is about the conversation between send-pack and receive-pack.
Oh, right, its not. I was pointing out that the last time the
protocol changed in a way the server can infer something about the
client, which IIRC was 41fa7d2, we still don't have a way to tell
what the client is.
> In send-pack receive-pack protocol, the server talks first before
> listening to the client, and the .have data is in this first part of the
> conversation.
But as you rightly point out, that's the real problem. Since the
server talks first, there's no way for the server to avoid giving
out the newer ".have" lines to a buggy client, as it knows nothing
at all about the client. Not even its capabilities.
PJ - the short story here is, to forever work around these buggy
1.6.1 clients, you'd have to either run an old server forever,
or forever run a patched server that disables the newer ".have"
extension in the advertised data written by git-upload-pack.
There just isn't a way to hide this from the client.
Really though, I'd recommend getting your users to upgrade to a
non-buggy client. Pasky has the same problem on repo.or.cz; if
he doesn't have it already he will soon when he upgrades...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] send-pack: Filter unknown commits from alternates of the remote
From: Junio C Hamano @ 2009-01-28 3:33 UTC (permalink / raw)
To: Björn Steinbrink
Cc: PJ Hyett, Shawn O. Pearce, Johannes Schindelin, Linus Torvalds,
git
In-Reply-To: <20090128013840.GA7224@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Since 40c155ff14c, receive-pack on the remote also sends refs from its
> alternates. Unfortunately, we don't filter commits that don't exist in the
> local repository from that list. This made us pass those unknown commits
> to pack-objects, causing it to fail with a "bad object" error.
>
> Signed-off-by: Björn Steinbrink <B.Steinbrink@gmx.de>
> ---
> builtin-send-pack.c | 14 +++++++++-----
> 1 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> index a9fdbf9..10d7016 100644
> --- a/builtin-send-pack.c
> +++ b/builtin-send-pack.c
> @@ -52,11 +52,15 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
> * parameters by writing to the pipe.
> */
> for (i = 0; i < extra->nr; i++) {
> - memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
> - buf[0] = '^';
> - buf[41] = '\n';
> - if (!write_or_whine(po.in, buf, 42, "send-pack: send refs"))
> - break;
> + if (!is_null_sha1(&extra->array[i][0]) &&
> + has_sha1_file(&extra->array[i][0])) {
> + memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
> + buf[0] = '^';
> + buf[41] = '\n';
> + if (!write_or_whine(po.in, buf, 42,
> + "send-pack: send refs"))
> + break;
> + }
> }
>
> while (refs) {
Actually I changed my mind.
We have the exactly the same issue for the real refs the target repository
has, not just borrowed phantom refs, in the code from day one of git-push.
In other words, this issue predates the ".have" extension, and your update
is in line with how the codepath for the real refs does its thing. So
your fix is not worse than the existing code.
It can be argued that at least in the "real ref" case you are in control
of both ends and if you have a disconnected chain in your local repository
that you do not have a ref for, you are screwing yourself, and it is your
problem. But when you forked your repository from somebody else on a
hosting site like github, you do not have much control over the other end
(because it is a closed site you cannot ssh in to diagnose what is really
going on), and if you do not exactly know from whom your hosted repository
is borrowing, it is more likely that you will get into a situation where
you may have objects near the tip without having the full chain after an
aborted transfer, and the insufficient check of doing only has_sha1_file()
may become a larger issue in such a settings.
But still, let's take the approach I labeled as *wrong* as an interim
solution for the immediate future.
I'd prefer a small helper function to consolidate the duplicated code,
like the attached patch, though. How about doing it like this?
builtin-send-pack.c | 46 ++++++++++++++++++++++++----------------------
1 files changed, 24 insertions(+), 22 deletions(-)
diff --git c/builtin-send-pack.c w/builtin-send-pack.c
index a9fdbf9..2d24cf2 100644
--- c/builtin-send-pack.c
+++ w/builtin-send-pack.c
@@ -15,6 +15,23 @@ static struct send_pack_args args = {
/* .receivepack = */ "git-receive-pack",
};
+static int feed_object(const unsigned char *theirs, int fd, int negative)
+{
+ char buf[42];
+
+ if (!has_sha1_file(theirs))
+ return 1;
+ /*
+ * NEEDSWORK: we should not be satisfied by simply having
+ * theirs, but should be making sure it is reachable from
+ * some of our refs.
+ */
+ memcpy(buf + negative, sha1_to_hex(theirs), 40);
+ if (negative)
+ buf[0] = '^';
+ buf[40 + negative] = '\n';
+ return write_or_whine(fd, buf, 41 + negative, "send-pack: send refs");
+}
/*
* Make a pack stream and spit it out into file descriptor fd
*/
@@ -35,7 +52,6 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
};
struct child_process po;
int i;
- char buf[42];
if (args.use_thin_pack)
argv[4] = "--thin";
@@ -51,31 +67,17 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
* We feed the pack-objects we just spawned with revision
* parameters by writing to the pipe.
*/
- for (i = 0; i < extra->nr; i++) {
- memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
- buf[0] = '^';
- buf[41] = '\n';
- if (!write_or_whine(po.in, buf, 42, "send-pack: send refs"))
+ for (i = 0; i < extra->nr; i++)
+ if (!feed_object(extra->array[i], po.in, 1))
break;
- }
while (refs) {
if (!is_null_sha1(refs->old_sha1) &&
- has_sha1_file(refs->old_sha1)) {
- memcpy(buf + 1, sha1_to_hex(refs->old_sha1), 40);
- buf[0] = '^';
- buf[41] = '\n';
- if (!write_or_whine(po.in, buf, 42,
- "send-pack: send refs"))
- break;
- }
- if (!is_null_sha1(refs->new_sha1)) {
- memcpy(buf, sha1_to_hex(refs->new_sha1), 40);
- buf[40] = '\n';
- if (!write_or_whine(po.in, buf, 41,
- "send-pack: send refs"))
- break;
- }
+ !feed_object(refs->old_sha1, po.in, 1))
+ break;
+ if (!is_null_sha1(refs->new_sha1) &&
+ !feed_object(refs->new_sha1, po.in, 0))
+ break;
refs = refs->next;
}
.
^ permalink raw reply related
* Re: Heads up: rebase -i -p will be made sane again
From: Stephen Haberman @ 2009-01-28 3:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901280225240.3586@pacific.mpi-cbg.de>
> Actually, I misread t3410 a great deal. The situation is as follows:
>
> ... UPSTREAM
> \
> ... A - B - C -D
>
> A is a patch the upstream does not have, B is a patch UPSTREAM has,
> and "git diff C^!" (i.e. the diff of C to its first parent) is _also_
> identical to a diff of a merge that is in UPSTREAM.
>
> Basically, t3410 tests that after "git rebase -i -p UPSTREAM" and leaving
> the rebase script as-is, essentially, A and D are cherry-picked on top of
> UPSTREAM.
Cool--I "knew" that, but could not have articulated the case as
succinctly.
> > Does this mean you're just getting rid of the code that calls "rev list
> > --cherry-pick"?
>
> Only now do I understand.
>
> I misread the code for --cherry-pick. For merges, it adds the diff to the
> first parent!
Ah, so that is how --cherry-pick works--I'd never looked into the
patch-id stuff before. Makes sense, both of how it is leveraged by
rev-list --cherry-pick and also that it doesn't make sense to only be
against the first parent of merges.
> So I adapted my code to find the "dropped" merges in
> git-rebase--interactive, too, for now, but I guess the proper fix is
> something like this:
So, if C, as a merge commit, doesn't get a patch id anymore (right?),
does that mean that C is included with A and D in the cherry-picking
on top of UPSTREAM (because with no patch id it cannot be recognized
as a duplicate)? So then C' is an empty-commit? This would be fine, I
think, or can you detect that C is a noop somehow without patch ids?
Thanks,
Stephen
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Stephen Bannasch @ 2009-01-28 3:52 UTC (permalink / raw)
To: git
In-Reply-To: <20090128033020.GF1321@spearce.org>
At 7:30 PM -0800 1/27/09, Shawn O. Pearce wrote:
>PJ - the short story here is, to forever work around these buggy
>1.6.1 clients, you'd have to either run an old server forever,
>or forever run a patched server that disables the newer ".have"
>extension in the advertised data written by git-upload-pack.
>There just isn't a way to hide this from the client.
>
>Really though, I'd recommend getting your users to upgrade to a
>non-buggy client. Pasky has the same problem on repo.or.cz; if
>he doesn't have it already he will soon when he upgrades...
Do you know if this problem is fixed in tag v1.6.1.1?
Tagger: Junio C Hamano <gitster@pobox.com>
Date: Sun Jan 25 12:41:48 2009 -0800
commit 5c415311f743ccb11a50f350ff1c385778f049d6
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Shawn O. Pearce @ 2009-01-28 3:57 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git
In-Reply-To: <p06240812c5a58676a1e2@[63.138.152.192]>
Stephen Bannasch <stephen.bannasch@deanbrook.org> wrote:
> At 7:30 PM -0800 1/27/09, Shawn O. Pearce wrote:
>> PJ - the short story here is, to forever work around these buggy
>> 1.6.1 clients, you'd have to either run an old server forever,
>> or forever run a patched server that disables the newer ".have"
>> extension in the advertised data written by git-upload-pack.
>> There just isn't a way to hide this from the client.
>>
>> Really though, I'd recommend getting your users to upgrade to a
>> non-buggy client. Pasky has the same problem on repo.or.cz; if
>> he doesn't have it already he will soon when he upgrades...
>
> Do you know if this problem is fixed in tag v1.6.1.1?
>
> Tagger: Junio C Hamano <gitster@pobox.com>
> Date: Sun Jan 25 12:41:48 2009 -0800
> commit 5c415311f743ccb11a50f350ff1c385778f049d6
Without even checking Git I can tell you it isn't fixed by 1.6.1.1.
The date on the tag is Jan 25th, 2 full days before PJ reported
the problem and a solution was proposed...
--
Shawn.
^ permalink raw reply
* Re: [PATCH] send-pack: Filter unknown commits from alternates of the remote
From: Björn Steinbrink @ 2009-01-28 3:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: PJ Hyett, Shawn O. Pearce, Johannes Schindelin, Linus Torvalds,
git
In-Reply-To: <7vskn4xfyg.fsf@gitster.siamese.dyndns.org>
On 2009.01.27 19:33:11 -0800, Junio C Hamano wrote:
> It can be argued that at least in the "real ref" case you are in control
> of both ends and if you have a disconnected chain in your local repository
> that you do not have a ref for, you are screwing yourself, and it is your
> problem. But when you forked your repository from somebody else on a
> hosting site like github, you do not have much control over the other end
> (because it is a closed site you cannot ssh in to diagnose what is really
> going on), and if you do not exactly know from whom your hosted repository
> is borrowing, it is more likely that you will get into a situation where
> you may have objects near the tip without having the full chain after an
> aborted transfer, and the insufficient check of doing only has_sha1_file()
> may become a larger issue in such a settings.
Uhm, it might be obvious, but what exactly could go wrong? Do we need to
fetch from multiple repos when alternates are involved? Or how would we
end up with a broken chain? I mean, it starts to make some sense to me
why we would need the connectivity check, but how do we end up with a
"partial" fetch at all?
> I'd prefer a small helper function to consolidate the duplicated code,
> like the attached patch, though. How about doing it like this?
Yeah, that looks a lot nicer :-)
Björn
^ permalink raw reply
* Re: Heads up: rebase -i -p will be made sane again
From: Johannes Schindelin @ 2009-01-28 4:01 UTC (permalink / raw)
To: Stephen Haberman; +Cc: git, gitster
In-Reply-To: <20090127213950.3596ecf9.stephen@exigencecorp.com>
Hi,
On Tue, 27 Jan 2009, Stephen Haberman wrote:
> > So I adapted my code to find the "dropped" merges in
> > git-rebase--interactive, too, for now, but I guess the proper fix is
> > something like this:
>
> So, if C, as a merge commit, doesn't get a patch id anymore (right?),
> does that mean that C is included with A and D in the cherry-picking
> on top of UPSTREAM (because with no patch id it cannot be recognized
> as a duplicate)?
Yep, it gets into the list. But not with a "pick" command, as a merge it
will get a "merge" command.
> So then C' is an empty-commit? This would be fine, I think, or can you
> detect that C is a noop somehow without patch ids?
Actually, there are three possible outcomes:
- it tries to merge an ancestor of HEAD or HEAD itself -> noop
- it tries to merge which results in a fast-forward -> fine
- it tries to merge and a proper merge is necessary -> may conflict
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] send-pack: Filter unknown commits from alternates of the remote
From: Junio C Hamano @ 2009-01-28 4:13 UTC (permalink / raw)
To: Björn Steinbrink
Cc: PJ Hyett, Shawn O. Pearce, Johannes Schindelin, Linus Torvalds,
git
In-Reply-To: <20090128035804.GC7503@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Uhm, it might be obvious, but what exactly could go wrong?
Between the refs and your object store, there is a contract that
guarantees that everything that is reachable from your refs are complete
and you won't hit unreachable object while traversing the reachability
chain from them. But your object store can contain other garbage
objects. The contract is one of the things "git fsck" checks.
Imagine you have fetched from somewhere with a commit walker (e.g. fetch
over http), that started fetching from the tip commit and its associated
objects, and then got interrupted. Such a transfer will leave the objects
in your local repository but it is safe because it won't update your refs.
>> I'd prefer a small helper function to consolidate the duplicated code,
>> like the attached patch, though. How about doing it like this?
>
> Yeah, that looks a lot nicer :-)
But it was broken. The initial check feed_object() does with
has_sha1_file() and NEEDSWORK comment needs to be inside
if (negative) {
if (!has_sha1_file(theirs))
return 1;
/*
* NEEDSWORK: we should not be satisfied by simply having
* theirs, but should be making sure it is reachable from
* some of our refs.
*/
}
to make sure we won't trigger the availability or connectivity check for
positive refs.
^ permalink raw reply
* Re: [PATCH v2 1/2] git-am: emit usage when called w/o arguments and w/o patch on stdin
From: Junio C Hamano @ 2009-01-28 4:17 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, gitster, sverre
In-Reply-To: <1233113262-17491-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> + test $# = 0 && test -t 0 && usage
Sorry to be dense. Why isn't your patch the above single liner?
^ permalink raw reply
* Re: [PATCH v2 2/2] git-am: minor cleanups
From: Junio C Hamano @ 2009-01-28 4:18 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, gitster, sverre
In-Reply-To: <1233113262-17491-2-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> Use "test -t 0" instead of deprecated "tty -s" to detect when stdin is a
> terminal.
Who deprecated it?
Other changes looked sensible, though.
^ permalink raw reply
* Re: [PATCH] Windows: Fix intermittent failures of t7701
From: Jeff King @ 2009-01-28 4:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901271740320.3586@pacific.mpi-cbg.de>
On Tue, Jan 27, 2009 at 05:42:03PM +0100, Johannes Schindelin wrote:
> > We want to catch failures of test-chmtime; but since it appears in a
> > pipe, we cannot access its exit code. Therefore, we at least make sure
> > that it prints time stamps of all files that are passed on its command
> > line.
>
> I use this trick in my valgrind series:
>
> ($PROGRAM; echo $? > exit.code) | $OTHER_PROGRAM &&
> test 0 = "$(cat exit.code)"
Oh, that's far too readable. How about:
exec 3>&1
status=$( ( ($PROGRAM ; echo $? >&4) | $OTHER_PROGRAM >&3) 4>&1 )
exec 3>&-
But seriously, I think if we are talking about tests, then
$PROGRAM >output &&
$OTHER_PROGRAM <output
is very clear to read, and as a bonus makes "output" accessible for
viewing when the test breaks. The downside is that it isn't very
efficient for a large output, but most of our test output is small (and
we don't care that much about efficiency).
Just my shell bikeshedding 2 cents. Feel free to ignore.
-Peff
^ permalink raw reply
* Re: [PATCH] send-pack: Filter unknown commits from alternates of the remote
From: Junio C Hamano @ 2009-01-28 4:32 UTC (permalink / raw)
To: Björn Steinbrink
Cc: PJ Hyett, Shawn O. Pearce, Johannes Schindelin, Linus Torvalds,
git
In-Reply-To: <20090128035804.GC7503@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> ... Do we need to
> fetch from multiple repos when alternates are involved?
This part is a slightly different issue than the rest of your message, so
I'll answer separately.
Yes, in the example, if Bob fetched from Alice before he pushed, his push
will succeed with the 1.6.1 send-pack.
But that is a workaround, and it is not a fix.
^ permalink raw reply
* [JGIT PATCH] Add getTaggerIdent, getShortMessage, getFullMessage to RevTag
From: Shawn O. Pearce @ 2009-01-28 4:35 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
These methods make the RevTag API more like the RevCommit API, such
that it is more consistent for applications to access the "fields"
of a tag object in the same way that they access the fields of any
commit object.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Actually, this has also gone through Gerrit2. If you want to see
what the same patch looks like (just for fun):
http://review.source.android.com/8681
or
http://review.source.android.com/r/633476cf478da7c9375abf5fe
.../src/org/spearce/jgit/revwalk/RevCommit.java | 2 +-
.../src/org/spearce/jgit/revwalk/RevTag.java | 74 +++++++++++++++++++-
.../src/org/spearce/jgit/util/RawParseUtils.java | 47 ++++++++++++-
3 files changed, 119 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
index 7454d8e..de11c39 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevCommit.java
@@ -367,7 +367,7 @@ public final String getShortMessage() {
return str;
}
- private static boolean hasLF(final byte[] r, int b, final int e) {
+ static boolean hasLF(final byte[] r, int b, final int e) {
while (b < e)
if (r[b++] == '\n')
return true;
diff --git a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevTag.java b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevTag.java
index 77a55cd..82f0009 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevTag.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/revwalk/RevTag.java
@@ -38,6 +38,7 @@
package org.spearce.jgit.revwalk;
import java.io.IOException;
+import java.nio.charset.Charset;
import org.spearce.jgit.errors.CorruptObjectException;
import org.spearce.jgit.errors.IncorrectObjectTypeException;
@@ -45,6 +46,7 @@
import org.spearce.jgit.lib.AnyObjectId;
import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.lib.ObjectLoader;
+import org.spearce.jgit.lib.PersonIdent;
import org.spearce.jgit.lib.Tag;
import org.spearce.jgit.util.MutableInteger;
import org.spearce.jgit.util.RawParseUtils;
@@ -100,7 +102,77 @@ void parseCanonical(final RevWalk walk, final byte[] rawTag)
public int getType() {
return Constants.OBJ_TAG;
}
-
+
+ /**
+ * Parse the tagger identity from the raw buffer.
+ * <p>
+ * This method parses and returns the content of the tagger line, after
+ * taking the tag's character set into account and decoding the tagger
+ * name and email address. This method is fairly expensive and produces a
+ * new PersonIdent instance on each invocation. Callers should invoke this
+ * method only if they are certain they will be outputting the result, and
+ * should cache the return value for as long as necessary to use all
+ * information from it.
+ *
+ * @return identity of the tagger (name, email) and the time the tag
+ * was made by the tagger; null if no tagger line was found.
+ */
+ public final PersonIdent getTaggerIdent() {
+ final byte[] raw = buffer;
+ final int nameB = RawParseUtils.tagger(raw, 0);
+ if (nameB < 0)
+ return null;
+ return RawParseUtils.parsePersonIdent(raw, nameB);
+ }
+
+ /**
+ * Parse the complete tag message and decode it to a string.
+ * <p>
+ * This method parses and returns the message portion of the tag buffer,
+ * after taking the tag's character set into account and decoding the buffer
+ * using that character set. This method is a fairly expensive operation and
+ * produces a new string on each invocation.
+ *
+ * @return decoded tag message as a string. Never null.
+ */
+ public final String getFullMessage() {
+ final byte[] raw = buffer;
+ final int msgB = RawParseUtils.tagMessage(raw, 0);
+ if (msgB < 0)
+ return "";
+ final Charset enc = RawParseUtils.parseEncoding(raw);
+ return RawParseUtils.decode(enc, raw, msgB, raw.length);
+ }
+
+ /**
+ * Parse the tag message and return the first "line" of it.
+ * <p>
+ * The first line is everything up to the first pair of LFs. This is the
+ * "oneline" format, suitable for output in a single line display.
+ * <p>
+ * This method parses and returns the message portion of the tag buffer,
+ * after taking the tag's character set into account and decoding the buffer
+ * using that character set. This method is a fairly expensive operation and
+ * produces a new string on each invocation.
+ *
+ * @return decoded tag message as a string. Never null. The returned string
+ * does not contain any LFs, even if the first paragraph spanned
+ * multiple lines. Embedded LFs are converted to spaces.
+ */
+ public final String getShortMessage() {
+ final byte[] raw = buffer;
+ final int msgB = RawParseUtils.tagMessage(raw, 0);
+ if (msgB < 0)
+ return "";
+
+ final Charset enc = RawParseUtils.parseEncoding(raw);
+ final int msgE = RawParseUtils.endOfParagraph(raw, msgB);
+ String str = RawParseUtils.decode(enc, raw, msgB, msgE);
+ if (RevCommit.hasLF(raw, msgB, msgE))
+ str = str.replace('\n', ' ');
+ return str;
+ }
+
/**
* Parse this tag buffer for display.
*
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
index 758e7af..646a654 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/RawParseUtils.java
@@ -40,6 +40,7 @@
import static org.spearce.jgit.lib.ObjectChecker.author;
import static org.spearce.jgit.lib.ObjectChecker.committer;
import static org.spearce.jgit.lib.ObjectChecker.encoding;
+import static org.spearce.jgit.lib.ObjectChecker.tagger;
import java.nio.ByteBuffer;
import java.nio.charset.CharacterCodingException;
@@ -397,6 +398,32 @@ public static final int committer(final byte[] b, int ptr) {
}
/**
+ * Locate the "tagger " header line data.
+ *
+ * @param b
+ * buffer to scan.
+ * @param ptr
+ * position in buffer to start the scan at. Most callers should
+ * pass 0 to ensure the scan starts from the beginning of the tag
+ * buffer and does not accidentally look at message body.
+ * @return position just after the space in "tagger ", so the first
+ * character of the tagger's name. If no tagger header can be
+ * located -1 is returned.
+ */
+ public static final int tagger(final byte[] b, int ptr) {
+ final int sz = b.length;
+ while (ptr < sz) {
+ if (b[ptr] == '\n')
+ return -1;
+ final int m = match(b, ptr, tagger);
+ if (m >= 0)
+ return m;
+ ptr = nextLF(b, ptr);
+ }
+ return -1;
+ }
+
+ /**
* Locate the "encoding " header line.
*
* @param b
@@ -648,9 +675,25 @@ public static final int commitMessage(final byte[] b, int ptr) {
while (ptr < sz && b[ptr] == 'p')
ptr += 48; // skip this parent.
- // skip any remaining header lines, ignoring what their actual
- // header line type is.
+ // Skip any remaining header lines, ignoring what their actual
+ // header line type is. This is identical to the logic for a tag.
//
+ return tagMessage(b, ptr);
+ }
+
+ /**
+ * Locate the position of the tag message body.
+ *
+ * @param b
+ * buffer to scan.
+ * @param ptr
+ * position in buffer to start the scan at. Most callers should
+ * pass 0 to ensure the scan starts from the beginning of the tag
+ * buffer.
+ * @return position of the user's message buffer.
+ */
+ public static final int tagMessage(final byte[] b, int ptr) {
+ final int sz = b.length;
while (ptr < sz && b[ptr] != '\n')
ptr = nextLF(b, ptr);
if (ptr < sz && b[ptr] == '\n')
--
1.6.1.1.374.g0d9d7
^ permalink raw reply related
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 4:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: PJ Hyett, Johannes Schindelin, git
In-Reply-To: <20090128033020.GF1321@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>>
>> Hmm, I am puzzled.
>>
>> I do not know how 41fa7d2 (Teach git-fetch to exploit server side
>> automatic tag following, 2008-03-03), which is about the conversation
>> between fetch-pack and upload-pack, is relevant to the issue at hand,
>> which is about the conversation between send-pack and receive-pack.
>
> Oh, right, its not. I was pointing out that the last time the
> protocol changed in a way the server can infer something about the
> client, which IIRC was 41fa7d2, we still don't have a way to tell
> what the client is.
But you are still talking as if there is one protocol you can call "the
protocol", but it is not. The send-pack receive-pack protocol is on topic
in this thread; the quoted commit was about a separate and independent
fetch-pack upload-pack protocol. It does not matter when that unrelated
protocol was enhanced.
> PJ - the short story here is, to forever work around these buggy
> 1.6.1 clients, you'd have to either run an old server forever,
> or forever run a patched server that disables the newer ".have"
> extension in the advertised data written by git-upload-pack.
> There just isn't a way to hide this from the client.
>
> Really though, I'd recommend getting your users to upgrade to a
> non-buggy client. Pasky has the same problem on repo.or.cz; if
> he doesn't have it already he will soon when he upgrades...
Yeah, I'll apply the attached patch to 'maint' and it will be in the next
1.6.1.X maintenance release. I suspect that your 1.6.1 users are the ones
who like to be on the cutting edge, and it wouldn't be unreasonable to
expect that they will update soon (1.6.1 has been out only for one month).
-- >8 --
Subject: [PATCH] send-pack: do not send unknown object name from ".have" to pack-objects
v1.6.1 introduced ".have" extension to the protocol to allow the receiving
side to advertise objects that are reachable from refs in the repositories
it borrows from. This was meant to be used by the sending side to avoid
sending such objects; they are already available through the alternates
mechanism.
The client side implementation in v1.6.1, which was introduced with
40c155f (push: prepare sender to receive extended ref information from the
receiver, 2008-09-09) aka v1.6.1-rc1~203^2~1, were faulty in that it did
not consider the possiblity that the repository receiver borrows from
might have objects it does not know about.
This implements a tentative fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-send-pack.c | 49 +++++++++++++++++++++++++++----------------------
1 files changed, 27 insertions(+), 22 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index a9fdbf9..fae597b 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -15,6 +15,26 @@ static struct send_pack_args args = {
/* .receivepack = */ "git-receive-pack",
};
+static int feed_object(const unsigned char *theirs, int fd, int negative)
+{
+ char buf[42];
+
+ if (negative) {
+ if (!has_sha1_file(theirs))
+ return 1;
+ /*
+ * NEEDSWORK: we should not be satisfied by simply having
+ * theirs, but should be making sure it is reachable from
+ * some of our refs.
+ */
+ }
+
+ memcpy(buf + negative, sha1_to_hex(theirs), 40);
+ if (negative)
+ buf[0] = '^';
+ buf[40 + negative] = '\n';
+ return write_or_whine(fd, buf, 41 + negative, "send-pack: send refs");
+}
/*
* Make a pack stream and spit it out into file descriptor fd
*/
@@ -35,7 +55,6 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
};
struct child_process po;
int i;
- char buf[42];
if (args.use_thin_pack)
argv[4] = "--thin";
@@ -51,31 +70,17 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
* We feed the pack-objects we just spawned with revision
* parameters by writing to the pipe.
*/
- for (i = 0; i < extra->nr; i++) {
- memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
- buf[0] = '^';
- buf[41] = '\n';
- if (!write_or_whine(po.in, buf, 42, "send-pack: send refs"))
+ for (i = 0; i < extra->nr; i++)
+ if (!feed_object(extra->array[i], po.in, 1))
break;
- }
while (refs) {
if (!is_null_sha1(refs->old_sha1) &&
- has_sha1_file(refs->old_sha1)) {
- memcpy(buf + 1, sha1_to_hex(refs->old_sha1), 40);
- buf[0] = '^';
- buf[41] = '\n';
- if (!write_or_whine(po.in, buf, 42,
- "send-pack: send refs"))
- break;
- }
- if (!is_null_sha1(refs->new_sha1)) {
- memcpy(buf, sha1_to_hex(refs->new_sha1), 40);
- buf[40] = '\n';
- if (!write_or_whine(po.in, buf, 41,
- "send-pack: send refs"))
- break;
- }
+ !feed_object(refs->old_sha1, po.in, 1))
+ break;
+ if (!is_null_sha1(refs->new_sha1) &&
+ !feed_object(refs->new_sha1, po.in, 0))
+ break;
refs = refs->next;
}
--
1.6.1.1.273.g0e555
^ permalink raw reply related
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Shawn O. Pearce @ 2009-01-28 4:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: PJ Hyett, Johannes Schindelin, git
In-Reply-To: <7v1vuoxcxk.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> >
> > Oh, right, its not. I was pointing out that the last time the
> > protocol changed in a way the server can infer something about the
> > client, which IIRC was 41fa7d2, we still don't have a way to tell
> > what the client is.
>
> But you are still talking as if there is one protocol you can call "the
> protocol", but it is not. The send-pack receive-pack protocol is on topic
> in this thread; the quoted commit was about a separate and independent
> fetch-pack upload-pack protocol. It does not matter when that unrelated
> protocol was enhanced.
Blargh. Of course you are right. Its been a long 2 months for me
at work. I'm too #@*#@!@! tired to keep the basics straight anymore.
I'm going to shut up now.
--
Shawn.
^ permalink raw reply
* Re: friendlier names
From: Junio C Hamano @ 2009-01-28 4:51 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, David Abrahams, git
In-Reply-To: <200901280312.16717.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> BTW with "git add" way you have to know that "git add"-ing a file
> would clear 'is in merge conflict' flags (well, will hide >0 stages...).
Sigh...
Again, you seem to be affected by the same confusion that caused you to
think "git resolved" may have some reason to exist.
An unmerged index with higer stages means that the contents that need to
be in the next commit is _unknown_ for the paths.
If somebody says "I am telling you that this path has the contents I want
to have in the commit I will create next" (which is what "staging" the
contents in the "index" is), what plausible reason does git have to keep
the higher stages for them? At that point, the contents the user wants to
have for these paths are known.
^ permalink raw reply
* Re: "malloc failed"
From: Jeff King @ 2009-01-28 5:02 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <878wow7pth.fsf@mcbain.luannocracy.com>
On Tue, Jan 27, 2009 at 10:04:42AM -0500, David Abrahams wrote:
> I've been abusing Git for a purpose it wasn't intended to serve:
> archiving a large number of files with many duplicates and
> near-duplicates. Every once in a while, when trying to do something
> really big, it tells me "malloc failed" and bails out (I think it's
> during "git add" but because of the way I issued the commands I can't
> tell: it could have been a commit or a gc). This is on a 64-bit linux
> machine with 8G of ram and plenty of swap space, so I'm surprised.
>
> Git is doing an amazing job at archiving and compressing all this stuff
> I'm putting in it, but I have to do it a wee bit at a time or it craps
> out. Bug?
How big is the repository? How big are the biggest files? I have a
3.5G repo with files ranging from a few bytes to about 180M. I've never
run into malloc problems or gone into swap on my measly 1G box.
How does your dataset compare?
As others have mentioned, git wasn't really designed specifically for
those sorts of numbers, but in the interests of performance, I find git
is usually pretty careful about not keeping too much useless stuff in
memory at one time. And the fact that you can perform the same
operation a little bit at a time and achieve success implies to me there
might be a leak or some silly behavior that can be fixed.
It would help a lot if we knew the operation that was causing the
problem. Can you try to isolate the failed command next time it happens?
-Peff
^ permalink raw reply
* Re: Heads up: rebase -i -p will be made sane again
From: Stephen Haberman @ 2009-01-28 5:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901280458590.3586@pacific.mpi-cbg.de>
> > > So I adapted my code to find the "dropped" merges in
> > > git-rebase--interactive, too, for now, but I guess the proper fix is
> > > something like this:
> >
> > So, if C, as a merge commit, doesn't get a patch id anymore (right?),
> > does that mean that C is included with A and D in the cherry-picking
> > on top of UPSTREAM (because with no patch id it cannot be recognized
> > as a duplicate)?
>
> Yep, it gets into the list. But not with a "pick" command, as a merge it
> will get a "merge" command.
>
> > So then C' is an empty-commit? This would be fine, I think, or can you
> > detect that C is a noop somehow without patch ids?
>
> Actually, there are three possible outcomes:
>
> - it tries to merge an ancestor of HEAD or HEAD itself -> noop
>
> - it tries to merge which results in a fast-forward -> fine
>
> - it tries to merge and a proper merge is necessary -> may conflict
Ah, cool, that makes sense.
Thanks,
Stephen
^ permalink raw reply
* Re: connecting existing local git repository to svn
From: Ittay Dror @ 2009-01-28 5:26 UTC (permalink / raw)
Cc: git
In-Reply-To: <497F05D7.3060607@drmicha.warpmail.net>
Michael J Gruber wrote:
> Ittay Dror venit, vidit, dixit 01/27/09 13:48:
>
>> Sverre Rabbelier wrote:
>>
>>
>>> On Tue, Jan 27, 2009 at 11:41, Ittay Dror <ittay.dror@gmail.com> wrote:
>>>
>>>
>>>> git: ----v1----v2----v3--v4---v5
>>>> svn: \---v4--v5
>>>>
>>>> so the svn history starts from v3, but the git history remains unchanged.
>>>>
>>>>
>>> Create the new branch from v3 then, and use git svn to pull it in.
>>> Then you can do 'git rebase that-svn-branch' on your git branch to put
>>> all commits (not as one big commit) on top of that branch point. Now
>>> you 'git checkout' that-svn-branch and do 'git reset --hard
>>> the-git-branch', which should now consist of
>>> v1--v2--v3--v4(git)--v5(git), etc. If you do 'git svn dcommit' from
>>> the that-svn-branch now it should dcommit to svn each of your git
>>>
>>>
>> sorry, my ascii art was confusing:
>>
>> git: ----v1----v2----v3--v4---v5
>> svn: v1-4---v5
>>
>> v1-4 is v1 to v4 squashed together. (e.g., if i added a file in v2 and
>> removed in v3 it will not appear in svn history)
>>
>
> Well, for git and svn "revisions" are really "versions" of the complete
> tree, not changesets. Have messed around with hg lately? ;)
>
> On the other hand, a commit that introduces a new version is the
> difference with respect to the previous "version".
>
>
here's a new one:
initial
git: --- c1 --- c2 --- c3 --- c4
create svn:
git: --- c1 --- c2 --- c3 --- c4
svn --- c1|c2|c3|c4
where c1|c2|c3|c4 is the squashing of all commits into one. it is the
first revision in the svn repository
c1|c2|c3|c4 === r1
do some work, commit, dcommit:
git: --- c1 --- c2 --- c3 --- c4 --- c5
svn --- c1|c2|c3|c4 --- r2
where 'r2' is revision 2 of the svn repository and contains the same
changes as c5. that is diff(r2, r1) is the same as diff(c5, c4)
so the svn history starts from how the working tree looks like when it
is created and progresses from there. the git history is unaltered. i
want to keep on working on 'master' in git (and 'git log' should show
all commits as before).
> Ususally it's clear what is meant, but you seem to mix both notions.
>
> So, if v? denotes a version, then v4 is the result of all commits
> leading up to v4. It *is* v4. "squashing" applies only to commits
> ("changes").
>
> In any case, Sverre's as well as my suggestions should do what you want.
> Why not try it out if you doubt it?
>
well, sverre's suggestion says it will dcommit each git commit
individually and i think your suggestion means i discard my git history
in the branch i'm working on.
thank you,
ittay
> Cheers,
> Michael
>
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 5:44 UTC (permalink / raw)
To: Stephen Bannasch; +Cc: git
In-Reply-To: <p06240812c5a58676a1e2@[63.138.152.192]>
Stephen Bannasch <stephen.bannasch@deanbrook.org> writes:
> At 7:30 PM -0800 1/27/09, Shawn O. Pearce wrote:
>>PJ - the short story here is, to forever work around these buggy
>>1.6.1 clients, you'd have to either run an old server forever,
>>or forever run a patched server that disables the newer ".have"
>>extension in the advertised data written by git-upload-pack.
>>There just isn't a way to hide this from the client.
>>
>>Really though, I'd recommend getting your users to upgrade to a
>>non-buggy client. Pasky has the same problem on repo.or.cz; if
>>he doesn't have it already he will soon when he upgrades...
>
> Do you know if this problem is fixed in tag v1.6.1.1?
>
> Tagger: Junio C Hamano <gitster@pobox.com>
> Date: Sun Jan 25 12:41:48 2009 -0800
> commit 5c415311f743ccb11a50f350ff1c385778f049d6
Give us a break. This was reported today and diagnosed a few hours ago.
In the meantime, here is a minimum patch that should help you to help us
convince the approach we decided to take would work fine for people.
connect.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git c/connect.c w/connect.c
index 2f23ab3..8026850 100644
--- c/connect.c
+++ w/connect.c
@@ -43,6 +43,9 @@ int check_ref_type(const struct ref *ref, int flags)
static void add_extra_have(struct extra_have_objects *extra, unsigned char *sha1)
{
+ if (!has_sha1_file(sha1))
+ return;
+
ALLOC_GROW(extra->array, extra->nr + 1, extra->alloc);
hashcpy(&(extra->array[extra->nr][0]), sha1);
extra->nr++;
^ permalink raw reply related
* Re: How to install and use a custom merge driver
From: Jeff King @ 2009-01-28 6:18 UTC (permalink / raw)
To: Alec Clews; +Cc: git
In-Reply-To: <497FCC9A.9080008@gmail.com>
On Wed, Jan 28, 2009 at 02:10:18PM +1100, Alec Clews wrote:
> Setup:
>
> I have set up my ..git/info/gitattributes as follows
>
> * merge=overwrite
Your setup looks right, except that the correct file is
".git/info/attributes".
-Peff
^ 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