* [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
This is a small set of patches to git-p4 to fix a couple of issues with
branches and labels.
This is the second version of this patch series; the first one vanished
without trace :-)
Firstly, I've added the fixes needed so that branches and labels can
contain shell metacharacters (missed from the previous series). Added
a test case for this.
In adding the test case for labels I also found and fixed a few other
small bugs in the label handling:
- labels missing a description or "EOT" in their text cause problems;
- labels without an owner cause problems.
I also noticed, but did not fix, that you can't have more than one label
per commit (the others are silently dropped) and the documentation for
branch import could be improved. I've added a (failing) test case for
the multiple label problem.
Luke Diamand (4):
git-p4: handle p4 branches and labels containing shell chars
git-p4: cope with labels with empty descriptions
git-p4: importing labels should cope with missing owner
git-p4: add test for p4 labels
contrib/fast-import/git-p4 | 61 +++++++++++++-----------
t/t9801-git-p4-branch.sh | 48 ++++++++++++++++++
t/t9804-git-p4-label.sh | 114 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 195 insertions(+), 28 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply
* [PATCHv2 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1322643817-13051-1-git-send-email-luke@diamand.org>
Don't use shell expansion when detecting branches, as it will
fail if the branch name contains a shell metachar. Similarly
for labels.
Add additional test for branches with shell metachars.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++---
t/t9801-git-p4-branch.sh | 48 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index b975d67..bcac6ec 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -793,7 +793,7 @@ class P4Submit(Command, P4UserMap):
def canChangeChangelists(self):
# check to see if we have p4 admin or super-user permissions, either of
# which are required to modify changelists.
- results = p4CmdList("protects %s" % self.depotPath)
+ results = p4CmdList(["protects", self.depotPath])
for r in results:
if r.has_key('perm'):
if r['perm'] == 'admin':
@@ -1528,7 +1528,7 @@ class P4Sync(Command, P4UserMap):
def getLabels(self):
self.labels = {}
- l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
+ l = p4CmdList(["labels", "%s..." % ' '.join (self.depotPaths)])
if len(l) > 0 and not self.silent:
print "Finding files belonging to labels in %s" % `self.depotPaths`
@@ -1570,7 +1570,7 @@ class P4Sync(Command, P4UserMap):
command = "branches"
for info in p4CmdList(command):
- details = p4Cmd("branch -o %s" % info["branch"])
+ details = p4Cmd(["branch", "-o", info["branch"]])
viewIdx = 0
while details.has_key("View%s" % viewIdx):
paths = details["View%s" % viewIdx].split(" ")
@@ -1708,7 +1708,7 @@ class P4Sync(Command, P4UserMap):
sourceRef = self.gitRefForBranch(sourceBranch)
#print "source " + sourceBranch
- branchParentChange = int(p4Cmd("changes -m 1 %s...@1,%s" % (sourceDepotPath, firstChange))["change"])
+ branchParentChange = int(p4Cmd(["changes", "-m", "1", "%s...@1,%s" % (sourceDepotPath, firstChange)])["change"])
#print "branch parent: %s" % branchParentChange
gitParent = self.gitCommitByP4Change(sourceRef, branchParentChange)
if len(gitParent) > 0:
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index a25f18d..bd08dff 100755
--- a/t/t9801-git-p4-branch.sh
+++ b/t/t9801-git-p4-branch.sh
@@ -226,6 +226,54 @@ test_expect_success 'git-p4 clone simple branches' '
)
'
+# Create a branch with a shell metachar in its name
+#
+# 1. //depot/main
+# 2. //depot/branch$3
+
+test_expect_success 'branch with shell char' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ (
+ cd "$cli" &&
+
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ p4 integrate //depot/main/... //depot/branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ echo f1 >branch\$3/shell_char_branch_file &&
+ p4 add branch\$3/shell_char_branch_file &&
+ p4 submit -d "branch\$3/shell_char_branch_file" &&
+
+ p4 branch -i <<-EOF &&
+ Branch: branch\$3
+ View: //depot/main/... //depot/branch\$3/...
+ EOF
+
+ p4 edit main/f1 &&
+ echo "a change" >> main/f1 &&
+ p4 submit -d "a change" main/f1 &&
+
+ p4 integrate -b branch\$3 &&
+ p4 resolve -am branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ cd "$git" &&
+
+ git config git-p4.branchList main:branch\$3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch\$3 &&
+ test -f shell_char_branch_file &&
+ test -f f1
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv2 2/4] git-p4: cope with labels with empty descriptions
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1322643817-13051-1-git-send-email-luke@diamand.org>
Use an explicit length for the data in a label, rather
than EOT, so that labels with empty descriptions are
passed through correctly.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index bcac6ec..02f0f54 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1511,9 +1511,11 @@ class P4Sync(Command, P4UserMap):
else:
tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
self.gitStream.write("tagger %s\n" % tagger)
- self.gitStream.write("data <<EOT\n")
- self.gitStream.write(labelDetails["Description"])
- self.gitStream.write("EOT\n\n")
+
+ description = labelDetails["Description"]
+ self.gitStream.write("data %d\n" % len(description))
+ self.gitStream.write(description)
+ self.gitStream.write("\n")
else:
if not self.silent:
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv2 4/4] git-p4: add test for p4 labels
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1322643817-13051-1-git-send-email-luke@diamand.org>
Add basic test of p4 label import. Checks label import and
import with shell metachars; labels with different length
descriptions.
Add failure test case for multiple labels.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9804-git-p4-label.sh | 114 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 114 insertions(+), 0 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
diff --git a/t/t9804-git-p4-label.sh b/t/t9804-git-p4-label.sh
new file mode 100755
index 0000000..a46763f
--- /dev/null
+++ b/t/t9804-git-p4-label.sh
@@ -0,0 +1,114 @@
+test_description='git-p4 p4 label tests'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+# Basic p4 label tests.
+#
+# Note: can't have more than one label per commit - others
+# are silently discarded.
+#
+test_expect_success 'basic p4 labels' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$cli" &&
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ echo f2 >main/f2 &&
+ p4 add main/f2 &&
+ p4 submit -d "main/f2" &&
+
+ echo f3 >main/file_with_\$metachar &&
+ p4 add main/file_with_\$metachar &&
+ p4 submit -d "file with metachar" &&
+
+ p4 tag -l tag_f1_only main/f1 &&
+ p4 tag -l tag_with\$_shell_char main/... &&
+
+ echo f4 >main/f4 &&
+ p4 add main/f4 &&
+ p4 submit -d "main/f4" &&
+
+ p4 label -i <<-EOF &&
+ Label: long_label
+ Description:
+ A Label first line
+ A Label second line
+ View: //depot/...
+ EOF
+
+ p4 tag -l long_label ... &&
+
+ p4 labels ... &&
+
+ cd "$git" &&
+ pwd &&
+ "$GITP4" clone --dest=. --detect-labels //depot@all &&
+
+ git tag &&
+ git tag >taglist &&
+ test_line_count = 3 taglist &&
+
+ cd main &&
+ git checkout tag_tag_f1_only &&
+ ! test -f f2 &&
+ git checkout tag_tag_with\$_shell_char &&
+ test -f f1 && test -f f2 && test -f file_with_\$metachar &&
+
+ git show tag_long_label | grep -q "A Label second line"
+ )
+'
+
+# Test some label corner cases:
+#
+# - two tags on the same file; both should be available
+# - a tag that is only on one file; the other file should
+# not be checked out on the tag.
+
+test_expect_failure 'two labels on the same changelist' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$cli" &&
+ mkdir -p main &&
+
+ p4 edit main/f1 main/f2 &&
+ echo "hello world" >main/f1 &&
+ echo "not in the tag" >main/f2 &&
+ p4 submit -d "main/f[12]: testing two labels" &&
+
+ p4 tag -l tag_f1_1 main/f1 &&
+ p4 tag -l tag_f1_2 main/f1 &&
+
+ p4 labels ... &&
+
+ cd "$git" &&
+ pwd &&
+ "$GITP4" clone --dest=. --detect-labels //depot@all &&
+
+ git tag | grep -q tag_f1_1 &&
+ git tag | grep -q tag_f1_2 &&
+
+ cd main &&
+
+ git checkout tag_tag_f1_1 &&
+ test -f f1 &&
+
+ git checkout tag_tag_f1_1 &&
+ test -f f1 &&
+
+ ! test -f f2
+ )
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv2 3/4] git-p4: importing labels should cope with missing owner
From: Luke Diamand @ 2011-11-30 9:03 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1322643817-13051-1-git-send-email-luke@diamand.org>
In p4, the Owner field is optional. If it is missing,
construct something sensible rather than crashing.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 45 +++++++++++++++++++++++--------------------
1 files changed, 24 insertions(+), 21 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 02f0f54..d97f927 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -553,6 +553,27 @@ class Command:
def __init__(self):
self.usage = "usage: %prog [options]"
self.needsGit = True
+ self.myP4UserId = None
+
+ def p4UserId(self):
+ if self.myP4UserId:
+ return self.myP4UserId
+
+ results = p4CmdList("user -o")
+ for r in results:
+ if r.has_key('User'):
+ self.myP4UserId = r['User']
+ return r['User']
+ die("Could not find your p4 user id")
+
+ def p4UserIsMe(self, p4User):
+ # return True if the given p4 user is actually me
+ me = self.p4UserId()
+ if not p4User or p4User != me:
+ return False
+ else:
+ return True
+
class P4UserMap:
def __init__(self):
@@ -694,7 +715,6 @@ class P4Submit(Command, P4UserMap):
self.verbose = False
self.preserveUser = gitConfig("git-p4.preserveUser").lower() == "true"
self.isWindows = (platform.system() == "Windows")
- self.myP4UserId = None
def check(self):
if len(p4CmdList("opened ...")) > 0:
@@ -802,25 +822,6 @@ class P4Submit(Command, P4UserMap):
return 1
return 0
- def p4UserId(self):
- if self.myP4UserId:
- return self.myP4UserId
-
- results = p4CmdList("user -o")
- for r in results:
- if r.has_key('User'):
- self.myP4UserId = r['User']
- return r['User']
- die("Could not find your p4 user id")
-
- def p4UserIsMe(self, p4User):
- # return True if the given p4 user is actually me
- me = self.p4UserId()
- if not p4User or p4User != me:
- return False
- else:
- return True
-
def prepareSubmitTemplate(self):
# remove lines in the Files section that show changes to files outside the depot path we're committing into
template = ""
@@ -1506,7 +1507,9 @@ class P4Sync(Command, P4UserMap):
owner = labelDetails["Owner"]
tagger = ""
- if author in self.users:
+ if not owner:
+ tagger = "%s <a@b> %s %s" % (self.p4UserId(), epoch, self.tz)
+ elif author in self.users:
tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
else:
tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* Re: [RFC/PATCH] remote: add new sync command
From: Felipe Contreras @ 2011-11-30 11:47 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111130070111.GE5317@sigill.intra.peff.net>
On Wed, Nov 30, 2011 at 9:01 AM, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 22, 2011 at 01:47:36AM +0200, Felipe Contreras wrote:
>
>> > I didn't mean "you didn't define a mirror in your config". I meant "your
>> > question is not well-defined, because you haven't defined the term
>> > 'mirror'". IOW, I can't answer your question without knowing exactly
>> > what you meant.
>>
>> I wasn't the one that brought the mirror up, you did:
>
> Yes, because that is the most related concept in current git. But I
> thought you were asking from the perspective of a clueless user, and I
> don't know what that clueless user meant by "mirror".
I don't think common users know, or should care about, what a "mirror" is.
> Anyway, I don't think it's important.
Me neither.
> I read over your whole message, and I feel like our discussion isn't
> really moving towards an actual goal. Junio and I both mentioned that in
> the long-term, features like this should be part of "push", not
> "remote". Do you want to try revising your patch in that direction?
Yes, I can try that for 'git push', but my worry is about 'git fetch'.
To me it's really clear that what I am trying to achieve is more
complicated than a simple push/fetch.
You still haven't replied to my solution to synchronize the local
branches, which to first do a 'git fetch' so we have the remote
branches tracked locally, and go through each one of them and do
something to the local ones. This solution works, is simple, and
allows all kinds of options, but IMO it's not part of 'git fetch'.
> That will give us something concrete to talk about (and hopefully
> apply).
Yes, but that's basically 'git push --prune', which I think is the
only thing we have agreed. But what about the rest?
I feel you are trying to ignore the fact that 'refs/heads/*' is not
user-friendly, neither is BRANCHES, or :, and 'git fetch' would be
even more cumbersome.
The user-friendliness of git is one of the biggest complains people
have, and while it makes sense to keep certain operations under
push/fetch, there's only so much pureness we can have before things
become too complicated for the users. The fact of the matter is that
these particular remote synchronization operations are much easier to
picture mentally in a group like 'git remote sync'. That not only
works for all the cases, including 'git fetch', but it's
non-intrusive, and most importantly: user-friendly.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: two branches: keep one difference but merge others forth and back
From: Tor Arntsen @ 2011-11-30 12:37 UTC (permalink / raw)
To: Gelonida N; +Cc: git
In-Reply-To: <jats5v$r7c$1@dough.gmane.org>
On Sun, Nov 27, 2011 at 18:31, Gelonida N <gelonida@gmail.com> wrote:
> Hi,
>
>
> Is this possible.
>
>
> I'd like to have two branches.
>
> If possible I would be able to merge forth and back between both of them.
>
> However I would like, that certain differences will be kept between both
> branches.
>
> Is there any way to tell git to permanently ignoring certain commits
> from merging?
Instead of merging, you could use rebasing. So you have one
development branch where you do all the changes, and then another
branch where the only commit there is that special difference (as in
your /usr/bin/bash example). From then on you only develop/maintain
the original branch, and then you rebase the 'special' branch on top
of the development branch. Then you get all the updates, plus your
special change applied on top each time.
Likewise, if you have two variants (say, one /bin/bash, another
/usr/bin/bash, and then one with /usr/local/bin/bash) then create two
branches and rebase them on top of the third branch (the development
branch) every time you wish to deploy new updates.
-Tor
^ permalink raw reply
* Status after 'git clone --no-checkout' ?
From: norbert.nemec @ 2011-11-30 13:02 UTC (permalink / raw)
To: git
Hi there,
what exactly is the status after 'git clone --no-checkout'? Is there any
straightforward way how one could end up in this state starting from a
regularly checked out repository?
A somewhat related question:
'git checkout' without any further options serves to move from the
aforementioned special state to a regular checked out state. Otherwise
it never seems to do anything. Are there any other situations where 'git
checkout' on its own would have any effect?
Thanks for any insight on this!
Norbert Nemec
^ permalink raw reply
* Re: [PATCH] Implement fast hash-collision detection
From: Nguyen Thai Ngoc Duy @ 2011-11-30 13:35 UTC (permalink / raw)
To: Jeff King; +Cc: Bill Zaumen, git, gitster, spearce, torvalds
In-Reply-To: <20111129205905.GA1793@sigill.intra.peff.net>
On Wed, Nov 30, 2011 at 3:59 AM, Jeff King <peff@peff.net> wrote:
> If you wanted to say "make a digest of all of the sub-objects pointed to
> by the tag", then yes, that does work (security-wise). But it's
> expensive to calculate. Instead, you want to use a "digest of digests"
> as much as possible. Which is what git already does, of course; you hash
> the tree object, which contains hashes of the blob sha1s. Git's
> conceptual model is fine. The only problem is that sha1 is potentially
> going to lose its security properties, weakening the links in the chain.
> So as much as possible, we want to insert additional links at the exact
> same places, but using a stronger algorithm.
What I'm thinking is whether it's possible to decouple two sha-1 roles
in git, as object identifier and digest, separately. Each sha-1
identifies an object and an extra set of digests on the "same" object.
Object database is extended to store all these new digests and mapping
between sha-1 and them. When we need to verify an object, given an
sha-1, we rehash that object and check the result digest with the ones
linked to the sha-1.
These new digests would be "digest of digests" just like how we use
sha-1. In fact this new digest set could be just sha-1. We just don't
hash trees/commits/tags as-is when computing these new digests. When a
tree object is hashed, for example, a new tree object with new digests
will be created for hashing (we keep sha-1 <-> new digest mapping on
disk). Think of duplicating an entire DAG with new digests as links
instead of sha-1, then we keep digests and drop the DAG.
The day sha-1 is broken, a project can generate new digests from its
old good repo and enforce developers to use new digests for
verification instead of sha-1. sha-1 is still used by git as
identifier after that day.
Computing these digests is expensive, but for local, day-to-day use,
we only need sha-1 as identifier (correct me if I'm wrong here), so we
can delay compute/store these new digests until we absolutely need
them (e.g. push/fetch). There is also an interesting case, assume
these digests are strong enough, we could replace sha-1 as identifier
in git with a cheaper hash. A new hash must fit in 160-bit space that
sha-1 takes and should have good distribution, of course. Projects
with a lot of data may like it that way.
--
Duy
^ permalink raw reply
* Re: [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Vitor Antunes @ 2011-11-30 14:55 UTC (permalink / raw)
To: git
In-Reply-To: <1322643817-13051-1-git-send-email-luke@diamand.org>
Luke Diamand <luke <at> diamand.org> writes:
> In adding the test case for labels I also found and fixed a few other
> small bugs in the label handling:
>
> - labels missing a description or "EOT" in their text cause problems;
> - labels without an owner cause problems.
>
> I also noticed, but did not fix, that you can't have more than one label
> per commit (the others are silently dropped) and the documentation for
> branch import could be improved. I've added a (failing) test case for
> the multiple label problem.
Hi Luke,
Seeing that you have some experience using labels, could I kindly ask you to
include some description of it in git-p4.txt?
Thanks,
Vitor
^ permalink raw reply
* Re: [PATCH] rebase -i: interrupt rebase when "commit --amend" failed during "reword"
From: Andrew Wong @ 2011-11-30 15:52 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
In-Reply-To: <7vk46isncq.fsf@alter.siamese.dyndns.org>
On 11-11-29 3:08 PM, Junio C Hamano wrote:
> Is there anything we should be saying more than "fatal: Cannot amend" to
> help users when this new "die" triggers?
Ah, yes, that would be helpful.
The situation is actually very similar to an "edit", where a pick is successful
but requires user intervention. So I'm planning to refactor the behavior and
message from "edit" into a function called "exit_with_patch". Then call the
function from "reword" as well. Though it bothers me a bit that I have to pass
in an exit code as well, since we want the exit status for "reword" to indicate
a failure, but "edit" needs to indicate a success. Is this acceptable? Or
should I just not bother with refactoring?
Andrew Wong (1):
rebase -i: interrupt rebase when "commit --amend" failed during
"reword"
git-rebase--interactive.sh | 36 +++++++++++++++++++++++-------------
1 files changed, 23 insertions(+), 13 deletions(-)
--
1.7.8.rc3.32.gb0399.dirty
^ permalink raw reply
* [PATCH] rebase -i: interrupt rebase when "commit --amend" failed during "reword"
From: Andrew Wong @ 2011-11-30 15:52 UTC (permalink / raw)
To: git; +Cc: Andrew Wong
In-Reply-To: <1322668371-21218-1-git-send-email-andrew.kw.w@gmail.com>
"commit --amend" could fail in cases like the user empties the commit
message, or pre-commit failed. When it fails, rebase should be
interrupted and alert the user, rather than ignoring the error and
continue on rebasing. This also gives users a way to gracefully
interrupt a "reword" if they decided they actually want to do an "edit",
or even "rebase --abort".
Signed-off-by: Andrew Wong <andrew.kw.w@gmail.com>
---
git-rebase--interactive.sh | 36 +++++++++++++++++++++++-------------
1 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 804001b..5812222 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -143,6 +143,21 @@ die_with_patch () {
die "$2"
}
+exit_with_patch () {
+ echo "$1" > "$state_dir"/stopped-sha
+ make_patch $1
+ git rev-parse --verify HEAD > "$amend"
+ warn "You can amend the commit now, with"
+ warn
+ warn " git commit --amend"
+ warn
+ warn "Once you are satisfied with your changes, run"
+ warn
+ warn " git rebase --continue"
+ warn
+ exit $2
+}
+
die_abort () {
rm -rf "$state_dir"
die "$1"
@@ -408,7 +423,13 @@ do_next () {
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
- git commit --amend --no-post-rewrite
+ git commit --amend --no-post-rewrite || {
+ warn "Could not amend commit after successfully picking $sha1... $rest"
+ warn "This is most likely due to an empty commit message, or the pre-commit hook"
+ warn "failed. If the pre-commit hook failed, you may need to resolve the issue before"
+ warn "you are able to reword the commit."
+ exit_with_patch $sha1 1
+ }
record_in_rewritten $sha1
;;
edit|e)
@@ -417,19 +438,8 @@ do_next () {
mark_action_done
pick_one $sha1 ||
die_with_patch $sha1 "Could not apply $sha1... $rest"
- echo "$sha1" > "$state_dir"/stopped-sha
- make_patch $sha1
- git rev-parse --verify HEAD > "$amend"
warn "Stopped at $sha1... $rest"
- warn "You can amend the commit now, with"
- warn
- warn " git commit --amend"
- warn
- warn "Once you are satisfied with your changes, run"
- warn
- warn " git rebase --continue"
- warn
- exit 0
+ exit_with_patch $sha1 0
;;
squash|s|fixup|f)
case "$command" in
--
1.7.8.rc3.32.gb0399.dirty
^ permalink raw reply related
* Re: [PATCH 3/3] fast-export: output reset command for commandline revs
From: Thomas Rast @ 2011-11-30 16:56 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, Git List,
Daniel Barkalow, Ramkumar Ramachandra, Dmitry Ivankov,
Johannes Schindelin, Ævar Arnfjörð Bjarmason,
Eric Herman, Fernando Vezzosi
In-Reply-To: <1320535407-4933-4-git-send-email-srabbelier@gmail.com>
Sverre Rabbelier wrote:
> When a revision is specified on the commandline we explicitly output
> a 'reset' command for it if it was not handled already. This allows
> for example the remote-helper protocol to use fast-export to create
> branches that point to a commit that has already been exported.
>
> Initial-patch-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
My apologies if this is redundant, I'm not up to speed on progress
here. But a crash in t9350.19 caught my eye:
checking known breakage:
(
cd limit-by-paths &&
git fast-export master~2..master~1 > output &&
test_cmp output expected
)
==23766== Invalid read of size 1
==23766== at 0x4FD21E: prefixcmp (strbuf.c:9)
==23766== by 0x42B936: handle_tags_and_duplicates (fast-export.c:563)
==23766== by 0x42C274: cmd_fast_export (fast-export.c:732)
==23766== by 0x4051F1: run_builtin (git.c:308)
==23766== by 0x40538B: handle_internal_command (git.c:466)
==23766== by 0x4054A5: run_argv (git.c:512)
==23766== by 0x40562C: main (git.c:585)
==23766== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==23766==
{
<insert_a_suppression_name_here>
Memcheck:Addr1
fun:prefixcmp
fun:handle_tags_and_duplicates
fun:cmd_fast_export
fun:run_builtin
fun:handle_internal_command
fun:run_argv
fun:main
}
==23766==
==23766== Process terminating with default action of signal 11 (SIGSEGV)
==23766== Access not within mapped region at address 0x0
==23766== at 0x4FD21E: prefixcmp (strbuf.c:9)
==23766== by 0x42B936: handle_tags_and_duplicates (fast-export.c:563)
==23766== by 0x42C274: cmd_fast_export (fast-export.c:732)
==23766== by 0x4051F1: run_builtin (git.c:308)
==23766== by 0x40538B: handle_internal_command (git.c:466)
==23766== by 0x4054A5: run_argv (git.c:512)
==23766== by 0x40562C: main (git.c:585)
The crash is hidden by the fact that the test is test_expect_failure.
It bisects to this commit. Perhaps we should distinguish between
test_expect_failure and test_expect_crash?...
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: John Twilley @ 2011-11-30 17:43 UTC (permalink / raw)
To: git
Today someone asked me if there was a way to run git against a
directory other than the current directory. I looked at the output of
--help and ran this:
$ git --work-tree blah status
I got the following output:
fatal: Not a git repository (or any parent up to mount parent /home)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
I mistakenly thought the error message meant that blah was not a git
repository. What it meant was that there was no .git in the current
directory or any parent directory up to /home.
This command worked as expected:
$ git --work-tree blah --git-dir blah/.git status
The documentation is somewhat fuzzy about what constitutes a git
repository. The gittutorial describes the git repository as .git when
talking about "git init" while the Git User's Manual describes the git
repository as the working tree and the special top-level directory
named .git when talking about "git clone".
It's clear (to me at least) that --work-tree should be used to
identify the root of the working tree when not inside the working
tree. I expected that the git directory would be automatically set to
.git in the root of the working tree, as that would match the
documentation. Instead, the current directory and its parents were
checked -- which could provide dangerously misleading information to
the user.
I think that one of two things should be done: either the --git-dir
default should be changed when the --work-tree option is set, or the
error message cited above should be changed to explicitly identify the
directory being tested as a potential git repository. I personally
believe the first option is superior because it fulfills the
expectations of average users (folks who read git's documentation
instead of its source code) while permitting flexibility to those who
wish to refer to the current directory or some other directory for
their --git-dir value. If the current behavior is somehow not a bug
but instead a critical and significant feature which if changed would
cause more harm than good, please consider the second option.
Jack.
--
mathuin at gmail dot com
^ permalink raw reply
* Re: [PATCH] Implement fast hash-collision detection
From: Junio C Hamano @ 2011-11-30 18:05 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Jeff King, Bill Zaumen, git, gitster, spearce, torvalds
In-Reply-To: <CACsJy8A6kGmn0h0xdxfTC4krXgc8hzO1fHTdqfk0YnASGN5K0w@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> What I'm thinking is whether it's possible to decouple two sha-1 roles
> in git, as object identifier and digest, separately.
Why it would be a good thing? If you have a collided identifier, somebody
has to choose which blob a particular tree wants to have at the path, and
because the tree would not record anything but the identifier, you cannot.
> ...
> The day sha-1 is broken, a project can generate new digests from its
> old good repo and enforce developers to use new digests for
> verification instead of sha-1. sha-1 is still used by git as
> identifier after that day.
And an old blob that is identified with a SHA-1 now has a new blob that
has different contents but happens to have the same SHA-1. How does Git
decide which blob to use when a particular object is named by the SHA-1?
^ permalink raw reply
* Re: BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: Carlos Martín Nieto @ 2011-11-30 18:22 UTC (permalink / raw)
To: John Twilley; +Cc: git
In-Reply-To: <CAEUMa-cA8qPjJuPBREE1RqhgwmcZG7x1MjBYkxa3i+ZSAnMPOA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4175 bytes --]
On Wed, Nov 30, 2011 at 09:43:08AM -0800, John Twilley wrote:
> Today someone asked me if there was a way to run git against a
> directory other than the current directory. I looked at the output of
> --help and ran this:
>
> $ git --work-tree blah status
>
> I got the following output:
>
> fatal: Not a git repository (or any parent up to mount parent /home)
> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
>
> I mistakenly thought the error message meant that blah was not a git
> repository. What it meant was that there was no .git in the current
> directory or any parent directory up to /home.
Yes, git looks at the current directory and .git/ to see if there's a
git repository there. This is what happens unless you tell git to look
for it somewhere else.
>
> This command worked as expected:
>
> $ git --work-tree blah --git-dir blah/.git status
>
> The documentation is somewhat fuzzy about what constitutes a git
> repository. The gittutorial describes the git repository as .git when
> talking about "git init" while the Git User's Manual describes the git
> repository as the working tree and the special top-level directory
> named .git when talking about "git clone".
A git repository is what's under .git/ (or in foo.git/ for bare
repos). Non-bare repositories have a working tree associated with
them, which by default lives just above the repository, because it'd
be silly to have it somewhere else by default. Often you can think of
both as the repository, as they're both. When you tell git to look for
the worktree somewhere else, you're only overriding that particular
variable, as git expects to be run from the repository (or just above,
in the worktree).
>
> It's clear (to me at least) that --work-tree should be used to
> identify the root of the working tree when not inside the working
> tree. I expected that the git directory would be automatically set to
> .git in the root of the working tree, as that would match the
> documentation. Instead, the current directory and its parents were
> checked -- which could provide dangerously misleading information to
> the user.
What part of the documentation exactly? --work-tree tells git to look
for the working tree somewhere else. This option exists in order to
support a multiple-workdir workflow.
>
> I think that one of two things should be done: either the --git-dir
> default should be changed when the --work-tree option is set, or the
> error message cited above should be changed to explicitly identify the
> directory being tested as a potential git repository. I personally
Git does tell you explicitly, but only when you specify a gitdir (via
GIT_DIR or --git-dir), otherwise it looks at the current directory.
> believe the first option is superior because it fulfills the
> expectations of average users (folks who read git's documentation
> instead of its source code) while permitting flexibility to those who
It's not likely that it will get changed because that would break
backwards-compatability in a very big way. If your concern is for
"average user", she shouldn't be using that option, but changing to
that directory instead. If you want your working tree to be ./foo/ and
your gitdir to be ./foo/.git, why don't you just cd to ./foo/?
> wish to refer to the current directory or some other directory for
> their --git-dir value. If the current behavior is somehow not a bug
> but instead a critical and significant feature which if changed would
> cause more harm than good, please consider the second option.
You get two different messages depending on how git is looking for the
repository. The message you mentioned gets printed when git tries to
find it automatically. A "fatal: Not a git repository: '/tmp'" gets
printed if you've told git to look for it in a specific place. The
information is already there, though I guess you do have to know about
the difference. Adding the current directory to the "default" message
probably wouldn't hurt, as it's unlikely that a script is parsing
that, and might be useful.
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: log: option "--follow" not the default for a single file?
From: Junio C Hamano @ 2011-11-30 18:27 UTC (permalink / raw)
To: Jeff King; +Cc: Ralf Thielow, git
In-Reply-To: <20111130063743.GB5317@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 2. It can be slower than a regular traversal, since we have to do
> rename detection whenever we see a deletion. In practice I don't
> think it is much slower, though (mainly because files don't get
> moved all that much).
There is no difference between a regular traversal and a follow traversal
while the path is still there. When a path disappear during a regular
traversal, most likely the remaining traversal will yield nothing but the
user has already seen what is there to see. If a follow traversal was in
use, the user has seen the same as the regular traversal up to that point,
we spend a bit of time in rename detection, and then we start showing the
result of the traversal using an updated pathspec. I doubt that "slowness"
is an issue here.
^ permalink raw reply
* Re: log: option "--follow" not the default for a single file?
From: Ralf Thielow @ 2011-11-30 18:38 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111130063743.GB5317@sigill.intra.peff.net>
> pathspec. That may happen to match a single file in the current> revision, but to git it is actually a prefix-limiting pattern, and
Is it possible to detect the case of a single file in the current
revisionand use "--follow" by default for exactly that?
^ permalink raw reply
* Re: [PATCH] Implement fast hash-collision detection
From: Bill Zaumen @ 2011-11-30 19:00 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Jeff King, git, gitster, spearce, torvalds
In-Reply-To: <CACsJy8A6kGmn0h0xdxfTC4krXgc8hzO1fHTdqfk0YnASGN5K0w@mail.gmail.com>
[Will send a reply to Jeff's comment from last night with some
clarifications and explanations later].
> What I'm thinking is whether it's possible to decouple two sha-1 roles
> in git, as object identifier and digest, separately. Each sha-1
> identifies an object and an extra set of digests on the "same" object.
> Object database is extended to store all these new digests and mapping
> between sha-1 and them. When we need to verify an object, given an
> sha-1, we rehash that object and check the result digest with the ones
> linked to the sha-1.
The patch I created (at least, a reasonable chunk of the code) kind of
does that: it is very easy to change the CRC to whatever message digest
one wants. I used a CRC primarily because I had the impression that
people were very concerned about speed, but it is easy to change that to
the message digest of your choice. In any case, it might be a good
starting point if you want to try something in a different direction.
Basically, when you create a loose object, in addition to getting a
SHA-1 ID, you get a message digest that gets stored as well (in a
separate file). When you index a pack file, you get an IDX file
containing the SHA-1 ID plus a corresponding MDS file containing the
message digest. Index-pack calculates the SHA-1 value from the object
stored in the pack file, and the (additional) message digest is computed
at the same time using the same data. Commands like verify-pack check
both the IDX file and the MDS file for consistency with the matching
pack file. The new message digest (the CRC in the patch) is used only
in cases where a repository is being altered (e.g., a loose object or
pack file is being created or a fetch, push, or pull operation) or some
explicit verification operation is running (e.g., git verify-pack).
Adding an additional header to the commit message is a good idea (I had
actually tried that, but something went wrong, although one of you
suggested what the problem might have been --- I can try again if there
is some interest in pursuing that).
It might be worth pointing out that you can use the SHA-1 hash of the
contents of objects (e.g., without the Git object header) as an
additional digest: I tried a test using two 128-byte files with the
same MD5 hash, differing past the 20th byte, and deleted the first
four bytes of each. With those bytes deleted, the hash collision
went away. I doubt if there is a known efficient algorithm that can
generate a hash collision for two files and for two other files that
differ from the first set by deleting N bytes from both.
^ permalink raw reply
* Re: BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: John Twilley @ 2011-11-30 19:13 UTC (permalink / raw)
To: Carlos Martín Nieto, git
In-Reply-To: <20111130182230.GC12096@centaur.lab.cmartin.tk>
On Wed, Nov 30, 2011 at 10:22, Carlos Martín Nieto <cmn@elego.de> wrote:
> On Wed, Nov 30, 2011 at 09:43:08AM -0800, John Twilley wrote:
>> Today someone asked me if there was a way to run git against a
>> directory other than the current directory. I looked at the output of
>> --help and ran this:
>>
>> $ git --work-tree blah status
>>
>> I got the following output:
>>
>> fatal: Not a git repository (or any parent up to mount parent /home)
>> Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
>>
>> I mistakenly thought the error message meant that blah was not a git
>> repository. What it meant was that there was no .git in the current
>> directory or any parent directory up to /home.
>
> Yes, git looks at the current directory and .git/ to see if there's a
> git repository there. This is what happens unless you tell git to look
> for it somewhere else.
This makes perfect sense, because nearly every time I run git
commands, I am somewhere within the working tree. The point of my
post was that I was using --work-tree to tell git to look for the git
repository somewhere else (the root of the specified working tree)
which is not what git expected.
>> This command worked as expected:
>>
>> $ git --work-tree blah --git-dir blah/.git status
>>
>> The documentation is somewhat fuzzy about what constitutes a git
>> repository. The gittutorial describes the git repository as .git when
>> talking about "git init" while the Git User's Manual describes the git
>> repository as the working tree and the special top-level directory
>> named .git when talking about "git clone".
>
> A git repository is what's under .git/ (or in foo.git/ for bare
> repos). Non-bare repositories have a working tree associated with
> them, which by default lives just above the repository, because it'd
> be silly to have it somewhere else by default. Often you can think of
> both as the repository, as they're both. When you tell git to look for
> the worktree somewhere else, you're only overriding that particular
> variable, as git expects to be run from the repository (or just above,
> in the worktree).
And it's exactly this issue -- that sometimes the repository is just
the git directory, and sometimes the repository is the working tree
which contains the git directory at its root -- that caused the
confusion and unexpected behavior. If I were to use a bare repository
directly (something I've never done), I guess I might use --git-dir
since the repository may not be named .git but instead something like
proj.git. When I accessed a repository from outside its working tree,
I expected --work-tree to cover the whole shebang. Obviously this
discussion is exposing my relatively limited experience with git, but
these assumptions do not seem unreasonable on their face.
>> It's clear (to me at least) that --work-tree should be used to
>> identify the root of the working tree when not inside the working
>> tree. I expected that the git directory would be automatically set to
>> .git in the root of the working tree, as that would match the
>> documentation. Instead, the current directory and its parents were
>> checked -- which could provide dangerously misleading information to
>> the user.
>
> What part of the documentation exactly? --work-tree tells git to look
> for the working tree somewhere else. This option exists in order to
> support a multiple-workdir workflow.
What you mention above was what I was thinking about when I mentioned
the possibility of this being a critical and significant feature. If
it is important to support a workflow with one git directory and
multiple working trees, and that case is more common/important than
the one I experienced, then changing the behavior of --git-dir is
obviously not the right thing to do.
>> I think that one of two things should be done: either the --git-dir
>> default should be changed when the --work-tree option is set, or the
>> error message cited above should be changed to explicitly identify the
>> directory being tested as a potential git repository. I personally
>
> Git does tell you explicitly, but only when you specify a gitdir (via
> GIT_DIR or --git-dir), otherwise it looks at the current directory.
This is misleading if you don't know that the specification of a
working tree does not also implicitly specify a git directory.
Whether that lack of knowledge is the user's problem or the
software/documentation's problem is a separate question.
>> believe the first option is superior because it fulfills the
>> expectations of average users (folks who read git's documentation
>> instead of its source code) while permitting flexibility to those who
>
> It's not likely that it will get changed because that would break
> backwards-compatability in a very big way. If your concern is for
> "average user", she shouldn't be using that option, but changing to
> that directory instead. If you want your working tree to be ./foo/ and
> your gitdir to be ./foo/.git, why don't you just cd to ./foo/?
From that perspective, why have --work-tree at all? Without that
option, either the git directory is in the root of your current
working tree, or it's not -- in which case --git-dir is all you need.
If you're going to keep the option, it's helpful to provide the
diagnostic output. My suggestion would be more compelling if I could
provide a valid use case, but all I can come up with off the top of my
head are scripts and something like "(cd $worktree && git status)"
would probably work fine.
>> wish to refer to the current directory or some other directory for
>> their --git-dir value. If the current behavior is somehow not a bug
>> but instead a critical and significant feature which if changed would
>> cause more harm than good, please consider the second option.
>
> You get two different messages depending on how git is looking for the
> repository. The message you mentioned gets printed when git tries to
> find it automatically. A "fatal: Not a git repository: '/tmp'" gets
> printed if you've told git to look for it in a specific place. The
> information is already there, though I guess you do have to know about
> the difference. Adding the current directory to the "default" message
> probably wouldn't hurt, as it's unlikely that a script is parsing
> that, and might be useful.
Fewer scripts would be broken if the additional output is only
displayed when --work-tree is used, but that might be too special-case
for this situation.
> cmn
Jack.
--
mathuin at gmail dot com
^ permalink raw reply
* Re: [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Luke Diamand @ 2011-11-30 19:14 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Pete Wyckoff
In-Reply-To: <loom.20111130T155409-599@post.gmane.org>
On 30/11/11 14:55, Vitor Antunes wrote:
> Luke Diamand<luke<at> diamand.org> writes:
>
>> In adding the test case for labels I also found and fixed a few other
>> small bugs in the label handling:
>>
>> - labels missing a description or "EOT" in their text cause problems;
>> - labels without an owner cause problems.
>>
>> I also noticed, but did not fix, that you can't have more than one label
>> per commit (the others are silently dropped) and the documentation for
>> branch import could be improved. I've added a (failing) test case for
>> the multiple label problem.
>
> Hi Luke,
>
> Seeing that you have some experience using labels, could I kindly ask you to
> include some description of it in git-p4.txt?
OK, if you can help me understand what's going on...
The label-detection bug that I've described, on further investigation,
looks to be a fundamental limitation.
With perforce, I can check out the head revision, and then tag just a
single file. If I then check out on that tag, I get just that one file.
I think I can't do that with git; certainly fast-import can't do it.
So the code in git-p4 that is checking the file vs label counts (git-p4
around line 1496) is actually trying to say "this label can't be
imported into git".
If my understanding is correct, I can then fix my test and update the
docs and the code to explain this.
As an aside, git-p4.txt currently has quite good information on the
config variables, but nothing on the command line variables. Possibly
that should be fixed.
Cheers!
Luke
^ permalink raw reply
* Re: BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: Junio C Hamano @ 2011-11-30 19:21 UTC (permalink / raw)
To: John Twilley; +Cc: git
In-Reply-To: <CAEUMa-cA8qPjJuPBREE1RqhgwmcZG7x1MjBYkxa3i+ZSAnMPOA@mail.gmail.com>
John Twilley <mathuin@gmail.com> writes:
> Today someone asked me if there was a way to run git against a
> directory other than the current directory. I looked at the output of
> --help and ran this:
>
> $ git --work-tree blah status
>
> I got the following output:
>
> fatal: Not a git repository (or any parent up to mount parent /home)
Yeah, that is a "this a use case that we didn't even intend to support,
and as a consequence we do a random thing" bug.
Originally, when GIT_DIR is set (from the environment, and then later we
added "git --git-dir=..." as another way to do so), Git always used the
current directory as the top of the working tree. There was no mechanism
for the user to say "No, I am not at the top level, but I am in a
subdirectory of the working tree. The top of working tree is there". That
was the use case GIT_WORK_TREE (from the environment, and then later we
added "git --work-tree=..." as another way to do so) was introduced
for.
So in that sense, it is an unsupported mode of operation and it is not
surprising at all if Git did any random and meaningless things if you used
GIT_WORK_TREE without specifying GIT_DIR at all. In the same sense,
strictly speaking, setting GIT_WORK_TREE to somewhere that is not a parent
directory of the current directory (even if you set GIT_DIR) is also an
unsupported mode of operation.
When GIT_DIR is not set, I think we still run the normal GIT_DIR discovery
starting from the current working directory, and when we do not find one,
we would error out, as you saw. I am sympathetic that your particular case
might have resulted in a more pleasant user experience if the GIT_DIR
discovery started from the directory specified by GIT_WORK_TREE (i.e. the
subdirectory "blah/.git"), but I do not think this is likely to change, as
I suspect that people and scripts are relying on the current behaviour to
be able to do something like this:
cd /pub/scm/git/git.git ;# this is a bare repository
mkdir /var/tmp/git
git --work-tree=/var/tmp/git checkout
to have a temporary checkout, and changing the GIT_DIR discovery logic
will break them, i.e. they now have to do:
cd /pub/scm/git/git.git ;# this is a bare repository
mkdir /var/tmp/git
git --work-tree=/var/tmp/git --git-dir=$(pwd) checkout
or something. Instead, what you wanted to do is already supported by:
(cd blah && git status)
so nothing is lost.
We could reword this:
> fatal: Not a git repository (or any parent up to mount parent /home)
to "fatal: /home/bar/baz (or any parent ...) is not a git repository" to
mention the current directory /home/bar/baz, but I am having a hard time
convincing myself that such a change is particularly good, because almost
always you know where you are (many people have it in their shell prompt).
Such a change makes the message longer to fit on a line without adding
much value.
^ permalink raw reply
* Re: BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: Carlos Martín Nieto @ 2011-11-30 19:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: John Twilley, git
In-Reply-To: <7vaa7dquva.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 629 bytes --]
On Wed, Nov 30, 2011 at 11:21:29AM -0800, Junio C Hamano wrote:
> subdirectory "blah/.git"), but I do not think this is likely to change, as
> I suspect that people and scripts are relying on the current behaviour to
> be able to do something like this:
>
> cd /pub/scm/git/git.git ;# this is a bare repository
> mkdir /var/tmp/git
> git --work-tree=/var/tmp/git checkout
>
This is in fact the way that many (or from what I can see the most
popular) tutorials for abusing git as a deployment system tell you to
run it (though more often than not setting GIT_WORKTREE in the
environment).
cmn
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCHv2 0/4] git-p4: small fixes to branches and labels; tests
From: Vitor Antunes @ 2011-11-30 19:44 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, Pete Wyckoff
In-Reply-To: <4ED6809A.9020703@diamand.org>
On Wed, Nov 30, 2011 at 7:14 PM, Luke Diamand <luke@diamand.org> wrote:
> OK, if you can help me understand what's going on...
>
> The label-detection bug that I've described, on further investigation, looks
> to be a fundamental limitation.
>
> With perforce, I can check out the head revision, and then tag just a single
> file. If I then check out on that tag, I get just that one file.
>
> I think I can't do that with git; certainly fast-import can't do it.
>
> So the code in git-p4 that is checking the file vs label counts (git-p4
> around line 1496) is actually trying to say "this label can't be imported
> into git".
>
> If my understanding is correct, I can then fix my test and update the docs
> and the code to explain this.
>
> As an aside, git-p4.txt currently has quite good information on the config
> variables, but nothing on the command line variables. Possibly that should
> be fixed.
Hey Luke,
I did not have any success in the few times I tried to import labels.
Since you were updating some of that code I was hoping you could
extend git-p4.txt such that I would be able to understand it. This to
say: I can't help you much with my current expertise level on how
labels are implemented. Will need to look into that later.
--
Vitor Antunes
^ permalink raw reply
* Re: BUG: "--work-tree blah" does not imply "--git-dir blah/.git" or fix misleading error message
From: Junio C Hamano @ 2011-11-30 20:45 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: John Twilley, git
In-Reply-To: <20111130194233.GD12096@centaur.lab.cmartin.tk>
Carlos Martín Nieto <carlos@cmartin.tk> writes:
> On Wed, Nov 30, 2011 at 11:21:29AM -0800, Junio C Hamano wrote:
>> subdirectory "blah/.git"), but I do not think this is likely to change, as
>> I suspect that people and scripts are relying on the current behaviour to
>> be able to do something like this:
>>
>> cd /pub/scm/git/git.git ;# this is a bare repository
>> mkdir /var/tmp/git
>> git --work-tree=/var/tmp/git checkout
>
> This is in fact the way that many (or from what I can see the most
> popular) tutorials for abusing git as a deployment system tell you to
> run it (though more often than not setting GIT_WORKTREE in the
> environment).
Heh, *ab*using is a good description if they really mean to use it as a
deployment system. For one thing it won't do anything a proper deployment
should do if the target directory is not empty ;-)
^ 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