* 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
* [PATCH] mergetool merge/skip/abort at prompt
From: Caleb Cushing @ 2009-01-28 6:56 UTC (permalink / raw)
To: Junio C Hamano, Charles Bailey, git, Nanako Shiraishi
previously git mergetool when run with prompt only allowed the user to continue
merging. This changes git mergetool to allow the option of skipping a file or
aborting, and includes an addtional key to explicitly select merge.
Signed-off-by: Caleb Cushing <xenoterracide@gmail.com>
---
git-mergetool.sh | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 00e1337..575fbb2 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -177,8 +177,24 @@ merge_file () {
describe_file "$local_mode" "local" "$LOCAL"
describe_file "$remote_mode" "remote" "$REMOTE"
if "$prompt" = true; then
- printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
- read ans
+ while true; do
+ printf "Use (m)erge file or (s)kip file, or (a)bort? (%s): " \
+ "$merge_tool"
+ read ans
+ case "$ans" in
+ [mM]*|"")
+ break
+ ;;
+ [sS]*)
+ cleanup_temp_files
+ return 0
+ ;;
+ [aA]*)
+ cleanup_temp_files
+ exit 0
+ ;;
+ esac
+ done
fi
case "$merge_tool" in
--
1.6.1.1
^ permalink raw reply related
* Re: git 1.6.1 on AIX 5.3
From: Jeff King @ 2009-01-28 7:01 UTC (permalink / raw)
To: Perry Smith; +Cc: Mike Ralphson, git
In-Reply-To: <BAD975AD-323D-4278-8405-0B57E7202797@gmail.com>
On Tue, Jan 27, 2009 at 07:35:00PM -0600, Perry Smith wrote:
> Just to be sure we are on the same page. My directory structure has a
> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is the
> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
> then do: ../../src/git-1.6.1/configure <options> After this
> completes, you can do "make".
I don't see how this would work without automake support, which git does
not have. The configure script just generates a config.mak.autogen file,
which is included by the Makefile. So you have no Makefile in your build
directory.
> About 90% of the open source configure / autoconf code out there can
> do this with. The other 10% you can not. I like it because when
> things die, its easier to grep around the source tree and I blow away
> the build directory and start back over and I know that I'm starting
> fresh.
Another way of solving the same problem:
cd untarred-sources
git init
git add .
git commit -m 'pristine sources'
Now you can use "git clean" to clean up cruft, not to mention the usual
git stuff like tracking any changes you've made and submitting any
patches upstream.
> I get further. But now test 10 of t0001.sh fails because test_cmp can
> not be found.
>
> Is that a GNU tool? (I didn't see it in git or coreutils.)
It's a shell function defined in test-lib.sh (which is sourced by all of
the test scripts).
-Peff
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort at prompt
From: Caleb Cushing @ 2009-01-28 7:01 UTC (permalink / raw)
To: Junio C Hamano, Charles Bailey, git, Nanako Shiraishi
In-Reply-To: <81bfc67a0901272256t726bf206k351bb6c8b2778bd5@mail.gmail.com>
better? I think I got the formatting fixed... got the imap working...
added a more descriptive commit message. hoping that everything looks
good.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 7:14 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, PJ Hyett, Johannes Schindelin, git
In-Reply-To: <20090128044150.GI1321@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> 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.
Please don't.
I've been toying with an idea for an alternative solution, and need
somebody competent to bounce it around with.
pack-objects ends up doing eventually
rev-list --objects $send1 $send2 $send3 ... --not $have1 $have2 ...
which lists commits and associated objects reachable from $sendN,
excluding the ones that are reachable from $haveN.
The tentative solution Björn Steinbrink and I came up with excludes
missing commit from $haveN to avoid rev-list machinery to barf, but it
violates the ref-object contract as I explained to Björn in my other
message.
Side note. We often cite "interrupted commit walkers" as the
reason why has_sha1_file() is not a good enough check, but you can
discard a deep commit chain by deleting a branch, and have gc
expire older commit in the commit chain while retaining newer ones
near the tip of that branch. If (1) you earlier gave that branch
to somebody else, (2) that somebody else has the tip of the branch
you discarded in his repository, and (3) the repository you are
pushing into borrows from that somebody else's repository, then
you have the same situation that your has_sha1_file() succeeds but
it will fail when you start digging deeper.
Checking if each commit is reachable from any of the refs is quite
expensive, and it would especially be so if it is done once per ".have"
and real ref we receive from the other end.
An alternative is to realize that rev-list traversal already does
something quite similar to what is needed to prove if these ".have"s are
reachable from refs when listing the reachable objects. This computation
is what it needs to do anyway, so if we teach rev-list to ignore missing
or broken chain while traversing negative refs, we do not have to incur
any overhead over existing code.
Here is my work in progress. It introduces "ignore-missing-negative"
option to the revision traversal machinery, and squelches the places we
currently complain loudly and die when we expect an object to be
available, when the color we are going to paint the object with is
UNINTERESTING.
I have a mild suspicion that it may even be the right thing to ignore them
unconditionally, and it might even match the intention of Linus's original
code. That would make many hunks in this patch much simpler.
The evidences behind this suspicion are found in a handful of places in
revision.c. mark_blob_uninteresting() does not complain if the caller
fails to find the blob. mark_tree_uninteresting() does not, either.
mark_parents_uninteresting() does not, either, and it even has a comment
that strongly suggests the original intention was not to care about
missing UNINTERESTING objects.
builtin-pack-objects.c | 1 +
revision.c | 24 ++++++++++++++++++++----
revision.h | 1 +
3 files changed, 22 insertions(+), 4 deletions(-)
diff --git i/builtin-pack-objects.c w/builtin-pack-objects.c
index cedef52..c615a2f 100644
--- i/builtin-pack-objects.c
+++ w/builtin-pack-objects.c
@@ -2026,6 +2026,7 @@ static void get_object_list(int ac, const char **av)
int flags = 0;
init_revisions(&revs, NULL);
+ revs.ignore_missing_negative = 1;
save_commit_buffer = 0;
setup_revisions(ac, av, &revs, NULL);
diff --git i/revision.c w/revision.c
index db60f06..314341b 100644
--- i/revision.c
+++ w/revision.c
@@ -132,6 +132,8 @@ void mark_parents_uninteresting(struct commit *commit)
static void add_pending_object_with_mode(struct rev_info *revs, struct object *obj, const char *name, unsigned mode)
{
+ if (!obj)
+ return;
if (revs->no_walk && (obj->flags & UNINTERESTING))
die("object ranges do not make sense when not walking revisions");
if (revs->reflog_info && obj->type == OBJ_COMMIT &&
@@ -163,8 +165,11 @@ static struct object *get_reference(struct rev_info *revs, const char *name, con
struct object *object;
object = parse_object(sha1);
- if (!object)
+ if (!object) {
+ if (revs->ignore_missing_negative && (flags & UNINTERESTING))
+ return NULL;
die("bad object %s", name);
+ }
object->flags |= flags;
return object;
}
@@ -183,8 +188,11 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object
if (!tag->tagged)
die("bad tag");
object = parse_object(tag->tagged->sha1);
- if (!object)
+ if (!object) {
+ if (revs->ignore_missing_negative && (flags & UNINTERESTING))
+ return NULL;
die("bad object %s", sha1_to_hex(tag->tagged->sha1));
+ }
}
/*
@@ -193,8 +201,11 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object
*/
if (object->type == OBJ_COMMIT) {
struct commit *commit = (struct commit *)object;
- if (parse_commit(commit) < 0)
+ if (parse_commit(commit) < 0) {
+ if (revs->ignore_missing_negative && (flags & UNINTERESTING))
+ return NULL;
die("unable to parse commit %s", name);
+ }
if (flags & UNINTERESTING) {
commit->object.flags |= UNINTERESTING;
mark_parents_uninteresting(commit);
@@ -479,8 +490,11 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
while (parent) {
struct commit *p = parent->item;
parent = parent->next;
- if (parse_commit(p) < 0)
+ if (parse_commit(p) < 0) {
+ if (revs->ignore_missing_negative)
+ return 0;
return -1;
+ }
p->object.flags |= UNINTERESTING;
if (p->parents)
mark_parents_uninteresting(p);
@@ -1110,6 +1124,8 @@ static int handle_revision_opt(struct rev_info *revs, int argc, const char **arg
revs->tree_objects = 1;
revs->blob_objects = 1;
revs->edge_hint = 1;
+ } else if (!strcmp(arg, "--ignore-missing-negative")) {
+ revs->ignore_missing_negative = 1;
} else if (!strcmp(arg, "--unpacked")) {
revs->unpacked = 1;
free(revs->ignore_packed);
diff --git i/revision.h w/revision.h
index 7cf8487..bb90399 100644
--- i/revision.h
+++ w/revision.h
@@ -48,6 +48,7 @@ struct rev_info {
tree_objects:1,
blob_objects:1,
edge_hint:1,
+ ignore_missing_negative:1,
limited:1,
unpacked:1, /* see also ignore_packed below */
boundary:2,
^ permalink raw reply related
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Jeff King @ 2009-01-28 7:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, git
In-Reply-To: <497F021B.2050306@viscovery.net>
On Tue, Jan 27, 2009 at 01:46:19PM +0100, Johannes Sixt wrote:
> Exit code and start_command/finish_command's return code handling is a
> complete mess IMHO and deserves a clean-up series of its own. If the few
Yes, the negation is a bit confusing, just for being allowed to say
if (run_command(foo) < 0)
since you end up having to store and re-negate anyway to get the actual
code. Plus the value of errno is untrustworthy, since we may have been
doing cleanup calls.
> codes at 10000 and above are truncated to 8 bits, then we get exit codes
> 16 and higher; I think that's good enough for this series.
I think it is nice to differentiate between an exit code from the
sub-program and our own error, though. See my updated series for what I
think is a reasonable one-liner fix.
-Peff
^ permalink raw reply
* feature needed imap-send pass as cli switch
From: Caleb Cushing @ 2009-01-28 7:18 UTC (permalink / raw)
To: git
I tend to have my .gitconfig shared on github with a bunch of other
config files and this has been ok, until submitting a patch here I
needed to use imap-send, and the only way I see in the documentation
is to put my email password in .gitconfig, obviously I can't push this
up to my remote as I usually do. I'd like to see an option to pass the
password on the cli, either as an input prompt or as just an argument
to an option, or both. I think storing it in the config file is a
security risk, storing passwords in plaintext is just bad practice.
if it's already possible could someone share how with me? and perhaps
patch the documentation to include how.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* Re: [PATCH] Windows: Fix intermittent failures of t7701
From: Johannes Sixt @ 2009-01-28 7:26 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901271740320.3586@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> I use this trick in my valgrind series:
>
> ($PROGRAM; echo $? > exit.code) | $OTHER_PROGRAM &&
> test 0 = "$(cat exit.code)"
Ah, using a file as temporary storage? Why not simply
$PROGRAM > data &&
$OTHER_PROGRAM < data
Hm? ;)
-- Hannes
^ permalink raw reply
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Jeff King @ 2009-01-28 7:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901271728130.3586@pacific.mpi-cbg.de>
On Tue, Jan 27, 2009 at 05:31:02PM +0100, Johannes Schindelin wrote:
> I like the patch series, well designed and concise (especially with the
> fixes Hannes proposed).
Good. Response seems positive, so I will drop the RFC, then, and post a
fixed-up series meant for inclusion.
> > There are two potential downsides to the fix:
> >
> > 1. There is an extra fork and a parent process sitting in memory for
> > dashed externals. This is pretty necessary to any fix, since
> > something has to wait to do pager cleanup, and we can't rely on the
> > child to do so.
>
> Actually, I think this is a good thing; that way, we can catch
> segmentation fault properly and display an error message in the pager.
> That was not possible previously.
True. On the other hand, most of our externals are shell scripts. It's
the builtins that segfault, and we don't have a watcher process for
that. :)
-Peff
^ permalink raw reply
* [PATCHv2 1/4] git: s/run_command/run_builtin/
From: Jeff King @ 2009-01-28 7:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20090128073059.GD19165@coredump.intra.peff.net>
There is a static function called run_command which
conflicts with the library function in run-command.c; this
isn't a problem currently, but prevents including
run-command.h in git.c.
This patch just renames the static function to something
more specific and non-conflicting.
Signed-off-by: Jeff King <peff@peff.net>
---
Same as before.
git.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index ecc8fad..45e493d 100644
--- a/git.c
+++ b/git.c
@@ -219,7 +219,7 @@ struct cmd_struct {
int option;
};
-static int run_command(struct cmd_struct *p, int argc, const char **argv)
+static int run_builtin(struct cmd_struct *p, int argc, const char **argv)
{
int status;
struct stat st;
@@ -384,7 +384,7 @@ static void handle_internal_command(int argc, const char **argv)
struct cmd_struct *p = commands+i;
if (strcmp(p->cmd, cmd))
continue;
- exit(run_command(p, argc, argv));
+ exit(run_builtin(p, argc, argv));
}
}
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* [PATCHv2 2/4] run_command: handle missing command errors more gracefully
From: Jeff King @ 2009-01-28 7:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20090128073059.GD19165@coredump.intra.peff.net>
When run_command was asked to run a non-existant command,
its behavior varied depending on the platform:
- on POSIX systems, we would fork, and then after the
execvp call failed, we could call die(), which prints a
message to stderr and exits with code 128.
- on Windows, we do a PATH lookup, realize the program
isn't there, and then return ERR_RUN_COMMAND_FORK
The goal of this patch is to make it clear to callers that
the specific error was a missing command. To do this, we
will return the error code ERR_RUN_COMMAND_EXEC, which is
already defined in run-command.h, checked for in several
places, but never actually gets set.
The new behavior is:
- on POSIX systems, we exit the forked process with code
127 (the same as the shell uses to report missing
commands). The parent process recognizes this code and
returns an EXEC error. The stderr message is silenced,
since the caller may be speculatively trying to run a
command. Instead, we use trace_printf so that somebody
interested in debugging can see the error that occured.
- on Windows, we check errno, which is already set
correctly by mingw_spawnvpe, and report an EXEC error
instead of a FORK error
Thus it is safe to speculatively run a command:
int r = run_command_v_opt(argv, 0);
if (r == -ERR_RUN_COMMAND_EXEC)
/* oops, it wasn't found; try something else */
else
/* we failed for some other reason, error is in r */
Signed-off-by: Jeff King <peff@peff.net>
---
Incorporates JSixt's fix to retain errno across system calls.
run-command.c | 18 ++++++++++++++----
1 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/run-command.c b/run-command.c
index db9ce59..b05c734 100644
--- a/run-command.c
+++ b/run-command.c
@@ -118,7 +118,9 @@ int start_command(struct child_process *cmd)
} else {
execvp(cmd->argv[0], (char *const*) cmd->argv);
}
- die("exec %s failed.", cmd->argv[0]);
+ trace_printf("trace: exec '%s' failed: %s\n", cmd->argv[0],
+ strerror(errno));
+ exit(127);
}
#else
int s0 = -1, s1 = -1, s2 = -1; /* backups of stdin, stdout, stderr */
@@ -187,6 +189,7 @@ int start_command(struct child_process *cmd)
#endif
if (cmd->pid < 0) {
+ int err = errno;
if (need_in)
close_pair(fdin);
else if (cmd->in)
@@ -197,7 +200,9 @@ int start_command(struct child_process *cmd)
close(cmd->out);
if (need_err)
close_pair(fderr);
- return -ERR_RUN_COMMAND_FORK;
+ return err == ENOENT ?
+ -ERR_RUN_COMMAND_EXEC :
+ -ERR_RUN_COMMAND_FORK;
}
if (need_in)
@@ -236,9 +241,14 @@ static int wait_or_whine(pid_t pid)
if (!WIFEXITED(status))
return -ERR_RUN_COMMAND_WAITPID_NOEXIT;
code = WEXITSTATUS(status);
- if (code)
+ switch (code) {
+ case 127:
+ return -ERR_RUN_COMMAND_EXEC;
+ case 0:
+ return 0;
+ default:
return -code;
- return 0;
+ }
}
}
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* [PATCHv2 3/4] run-command: help callers distinguish errors
From: Jeff King @ 2009-01-28 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20090128073059.GD19165@coredump.intra.peff.net>
run_command returns a single integer specifying either an
error code or the exit status of the spawned program. The
only way to tell the difference is that the error codes are
outside of the allowed range of exit status values.
Rather than make each caller implement the test against a
magic limit, let's provide a macro.
Signed-off-by: Jeff King <peff@peff.net>
---
New since v1 of the series.
run-command.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/run-command.h b/run-command.h
index 0211e1d..a88b3cd 100644
--- a/run-command.h
+++ b/run-command.h
@@ -10,6 +10,7 @@ enum {
ERR_RUN_COMMAND_WAITPID_SIGNAL,
ERR_RUN_COMMAND_WAITPID_NOEXIT,
};
+#define IS_RUN_COMMAND_ERR(x) (x >= ERR_RUN_COMMAND_FORK)
struct child_process {
const char **argv;
--
1.6.1.1.367.g30b36
^ 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