* [PATCH v2 2/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-21 0:21 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand, Vitor Antunes
In-Reply-To: <1327105292-30092-1-git-send-email-vitor.hda@gmail.com>
To find out which is its parent the commit of the new branch is applied
sequentially to each blob of the parent branch from the newest to the
oldest. The first blob which results in a zero diff is considered the
parent commit. If none is found, then the commit is applied to the top
of the parent branch.
A fast-import "checkpoint" call is required for each comparison because
diff-tree is only able to work with blobs on disk. But most of these
commits will not be part of the final imported tree, making fast-import
fail. To avoid this, the temporary branches are tracked and then removed
at the end of the import process.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 30 +++++++++++++++++++++++++++++-
1 files changed, 29 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 417d119..2e3b741 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1429,6 +1429,8 @@ class P4Sync(Command, P4UserMap):
self.cloneExclude = []
self.useClientSpec = False
self.clientSpecDirs = None
+ self.tempBranches = []
+ self.tempBranchLocation = "git-p4-tmp"
if gitConfig("git-p4.syncFromOrigin") == "false":
self.syncWithOrigin = False
@@ -2012,7 +2014,27 @@ class P4Sync(Command, P4UserMap):
parent = self.initialParents[branch]
del self.initialParents[branch]
- self.commit(description, filesForCommit, branch, [branchPrefix], parent)
+ parentFound = False
+ if len(parent) > 0:
+ tempBranch = os.path.join(self.tempBranchLocation, "%d" % (change))
+ if self.verbose:
+ print "Creating temporary branch: " + tempBranch
+ self.commit(description, filesForCommit, tempBranch, [branchPrefix])
+ self.tempBranches.append(tempBranch)
+ self.checkpoint()
+ for blob in read_pipe_lines("git rev-list --reverse --no-merges %s" % parent):
+ blob = blob.strip()
+ if len( read_pipe("git diff-tree %s %s" % (blob, tempBranch)) ) == 0:
+ parentFound = True
+ 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)
else:
files = self.extractFilesFromCommit(description)
self.commit(description, files, self.branch, self.depotPaths,
@@ -2347,6 +2369,12 @@ class P4Sync(Command, P4UserMap):
self.gitOutput.close()
self.gitError.close()
+ # Cleanup temporary branches created during import
+ if self.tempBranches != []:
+ for branch in self.tempBranches:
+ read_pipe("git update-ref -d %s" % branch)
+ os.rmdir(os.path.join(os.environ.get("GIT_DIR", ".git"), self.tempBranchLocation))
+
return True
class P4Rebase(Command):
--
1.7.7.rc2.14.g5e044.dirty
^ permalink raw reply related
* [PATCH v2 3/3] git-p4: Add test case for complex branch import
From: Vitor Antunes @ 2012-01-21 0:21 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand, Vitor Antunes
In-Reply-To: <1327105292-30092-1-git-send-email-vitor.hda@gmail.com>
Check if branches created from old changelists are correctly imported.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
t/t9801-git-p4-branch.sh | 80 ++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 80 insertions(+), 0 deletions(-)
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index a25f18d..ed4e48c 100755
--- a/t/t9801-git-p4-branch.sh
+++ b/t/t9801-git-p4-branch.sh
@@ -226,6 +226,86 @@ test_expect_success 'git-p4 clone simple branches' '
)
'
+# Create a complex branch structure in P4 depot to check if they are correctly
+# cloned. The branches are created from older changelists to check if git-p4 is
+# able to correctly detect them.
+# The final expected structure is:
+# `branch1
+# | `- file1
+# | `- file2 (updated)
+# | `- file3
+# `branch2
+# | `- file1
+# | `- file2
+# `branch3
+# | `- file1
+# | `- file2 (updated)
+# | `- file3
+# `branch4
+# | `- file1
+# | `- file2
+# `branch5
+# `- file1
+# `- file2
+# `- file3
+test_expect_success 'git-p4 add complex branches' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ (
+ cd "$cli" &&
+ changelist=$(p4 changes -m1 //depot/... | cut -d" " -f2) &&
+ changelist=$(($changelist - 5)) &&
+ p4 integrate //depot/branch1/...@$changelist //depot/branch4/... &&
+ p4 submit -d "branch4" &&
+ changelist=$(($changelist + 2)) &&
+ p4 integrate //depot/branch1/...@$changelist //depot/branch5/... &&
+ p4 submit -d "branch5"
+ )
+'
+
+# Configure branches through git-config and clone them. git-p4 will only be able
+# to clone the original structure if it is able to detect the origin changelist
+# of each branch.
+test_expect_success 'git-p4 clone complex branches' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ (
+ cd "$git" &&
+ git config git-p4.branchList branch1:branch2 &&
+ git config --add git-p4.branchList branch1:branch3 &&
+ git config --add git-p4.branchList branch1:branch4 &&
+ git config --add git-p4.branchList branch1:branch5 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch1 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_file file3 &&
+ grep -q update file2 &&
+ git reset --hard p4/depot/branch2 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_missing file3 &&
+ ! grep -q update file2 &&
+ git reset --hard p4/depot/branch3 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_file file3 &&
+ grep -q update file2 &&
+ git reset --hard p4/depot/branch4 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_missing file3 &&
+ ! grep -q update file2 &&
+ git reset --hard p4/depot/branch5 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_file file3 &&
+ ! grep -q update file2 &&
+ test_path_is_missing .git/git-p4-tmp
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.7.rc2.14.g5e044.dirty
^ permalink raw reply related
* [PATCH v2 0/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-21 0:21 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand, Vitor Antunes
The new version of these patches includes the improvement suggestions
from Pete Wyckoff:
- Use os.path.join().
- Use git update-ref -d to remove refs.
- Read $GIT_DIR environment variable.
- Optimize comparison cycle to avoid excessive use of checkpoint
command.
Vitor Antunes (3):
git-p4: Add checkpoint() task
git-p4: Search for parent commit on branch creation
git-p4: Add test case for complex branch import
contrib/fast-import/git-p4 | 38 ++++++++++++++++++++-
t/t9801-git-p4-branch.sh | 80 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 117 insertions(+), 1 deletions(-)
--
1.7.7.rc2.14.g5e044.dirty
^ permalink raw reply
* [PATCH v2 1/3] git-p4: Add checkpoint() task
From: Vitor Antunes @ 2012-01-21 0:21 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand, Vitor Antunes
In-Reply-To: <1327105292-30092-1-git-send-email-vitor.hda@gmail.com>
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3e1aa27..417d119 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1450,6 +1450,14 @@ class P4Sync(Command, P4UserMap):
.replace("%25", "%")
return path
+ # Force a checkpoint in fast-import and wait for it to finish
+ def checkpoint(self):
+ self.gitStream.write("checkpoint\n\n")
+ self.gitStream.write("progress checkpoint\n\n")
+ out = self.gitOutput.readline()
+ if self.verbose:
+ print "checkpoint finished: " + out
+
def extractFilesFromCommit(self, commit):
self.cloneExclude = [re.sub(r"\.\.\.$", "", path)
for path in self.cloneExclude]
--
1.7.7.rc2.14.g5e044.dirty
^ permalink raw reply related
* Re: post-update to stash after push to non-bare current branch
From: Junio C Hamano @ 2012-01-21 0:16 UTC (permalink / raw)
To: Neal Kreitzinger
In-Reply-To: <4F1A0311.30502@gmail.com>
Neal Kreitzinger <nkreitzinger@gmail.com> writes:
> To get this to work I had to learn more about shell scripting and export
> the GIT_WORK_TREE git environment variable.
>
> (post-update hook):
> export GIT_WORK_TREE=/home/neal/FSNMSTHTML
> git checkout -f HEAD
Hmm, I thought "cd .. && git checkout -f HEAD" (or "git reset --hard")
would have worked.
^ permalink raw reply
* Re: post-update to stash after push to non-bare current branch
From: Neal Kreitzinger @ 2012-01-21 0:13 UTC (permalink / raw)
Cc: Neal Kreitzinger, git
In-Reply-To: <4F188FA2.1000209@gmail.com>
On 1/19/2012 3:48 PM, Neal Kreitzinger wrote:
> On 1/18/2012 7:00 PM, Junio C Hamano wrote:
>> Neal Kreitzinger<nkreitzinger@gmail.com> writes:
>>
>>>> Have you checked where in the filesystem hierarchy that script
>>>> is run (hint: pwd)?
>>>>
>>> echo pwd in post-update echoes /path/WORKTREE/.git in git-push
>>> stdout. ... 'git-checkout -f' works manually, but in post-update
>>> hook...
>>
>> Stronger hint. Did you run "git checkout -f" in
>> /path/WORKTREE/.git to back that "works manually" claim?
>
> (Manual behavior): If pwd is WORKTREE/ then git-checkout has correct
> effect, ie. worktree, index, and HEAD match. If pwd is
> WORKTREE/.git/ then git-checkout complains 'must be run in a
> worktree' and has no effect.
>
> (post-update hook behavior): If pwd is WORKTREE/.git/ then git-push
> verbage does not complain, and git-checkout exits zero status but
> has incorrect effect, ie. index and HEAD match, but worktree matches
> HEAD@{1}. If pwd is WORKTREE/ then git-push complains 'not a git
> repository', and git-checkout exits non-zero status and has no
> effect, ie. worktree and index match HEAD@{1}.
>
> Evidence:
>
> (post-update hook script): MYPWD=`pwd` echo $MYPWD pushd
> /home/neal/FSNMSTHTML MYPWD=`pwd` echo $MYPWD git checkout -f HEAD
> if [ $? -ne 0 ]; then echo "error on checkout!" else echo "checkout
> HEAD to non-bare remote current branch after push" fi echo $MYPWD
> popd MYPWD=`pwd` echo $MYPWD
>
> (git-push verbage): $ git push origin HEAD Counting objects: 9, done.
> Delta compression using up to 8 threads. Compressing objects: 100%
> (5/5), done. Writing objects: 100% (5/5), 462 bytes, done. Total 5
> (delta 4), reused 0 (delta 0) Unpacking objects: 100% (5/5), done.
> remote: warning: updating the current branch remote:
> /home/neal/FSNMSTHTML/.git remote: ~/FSNMSTHTML ~/FSNMSTHTML/.git
> remote: /home/neal/FSNMSTHTML remote: fatal: Not a git repository:
> '.' remote: error on checkout! remote: /home/neal/FSNMSTHTML remote:
> ~/FSNMSTHTML/.git remote: /home/neal/FSNMSTHTML/.git To
> file:///home/neal/FSNMSTHTML cee9269..34dc5a9 HEAD -> master
>
To get this to work I had to learn more about shell scripting and export
the GIT_WORK_TREE git environment variable.
(post-update hook):
export GIT_WORK_TREE=/home/neal/FSNMSTHTML
git checkout -f HEAD
for more info see this stackoverflow thread
http://stackoverflow.com/questions/6635018/reuse-git-work-tree-in-post-receive-hook-to-rm-a-few-files
v/r,
neal
^ permalink raw reply
* highlights from next "What's cooking"
From: Junio C Hamano @ 2012-01-21 0:13 UTC (permalink / raw)
To: git
These have been merged for upcoming 1.7.9 recently:
* jc/pull-signed-tag-doc (2012-01-17) 1 commit
+ pulling signed tag: add howto document
* 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
* 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
* 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
* jk/credentials (2012-01-16) 4 commits
(merged to 'next' on 2012-01-16 at 2810b82)
+ credential-cache: ignore "connection refused" errors
(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
Also I updated the jc/pull-signed-tag topic that follows Linus's
suggestion to always spawn an editor when running "git merge" in an
interactive session. The special-case environment variable has been
renamed to MERGE_AUTOEDIT, and scripts can set it to "no" when they start
to accept the autogenerated merge log message. There is no plan to
encourage humans to keep using the historical behaviour, hence there is no
support for configuration variable (e.g. merge.autoedit) that can be set
to 'no'.
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Junio C Hamano @ 2012-01-21 0:04 UTC (permalink / raw)
To: David Brown; +Cc: Andreas Schwab, Brian Foster, git mailing list
In-Reply-To: <20120120233335.GA20302@codeaurora.org>
David Brown <davidb@codeaurora.org> writes:
> Hmm, I thought I'd convinced myself that this was possible. Now, I
> can't come up with a way of doing it that doesn't involve improper
> commits with earlier timestamps than their parents.
I'd actually want to see a way to do so that *does* involve timestamp
skew.
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: David Brown @ 2012-01-20 23:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, Brian Foster, git mailing list
In-Reply-To: <7v7h0mfahx.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 11:18:50AM -0800, Junio C Hamano wrote:
> David Brown <davidb@codeaurora.org> writes:
>
> > On Fri, Jan 20, 2012 at 03:13:58PM +0100, Andreas Schwab wrote:
> >> Brian Foster <brian.foster@maxim-ic.com> writes:
> >>
> >> > In a script, how can I determine commit Y is reachable
> >> > from the current HEAD ?
> >>
> >> test $(git merge-base HEAD Y) = $(git rev-parse Y)
> >
> > Almost. It works as long as there is only one merge base. You really
> > need to check if $(git rev-parse Y) is one of $(git merge-base --all
> > HEAD Y)
>
> Can you give us an example of a topology to which "merge-base --all HEAD Y"
> gives more than one output and Y is still reachable from HEAD?
>
> It is my understanding that merge-base computation will give only Y and
> nothing else when Y is reachable from HEAD. I also think this assumption
> is used by some of the internal code in Git, and that is why I care.
Hmm, I thought I'd convinced myself that this was possible. Now, I
can't come up with a way of doing it that doesn't involve improper
commits with earlier timestamps than their parents.
Sorry about that,
David
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Sitaram Chamarty @ 2012-01-20 22:50 UTC (permalink / raw)
To: Brian Foster; +Cc: git mailing list
In-Reply-To: <201201201433.30267.brian.foster@maxim-ic.com>
On Fri, Jan 20, 2012 at 7:03 PM, Brian Foster <brian.foster@maxim-ic.com> wrote:
>
> Hello,
>
> Whilst I have found answers to my question on the Web,
> only one seems to do exactly what I want ....
>
> x---Y---y---y---y HEAD
> /
> ...--o---o---C---o---S
> \
> n---n---N---*---* other
>
> In a script, how can I determine commit Y is reachable
> from the current HEAD ? And, much more importantly
I've been using 'git rev-list HEAD..Y'. If it produces any output, Y
is not reachable from HEAD (there is something in Y that is not in
HEAD).
^ permalink raw reply
* git clone, hardlinks and multiple users?
From: Marc Herbert @ 2012-01-20 17:31 UTC (permalink / raw)
To: git
Hi,
"git clone" is using hardlinks by default, even when cloning from a
different user. In such a case the clone ends up with a number of files
owned by someone else.
Since only immutable objects are cloned this seems to work fine. However
I would like to know if this "multiple users" case works by chance or by
specification.
In other words, is there a guarantee that no later version of git or no
obscure option I haven't used yet will ever try to touch a hardlink in
any way like for instance: trying update some metadata timestamp or,
overwrite it with the same value by lack of optimization, or any other
kind of side-effect that would obviously fail.
Thanks in advance!
Marc
^ permalink raw reply
* Finding all commits which modify a file
From: Neal Groothuis @ 2012-01-20 21:35 UTC (permalink / raw)
To: git
Hello,
I'm trying to find /all/ commits that change a file in the
repository...and its proving to be trickier than I thought. :-)
The situation that we were dealing with is this:
- Person A and person B both pull from the same central repository.
- Person A makes a change to file foo.txt and bar.txt, commits, and pushes
to the central repository.
- Person B makes a similar change to bar.txt and commits it.
- Person B does a fetch and merge. Since both A and B made changes to
bar.txt, this requires conflicts to be resolved manually.
- B reverts A's changes to foo.txt. (If B is coming from a different
revision control system, this may happen due to confusion about how merges
are handled.)
- B commits the changes.
- B makes more changes to bar.txt, commits them, and pushes to the central
repository.
At this point, A's changes to foo.txt have been undone.
Graphically:
A1
/ ^
v \
C1 B2<-B3
^ /
\ v
B1
B1, B2, and B3 have the same version of foo.txt as C1, A1 modifies it.
Person A discovers that his changes are missing and wants to know what
happened.
git log foo.txt doesn't help; it won't even show commit A1, due to history
simplification.
git log --full-history foo.txt will show commit A1. It still won't show
commit B2, though, which we'd also like to show (because that's where the
change to foo.txt got removed).
I would think that git log --simplify-merges foo.txt would have done what
I'd wanted, but it still does not show commit B2. Based on what I'm
reading in the man page, I would expect the simplification to go like
this:
A1
| ^
| \
| B2<-B3
| /
v v
C1
(since B1 is TREESAME as C1 if we're only considering foo.txt)
A1
| ^
| \
| B2<-B3
|
v
C1
(since C1 is an ancestor of A1)
However, the actual output only includes A1, not B2.
- Can someone explain this, and/or
- can someone offer a command to display all commits (including merges)
in which ANY parent is not TREESAME?
Thanks!
- Neal
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Alex Riesen @ 2012-01-20 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <7vbopydst0.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 21:26, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>> .... Besides, the current version
>> wont have problems with such an upgrade.
>
> Yes, but at what cost?
A fixed number of "fork and exec" for every executed ". git-sh-i18n" line?
The overhead might be considered negligible...
Er. Am I missing something very obvious? (not obvious to me, yet)
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Junio C Hamano @ 2012-01-20 20:26 UTC (permalink / raw)
To: Alex Riesen; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <CALxABCZnz-8BuXf=-HrH7UZXi6pQ3VzL4HrOKgKHqWwUMnwJQA@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> .... Besides, the current version
> wont have problems with such an upgrade.
Yes, but at what cost?
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Alex Riesen @ 2012-01-20 20:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <7vfwfadt10.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 21:21, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>>> ... At build time, instead
>>> of, or in addition to, the $(cmd_munge_script), we could replace the
>>> single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to
>>> use to hardcode the decision we make at the compile time.
>>
>> I can imagine a Solaris system being upgraded to GNU gettext _after_ Git
>> installation. Hardcoding the decision might break git scripts then.
>
> Just like you would break http transport by removing libcurl after
> installing Git? What else is new?
Removing - yes, upgrading it - very unlikely. Besides, the current version
wont have problems with such an upgrade.
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Junio C Hamano @ 2012-01-20 20:21 UTC (permalink / raw)
To: Alex Riesen; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <CALxABCZJATyVRf9akmfpn3WpJ8Xt80Ky0isFOTwDGpFKvFp3nw@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
>> ... At build time, instead
>> of, or in addition to, the $(cmd_munge_script), we could replace the
>> single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to
>> use to hardcode the decision we make at the compile time.
>
> I can imagine a Solaris system being upgraded to GNU gettext _after_ Git
> installation. Hardcoding the decision might break git scripts then.
Just like you would break http transport by removing libcurl after
installing Git? What else is new?
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Alex Riesen @ 2012-01-20 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð, git, Johannes Sixt
In-Reply-To: <7vobtydu0o.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 21:00, Junio C Hamano <gitster@pobox.com> wrote:
> IOW, the first step would look like the attached patch, and then we can
> replace the entire "First decide" part if/elif/fi chain with just this:
>
> # The scheme to use
> : ${GIT_INTERNAL_GETTEXT_SH_SCHEME:=@@GETTEXT_SH_SCHEME@@}
>
> so that t/lib-gettext.sh can define and export GIT_INTERNAL_GETTEXT_SH to
> always get what it wants to test (fallthrough?). At build time, instead
> of, or in addition to, the $(cmd_munge_script), we could replace the
> single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to
> use to hardcode the decision we make at the compile time.
I can imagine a Solaris system being upgraded to GNU gettext _after_ Git
installation. Hardcoding the decision might break git scripts then.
^ permalink raw reply
* Re: [PATCH] git-sh-i18n: detect and avoid broken gettext(1) implementation
From: Junio C Hamano @ 2012-01-20 20:00 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason
Cc: git, Junio C Hamano, Alex Riesen, Johannes Sixt
In-Reply-To: <1327063775-28420-1-git-send-email-avarab@gmail.com>
Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
> Here's a minimal patch to git-sh-i18n that should make things work on
> Cygwin and any other platforms with broken gettext functions while
> also using the OS-provided functions if they work.
> I've added a new t0201-gettext-fallbacks-broken-gettext.sh test that
> tests this. This required a small change in lib-gettext.sh so I
> wouldn't load test-lib.sh twice.
>
> Note that there's already a t0201* test in the repo. Maybe we want to
> increment all the gettext test numbers by one to make room for it?
>
> As an aside I'm really not a big fan of having hardcoded numbers in
> the test files like this. We don't care about the order of execution
> here.
We do not care the order but we do care about the uniqueness in parallel
test execution.
It does appear that we need a bit better preprocessing of git-sh-i18n at
the compile time now. How about applying the restructuring shown in the
patch by Alex (without the @@NO_GETTEXT@@ bit) first without changing any
logic, then try making the "First decide what scheme to use" part lighter
weight by replacing the runtime "type gettext.sh" and such checks with
some preprocessing?
IOW, the first step would look like the attached patch, and then we can
replace the entire "First decide" part if/elif/fi chain with just this:
# The scheme to use
: ${GIT_INTERNAL_GETTEXT_SH_SCHEME:=@@GETTEXT_SH_SCHEME@@}
so that t/lib-gettext.sh can define and export GIT_INTERNAL_GETTEXT_SH to
always get what it wants to test (fallthrough?). At build time, instead
of, or in addition to, the $(cmd_munge_script), we could replace the
single @@GETTEXT_SH_SCHEME@@ token above with whatever scheme we want to
use to hardcode the decision we make at the compile time.
Hmm?
git-sh-i18n.sh | 103 +++++++++++++++++++++++++++-----------------------------
1 files changed, 50 insertions(+), 53 deletions(-)
diff --git a/git-sh-i18n.sh b/git-sh-i18n.sh
index 26a57b0..6648bd3 100644
--- a/git-sh-i18n.sh
+++ b/git-sh-i18n.sh
@@ -16,61 +16,45 @@ else
fi
export TEXTDOMAINDIR
-if test -z "$GIT_GETTEXT_POISON"
+# First decide what scheme to use...
+GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
+if test -n "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS"
+then
+ : no probing necessary
+elif test -n "$GIT_GETTEXT_POISON"
then
- if test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && type gettext.sh >/dev/null 2>&1 && test "$(gettext test 2>&1)" = "test"
- then
- # This is GNU libintl's gettext.sh, we don't need to do anything
- # else than setting up the environment and loading gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Try to use libintl's gettext.sh, or fall back to English if we
- # can't.
- . gettext.sh
-
- elif test -z "$GIT_INTERNAL_GETTEXT_TEST_FALLBACKS" && test "$(gettext -h 2>&1)" = "-h"
- then
- # We don't have gettext.sh, but there's a gettext binary in our
- # path. This is probably Solaris or something like it which has a
- # gettext implementation that isn't GNU libintl.
- GIT_INTERNAL_GETTEXT_SH_SCHEME=solaris
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- # Solaris has a gettext(1) but no eval_gettext(1)
- eval_gettext () {
- gettext "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
-
- else
- # Since gettext.sh isn't available we'll have to define our own
- # dummy pass-through functions.
-
- # Tell our tests that we don't have the real gettext.sh
- GIT_INTERNAL_GETTEXT_SH_SCHEME=fallthrough
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
-
- gettext () {
- printf "%s" "$1"
- }
-
- eval_gettext () {
- printf "%s" "$1" | (
- export PATH $(git sh-i18n--envsubst --variables "$1");
- git sh-i18n--envsubst "$1"
- )
- }
- fi
-else
- # Emit garbage under GETTEXT_POISON=YesPlease. Unlike the C tests
- # this relies on an environment variable
-
GIT_INTERNAL_GETTEXT_SH_SCHEME=poison
- export GIT_INTERNAL_GETTEXT_SH_SCHEME
+elif type gettext.sh >/dev/null 2>&1
+then
+ # GNU libintl's gettext.sh
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gnu
+elif test "$(gettext -h 2>&1)" = "-h"
+then
+ # gettext binary exists but no gettext.sh. likely to be a gettext
+ # binary on a Solaris or something that is not GNU libintl and
+ # lack eval_gettext.
+ GIT_INTERNAL_GETTEXT_SH_SCHEME=gettext_without_eval_gettext
+fi
+export GIT_INTERNAL_GETTEXT_SH_SCHEME
+# ... and then follow that decision.
+case "$GIT_INTERNAL_GETTEXT_SH_SCHEME" in
+gnu)
+ # Use libintl's gettext.sh, or fall back to English if we can't.
+ . gettext.sh
+ ;;
+gettext_without_eval_gettext)
+ # Solaris has a gettext(1) but no eval_gettext(1)
+ eval_gettext () {
+ gettext "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+poison)
+ # Emit garbage so that tests that incorrectly rely on translatable
+ # strings will fail.
gettext () {
printf "%s" "# GETTEXT POISON #"
}
@@ -78,7 +62,20 @@ else
eval_gettext () {
printf "%s" "# GETTEXT POISON #"
}
-fi
+ ;;
+*)
+ gettext () {
+ printf "%s" "$1"
+ }
+
+ eval_gettext () {
+ printf "%s" "$1" | (
+ export PATH $(git sh-i18n--envsubst --variables "$1");
+ git sh-i18n--envsubst "$1"
+ )
+ }
+ ;;
+esac
# Git-specific wrapper functions
gettextln () {
^ permalink raw reply related
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-20 19:45 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ævar Arnfjörð, Johannes Sixt, Git Mailing List
In-Reply-To: <7vsjjadv5g.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 20:35, Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
>>> And then a --version for whatever programs that function uses,
>>> e.g. here:
>>>
>>> $ envsubst --version
>>
>> Nothing. Exit code 127.
>
> Interesting.
>
> $ wonbsubst --version; echo $?
> bash: wonbsubst: command not found
> 127
>
> Perhaps your distro lacks a necessary package dependencies between gettext
> and envsubst?
>
>> I believe gettext (the binary) just doesn't start at all here. Maybe
>> some Cygwin library wrong or missing library. Happens all the time
>> here,...
>
> Aha.
>
> I guess we either leave it broken for broken installation or add an extra
> "MY_GETTEXT_IS_BROKEN" option; in either way, it does not sound like a
> serious enough issue that is widespread to be urgently fixed during the
> feature freeze.
Ævar already posted a very cute little fix for this, which looks
pretty minimal and is very obvious.
P.S. Sorry for html mail before (tried to use the Android Gmail client).
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Junio C Hamano @ 2012-01-20 19:35 UTC (permalink / raw)
To: Alex Riesen
Cc: Ævar Arnfjörð Bjarmason, Johannes Sixt,
Git Mailing List
In-Reply-To: <CALxABCZWBtgX736Acoy-CCAz8RJb0EKnHf+7g72dOdVS+BOhSw@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
>> And then a --version for whatever programs that function uses,
>> e.g. here:
>>
>> $ envsubst --version
>
> Nothing. Exit code 127.
Interesting.
$ wonbsubst --version; echo $?
bash: wonbsubst: command not found
127
Perhaps your distro lacks a necessary package dependencies between gettext
and envsubst?
> I believe gettext (the binary) just doesn't start at all here. Maybe
> some Cygwin library wrong or missing library. Happens all the time
> here,...
Aha.
I guess we either leave it broken for broken installation or add an extra
"MY_GETTEXT_IS_BROKEN" option; in either way, it does not sound like a
serious enough issue that is widespread to be urgently fixed during the
feature freeze.
^ permalink raw reply
* Re: Autocompletion - commands no longer work as stand alone
From: Nathan Bullock @ 2012-01-20 19:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: SZEDER Gábor, git
In-Reply-To: <7vwr8mdvo8.fsf@alter.siamese.dyndns.org>
So just as a comment on the use of underscores. The actual main auto
complete function, _git, also starts with an underscore. From looking
at the code it looked like the double underscore functions were the
internal ones.
2012/1/20 Junio C Hamano <gitster@pobox.com>:
> Pinging Szeder. I personally do not think it is a crime for us to break
> anything that uses an internal function whose name begins with underscore,
> but people more deeply involved in this part of the system may have ideas
> to help supporting even such users.
>
> Nathan Bullock <nathanbullock@gmail.com> writes:
>
>> I have for a number of years had the following in my .bashrc
>>
>> alias br="git branch"
>> complete -F _git_branch br
>>
>> As well as similar commands for co and log.
>>
>> Recently though this broke, now when I type something like "br
>> mas<command completion>" it will occasionally complain with messages
>> like:
>> bash: [: 1: unary operator expected
>>
>> From digging through the source it looks like this was broken back in
>> April. (The commit is show at the bottom of this email.)
>>
>> So my questions are:
>> 1. Is it reasonable for things like _git_branch to work as a
>> standalone autocompletion function instead of having to go through
>> _git? I certainly like it to work as a standalone function. I also use
>> it to add autocompletion to other bash scripts that I use frequently.
>>
>> 2. If I add code that verifies that the variable cword exists at the
>> start of these functions and only if not call something like
>> _get_comp_words_by_ref -n =: cur words cword prev. Would that be
>> reasonable? I think this should address the performance concerns that
>> caused these to be removed in the first place, but it may make the
>> code uglier.
>>
>> I have already added wrapper functions in my bashrc so that this is no
>> longer a problem for me, but there may be other people who start
>> hitting this as well once they start using newer versions of git.
>>
>> Nathan
>>
>>
>> commit da4902a73017ad82b9926d03101ec69a2802d1e7
>> Author: SZEDER Gábor <szeder@ira.uka.de>
>> Date: Thu Apr 28 18:01:52 2011 +0200
>>
>> completion: remove unnecessary _get_comp_words_by_ref() invocations
>>
>> In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
>> with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()
>> to access completion-related variables. That was large change, and to
>> make it easily reviewable, we invoked _get_comp_words_by_ref() in each
>> completion function and systematically replaced every occurance of
>> bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with
>> variables set by _get_comp_words_by_ref().
>>
>> This has the downside that _get_comp_words_by_ref() is invoked several
>> times during a single completion. The worst offender is perhaps 'git
>> log mas<TAB>': during the completion of 'master'
>> _get_comp_words_by_ref() is invoked no less than six times.
>>
>> However, the variables $prev, $cword, and $words provided by
>> _get_comp_words_by_ref() are not modified in any of the completion
>> functions, and the previous commit ensures that the $cur variable is
>> not modified as well. This makes it possible to invoke
>> _get_comp_words_by_ref() to get those variables only once in our
>> toplevel completion functions _git() and _gitk(), and all other
>> completion functions will inherit them.
>>
>> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
>> Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: Autocompletion - commands no longer work as stand alone
From: Junio C Hamano @ 2012-01-20 19:24 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Nathan Bullock, git
In-Reply-To: <CAPx=Vfqj3UZuFv3Xmupy7k9arUxyZJyprm628p9QVKabdOz8cw@mail.gmail.com>
Pinging Szeder. I personally do not think it is a crime for us to break
anything that uses an internal function whose name begins with underscore,
but people more deeply involved in this part of the system may have ideas
to help supporting even such users.
Nathan Bullock <nathanbullock@gmail.com> writes:
> I have for a number of years had the following in my .bashrc
>
> alias br="git branch"
> complete -F _git_branch br
>
> As well as similar commands for co and log.
>
> Recently though this broke, now when I type something like "br
> mas<command completion>" it will occasionally complain with messages
> like:
> bash: [: 1: unary operator expected
>
> From digging through the source it looks like this was broken back in
> April. (The commit is show at the bottom of this email.)
>
> So my questions are:
> 1. Is it reasonable for things like _git_branch to work as a
> standalone autocompletion function instead of having to go through
> _git? I certainly like it to work as a standalone function. I also use
> it to add autocompletion to other bash scripts that I use frequently.
>
> 2. If I add code that verifies that the variable cword exists at the
> start of these functions and only if not call something like
> _get_comp_words_by_ref -n =: cur words cword prev. Would that be
> reasonable? I think this should address the performance concerns that
> caused these to be removed in the first place, but it may make the
> code uglier.
>
> I have already added wrapper functions in my bashrc so that this is no
> longer a problem for me, but there may be other people who start
> hitting this as well once they start using newer versions of git.
>
> Nathan
>
>
> commit da4902a73017ad82b9926d03101ec69a2802d1e7
> Author: SZEDER Gábor <szeder@ira.uka.de>
> Date: Thu Apr 28 18:01:52 2011 +0200
>
> completion: remove unnecessary _get_comp_words_by_ref() invocations
>
> In v1.7.4-rc0~11^2~2 (bash: get --pretty=m<tab> completion to work
> with bash v4, 2010-12-02) we started to use _get_comp_words_by_ref()
> to access completion-related variables. That was large change, and to
> make it easily reviewable, we invoked _get_comp_words_by_ref() in each
> completion function and systematically replaced every occurance of
> bash's completion-related variables ($COMP_WORDS and $COMP_CWORD) with
> variables set by _get_comp_words_by_ref().
>
> This has the downside that _get_comp_words_by_ref() is invoked several
> times during a single completion. The worst offender is perhaps 'git
> log mas<TAB>': during the completion of 'master'
> _get_comp_words_by_ref() is invoked no less than six times.
>
> However, the variables $prev, $cword, and $words provided by
> _get_comp_words_by_ref() are not modified in any of the completion
> functions, and the previous commit ensures that the $cur variable is
> not modified as well. This makes it possible to invoke
> _get_comp_words_by_ref() to get those variables only once in our
> toplevel completion functions _git() and _gitk(), and all other
> completion functions will inherit them.
>
> Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: Junio C Hamano @ 2012-01-20 19:18 UTC (permalink / raw)
To: David Brown; +Cc: Andreas Schwab, Brian Foster, git mailing list
In-Reply-To: <20120120180620.GA8504@codeaurora.org>
David Brown <davidb@codeaurora.org> writes:
> On Fri, Jan 20, 2012 at 03:13:58PM +0100, Andreas Schwab wrote:
>> Brian Foster <brian.foster@maxim-ic.com> writes:
>>
>> > In a script, how can I determine commit Y is reachable
>> > from the current HEAD ?
>>
>> test $(git merge-base HEAD Y) = $(git rev-parse Y)
>
> Almost. It works as long as there is only one merge base. You really
> need to check if $(git rev-parse Y) is one of $(git merge-base --all
> HEAD Y)
Can you give us an example of a topology to which "merge-base --all HEAD Y"
gives more than one output and Y is still reachable from HEAD?
It is my understanding that merge-base computation will give only Y and
nothing else when Y is reachable from HEAD. I also think this assumption
is used by some of the internal code in Git, and that is why I care.
^ permalink raw reply
* Re: [PATCH v3] mergetool: Provide an empty file when needed
From: Junio C Hamano @ 2012-01-20 18:28 UTC (permalink / raw)
To: Jason Wenger; +Cc: David Aguilar, git
In-Reply-To: <CAM6z=4-HfRAjJjnYqfoiYsYjiZJSsbkCaW-VtLWvoeFM0xsB9g@mail.gmail.com>
Jason Wenger <jcwenger@gmail.com> writes:
> On Fri, Jan 20, 2012 at 01:53, David Aguilar <davvid@gmail.com> wrote:
>> On Thu, Jan 19, 2012 at 11:47 PM, David Aguilar <davvid@gmail.com> wrote:
>>> Some merge tools cannot cope when $LOCAL, $BASE, or $REMOTE
>>> are missing. $BASE can be missing when two branches
>>> independently add the same filename. $LOCAL and $REMOTE
>>> can be missing when a delete/modify conflict occurs.
>>>
>>> Provide an empty file to make these tools happy.
>
> This is cleaner, yes -- but is this extra processing on $LOCAL and
> $REMOTE necessary? Git mergetool doesn't actually call an external
> mergetool during del/mod conflicts -- instead it goes into an
> alternate processing and prompts the user interactively whether to
> take the deleted or modified file. Can these changes be reached?
> (command line option I'm not aware of?)
Thanks for a careful reading. I did not read outside the context of the
patch so I didn't know if we had special cases for del/mod.
A bigger question is if the del/mod codepaths are negatively affected by
the presense of these superfluous empty $LOCAL/$REMOTE files. If they are,
this change will _break_ things. If they are not, I think the change would
be OK.
Another small worry is that this could potentially negatively affect some
merge tools that are sufficiently clueful, if it can give different and
better results for a true two-way-merge than a simulated two-way-merge
this patch feeds them by using a three-way-merge with an empty file as a
base.
^ permalink raw reply
* Re: [PATCH] remote-curl: Fix push status report when all branches fail
From: Junio C Hamano @ 2012-01-20 18:18 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1327079011-24788-1-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Always print a blank line after the send-pack process terminates,
> ensuring the helper status report (if it was output) will be
> correctly parsed by the calling transport-helper.c. This ensures
> the helper doesn't abort before the status report can be shown to
> the user.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
Thanks; let's do the following on top of this patch, so that:
- We won't miss a "git push" that errorneously succeeds; and
- We won't be affected by any future change in the sideband #2
demultiplexor of the amount of "padding".
t/t5541-http-push.sh | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git b/t/t5541-http-push.sh a/t/t5541-http-push.sh
index d3e340e..b8f4c2a 100755
--- b/t/t5541-http-push.sh
+++ a/t/t5541-http-push.sh
@@ -101,8 +101,8 @@ exit 1
EOF
chmod a+x "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update"
-printf 'remote: error: hook declined to update refs/heads/dev2 \n' >exp
-cat >>exp <<EOF
+cat >exp <<EOF
+remote: error: hook declined to update refs/heads/dev2
To http://127.0.0.1:$LIB_HTTPD_PORT/smart/test_repo.git
! [remote rejected] dev2 -> dev2 (hook declined)
error: failed to push some refs to 'http://127.0.0.1:5541/smart/test_repo.git'
@@ -115,8 +115,9 @@ test_expect_success 'rejected update prints status' '
git add path4 &&
test_tick &&
git commit -m dev2 &&
- git push origin dev2 2>act
- test_cmp exp act
+ test_must_fail git push origin dev2 2>act &&
+ sed -e "/^remote: /s/ *$//" <act >cmp &&
+ test_cmp exp cmp
'
rm -f "$HTTPD_DOCUMENT_ROOT_PATH/test_repo.git/hooks/update"
^ permalink raw reply related
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