* [PATCH v3 2/3] git-p4: Add test case for complex branch import
From: Vitor Antunes @ 2012-01-25 23:48 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand, Vitor Antunes
In-Reply-To: <1327535304-11332-1-git-send-email-vitor.hda@gmail.com>
Check if branches created from old changelists are correctly imported.
Also included some updates to simple branch test so that both are
coherent in respect to each other.
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
t/t9801-git-p4-branch.sh | 94 ++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 87 insertions(+), 7 deletions(-)
diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
index a25f18d..6ff713b 100755
--- a/t/t9801-git-p4-branch.sh
+++ b/t/t9801-git-p4-branch.sh
@@ -172,9 +172,9 @@ test_expect_success 'add simple p4 branches' '
echo file1 >file1 &&
echo file2 >file2 &&
p4 add file1 file2 &&
- p4 submit -d "branch1" &&
+ p4 submit -d "Create branch1" &&
p4 integrate //depot/branch1/... //depot/branch2/... &&
- p4 submit -d "branch2" &&
+ p4 submit -d "Integrate branch2 from branch1" &&
echo file3 >file3 &&
p4 add file3 &&
p4 submit -d "add file3 in branch1" &&
@@ -182,7 +182,7 @@ test_expect_success 'add simple p4 branches' '
echo update >>file2 &&
p4 submit -d "update file2 in branch1" &&
p4 integrate //depot/branch1/... //depot/branch3/... &&
- p4 submit -d "branch3"
+ p4 submit -d "Integrate branch3 from branch1"
)
'
@@ -203,17 +203,17 @@ test_expect_success 'git-p4 clone simple branches' '
test -f file1 &&
test -f file2 &&
test -f file3 &&
- grep -q update file2 &&
+ grep update file2 &&
git reset --hard p4/depot/branch2 &&
test -f file1 &&
test -f file2 &&
test ! -f file3 &&
- test_must_fail grep -q update file2 &&
+ test_must_fail grep update file2 &&
git reset --hard p4/depot/branch3 &&
test -f file1 &&
test -f file2 &&
test -f file3 &&
- grep -q update file2 &&
+ grep update file2 &&
cd "$cli" &&
cd branch1 &&
p4 edit file2 &&
@@ -222,7 +222,87 @@ test_expect_success 'git-p4 clone simple branches' '
cd "$git" &&
git reset --hard p4/depot/branch1 &&
"$GITP4" rebase &&
- grep -q file2_ file2
+ grep file2_ file2
+ )
+'
+
+# 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 "Integrate branch4 from branch1@${changelist}" &&
+ changelist=$(($changelist + 2)) &&
+ p4 integrate //depot/branch1/...@$changelist //depot/branch5/... &&
+ p4 submit -d "Integrate branch5 from branch1@${changelist}"
+ )
+'
+
+# 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 update file2 &&
+ git reset --hard p4/depot/branch2 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_missing file3 &&
+ test_must_fail grep update file2 &&
+ git reset --hard p4/depot/branch3 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_file file3 &&
+ grep update file2 &&
+ git reset --hard p4/depot/branch4 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_missing file3 &&
+ test_must_fail grep update file2 &&
+ git reset --hard p4/depot/branch5 &&
+ test_path_is_file file1 &&
+ test_path_is_file file2 &&
+ test_path_is_file file3 &&
+ test_must_fail grep update file2 &&
+ test_path_is_missing .git/git-p4-tmp
)
'
--
1.7.8.3
^ permalink raw reply related
* [PATCH v3 1/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-25 23:48 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand, Vitor Antunes
In-Reply-To: <1327535304-11332-1-git-send-email-vitor.hda@gmail.com>
To find out which is its parent the commit of the new branch is compared
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 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 | 46 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 45 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3e1aa27..584cc41 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
@@ -1450,6 +1452,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]
@@ -1948,6 +1958,20 @@ class P4Sync(Command, P4UserMap):
self.importChanges(changes)
return True
+ def searchParent(self, parent, branch, target):
+ parentFound = False
+ for blob in read_pipe_lines(["git", "rev-list", "--reverse", "--no-merges", parent]):
+ blob = blob.strip()
+ if len(read_pipe(["git", "diff-tree", blob, target])) == 0:
+ parentFound = True
+ if self.verbose:
+ print "Found parent of %s in commit %s" % (branch, blob)
+ break
+ if parentFound:
+ return blob
+ else:
+ return None
+
def importChanges(self, changes):
cnt = 1
for change in changes:
@@ -2004,7 +2028,21 @@ class P4Sync(Command, P4UserMap):
parent = self.initialParents[branch]
del self.initialParents[branch]
- self.commit(description, filesForCommit, branch, [branchPrefix], parent)
+ blob = None
+ 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()
+ blob = self.searchParent(parent, branch, tempBranch)
+ if blob:
+ 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,
@@ -2339,6 +2377,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.8.3
^ permalink raw reply related
* [PATCH v3 3/3] git-p4: Change p4 command invocation
From: Vitor Antunes @ 2012-01-25 23:48 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand, Vitor Antunes
In-Reply-To: <1327535304-11332-1-git-send-email-vitor.hda@gmail.com>
From: Pete Wyckoff <pw@padd.com>
Change p4 command invocation to avoid going through the shell. This
allows names with spaces and wildcards to work.
Signed-off-by: Pete Wyckoff <pw@padd.com>
Signed-off-by: Vitor Antunes <vitor.hda@gmail.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 584cc41..74d3613 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1975,7 +1975,7 @@ class P4Sync(Command, P4UserMap):
def importChanges(self, changes):
cnt = 1
for change in changes:
- description = p4Cmd("describe %s" % change)
+ description = p4Cmd(["describe", str(change)])
self.updateOptionDict(description)
if not self.silent:
--
1.7.8.3
^ permalink raw reply related
* [PATCH v3 0/3] git-p4: Search for parent commit on branch creation
From: Vitor Antunes @ 2012-01-25 23:48 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand, Vitor Antunes
I think this will, hopefully, be the final version of this series of
patches. This version includes the following changes since v2:
- Move search algorithm into its own function.
- Use lists instead of strings on shell commands.
- Some small (almost cosmetic) updates to test cases.
Pete Wyckoff (1):
git-p4: Change p4 command invocation
Vitor Antunes (2):
git-p4: Search for parent commit on branch creation
git-p4: Add test case for complex branch import
contrib/fast-import/git-p4 | 48 +++++++++++++++++++++-
t/t9801-git-p4-branch.sh | 94 ++++++++++++++++++++++++++++++++++++++++---
2 files changed, 133 insertions(+), 9 deletions(-)
--
1.7.8.3
^ permalink raw reply
* Re: [PATCH 5/5] run-command: Error out if interpreter not found
From: Frans Klaver @ 2012-01-25 23:09 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jonathan Nieder, git, Junio C. Hamano
In-Reply-To: <4F205028.4060606@kdbg.org>
On Wed, 25 Jan 2012 19:55:36 +0100, Johannes Sixt <j6t@kdbg.org> wrote:
>> I guess it could use similar code to this patch series to tackle
>> all this.
>
> No thanks. IMHO, this is already too much code for too little gain.
That's OK. If it's not only you who feels this way, I'd better spend my
time on something that does add value.
Thanks for having a look in any case.
Frans
^ permalink raw reply
* Re: [PATCH 3/5] run-command: Elaborate execvp error checking
From: Frans Klaver @ 2012-01-25 22:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C. Hamano, Jonathan Nieder
In-Reply-To: <4F205212.5080007@kdbg.org>
On Wed, 25 Jan 2012 20:03:46 +0100, Johannes Sixt <j6t@kdbg.org> wrote:
> Am 24.01.2012 23:32, schrieb Frans Klaver:
>> +static void inspect_failure(const char *argv0, int silent_exec_failure)
>> +{
>> + int err = errno;
>> + struct strbuf sb = STRBUF_INIT;
>> +
>> + /* errors not related to path */
>> + if (errno == E2BIG || errno == ENOMEM)
>> + die_file_error(argv0, err);
>> +
>> + if (strchr(argv0, '/')) {
>> + if (file_exists(argv0)) {
>> + strbuf_add(&sb, argv0, strlen(argv0));
>> + inspect_file(&sb, err, argv0);
>
> Can we end up here if errno == ENOENT? If so, silent_exec_failure must
> be checked. (inspect_file does not return.)
Hm, good catch. Yes, we can if the interpreter isn't found. I never
intended to actually leave the "interpreter not found" ENOENT case in it's
current shape, so it probably slipped through. Will fix inspect_failure
here to guarantee silent_exec_failure is heeded. Patch 5/5 would probably
remove it again.
Thanks.
^ permalink raw reply
* Re: [PATCH 3/5] run-command: Elaborate execvp error checking
From: Frans Klaver @ 2012-01-25 22:48 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git, Junio C. Hamano, Johannes Sixt
In-Reply-To: <20120125192222.GH1824@burratino>
On Wed, 25 Jan 2012 20:22:22 +0100, Jonathan Nieder <jrnieder@gmail.com>
wrote:
> Frans Klaver wrote:
>> Jonathan Nieder wrote:
>
>>> Could you give an example?
>>
>> The case that triggered me to work on this. I had an incorrect entry
>> in my PATH and some aliasing tests failed. The generated command
>> output was something like
>>
>> fatal: script: Access Denied
>
> Sorry for the lack of clarity. I meant that a (precise) "before and
> after" example could make the commit message a lot easier to
> understand.
Ah I see. I'll add something along those lines.
> [...]
>>> What happens on Windows?
>>
>> I haven't changed anything on the windows side, so that probably
>> sticks to the old behavior.
>
> This was mostly a comment on the change description --- unless I look
> at the patch, if I try this out on Windows after reading the changelog
> I would end up utterly confused. For patch 5/5, it also brings up
> worries about consistency --- if systems are going to be relying on a
> missing #! interpreter being treated differently from a missing script
> for the sake of silent_exec_failure, do the same considerations apply
> on Windows, too?
I'm actually not sure if scripts would be relying on this. There is of
course a good chance that people actually will rely on it, regardless of
what we think. If there are consistency concerns on different platforms
I'd probably have to work on that as well. Mentioning that windows isn't
affected by these changes would be a start though.
> Perhaps it's more along the lines of "this is not supposed to happen
> in practice, and when it does, humans will find it easier to debug if
> we error out hard instead of falling back to the 'if the command does
> not exist' behavior (e.g., by trying an alias next)". In other words,
> maybe this is intended as an optional nicety rather than something
> scripts would ever rely on.
Exactly. My concern was primarily the human interaction, so getting at
least some pointer to the cause of the error. Would that be nice to have
on windows as well? It probably would.
^ permalink raw reply
* Re: git version not changed after installing new version
From: Carlos Martín Nieto @ 2012-01-25 22:29 UTC (permalink / raw)
To: freefly; +Cc: git
In-Reply-To: <loom.20120125T211638-609@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 695 bytes --]
On Wed, 2012-01-25 at 20:20 +0000, freefly wrote:
> > Please don't cull the CC list. It's customary in the git ML to send a
> > copy of the message to each participant.
> >
>
> > There you go then. That should get set in ~/.bashrc so edit that file to
> > change the order.
> >
> > cmn
>
> I didn't the rules about ML and culling some of them
> have guidelines to reduce the noise.
> So you want me to edit the ~/.bashrc
> and put change the order of those paths ?
With the places you've installed git in, that's what you need to do. You
need to tell your shell to look at /usr/local/bin before /usr/bin,
otherwise it won't use your locally-installed git.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* [PATCH] docs: minor grammar fixes for v1.7.9 release notes
From: Jeff King @ 2012-01-25 22:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Jeff King <peff@peff.net>
---
Easier to view with --color-words, of course.
I also looked through "git log --first-parent v1.7.8..master" to see if
anything had been missed. I think you hit the feature highlights pretty
well (I notice you mostly include features and not bug-fixes, which I
assume is to keep the list to a readable length).
Documentation/RelNotes/1.7.9.txt | 13 +++++++------
1 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/Documentation/RelNotes/1.7.9.txt b/Documentation/RelNotes/1.7.9.txt
index f1294b4..95320aa 100644
--- a/Documentation/RelNotes/1.7.9.txt
+++ b/Documentation/RelNotes/1.7.9.txt
@@ -12,19 +12,20 @@ Updates since v1.7.8
* Git uses gettext to translate its most common interface messages
into the user's language if translations are available and the
- locale is appropriately set. Distributors can drop in new PO files
+ locale is appropriately set. Distributors can drop new PO files
in po/ to add new translations.
- * The code to handle username/password for HTTP transaction used in
+ * The code to handle username/password for HTTP transactions used in
"git push" & "git fetch" learned to talk "credential API" to
external programs to cache or store them, to allow integration with
platform native keychain mechanisms.
- * The prompted input in the terminal use our own getpass() replacement
- when possible. HTTP transactions used to ask username without echoing
- back what was typed, but with this change you will see it as you type.
+ * The input prompts in the terminal use our own getpass() replacement
+ when possible. HTTP transactions used to ask for the username without
+ echoing back what was typed, but with this change you will see it as
+ you type.
- * The internal of "revert/cherry-pick" has been tweaked to prepare
+ * The internals of "revert/cherry-pick" have been tweaked to prepare
building more generic "sequencer" on top of the implementation that
drives them.
--
1.7.9.rc2.293.gaae2
^ permalink raw reply related
* Re: [PATCH] git-completion: workaround zsh COMPREPLY bug
From: Matthieu Moy @ 2012-01-25 22:02 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git, gitster
In-Reply-To: <CAMP44s16L0GJUh4JcQgjBXUf4ftT7yQFgPy0p6zCNMnZjZGQww@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
>>> + typeset -h IFS
>>
>> No time to test right now, but is this not going to
>>
>> 1) leave IFS as hidden even outside the completion script, possibly
>> affecting unrelated scripts that would need to set IFS as local and keep
>> its special effect?
>
> What special effect?
>
> Unrelated scripts can still set IFS as local.
OK, I missed the fact that typeset -h had only local effect.
>> 2) break cases where strings are to be split on \n only (e.g. see
>> "foo bar\nboz" as three possible completions "foo", "bar", "boz" instead
>> of "foo bar" and "boz"?
>
> Those cases are already broken, which is what I reported to the zsh
> mailing list. You would get "foo\ bar" and "boz", and that's after
> 4.3.12; before, compgen -W would still break the completions in 3,
> because they did 'results+=( $words )', instead of 'results+=(
> "$words" )'.
Makes sense.
I still have a minor comment: maybe part of your commit message could go
to a comment in the code as well, in particular the "Once zsh is fixed"
part, to help future contributors to actually disable the workaround
when possible in the future.
Tested-by: Matthieu Moy <Matthieu.Moy@imag.fr>
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] Don't search files with an unset "grep" attribute
From: Jeff King @ 2012-01-25 21:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Conrad Irwin, git, Nguyen Thai Ngoc Duy, Dov Grobgeld
In-Reply-To: <7vaa5d4mce.fsf@alter.siamese.dyndns.org>
On Mon, Jan 23, 2012 at 10:59:45PM -0800, Junio C Hamano wrote:
> Conrad Irwin <conrad.irwin@gmail.com> writes:
> > I used to use this approach, hooking into the "diff" attribute directly to mark
> > a file as binary, however that was clearly a hack.
>
> After thinking about this a bit more, I have to say I disagree that it is
> a hack.
I kind of agree.
The biggest problem is that the name is wrong. The "diff.*.command"
option really is about generating a diff between two blobs of a certain
type. But "diff.*.textconv" and "diff.*.binary" are really just
attributes of the file, and may or may not have to do with generating a
diff. Ditto for diff.*.funcname, I think.
You argue, and I agree, that if we are talking about attributes of the
files and not diff-specific things, then other parts of git can and
should make use of that information.
So if this was all spelled:
$ cat .gitattributes
*.pdf filetype=pdf
$ cat .git/config
[filetype "pdf"]
binary = true
textconv = pdf2txt
I think it would be a no-brainer that those type attributes should apply
to "git grep".
So maybe the first step on this path would be to introduce something
like "filetype" as a new attribute, have "diff" respect its settings,
and recommend people set up filetypes as appropriate. Or maybe that just
makes things more confusing in the long run, and we are better off
simply accepting that the name is slightly misleading. But either way,
it seems clear that git should be respecting gitattributes at the very
least to mark files as binary (and I think we already use funcname
patterns; textconv is a slightly stickier subject, so I'll address that
below).
But what I'm not sure I agree with is that the idea of "I don't want to
include path X in my grep" maps to "just mark the file as binary". For
example, in git we carry around a lot of code in compat/ that comes from
other places. I generally don't want to see grep results from
compat/nedmalloc/, because that isn't git code.
But should I mark everything in compat/nedmalloc as binary? I don't
think so. I _do_ want to see changes in nedmalloc in "git log" or "git
diff". They don't bother me because they're infrequent, and we still
want to produce regular text patches for the list when they come up. But
because nedmalloc contains a lot of lines of code (even though they
don't change a lot), it happens to produce a lot of uninteresting
matches when grepping.
> - The user has flexibility to set "diff" and "grep" independently, which
> is an unnecessary complication [*1*]; and
In the nedmalloc case, if we are to have "grep" and "diff" attributes
that behave similarly, you potentially do want to set them differently.
It would be nice to be able to treat them differently in the cases you
wanted to, but not _have_ to do so. Attribute macros can almost
implement this. You could add "-grep" to binary. But you can't (as far
as I know) do "macro=foo" to handle arbitrary diff drivers. I suspect we
could extend the rules to allow macros that take an argument and pass it
to their constituent attributes.
However, I think this is the wrong road to go down. You would want
macros like this _if_ you have grep and diff attributes that basically
do the same thing (e.g., marking a file as binary for diff versus binary
for grep). But I think that's a wrong road to go down. More likely a
file is binary or it is not binary, and the problem is conflating "file
is binary" with "I do not usually want to grep this file".
I'd much rather see grep inherit diff's file attributes unconditionally
(whether we still call them "diff" or not), and add a grep attribute
that is about "usually this is worth grepping". And then have a
tri-state command-line option for grep to either include uninteresting
things, exclude them, or to give terse output for them (mention that
there were matches in foo.c, but not each one). Probably defaulting to
terse output.
That makes the case you presented work out of the box: things marked as
binary for diffing look binary to grep, and we give the usual terse
"binary file matches" output. The user doesn't have to do anything. For
more complex cases like nedmalloc, you can still achieve the "this is
text, but it's usually boring" behavior. And if you really want to do a
thorough grep, you can just "git grep --exclude=none".
> So let's step back a bit and take a look at the handling of files for
> which you do not want to see patch output and/or you do not want to see
> grep hits, in a fictional but realisitic use scenario.
> [...]
I think this is a nice user story, and it fits in with your suggested
git behavior. But I think there are other stories, too, like the
nedmalloc one. And it would be nice to make them work without hurting
the simplicity of the case you mentioned.
> If you think about it this way from the very high level description of the
> problem, aka, end user's point of view, it is fairly clear that tying the
> "binary" attribute to "git grep" to allow us to override the built-in
> buffer_is_binary() call you see in grep.c gives the most intuitive result,
> without forcing the user to do anything more than they are already doing.
This is not a complaint about the core of your point, but rather an
aside that should be considered: how many people are really using the
binary macro attribute? Personally, I never use it, because when I mark
something with a "diff" attribute, it is because I am telling git about
a specific diff driver (usually textconv). Otherwise I don't bother
setting attributes at all, because git's binary detection tends to be
good. This leaves me without setting "-text", of course, but I don't
generally care because I don't do CRLF conversion at all.
So I think it is worth considering not just people setting "binary", but
how users of just "diff" (both "-diff" and "diff=foo") will want things
to work.
> Suppose that this binary blob firmware came with an API manual formatted
> in PDF, xyzzy.pdf, also supplied by the vendor. It is also kept in the
> repository, but again, running textual diff between updated versions of
> the PDF documentation would not be very useful. I however may have a
> textconv filter defined for it to grab the text by running pdf2ascii.
>
> Now if my "git show --textconv xyzzy.pdf" has an output line that says a
> string "XYZZY API 2.0" was added to the current version, wouldn't it be
> natural for me to expect that "git grep --textconv 'XYZZY API' xyzzy.pdf"
> to find it [*4*]?
This is an interesting concept. As a user of textconv, I already have
some specialized grep tools for matching inside binary files (e.g., I
have a tool that greps within exif tags of images). But being able to do
so with "git grep", and even at an arbitrary revision, is kind of neat.
I would worry about turning it on by default, since the results could be
misleading. In particular, your pattern "foo" might be in the binary
file but not in the textconv'd version, leading you to think you had
found all instances of "foo" but had not (or much more subtle, things
like line breaks really matter during the conversion if you are going to
be using "grep -C").
Making it available by "--textconv" seems reasonable to me, though. The
only inconsistency is that it's on by default for "git show", but would
not be for "git grep".
Perhaps I am being overly paranoid on the "misleading" bit above. It
seems to me that grep has the room to be a lot more subtle, because an
omission from the output is considered "did not match". But you could
construct equally weird scenarios for "git show" (e.g., you changed
"foo" to "bar" but that part did not appear in the textconv portion.
Which is really a quality-of-implementation issue for your textconv
filter).
> As an added bonus, if you truly want to omit _any_ hit from "git grep" for
> your minified.js files, you can easily do so. Just define a textconv
> filter that yields an empty string for them, and "grep --textconv" won't
> produce any matches, not even "Binary file ... matches".
Clever. But then you will never ever see a diff for that file, either,
because we will consider all changes to be empty (actually, I didn't
check, but you may get the diff header without any content, similar to
the stat-dirty entries).
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] Git 1.7.9.rc2
From: fREW Schmidt @ 2012-01-25 21:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v39b53r8w.fsf@alter.siamese.dyndns.org>
On Tue, Jan 24, 2012 at 12:11 PM, Junio C Hamano <gitster@pobox.com> wrote:
> fREW Schmidt <frioux@gmail.com> writes:
>
>> On Wed, Jan 18, 2012 at 7:16 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>> * gitk updates accumulated since early 2011.
>>
>> Where might one go to find more detail on this one?
>
> Hmm, http://git.kernel.org/?p=git/git.git;a=shortlog, perhaps?
Ah, I actually looked there before but for some reason didn't see the
latest merge. If anyone else cares:
$ git log v1.7.9-rc2 ^v1.7.8 -- gitk-git/
commit 09bb4eb4f14c0b92baa649b2b97cda2390b84b84
Merge: 10f4eb6 811c70f
Author: Junio C Hamano <gitster@pobox.com>
Date: Fri Dec 16 22:18:42 2011 -0800
Merge git://ozlabs.org/~paulus/gitk
* git://ozlabs.org/~paulus/gitk:
gitk: Make vi-style keybindings more vi-like
gitk: Make "touching paths" search support backslashes
gitk: Show modified files with separate work tree
gitk: Simplify calculation of gitdir
gitk: Run 'git rev-parse --git-dir' only once
gitk: Put temporary directory inside .git
gitk: Fix "External diff" with separate work tree
gitk: Fix "blame parent commit" with separate work tree
gitk: Fix "show origin of this line" with separate work tree
gitk: Fix file highlight when run in subdirectory
gitk: Update copyright
gitk: When a commit contains a note, mark it with a yellow box
gitk: Remember time zones from author and commit timestamps
gitk: Remove unused $cdate array
--
fREW Schmidt
http://blog.afoolishmanifesto.com
^ permalink raw reply
* Re: git version not changed after installing new version
From: freefly @ 2012-01-25 20:23 UTC (permalink / raw)
To: git
In-Reply-To: <1327521489.31804.85.camel@centaur.lab.cmartin.tk>
Sorry about the last post, I had to prune some things from the message,
because when I was trying to post it just keep telling me that
I have more quoted text than what I have written :(
^ permalink raw reply
* Re: git version not changed after installing new version
From: freefly @ 2012-01-25 20:20 UTC (permalink / raw)
To: git
In-Reply-To: <1327521489.31804.85.camel@centaur.lab.cmartin.tk>
> Please don't cull the CC list. It's customary in the git ML to send a
> copy of the message to each participant.
>
> There you go then. That should get set in ~/.bashrc so edit that file to
> change the order.
>
> cmn
I didn't the rules about ML and culling some of them
have guidelines to reduce the noise.
So you want me to edit the ~/.bashrc
and put change the order of those paths ?
^ permalink raw reply
* Re: git version not changed after installing new version
From: Carlos Martín Nieto @ 2012-01-25 19:58 UTC (permalink / raw)
To: freefly; +Cc: git
In-Reply-To: <loom.20120125T202642-92@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 870 bytes --]
Please don't cull the CC list. It's customary in the git ML to send a
copy of the message to each participant.
On Wed, 2012-01-25 at 19:32 +0000, freefly wrote:
>
> > What do `which git` and `type git` say? Bash remembers where it ran a
> > command so if you install a binary to a new location, it might not find
> > it straight away.
>
> which git => /usr/bin/git
>
> type git => git is hashed (/usr/bin/git)
>
> > So the script detected that no change was needed presumably. What's your
> > $PATH and is /usr/local/bin/ before /usr/bin/?
>
> echo $PATH => /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:
> /usr/X11/bin:/usr/local/git/bin:/opt/local/bin
>
> from the above output it is not before /usr/bin :(
There you go then. That should get set in ~/.bashrc so edit that file to
change the order.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: git version not changed after installing new version
From: freefly @ 2012-01-25 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <1327517841.31804.75.camel@centaur.lab.cmartin.tk>
> What do `which git` and `type git` say? Bash remembers where it ran a
> command so if you install a binary to a new location, it might not find
> it straight away.
which git => /usr/bin/git
type git => git is hashed (/usr/bin/git)
> So the script detected that no change was needed presumably. What's your
> $PATH and is /usr/local/bin/ before /usr/bin/?
echo $PATH => /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:
/usr/X11/bin:/usr/local/git/bin:/opt/local/bin
from the above output it is not before /usr/bin :(
^ permalink raw reply
* Re: [PATCH 3/5] run-command: Elaborate execvp error checking
From: Jonathan Nieder @ 2012-01-25 19:22 UTC (permalink / raw)
To: Frans Klaver; +Cc: git, Junio C. Hamano, Johannes Sixt
In-Reply-To: <op.v8motzak0aolir@keputer>
Frans Klaver wrote:
> Jonathan Nieder wrote:
>> Could you give an example?
>
> The case that triggered me to work on this. I had an incorrect entry
> in my PATH and some aliasing tests failed. The generated command
> output was something like
>
> fatal: script: Access Denied
Sorry for the lack of clarity. I meant that a (precise) "before and
after" example could make the commit message a lot easier to
understand.
[...]
>> What happens on Windows?
>
> I haven't changed anything on the windows side, so that probably
> sticks to the old behavior.
This was mostly a comment on the change description --- unless I look
at the patch, if I try this out on Windows after reading the changelog
I would end up utterly confused. For patch 5/5, it also brings up
worries about consistency --- if systems are going to be relying on a
missing #! interpreter being treated differently from a missing script
for the sake of silent_exec_failure, do the same considerations apply
on Windows, too?
Perhaps it's more along the lines of "this is not supposed to happen
in practice, and when it does, humans will find it easier to debug if
we error out hard instead of falling back to the 'if the command does
not exist' behavior (e.g., by trying an alias next)". In other words,
maybe this is intended as an optional nicety rather than something
scripts would ever rely on.
Jonathan
^ permalink raw reply
* Re: Git svn migration does not work because fatal git checkout updating paths is incompatible with switching branches
From: Carlos Martín Nieto @ 2012-01-25 19:09 UTC (permalink / raw)
To: Christine Bauers; +Cc: git
In-Reply-To: <4F20442A.1080005@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 3117 bytes --]
On Wed, 2012-01-25 at 19:04 +0100, Christine Bauers wrote:
> Hi there,
>
> I´m trying to migrate a repository from svn to git which branches and
> tags with the following migration script:
>
> git svn clone --no-metadata --stdlayout --A ../users.txt
> svn://host/svn/project/subproject subproject
>
> cd subproject
> git config svn.authorsfile ../../users.txt
> git svn fetch
>
> git checkout -b branch1 remotes/branch1
> git checkout -b branch2 remotes/branch2
> git checkout -b branch3 remotes/branch3
>
> git checkout -b src_v1 remotes/tags/src
> git checkout master
> git tag src src_v1
> git branch -D src_v1
>
> git checkout -b WebContent_v1 remotes/tags/WebContent
> git checkout master
> git tag WebContent WebContent_v1
> git branch -D WebContent_v1
>
> and get the follwoing errors:
>
> W: Ignoring error from SVN, path probably does not exist: (160013):
> Filesystem has no item: Datei nicht gefunden: Revision 8966, Pfad
> »subproject«
> W: Do not be alarmed at the above message git-svn is just searching
> aggressively for old history.
> This may take a while on large repositories
> fatal: git checkout: updating paths is incompatible with switching branches.
> Did you intend to checkout 'remotes/branch1' which can not be resolved
> as commit?
> fatal: git checkout: updating paths is incompatible with switching branches.
> Did you intend to checkout 'remotes/branch2 which can not be resolved as
> commit?
> fatal: git checkout: updating paths is incompatible with switching branches.
> Did you intend to checkout 'remotes/branch3' which can not be resolved
> as commit?
> fatal: git checkout: updating paths is incompatible with switching branches.
> Did you intend to checkout 'remotes/tags/src' which can not be resolved
> as commit?
> error: pathspec 'master' did not match any file(s) known to git.
> fatal: Failed to resolve 'src_v1' as a valid ref.
> error: branch 'src_v1' not found.
> fatal: git checkout: updating paths is incompatible with switching branches.
> Did you intend to checkout 'remotes/tags/WebContent' which can not be
> resolved as commit?
> error: pathspec 'master' did not match any file(s) known to git.
> fatal: Failed to resolve 'WebContent_v1' as a valid ref.
> error: branch 'WebContent_v1' not found.
>
> How do I solve this problem?
First try to figure out where the problem happens. It could be that
git-svn isn't recognising the branches properly, or that the layout
isn't what it expects or any number of things.
What layout does the repo have? Does it correspond to what git-svn is
expecting? All those error messages come from the fact that you're
telling git some starting points that it can't find. Make sure those
exist and they have the name you're giving. What does `git branch -a`
say? You're presumably not giving us the real names, so we can't tell if
there are problems there.
If you're looking to migrate completely, something like
svn-dump-fast-export ( https://github.com/barrbrain/svn-dump-fast-export
) might get you there better.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 3/5] run-command: Elaborate execvp error checking
From: Johannes Sixt @ 2012-01-25 19:03 UTC (permalink / raw)
To: Frans Klaver; +Cc: git, Junio C. Hamano, Jonathan Nieder
In-Reply-To: <1327444346-6243-4-git-send-email-fransklaver@gmail.com>
Am 24.01.2012 23:32, schrieb Frans Klaver:
> +static void inspect_failure(const char *argv0, int silent_exec_failure)
> +{
> + int err = errno;
> + struct strbuf sb = STRBUF_INIT;
> +
> + /* errors not related to path */
> + if (errno == E2BIG || errno == ENOMEM)
> + die_file_error(argv0, err);
> +
> + if (strchr(argv0, '/')) {
> + if (file_exists(argv0)) {
> + strbuf_add(&sb, argv0, strlen(argv0));
> + inspect_file(&sb, err, argv0);
Can we end up here if errno == ENOENT? If so, silent_exec_failure must
be checked. (inspect_file does not return.)
> + }
> + } else {
> + char *path, *next;
> + path = getenv("PATH");
> + while (path) {
> + next = strchrnul(path, ':');
> + if (path < next)
> + strbuf_add(&sb, path, next - path);
> + else
> + strbuf_addch(&sb, '.');
> +
> + if (!*next)
> + path = NULL;
> + else
> + path = next + 1;
> +
> + if (!is_searchable(sb.buf)) {
> + strbuf_release(&sb);
> + continue;
> + }
> +
> + if (sb.len && sb.buf[sb.len - 1] != '/')
> + strbuf_addch(&sb, '/');
> + strbuf_addstr(&sb, argv0);
> +
> + if (file_exists(sb.buf))
> + inspect_file(&sb, err, argv0);
> +
> + strbuf_release(&sb);
> + }
> + }
> +
> + if (err == ENOENT) {
> + if (!silent_exec_failure)
> + error("cannot exec '%s': %s", argv0,
> + strerror(ENOENT));
> + exit(127);
> + } else {
> + die_file_error(argv0, err);
> + }
> +}
> +#endif
> +
> int start_command(struct child_process *cmd)
> {
> int need_in, need_out, need_err;
> @@ -280,14 +415,7 @@ fail_pipe:
> } else {
> execvp(cmd->argv[0], (char *const*) cmd->argv);
> }
> - if (errno == ENOENT) {
> - if (!cmd->silent_exec_failure)
> - error("cannot run %s: %s", cmd->argv[0],
> - strerror(ENOENT));
> - exit(127);
> - } else {
> - die_errno("cannot exec '%s'", cmd->argv[0]);
> - }
> + inspect_failure(cmd->argv[0], cmd->silent_exec_failure);
Isn't it important that this function calls exit(127) if we want
silent_exec_failure and errno == ENOENT? But I don't see that this
guaranteed by inspect_failure; see above.
> }
> if (cmd->pid < 0)
> error("cannot fork() for %s: %s", cmd->argv[0],
-- Hannes
^ permalink raw reply
* Re: git version not changed after installing new version
From: Carlos Martín Nieto @ 2012-01-25 18:57 UTC (permalink / raw)
To: freefly; +Cc: git
In-Reply-To: <loom.20120125T181639-351@post.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 722 bytes --]
On Wed, 2012-01-25 at 17:19 +0000, freefly wrote:
> Thanks both of you for your replies, I have checked but,
> it still points to the old "/usr/bin/git" not the
> "/usr/local/git/bin" :(
What do `which git` and `type git` say? Bash remembers where it ran a
command so if you install a binary to a new location, it might not find
it straight away.
>
> when I run the update path script I get this output.
>
>
> No change to PATH in ~/.MacOSX/environment.plist
> ~ /Volumes/Git 1.7.8.3 Snow Leopard Intel Universal
> /Volumes/Git 1.7.8.3 Snow Leopard Intel Universal
So the script detected that no change was needed presumably. What's your
$PATH and is /usr/local/bin/ before /usr/bin/?
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: [PATCH 5/5] run-command: Error out if interpreter not found
From: Johannes Sixt @ 2012-01-25 18:55 UTC (permalink / raw)
To: Frans Klaver; +Cc: Jonathan Nieder, git, Junio C. Hamano
In-Reply-To: <op.v8moybu10aolir@keputer>
Am 25.01.2012 08:12, schrieb Frans Klaver:
> On Wed, 25 Jan 2012 00:24:21 +0100, Jonathan Nieder <jrnieder@gmail.com>
>> What happens on Windows?
>
> I didn't plan anything to happen on windows. Doesn't POSIXPERM rule that
> OS out?
It does; these tests are skipped on Windows.
> I guess it could use similar code to this patch series to tackle
> all this.
No thanks. IMHO, this is already too much code for too little gain.
-- Hannes
^ permalink raw reply
* Git svn migration does not work because fatal git checkout updating paths is incompatible with switching branches
From: Christine Bauers @ 2012-01-25 18:04 UTC (permalink / raw)
To: git
Hi there,
I´m trying to migrate a repository from svn to git which branches and
tags with the following migration script:
git svn clone --no-metadata --stdlayout --A ../users.txt
svn://host/svn/project/subproject subproject
cd subproject
git config svn.authorsfile ../../users.txt
git svn fetch
git checkout -b branch1 remotes/branch1
git checkout -b branch2 remotes/branch2
git checkout -b branch3 remotes/branch3
git checkout -b src_v1 remotes/tags/src
git checkout master
git tag src src_v1
git branch -D src_v1
git checkout -b WebContent_v1 remotes/tags/WebContent
git checkout master
git tag WebContent WebContent_v1
git branch -D WebContent_v1
and get the follwoing errors:
W: Ignoring error from SVN, path probably does not exist: (160013):
Filesystem has no item: Datei nicht gefunden: Revision 8966, Pfad
»subproject«
W: Do not be alarmed at the above message git-svn is just searching
aggressively for old history.
This may take a while on large repositories
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'remotes/branch1' which can not be resolved
as commit?
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'remotes/branch2 which can not be resolved as
commit?
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'remotes/branch3' which can not be resolved
as commit?
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'remotes/tags/src' which can not be resolved
as commit?
error: pathspec 'master' did not match any file(s) known to git.
fatal: Failed to resolve 'src_v1' as a valid ref.
error: branch 'src_v1' not found.
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout 'remotes/tags/WebContent' which can not be
resolved as commit?
error: pathspec 'master' did not match any file(s) known to git.
fatal: Failed to resolve 'WebContent_v1' as a valid ref.
error: branch 'WebContent_v1' not found.
How do I solve this problem?
Greetings
Christine
^ permalink raw reply
* Re: git version not changed after installing new version
From: freefly @ 2012-01-25 17:19 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20120125T173801-500@post.gmane.org>
Thanks both of you for your replies, I have checked but,
it still points to the old "/usr/bin/git" not the
"/usr/local/git/bin" :(
when I run the update path script I get this output.
No change to PATH in ~/.MacOSX/environment.plist
~ /Volumes/Git 1.7.8.3 Snow Leopard Intel Universal
/Volumes/Git 1.7.8.3 Snow Leopard Intel Universal
^ permalink raw reply
* Re: git version not changed after installing new version
From: Kirill Likhodedov @ 2012-01-25 16:57 UTC (permalink / raw)
To: freefly; +Cc: git
In-Reply-To: <loom.20120125T173801-500@post.gmane.org>
Most likely, you didn't update the PATH well enough.
Check what is the output of 'which git' command. It will point to the xcode installation. So please double check the path.
25.01.2012, в 20:45, freefly:
> Hi all,
> I am new to Mac OS X lion and I had a previous installation of XCODE 4.2
> on my mac mini. It has a git version 1.7.5.4. I installed a new version 1.7.8.4.
> and updated the Path variables by running the script comes with the
> package as well. but when I type "git --version" in the terminal
> I get 1.7.5.4. Can anyone tell me what is going wrong ?
>
> Kind regards
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git version not changed after installing new version
From: Thomas Rast @ 2012-01-25 17:03 UTC (permalink / raw)
To: freefly; +Cc: git
In-Reply-To: <loom.20120125T173801-500@post.gmane.org>
freefly <free.fly@live.com> writes:
> Hi all,
> I am new to Mac OS X lion and I had a previous installation of XCODE 4.2
> on my mac mini. It has a git version 1.7.5.4. I installed a new version 1.7.8.4.
> and updated the Path variables by running the script comes with the
> package as well. but when I type "git --version" in the terminal
> I get 1.7.5.4. Can anyone tell me what is going wrong ?
Enter 'which git' in a terminal. The 'which' utility looks up which
executable from $PATH will be run if you use 'git' (in this case) as a
command word, i.e., without specifying its path.
This should point to your newly installed git. It probably doesn't, and
you can compare it and your $PATH (try: 'echo "$PATH"' in a terminal) to
see why.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ 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