* Re: Bus Error- git merge
From: Brian Moran @ 2009-01-31 0:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git@vger.kernel.org
In-Reply-To: <alpine.DEB.1.00.0901301950100.3586@pacific.mpi-cbg.de>
With subsequent changes to the merged-to repository, the bug does not
manifest. I will attempt to reproduce when we encounter it next.
On 1/30/09 10:57 AM, "Johannes Schindelin" <Johannes.Schindelin@gmx.de>
wrote:
> Hi,
>
> On Fri, 30 Jan 2009, Brian Moran wrote:
>
>> I am getting a bus error on a git merge, including the more recent versions.
>> Following the instructions from a bug August, I got the latest sources,
>> compiled them up, and executed the merge in the debugger to repro. Here¹s
>> what I found:
>
> Is it possible that your branch has submodules?
>
^ permalink raw reply
* Re: [PATCH v2 3/5] chain kill signals for cleanup functions
From: Junio C Hamano @ 2009-01-31 0:28 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, git
In-Reply-To: <20090130082101.GA28809@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Fri, Jan 30, 2009 at 09:13:00AM +0100, Johannes Sixt wrote:
>
>> Jeff King schrieb:
>> > One fix would be to just "signal(SIGINT, SIG_DFL)" at the top. But I
>> > think it makes the test cleaner to just switch to a more reliable
>> > signal. The patch would look something like what is below. But I need to
>> > know what exit code Windows generates for SIGTERM. Johannes?
>>
>> The same as with SIGINT: 3.
>
> Hmm. Clever.
>
> Junio, can you apply this on top of the jk/signal-cleanup topic?
Will do, but I've been sick today, haven't caught up with the list
traffic, and I do not think I'll be reading my mails for the rest of the
day either. It may take some time for it to appear in the public
repositories.
Thanks.
^ permalink raw reply
* Re: Newbie question regarding 3way merge order.
From: Sitaram Chamarty @ 2009-01-31 0:32 UTC (permalink / raw)
To: git
In-Reply-To: <87vdrwbofv.fsf@gigli.quasi.internal>
On 2009-01-30, Raimund Berger <raimund.berger@gmail.com> wrote:
> E.g. with A, B and ancestor C, the merging and conflict resolution
> algorithm had to be completely symmetric if diff(A,C)+diff(B,C) applied
> to C should always be the same as diff(B,C)+diff(A,C) applied to C.
> So I'm really asking if that is a fact upon which I can rely.
I've always relied on it :-) Or, to put it another way,
I've never come been bitten by this issue.
> An interesting hint. Up to now, I assumed that rebase would always
> perform implicit merging strategies. I mean what else would one expect
It does.
> in the above picture to happen when rebasing A on B? I'd assume it'd
> produce the same tree as a merge of A into B, by employing exactly the
> same machinery. E.g. fast forward of C to B, then merge A in. So that,
> effectively, the only difference between rebase and merge is just commit
> history but not (tree) content.
This is also true. For example, "git help pull" offers an
option to use rebase instead of merge.
> From reading the rebase man page though it seems that merging machinery
> has to be explicitly requested via '-m'. Which makes me wonder how the
> default rebase actually works.
No. I think the documentation is not sufficiently clear.
Everything else in "git help rebase" (look for the string
"strateg") tells me that the default, if you don't specify
anything at all, is the recursive merge strategy. Since
"-s" implies "-m", I'm not sure what -- if anything -- is
achived by "-m" all by itself.
When I get some time I'm planning to look at the test
scripts and simulate them without "-m" to see what
differences there are; I'd assume a test script set up to
test the proper operation of rebase --merge should be using
a test case whose result differs if you dont use --merge!
> Mathematically speaking, if A1 and A2 commute with regard to a binary
> operation, A1 ... An do as well. So I'd still think the latter question
> boils down to the commutativity question above *iff* rebase actually
> does an implicit merge by default. Which I'm now led to question.
Rebase *does* do an implicit merge by default (as far as the
tree that results is concerned, which you mentioned right at
the start), I'm pretty sure of it.
Perhaps someone with more git smarts will chip in with
something more concrete.
^ permalink raw reply
* [PATCH v2] Add getTaggerIdent, getShortMessage, getFullMessage to RevTag
From: Shawn O. Pearce @ 2009-01-31 0:56 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git
In-Reply-To: <200901282110.48899.robin.rosenberg.lists@dewire.com>
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>
---
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> Where are the unit tests?
New test file included.
> I'm kind of surprised you did not optimized skipping past the object header,
> like the parents are skipped when parsing commits.
Also included. Otherwise unmodified from v1.
.../org/spearce/jgit/revwalk/RevTagParseTest.java | 350 ++++++++++++++++++++
.../src/org/spearce/jgit/revwalk/RevCommit.java | 2 +-
.../src/org/spearce/jgit/revwalk/RevTag.java | 74 ++++-
.../src/org/spearce/jgit/util/RawParseUtils.java | 51 +++-
4 files changed, 473 insertions(+), 4 deletions(-)
create mode 100644 org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevTagParseTest.java
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevTagParseTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevTagParseTest.java
new file mode 100644
index 0000000..82680f3
--- /dev/null
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/revwalk/RevTagParseTest.java
@@ -0,0 +1,350 @@
+/*
+ * Copyright (C) 2008, Google Inc.
+ *
+ * All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or
+ * without modification, are permitted provided that the following
+ * conditions are met:
+ *
+ * - Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ *
+ * - Redistributions in binary form must reproduce the above
+ * copyright notice, this list of conditions and the following
+ * disclaimer in the documentation and/or other materials provided
+ * with the distribution.
+ *
+ * - Neither the name of the Git Development Community nor the
+ * names of its contributors may be used to endorse or promote
+ * products derived from this software without specific prior
+ * written permission.
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
+ * CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
+ * INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
+ * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR
+ * CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+ * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
+ * ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+package org.spearce.jgit.revwalk;
+
+import java.io.ByteArrayOutputStream;
+
+import org.spearce.jgit.lib.Constants;
+import org.spearce.jgit.lib.ObjectId;
+import org.spearce.jgit.lib.PersonIdent;
+import org.spearce.jgit.lib.RepositoryTestCase;
+
+public class RevTagParseTest extends RepositoryTestCase {
+ public void testTagBlob() throws Exception {
+ testOneType(Constants.OBJ_BLOB);
+ }
+
+ public void testTagTree() throws Exception {
+ testOneType(Constants.OBJ_TREE);
+ }
+
+ public void testTagCommit() throws Exception {
+ testOneType(Constants.OBJ_COMMIT);
+ }
+
+ public void testTagTag() throws Exception {
+ testOneType(Constants.OBJ_TAG);
+ }
+
+ private void testOneType(final int typeCode) throws Exception {
+ final ObjectId id = id("9788669ad918b6fcce64af8882fc9a81cb6aba67");
+ final StringBuilder b = new StringBuilder();
+ b.append("object " + id.name() + "\n");
+ b.append("type " + Constants.typeString(typeCode) + "\n");
+ b.append("tag v1.2.3.4.5\n");
+ b.append("tagger A U. Thor <a_u_thor@example.com> 1218123387 +0700\n");
+ b.append("\n");
+
+ final RevWalk rw = new RevWalk(db);
+ final RevTag c;
+
+ c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
+ assertNull(c.getObject());
+ assertNull(c.getName());
+
+ c.parseCanonical(rw, b.toString().getBytes("UTF-8"));
+ assertNotNull(c.getObject());
+ assertEquals(id, c.getObject().getId());
+ assertSame(rw.lookupAny(id, typeCode), c.getObject());
+ }
+
+ public void testParseAllFields() throws Exception {
+ final ObjectId treeId = id("9788669ad918b6fcce64af8882fc9a81cb6aba67");
+ final String name = "v1.2.3.4.5";
+ final String taggerName = "A U. Thor";
+ final String taggerEmail = "a_u_thor@example.com";
+ final int taggerTime = 1218123387;
+
+ final StringBuilder body = new StringBuilder();
+
+ body.append("object ");
+ body.append(treeId.name());
+ body.append("\n");
+
+ body.append("type tree\n");
+
+ body.append("tag ");
+ body.append(name);
+ body.append("\n");
+
+ body.append("tagger ");
+ body.append(taggerName);
+ body.append(" <");
+ body.append(taggerEmail);
+ body.append("> ");
+ body.append(taggerTime);
+ body.append(" +0700\n");
+
+ body.append("\n");
+
+ final RevWalk rw = new RevWalk(db);
+ final RevTag c;
+
+ c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
+ assertNull(c.getObject());
+ assertNull(c.getName());
+
+ c.parseCanonical(rw, body.toString().getBytes("UTF-8"));
+ assertNotNull(c.getObject());
+ assertEquals(treeId, c.getObject().getId());
+ assertSame(rw.lookupTree(treeId), c.getObject());
+
+ assertNotNull(c.getName());
+ assertEquals(name, c.getName());
+ assertEquals("", c.getFullMessage());
+
+ final PersonIdent cTagger = c.getTaggerIdent();
+ assertNotNull(cTagger);
+ assertEquals(taggerName, cTagger.getName());
+ assertEquals(taggerEmail, cTagger.getEmailAddress());
+ }
+
+ private RevTag create(final String msg) throws Exception {
+ final StringBuilder b = new StringBuilder();
+ b.append("object 9788669ad918b6fcce64af8882fc9a81cb6aba67\n");
+ b.append("type tree\n");
+ b.append("tag v1.2.3.4.5\n");
+ b.append("tagger A U. Thor <a_u_thor@example.com> 1218123387 +0700\n");
+ b.append("\n");
+ b.append(msg);
+
+ final RevTag c;
+ c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
+ c.parseCanonical(new RevWalk(db), b.toString().getBytes("UTF-8"));
+ return c;
+ }
+
+ public void testParse_implicit_UTF8_encoded() throws Exception {
+ final ByteArrayOutputStream b = new ByteArrayOutputStream();
+ b.write("object 9788669ad918b6fcce64af8882fc9a81cb6aba67\n"
+ .getBytes("UTF-8"));
+ b.write("type tree\n".getBytes("UTF-8"));
+ b.write("tag v1.2.3.4.5\n".getBytes("UTF-8"));
+
+ b
+ .write("tagger F\u00f6r fattare <a_u_thor@example.com> 1218123387 +0700\n"
+ .getBytes("UTF-8"));
+ b.write("\n".getBytes("UTF-8"));
+ b.write("Sm\u00f6rg\u00e5sbord\n".getBytes("UTF-8"));
+ b.write("\n".getBytes("UTF-8"));
+ b.write("\u304d\u308c\u3044\n".getBytes("UTF-8"));
+ final RevTag c;
+ c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
+ c.parseCanonical(new RevWalk(db), b.toByteArray());
+
+ assertEquals("F\u00f6r fattare", c.getTaggerIdent().getName());
+ assertEquals("Sm\u00f6rg\u00e5sbord", c.getShortMessage());
+ assertEquals("Sm\u00f6rg\u00e5sbord\n\n\u304d\u308c\u3044\n", c
+ .getFullMessage());
+ }
+
+ public void testParse_implicit_mixed_encoded() throws Exception {
+ final ByteArrayOutputStream b = new ByteArrayOutputStream();
+ b.write("object 9788669ad918b6fcce64af8882fc9a81cb6aba67\n"
+ .getBytes("UTF-8"));
+ b.write("type tree\n".getBytes("UTF-8"));
+ b.write("tag v1.2.3.4.5\n".getBytes("UTF-8"));
+ b
+ .write("tagger F\u00f6r fattare <a_u_thor@example.com> 1218123387 +0700\n"
+ .getBytes("ISO-8859-1"));
+ b.write("\n".getBytes("UTF-8"));
+ b.write("Sm\u00f6rg\u00e5sbord\n".getBytes("UTF-8"));
+ b.write("\n".getBytes("UTF-8"));
+ b.write("\u304d\u308c\u3044\n".getBytes("UTF-8"));
+ final RevTag c;
+ c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
+ c.parseCanonical(new RevWalk(db), b.toByteArray());
+
+ assertEquals("F\u00f6r fattare", c.getTaggerIdent().getName());
+ assertEquals("Sm\u00f6rg\u00e5sbord", c.getShortMessage());
+ assertEquals("Sm\u00f6rg\u00e5sbord\n\n\u304d\u308c\u3044\n", c
+ .getFullMessage());
+ }
+
+ /**
+ * Test parsing of a commit whose encoding is given and works.
+ *
+ * @throws Exception
+ */
+ public void testParse_explicit_encoded() throws Exception {
+ final ByteArrayOutputStream b = new ByteArrayOutputStream();
+ b.write("object 9788669ad918b6fcce64af8882fc9a81cb6aba67\n"
+ .getBytes("EUC-JP"));
+ b.write("type tree\n".getBytes("EUC-JP"));
+ b.write("tag v1.2.3.4.5\n".getBytes("EUC-JP"));
+ b
+ .write("tagger F\u00f6r fattare <a_u_thor@example.com> 1218123387 +0700\n"
+ .getBytes("EUC-JP"));
+ b.write("encoding euc_JP\n".getBytes("EUC-JP"));
+ b.write("\n".getBytes("EUC-JP"));
+ b.write("\u304d\u308c\u3044\n".getBytes("EUC-JP"));
+ b.write("\n".getBytes("EUC-JP"));
+ b.write("Hi\n".getBytes("EUC-JP"));
+ final RevTag c;
+ c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
+ c.parseCanonical(new RevWalk(db), b.toByteArray());
+
+ assertEquals("F\u00f6r fattare", c.getTaggerIdent().getName());
+ assertEquals("\u304d\u308c\u3044", c.getShortMessage());
+ assertEquals("\u304d\u308c\u3044\n\nHi\n", c.getFullMessage());
+ }
+
+ /**
+ * This is a twisted case, but show what we expect here. We can revise the
+ * expectations provided this case is updated.
+ *
+ * What happens here is that an encoding us given, but data is not encoded
+ * that way (and we can detect it), so we try other encodings.
+ *
+ * @throws Exception
+ */
+ public void testParse_explicit_bad_encoded() throws Exception {
+ final ByteArrayOutputStream b = new ByteArrayOutputStream();
+ b.write("object 9788669ad918b6fcce64af8882fc9a81cb6aba67\n"
+ .getBytes("UTF-8"));
+ b.write("type tree\n".getBytes("UTF-8"));
+ b.write("tag v1.2.3.4.5\n".getBytes("UTF-8"));
+ b
+ .write("tagger F\u00f6r fattare <a_u_thor@example.com> 1218123387 +0700\n"
+ .getBytes("ISO-8859-1"));
+ b.write("encoding EUC-JP\n".getBytes("UTF-8"));
+ b.write("\n".getBytes("UTF-8"));
+ b.write("\u304d\u308c\u3044\n".getBytes("UTF-8"));
+ b.write("\n".getBytes("UTF-8"));
+ b.write("Hi\n".getBytes("UTF-8"));
+ final RevTag c;
+ c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
+ c.parseCanonical(new RevWalk(db), b.toByteArray());
+
+ assertEquals("F\u00f6r fattare", c.getTaggerIdent().getName());
+ assertEquals("\u304d\u308c\u3044", c.getShortMessage());
+ assertEquals("\u304d\u308c\u3044\n\nHi\n", c.getFullMessage());
+ }
+
+ /**
+ * This is a twisted case too, but show what we expect here. We can revise
+ * the expectations provided this case is updated.
+ *
+ * What happens here is that an encoding us given, but data is not encoded
+ * that way (and we can detect it), so we try other encodings. Here data
+ * could actually be decoded in the stated encoding, but we override using
+ * UTF-8.
+ *
+ * @throws Exception
+ */
+ public void testParse_explicit_bad_encoded2() throws Exception {
+ final ByteArrayOutputStream b = new ByteArrayOutputStream();
+ b.write("object 9788669ad918b6fcce64af8882fc9a81cb6aba67\n"
+ .getBytes("UTF-8"));
+ b.write("type tree\n".getBytes("UTF-8"));
+ b.write("tag v1.2.3.4.5\n".getBytes("UTF-8"));
+ b
+ .write("tagger F\u00f6r fattare <a_u_thor@example.com> 1218123387 +0700\n"
+ .getBytes("UTF-8"));
+ b.write("encoding ISO-8859-1\n".getBytes("UTF-8"));
+ b.write("\n".getBytes("UTF-8"));
+ b.write("\u304d\u308c\u3044\n".getBytes("UTF-8"));
+ b.write("\n".getBytes("UTF-8"));
+ b.write("Hi\n".getBytes("UTF-8"));
+ final RevTag c;
+ c = new RevTag(id("9473095c4cb2f12aefe1db8a355fe3fafba42f67"));
+ c.parseCanonical(new RevWalk(db), b.toByteArray());
+
+ assertEquals("F\u00f6r fattare", c.getTaggerIdent().getName());
+ assertEquals("\u304d\u308c\u3044", c.getShortMessage());
+ assertEquals("\u304d\u308c\u3044\n\nHi\n", c.getFullMessage());
+ }
+
+ public void testParse_NoMessage() throws Exception {
+ final String msg = "";
+ final RevTag c = create(msg);
+ assertEquals(msg, c.getFullMessage());
+ assertEquals(msg, c.getShortMessage());
+ }
+
+ public void testParse_OnlyLFMessage() throws Exception {
+ final RevTag c = create("\n");
+ assertEquals("\n", c.getFullMessage());
+ assertEquals("", c.getShortMessage());
+ }
+
+ public void testParse_ShortLineOnlyNoLF() throws Exception {
+ final String shortMsg = "This is a short message.";
+ final RevTag c = create(shortMsg);
+ assertEquals(shortMsg, c.getFullMessage());
+ assertEquals(shortMsg, c.getShortMessage());
+ }
+
+ public void testParse_ShortLineOnlyEndLF() throws Exception {
+ final String shortMsg = "This is a short message.";
+ final String fullMsg = shortMsg + "\n";
+ final RevTag c = create(fullMsg);
+ assertEquals(fullMsg, c.getFullMessage());
+ assertEquals(shortMsg, c.getShortMessage());
+ }
+
+ public void testParse_ShortLineOnlyEmbeddedLF() throws Exception {
+ final String fullMsg = "This is a\nshort message.";
+ final String shortMsg = fullMsg.replace('\n', ' ');
+ final RevTag c = create(fullMsg);
+ assertEquals(fullMsg, c.getFullMessage());
+ assertEquals(shortMsg, c.getShortMessage());
+ }
+
+ public void testParse_ShortLineOnlyEmbeddedAndEndingLF() throws Exception {
+ final String fullMsg = "This is a\nshort message.\n";
+ final String shortMsg = "This is a short message.";
+ final RevTag c = create(fullMsg);
+ assertEquals(fullMsg, c.getFullMessage());
+ assertEquals(shortMsg, c.getShortMessage());
+ }
+
+ public void testParse_GitStyleMessage() throws Exception {
+ final String shortMsg = "This fixes a bug.";
+ final String body = "We do it with magic and pixie dust and stuff.\n"
+ + "\n" + "Signed-off-by: A U. Thor <author@example.com>\n";
+ final String fullMsg = shortMsg + "\n" + "\n" + body;
+ final RevTag c = create(fullMsg);
+ assertEquals(fullMsg, c.getFullMessage());
+ assertEquals(shortMsg, c.getShortMessage());
+ }
+
+ private static ObjectId id(final String str) {
+ return ObjectId.fromString(str);
+ }
+}
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..1b8bf94 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,34 @@ 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;
+ if (ptr == 0)
+ ptr += 48; // skip the "object ..." line.
+ 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 +677,27 @@ 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;
+ if (ptr == 0)
+ ptr += 48; // skip the "object ..." line.
while (ptr < sz && b[ptr] != '\n')
ptr = nextLF(b, ptr);
if (ptr < sz && b[ptr] == '\n')
--
1.6.1.2.418.gd79e6
--
Shawn.
^ permalink raw reply related
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Nanako Shiraishi @ 2009-01-31 0:56 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jay Soffian, git, gitster
In-Reply-To: <alpine.DEB.1.00.0901301959300.3586@pacific.mpi-cbg.de>
Quoting Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> You cannot just cater for one workflow and fsck the other workflows over.
>
> You'll have to devise a method that helps the workflow you are interested
> in, but leaves the others alone.
I think you'd want to repeat that to yourself when you propose to switch
the default for denyCurrentcurrentBranch config to "true" too hastily the
next time?
I don't think your patch matches the tradition of how defaults are changed
in git project. You don't introduce a large change just after the maintainer
hints about going into a freeze for 1.X.Y release when Y isn't zero.
I assume that everybody, including the maintainer who is too heavyweight
and has too much inertia to accept too sudden a change of the course,
wants to eventually make the default to deny pushing to the current
branch. But I think such a change should come at 1.7.0 release at the
earliest, and a constructive thing to do is to put in a patch to 1.6.2
that helps the users with the eventual transition.
How about doing these before the 1.7.0 release?
1. Add some code to git-clone to set the config to "deny" if it is
not a bare repository. The reason I think this makes sense is
because the reason why old-timers want to push into the current
branch is because they are used to the old layout that doesn't use
separate remotes. If they use today's git-clone and still want to
use the old layout, they need to update the config file in the new
clone anyway. The "deny" is just another thing for them to fix at
that point.
I suspect that Junio will not like this in 1.6.2 because it is an
unannounced and unplanned change in behavior, but I think it is a
reasonable preparatory step, probably in 1.6.3, before you change
the default to deny in release 1.7.0.
2. Reword the warning message as Junio suggested in his response. I
don't know the details of the code very well, but I think you can
tell a repository that doesn't have the config at all from a
repository that has the config set to "warn", and you can use
"annoyingly long" (in Junio's words) message to force the user set
the config to a desired value only when pushing into the former
kind, and say that the default will change to deny in release
1.7.0. When pushing into the latter, the warning message can be
shorter (probably you can say "warning: updating the current
branch in a non-bare repository" and nothing else).
3. Reword the error message as you proposed to say "error: won't
update the current branch in a non-bare repository", without
saying anything else. You want to eventually change the default to
deny, and there is no point to teach how to allow it to people who
set the config to deny themselves, nor to new people who created
their repository with updated git-clone.
I think this makes sense to do in 1.6.2 release, because the only
people who will see this message will be the people who set the
config to deny themselves, especially if you postpone the change
to git-clone for the upcoming release.
What do people think?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Newbie question regarding 3way merge order.
From: Nanako Shiraishi @ 2009-01-31 0:57 UTC (permalink / raw)
To: Raimund Berger; +Cc: git
In-Reply-To: <871vulda2r.fsf@gigli.quasi.internal>
Quoting "Raimund Berger" <raimund.berger@gmail.com>:
> The question is whether a (3way) merge is commutative, purely in terms
> of content (i.e. disregarding commit history for now). Iow if no matter
> in which order I merge A and B, i.e. A into B or B into A, I'd be
> guaranteed to arrive at the same content.
I think three-way merge of A into B and B into A will produce the same
result when the merge doesn't conflict (when it does, you will get the
conflict markers and text from A and B in a different order depending on
the direction of the merge).
> The reason I ask is obvious I guess. What basically interests me is if I
> gave a bunch of topic branches exposure on a test branch and, after
> resolving issues, applied them to stable, that I could be 100% sure to
> not introduce new issues content wise just by applying merges in a
> different order or form (rebase, patch set).
I don't think you can make a blanket conclusion like that by only knowing
that merging A into B and merging B into A would produce the same result.
If you merge topics A, B, and C in this order into your current state O,
there may not be any conflict, but if you merge the same topics to the
same current state in different order, C, B and then A for example, you
may get conflicts that breaks the merge. The commutativeness only says
that merge of A into O will produce the same result as merge of O into A.
It doesn't say anything about what would happen when you merge B to O.
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCHv4 1/2] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-31 1:14 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1233139832-24124-1-git-send-email-giuseppe.bilotta@gmail.com>
On Wed, 28 Jan 2009, Giuseppe Bilotta wrote:
> When gitweb is invoked with PATH_INFO and links to static files such as
> the CSS and favicon/shortcut icon are relative URLs with relative paths
> (as is the case when using the default Makefile), these files are not
> accessible beyond the project list and summary page (e.g. in shortlog or
> commit view).
>
> Fix this by adding a <base> tag pointing to the script's own URL, that
> ensure that all relative paths will be based on this.
I think it is a very good idea, good patch (now with esc_url, just in
case, even though I think it should be needed), and commit message has
all info that it should have. But I think that it could be phrased
better: instead of one long sentence, perhaps split it into few
sentences, each dealing with one issue. Something like below:
-- >8 --
Gitweb links to a few static files: CSS stylesheet, favicon/shortcut
icon and git logo. When links to those files are given by relative
URLs with relative paths (not starting with '/'), and gitweb is invoked
with (non empty) PATH_INFO, these files are not accessible beyond
projects list and 'summary' view for a project (e.g. in 'shortlog' or
'commit' view). Default Makefile rules use base filenames for those
static files.
Fix this by adding <base> element pointing to script's own URL,
which ensures that all relative paths relative URLs will be resolved
correctly.
-- 8< --
Gaaahhh... I think this version could be better, but I cannot think
how it should look like...
>
> Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
> ---
> gitweb/gitweb.perl | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 931db4f..f7aaf9a 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -2901,6 +2901,11 @@ sub git_header_html {
> <meta name="robots" content="index, nofollow"/>
> <title>$title</title>
> EOF
> +# the stylesheet, favicon etc urls won't work correctly with path_info unless we
> +# set the appropriate base URL
BTW. I think there should be independent patch making those comments
indented properly...
> + if ($ENV{'PATH_INFO'}) {
> + print "<base href='".esc_url($my_url)."' />\n";
Errr... here we use ' as attribute delimiter, while everywhere else
we use "; I don't know if esc_url deals correctly with this... it does
as neither " nor ' is in "allowed" list, but I'd personally use
+ print '<base href="'.esc_url($my_url).'" />'."\n";
> + }
> # print out each stylesheet that exist
> if (defined $stylesheet) {
> #provides backwards capability for those people who define style sheet in a config file
> --
> 1.5.6.5
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [EGIT] Blame functionality update
From: Shawn O. Pearce @ 2009-01-31 1:26 UTC (permalink / raw)
To: Manuel Woelker; +Cc: Robin Rosenberg, git
In-Reply-To: <200901292156.51906.robin.rosenberg.lists@dewire.com>
Robin Rosenberg <robin.rosenberg.lists@dewire.com> wrote:
> torsdag 29 januari 2009 18:35:28 skrev Manuel Woelker:
> > Hi folks,
> >
> > quick update about the state of blame functionality in my egit branch
> > at http://github.com/manuel-woelker/egit/tree/blame
> > Screen shot here: http://docs.google.com/View?docid=df5rvczr_3f46vd2ds
>
> Impressive!. Someone's been busy :)
+1. This is very nice.
--
Shawn.
^ permalink raw reply
* [PATCHv5 0/3] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-31 1:31 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
This patchset includes
1. the single patch to make static files accessible with PATH_INFO, with
the same quoting standard as the nearby code;
2. an additional patch that extends the README with some examples on how
to configure Apache to use gitweb with PATH_INFO enabled by default
(and gitweb as directory index);
3. the repeatedly recommended comment fix to align comments to code in the
git_header_html() sub.
Giuseppe Bilotta (3):
gitweb: make static files accessible with PATH_INFO
gitweb: webserver config for PATH_INFO
gitweb: align comments to code
gitweb/README | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++
gitweb/gitweb.perl | 9 +++++-
2 files changed, 83 insertions(+), 2 deletions(-)
^ permalink raw reply
* [PATCHv5 1/3] gitweb: make static files accessible with PATH_INFO
From: Giuseppe Bilotta @ 2009-01-31 1:31 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1233365512-7130-1-git-send-email-giuseppe.bilotta@gmail.com>
Gitweb links to a number of static files such as CSS stylesheets,
favicon or the git logo. When, such as with the default Makefile, the
paths to these files are relative (i.e. doesn't start with a "/"), the
files become inaccessible in any view other tha project list and summary
page if gitweb is invoked with a non-empty PATH_INFO.
Fix this by adding a <base> element pointing to the script's own URL,
which ensure that all relative paths will be resolved correctly.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 931db4f..538bd5a 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,6 +2901,11 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
+# the stylesheet, favicon etc urls won't work correctly with path_info unless we
+# set the appropriate base URL
+ if ($ENV{'PATH_INFO'}) {
+ print '<base href="'.esc_url($my_url).'" />\n';
+ }
# print out each stylesheet that exist
if (defined $stylesheet) {
#provides backwards capability for those people who define style sheet in a config file
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 3/3] gitweb: align comments to code
From: Giuseppe Bilotta @ 2009-01-31 1:31 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1233365512-7130-3-git-send-email-giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 538bd5a..c5f0130 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2901,14 +2901,14 @@ sub git_header_html {
<meta name="robots" content="index, nofollow"/>
<title>$title</title>
EOF
-# the stylesheet, favicon etc urls won't work correctly with path_info unless we
-# set the appropriate base URL
+ # the stylesheet, favicon etc urls won't work correctly with path_info
+ # unless we set the appropriate base URL
if ($ENV{'PATH_INFO'}) {
print '<base href="'.esc_url($my_url).'" />\n';
}
-# print out each stylesheet that exist
+ # print out each stylesheet that exist, providing backwards capability
+ # for those people who defined $stylesheet in a config file
if (defined $stylesheet) {
-#provides backwards capability for those people who define style sheet in a config file
print '<link rel="stylesheet" type="text/css" href="'.$stylesheet.'"/>'."\n";
} else {
foreach my $stylesheet (@stylesheets) {
--
1.5.6.5
^ permalink raw reply related
* [PATCHv5 2/3] gitweb: webserver config for PATH_INFO
From: Giuseppe Bilotta @ 2009-01-31 1:31 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1233365512-7130-2-git-send-email-giuseppe.bilotta@gmail.com>
Document some possible Apache configurations when the path_info feature
is enabled in gitweb.
---
gitweb/README | 76 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/gitweb/README b/gitweb/README
index 825162a..52ad88b 100644
--- a/gitweb/README
+++ b/gitweb/README
@@ -322,6 +322,82 @@ something like the following in your gitweb.conf (or gitweb_config.perl) file:
$home_link = "/";
+PATH_INFO usage
+-----------------------
+If you enable PATH_INFO usage in gitweb by putting
+
+ $feature{'pathinfo'}{'default'} = [1];
+
+in your gitweb.conf, it is possible to set up your server so that it
+consumes and produces URLs in the form
+
+http://git.example.com/project.git/shortlog/sometag
+
+by using a configuration such as the following, that assumes that
+/var/www/gitweb is the DocumentRoot of your webserver, and that it
+contains the gitweb.cgi script and complementary static files
+(stylesheet, favicon):
+
+<VirtualHost *:80>
+ ServerAlias git.example.com
+
+ DocumentRoot /var/www/gitweb
+
+ <Directory /var/www/gitweb>
+ Options ExecCGI
+ AddHandler cgi-script cgi
+
+ DirectoryIndex gitweb.cgi
+
+ RewriteEngine On
+ RewriteCond %{REQUEST_FILENAME} !-f
+ RewriteCond %{REQUEST_FILENAME} !-d
+ RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
+ </Directory>
+</VirtualHost>
+
+The rewrite rule guarantees that existing static files will be properly
+served, whereas any other URL will be passed to gitweb as PATH_INFO
+parameter.
+
+Notice that in this case you don't need special settings for
+@stylesheets, $my_uri and $home_link, but you lose "dumb client" access
+to your project .git dirs. A possible workaround for the latter is the
+following: in your project root dir (e.g. /pub/git) have the projects
+named without a .git extension (e.g. /pub/git/project instead of
+/pub/git/project.git) and configure Apache as follows:
+
+<VirtualHost *:80>
+ ServerAlias git.example.com
+
+ DocumentRoot /var/www/gitweb
+
+ AliasMatch ^(/.*?)(\.git)(/.*)? /pub/git$1$3
+ <Directory /var/www/gitweb>
+ Options ExecCGI
+ AddHandler cgi-script cgi
+
+ DirectoryIndex gitweb.cgi
+
+ RewriteEngine On
+ RewriteCond %{REQUEST_FILENAME} !-f
+ RewriteCond %{REQUEST_FILENAME} !-d
+ RewriteRule ^.* /gitweb.cgi/$0 [L,PT]
+ </Directory>
+</VirtualHost>
+
+The additional AliasMatch makes it so that
+
+http://git.example.com/project.git
+
+will give raw access to the project's git dir (so that the project can
+be cloned), while
+
+http://git.example.com/project
+
+will provide human-friendly gitweb access.
+
+
Originally written by:
Kay Sievers <kay.sievers@vrfy.org>
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH v2 3/5] chain kill signals for cleanup functions
From: Jeff King @ 2009-01-31 1:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vd4e49v48.fsf@gitster.siamese.dyndns.org>
On Fri, Jan 30, 2009 at 04:28:39PM -0800, Junio C Hamano wrote:
> > Hmm. Clever.
> >
> > Junio, can you apply this on top of the jk/signal-cleanup topic?
>
> Will do, but I've been sick today, haven't caught up with the list
> traffic, and I do not think I'll be reading my mails for the rest of the
> day either. It may take some time for it to appear in the public
> repositories.
No problem. It really is a fix for a false negative in the test, not any
actual git bug, so no rush.
Now I'm off to go make fun of you, buried deep in a thread where you
won't see it.
-Peff
^ permalink raw reply
* Re: [PATCHv5 0/3] gitweb: make static files accessible with PATH_INFO
From: Jakub Narebski @ 2009-01-31 2:04 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1233365512-7130-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta wrote:
> This patchset includes
>
> 1. the single patch to make static files accessible with PATH_INFO, with
> the same quoting standard as the nearby code;
> 2. an additional patch that extends the README with some examples on how
> to configure Apache to use gitweb with PATH_INFO enabled by default
> (and gitweb as directory index);
> 3. the repeatedly recommended comment fix to align comments to code in the
> git_header_html() sub.
I like it. Ack for the whole series.
> Giuseppe Bilotta (3):
> gitweb: make static files accessible with PATH_INFO
> gitweb: webserver config for PATH_INFO
> gitweb: align comments to code
>
> gitweb/README | 76 ++++++++++++++++++++++++++++++++++++++++++++++++++++
> gitweb/gitweb.perl | 9 +++++-
> 2 files changed, 83 insertions(+), 2 deletions(-)
>
>
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] contrib/difftool: add support for Kompare
From: David Aguilar @ 2009-01-31 6:37 UTC (permalink / raw)
To: Markus Heidelberg; +Cc: Junio C Hamano, git
In-Reply-To: <200901310019.30117.markus.heidelberg@web.de>
On 0, Markus Heidelberg <markus.heidelberg@web.de> wrote:
>
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
> ---
> contrib/difftool/git-difftool-helper | 16 ++++++++++------
> contrib/difftool/git-difftool.txt | 3 ++-
> 2 files changed, 12 insertions(+), 7 deletions(-)
Good stuff =)
Should we patch mergetool with the same change?
Kompare's pretty popular in KDE land.
BTW git.git's next branch has:
commit fb700cb0679e22900f0d1435641e6cf7c652968b
Author: Johannes Gilger <heipei@hackvalue.de>
Date: Sat Jan 24 00:12:45 2009 +0100
mergetool: Don't repeat merge tool candidates
git mergetool listed some candidates for mergetools twice, depending on
the environment.
This slightly changes the behavior when both KDE_FULL_SESSION and
GNOME_DESKTOP_SESSION_ID are set at the same time; in such a case
meld is used in favor of kdiff3 (the old code favored kdiff3 in such a
case), but it should not matter in practice.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
difftool probably needs a similar patch.
I'll see if I can get to that this weekend if no one beats
me to it.
>
> diff --git a/contrib/difftool/git-difftool-helper b/contrib/difftool/git-difftool-helper
> index 0c48506..10632a3 100755
> --- a/contrib/difftool/git-difftool-helper
> +++ b/contrib/difftool/git-difftool-helper
> @@ -1,7 +1,7 @@
> #!/bin/sh
> # git-difftool-helper is a GIT_EXTERNAL_DIFF-compatible diff tool launcher.
> -# It supports kdiff3, tkdiff, xxdiff, meld, opendiff, emerge, ecmerge,
> -# vimdiff, gvimdiff, and custom user-configurable tools.
> +# It supports kdiff3, kompare, tkdiff, xxdiff, meld, opendiff,
> +# emerge, ecmerge, vimdiff, gvimdiff, and custom user-configurable tools.
> # This script is typically launched by using the 'git difftool'
> # convenience command.
> #
> @@ -73,6 +73,10 @@ launch_merge_tool () {
> > /dev/null 2>&1
> ;;
>
> + kompare)
> + "$merge_tool_path" "$LOCAL" "$REMOTE"
> + ;;
> +
> tkdiff)
> "$merge_tool_path" -o "$MERGED" "$LOCAL" "$REMOTE"
> ;;
> @@ -134,7 +138,7 @@ valid_custom_tool() {
> # Built-in merge tools are always valid.
> valid_tool() {
> case "$1" in
> - kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
> + kdiff3 | kompare | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
> ;; # happy
> *)
> if ! valid_custom_tool "$1"
> @@ -180,14 +184,14 @@ if test -z "$merge_tool"; then
>
> # We have a $DISPLAY so try some common UNIX merge tools
> if test -n "$DISPLAY"; then
> - merge_tool_candidates="kdiff3 tkdiff xxdiff meld gvimdiff"
> + merge_tool_candidates="kdiff3 kompare tkdiff xxdiff meld gvimdiff"
> # If gnome then prefer meld
> if test -n "$GNOME_DESKTOP_SESSION_ID"; then
> merge_tool_candidates="meld $merge_tool_candidates"
> fi
> - # If KDE then prefer kdiff3
> + # If KDE then prefer kdiff3 or kompare
> if test "$KDE_FULL_SESSION" = "true"; then
> - merge_tool_candidates="kdiff3 $merge_tool_candidates"
> + merge_tool_candidates="kdiff3 kompare $merge_tool_candidates"
> fi
> fi
>
> diff --git a/contrib/difftool/git-difftool.txt b/contrib/difftool/git-difftool.txt
> index ca3dbd2..6e2610c 100644
> --- a/contrib/difftool/git-difftool.txt
> +++ b/contrib/difftool/git-difftool.txt
> @@ -28,7 +28,8 @@ OPTIONS
> --tool=<tool>::
> Use the merge resolution program specified by <tool>.
> Valid merge tools are:
> - kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
> + kdiff3, kompare, tkdiff, meld, xxdiff, emerge,
> + vimdiff, gvimdiff, ecmerge, and opendiff
> +
> If a merge resolution program is not specified, 'git-difftool'
> will use the configuration variable `merge.tool`. If the
> --
> 1.6.1.2.256.g62566b
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
David
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Sam Vilain @ 2009-01-31 6:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0901220606040.3586@pacific.mpi-cbg.de>
On Thu, 2009-01-22 at 06:13 +0100, Johannes Schindelin wrote:
> > It would be nice to hear a real world success story using the notes
> > mechanism before casting this design in stone.
>
> I'd like to have some profiling done before that. For example, I am still
> a bit unsure how the things would perform with a 50-deep delta chain for
> a notes tree having 50,000+ notes in it (which I think will not be all
> that unreasonable for a medium-sized project that stores bug-tracking
> information in the notes).
Is there any reason why the split has to be cast in stone at all?
ie, the code could just scan the root tree of the branch, and
progressively descend into sub-trees based on a partial match of the
object for which the note is to be found. If you find a partial name
then you expect that it is a tree and descend into it and scan for the
rest. If you find a complete name then you expect that it is a blob and
open it. If it turns out to be a tree then there are multiple notes for
that commit. Then I think you get the best of both worlds; you can
start with a simple flat structure and then later someone can come along
and make it split it when there are more than N entries in the root tree
(where N is determined from profiling etc).
There are two practical applications I could use this for straight away
for perl.git, and I think that they would be important use cases.
One would be to allow grafts to be noted. These might want to live in a
different place to refs/notes/commits, like refs/notes/grafts, to avoid
performance issues and to recognise they are a different type of data.
A second would be for commit header information - particularly the
author field and commit description - to be amended. I think this all
belongs under refs/notes/commits. These are in essence, historical
corrections that don't need to alter the tree.
The idea of making it allow a union merge seems relatively workable, I
think for simplicity and flexibility that the contents of the note
should be considered to be format-patch output (except without the diff
of course). So union-ish, more like a RFC822-aware merge of mail
messages.
eg, say the contents of the note are:
Some text
=> appends "Some text" to the note as currently implemented
Subject: Blah blah
Blah blah blah
=> _replaces_ commit message and body, as if it had been committed
with the above message
From: Sam Vilain <sam@vilain.net>
Date: Thu, 22 Jan 2009 06:13:01 +1300
Blah blah blah
=> replaces 'author' line in commit. "Blah blah blah" appended to
commit body.
Sound sane?
Sam.
^ permalink raw reply
* Re: [PATCH v2 3/5] chain kill signals for cleanup functions
From: Jeff King @ 2009-01-31 6:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20090131014420.GA7696@sigill.intra.peff.net>
On Fri, Jan 30, 2009 at 08:44:20PM -0500, Jeff King wrote:
> > Will do, but I've been sick today, haven't caught up with the list
> > traffic, and I do not think I'll be reading my mails for the rest of the
> > day either. It may take some time for it to appear in the public
> > repositories.
> [...]
> Now I'm off to go make fun of you, buried deep in a thread where you
> won't see it.
Hmm, reading that again, it sounds mean, and I didn't mean it that way.
I should have put a ";P" at the end. What I meant was "while the cat is
away, the mice will play" (i.e., make mischief while our benevolent
dictator is out of commission).
Hope you feel better soon.
-Peff
^ permalink raw reply
* Re: [RFC] Line diff fragments, custom colour markers and word change highlighting
From: Jeff King @ 2009-01-31 6:57 UTC (permalink / raw)
To: Reece Dunn; +Cc: Git List
In-Reply-To: <3f4fd2640901301244s34d94e0fka00ce2eb6f6bef48@mail.gmail.com>
On Fri, Jan 30, 2009 at 08:44:26PM +0000, Reece Dunn wrote:
> At the moment, I am manually editing the output of git diff to produce
> the desired output. I intend on modifying git to get it to produce the
> output in a format that I am interested in so that I don't have to
> edit it by hand.
Have you considered writing an external diff driver (see the description
of GIT_EXTERNAL_DIFF in git(1))? That would be a good starting point for
experimenting if you want to use a totally different diff driver (but if
you are just making tweaks to git's diff code, then obviously that isn't
a good idea).
Your RFCs look more like tweaks, but I wonder if there isn't already a
good external tool for doing these sorts of non-line-oriented diffs.
-Peff
^ permalink raw reply
* Re: Git log can not show history before rename
From: Jeff King @ 2009-01-31 7:04 UTC (permalink / raw)
To: Thomas Rast; +Cc: Santi Béjar, Frank Li, git
In-Reply-To: <200901302252.18051.trast@student.ethz.ch>
On Fri, Jan 30, 2009 at 10:52:13PM +0100, Thomas Rast wrote:
> You might find this useful:
>
> $ git config alias.renames
> !GIT_PAGER="grep -v '^$' | sort -u" git --paginate log --follow --name-only --pretty=format:"" --
>
> Slow and hacky, but works nice enough in practice. The intended use
> case is like
>
> $ gitk --complicated-rev-options $(git renames git-svn.perl)
Related (but also slow and hacky :) ), it is sometimes nice to see not
the whole history of a file, but all of the commits, in the usual log
order, that ended up affecting the outcome of a set of content (so not
any commits whose work was later overwritten). I posted a short script
for it a while back:
http://article.gmane.org/gmane.comp.version-control.git/99278
-Peff
^ permalink raw reply
* Re: 'git clone' doesn't use alternates automatically?
From: Jeff King @ 2009-01-31 7:12 UTC (permalink / raw)
To: James Pickens; +Cc: Git ML
In-Reply-To: <885649360901301412jd5c6b0dne1eff1ff00dd043e@mail.gmail.com>
On Fri, Jan 30, 2009 at 03:12:42PM -0700, James Pickens wrote:
> I have a central, shared Git repository on an NFS drive at path
> $central. I have added "$central/objects" to
> $central/objects/info/alternates. I see that when I clone this
> repository with Git 1.6.1, the alternates file is automatically copied
> to the clone, but so are all the pack files and loose objects. If I
> then cd to the clone and run 'git gc', it removes the redundant local
> objects.
Yes, we don't set up alternates to an origin by default. If it's a local
clone, we do hardlink by default:
$ ls -i git/.git/objects/pack
7639155 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.idx
7638782 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.pack
$ git clone git foo
...
$ ls -i foo/.git/objects/pack
7639155 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.idx
7638782 pack-0651ae7e35ffde1921db158a3292e1c81153be1a.pack
but presumably in your example the second clone is _not_ on the NFS
mount, and therefore can't hardlink.
So you can try "git clone -s" to specify that you definitely want
alternates.
> I thought I tested this setup a few months back, and 'git clone'
> automatically used the alternates file to avoid copying the redundant
> objects into the clone. Has this behavior changed, or is my memory
> bad?
I don't recall clone ever being that clever, but I could be wrong (it is
not an area of the code that I am too familiar with).
Can you try a test with a few different versions to see if it ever
behaved as you expected (and if it does, bisect to find the breakage)?
-Peff
^ permalink raw reply
* Re: [PATCH] utf8: add utf8_strwidth()
From: Jeff King @ 2009-01-31 7:17 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: git
In-Reply-To: <1233308489-2656-1-git-send-email-geofft@mit.edu>
On Fri, Jan 30, 2009 at 04:41:28AM -0500, Geoffrey Thomas wrote:
> I'm about to use this pattern more than once, so make it a common function.
I know next to nothing about our encoding functions, but this seems
suspiciously similar to utf8_width in utf8.c. There is also a
git_wcwidth, but I don't know how they relate.
-Peff
^ permalink raw reply
* Re: [PATCH] builtin-blame.c: Use utf8_strwidth for author's names
From: Jeff King @ 2009-01-31 7:24 UTC (permalink / raw)
To: Geoffrey Thomas; +Cc: Johannes Schindelin, git
In-Reply-To: <alpine.DEB.2.00.0901301710130.1984@vinegar-pot.mit.edu>
On Fri, Jan 30, 2009 at 05:22:07PM -0500, Geoffrey Thomas wrote:
> I don't believe there are any encoding conversions performed up to that
> point. IIRC git doesn't require any encoding but encourages UTF-8; if it's
> something obscure, I have no way of knowing how wide in screen columns the
> author field is because I likely don't have a library for it in git at
> all. I do have a utf8.c, though.
Don't we pull the author from the commit message after it has been
converted using reencode_commit_message (see get_commit_info)? That
should be respecting the log output encoding.
It looks like we just throw away the information on what we encoded _to_
(i.e., the second parameter of reencode_commit_message). Probably we
need to remember that and use a generic "what is the width of this
string in this encoding" function.
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] EasyGit (eg) 0.97
From: Jeff King @ 2009-01-31 7:25 UTC (permalink / raw)
To: Elijah Newren; +Cc: Mike Ralphson, Git Mailing List
In-Reply-To: <51419b2c0901301455h32775947rfc4483fd5a5b6c2a@mail.gmail.com>
On Fri, Jan 30, 2009 at 03:55:28PM -0700, Elijah Newren wrote:
> > So you would have to read color.diff yourself and then decide whether to
> > add --color.
>
> It looks like I can also set the environment variable GIT_PAGER_IN_USE
> to achieve the same effects (and I don't even need to do so for most
> commands, such as diff, just those whose output I'm parsing and
> possibly tweaking).
Ah, right. I forgot about that. Yes, setting GIT_PAGER_IN_USE should
work, I think.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #05; Wed, 21)
From: Jeff King @ 2009-01-31 7:36 UTC (permalink / raw)
To: Sam Vilain; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <1233384354.10045.170.camel@maia.lan>
On Sat, Jan 31, 2009 at 07:45:54PM +1300, Sam Vilain wrote:
> Is there any reason why the split has to be cast in stone at all?
>
> ie, the code could just scan the root tree of the branch, and
> progressively descend into sub-trees based on a partial match of the
> object for which the note is to be found. If you find a partial name
> then you expect that it is a tree and descend into it and scan for the
> rest. If you find a complete name then you expect that it is a blob and
> open it. If it turns out to be a tree then there are multiple notes for
> that commit. Then I think you get the best of both worlds; you can
> start with a simple flat structure and then later someone can come along
> and make it split it when there are more than N entries in the root tree
> (where N is determined from profiling etc).
Actually, lookup is even easier than that: we iterate through the entire
tree recursively and add everything to a flat hash. So we really don't
care there what the layout is like (just take the first 40 characters of
any directory name as a hash).
But it violates the usual git principle of "content has a unique name".
What happens when I add "a/b" and you add "ab"? A dumb merge will let
both co-exist, but which one do you return for lookup?
> One would be to allow grafts to be noted. These might want to live in a
> different place to refs/notes/commits, like refs/notes/grafts, to avoid
> performance issues and to recognise they are a different type of data.
> A second would be for commit header information - particularly the
> author field and commit description - to be amended. I think this all
> belongs under refs/notes/commits. These are in essence, historical
> corrections that don't need to alter the tree.
I agree that there should be multiple note hierarchies, and multiple
keys within each hierarchy. I have posted some thoughts on that before
(and you should be able to find them searching for "notes" in the list
archive), but unfortunately I have not had time to sit down and really
work out a notes implementation that matches what I posted (which I
don't think is that far from Dscho's work in next).
And I think what you are proposing (here and in the rest of your
message) is that certain notes hierarchies may have particular formats
and semantics. And that sounds reasonable to me.
-Peff
^ permalink raw reply
* Re: [PATCH] utf8: add utf8_strwidth()
From: Geoffrey Thomas @ 2009-01-31 8:51 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20090131071711.GA3710@coredump.intra.peff.net>
On Sat, 31 Jan 2009, Jeff King wrote:
> I know next to nothing about our encoding functions, but this seems
> suspiciously similar to utf8_width in utf8.c. There is also a
> git_wcwidth, but I don't know how they relate.
git_wcwidth determines the screen columns of a single ucs_char_t.
utf8_width returns the git_wcwidth of the first character in a string.
utf8_strwidth (the function added by this patch) is a simple loop around
utf8_width, because writing the loop every time would be silly.
On that note, there are probably more cases in the code that ought to use
something like utf8_strwidth. I only noticed this one case because I'm
working on a project with someone with an accented letter in his last
name.
--
Geoffrey Thomas
geofft@mit.edu
^ 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