* 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: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: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: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: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
* 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
* 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
* 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
* 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: 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
* 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: 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
* 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
* [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
* [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 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 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
* Re: post-update to stash after push to non-bare current branch
From: Neal Kreitzinger @ 2012-01-21 0:35 UTC (permalink / raw)
To: Junio C Hamano
In-Reply-To: <7vr4ytdi54.fsf@alter.siamese.dyndns.org>
On 1/20/2012 6:16 PM, Junio C Hamano wrote:
> 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.
Ok, I just tried that for the first time and it complained "not a git
repository: '.'" because it looks like that caused GIT_DIR to no longer
point to WORKTREE/.git but instead to WORKTREE/ because GIT_DIR is set
to '.' in the post-update script's environment as indicated in this
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
* Re: [PATCH v2 3/3] git-p4: Add test case for complex branch import
From: Junio C Hamano @ 2012-01-21 4:54 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Pete Wyckoff, Luke Diamand
In-Reply-To: <1327105292-30092-4-git-send-email-vitor.hda@gmail.com>
Vitor Antunes <vitor.hda@gmail.com> writes:
> +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"
That's a strange quoting convention. Why are "branch4" and "branch5"
enclosed in double quotes while "integrate" and "submit" aren't?
(rhetorical: do not quote these branch names without a good reason).
> +# 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 &&
Do you really need to use "-q" here? Wouldn't it help if you wrote it
without it while debugging tests with "sh ./t9801-*.sh -v"?
Also how does this series interact with the series Luke posted earlier on
branches and labels?
Thanks.
^ permalink raw reply
* Re: [PATCH v2 2/3] git-p4: Search for parent commit on branch creation
From: Junio C Hamano @ 2012-01-21 4:55 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git, Pete Wyckoff, Luke Diamand
In-Reply-To: <1327105292-30092-3-git-send-email-vitor.hda@gmail.com>
Vitor Antunes <vitor.hda@gmail.com> writes:
> 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>
> ---
It might make sense to squash 1/3 with this patch; the definition alone
without any actual user would not be very useful and won't help hunting
for breakages, if exists, in the future.
> @@ -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)
... also this looks excessively deeply nested, which is a sign that it
might be a good idea to refactor this part into a separate helper function
or something.
^ permalink raw reply
* Re: [Q] Determing if a commit is reachable from the HEAD ?
From: David Brown @ 2012-01-21 4:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Schwab, Brian Foster, git mailing list
In-Reply-To: <7vzkdhdiot.fsf@alter.siamese.dyndns.org>
On Fri, Jan 20, 2012 at 04:04:50PM -0800, Junio C Hamano wrote:
> 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.
Sorry, I guess I shouldn't tried this with a recent version of git. I
can't cause this, and it looks like there's some pretty sophisticated
stuff in there to deal with this.
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
* [PATCH] mergetool: Suppress stderr and fix the "both added" test
From: David Aguilar @ 2012-01-21 10:26 UTC (permalink / raw)
To: gitster; +Cc: jcwenger, git
Silence error messages when "git checkout-index" is used to
checkout a stage that does not exist. This can happen now that
mergetool calls checkout_staged_file() unconditionally when
creating the temporary $BASE, $LOCAL, and $REMOTE files.
Fix the test so that it checks the contents of the "both added"
file. The test was passing as a consequence of accidentally
handing a bad path to "cat".
Signed-off-by: David Aguilar <davvid@gmail.com>
---
This applies on top of da/maint-mergetool-twoway in pu.
git-mergetool.sh | 4 +++-
t/t7610-mergetool.sh | 5 +++--
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 24bedc5..a9f23f7 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -181,7 +181,9 @@ stage_submodule () {
}
checkout_staged_file () {
- tmpfile=$(expr "$(git checkout-index --temp --stage="$1" "$2")" : '\([^ ]*\) ')
+ tmpfile=$(expr \
+ "$(git checkout-index --temp --stage="$1" "$2" 2>/dev/null)" \
+ : '\([^ ]*\) ')
if test $? -eq 0 -a -n "$tmpfile" ; then
mv -- "$(git rev-parse --show-cdup)$tmpfile" "$3"
diff --git a/t/t7610-mergetool.sh b/t/t7610-mergetool.sh
index 2272743..3f261a3 100755
--- a/t/t7610-mergetool.sh
+++ b/t/t7610-mergetool.sh
@@ -465,8 +465,9 @@ test_expect_success 'directory vs modified submodule' '
test_expect_success 'file with no base' '
git checkout -b test13 branch1 &&
test_must_fail git merge master &&
- git mergetool --no-prompt --tool mybase -- base &&
- test "$(cat "$MERGED")" = "" &&
+ git mergetool --no-prompt --tool mybase -- both &&
+ >expected &&
+ test_cmp both expected &&
git reset --hard master >/dev/null 2>&1
'
--
1.7.7.166.g1cd0c
^ permalink raw reply related
* Re: [PATCH v2 3/3] git-p4: Add test case for complex branch import
From: Luke Diamand @ 2012-01-21 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Vitor Antunes, git, Pete Wyckoff
In-Reply-To: <7vehutd59p.fsf@alter.siamese.dyndns.org>
On 21/01/12 04:54, Junio C Hamano wrote:
> Vitor Antunes<vitor.hda@gmail.com> writes:
>
>> + grep -q update file2&&
>
> Do you really need to use "-q" here? Wouldn't it help if you wrote it
> without it while debugging tests with "sh ./t9801-*.sh -v"?
>
> Also how does this series interact with the series Luke posted earlier on
> branches and labels?
Vitor's series applies cleanly to my changes.
However, one thing I noticed in reading through is that it will break if
you end up importing a P4 branch that has spaces (or other shell chars)
in its name. A quick test confirms this.
- the code doesn't handle the names properly
- git and p4 have different ideas about valid branch names
But before rejecting Vitor's changes because of that it would be worth
considering whether we care (much). My own opinion is that if you have
developers who are daft enough to put spaces or dollars in their branch
names then their project is already doomed anyway....
Perhaps it would be enough just to issue a warning ("your project is
doomed; start working on your CV") and skip such branch names rather
than falling over with inexplicable error messages.
>
> Thanks.
^ permalink raw reply
* How to restore "svn mirror generator"?
From: Manuel Reimer @ 2012-01-21 15:45 UTC (permalink / raw)
To: git
Hello,
I want to create a GIT mirror of a SVN repository.
I plan to mirror a SVN server to GIT. I don't want to fetch the full history but
all future commits should be mirrored.
I plan to do this in the following way:
git svn clone -r $REVISION_TO_START_WITH http://domain.tld/path/to/svn
git remote add origin ssh://user@gitserver.tld/mirror.git
git push
Now, from time to time, I want to update with
git svn rebase
git push
I hope, so far I'm on the right way.
But what happens if, for some reason, my local repository gets lost?
How to reconnect GIT and SVN so I'm able to mirror, again?
Is the first step to clone the GIT repository and then, somehow, get the SVN
connected, again, or do I have to do it the other way around?
Yours
Manuel
^ permalink raw reply
* Re: [PATCH v2 3/3] git-p4: Add test case for complex branch import
From: Pete Wyckoff @ 2012-01-21 17:11 UTC (permalink / raw)
To: Luke Diamand; +Cc: Junio C Hamano, Vitor Antunes, git
In-Reply-To: <4F1A98A3.2090607@diamand.org>
luke@diamand.org wrote on Sat, 21 Jan 2012 10:51 +0000:
> On 21/01/12 04:54, Junio C Hamano wrote:
> >Vitor Antunes<vitor.hda@gmail.com> writes:
> >
> >>+ grep -q update file2&&
> >
> >Do you really need to use "-q" here? Wouldn't it help if you wrote it
> >without it while debugging tests with "sh ./t9801-*.sh -v"?
> >
> >Also how does this series interact with the series Luke posted earlier on
> >branches and labels?
>
> Vitor's series applies cleanly to my changes.
>
> However, one thing I noticed in reading through is that it will
> break if you end up importing a P4 branch that has spaces (or other
> shell chars) in its name. A quick test confirms this.
>
> - the code doesn't handle the names properly
> - git and p4 have different ideas about valid branch names
>
> But before rejecting Vitor's changes because of that it would be
> worth considering whether we care (much). My own opinion is that if
> you have developers who are daft enough to put spaces or dollars in
> their branch names then their project is already doomed anyway....
>
> Perhaps it would be enough just to issue a warning ("your project is
> doomed; start working on your CV") and skip such branch names rather
> than falling over with inexplicable error messages.
This doesn't seem like a big deal. The read_pipe and
read_pipe_lines calls shoud be list-ified. That gets rid
of the problem with shell interactions.
For git branch name reserved characters, a little function
to replace the bogus characters with "_" would avoid needing
to go work on the resume. Anything in bad_ref_char() and
check_refname_component(). I agree this doesn't have to be
perfect.
This could be a new patch unrelated to Vitor's series, which
verifies branch names anywhere a new commit is made.
-- Pete
^ 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