* Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Junio C Hamano @ 2008-06-24 22:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Michael Haggerty, Jeff King, git
In-Reply-To: <alpine.DEB.1.00.0806242137120.9925@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Tue, 24 Jun 2008, Michael Haggerty wrote:
> ...
>> It seems to me that your problem is that git-bisect requires the "good"
>> revision to be older than the "bad" one. If this requirement were
>> removed, would there still be a need for "fixed" vs. "unfixed"?
>
> Nope.
>
> The thing that makes "fixed" and "bad" special is that _one_ commit
> introduced that.
That was my initial reaction, and I actually was about to phrase it more
bluntly: you do not understand what "bisect" is.
But that was a reaction without thinking things through. It may not be
what "git bisect" currently is, but the suggestion does not go against
what the underlying "git rev-list --bisect" is at all. I think what
Michael is speculating is different, and it makes sense in its own way.
Instead of having a set of bisect/good-* refs and a single bisect-bad ref,
your "fixed and unfixed" mode could work quite differently. By noticing
that the topology the user specified with initial good and bad have
ancient bad and recent good --- that is, "it used to be bad but now it is
good" --- you could instead use a set of bisect/bad-* refs and a single
bisect-good ref, and feed good and bad swapped to "rev-list --bisect" in
bisect_next(). That way, the labels given by visualize will match what
the user is doing automatically.
I said "it makes sense in its own way", because it is _quite_ different
from how git-bisect currently assumes, and restructuring git-bisect to
operate naturally in a way Michael describes would be a much larger
surgery with costs (including risks of bugs) associated with it, which
needs to be weighed in when judging that approach would actually make
sense.
^ permalink raw reply
* Re: [PATCH] pre-commit hook should ignore carriage returns at EOL
From: Junio C Hamano @ 2008-06-24 22:31 UTC (permalink / raw)
To: Christian Holtje; +Cc: Ian Hilt, git
In-Reply-To: <39C2861E-F800-40AE-8C15-4FC3BB51EF16@gmail.com>
Christian Holtje <docwhat@gmail.com> writes:
> The code is checking for \r$ and then doing a different space check
> depending on that, not one after another.
>
> Thanks for the feedback. I'll put up v2 in a second.
Please don't.
It's an ancient sample hook that is not be enabled by default. I do not
want people to be wasting too much time on the relic.
However, if this sample is to be changed at all, please do it right.
If somebody suddenly adds CR at the end of an existing file that ought to
have LF line endings, we _DO_ want to catch that as a breakage. So the
title of the commit "should ignore carriage returns at EOL" is WRONG. It
shouldn't, in general.
One thing the hook could and probably should do these days is if the file
type says you _ought to_ have CRLF line endings, actively make sure your
lines do end with CRLF (this is a much stronger and better check than
blindly ignoring CR before LF for such files). And on the other hand, if
the file should end with LF, do make sure it does not have CR before it.
The person who did the sample hook you are looking at couldn't do so
because there weren't autocrlf nor gitattributes(5) facility back then.
But you can use them now to rewrite this properly.
I wonder if "git diff --check" can be used for most if not all of the
checking, without the big Perl script you are touching in your patch.
That facility did not exist when the current sample hook was written,
either.
^ permalink raw reply
* Re: [PATCH] cmd_reset: don't trash uncommitted changes unless told to
From: Junio C Hamano @ 2008-06-24 22:31 UTC (permalink / raw)
To: Steven Walter; +Cc: git, jeske
In-Reply-To: <1214346098-24584-1-git-send-email-stevenrwalter@gmail.com>
Steven Walter <stevenrwalter@gmail.com> writes:
> @@ -225,6 +243,10 @@ int cmd_reset(int argc, const char **argv, const char *prefix)
> if (reset_type == HARD && is_bare_repository())
> die("hard reset makes no sense in a bare repository");
>
> + if (reset_type == HARD && !force && index_is_dirty()) {
> + die("Uncommitted changes; re-run with -f to trash them");
> + }
> +
Please don't. With your change, does the testsuite even pass?
"reset --hard" has *ALWAYS* meant to be destructive --- discarding
potential local cruft is the whole point of the operation.
Learn the lingo, and get over it.
^ permalink raw reply
* Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Nicolas Pitre @ 2008-06-24 22:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Michael Haggerty, Jeff King, git
In-Reply-To: <7v8wwubh3j.fsf@gitster.siamese.dyndns.org>
On Tue, 24 Jun 2008, Junio C Hamano wrote:
> Instead of having a set of bisect/good-* refs and a single bisect-bad ref,
> your "fixed and unfixed" mode could work quite differently. By noticing
> that the topology the user specified with initial good and bad have
> ancient bad and recent good --- that is, "it used to be bad but now it is
> good" --- you could instead use a set of bisect/bad-* refs and a single
> bisect-good ref, and feed good and bad swapped to "rev-list --bisect" in
> bisect_next(). That way, the labels given by visualize will match what
> the user is doing automatically.
... and the final answer would be "the first good commit is ...".
That would be awesome, much nicer than yet more keywords.
> I said "it makes sense in its own way", because it is _quite_ different
> from how git-bisect currently assumes, and restructuring git-bisect to
> operate naturally in a way Michael describes would be a much larger
> surgery with costs (including risks of bugs) associated with it, which
> needs to be weighed in when judging that approach would actually make
> sense.
> --
> 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
>
Nicolas
^ permalink raw reply
* Windows symlinks
From: Patrick.Higgins @ 2008-06-24 22:42 UTC (permalink / raw)
To: git
It looks like one of the bigger (biggest?) hurdles for git adoption at my company is going to be handling symlinks on Windows. We may be able to sidestep the issue entirely by having developers run Linux in a virtual machine (or better yet, Windows in a VM) because we deploy to Linux and thus can make a very strong argument that developers should develop on Linux, too. That run into an image problem where people might start blaming git for needing to have an extra operating system around just for revision control.
We currently use Clearcase snapshot views on Windows and it has some kind of magic to be able to deal with symlinks. I haven't actually used the Windows version of Clearcase so I don't know how it does it, but my understanding is that it handles them with copies, and I guess it somehow knows to update all the copies when a change is made.
Has anyone thought about a way for git to handle symlinks? Vista seems to have added native symlinks, but you need have elevated privilege to create them. NTFS junction points seem helpful for older versions of Windows, but don't work for anything except directories, and seem to be dangerous to use with tools that do recursive deletes. Neither junction points nor native symlinks sound like great options.
Cygwin's clever symlink trick seems to work pretty well in practice. I'm not exactly sure what it's doing, but it seems to create a shortcut that it's own programs understand. Some other non-Cygwin programs seem to understand them, too, but Java does not which is a big problem for me.
I just don't see any good solutions here. Does anyone have any better ideas?
Thanks,
Patrick
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: David Jeske @ 2008-06-24 22:13 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jakub Narebski, Boaz Harrosh, git
In-Reply-To: <FmVFerrNVumRho9GZZwRiHrXV_hb12J_P_hSYUBnFhcCFiMGdtdCrg@cipher.nrlssc.navy.mil>
-- Brandon Casey wrote:
> I only have the same advice I gave to Boaz. I think you should try to adjust
> your workflow so that 'git reset' is not necessary. It seems that for the
> functions you're trying to perform, 'checkout' and 'branch' should be used
> rather than 'reset'.
Even when I change my workflow to avoid 'reset', I believe that the
user-interface of git will be stronger if it is a simpler expression of the
same functionality. One way to simplify it is to use convention that is
standardized across a set of tools so we don't have to learn every little
nuance of every little feature independently.
Two things I'd like to make it easy for users to never do are:
- delete data
- cause refs to be dangling
Therefore, I'd like a simple convention I can apply across all commands, so
that if users never do them, they'll never do either of the above things. I'm
not alone.
I think some of the impedance mismatch between my suggestions, and current
usage, has to do with where I'd like to be next. This is a meaty topic, I'll
start another thread on "policy and mechanism for less-connected clients".
> I'm not sure why you want to use reset so often. If there is something in the
> documentation that led you to want to use reset maybe it can be changed so
that
> other users are not led in the same way.
Yes, it's a problem in the git-gui and the "reset --hard" documentation. I'm
working on a patch.
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: David Jeske @ 2008-06-24 22:13 UTC (permalink / raw)
To: Brandon Casey; +Cc: Jakub Narebski, Boaz Harrosh, git
In-Reply-To: <FmVFerrNVumRho9GZZwRiHrXV_hb12J_P_hSYUBnFhcCFiMGdtdCrg@cipher.nrlssc.navy.mil>
-- Brandon Casey wrote:
> I only have the same advice I gave to Boaz. I think you should try to adjust
> your workflow so that 'git reset' is not necessary. It seems that for the
> functions you're trying to perform, 'checkout' and 'branch' should be used
> rather than 'reset'.
Even when I change my workflow to avoid 'reset', I believe that the
user-interface of git will be stronger if it is a simpler expression of the
same functionality. One way to simplify it is to use convention that is
standardized across a set of tools so we don't have to learn every little
nuance of every little feature independently.
Two things I'd like to make it easy for users to never do are:
- delete data
- cause refs to be dangling
Therefore, I'd like a simple convention I can apply across all commands, so
that if users never do them, they'll never do either of the above things. I'm
not alone.
I think some of the impedance mismatch between my suggestions, and current
usage, has to do with where I'd like to be next. This is a meaty topic, I'll
start another thread on "policy and mechanism for less-connected clients".
> I'm not sure why you want to use reset so often. If there is something in the
> documentation that led you to want to use reset maybe it can be changed so
that
> other users are not led in the same way.
Yes, it's a problem in the git-gui and the "reset --hard" documentation. I'm
working on a patch.
^ permalink raw reply
* Re: [NON-TOY PATCH] git bisect: introduce 'fixed' and 'unfixed'
From: Lea Wiemann @ 2008-06-24 22:48 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Johannes Schindelin, Jeff King, git
In-Reply-To: <486153DB.3070502@alum.mit.edu>
Michael Haggerty wrote:
> Therefore it should be easy to teach git-bisect to locate either kind of
> transition, "bad" -> "good" or "good" -> "bad", depending only on where
> the user places the original "good" and "bad" tags.
I think this is a good suggestion (though I haven't thought things
through). Another idea is to add "old" and "new" (or something like
that) as aliases to "good" and "bad", since that's the only semantics
that the bisect labels actually seem to have.
-- Lea
^ permalink raw reply
* [JGIT PATCH 1/4] LsTree: Do not use the default first empty tree in the walker
From: Robin Rosenberg @ 2008-06-24 21:36 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Marek Zawirski, Florian Koeberle,
Robin Rosenberg
In-Reply-To: <1214343392-5341-1-git-send-email-robin.rosenberg@dewire.com>
In f0ef5e1ef09d346432fead17bc82d78b7cfbd621 an empty tree
was added to all TreeWalkers.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/pgm/LsTree.java | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/LsTree.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/LsTree.java
index 1bc7bbd..05ec8c3 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/pgm/LsTree.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/LsTree.java
@@ -65,6 +65,7 @@ class LsTree extends TextBuiltin {
else if (argi + 1 < args.length)
throw die("too many arguments");
+ walk.reset(); // drop the first empty tree, which we do not need here
final String n = args[argi];
if (is_WorkDir(n))
walk.addTree(new FileTreeIterator(new File(n)));
--
1.5.5.1.178.g1f811
^ permalink raw reply related
* oops, resend
From: Robin Rosenberg @ 2008-06-24 21:36 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Marek Zawirski, Florian Koeberle
In-Reply-To: <20080622233525.GJ11793@spearce.org>
I f*d the first series. 1 2 3 testing.. :(
-- robin
^ permalink raw reply
* [JGIT PATCH 4/4] LsTree: Enable pattern matching in LsTree
From: Robin Rosenberg @ 2008-06-24 21:36 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Marek Zawirski, Florian Koeberle,
Robin Rosenberg
In-Reply-To: <1214343392-5341-4-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/pgm/LsTree.java | 19 +++++++++++++------
.../jgit/treewalk/filter/WildCardTreeFilter.java | 2 +-
2 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/pgm/LsTree.java b/org.spearce.jgit/src/org/spearce/jgit/pgm/LsTree.java
index 05ec8c3..6bb4192 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/pgm/LsTree.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/pgm/LsTree.java
@@ -43,8 +43,11 @@ import org.spearce.jgit.lib.Constants;
import org.spearce.jgit.lib.FileMode;
import org.spearce.jgit.treewalk.FileTreeIterator;
import org.spearce.jgit.treewalk.TreeWalk;
+import org.spearce.jgit.treewalk.filter.TreeFilter;
+import org.spearce.jgit.treewalk.filter.WildCardTreeFilter;
class LsTree extends TextBuiltin {
+
@Override
void execute(final String[] args) throws Exception {
final TreeWalk walk = new TreeWalk(db);
@@ -60,18 +63,22 @@ class LsTree extends TextBuiltin {
break;
}
- if (argi == args.length)
- throw die("usage: [-r] treename");
- else if (argi + 1 < args.length)
- throw die("too many arguments");
-
walk.reset(); // drop the first empty tree, which we do not need here
- final String n = args[argi];
+ final String n = args[argi++];
if (is_WorkDir(n))
walk.addTree(new FileTreeIterator(new File(n)));
else
walk.addTree(resolve(n));
+ if (argi == args.length - 1) {
+ TreeFilter filter = WildCardTreeFilter.create(args[argi++]);
+ walk.setFilter(filter);
+ }
+ if (argi + 1 == args.length)
+ throw die("usage: [-r] treename [pattern]");
+ else if (argi + 1 < args.length)
+ throw die("too many arguments");
+
while (walk.next()) {
final FileMode mode = walk.getFileMode(0);
if (mode == FileMode.TREE)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/treewalk/filter/WildCardTreeFilter.java b/org.spearce.jgit/src/org/spearce/jgit/treewalk/filter/WildCardTreeFilter.java
index ce6da5e..8b22e25 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/treewalk/filter/WildCardTreeFilter.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/treewalk/filter/WildCardTreeFilter.java
@@ -76,7 +76,7 @@ public class WildCardTreeFilter extends TreeFilter {
if (walker.isRecursive() && walker.isSubtree())
return true;
matcher.reset();
- matcher.append(walker.getPathString());
+ matcher.append(walker.getName());
if (matcher.isMatch())
return true;
return false;
--
1.5.5.1.178.g1f811
^ permalink raw reply related
* [JGIT PATCH 2/4] Create a fnmatch-style pattern TreeFilter
From: Robin Rosenberg @ 2008-06-24 21:36 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Marek Zawirski, Florian Koeberle,
Robin Rosenberg
In-Reply-To: <1214343392-5341-2-git-send-email-robin.rosenberg@dewire.com>
This uses Florian's pattern matcher to perform the matching.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../jgit/treewalk/filter/WildCardTreeFilter.java | 103 ++++++++++++++++++++
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 org.spearce.jgit/src/org/spearce/jgit/treewalk/filter/WildCardTreeFilter.java
diff --git a/org.spearce.jgit/src/org/spearce/jgit/treewalk/filter/WildCardTreeFilter.java b/org.spearce.jgit/src/org/spearce/jgit/treewalk/filter/WildCardTreeFilter.java
new file mode 100644
index 0000000..ce6da5e
--- /dev/null
+++ b/org.spearce.jgit/src/org/spearce/jgit/treewalk/filter/WildCardTreeFilter.java
@@ -0,0 +1,103 @@
+/*
+ * Copyright (C) 2008, Robin Rosenberg <robin.rosenberg@dewire.com>
+ *
+ * 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.treewalk.filter;
+
+import java.io.IOException;
+
+import org.spearce.jgit.errors.IncorrectObjectTypeException;
+import org.spearce.jgit.errors.InvalidPatternException;
+import org.spearce.jgit.errors.MissingObjectException;
+import org.spearce.jgit.fnmatch.FileNameMatcher;
+import org.spearce.jgit.treewalk.TreeWalk;
+import org.spearce.jgit.treewalk.filter.TreeFilter;
+
+/**
+ * This class implements a TreeeFilter that uses the wildcard style pattern
+ * matching like of Posix fnmatch function.
+ */
+public class WildCardTreeFilter extends TreeFilter {
+
+ private final FileNameMatcher matcher;
+
+ private final String pattern;
+
+ protected WildCardTreeFilter(final String pattern) {
+ try {
+ this.pattern = pattern;
+ matcher = new FileNameMatcher(pattern, null);
+ } catch (InvalidPatternException e) {
+ throw new IllegalArgumentException(e);
+ }
+ }
+
+ @Override
+ public TreeFilter clone() {
+ return new WildCardTreeFilter(pattern);
+ }
+
+ @Override
+ public boolean include(TreeWalk walker) throws MissingObjectException,
+ IncorrectObjectTypeException, IOException {
+ if (walker.isRecursive() && walker.isSubtree())
+ return true;
+ matcher.reset();
+ matcher.append(walker.getPathString());
+ if (matcher.isMatch())
+ return true;
+ return false;
+ }
+
+ @Override
+ public boolean shouldBeRecursive() {
+ return true;
+ }
+
+ /**
+ * Construct a WildCardmatcher like POSIX fnmatch.
+ *
+ * @param pattern
+ * A POSIX wildcard pattern
+ * @return a {@link TreeFilter} that matches pattern
+ * @throws IllegalArgumentException
+ * if the pattern is malformed
+ */
+ public static TreeFilter create(final String pattern) {
+ return new WildCardTreeFilter(pattern);
+ }
+
+}
--
1.5.5.1.178.g1f811
^ permalink raw reply related
* [JGIT PATCH 3/4] Added a method to get the non-relative name from the tree walker
From: Robin Rosenberg @ 2008-06-24 21:36 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Marek Zawirski, Florian Koeberle,
Robin Rosenberg
In-Reply-To: <1214343392-5341-3-git-send-email-robin.rosenberg@dewire.com>
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../src/org/spearce/jgit/treewalk/TreeWalk.java | 21 ++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java b/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
index 42f8b25..a5eb4d9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/treewalk/TreeWalk.java
@@ -499,6 +499,17 @@ public class TreeWalk {
}
/**
+ * Get the current entry's name.
+ * <p>
+ *
+ * @return name of the current entry only.
+ * @see #getPathString()
+ */
+ public String getName() {
+ return nameOf(currentHead);
+ }
+
+ /**
* Test if the supplied path matches the current entry's path.
* <p>
* This method tests that the supplied path is exactly equal to the current
@@ -659,4 +670,14 @@ public class TreeWalk {
+ Constants.CHARACTER_ENCODING, uee);
}
}
+
+ private static String nameOf(final AbstractTreeIterator t) {
+ try {
+ return new String(t.path, t.pathOffset, t.pathLen - t.pathOffset,
+ Constants.CHARACTER_ENCODING);
+ } catch (UnsupportedEncodingException uee) {
+ throw new RuntimeException("JVM doesn't support "
+ + Constants.CHARACTER_ENCODING, uee);
+ }
+ }
}
--
1.5.5.1.178.g1f811
^ permalink raw reply related
* Re: [JGIT PATCH 00/10] Support writing pack index version 2
From: Robin Rosenberg @ 2008-06-24 22:48 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Marek Zawirski, git
In-Reply-To: <1214273408-70793-1-git-send-email-spearce@spearce.org>
Ocular review looks fine, but nevertheless some tests break.
-- robin
org.spearce.jgit--All-Tests
org.spearce.jgit.lib.PackIndexV2Test
testIteratorMethodsContract(org.spearce.jgit.lib.PackIndexV2Test)
java.io.IOException: Unreadable pack index: /home/me/SW/EGIT.contrib/org.spearce.jgit.test/tst/pack-34be9032ac282b11fa9babdc2b2a93ca996c9c2f.idxV2
at org.spearce.jgit.lib.PackIndex.open(PackIndex.java:95)
at org.spearce.jgit.lib.PackIndexTest.setUp(PackIndexTest.java:54)
at junit.framework.TestCase.runBare(TestCase.java:128)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at junit.framework.TestSuite.runTest(TestSuite.java:230)
at junit.framework.TestSuite.run(TestSuite.java:225)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:460)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:673)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:386)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:196)
Caused by: java.io.EOFException: Short read of block.
at org.spearce.jgit.util.NB.readFully(NB.java:67)
at org.spearce.jgit.lib.PackIndexV1.<init>(PackIndexV1.java:75)
at org.spearce.jgit.lib.PackIndex.open(PackIndex.java:91)
... 14 more
testIteratorReturnedValues1(org.spearce.jgit.lib.PackIndexV2Test)
same trace
testCompareEntriesOffsetsWithFindOffsets(org.spearce.jgit.lib.PackIndexV2Test)
same trace
testIteratorReturnedValues2(org.spearce.jgit.lib.PackIndexV2Test)
same trace
Together with Marek's packwrite patches the list gets even longer (his patches alone are "green"). I'm
not including them here.
-- robin
^ permalink raw reply
* Re: why is git destructive by default? (i suggest it not be!)
From: Theodore Tso @ 2008-06-24 22:54 UTC (permalink / raw)
To: Brandon Casey; +Cc: David Jeske, Jakub Narebski, Boaz Harrosh, git
In-Reply-To: <FmVFerrNVumRho9GZZwRiHrXV_hb12J_P_hSYUBnFhcCFiMGdtdCrg@cipher.nrlssc.navy.mil>
On Tue, Jun 24, 2008 at 04:42:49PM -0500, Brandon Casey wrote:
> Again, as I mentioned to Boaz, there is really no benefit to reusing
> a single branch name if that is what you are trying to do. The cost
> of branching in git is 41 bytes i.e. nil.
The main reason that I find for reusing a branch name is for my
integration branch. I have a script which basically does:
git checkout integration
git reset --hard origin
git merge branch-A
git merge branch-B
git merge branch-C
git merge branch-D
I suppose I could have avoided the use of git reset with something
like this:
git update-index --refresh --unmerged > /dev/null
if git diff-index --name-only HEAD | read dummy; then
echo "There are local changes; refusing to build integration branch!"
exit 1
fi
git update-ref refs/heads/integration origin
git checkout integration
git merge branch-A
git merge branch-B
git merge branch-C
git merge branch-D
Instead, I've just learned to be careful and my use of git reset
--hard is mainly for historical reasons. But the point is, I can very
easily think of workflows where it makes sense to reuse a branch name,
most of them having to do with creating integration branches which are
basically throwaways after I am done testing or building that combined
tree.
- Ted
^ permalink raw reply
* [PATCH] factorize pack structure allocation
From: Nicolas Pitre @ 2008-06-24 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Teemu Likonen
New pack structures are currently allocated in 2 different places
and all members have to be initialized explicitly. This is prone
to errors leading to segmentation faults as found by Teemu Likonen.
Let's have a common place where this structure is allocated, and have
all members implicitly initialized to zero.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/sha1_file.c b/sha1_file.c
index a92f023..c56f674 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -792,18 +792,28 @@ unsigned char* use_pack(struct packed_git *p,
return win->base + offset;
}
+static struct packed_git *alloc_packed_git(int extra)
+{
+ struct packed_git *p = xmalloc(sizeof(*p) + extra);
+ memset(p, 0, sizeof(*p));
+ p->pack_fd = -1;
+ return p;
+}
+
struct packed_git *add_packed_git(const char *path, int path_len, int local)
{
struct stat st;
- struct packed_git *p = xmalloc(sizeof(*p) + path_len + 2);
+ struct packed_git *p = alloc_packed_git(path_len + 2);
/*
* Make sure a corresponding .pack file exists and that
* the index looks sane.
*/
path_len -= strlen(".idx");
- if (path_len < 1)
+ if (path_len < 1) {
+ free(p);
return NULL;
+ }
memcpy(p->pack_name, path, path_len);
strcpy(p->pack_name + path_len, ".pack");
if (stat(p->pack_name, &st) || !S_ISREG(st.st_mode)) {
@@ -814,16 +824,7 @@ struct packed_git *add_packed_git(const char *path, int path_len, int local)
/* ok, it looks sane as far as we can check without
* actually mapping the pack file.
*/
- p->index_version = 0;
- p->index_data = NULL;
- p->index_size = 0;
- p->num_objects = 0;
- p->num_bad_objects = 0;
- p->bad_object_sha1 = NULL;
p->pack_size = st.st_size;
- p->next = NULL;
- p->windows = NULL;
- p->pack_fd = -1;
p->pack_local = local;
p->mtime = st.st_mtime;
if (path_len < 40 || get_sha1_hex(path + path_len - 40, p->sha1))
@@ -835,19 +836,15 @@ struct packed_git *parse_pack_index(unsigned char *sha1)
{
const char *idx_path = sha1_pack_index_name(sha1);
const char *path = sha1_pack_name(sha1);
- struct packed_git *p = xmalloc(sizeof(*p) + strlen(path) + 2);
+ struct packed_git *p = alloc_packed_git(strlen(path) + 1);
+ strcpy(p->pack_name, path);
+ hashcpy(p->sha1, sha1);
if (check_packed_git_idx(idx_path, p)) {
free(p);
return NULL;
}
- strcpy(p->pack_name, path);
- p->pack_size = 0;
- p->next = NULL;
- p->windows = NULL;
- p->pack_fd = -1;
- hashcpy(p->sha1, sha1);
return p;
}
^ permalink raw reply related
* Re: why is git destructive by default? (i suggest it not be!)
From: Junio C Hamano @ 2008-06-24 23:07 UTC (permalink / raw)
To: Theodore Tso
Cc: Brandon Casey, David Jeske, Jakub Narebski, Boaz Harrosh, git
In-Reply-To: <20080624225442.GA20361@mit.edu>
Theodore Tso <tytso@mit.edu> writes:
> The main reason that I find for reusing a branch name is for my
> integration branch. I have a script which basically does:
>
> git checkout integration
> git reset --hard origin
> git merge branch-A
> git merge branch-B
> git merge branch-C
> git merge branch-D
>
> I suppose I could have avoided the use of git reset with something
> like this:
>
> git update-index --refresh --unmerged > /dev/null
> if git diff-index --name-only HEAD | read dummy; then
> echo "There are local changes; refusing to build integration branch!"
> exit 1
> fi
> git update-ref refs/heads/integration origin
> git checkout integration
> git merge branch-A
> git merge branch-B
> git merge branch-C
> git merge branch-D
>
> Instead, I've just learned to be careful and my use of git reset
> --hard is mainly for historical reasons.
This makes it sound as if avoiding "reset --hard" is a good thing, but I
do not understand why.
The reason you have the diff-index check in the second sequence is because
update-ref does not have the "local changes" check either. You could have
used the same diff-index check in front of "reset --hard".
Moreover, in your original sequence above, doesn't "git checkout
integration" list your local changes when you have any, and wouldn't that
be a clue enough that the next "reset --hard origin" would discard them?
> ... But the point is, I can very
> easily think of workflows where it makes sense to reuse a branch name,
> most of them having to do with creating integration branches which are
> basically throwaways after I am done testing or building that combined
> tree.
Absolutely.
^ permalink raw reply
* Re: [PATCH] factorize pack structure allocation
From: Jon Loeliger @ 2008-06-24 23:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git, Teemu Likonen
In-Reply-To: <alpine.LFD.1.10.0806241851420.2979@xanadu.home>
Nicolas Pitre wrote:
> New pack structures are currently allocated in 2 different places
> and all members have to be initialized explicitly. This is prone
> to errors leading to segmentation faults as found by Teemu Likonen.
>
> Let's have a common place where this structure is allocated, and have
> all members implicitly initialized to zero.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> ---
> diff --git a/sha1_file.c b/sha1_file.c
> index a92f023..c56f674 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -792,18 +792,28 @@ unsigned char* use_pack(struct packed_git *p,
> return win->base + offset;
> }
>
> +static struct packed_git *alloc_packed_git(int extra)
> +{
> + struct packed_git *p = xmalloc(sizeof(*p) + extra);
> + memset(p, 0, sizeof(*p));
> + p->pack_fd = -1;
> + return p;
> +}
Nit: That's an explicit 0 initialization!
jdl
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-06-24 23:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <20080624221049.GE29404@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Jun 24, 2008 at 01:44:34PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
>> >> bash: git-upload-pack: command not found
>> >> fatal: The remote end hung up unexpectedly
>> >
>> > Hmm. Probably the client needs to be newer, too. This is going to be
>> > painful. Junio?
>>
>> Even with maint client accessing an account with next git-shell as its
>> login shell, I do not get the above failure.
>>
>> Is git-shell installed and configured correctly at all in Miklos's setup?
>> Why does the other side say "bash: git-upload-pack" when login shell is
>> git-shell and not bash?
>
> Sorry for the confusion, this is not about git-shell at all. I have
> bash as the shell on the server, obviously.
>
> So, in case the server runs next, the client runs master, and I try to
> clone via ssh, I get the above error.
Ah, there is not much we can do in that case then. git-upload-pack is
what the client asks you to run, and if you do not have it in the path,
you can (1) either make sure it is on the path, (2) have the client be
more explicit when asking for git-upload-pack (--upload-pack=$where), or
(3) leave the minimum git-* binaries that can remotely be launched
directly in the usual $PATH.
It most likely makes sense to do (3) anyway. upload-pack, receive-pack,
anything else?
^ permalink raw reply
* Re: Windows symlinks
From: Avery Pennarun @ 2008-06-24 23:18 UTC (permalink / raw)
To: Patrick.Higgins@cexp.com; +Cc: git
In-Reply-To: <911589C97062424796D53B625CEC0025E4618F@USCOBRMFA-SE-70.northamerica.cexp.com>
On 6/24/08, Patrick.Higgins@cexp.com <Patrick.Higgins@cexp.com> wrote:
> Cygwin's clever symlink trick seems to work pretty well in practice. I'm not exactly sure what
> it's doing, but it seems to create a shortcut that it's own programs understand. Some other
> non-Cygwin programs seem to understand them, too, but Java does not which is a big
> problem for me.
It seems somewhat odd that your developers are relying on an operating
system feature that doesn't even exist. I might suggest one of:
- add an abstraction layer to your Java applet that understands
cygwin-style symlinks
- actually just check in the file multiple times; git will store it
efficiently anyway
- improve your Makefile to automatically copy the files and/or create
symlinks at build time rather than storing the symlinks in revision
control.
My understanding of Clearcase is that it actually loads a virtual
filesystem driver in Windows and does all kinds of insane magic -
slowly and inefficiently, too - behind the scenes. Something tells me
git (and every other VCS :)) really doesn't want to go there.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH] pre-commit hook should ignore carriage returns at EOL
From: Christian Holtje @ 2008-06-24 23:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3an2bh3b.fsf@gitster.siamese.dyndns.org>
On Jun 24, 2008, at 6:31 PM, Junio C Hamano wrote:
> Christian Holtje <docwhat@gmail.com> writes:
>
>> The code is checking for \r$ and then doing a different space check
>> depending on that, not one after another.
>>
>> Thanks for the feedback. I'll put up v2 in a second.
>
> Please don't.
>
> It's an ancient sample hook that is not be enabled by default. I do
> not
> want people to be wasting too much time on the relic
Part of the reason I'm fixing this is because it *is* enabled by
default in windows. I don't know why, but cygwin always marks it with
executable.
> However, if this sample is to be changed at all, please do it right.
>
> If somebody suddenly adds CR at the end of an existing file that
> ought to
> have LF line endings, we _DO_ want to catch that as a breakage. So
> the
> title of the commit "should ignore carriage returns at EOL" is
> WRONG. It
> shouldn't, in general.
>
> One thing the hook could and probably should do these days is if the
> file
> type says you _ought to_ have CRLF line endings, actively make sure
> your
> lines do end with CRLF (this is a much stronger and better check than
> blindly ignoring CR before LF for such files). And on the other
> hand, if
> the file should end with LF, do make sure it does not have CR before
> it.
>
> The person who did the sample hook you are looking at couldn't do so
> because there weren't autocrlf nor gitattributes(5) facility back
> then.
> But you can use them now to rewrite this properly.
How can I detect if a file should have CRLF vs. LF? I didn't do a
better check because I didn't know how.
> I wonder if "git diff --check" can be used for most if not all of the
> checking, without the big Perl script you are touching in your patch.
> That facility did not exist when the current sample hook was written,
> either.
I like that better. Ditching the whole perl script in a shell script
seems better.
I wrote a test case for what you describe above (a crlf file with an
lf line or a lf file with a crlf) but "git diff --check" doesn't catch
that.
Based on the information about core.whitespace doesn't git do this
already? Maybe we should just delete the pre-commit hook or make it
empty with a note saying what you can do with it?
Ciao!
^ permalink raw reply
* Re: Windows symlinks
From: Jakub Narebski @ 2008-06-24 23:28 UTC (permalink / raw)
To: Patrick Higgins; +Cc: git
In-Reply-To: <911589C97062424796D53B625CEC0025E4618F@USCOBRMFA-SE-70.northamerica.cexp.com>
Patrick Higgins <Patrick.Higgins@cexp.com> writes:
> It looks like one of the bigger (biggest?) hurdles for git adoption
> at my company is going to be handling symlinks on Windows. We may be
> able to sidestep the issue [...] by [...] run[ning] Linux
> in a virtual machine [...]
If only MS Windows supported other filesystems which have symlinks...
> Has anyone thought about a way for git to handle symlinks? Vista
> seems to have added native symlinks, but you need have elevated
> privilege to create them. NTFS junction points seem helpful for
> older versions of Windows, but don't work for anything except
> directories, and seem to be dangerous to use with tools that do
> recursive deletes. Neither junction points nor native symlinks sound
> like great options.
>
> Cygwin's clever symlink trick seems to work pretty well in
> practice. I'm not exactly sure what it's doing, but it seems to
> create a shortcut that it's own programs understand. Some other
> non-Cygwin programs seem to understand them, too, but Java does not
> which is a big problem for me.
First, I think that both "git on Windows" solutions, namely Cygwin and
msysGit port, don't use symlinks either in installed programs, nor in
repository layout.
Second, the problem there can be _only_ if your repository contains
(or contained) symlinks, and then it is your own damn fault. I don't
know how Cygwin, or msysGit deals with symlinks in a wirking
directory, but you can work around symlinks (although in a bit
unwieldy way) by using `core.symlinks' configuration variable;
see git-config(1):
core.symlinks::
If false, symbolic links are checked out as small plain files
that contain the link text. git-update-index(1) and git-add(1)
will not change the recorded type to regular file. Useful on
filesystems like FAT that do not support symbolic links. True
by default.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Miklos Vajna @ 2008-06-24 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Pieter de Bie, git
In-Reply-To: <7vk5gea0ff.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 197 bytes --]
On Tue, Jun 24, 2008 at 04:16:36PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> It most likely makes sense to do (3) anyway. upload-pack, receive-pack,
> anything else?
I think that's all.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Windows symlinks
From: Robin Rosenberg @ 2008-06-24 23:29 UTC (permalink / raw)
To: Patrick.Higgins; +Cc: git
In-Reply-To: <911589C97062424796D53B625CEC0025E4618F@USCOBRMFA-SE-70.northamerica.cexp.com>
onsdagen den 25 juni 2008 00.42.49 skrev Patrick.Higgins@cexp.com:
> It looks like one of the bigger (biggest?) hurdles for git adoption at my company is going to be handling symlinks on Windows. We may be able to sidestep the issue entirely by having developers run Linux in a virtual machine (or better yet, Windows in a VM) because we deploy to Linux and thus can make a very strong argument that developers should develop on Linux, too. That run into an image problem where people might start blaming git for needing to have an extra operating system around just for revision control.
Right, they could use only Linux and not have an extra OS for email..
>
> We currently use Clearcase snapshot views on Windows and it has some kind of magic to be able to deal with symlinks. I haven't actually used the Windows version of Clearcase so I don't know how it does it, but my understanding is that it handles them with copies, and I guess it somehow knows to update all the copies when a change is made.
It is one of the few sane things clearcase does. msysgit's approach is just unusable. I've not come up with the patches yet. Clearcase makes copies
instead of the symlinks and updates them on checkout/checkin and update.
Git could do one step better by updating copies when index is updated, avoiding an unnecessary commit (which is pretty annoying in CC).
Invalid symlinks, i.e. pointing at non-existent objects or outside then VOB (repository in Git parlance, don't show up at all in snapshot views. Git could do the same thereby making the workdir usable
when it contains and depends on symlinks.
> Has anyone thought about a way for git to handle symlinks? Vista seems to have added native symlinks, but you need have elevated privilege to create
> them. NTFS junction points seem helpful for older versions of Windows, but don't work for anything except directories, and seem to be dangerous to use with tools that do recursive deletes. Neither junction points nor native symlinks sound like great options.
Obviously one could make this a switchable feature and enable it when the
file system supports it. As for junction points i'd say no too. What little testing I did on symlinks in vista they seem capable of most sane uses.
> Cygwin's clever symlink trick seems to work pretty well in practice. I'm not exactly sure what it's doing, but it seems to create a shortcut that it's own programs understand. Some other non-Cygwin programs seem to understand them, too, but Java does not which is a big problem for me.
>
> I just don't see any good solutions here. Does anyone have any better ideas?
No, copies. If you have a patch I can test it and then implement it for jgit, which doesn't have symlinks either.
-- robin
^ permalink raw reply
* Re: [PATCH] pre-commit hook should ignore carriage returns at EOL
From: Jakub Narebski @ 2008-06-24 23:34 UTC (permalink / raw)
To: Christian Holtje; +Cc: Junio C Hamano, git
In-Reply-To: <930163B6-4A7E-49C7-B9D5-F7B37699C2A9@gmail.com>
Christian Holtje <docwhat@gmail.com> writes:
> Based on the information about core.whitespace doesn't git do this
> already? Maybe we should just delete the pre-commit hook or make it
> empty with a note saying what you can do with it?
pre-commit hook also detects unresolved merge conflicts, which
core.whitespace doesn't (and probably shouldn't).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ 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