* [PATCH 3/4] git-p4: importing labels should cope with missing owner
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-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 | 63 ++++++++++++++++++++++++-------------------
1 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index f7707f2..efb2dad 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -563,6 +563,26 @@ class Command:
class P4UserMap:
def __init__(self):
self.userMapFromPerforceServer = False
+ 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
def getUserCacheFilename(self):
home = os.environ.get("HOME", os.environ.get("USERPROFILE"))
@@ -700,7 +720,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:
@@ -808,25 +827,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 = ""
@@ -1664,6 +1664,12 @@ class P4Sync(Command, P4UserMap):
if self.stream_file.has_key('depotFile'):
self.streamOneP4File(self.stream_file, self.stream_contents)
+ def make_email(self, userid):
+ if userid in self.users:
+ return self.users[userid]
+ else:
+ return "%s <a@b>" % userid
+
def commit(self, details, files, branch, branchPrefixes, parent = ""):
epoch = details["time"]
author = details["user"]
@@ -1687,10 +1693,7 @@ class P4Sync(Command, P4UserMap):
committer = ""
if author not in self.users:
self.getUserMapFromPerforceServer()
- if author in self.users:
- committer = "%s %s %s" % (self.users[author], epoch, self.tz)
- else:
- committer = "%s <a@b> %s %s" % (author, epoch, self.tz)
+ committer = "%s %s %s" % (self.make_email(author), epoch, self.tz)
self.gitStream.write("committer %s\n" % committer)
@@ -1735,11 +1738,15 @@ class P4Sync(Command, P4UserMap):
self.gitStream.write("from %s\n" % branch)
owner = labelDetails["Owner"]
- tagger = ""
- if author in self.users:
- tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
+
+ # Try to use the owner of the p4 label, or failing that,
+ # the current p4 user id.
+ if owner:
+ email = self.make_email(owner)
else:
- tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
+ email = self.make_email(self.p4UserId())
+ tagger = "%s %s %s" % (email, epoch, self.tz)
+
self.gitStream.write("tagger %s\n" % tagger)
description = labelDetails["Description"]
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCH 4/4] git-p4: add test for p4 labels
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-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.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9804-git-p4-label.sh | 73 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 73 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..eba3521
--- /dev/null
+++ b/t/t9804-git-p4-label.sh
@@ -0,0 +1,73 @@
+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_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCH 2/4] git-p4: cope with labels with empty descriptions
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-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 822e6f1..f7707f2 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1741,9 +1741,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
* Re: [PATCH 2/2] commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
From: Junio C Hamano @ 2012-01-16 23:21 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Jonathan Nieder
In-Reply-To: <1326681407-6344-3-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Normally cache-tree will not produce trees from an index that has
> CE_INTENT_TO_ADD entries. This is a safe measure to avoid
> mis-interpreting user's intention regarding this flag.
s/safe/safety/;
> There are situations however where users want to create trees/commits
> regardless i-t-a entries.
A new command line option "--no-check-intent-to-add" to "commit" without
any configuration bit may be a useful addition as a first cut, and in
order to help users to which "there are situations" is more than 50% of
the time, a configuration that can be overriden by "--check-intent-to-add"
may be a usability improvement over that first cut, but if this is really
about "there are situations", then a configuration that cannot be
overriden by command line option feels a wrong way to go about it.
Is this really about "there are situations" to begin with? I am suspecting
that this patch is either:
(1) making it easier to use a wrong workflow, by promoting a way to
bypass a useful safety measure;
(2) fixing an earlier UI mistake (iow, the interpretation #2 in the old
discussion is always the right one and the existing safety measure is
misguided) in such a way that allows you to work around an objection
from a bonehead maintainer who refuses to admit that earlier mistake;
and/or
(3) splitting the Git userbase into two and making the resulting system
harder to teach.
If it is (2), and I suspect it may be the case, we might want to rather
honestly describe that the future direction is to fix it, and describe the
configuration option as "an early opt-in" switch, together with the usual
three-step deprecation and migration schedule to make the new behaviour
the default in a future version. From the timeline point of view, it
probably can coincide with the change to always start an editor when
recording a merge commit.
In any case, for this change to help people who add more than one paths
with "add -N" and want to include only a subset of them in the commit, we
may want to explicitly teach them to add what they want to before
committing with the new command line option in the documentation.
^ permalink raw reply
* Re: Re* Regulator updates for 3.3
From: Junio C Hamano @ 2012-01-16 23:33 UTC (permalink / raw)
To: Pete Harlan
Cc: Linus Torvalds, Mark Brown, Liam Girdwood, linux-kernel,
Git Mailing List
In-Reply-To: <4F136BE4.4040502@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> On 01/10/2012 10:59 PM, Junio C Hamano wrote:
>> There may be existing scripts that leave the standard input and the
>> standard output of the "git merge" connected to whatever environment the
>> scripts were started, and such invocation might trigger the above
>> "interactive session" heuristics. Such scripts can export GIT_MERGE_LEGACY
>> environment variable set to "yes" to force the traditional behaviour.
>
> The name GIT_MERGE_LEGACY gives no clue about what flavor of legacy
> merge behavior is being enabled. Something like GIT_MERGE_LEGACY_EDIT
> might be clearer, or perhaps just have GIT_MERGE_EDIT=0 to get the old
> behavior without reference to whether or not that behavior is
> considered legacy.
Hrm.
The only case your suggestion may make a difference would be when we find
another earlier UI mistake we would want to correct in a backward
incompatible way that affects _existing_ scripts.
With your suggestion, they need to export "GIT_MERGE_EDIT=0" today, and
they will need to update again to export "GIT_MERGE_SOMETHINGELSE=0" when
such an incompatible change comes.
With a single "GIT_MERGE_LEGACY=YesPlease", they can be future-proofed today
and will not be affected when we make another incompatible change.
So I am not sure why separating the big-red-switch into smaller pieces
would be an improvement, especially wnen the scripts that want to specify
finer-grained control of features can use "--[no-]edit" options to
explicitly ask for it.
^ permalink raw reply
* Re: [PATCH 2/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-16 23:41 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20120116185738.GA21996@padd.com>
On Mon, Jan 16, 2012 at 6:57 PM, Pete Wyckoff <pw@padd.com> wrote:
> This looks much better without the need for "--force". It'll be
> great to fix this major branch detection problem. Can you make a
> couple of further minor changes?
Of course I can :)
>> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
>> @@ -2012,7 +2014,28 @@ class P4Sync(Command, P4UserMap):
>> - self.commit(description, filesForCommit, branch, [branchPrefix], parent)
>> + parentFound = 0
>> + if len(parent) > 0:
>> + self.checkpoint()
>> + for blob in read_pipe_lines("git rev-list --reverse --no-merges %s" % parent):
>> + blob = blob.strip()
>> + tempBranch = self.tempBranchLocation + os.sep + "%d-%s" % (change, blob)
>> + if self.verbose:
>> + print "Creating temporary branch: " + tempBranch
>> + self.commit(description, filesForCommit, tempBranch, [branchPrefix], blob)
>> + self.tempBranches.append(tempBranch)
>> + self.checkpoint()
>> + if len( read_pipe("git diff-tree %s %s" % (blob, tempBranch)) ) == 0:
>> + parentFound = 1
>> + if self.verbose:
>> + print "Found parent of %s in commit %s" % (branch, blob)
>> + break
>> + if parentFound:
>> + self.commit(description, filesForCommit, branch, [branchPrefix], blob)
>> + else:
>> + if self.verbose:
>> + print "Parent of %s not found. Committing into head of %s" % (branch, parent)
>> + self.commit(description, filesForCommit, branch, [branchPrefix], parent)
>
> 1. Move the tempBranch commit outside of the "for blob" loop.
> It can have no parent, and the diff-tree will still tell you
> if you found the same contents. Instead of a ref for
> each blob inspected for each change, you'll just have one ref
> per change. Only one checkpoint() after the tempBranch
> commit should be needed.
You're right. Completely oversaw that. Will improve the code
accordingly.
> 2. Nit. parentFound is boolean, use True/False, not 1/0.
That was not a nice thing to do... thanks for noticing :)
>> @@ -2347,6 +2370,12 @@ class P4Sync(Command, P4UserMap):
>> + # Cleanup temporary branches created during import
>> + if self.tempBranches != []:
>> + for branch in self.tempBranches:
>> + os.remove(".git" + os.sep + branch)
>> + os.rmdir(".git" + os.sep + self.tempBranchLocation)
>> +
>
> 3. Deleting refs should probably use "git update-ref -d"
> just in case GIT_DIR is not ".git". I think you could just
> leave the "git-p4-tmp" directory around, but use
> os.environ["GIT_DIR"] instead of ".git" if you want to
> delete it.
Will use os.environ.get, which can be configured to return ".git" if
$GIT_DIR is not defined. Is this ok?
> 4. Paths are best manipulated with os.path.join(dir, file), to handle
> weirdnesses like drive letters.
Perfect. I was completely unaware of that method. Thanks for the tip.
> Eventually if the fast-import protocol learns to delete the refs
> it creates, we can clean up a bit more nicely. I think there was
> agreement this was a good idea, just needs someone to do it
> sometime.
One can always hope ;)
Thanks,
Vitor
^ permalink raw reply
* Re: Re* Regulator updates for 3.3
From: Martin Fick @ 2012-01-16 23:43 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pete Harlan, Linus Torvalds, Mark Brown, Liam Girdwood,
linux-kernel, Git Mailing List
In-Reply-To: <7v62gbussz.fsf@alter.siamese.dyndns.org>
On Monday, January 16, 2012 04:33:00 pm Junio C Hamano
wrote:
> With your suggestion, they need to export
> "GIT_MERGE_EDIT=0" today, and they will need to update
> again to export "GIT_MERGE_SOMETHINGELSE=0" when such an
> incompatible change comes.
>
> With a single "GIT_MERGE_LEGACY=YesPlease", they can be
> future-proofed today and will not be affected when we
> make another incompatible change.
>
> So I am not sure why separating the big-red-switch into
> smaller pieces would be an improvement, especially wnen
> the scripts that want to specify finer-grained control
> of features can use "--[no-]edit" options to explicitly
> ask for it.
Then, what would I do if I write a script which uses the new
edit functionality (without even being aware that there was
an old way) and you introduce a new incompatibility? I
can't turn on GIT_MERGE_LEGACY then since it would revert to
behavior which my script would not expect (since it was
written after the current incompatibility, but before the
new one)!
-Martin
^ permalink raw reply
* Re: [PATCH 2/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-17 0:10 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <CAOpHH-UkyK-c_AHUOPbQQmW9cQQypDvirMR0Jb7vTGSQF7RZpw@mail.gmail.com>
On Mon, Jan 16, 2012 at 11:41 PM, Vitor Antunes <vitor.hda@gmail.com> wrote:
> On Mon, Jan 16, 2012 at 6:57 PM, Pete Wyckoff <pw@padd.com> wrote:
>> 1. Move the tempBranch commit outside of the "for blob" loop.
>> It can have no parent, and the diff-tree will still tell you
>> if you found the same contents. Instead of a ref for
>> each blob inspected for each change, you'll just have one ref
>> per change. Only one checkpoint() after the tempBranch
>> commit should be needed.
>
> You're right. Completely oversaw that. Will improve the code
> accordingly.
Apparently I did not oversee it. Assume you have added a new file to
HEAD of parent branch, but you branched from a previous commit. When the
new branch is committed over HEAD the new file will, incorrectly, be
part of it and diff-tree will not work as expected.
I should avoid taking 6 months to submit a patch to avoid forgetting why
I did what I did :)
Vitor
^ permalink raw reply
* Re: Commit changes to remote repository
From: Junio C Hamano @ 2012-01-17 0:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Carlos Martín Nieto, ruperty, git
In-Reply-To: <vpqboq6fjfy.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
>> You're trying to push to a non-bare repository and change the
>> currently active branch, which can cause problems, so git isn't
>> letting you. There's an explanation of bare and non-bare at
>> http://bare-vs-nonbare.gitrecipes.de/ but the short and sweet is that
>> you should init the repo you want to use as the central point with
>> --bare and do modifications locally and then push there.
>
> An alternative is to push to a temporary, non-checked-out branch.
Or more generally, treat such a push as if you are pulling in the opposite
direction. So in this example,
> I sometimes do
>
> laptop$ git push desktop HEAD:incomming
>
> and then
>
> desktop$ git merge incomming
you pretend as if you are running "git pull" on your desktop in order to
integrate the work done on your laptop. If you did
desktop$ git pull laptop
you would store where the branches on the laptop are in the remote
tracking branches for "laptop" remote in your desktop's repository.
So a good way to simulate that would be:
laptop$ git push desktop master:refs/remotes/laptop/master
and then run:
desktop$ git merge laptop/master
> The push does not disturb the worktree on the desktop, and the merge is
> done manually on the receiving machine.
^ permalink raw reply
* Re: [PATCH 2/2] commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
From: Nguyen Thai Ngoc Duy @ 2012-01-17 1:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
In-Reply-To: <7vaa5nutbp.fsf@alter.siamese.dyndns.org>
2012/1/17 Junio C Hamano <gitster@pobox.com>:
> A new command line option "--no-check-intent-to-add" to "commit" without
> any configuration bit may be a useful addition as a first cut, and in
> order to help users to which "there are situations" is more than 50% of
> the time, a configuration that can be overriden by "--check-intent-to-add"
> may be a usability improvement over that first cut, but if this is really
> about "there are situations", then a configuration that cannot be
> overriden by command line option feels a wrong way to go about it.
"git -c key=value commit" may help.
> Is this really about "there are situations" to begin with? I am suspecting
> that this patch is either:
>
> (1) making it easier to use a wrong workflow, by promoting a way to
> bypass a useful safety measure;
>
> (2) fixing an earlier UI mistake (iow, the interpretation #2 in the old
> discussion is always the right one and the existing safety measure is
> misguided) in such a way that allows you to work around an objection
> from a bonehead maintainer who refuses to admit that earlier mistake;
> and/or
>
> (3) splitting the Git userbase into two and making the resulting system
> harder to teach.
This patch is towards (3). I agree that "add -N" can be confusing to
new users because it does not actually add anything. Those who do not
read manual carefully and commit without checking the result may fall
into that trap. So a user is expected to "level up" a bit and
hopefully by the time he/she feels the need to get around the safety
check and discover this flag, they should be ready to go without the
safety check.
Although I would not oppose deprecating the old behavior if you go with (2) ;)
> In any case, for this change to help people who add more than one paths
> with "add -N" and want to include only a subset of them in the commit, we
> may want to explicitly teach them to add what they want to before
> committing with the new command line option in the documentation.
yeah, keep telling people "this does not add any thing, you need to
git-add again without -N" after running "add -N" using advice
framework when this config is on?
--
Duy
^ permalink raw reply
* Re: git grep doesn't follow symbolic link
From: Nguyen Thai Ngoc Duy @ 2012-01-17 1:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pang Yan Han, Thomas Rast, Ramkumar Ramachandra, Bertrand BENOIT,
git
In-Reply-To: <7vwr8ruv1j.fsf@alter.siamese.dyndns.org>
On Tue, Jan 17, 2012 at 5:44 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>> It's not wrong per se. It's an implication that users have to take
>> when they choose to use it. We may help make it clear that the
>> symlinks point to untracked files by putting some indication in the
>> diff.
>>
>> When I do "git log -Sfoo -- '*.cxx'" I don't really care if bar.cxx is
>> a symlink. Neither does my compiler. It may be a symlink's target
>> change that makes "foo" appear. Git could help me detect that quickly
>> instead of sticking with tracked contents only.
>
> As there is nothing in Git that tells that whatever is pointed at by
> bar.cxx that happens to be in your filesystem today had "foo" in it when
> that historical version of the commit whose bar.cxx symlink was updated to
> point to that file. It is *WRONG* to show the commit as something that
> changes bar.cxx to contain "foo" (or more precisely, changes the count of
> "foo" in it).
>
> Why is it so hard to understand?
OK resolving links to untracked contents is bad and should only be
supported in --no-index case, resolving links to tracked contents
should be ok in principal? (I'm not sure how messed up diff code could
be with these changes)
--
Duy
^ permalink raw reply
* Re: [PATCH 2/2] commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
From: Jonathan Nieder @ 2012-01-17 2:47 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git
In-Reply-To: <CACsJy8B_qGphVz8PFhPNLsOe-Ve7xb+biNP8Ok7dXiygu3KoSg@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> Although I would not oppose deprecating the old behavior if you go with (2) ;)
My reaction on reading the patch and clarifying followup was similar
to Junio's. I don't think a configuration item makes sense unless we
are planning to flip the default in the future, and it would probably
be clearer to document it that way.
By the way, thanks very much for working on this. I wish I had more
time to offer more than comments.
Sincerely,
Jonathan
^ permalink raw reply
* What's cooking in git.git (Jan 2012, #04; Mon, 16)
From: Junio C Hamano @ 2012-01-17 3:27 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* mh/maint-show-ref-doc (2012-01-13) 2 commits
(merged to 'next' on 2012-01-16 at 8573f09)
+ git-show-ref doc: typeset regexp in fixed width font
+ git-show-ref: fix escaping in asciidoc source
Will merge to 'master' by v1.7.9-rc2.
* nd/pathspec-recursion-cleanup (2012-01-16) 2 commits
(merged to 'next' on 2012-01-16 at 0189264)
+ diff-index: enable recursive pathspec matching in unpack_trees
+ Document limited recursion pathspec matching with wildcards
Will merge to 'master' by v1.7.9-rc2.
* tr/maint-word-diff-incomplete-line (2012-01-12) 1 commit
(merged to 'next' on 2012-01-16 at 58ddaaf)
+ word-diff: ignore '\ No newline at eof' marker
Will merge to 'master' by v1.7.9-rc2.
--------------------------------------------------
[Graduated to "master"]
* jc/request-pull-show-head-4 (2012-01-10) 1 commit
(merged to 'next' on 2012-01-11 at 8d98a6b)
+ request-pull: use the real fork point when preparing the message
Hopefully the final finishing touch to the request-pull script that was
updated during this cycle.
* jk/maint-upload-archive (2012-01-11) 1 commit
(merged to 'next' on 2012-01-11 at 5c0bfa9)
+ archive: re-allow HEAD:Documentation on a remote invocation
Running "git archive" remotely and asking for a partial tree of a ref,
e.g. HEAD:$path was forbidden by a recent change to tighten security, but
was found to be overly restrictive.
* jn/maint-gitweb-grep-fix (2012-01-05) 2 commits
(merged to 'next' on 2012-01-13 at a15e6ab)
+ gitweb: Harden "grep" search against filenames with ':'
+ gitweb: Fix file links in "grep" search
* ss/maint-msys-cvsexportcommit (2012-01-11) 2 commits
(merged to 'next' on 2012-01-11 at 007aab1)
+ git-cvsexportcommit: Fix calling Perl's rel2abs() on MSYS
+ t9200: On MSYS, do not pass Windows-style paths to CVS
--------------------------------------------------
[Stalled]
* jc/advise-push-default (2011-12-18) 1 commit
- push: hint to use push.default=upstream when appropriate
Peff had a good suggestion outlining an updated code structure so that
somebody new can try to dip his or her toes in the development. Any
takers?
Waiting for a reroll.
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
Not ready.
At least pack-objects and fsck need to learn the new encoding for the
series to be usable locally, and then index-pack/unpack-objects needs to
learn it to be used remotely.
--------------------------------------------------
[Cooking]
* jc/pull-signed-tag (2012-01-11) 1 commit
- merge: use editor by default in interactive sessions
Per Linus's strong suggestion, sugarcoated (aka "taking blame for the
original UI screw-ups") so that it is easier for me to swallow and accept
a potentially huge backward incompatibility issue, "git merge" is made to
launch an editor to explain the merge in the merge commit by default in
interactive sessions.
May need renaming the backward compatibility "GIT_MERGE_LEGACY"
environment variable, and also will need a smoother migration plan.
Will defer till the next cycle.
* nd/commit-ignore-i-t-a (2012-01-16) 2 commits
- commit, write-tree: allow to ignore CE_INTENT_TO_ADD while writing trees
- cache-tree: update API to take abitrary flags
May want to consider this as fixing an earlier UI mistake, and not as a
feature that devides the userbase.
Will defer till the next cycle.
* nd/maint-refname-in-hierarchy-check (2012-01-11) 1 commit
- Fix incorrect ref namespace check
Avoid getting confused by "ref/headxxx" and mistaking it as if it is under
the "refs/heads/" hierarchy.
Not urgent.
* jc/advise-i18n (2011-12-22) 1 commit
- i18n of multi-line advice messages
Allow localization of advice messages that tend to be longer and
multi-line formatted. For now this is deliberately limited to advise()
interface and not vreportf() in general as touching the latter has
interactions with error() that has plumbing callers whose prefix "error: "
should never be translated.
Not urgent.
* rr/sequencer (2012-01-11) 2 commits
- sequencer: factor code out of revert builtin
- revert: prepare to move replay_action to header
Moving large chunk of code out of cherry-pick/revert for later reuse,
primarily to prepare for the next cycle.
Not urgent.
* tr/maint-mailinfo (2012-01-16) 2 commits
- mailinfo: with -b, keep space after [foo]
- am: learn passing -b to mailinfo
Looked reasonable.
Not urgent.
* jk/credentials (2012-01-11) 3 commits
(merged to 'next' on 2012-01-16 at 1c6c94a)
+ unix-socket: do not let close() or chdir() clobber errno during cleanup
+ credential-cache: report more daemon connection errors
+ unix-socket: handle long socket pathnames
Minor fix-ups to the new feature.
Will merge to 'master' by v1.7.9-rc2.
* pw/p4-view-updates (2012-01-11) 5 commits
- git-p4: add tests demonstrating spec overlay ambiguities
- git-p4: adjust test to adhere to stricter useClientSpec
- git-p4: clarify comment
- git-p4: fix verbose comment typo
- git-p4: only a single ... wildcard is supported
* rs/diff-postimage-in-context (2012-01-06) 1 commit
(merged to 'next' on 2012-01-09 at 9635032)
+ xdiff: print post-image for common records instead of pre-image
Looked reasonable.
Not urgent.
* cb/push-quiet (2012-01-08) 3 commits
- t5541: avoid TAP test miscounting
- fix push --quiet: add 'quiet' capability to receive-pack
- server_supports(): parse feature list more carefully
Looked reasonable.
Not urgent.
* nd/clone-detached (2012-01-16) 10 commits
- clone: print advice on checking out detached HEAD
- clone: allow --branch to take a tag
- clone: refuse to clone if --branch points to bogus ref
- clone: --branch=<branch> always means refs/heads/<branch>
- clone: delay cloning until after remote HEAD checking
- clone: factor out remote ref writing
- clone: factor out HEAD update code
- clone: factor out checkout code
- clone: write detached HEAD in bare repositories
- t5601: add missing && cascade
(this branch uses nd/clone-single-branch.)
Looking good.
Not urgent.
* nd/clone-single-branch (2012-01-08) 1 commit
(merged to 'next' on 2012-01-09 at 6c3c759)
+ clone: add --single-branch to fetch only one branch
(this branch is used by nd/clone-detached.)
Looked reasonable.
Not urgent.
* jn/gitweb-unspecified-action (2012-01-09) 1 commit
- gitweb: Fix actionless dispatch for non-existent objects
Looked reasonable.
Not urgent.
* nd/index-pack-no-recurse (2012-01-16) 3 commits
- index-pack: eliminate unlimited recursion in get_base_data()
- index-pack: eliminate recursion in find_unresolved_deltas
- Eliminate recursion in setting/clearing marks in commit list
Much better explained than the previous round.
Will defer till the next cycle.
* mh/ref-api-rest (2011-12-12) 35 commits
- repack_without_ref(): call clear_packed_ref_cache()
- read_packed_refs(): keep track of the directory being worked in
- is_refname_available(): query only possibly-conflicting references
- refs: read loose references lazily
- read_loose_refs(): take a (ref_entry *) as argument
- struct ref_dir: store a reference to the enclosing ref_cache
- sort_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- do_for_each_ref_in_dir*(): take (ref_entry *) instead of (ref_dir *)
- add_entry(): take (ref_entry *) instead of (ref_dir *)
- search_ref_dir(): take (ref_entry *) instead of (ref_dir *)
- find_containing_direntry(): use (ref_entry *) instead of (ref_dir *)
- add_ref(): take (ref_entry *) instead of (ref_dir *)
- read_packed_refs(): take (ref_entry *) instead of (ref_dir *)
- find_ref(): take (ref_entry *) instead of (ref_dir *)
- is_refname_available(): take (ref_entry *) instead of (ref_dir *)
- get_loose_refs(): return (ref_entry *) instead of (ref_dir *)
- get_packed_refs(): return (ref_entry *) instead of (ref_dir *)
- refs: wrap top-level ref_dirs in ref_entries
- get_ref_dir(): keep track of the current ref_dir
- do_for_each_ref(): only iterate over the subtree that was requested
- refs: sort ref_dirs lazily
- sort_ref_dir(): do not sort if already sorted
- refs: store references hierarchically
- refs.c: rename ref_array -> ref_dir
- struct ref_entry: nest the value part in a union
- check_refname_component(): return 0 for zero-length components
- free_ref_entry(): new function
- refs.c: reorder definitions more logically
- is_refname_available(): reimplement using do_for_each_ref_in_array()
- names_conflict(): simplify implementation
- names_conflict(): new function, extracted from is_refname_available()
- repack_without_ref(): reimplement using do_for_each_ref_in_array()
- do_for_each_ref_in_arrays(): new function
- do_for_each_ref_in_array(): new function
- do_for_each_ref(): correctly terminate while processesing extra_refs
The API for extra anchoring points may require rethought first; that would
hopefully make the "ref" part a lot simpler. And that is happening in
another topic (which has graduated to 'master').
Will defer till the next cycle.
* ss/git-svn-prompt-sans-terminal (2012-01-04) 3 commits
- fixup! 15eaaf4
- git-svn, perl/Git.pm: extend Git::prompt helper for querying users
(merged to 'next' on 2012-01-05 at 954f125)
+ perl/Git.pm: "prompt" helper to honor GIT_ASKPASS and SSH_ASKPASS
The bottom one has been replaced with a rewrite based on comments from
Ævar. The second one needs more work, both in perl/Git.pm and prompt.c, to
give precedence to tty over SSH_ASKPASS when terminal is available.
Will defer till the next cycle.
* cb/git-daemon-tests (2012-01-08) 5 commits
(merged to 'next' on 2012-01-08 at 1db8351)
+ git-daemon tests: wait until daemon is ready
+ git-daemon: produce output when ready
+ git-daemon: add tests
+ dashed externals: kill children on exit
+ run-command: optionally kill children on exit
Will defer till the next cycle.
* jk/parse-object-cached (2012-01-06) 3 commits
(merged to 'next' on 2012-01-08 at 8c6fa4a)
+ upload-pack: avoid parsing tag destinations
+ upload-pack: avoid parsing objects during ref advertisement
+ parse_object: try internal cache before reading object db
These are a bit scary changes, but I do think they are worth doing.
Will defer till the next cycle.
^ permalink raw reply
* Re: Signed tags in octopus merge..
From: Junio C Hamano @ 2012-01-17 3:31 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jacob Helwig, Git Mailing List
In-Reply-To: <CA+55aFzZXSCt1AwOotMZJ+GcNcJKL2OcsPOtaZ3=cvraJ=PD+Q@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Mon, Jan 16, 2012 at 2:58 PM, Jacob Helwig <jacob@technosorcery.net> wrote:
>>
>> My immediate thought regarding the "side branch #1" version is not
>> wanting to have to do the math (even though it's a simple n+1)
>
> "Math is hard, let's go shopping".
>
> But I think even barbie could do the "add one" thing. That said, I
> think the current thing is already more than good enough, and I don't
> think it's at all confusing to talk about "parent #2". In fact, I
> think it's more obvious than "side branch #1".
I think Jacob is correct to point out that mice are even dumber than
Barbie and cannot do the "add one" thing, so let's leave the output as is.
Thanks for an amusing response.
^ permalink raw reply
* Re: Re* Regulator updates for 3.3
From: Pete Harlan @ 2012-01-17 5:33 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Mark Brown, Liam Girdwood, linux-kernel,
Git Mailing List
In-Reply-To: <7v62gbussz.fsf@alter.siamese.dyndns.org>
On 01/16/2012 03:33 PM, Junio C Hamano wrote:
> Pete Harlan <pgit@pcharlan.com> writes:
>
>> On 01/10/2012 10:59 PM, Junio C Hamano wrote:
>>> There may be existing scripts that leave the standard input and the
>>> standard output of the "git merge" connected to whatever environment the
>>> scripts were started, and such invocation might trigger the above
>>> "interactive session" heuristics. Such scripts can export GIT_MERGE_LEGACY
>>> environment variable set to "yes" to force the traditional behaviour.
>>
>> The name GIT_MERGE_LEGACY gives no clue about what flavor of legacy
>> merge behavior is being enabled. Something like GIT_MERGE_LEGACY_EDIT
>> might be clearer, or perhaps just have GIT_MERGE_EDIT=0 to get the old
>> behavior without reference to whether or not that behavior is
>> considered legacy.
>
> Hrm.
>
> The only case your suggestion may make a difference would be when we find
> another earlier UI mistake we would want to correct in a backward
> incompatible way that affects _existing_ scripts.
>
> With your suggestion, they need to export "GIT_MERGE_EDIT=0" today, and
> they will need to update again to export "GIT_MERGE_SOMETHINGELSE=0" when
> such an incompatible change comes.
Which is a good thing, because maybe they started using Git after the
current proposed change (which they like), and what you see as new
becomes their "legacy" behavior. If you change something after that,
you can't use GIT_MERGE_LEGACY=yes for that one also because which
legacy is it preserving?
In general, naming configuration variables "DO_IT_<THIS_WAY>" instead
of "DO_IT_THE_OLD_WAY" is better because it's self-documenting. The
only time I think I'd prefer "LEGACY" is if you're planning on
deprecating and removing it eventually and you want to indicate
something to that effect in the name.
--
Pete Harlan
pgit@pcharlan.com
^ permalink raw reply
* [PATCH 0/4] Remove a user of extra_refs in clone
From: mhagger @ 2012-01-17 5:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
From: Michael Haggerty <mhagger@alum.mit.edu>
When cloning, write_remote_refs() creates local packed refs from the
refs read from the remote repository. It does this by creating extra
refs for the references then calling pack_refs() to bake the extra
refs into the packed-refs file, then calling clear_extra_refs().
This is silly and relies on the kludgy extra_refs mechanism, which I
want to get rid of. Instead, add a function call add_packed_ref() to
the refs API, and use it to create packed refs (in the memory cache)
directly. Then call pack_refs() as before to write the packed-refs
file.
Because the new add_packed_ref() function allows references (perhaps
many of them) to be added to an existing ref_array, it would be
inefficient to re-sort the list after every addition. So instead,
append new entries to the end of the ref_array and note that the array
is unsorted. Then, before the ref_array is used, check if it is
unsorted and sort it if necessary.
A side effect of this change is that the new packed references are
left in the in-memory packed reference cache after the return from
write_remote_refs() (whereas previously, the refs were stored as
temporary extra refs that were purged before return from the
function). I can't see any place in the following code where this
would make a difference, but there is quite a bit of code there so it
is hard to audit. Confirmation that this is OK would be welcome.
Michael Haggerty (4):
pack_refs(): remove redundant check
ref_array: keep track of whether references are sorted
add_packed_ref(): new function in the refs API.
write_remote_refs(): create packed (rather than extra) refs
builtin/clone.c | 3 +--
pack-refs.c | 3 +--
refs.c | 39 ++++++++++++++++++++++++++++++++-------
refs.h | 6 ++++++
4 files changed, 40 insertions(+), 11 deletions(-)
--
1.7.8.3
^ permalink raw reply
* [PATCH 2/4] ref_array: keep track of whether references are sorted
From: mhagger @ 2012-01-17 5:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1326779434-20106-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Keep track of how many entries in a ref_array are already sorted. In
sort_ref_array(), only call qsort() if the dir contains unsorted
entries (i.e., if references have been appended to the end of the list
since the last call to sort_ref_array()).
Sort ref_arrays only when needed, namely in search_ref_array() and in
do_for_each_ref(). However, never sort the extra_refs, because
extra_refs can contain multiple entries with the same name.
This change is currently not useful, because entries are not added to
ref_arrays after they are created. But in a moment they will be...
Implementation note: we could store a binary "sorted" value instead of
an integer, but storing the number of sorted entries leaves the way
open for a couple of possible future optimizations:
* In sort_ref_array(), sort *only* the unsorted entries, then merge
them with the sorted entries. This should be faster if most of the
entries are already sorted.
* Teach search_ref_array() to do a binary search of any sorted
entries, and if unsuccessful do a linear search of any unsorted
entries. This would avoid the need to sort the list every time that
search_ref_array() is called, and (given some intelligence about how
often to sort) could significantly improve the speed in certain
hypothetical usage patterns.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
refs.c | 33 ++++++++++++++++++++++++++-------
1 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/refs.c b/refs.c
index 6f436f1..268816f 100644
--- a/refs.c
+++ b/refs.c
@@ -17,6 +17,15 @@ struct ref_entry {
struct ref_array {
int nr, alloc;
+
+ /*
+ * Entries with index 0 <= i < sorted are sorted by name. New
+ * entries are appended to the list unsorted, and are sorted
+ * only when required; thus we avoid the need to sort the list
+ * after the addition of every reference.
+ */
+ int sorted;
+
struct ref_entry **refs;
};
@@ -105,12 +114,18 @@ static int is_dup_ref(const struct ref_entry *ref1, const struct ref_entry *ref2
}
}
+/*
+ * Sort the entries in array (if they are not already sorted).
+ */
static void sort_ref_array(struct ref_array *array)
{
int i, j;
- /* Nothing to sort unless there are at least two entries */
- if (array->nr < 2)
+ /*
+ * This check also prevents passing a zero-length array to qsort(),
+ * which is a problem on some platforms.
+ */
+ if (array->sorted == array->nr)
return;
qsort(array->refs, array->nr, sizeof(*array->refs), ref_entry_cmp);
@@ -124,7 +139,7 @@ static void sort_ref_array(struct ref_array *array)
}
array->refs[++i] = array->refs[j];
}
- array->nr = i + 1;
+ array->sorted = array->nr = i + 1;
}
static struct ref_entry *search_ref_array(struct ref_array *array, const char *refname)
@@ -137,7 +152,7 @@ static struct ref_entry *search_ref_array(struct ref_array *array, const char *r
if (!array->nr)
return NULL;
-
+ sort_ref_array(array);
len = strlen(refname) + 1;
e = xmalloc(sizeof(struct ref_entry) + len);
memcpy(e->name, refname, len);
@@ -168,6 +183,10 @@ static struct ref_cache {
static struct ref_entry *current_ref;
+/*
+ * The extra_refs is never sorted, because it is allowed to contain entries
+ * with duplicate names.
+ */
static struct ref_array extra_refs;
static void clear_ref_array(struct ref_array *array)
@@ -176,7 +195,7 @@ static void clear_ref_array(struct ref_array *array)
for (i = 0; i < array->nr; i++)
free(array->refs[i]);
free(array->refs);
- array->nr = array->alloc = 0;
+ array->sorted = array->nr = array->alloc = 0;
array->refs = NULL;
}
@@ -268,7 +287,6 @@ static void read_packed_refs(FILE *f, struct ref_array *array)
!get_sha1_hex(refline + 1, sha1))
hashcpy(last->peeled, sha1);
}
- sort_ref_array(array);
}
void add_extra_ref(const char *refname, const unsigned char *sha1, int flag)
@@ -404,7 +422,6 @@ static struct ref_array *get_loose_refs(struct ref_cache *refs)
{
if (!refs->did_loose) {
get_ref_dir(refs, "refs", &refs->loose);
- sort_ref_array(&refs->loose);
refs->did_loose = 1;
}
return &refs->loose;
@@ -720,6 +737,8 @@ static int do_for_each_ref(const char *submodule, const char *base, each_ref_fn
for (i = 0; i < extra->nr; i++)
retval = do_one_ref(base, fn, trim, flags, cb_data, extra->refs[i]);
+ sort_ref_array(packed);
+ sort_ref_array(loose);
while (p < packed->nr && l < loose->nr) {
struct ref_entry *entry;
int cmp = strcmp(packed->refs[p]->name, loose->refs[l]->name);
--
1.7.8.3
^ permalink raw reply related
* [PATCH 3/4] add_packed_ref(): new function in the refs API.
From: mhagger @ 2012-01-17 5:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1326779434-20106-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
Add a new function add_packed_ref() that adds a reference directly to
the in-memory packed reference cache. This will be useful for
creating local references while cloning.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
This new function call only stores the new reference to the in-memory
cache. The user has to remember to call pack_refs() to actually write
the new reference(s) to the packed-refs file. (I don't think it is
practical to make the write happen automatically.)
refs.c | 6 ++++++
refs.h | 6 ++++++
2 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/refs.c b/refs.c
index 268816f..14f764d 100644
--- a/refs.c
+++ b/refs.c
@@ -319,6 +319,12 @@ static struct ref_array *get_packed_refs(struct ref_cache *refs)
return &refs->packed;
}
+void add_packed_ref(const char *refname, const unsigned char *sha1)
+{
+ add_ref(get_packed_refs(get_ref_cache(NULL)),
+ create_ref_entry(refname, sha1, REF_ISPACKED, 1));
+}
+
static void get_ref_dir(struct ref_cache *refs, const char *base,
struct ref_array *array)
{
diff --git a/refs.h b/refs.h
index d498291..00ba1e2 100644
--- a/refs.h
+++ b/refs.h
@@ -51,6 +51,12 @@ extern int for_each_rawref(each_ref_fn, void *);
extern void warn_dangling_symref(FILE *fp, const char *msg_fmt, const char *refname);
/*
+ * Add a reference to the in-memory packed reference cache. To actually
+ * write the reference to the packed-refs file, call pack_refs().
+ */
+extern void add_packed_ref(const char *refname, const unsigned char *sha1);
+
+/*
* Extra refs will be listed by for_each_ref() before any actual refs
* for the duration of this process or until clear_extra_refs() is
* called. Only extra refs added before for_each_ref() is called will
--
1.7.8.3
^ permalink raw reply related
* [PATCH 4/4] write_remote_refs(): create packed (rather than extra) refs
From: mhagger @ 2012-01-17 5:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1326779434-20106-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
write_remote_refs() creates new packed refs from references obtained
from the remote repository, which is "out of thin air" as far as the
local repository is concerned. Previously it did this by creating
"extra" refs, then calling pack_refs() to bake them into the
packed-refs file. Instead, create packed refs (in the packed
reference cache) directly, then call pack_refs().
Aside from being more logical, this is another step towards removing
extra refs entirely.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
builtin/clone.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index 86db954..9413537 100644
--- a/builtin/clone.c
+++ b/builtin/clone.c
@@ -441,11 +441,10 @@ static void write_remote_refs(const struct ref *local_refs)
for (r = local_refs; r; r = r->next) {
if (!r->peer_ref)
continue;
- add_extra_ref(r->peer_ref->name, r->old_sha1, 0);
+ add_packed_ref(r->peer_ref->name, r->old_sha1);
}
pack_refs(PACK_REFS_ALL);
- clear_extra_refs();
}
static int write_one_config(const char *key, const char *value, void *data)
--
1.7.8.3
^ permalink raw reply related
* [PATCH 1/4] pack_refs(): remove redundant check
From: mhagger @ 2012-01-17 5:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland,
Michael Haggerty
In-Reply-To: <1326779434-20106-1-git-send-email-mhagger@alum.mit.edu>
From: Michael Haggerty <mhagger@alum.mit.edu>
handle_one_ref() only adds refs to the cbdata.ref_to_prune list if
(cbdata.flags & PACK_REFS_PRUNE) is set. So any references in this
list at the end of pack_refs() can be pruned unconditionally.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Trivial simplification, not essential to the rest of this patch
series.
pack-refs.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/pack-refs.c b/pack-refs.c
index 23bbd00..f09a054 100644
--- a/pack-refs.c
+++ b/pack-refs.c
@@ -143,7 +143,6 @@ int pack_refs(unsigned int flags)
packed.fd = -1;
if (commit_lock_file(&packed) < 0)
die_errno("unable to overwrite old ref-pack file");
- if (cbdata.flags & PACK_REFS_PRUNE)
- prune_refs(cbdata.ref_to_prune);
+ prune_refs(cbdata.ref_to_prune);
return 0;
}
--
1.7.8.3
^ permalink raw reply related
* Re: [PATCHv3 10/13] credentials: add "cache" helper
From: Jeff King @ 2012-01-17 6:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jonathan Nieder
In-Reply-To: <20120110045733.GA12460@sigill.intra.peff.net>
On Mon, Jan 09, 2012 at 11:57:33PM -0500, Jeff King wrote:
> Subject: [PATCH] credential-cache: report more daemon connection errors
>
> Originally, this code remained relatively silent when we
> failed to connect to the cache. The idea was that it was
> simply a cache, and we didn't want to bother the user with
> temporary failures (the worst case is that we would simply
> ask their password again).
>
> However, if you have a configuration failure or other
> problem, it is helpful for the daemon to report those
> problems. Git will happily ignore the failed error code, but
> the extra information to stderr can help the user diagnose
> the problem.
This actually has a minor regression, fixed below.
-- >8 --
Subject: [PATCH] credential-cache: ignore "connection refused" errors
The credential-cache helper will try to connect to its
daemon over a unix socket. Originally, a failure to do so
was silently ignored, and we would either give up (if
performing a "get" or "erase" operation), or spawn a new
daemon (for a "store" operation).
But since 8ec6c8d, we try to report more errors. We detect a
missing daemon by checking for ENOENT on our connection
attempt. If the daemon is missing, we continue as before
(giving up or spawning a new daemon). For any other error,
we die and report the problem.
However, checking for ENOENT is not sufficient for a missing
daemon. We might also get ECONNREFUSED if a dead daemon
process left a stale socket. This generally shouldn't
happen, as the daemon cleans up after itself, but the daemon
may not always be given a chance to do so (e.g., power loss,
"kill -9").
The resulting state is annoying not just because the helper
outputs an extra useless message, but because it actually
blocks the helper from spawning a new daemon to replace the
stale socket.
Fix it by checking for ECONNREFUSED.
Signed-off-by: Jeff King <peff@peff.net>
---
If we really want to go belt-and-suspenders, the logic should perhaps be
changed to:
if (send_request(socket, &buf < 0) {
/* if we're starting a new one, who cares why it didn't work */
if (flags & FLAG_SPAWN) {
spawn_daemon(socket);
if (send_request(socket, &buf) < 0)
die_errno("unable to connect to spawned daemon");
}
/* otherwise, report any non-minor errors */
else if(errno != ENOENT && errno != ECONNREFUSED)
die_errno("unable to connect to cache daemon");
/* otherwise we are just missing the daemon, and we can ignore */
}
but that implies there is some condition besides ENOENT and ECONNREFUSED
where actually starting a new daemon (which will try to unlink whatever
is there now!) would be a good idea. I'd rather be conservative and
see if anybody reports a real-world case.
credential-cache.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/credential-cache.c b/credential-cache.c
index 1933018..9a03792 100644
--- a/credential-cache.c
+++ b/credential-cache.c
@@ -72,7 +72,7 @@ static void do_cache(const char *socket, const char *action, int timeout,
}
if (send_request(socket, &buf) < 0) {
- if (errno != ENOENT)
+ if (errno != ENOENT && errno != ECONNREFUSED)
die_errno("unable to connect to cache daemon");
if (flags & FLAG_SPAWN) {
spawn_daemon(socket);
--
1.7.9.rc0.33.gd3c17
^ permalink raw reply related
* Re: Re* Regulator updates for 3.3
From: Junio C Hamano @ 2012-01-17 6:13 UTC (permalink / raw)
To: Pete Harlan
Cc: Linus Torvalds, Mark Brown, Liam Girdwood, linux-kernel,
Git Mailing List
In-Reply-To: <4F15080C.6060004@pcharlan.com>
Pete Harlan <pgit@pcharlan.com> writes:
> ... The
> only time I think I'd prefer "LEGACY" is if you're planning on
> deprecating and removing it eventually and you want to indicate
> something to that effect in the name.
The discussion that led to the naming of that LEGACY token needs to be
re-read, then. The kind of "LEGACY" you prefer is exactly why the
environment variable is called LEGACY in the patch you are commenting on,
written in response to Linus's suggestion to switch the default, even
though I am not 100% buying it.
Having said that, I think I am wasting my time responding to this thread
during the feature-freeze period for v1.7.9, as I am not a big fan of
switching the default without adequate warning and transition plans, after
getting burned by the "'git-foo' vs 'git foo'" flames back in the v1.6.0
release. We would likely to take a gradual and smoother migration route to
transition, e.g. v1.7.9 to introduce "merge --edit", v1.7.10 to introduce
a configuration variable merge.edit (lack of which gives a warning and an
advice message while defaulting to 'no' to preserve the traditional
behaviour), and finally v1.8.0 (or v2.0) to flip the default to 'yes'
(while the configuration still giving a warning and an advice message)
that "merge --no-edit" can still countermand.
So you have until v1.7.10 to decide a good name for the overriding
environment variable.
^ permalink raw reply
* Re: [PATCH 0/4] Remove a user of extra_refs in clone
From: Jeff King @ 2012-01-17 6:35 UTC (permalink / raw)
To: mhagger; +Cc: Junio C Hamano, git, Jakub Narebski, Heiko Voigt, Johan Herland
In-Reply-To: <1326779434-20106-1-git-send-email-mhagger@alum.mit.edu>
On Tue, Jan 17, 2012 at 06:50:30AM +0100, mhagger@alum.mit.edu wrote:
> When cloning, write_remote_refs() creates local packed refs from the
> refs read from the remote repository. It does this by creating extra
> refs for the references then calling pack_refs() to bake the extra
> refs into the packed-refs file, then calling clear_extra_refs().
>
> This is silly and relies on the kludgy extra_refs mechanism, which I
> want to get rid of. Instead, add a function call add_packed_ref() to
> the refs API, and use it to create packed refs (in the memory cache)
> directly. Then call pack_refs() as before to write the packed-refs
> file.
I certainly approve of the goal.
> Because the new add_packed_ref() function allows references (perhaps
> many of them) to be added to an existing ref_array, it would be
> inefficient to re-sort the list after every addition. So instead,
> append new entries to the end of the ref_array and note that the array
> is unsorted. Then, before the ref_array is used, check if it is
> unsorted and sort it if necessary.
Makes sense.
> A side effect of this change is that the new packed references are
> left in the in-memory packed reference cache after the return from
> write_remote_refs() (whereas previously, the refs were stored as
> temporary extra refs that were purged before return from the
> function). I can't see any place in the following code where this
> would make a difference, but there is quite a bit of code there so it
> is hard to audit. Confirmation that this is OK would be welcome.
Actually, I think you may be fixing an extremely minor bug with this.
If later code in clone tries to resolve one of the refs in
refs/remotes/<origin>/, the current code will see that it doesn't exist
as a ref file (because we wrote it packed) and call get_packed_ref. That
checks the cached refs list, which will claim that did_packed is true,
but the "packed" array will be empty. Which is wrong; we _do_ have that
ref, and our cache is stale. After writing the packed list, the current
code probably ought to be calling invalidate_ref_cache(). It was only
the fact that most of the remaining code didn't care that this wasn't a
bug in the first place.
Your code makes more sense, in that it will keep the packed_refs list up
to date, and later calls to resolve_ref will properly find those refs.
The only place where I can detect a change in behavior is in the reflog
creation. When we write the refs/remotes/<origin>/HEAD ref, we call
create_symref, which in turn will decide whether to write a reflog entry
or not based on whether the pointed-to ref exists (because if we are
making a symref to something that doesn't exist, we have no sha1 to
write in the reflog entry). So before, we got no reflog for
refs/remotes/<origin>/HEAD (because we erroneously thought that
refs/remotes/origin/master (or whatever) did not exist). With your
patches, the reflog entry is created.
I doubt anyone ever noticed, but now that code is at least working as
intended.
> Michael Haggerty (4):
> pack_refs(): remove redundant check
> ref_array: keep track of whether references are sorted
> add_packed_ref(): new function in the refs API.
> write_remote_refs(): create packed (rather than extra) refs
I won't respond to each patch individually. All of them looked good to
me. Thanks for a very pleasant read.
-Peff
^ permalink raw reply
* Re: git grep doesn't follow symbolic link
From: Junio C Hamano @ 2012-01-17 6:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Pang Yan Han, Thomas Rast, Ramkumar Ramachandra, Bertrand BENOIT,
git
In-Reply-To: <CACsJy8B9AGuRSx_5P22TOsqrA1rTEjQb78NN7PcTuK53iUmP_w@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> OK resolving links to untracked contents is bad and should only be
> supported in --no-index case, resolving links to tracked contents should
> be ok in principal?
Conceptually it is not as bad, but I doubt it is still "ok".
It would defeat one of the fundamental properties of Git (or any content
based revision control scheme for that matter): a tree object records the
hash of its contents, so if two subtrees agree at the content hash level,
you do not have to descend into them to compare what they contain.
Imagine that you have a symlink at a/b/c/d that points a file e at the
root level, and you are running "git log a/b/c". Even if the entire
hierarchy a/ does not change in a commit since its parent, you may have to
show a/b/c/d only because "e" has changed.
So I suspect that the required change would involve a lot more than a
naïve "when we reach the leaf level, if it is a symlink, read the link
contents and call get_tree_entry() to dereference the blob, or if the link
points outside the tree, use 0{40} to say 'contents undefined'".
After you compare 'a' of parent and child and find them to be identical,
you still need to anticipate that the hierarchy _might_ have a symbolic
link somewhere deep inside, and read _everything_ at least once in order
to find symbolic links and where they point at (if you did that to parent
already, and if you know that the child agrees with it at 'a', then you
can obviously do not have to read everything in the child---you know the
parent and the child have the same _contents_ in 'a' at that point). And
then grab the pointee out of parent tree and child tree to compare.
I personally do not think it is worth it.
^ permalink raw reply
* Re: [PATCH 0/4] Remove a user of extra_refs in clone
From: Junio C Hamano @ 2012-01-17 6:51 UTC (permalink / raw)
To: mhagger; +Cc: git, Jeff King, Jakub Narebski, Heiko Voigt, Johan Herland
In-Reply-To: <1326779434-20106-1-git-send-email-mhagger@alum.mit.edu>
Yay ;-)
Thanks.
^ 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