* Re: Question: Is it possible to host a writable git repo over both http and ssh?
From: Jeff King @ 2009-03-26 2:12 UTC (permalink / raw)
To: Mike Gaffney; +Cc: git
In-Reply-To: <49CA6A17.6050903@gmail.com>
On Wed, Mar 25, 2009 at 12:29:59PM -0500, Mike Gaffney wrote:
> I am trying to setup a git repo internally at my work. I would like to
> make the repo accessable via https for both read and write so that we may
> access it from customer locations which don't allow anything but https. I
> would also like to host it via SSH because that protocol is much faster. I
> know that when you push with http it runs 'git update-server-info', would
> I have to make the ssh pushes do the same? Will this even work?
Yes, it should work just fine. All pushes, no matter how they arrive at
the repository, will need to run "git update-server-info", which is what
allows "dumb" protocols like http to read from the repository. The
default post-update hook does this; you just need to enable it by "cd
.git/hooks && mv post-update.sample post-update".
-Peff
^ permalink raw reply
* Re: branch ahead in commits but push claims all up to date
From: John Tapsell @ 2009-03-26 2:05 UTC (permalink / raw)
To: Irene Ros; +Cc: Daniel Barkalow, git
In-Reply-To: <7001b7a00903251023r1ce5cc0dnb29b7f9379408c42@mail.gmail.com>
2009/3/25 Irene Ros <imirene@gmail.com>:
> Hi Daniel,
>
> Thank you for the explanation, doing a git fetch actually did do the
> trick although I still don't quite see the difference between
> git pull origin myBranch
> and
> git fetch
git pull origin myBranch is equivalent to two commands:
git fetch
git merge origin/myBranch
(so fetch actual remote repository to local remote repository. Then
do the merge)
>
> When I push to origin myBranch it's clear that it actually pushes my
> changes to our remote repository since others can then pull and get
> them. So is it the case that:
>
> git push ==> actual remote repository
Yes
> while
> git pull <== local copy of remote repository for this branch ?
git pull <== actual remote repository copied to local copy of remote
repository. Then local copy of remote repository merged into your
branch.
> In that case why is it that in all branches that I have, besides this
> one, doing a 'git pull origin whateverBranch' actually pulls from the
> remote branch and not the local copy? This case has been quite unique
> given dozens of branches that we constantly switch to and from. We've
> never actually used (or clearly saw the need for) git fetch until now.
If you always git pull after git push, then you'll have no problem,
since git pull also does a git fetch.
git is sometimes a bit too bare bones :-/ It would be nice to try to
hide these implementation details better
^ permalink raw reply
* [PATCH 1/2] Add feature release instructions to MaintNotes addendum
From: rocketraman @ 2009-03-26 1:56 UTC (permalink / raw)
To: git
From: Raman Gupta <raman@rocketraman.com>
Based on a mailing list discussion, add the operations for creating a
feature release.
Signed-off-by: Raman Gupta <raman@rocketraman.com>
---
Documentation/howto/maintain-git.txt | 29 +++++++++++++++++++++++++++++
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/howto/maintain-git.txt b/Documentation/howto/maintain-git.txt
index 4357e26..f6ee0c5 100644
--- a/Documentation/howto/maintain-git.txt
+++ b/Documentation/howto/maintain-git.txt
@@ -244,6 +244,35 @@ by doing the following:
repo.or.cz
+A feature release of git is made by tagging 'master' with a tag
+matching vX.Y.Z, where X.Y.Z is the feature release version.
+
+ - Optionally, track the current 'maint' branch to support
+ new releases for the older codebase if necessary.
+
+ $ git branch maint-X.Y.(Z-1) maint
+
+ - The 'maint' branch is updated to the new release.
+
+ $ git checkout maint
+ $ git merge master
+
+ This is equivalent to deleting maint and recreating it from
+ master, but it preserves the maint reflog.
+
+ - The 'next' branch may be rebuilt from the tip of 'master'
+ using the surviving topics on 'next'.
+
+ $ git branch -f next master
+
+ (Again, this approach preserves the reflog and per-branch
+ configuration of 'next')
+
+ $ git merge ai/topic_in_next1
+ $ git merge ai/topic_in_next2
+ ...
+
+
Some observations to be made.
* Each topic is tested individually, and also together with
--
1.6.2
^ permalink raw reply related
* [PATCH 2/2] Add feature release instructions to gitworkflows man page
From: rocketraman @ 2009-03-26 1:56 UTC (permalink / raw)
To: git
In-Reply-To: <1238032575-10987-1-git-send-email-rocketraman@fastmail.fm>
From: Raman Gupta <raman@rocketraman.com>
Based on a mailing list discussion, add a description of the workflow,
and associated commands, for creating a feature release.
Signed-off-by: Raman Gupta <raman@rocketraman.com>
---
Documentation/gitworkflows.txt | 69 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 69 insertions(+), 0 deletions(-)
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 2b021e3..1796878 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -348,6 +348,75 @@ in patches to figure out the merge base. See linkgit:git-am[1] for
other options.
+RELEASE WORKFLOW
+----------------
+
+The maintainer may use the following release workflow:
+
+He first tags the tip of 'master' with a release tag, then he updates
+the 'maint' branch to the current tip of 'master' for managing future
+maintenance fixes on the current release, and lastly he optionally
+rebuilds 'next' from the tip of 'master'.
+
+
+Release Tagging
+~~~~~~~~~~~~~~~
+
+The new feature release is tagged on 'master' with a tag matching
+vX.Y.Z, where X.Y.Z is the new feature release version.
+
+.Release tagging
+[caption="Recipe: "]
+==========================================
+`git tag -s -m GIT "vX.Y.Z" vX.Y.Z`
+==========================================
+
+
+Maintenance branch update
+~~~~~~~~~~~~~~~~~~~~~~~~~
+
+The current maintenance branch is optionally tracked with the older
+release version number to allow for further maintenance releases on
+the older codebase.
+
+.Track maint
+[caption="Recipe: "]
+=====================================
+`git branch maint-X.Y.(Z-1) maint`
+=====================================
+
+'maint' is now updated to the new release code so that maintenance
+fixes can be merged for the current version.
+
+.Update maint to new release
+[caption="Recipe: "]
+=====================================
+* `git checkout maint`
+* `git merge master`
+=====================================
+
+This is equivalent to deleting maint and recreating it from master,
+but it preserves the maint reflog.
+
+Update next branch
+~~~~~~~~~~~~~~~~~~
+
+The 'next' branch may be rebuilt from the tip of 'master' using the
+surviving topics on 'next'.
+
+This step is optional. If it is done by the maintainer, then a public
+announcement will be made indicating that 'next' was rebased.
+
+.Update maint to new release
+[caption="Recipe: "]
+=====================================
+* `git branch -f next master`
+* `git merge ai/topic_in_next1`
+* `git merge ai/topic_in_next2`
+* ...
+=====================================
+
+
SEE ALSO
--------
linkgit:gittutorial[7],
--
1.6.2
^ permalink raw reply related
* [JGIT PATCH 5/5] Use Deflater directly in PackWriter
From: Shawn O. Pearce @ 2009-03-26 1:21 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marek Zawirski, Daniel Cheng, git
In-Reply-To: <1238030515-31768-4-git-send-email-spearce@spearce.org>
Rather than going through all of the indirection that makes up the
DeflaterOutputStream, including the new object construction for it
and the temporary buffer it allocates internally, we can pump data
directly through our Deflater instance and use our existing 16 KB
temporary "buf" for the transient storage as we compress data to
the pack output stream.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/PackWriter.java | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
index 2f34255..2d05c4e 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
@@ -47,7 +47,6 @@
import java.util.Iterator;
import java.util.List;
import java.util.zip.Deflater;
-import java.util.zip.DeflaterOutputStream;
import org.spearce.jgit.errors.IncorrectObjectTypeException;
import org.spearce.jgit.errors.MissingObjectException;
@@ -699,12 +698,15 @@ private void writeWholeObject(final ObjectToPack otp) throws IOException {
} else {
final ObjectLoader loader = db.openObject(windowCursor, otp);
final byte[] data = loader.getCachedBytes();
- final DeflaterOutputStream deflaterOut = new DeflaterOutputStream(
- out, deflater);
writeObjectHeader(otp.getType(), data.length);
- deflaterOut.write(data);
- deflaterOut.finish();
deflater.reset();
+ deflater.setInput(data, 0, data.length);
+ deflater.finish();
+ do {
+ final int n = deflater.deflate(buf, 0, buf.length);
+ if (n > 0)
+ out.write(buf, 0, n);
+ } while (!deflater.finished());
}
}
--
1.6.2.1.471.g682837
^ permalink raw reply related
* [JGIT PATCH 4/5] Write the pack header in one shot
From: Shawn O. Pearce @ 2009-03-26 1:21 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marek Zawirski, Daniel Cheng, git
In-Reply-To: <1238030515-31768-3-git-send-email-spearce@spearce.org>
Instead of making 3 individual write calls of 4 bytes each, write
the entire header as a single 12 byte buffer. Its also a little
bit easier to follow the final code, that these items appear at
the 0/4/8 offsets within the 12 byte long header.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../src/org/spearce/jgit/lib/PackWriter.java | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
index cfec35c..2f34255 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
@@ -644,13 +644,10 @@ private void selectObjectReuseForObject(final ObjectToPack otp,
}
private void writeHeader() throws IOException {
- out.write(Constants.PACK_SIGNATURE);
-
- NB.encodeInt32(buf, 0, PACK_VERSION_GENERATED);
- out.write(buf, 0, 4);
-
- NB.encodeInt32(buf, 0, getObjectsNumber());
- out.write(buf, 0, 4);
+ System.arraycopy(Constants.PACK_SIGNATURE, 0, buf, 0, 4);
+ NB.encodeInt32(buf, 4, PACK_VERSION_GENERATED);
+ NB.encodeInt32(buf, 8, getObjectsNumber());
+ out.write(buf, 0, 12);
}
private void writeObjects() throws IOException {
--
1.6.2.1.471.g682837
^ permalink raw reply related
* [JGIT PATCH 3/5] Test case for pack index CRC32 when written by PackWriter
From: Shawn O. Pearce @ 2009-03-26 1:21 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marek Zawirski, Daniel Cheng, git
In-Reply-To: <1238030515-31768-2-git-send-email-spearce@spearce.org>
Suggested-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../tst/org/spearce/jgit/lib/PackWriterTest.java | 33 ++++++++++++++++++++
1 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
index 46616e3..636059f 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
@@ -40,6 +40,7 @@
import java.io.ByteArrayInputStream;
import java.io.ByteArrayOutputStream;
import java.io.File;
+import java.io.FileOutputStream;
import java.io.IOException;
import java.io.InputStream;
import java.util.ArrayList;
@@ -353,6 +354,37 @@ public void testWritePack4SizeThinVsNoThin() throws Exception {
assertTrue(sizePack4 > sizePack4Thin);
}
+ public void testWriteIndex() throws Exception {
+ writer.setIndexVersion(2);
+ writeVerifyPack4(false);
+
+ // Validate that IndexPack came up with the right CRC32 value.
+ final PackIndex idx1 = PackIndex.open(indexFile);
+ assertTrue(idx1 instanceof PackIndexV2);
+ assertEquals(0x4743F1E4L, idx1.findCRC32(ObjectId
+ .fromString("82c6b885ff600be425b4ea96dee75dca255b69e7")));
+
+ // Validate that an index written by PackWriter is the same.
+ final File idx2File = new File(indexFile.getAbsolutePath() + ".2");
+ final FileOutputStream is = new FileOutputStream(idx2File);
+ try {
+ writer.writeIndex(is);
+ } finally {
+ is.close();
+ }
+ final PackIndex idx2 = PackIndex.open(idx2File);
+ assertTrue(idx2 instanceof PackIndexV2);
+ assertEquals(idx1.getObjectCount(), idx2.getObjectCount());
+ assertEquals(idx1.getOffset64Count(), idx2.getOffset64Count());
+
+ for (int i = 0; i < idx1.getObjectCount(); i++) {
+ final ObjectId id = idx1.getObjectId(i);
+ assertEquals(id, idx2.getObjectId(i));
+ assertEquals(idx1.findOffset(id), idx2.findOffset(id));
+ assertEquals(idx1.findCRC32(id), idx2.findCRC32(id));
+ }
+ }
+
// TODO: testWritePackDeltasCycle()
// TODO: testWritePackDeltasDepth()
@@ -469,6 +501,7 @@ private void verifyOpenPack(final boolean thin) throws IOException {
final IndexPack indexer = new IndexPack(db, is, packBase);
indexer.setKeepEmpty(true);
indexer.setFixThin(thin);
+ indexer.setIndexVersion(2);
indexer.index(new TextProgressMonitor());
pack = new PackFile(indexFile, packFile);
}
--
1.6.2.1.471.g682837
^ permalink raw reply related
* [JGIT PATCH 2/5] Implement CRC32 computation during PackWriter
From: Shawn O. Pearce @ 2009-03-26 1:21 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marek Zawirski, Daniel Cheng, git
In-Reply-To: <1238030515-31768-1-git-send-email-spearce@spearce.org>
To correctly create a v2 index file for a pack we must compute the
CRC32 code for each object entry as they are written out, otherwise
the CRC32 table will be full of 0's, and fail verification if the
resulting pack were to be reused.
Reported-by: Daniel Cheng (aka SDiZ) <j16sdiz+freenet@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../tst/org/spearce/jgit/lib/PackWriterTest.java | 17 +++---
.../PackOutputStream.java} | 65 +++++++++++++-------
.../src/org/spearce/jgit/lib/PackWriter.java | 16 ++---
3 files changed, 57 insertions(+), 41 deletions(-)
rename org.spearce.jgit/src/org/spearce/jgit/{util/CountingOutputStream.java => lib/PackOutputStream.java} (61%)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
index f7139fc..46616e3 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/PackWriterTest.java
@@ -56,7 +56,6 @@
import org.spearce.jgit.revwalk.RevObject;
import org.spearce.jgit.revwalk.RevWalk;
import org.spearce.jgit.transport.IndexPack;
-import org.spearce.jgit.util.CountingOutputStream;
import org.spearce.jgit.util.JGitTestUtil;
public class PackWriterTest extends RepositoryTestCase {
@@ -71,7 +70,7 @@
private ByteArrayOutputStream os;
- private CountingOutputStream cos;
+ private PackOutputStream cos;
private File packBase;
@@ -84,7 +83,7 @@
public void setUp() throws Exception {
super.setUp();
os = new ByteArrayOutputStream();
- cos = new CountingOutputStream(os);
+ cos = new PackOutputStream(os);
packBase = new File(trash, "tmp_pack");
packFile = new File(trash, "tmp_pack.pack");
indexFile = new File(trash, "tmp_pack.idx");
@@ -308,11 +307,11 @@ public void testWritePack4ThinPack() throws IOException {
*/
public void testWritePack2SizeDeltasVsNoDeltas() throws Exception {
testWritePack2();
- final long sizePack2NoDeltas = cos.getCount();
+ final long sizePack2NoDeltas = cos.length();
tearDown();
setUp();
testWritePack2DeltasReuseRefs();
- final long sizePack2DeltasRefs = cos.getCount();
+ final long sizePack2DeltasRefs = cos.length();
assertTrue(sizePack2NoDeltas > sizePack2DeltasRefs);
}
@@ -327,11 +326,11 @@ public void testWritePack2SizeDeltasVsNoDeltas() throws Exception {
*/
public void testWritePack2SizeOffsetsVsRefs() throws Exception {
testWritePack2DeltasReuseRefs();
- final long sizePack2DeltasRefs = cos.getCount();
+ final long sizePack2DeltasRefs = cos.length();
tearDown();
setUp();
testWritePack2DeltasReuseOffsets();
- final long sizePack2DeltasOffsets = cos.getCount();
+ final long sizePack2DeltasOffsets = cos.length();
assertTrue(sizePack2DeltasRefs > sizePack2DeltasOffsets);
}
@@ -345,11 +344,11 @@ public void testWritePack2SizeOffsetsVsRefs() throws Exception {
*/
public void testWritePack4SizeThinVsNoThin() throws Exception {
testWritePack4();
- final long sizePack4 = cos.getCount();
+ final long sizePack4 = cos.length();
tearDown();
setUp();
testWritePack4ThinPack();
- final long sizePack4Thin = cos.getCount();
+ final long sizePack4Thin = cos.length();
assertTrue(sizePack4 > sizePack4Thin);
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackOutputStream.java
similarity index 61%
rename from org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java
rename to org.spearce.jgit/src/org/spearce/jgit/lib/PackOutputStream.java
index 5f333f5..403b892 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackOutputStream.java
@@ -1,4 +1,5 @@
/*
+ * Copyright (C) 2009, Google Inc.
* Copyright (C) 2008, Marek Zawirski <marek.zawirski@gmail.com>
*
* All rights reserved.
@@ -35,46 +36,66 @@
* ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
*/
-package org.spearce.jgit.util;
+package org.spearce.jgit.lib;
-import java.io.FilterOutputStream;
import java.io.IOException;
import java.io.OutputStream;
+import java.security.MessageDigest;
+import java.util.zip.CRC32;
+
+/** Custom output stream to support {@link PackWriter}. */
+final class PackOutputStream extends OutputStream {
+ private final OutputStream out;
+
+ private final CRC32 crc = new CRC32();
+
+ private final MessageDigest md = Constants.newMessageDigest();
-/**
- * Counting output stream decoration. Counts bytes written to stream.
- */
-public class CountingOutputStream extends FilterOutputStream {
private long count;
- /**
- * Create counting stream being decorated to provided real output stream.
- *
- * @param out
- * output stream where data should be written
- */
- public CountingOutputStream(OutputStream out) {
- super(out);
+ PackOutputStream(final OutputStream out) {
+ this.out = out;
}
@Override
- public void write(int b) throws IOException {
+ public void write(final int b) throws IOException {
out.write(b);
+ crc.update(b);
+ md.update((byte) b);
count++;
}
@Override
- public void write(byte[] b, int off, int len) throws IOException {
+ public void write(final byte[] b, final int off, final int len)
+ throws IOException {
out.write(b, off, len);
+ crc.update(b, off, len);
+ md.update(b, off, len);
count += len;
}
- /**
- * Return number of already written bytes.
- *
- * @return number of written bytes since stream start.
- */
- public long getCount() {
+ @Override
+ public void flush() throws IOException {
+ out.flush();
+ }
+
+ /** @return total number of bytes written since stream start. */
+ long length() {
return count;
}
+
+ /** @return obtain the current CRC32 register. */
+ int getCRC32() {
+ return (int) crc.getValue();
+ }
+
+ /** Reinitialize the CRC32 register for a new region. */
+ void resetCRC32() {
+ crc.reset();
+ }
+
+ /** @return obtain the current SHA-1 digest. */
+ byte[] getDigest() {
+ return md.digest();
+ }
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
index 601ce71..cfec35c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/PackWriter.java
@@ -40,7 +40,6 @@
import java.io.BufferedOutputStream;
import java.io.IOException;
import java.io.OutputStream;
-import java.security.DigestOutputStream;
import java.security.MessageDigest;
import java.util.ArrayList;
import java.util.Collection;
@@ -57,7 +56,6 @@
import org.spearce.jgit.revwalk.RevObject;
import org.spearce.jgit.revwalk.RevSort;
import org.spearce.jgit.transport.PackedObjectInfo;
-import org.spearce.jgit.util.CountingOutputStream;
import org.spearce.jgit.util.NB;
/**
@@ -166,9 +164,7 @@
private final Repository db;
- private DigestOutputStream out;
-
- private CountingOutputStream countingOut;
+ private PackOutputStream out;
private final Deflater deflater;
@@ -563,8 +559,7 @@ public void writePack(OutputStream packStream) throws IOException {
if (!(packStream instanceof BufferedOutputStream))
packStream = new BufferedOutputStream(packStream);
- countingOut = new CountingOutputStream(packStream);
- out = new DigestOutputStream(countingOut, Constants.newMessageDigest());
+ out = new PackOutputStream(packStream);
writeMonitor.beginTask(WRITING_OBJECTS_PROGRESS, getObjectsNumber());
writeHeader();
@@ -687,11 +682,13 @@ private void writeObject(final ObjectToPack otp) throws IOException {
assert !otp.isWritten();
- otp.setOffset(countingOut.getCount());
+ out.resetCRC32();
+ otp.setOffset(out.length());
if (otp.isDeltaRepresentation())
writeDeltaObject(otp);
else
writeWholeObject(otp);
+ otp.setCRC(out.getCRC32());
writeMonitor.update(1);
}
@@ -753,8 +750,7 @@ private void writeObjectHeader(final int objectType, long dataLength)
}
private void writeChecksum() throws IOException {
- out.on(false);
- packcsum = out.getMessageDigest().digest();
+ packcsum = out.getDigest();
out.write(packcsum);
}
--
1.6.2.1.471.g682837
^ permalink raw reply related
* [JGIT PATCH 1/5] Remove dead/unused reset method from CountingOutputStream
From: Shawn O. Pearce @ 2009-03-26 1:21 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Marek Zawirski, Daniel Cheng, git
We never reset the stream, so just remove that as a valid option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
.../spearce/jgit/util/CountingOutputStream.java | 10 +---------
1 files changed, 1 insertions(+), 9 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java b/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java
index b0b5f7d..5f333f5 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/util/CountingOutputStream.java
@@ -72,17 +72,9 @@ public void write(byte[] b, int off, int len) throws IOException {
/**
* Return number of already written bytes.
*
- * @return number of written bytes since last reset (object is reset upon
- * creation)
+ * @return number of written bytes since stream start.
*/
public long getCount() {
return count;
}
-
- /**
- * Reset counter to zero value.
- */
- public void reset() {
- count = 0;
- }
}
--
1.6.2.1.471.g682837
^ permalink raw reply related
* Re: [PATCH JGIT 1/2] Calculate CRC32 on Pack Index v2
From: Daniel Cheng @ 2009-03-26 0:49 UTC (permalink / raw)
To: Marek Zawirski; +Cc: Shawn O. Pearce, git
In-Reply-To: <49CA3218.9090202@gmail.com>
On Wed, Mar 25, 2009 at 9:31 PM, Marek Zawirski
<marek.zawirski@gmail.com> wrote:
> Hi,
>
> Thanks for spotting this bug.
> (...)
[...]
>
> Have you tested that code? It seems that CRC32 updates is missing in
> write() method... or did I slept too short this night?:)
Sure I have tested some code, the wrong one.
The buggy code is at PackWriter.writeIndex(), and
the test case I have tested is using IndexPack.index().
.. hm...
I am thinking if we can combine two of them.
> Best,
> Marek
>
^ permalink raw reply
* Re: [PATCH] fast-export: Avoid dropping files from commits
From: Johannes Schindelin @ 2009-03-26 0:40 UTC (permalink / raw)
To: Elijah Newren; +Cc: git, gitster
In-Reply-To: <51419b2c0903251706n7cfa053eheff542d20ca9a753@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1318 bytes --]
Hi,
On Wed, 25 Mar 2009, Elijah Newren wrote:
> On Wed, Mar 25, 2009 at 4:13 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >> - if (commit->parents) {
> >> + if (commit->parents &&
> >> + get_object_mark(&commit->parents->item->object) != 0) {
> >> parse_commit(commit->parents->item);
> >> diff_tree_sha1(commit->parents->item->tree->object.sha1,
> >> commit->tree->object.sha1, "", &rev->diffopt);
> >
> > I do not understand that change.
> >
> > A good explanation in the commit message might help this stupid
> > developer.
>
> I resent the patch in another email (sorry for the duplication, but I
> don't trust gmail to preserve patches, and responding inline to comments
> via git-send-email isn't so great either). Let me know if the
> explanation is missing anything, is too detailed, or is using incorrect
> terminology. In two cases I was sufficiently unsure about my wording
> that I provided extra wording to try to make it clear what I was talking
> about.
I am pretty tired, but I still have the impression that I understood it,
so yes, I like it.
You might want to skip the != 0, though, as we avoid that in the rest of
Git's source code, too.
Thanks,
Dscho
^ permalink raw reply
* Re: [BUG?] How to make a shared/restricted repo?
From: Johan Herland @ 2009-03-26 0:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsadw5pz.fsf@gitster.siamese.dyndns.org>
On Thursday 26 March 2009, Junio C Hamano wrote:
> How about doing it like this, instead?
Looks good, and is obviously much less intrusive than my attempt.
There's still one issue as compared to my series: Hook scripts in
.git/hooks lose their executable bit when copied from template dir.
You probably need to do some kind of special x-bit handling, similar
to what's already done for directories.
Other than that:
Tested-by: Johan Herland <johan@herland.net>
> I think there are more places you could sprinkle adjust_shared_perm() for
> packfiles and other things. I didn't check, not because I wasn't
> uninterested, but because I am more interested in getting what
> adjust_shared_perm() itself does right.
Here is my #7 patch, re-rolled on top of your patch to call
adjust_shared_perm():
---
fast-import.c | 2 ++
http-push.c | 1 +
http-walker.c | 1 +
index-pack.c | 2 ++
4 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index beeac0d..d73ee71 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -903,7 +903,9 @@ static char *keep_pack(char *curr_index_name)
int keep_fd;
chmod(pack_data->pack_name, 0444);
+ adjust_shared_perm(pack_data->pack_name);
chmod(curr_index_name, 0444);
+ adjust_shared_perm(curr_index_name);
keep_fd = odb_pack_keep(name, sizeof(name), pack_data->sha1);
if (keep_fd < 0)
diff --git a/http-push.c b/http-push.c
index 6ce5a1d..a5acabf 100644
--- a/http-push.c
+++ b/http-push.c
@@ -750,6 +750,7 @@ static void finish_request(struct transfer_request *request)
} else if (request->state == RUN_FETCH_LOOSE) {
fchmod(request->local_fileno, 0444);
close(request->local_fileno); request->local_fileno = -1;
+ adjust_shared_perm(request->tmpfile);
if (request->curl_result != CURLE_OK &&
request->http_code != 416) {
diff --git a/http-walker.c b/http-walker.c
index 0dbad3c..24cfc45 100644
--- a/http-walker.c
+++ b/http-walker.c
@@ -233,6 +233,7 @@ static void finish_object_request(struct object_request *obj_req)
fchmod(obj_req->local, 0444);
close(obj_req->local); obj_req->local = -1;
+ adjust_shared_perm(obj_req->tmpfile);
if (obj_req->http_code == 416) {
fprintf(stderr, "Warning: requested range invalid; we may already have all the data.\n");
diff --git a/index-pack.c b/index-pack.c
index 7546822..7abe3f0 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -826,6 +826,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
}
if (from_stdin)
chmod(final_pack_name, 0444);
+ adjust_shared_perm(final_pack_name);
if (final_index_name != curr_index_name) {
if (!final_index_name) {
@@ -837,6 +838,7 @@ static void final(const char *final_pack_name, const char *curr_pack_name,
die("cannot store index file");
}
chmod(final_index_name, 0444);
+ adjust_shared_perm(final_index_name);
if (!from_stdin) {
printf("%s\n", sha1_to_hex(sha1));
--
1.6.2.1.473.g92672
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply related
* Re: [PATCH] fast-export: Avoid dropping files from commits
From: Elijah Newren @ 2009-03-26 0:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0903252312460.26370@intel-tinevez-2-302>
Hi,
On Wed, Mar 25, 2009 at 4:13 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> - if (commit->parents) {
>> + if (commit->parents &&
>> + get_object_mark(&commit->parents->item->object) != 0) {
>> parse_commit(commit->parents->item);
>> diff_tree_sha1(commit->parents->item->tree->object.sha1,
>> commit->tree->object.sha1, "", &rev->diffopt);
>
> I do not understand that change.
>
> A good explanation in the commit message might help this stupid developer.
I resent the patch in another email (sorry for the duplication, but I
don't trust gmail to preserve patches, and responding inline to
comments via git-send-email isn't so great either). Let me know if
the explanation is missing anything, is too detailed, or is using
incorrect terminology. In two cases I was sufficiently unsure about
my wording that I provided extra wording to try to make it clear what
I was talking about.
Thanks,
Elijah
^ permalink raw reply
* Re: [PATCH] fast-export: Avoid dropping files from commits
From: newren @ 2009-03-25 23:53 UTC (permalink / raw)
To: Johannes.Schindelin; +Cc: git, gitster, Elijah Newren
In-Reply-To: <alpine.DEB.1.00.0903252312460.26370@intel-tinevez-2-302>
From: Elijah Newren <newren@gmail.com>
When exporting a subset of commits on a branch that do not go back to a
root commit (e.g. master~2..master), we still want each exported commit to
have the same files in the exported tree as in the original tree.
Previously, when given such a range, we would omit master~2 as a parent of
master~1, but we would still diff against master~2 when selecting the list
of files to include in master~1. This would result in only files that
had changed in the given range showing up in the resulting export. In such
cases, we should diff master~1 against the root instead (i.e. use
diff_root_tree_sha1 instead of diff_tree_sha1).
There's a special case to consider here: incremental exports (i.e. exports
where the --import-marks flag is specified). If master~2 is an imported
mark, then we still want to diff master~1 against master~2 when selecting
the list of files to include.
We can handle all cases, including the special case, by just checking
whether master~2 corresponds to a known object mark when deciding what to
diff against.
Signed-off-by: Elijah Newren <newren@gmail.com>
---
builtin-fast-export.c | 3 ++-
t/t9301-fast-export.sh | 7 +++++--
2 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index fdf4ae9..34a419c 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -221,7 +221,8 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)
if (message)
message += 2;
- if (commit->parents) {
+ if (commit->parents &&
+ get_object_mark(&commit->parents->item->object) != 0) {
parse_commit(commit->parents->item);
diff_tree_sha1(commit->parents->item->tree->object.sha1,
commit->tree->object.sha1, "", &rev->diffopt);
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index 86c3760..b860626 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -8,6 +8,9 @@ test_description='git fast-export'
test_expect_success 'setup' '
+ echo break it > file0 &&
+ git add file0 &&
+ test_tick &&
echo Wohlauf > file &&
git add file &&
test_tick &&
@@ -57,8 +60,8 @@ test_expect_success 'fast-export master~2..master' '
(cd new &&
git fast-import &&
test $MASTER != $(git rev-parse --verify refs/heads/partial) &&
- git diff master..partial &&
- git diff master^..partial^ &&
+ git diff --exit-code master partial &&
+ git diff --exit-code master^ partial^ &&
test_must_fail git rev-parse partial~2)
'
--
1.6.0.6
^ permalink raw reply related
* Re: Reference for git.git release process
From: Junio C Hamano @ 2009-03-25 23:41 UTC (permalink / raw)
To: Raman Gupta; +Cc: git
In-Reply-To: <49CAAA16.1080401@fastmail.fm>
Raman Gupta <rocketraman@fastmail.fm> writes:
> Junio C Hamano wrote:
> ...
>> That is more-or-less correct, even though I'd actually do either
>>
>> git branch -f next master
>>
>> or
>>
>> git checkout next
>> git reset --hard master
>>
>> instead of deleting and recreating.
>
> Is that a stylistic preference or does your approach have some
> advantage over the delete/create? Doesn't git branch -f internally
> delete and re-create?
No, yes, and no. The last answer "no" relates to the fact that the
preservation of the reflog and per-branch configuration for "next", which
is the reason behind the second answer "yes".
> ... The only
> concern I had with this workflow was the difficult to understand
> visualization of the history. So to repeat my earlier question: Are
> there some canned gitk invocations, or other tips/tricks/approaches,...
I do not share the difficulty, and there is no answer from me to your
"earlier" question. Perhaps other people have some tips.
^ permalink raw reply
* Re: [PATCH] git-filter-branch: avoid collisions with variables in eval'ed commands
From: Junio C Hamano @ 2009-03-25 23:34 UTC (permalink / raw)
To: Petr Baudis; +Cc: Elijah Newren, git, Johannes.Schindelin, gitster
In-Reply-To: <20090325215848.GV8940@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Wed, Mar 25, 2009 at 03:33:31PM -0600, Elijah Newren wrote:
>> Hi,
>>
>> On Wed, Mar 25, 2009 at 3:24 PM, Petr Baudis <pasky@suse.cz> wrote:
>> > On Wed, Mar 25, 2009 at 03:13:01PM -0600, newren@gmail.com wrote:
>> >> From: Elijah Newren <newren@gmail.com>
>> >>
>> >> Avoid using simple variable names like 'i', since user commands are eval'ed
>> >> and may clash with and overwrite our values.
>> >>
>> >> Signed-off-by: Elijah Newren <newren@gmail.com>
>> >
>> > Almost-acked-by: Petr Baudis <pasky@suse.cz>
>> >
>> > But:
>> >
>> >>-i=0
>> >>+git_filter_branch_count=0
>> >
>> > Why branch_count? It counts commits, not branches, doesn't it?
>>
>> Oh, I was just changing i->git_filter_branch_i, then thought as long
>> as it was long I might as well use a word instead of "i". Didn't
>> think about the combined meaning. How about
>> "git_filter_branch_commit_count"? Maybe a double underscore between
>> the "namespace" and the "variable"?
>
> Oh, I sort of thought it's "git-filter branch count", not
> "git-filter-branch count". I'm dumbed down from all day spent in IKEA
> I guess. :/
>
> I'd personally just use $__git_i, $__git_commit or something, but YMMV.
Heh, I'll drop lmost-a from your earlier message and commit the result.
Thanks.
^ permalink raw reply
* Re: [BUG?] How to make a shared/restricted repo?
From: Junio C Hamano @ 2009-03-25 23:19 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <7v63hybaqd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Johan Herland <johan@herland.net> writes:
>
>> On Wednesday 25 March 2009, Junio C Hamano wrote:
>>> You might like to try a patch like this (untested).
>>>
>>> path.c | 17 +++++------------
>>> 1 files changed, 5 insertions(+), 12 deletions(-)
>>
>> Thanks!
>>
>> This works much better :)
>>
>> However, there are still some questions/issues:
>>
>> - t1301-shared-repo.sh fails:
>> Oops, .git/HEAD is not 0664 but -rw-rw---- [...]
>> * FAIL 3: shared=1 does not clear bits preset by umask 022
>> (I guess this is expected, as your patch changes the assumptions)
>
> I'd rather say the patch breaks people's expectations.
How about doing it like this, instead?
This fixes the behaviour of octal notation to how it is defined in the
documentation, while keeping the traditional "loosen only" semantics
intact for "group" and "everybody".
Three main points of this patch are:
- For an explicit octal notation, the internal shared_repository variable
is set to a negative value, so that we can tell "group" (which is to
"OR" in 0660) and 0660 (which is to "SET" to 0660);
- git-init did not set shared_repository variable early enough to affect
the initial creation of many files, notably copied templates and the
configuration. We set it very early when a command-line option
specifies a custom value.
- Loose object creation codepath first letsmkstemp() to create a new
temporary file; depending on systems, this gets 0660 or 0600, which
does not have anything to do with user's umask. To compensate for
this, close_sha1_file() unconditionally doing fchmod(0444). For the
traditional "loosen-only", adjust_shared_perm() call after it would be
a no-op (the mode is already loose enough), but with the new behaviour
it makes a difference.
I think there are more places you could sprinkle adjust_shared_perm() for
packfiles and other things. I didn't check, not because I wasn't
uninterested, but because I am more interested in getting what
adjust_shared_perm() itself does right.
builtin-init-db.c | 12 ++++++++++--
path.c | 33 ++++++++++++++++++---------------
setup.c | 5 ++---
sha1_file.c | 3 +++
4 files changed, 33 insertions(+), 20 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index fc63d0f..4e02b33 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -194,6 +194,8 @@ static int create_default_files(const char *template_path)
git_config(git_default_config, NULL);
is_bare_repository_cfg = init_is_bare_repository;
+
+ /* reading existing config may have overwrote it */
if (init_shared_repository != -1)
shared_repository = init_shared_repository;
@@ -312,12 +314,15 @@ int init_db(const char *template_dir, unsigned int flags)
* and compatibility values for PERM_GROUP and
* PERM_EVERYBODY.
*/
- if (shared_repository == PERM_GROUP)
+ if (shared_repository < 0)
+ /* force to the mode value */
+ sprintf(buf, "0%o", -shared_repository);
+ else if (shared_repository == PERM_GROUP)
sprintf(buf, "%d", OLD_PERM_GROUP);
else if (shared_repository == PERM_EVERYBODY)
sprintf(buf, "%d", OLD_PERM_EVERYBODY);
else
- sprintf(buf, "0%o", shared_repository);
+ die("oops");
git_config_set("core.sharedrepository", buf);
git_config_set("receive.denyNonFastforwards", "true");
}
@@ -397,6 +402,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
usage(init_db_usage);
}
+ if (init_shared_repository != -1)
+ shared_repository = init_shared_repository;
+
/*
* GIT_WORK_TREE makes sense only in conjunction with GIT_DIR
* without --bare. Catch the error early.
diff --git a/path.c b/path.c
index e332b50..9026b6e 100644
--- a/path.c
+++ b/path.c
@@ -314,33 +314,36 @@ char *enter_repo(char *path, int strict)
int adjust_shared_perm(const char *path)
{
struct stat st;
- int mode;
+ int mode, tweak, shared;
if (!shared_repository)
return 0;
if (lstat(path, &st) < 0)
return -1;
mode = st.st_mode;
-
- if (shared_repository) {
- int tweak = shared_repository;
- if (!(mode & S_IWUSR))
- tweak &= ~0222;
+ if (shared_repository < 0)
+ shared = -shared_repository;
+ else
+ shared = shared_repository;
+ tweak = shared;
+
+ if (!(mode & S_IWUSR))
+ tweak &= ~0222;
+ if (shared_repository < 0)
+ mode = (mode & ~0777) | tweak;
+ else
mode |= tweak;
- } else {
- /* Preserve old PERM_UMASK behaviour */
- if (mode & S_IWUSR)
- mode |= S_IWGRP;
- }
if (S_ISDIR(mode)) {
- mode |= FORCE_DIR_SET_GID;
-
/* Copy read bits to execute bits */
- mode |= (shared_repository & 0444) >> 2;
+ mode |= FORCE_DIR_SET_GID;
+ mode |= (shared & 0444) >> 2;
}
- if ((mode & st.st_mode) != mode && chmod(path, mode) < 0)
+ if (((shared_repository < 0
+ ? (st.st_mode & (FORCE_DIR_SET_GID | 0777))
+ : (st.st_mode & mode)) != mode) &&
+ chmod(path, mode) < 0)
return -2;
return 0;
}
diff --git a/setup.c b/setup.c
index 6c2deda..a430238 100644
--- a/setup.c
+++ b/setup.c
@@ -434,7 +434,7 @@ int git_config_perm(const char *var, const char *value)
/*
* Treat values 0, 1 and 2 as compatibility cases, otherwise it is
- * a chmod value.
+ * a chmod value to restrict to.
*/
switch (i) {
case PERM_UMASK: /* 0 */
@@ -456,7 +455,7 @@ int git_config_perm(const char *var, const char *value)
* Mask filemode value. Others can not get write permission.
* x flags for directories are handled separately.
*/
- return i & 0666;
+ return -(i & 0666);
}
int check_repository_format_version(const char *var, const char *value, void *cb)
diff --git a/sha1_file.c b/sha1_file.c
index 54972f9..b4c12c4 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2393,6 +2393,9 @@ static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
tmpfile, strerror(errno));
}
+ if (adjust_shared_perm(tmpfile))
+ die("unable to set permission to '%s'", tmpfile);
+
return move_temp_to_file(tmpfile, filename);
}
^ permalink raw reply related
* Re: Use alternate GIT servers to share traffic
From: Johannes Schindelin @ 2009-03-25 22:57 UTC (permalink / raw)
To: Thomas Koch; +Cc: git
In-Reply-To: <200903252145.30226.thomas@koch.ro>
Hi,
On Wed, 25 Mar 2009, Thomas Koch wrote:
> we host a public GIT repository on our high availability company
> cluster. Cloning the repo causes a trafic volume of 326 MB. We'd like to
> avoid that much trafic while still leaving the GIT repo where it is.
>
> I could imagine the following conversation between the GIT client and
> server:
>
> Client: Wanna clone!
> Server: You're welcome. Please note, that while I serve the most current
> state, you can get objects much faster from my collegue Server
> CHEAPHOST.
> Client: Thank you. Will take all the objects I can get from CHEAPHOST
> and come back if I should need anything else!
>
> The enduser should not need to specify anything, but only the regular
> git clone EXPENSIVEHOST line.
>
> Your thoughts?
That sounds a lot like the mirror-sync idea.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] init: support --import to add all files and commit right after init
From: Nguyen Thai Ngoc Duy @ 2009-03-25 22:54 UTC (permalink / raw)
To: Jeff King; +Cc: git, Johannes Schindelin
In-Reply-To: <20090325113510.GB4437@coredump.intra.peff.net>
2009/3/25 Jeff King <peff@peff.net>:
> On Wed, Mar 25, 2009 at 09:58:40PM +1100, Nguyễn Thái Ngọc Duy wrote:
>
>> -'git init' [-q | --quiet] [--bare] [--template=<template_directory>] [--shared[=<permissions>]]
>> +'git init' [-q | --quiet] [--bare] [--template=<template_directory>]
>> + [--shared[=<permissions>]] [-m|--import [<message>]]
>
> What happened to --import=? Whether or not "--import <arg>" works, the
> --long-opt= form should always work.
>
>> + else if (!strcmp(arg, "--import") || !strcmp(arg, "-m")) {
>> + if (i+1 >= argc)
>> + import_message = "Initial commit";
>> + else {
>> + import_message = argv[2];
>> + i++;
>> + argv++;
>> + }
>> + }
>
> This is the wrong way to do optional arguments. It means that
>
> git init --template=foo --import
>
> is different from
>
> git init --import --template=foo
>
> I think what you want is:
>
> else if (!strcmp(arg, "-m")) {
> if (i+1 >= argc)
> die("-m requires an import message");
> import_message = argv[2];
> i++;
> argv++;
> }
> else if (!strcmp(arg, "--import"))
> import_message = "Initial commit";
> else if (!prefixcmp(arg, "--import="))
> import_message = arg+9;
>
> That is, --import has a message or not depending on the '=', and "-m"
> always has a message. If you want "-m" to optionally have a message then
> it must be used as
>
> git init -mfoo
Right. Should not work late (or send it in the same night). Will rework.
--
Duy
^ permalink raw reply
* [PATCH] git-gui: run post-checkout hook on checkout
From: Jens Lehmann @ 2009-03-25 22:48 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, gitster, peff
git-gui is using "git-read-tree -u" for checkout which doesn't
invoke the post-checkout hook as a plain git-checkout would.
So git-gui must call the hook itself.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
It's been a while since i deeply touched tcl/tk code ... i basically
adapted the code for calling the post-commit hook here.
I renamed the former local variable "curHEAD" from the method
_start_checkout to a field named "old_hash" to be able to remember
the hash of the tree *before* the checkout started. This hash has
to be given as first argument to the post-checkout hook *after* the
checkout, where it is not the *current* HEAD anymore.
git-gui/lib/checkout_op.tcl | 39 ++++++++++++++++++++++++++++++++++-----
1 files changed, 34 insertions(+), 5 deletions(-)
diff --git a/git-gui/lib/checkout_op.tcl b/git-gui/lib/checkout_op.tcl
index caca888..31863a5 100644
--- a/git-gui/lib/checkout_op.tcl
+++ b/git-gui/lib/checkout_op.tcl
@@ -9,6 +9,7 @@ field w_cons {}; # embedded console window object
field new_expr ; # expression the user saw/thinks this is
field new_hash ; # commit SHA-1 we are switching to
field new_ref ; # ref we are updating/creating
+field old_hash ; # commit SHA-1 that was checked when we started
field parent_w .; # window that started us
field merge_type none; # type of merge to apply to existing branch
@@ -280,11 +281,11 @@ method _start_checkout {} {
# -- Our in memory state should match the repository.
#
- repository_state curType curHEAD curMERGE_HEAD
+ repository_state curType old_hash curMERGE_HEAD
if {[string match amend* $commit_type]
&& $curType eq {normal}
- && $curHEAD eq $HEAD} {
- } elseif {$commit_type ne $curType || $HEAD ne $curHEAD} {
+ && $old_hash eq $HEAD} {
+ } elseif {$commit_type ne $curType || $HEAD ne $old_hash} {
info_popup [mc "Last scanned state does not match repository state.
Another Git program has modified this repository since the last scan. A rescan must be performed before the current branch can be changed.
@@ -297,7 +298,7 @@ The rescan will be automatically started now.
return
}
- if {$curHEAD eq $new_hash} {
+ if {$old_hash eq $new_hash} {
_after_readtree $this
} elseif {[is_config_true gui.trustmtime]} {
_readtree $this
@@ -471,7 +472,19 @@ If you wanted to be on a branch, create one now starting from 'This Detached Che
set PARENT $HEAD
ui_status [mc "Checked out '%s'." $name]
}
- delete_this
+
+ # -- Run the post-checkout hook.
+ #
+ set fd_ph [githook_read post-checkout $old_hash $new_hash 1]
+ if {$fd_ph ne {}} {
+ upvar #0 pch_error pc_err
+ set pc_err {}
+ fconfigure $fd_ph -blocking 0 -translation binary -eofchar {}
+ fileevent $fd_ph readable \
+ [list checkout_postcheckout_wait $fd_ph $this]
+ } else {
+ delete_this
+ }
}
git-version proc _detach_HEAD {log new} {
@@ -608,3 +621,19 @@ $err"]
}
}
+
+proc checkout_postcheckout_wait {fd_ph t} {
+ upvar #0 pch_error pch_error
+
+ append pch_error [read $fd_ph]
+ fconfigure $fd_ph -blocking 1
+ if {[eof $fd_ph]} {
+ if {[catch {close $fd_ph}]} {
+ hook_failed_popup post-checkout $pch_error 0
+ }
+ unset pch_error
+ delete_this $t
+ return
+ }
+ fconfigure $fd_ph -blocking 0
+}
--
1.6.2.1.307.g91408
^ permalink raw reply related
* Re: [PATCH] fast-export: Avoid dropping files from commits
From: Johannes Schindelin @ 2009-03-25 22:13 UTC (permalink / raw)
To: Elijah Newren; +Cc: git, gitster
In-Reply-To: <1238014519-11683-1-git-send-email-newren@gmail.com>
Hi,
On Wed, 25 Mar 2009, newren@gmail.com wrote:
> From: Elijah Newren <newren@gmail.com>
>
> When exporting a subset of commits on a branch that do not go back to a
> root commit (e.g. master~2..master), we still want each exported commit to
> have the same files in the exported tree as in the original tree.
>
> Signed-off-by: Elijah Newren <newren@gmail.com>
> ---
Makes sense.
> builtin-fast-export.c | 3 ++-
> t/t9301-fast-export.sh | 7 +++++--
> 2 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/builtin-fast-export.c b/builtin-fast-export.c
> index fdf4ae9..34a419c 100644
> --- a/builtin-fast-export.c
> +++ b/builtin-fast-export.c
> @@ -221,7 +221,8 @@ static void handle_commit(struct commit *commit, struct rev_info *rev)
> if (message)
> message += 2;
>
> - if (commit->parents) {
> + if (commit->parents &&
> + get_object_mark(&commit->parents->item->object) != 0) {
> parse_commit(commit->parents->item);
> diff_tree_sha1(commit->parents->item->tree->object.sha1,
> commit->tree->object.sha1, "", &rev->diffopt);
I do not understand that change.
A good explanation in the commit message might help this stupid developer.
Ciao,
Dscho
^ permalink raw reply
* Re: Reference for git.git release process
From: Raman Gupta @ 2009-03-25 22:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqlxz9go.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
>> "After a feature release is made from "master", however, "next" will
>> be rebuilt from the tip of "master" using the surviving topics"
>>
>> Does this mean:
>>
>> git branch -d next
>> git checkout -b next master
>> git merge ai/topic1_to_cook_in_next
>> git merge ai/topic2_to_cook_in_next
>
> That is more-or-less correct, even though I'd actually do either
>
> git branch -f next master
>
> or
>
> git checkout next
> git reset --hard master
>
> instead of deleting and recreating.
Is that a stylistic preference or does your approach have some
advantage over the delete/create? Doesn't git branch -f internally
delete and re-create?
This whole approach seems really workable and powerful -- the only
concern I had with this workflow was the difficult to understand
visualization of the history. So to repeat my earlier question: Are
there some canned gitk invocations, or other tips/tricks/approaches,
that can be used to make the visualization of the integration and
topic branches more intuitive?
Within the next couple of days I will probably submit a patch to
maintain-git.txt that includes the information you have relayed to me
here, as I think it may be useful to others.
Cheers,
Raman
^ permalink raw reply
* Re: [TopGit PATCH] hooks/pre-commit.sh: fix it again
From: martin f krafft @ 2009-03-25 12:17 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Petr Baudis, git, u.kleine-koenig
In-Reply-To: <1237981384-7857-1-git-send-email-bert.wesarg@googlemail.com>
[-- Attachment #1: Type: text/plain, Size: 1112 bytes --]
also sprach Bert Wesarg <bert.wesarg@googlemail.com> [2009.03.25.1243 +0100]:
> First I think the '#' is a leftover, second this is now a bashism.
I think this can be rewritten as POSIX as follows:
> - git rev-parse -q --verify "${head_/#refs\/heads/refs\/top-bases}" >/dev/null || exit 0;;
> + git rev-parse -q --verify "${head_/refs\/heads/refs\/top-bases}" >/dev/null || exit 0;;
git rev-parse -q --verify "refs/top-bases/${head_##refs/heads/}" >/dev/null || exit 0;;
This turns e.g. refs/heads/foo into foo and prepends
refs/top-bases/, which should be the same effect, assuming that the
variable's value contains nothing else but the ref's path.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduck http://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
logik ist analsadismus: gedanken werden gewaltsam
durch einen engen gang gepreßt.
-- frei nach lacan
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH JGIT 1/2] Calculate CRC32 on Pack Index v2
From: Shawn O. Pearce @ 2009-03-25 21:59 UTC (permalink / raw)
To: Marek Zawirski; +Cc: Daniel Cheng (aka SDiZ), git
In-Reply-To: <49CA3218.9090202@gmail.com>
Marek Zawirski <marek.zawirski@gmail.com> wrote:
> I just wonder if it is sensible to compute it always regardless of used
> index version (outputVersion) - for index v1 we don't really need CRC32
> to be computed. I don't have a good idea how can it be avoided in truly
> elegant way, as we cannot rely on the outputVersion checking in this
> code - currently it may became changed after writing pack, but before
> writing index. But maybe it's not so important issue, as AFAIR v2 is
> already default version for index.
If the index version is specifically set to 1, we may be forced to
write a version 2 index if the pack file is huge, in which case we
need the CRC32 data on each object. Since version 2 is the default,
we probably hav to compute it no matter what.
> Have you tested that code? It seems that CRC32 updates is missing in
> write() method... or did I slept too short this night?:)
Yea, its missing the updates in the write method.
I'm writing up an alternate series of patches.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-filter-branch: avoid collisions with variables in eval'ed commands
From: Petr Baudis @ 2009-03-25 21:58 UTC (permalink / raw)
To: Elijah Newren; +Cc: git, Johannes.Schindelin, gitster
In-Reply-To: <51419b2c0903251433s75775206x556fc2d65a347d7d@mail.gmail.com>
On Wed, Mar 25, 2009 at 03:33:31PM -0600, Elijah Newren wrote:
> Hi,
>
> On Wed, Mar 25, 2009 at 3:24 PM, Petr Baudis <pasky@suse.cz> wrote:
> > On Wed, Mar 25, 2009 at 03:13:01PM -0600, newren@gmail.com wrote:
> >> From: Elijah Newren <newren@gmail.com>
> >>
> >> Avoid using simple variable names like 'i', since user commands are eval'ed
> >> and may clash with and overwrite our values.
> >>
> >> Signed-off-by: Elijah Newren <newren@gmail.com>
> >
> > Almost-acked-by: Petr Baudis <pasky@suse.cz>
> >
> > But:
> >
> >>-i=0
> >>+git_filter_branch_count=0
> >
> > Why branch_count? It counts commits, not branches, doesn't it?
>
> Oh, I was just changing i->git_filter_branch_i, then thought as long
> as it was long I might as well use a word instead of "i". Didn't
> think about the combined meaning. How about
> "git_filter_branch_commit_count"? Maybe a double underscore between
> the "namespace" and the "variable"?
Oh, I sort of thought it's "git-filter branch count", not
"git-filter-branch count". I'm dumbed down from all day spent in IKEA
I guess. :/
I'd personally just use $__git_i, $__git_commit or something, but YMMV.
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ 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