* Re: [BUG ?] completion of stash name with git stash
From: Thomas Rast @ 2012-01-19 16:18 UTC (permalink / raw)
To: Mathieu CLAVEL; +Cc: git
In-Reply-To: <loom.20120119T141601-606@post.gmane.org>
Mathieu CLAVEL <math.clavel@gmail.com> writes:
> I'm using mysgit 1.7.8 on XP.
>
> I think the stash name completion has a problem.
> I don't know if it's a problem from my system, mysgit or git.
>
> Here are the steps to reproduce (you need to have at least 2 stashed commits).
> '+ tab =>' means using the tab to autocomplete the current command. Left part is
> before completion, right tab is after completion.
>
> $ git stash list
> stash@{0}: WIP on feature/preservation_offres: 7f2c9a8 import.cmd : import par
> lot de 10.000 contrats
> stash@{1}: WIP on feature/echeancier: ddb7bb0 Mockito : 1.8.5 -> 1.9.0
>
> $ git stash drop '+ tab =>' $ git stash drop stash@{
>
> $ git stash drop stash@{0 '+ tab =>' $ git stash drop stashstash@{0}
>
> I don't know if it's relevant, but I also have 'git flow' and 'git flow
> completion' installed, and as said in a previous thread, 'git flow completion'
> isn't working with alias [2].
This works for me using git completion as shipped with v1.7.9-rc2 and
bash 4.2.10. Double-tabbing at 'git stash drop ' prints a list of
stashes as expected. Which bash version are you using?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH 2/2] diff --word-diff: use non-whitespace regex by default
From: Thomas Rast @ 2012-01-19 15:53 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CALUzUxqXTXZv4RE=4rBa79T3_1y7UdqZ6okjC1y-Ve+=NDbQ2g@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On Thu, Jan 12, 2012 at 5:22 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> [snip]
>> Case in point, consider my patch sent out yesterday
>>
>> http://article.gmane.org/gmane.comp.version-control.git/188391
>>
>> It consists of a one-hunk doc update. word-diff is not brilliant:
>>
>> -k::
>> Usually the program [-'cleans up'-]{+removes email cruft from+} the Subject:
>> header line to extract the title line for the commit log
>> [-message,-]
>> [- among which (1) remove 'Re:' or 're:', (2) leading-]
>> [- whitespaces, (3) '[' up to ']', typically '[PATCH]', and-]
>> [- then prepends "[PATCH] ".-]{+message.+} This [-flag forbids-]{+option prevents+} this munging, and is most
>> useful when used to read back 'git format-patch -k' output.
>> [snip the rest as it's only {+}]
>>
>> But character-diff tries too hard to find common subsequences:
>>
>> $ g show HEAD^^ --word-diff-regex='[^[:space:]]' | xsel
>>[snip]
>> w-]{+. T+}hi[-te-]s[-paces, (3) '[' up t-] o[-']', ty-]p[
>>
>> is just line noise? The colors don't even help as most of it is removed
>> (red).
>
> You missed the '+' quantifier, as in
>
> [^[:space:]]+
Did I? I was working from the example you provided earlier
} matrix[a,b,c]
} matrix[d,b,c]
} gives
} matrix[[-a-]{+d+},b,c]
}
} and when we have
}
} ImagineALanguageLikeFoo
} ImagineALanguageLikeBar
} we get
} ImagineALanguageLike[-Foo-]{+Bar+}
Under [^[:space:]]+ neither of the examples would work. Actually,
[^[:space:]]+ is the same as today's default, the [^[:space:]]* I
mentioned later is (strictly speaking) broken as it allows for a
0-length match. (It doesn't really matter because IIRC the engine
ignores 0-length words.)
>> That being said, I can see some arguments for changing the default to
>> split punctuation into a separate word. That is, whereas the current
>> default is semantically equivalent to a wordRegex of
>>
>> [^[:space:]]*
>>
>> (but has a faster code path)
>
> Oh right, there *is* a sensible default implemented in. Somehow I was
> under the impression that there wasn't.
>
> I wonder which is faster, using the non-whitespace regex, or the
> isspace() calls...
I tried measuring it across a few commits, but it mostly gets drowned
out by the diff effort. For a commit with stat
exercises/cgal/cover/cover.cpp | 5 +-
exercises/cgal/cover/cover.in1 |27014 +++++++++++++++-----
exercises/cgal/cover/cover.in2 |48996 +++++++++++++++++++++++------------
exercises/cgal/cover/cover.in3 |55041 +++++++++++++++++++++++++--------------
exercises/cgal/cover/cover.in4 |47600 ++++++++++++++++++++--------------
exercises/cgal/cover/cover.int |43491 ++++++++++++++++++++++---------
exercises/cgal/cover/cover.out1 | 53 +-
exercises/cgal/cover/cover.out2 | 24 +-
exercises/cgal/cover/cover.out3 | 11 +-
exercises/cgal/cover/cover.out4 | 2 +-
exercises/cgal/cover/cover.outt | 23 +-
exercises/cgal/cover/gen | 39 +-
exercises/cgal/cover/gen-1.cpp | 4 +-
exercises/cgal/cover/gen-2.cpp | 6 +-
exercises/cgal/cover/gen-3.cpp | 6 +-
(sorry, can't share as those testcases are secret) I get best-of-5
timings
--word-diff-regex='[^[:space:]]+' 0:07.50real 7.40user 0.07system
--word-diff 0:07.47real 7.41user 0.03system
In conclusion, "meh". I think ripping out the isspace() part would make
for a nice code reduction.
>> and your proposal is equivalent to
>>
>> [^[:space:]]|UTF_8_GUARD
>>
>> I think there is a case to be made for a default of
>>
>> [^[:space:]]|([[:alnum:]]|UTF_8_GUARD)+
>>
>> or some such. There's a lot of bikeshedding lurking in the (non)extent
>> of the [[:alnum:]] here, however.
>
> Care to explain further? Not to sure what you mean here.
For natural language, it may or may not make sense to match numbers as
part of a word.
For typical use in e.g. emails, a lot of punctuation has a double role;
breaking words in
http://article.gmane.org/gmane.comp.version-control.git/188391
may or may not make sense.
For some uses, especially source code, it would be better to match an
underscore _ as part of a complete word, too.
For some programming languages, say lisp, a dash - would also belong in
the same category.
There's no real reason other than ease of implementation why the pattern
handles ASCII non-alphanumerics separately, but non-ASCII UTF-8
non-alnums (like, say, unicode NO-BREAK SPACE which would show as \xc2
\xa0) always goes into a word. But if you were to make UTF-8 sequences
a single word, text in (say) many European languages would become
chunked at accented letters.
I'm sure you can find more items for this list. It's a grey area.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: More support on branch description?
From: Nguyen Thai Ngoc Duy @ 2012-01-19 15:24 UTC (permalink / raw)
To: Michael Schubert; +Cc: Git Mailing List
In-Reply-To: <4F183365.5010607@elegosoft.com>
On Thu, Jan 19, 2012 at 10:14 PM, Michael Schubert <mschub@elegosoft.com> wrote:
> Junio suggested a new option "--verbose-format" for branch some weeks
> ago:
>
> http://thread.gmane.org/gmane.comp.version-control.git/186727
>
> I planned on working on it, but haven't found the time yet nor do I
> really know which way to go.? (pretty.c seems to be the right
> place for format code, but it's very commit format specific atm.)
Thanks. I must have missed that. There's another piece of formatting
code in "for-each-ref --format" command (I happened to have a look at
it a few days ago). It's ref-specific, probably closer than pretty.c
for this kind of stuff.
--
Duy
^ permalink raw reply
* Re: [PATCHv4 0/5] git-p4: small fixes to branches and labels
From: Pete Wyckoff @ 2012-01-19 15:19 UTC (permalink / raw)
To: Luke Diamand; +Cc: git, Vitor Antunes
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
luke@diamand.org wrote on Thu, 19 Jan 2012 09:52 +0000:
> This is the fourth version of some small fixes to git-p4 branch and
> label handling, incorporating a fix from Pete Wyckoff and an
> additional failing test.
>
> This change does not fix the other problems with git-p4 labels:
>
> - two p4 labels on the same changelist will fall over
> - labels must match exactly the list of files imported
> - you can't import a label without a p4 commit
This all looks great to me. Thanks for adding that failing test,
and fixing the pre-existing bug in invoking p4 labels.
-- Pete
^ permalink raw reply
* Re: More support on branch description?
From: Michael Schubert @ 2012-01-19 15:14 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Git Mailing List
In-Reply-To: <CACsJy8D0_EB6jN7KxpzLtnPnj0HjdU6sNHJRyqXJf-2-ZNatFA@mail.gmail.com>
On 01/19/2012 03:14 PM, Nguyen Thai Ngoc Duy wrote:
> The coming v1.7.9 will introduce branch description, mainly used in
> integration process. I think we could make it useful for users who
> don't extensively use request-pull/format-patch. Showing a short
> summary along with branch name in "git branch" would be nice. "branch
> -v" is already used for something else, maybe we can come up with
> another option, or "-v -v"? Another place we could show branch
> description is "git status". What do you think?
Junio suggested a new option "--verbose-format" for branch some weeks
ago:
http://thread.gmane.org/gmane.comp.version-control.git/186727
I planned on working on it, but haven't found the time yet nor do I
really know which way to go.? (pretty.c seems to be the right
place for format code, but it's very commit format specific atm.)
^ permalink raw reply
* Re: diff --minimal as default?
From: Thomas Rast @ 2012-01-19 14:22 UTC (permalink / raw)
To: Victor Engmark; +Cc: git
In-Reply-To: <CAA5Ydx_ZqnaWRK3cEvMkULcrGx8B1MUyi2-Ca8eSBmbDg==fDQ@mail.gmail.com>
Victor Engmark <victor.engmark@gmail.com> writes:
> Git v1.7.8 supports `diff --minimal`. I've got cycles to spare and
> usually small files - Is there (or will there be) a configuration
> option to set this as the default? If not I'll just use an alias, but
> there should still be an inverse option to be able to override it in
> special cases.
AFAIK no config option is planned; you could make a patch :-)
But there's --no-minimal, following the usual pattern for boolean
options.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* More support on branch description?
From: Nguyen Thai Ngoc Duy @ 2012-01-19 14:14 UTC (permalink / raw)
To: Git Mailing List
Hi,
The coming v1.7.9 will introduce branch description, mainly used in
integration process. I think we could make it useful for users who
don't extensively use request-pull/format-patch. Showing a short
summary along with branch name in "git branch" would be nice. "branch
-v" is already used for something else, maybe we can come up with
another option, or "-v -v"? Another place we could show branch
description is "git status". What do you think?
--
Duy
^ permalink raw reply
* diff --minimal as default?
From: Victor Engmark @ 2012-01-19 13:41 UTC (permalink / raw)
To: git
Git v1.7.8 supports `diff --minimal`. I've got cycles to spare and
usually small files - Is there (or will there be) a configuration
option to set this as the default? If not I'll just use an alias, but
there should still be an inverse option to be able to override it in
special cases.
Cheers,
V
^ permalink raw reply
* [BUG ?] completion of stash name with git stash
From: Mathieu CLAVEL @ 2012-01-19 13:21 UTC (permalink / raw)
To: git
Hello,
I first posted that message on the group for msysgit [1].
====
I'm using mysgit 1.7.8 on XP.
I think the stash name completion has a problem.
I don't know if it's a problem from my system, mysgit or git.
Here are the steps to reproduce (you need to have at least 2 stashed commits).
'+ tab =>' means using the tab to autocomplete the current command. Left part is
before completion, right tab is after completion.
$ git stash list
stash@{0}: WIP on feature/preservation_offres: 7f2c9a8 import.cmd : import par
lot de 10.000 contrats
stash@{1}: WIP on feature/echeancier: ddb7bb0 Mockito : 1.8.5 -> 1.9.0
$ git stash drop '+ tab =>' $ git stash drop stash@{
$ git stash drop stash@{0 '+ tab =>' $ git stash drop stashstash@{0}
I don't know if it's relevant, but I also have 'git flow' and 'git flow
completion' installed, and as said in a previous thread, 'git flow completion'
isn't working with alias [2].
====
Regards,
Mathieu CLAVEL
[1] https://groups.google.com/d/topic/msysgit/AgGY7wl8IJQ/discussion
[2] https://groups.google.com/d/msg/msysgit/UnBHlY9eAK0/JfdH7q2hcsAJ
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Thomas Rast @ 2012-01-19 11:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vobu0liwj.fsf@alter.siamese.dyndns.org>
[dropped Dieter as this really goes off on an internal tangent]
Junio C Hamano <gitster@pobox.com> writes:
> If somebody is writing a script using "git add" (which is not recommended
> to begin with)
Can we still stick to that stance? Our tests are increasingly using
'git add' instead of 'git update-index --add':
$ git grep 'git[ -]add' t/ | wc -l
1540
$ git grep 'git[ -]update-index --add' t/ | wc -l
269
$ git grep 'git[ -]update-index --add' v1.6.0 t/ | wc -l
251
$ git grep 'git[ -]add' v1.6.0 t/ | wc -l
705
So while git(1) still says git-add is porcelain (and thus not to be used
for scripting), it has mostly superseded 'git update-index --add' in new
script usage even within git.git. I suspect the same goes for things
like git-rm, git-commit, etc.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] git-add: allow --ignore-missing always, not just in dry run
From: Dieter Plaetinck @ 2012-01-19 10:52 UTC (permalink / raw)
To: Junio C Hamano, Jens Lehmann; +Cc: git
In-Reply-To: <7vobu0liwj.fsf@alter.siamese.dyndns.org>
On Wed, 18 Jan 2012 14:56:12 -0800
Junio C Hamano <gitster@pobox.com> wrote:
> Dieter Plaetinck <dieter@plaetinck.be> writes:
>
> > There is no need to restrict use of --ignore-missing to dry runs,
> > it can be useful to ignore missing files during normal operation as
> > well.
> >
> > Signed-off-by: Dieter Plaetinck <dieter@plaetinck.be>
>
> Sorry, but for this kind of change, we would want to see a
> justification that is much better than that. The default around here
> is not to change an established behaviour without a good reason.
Hello Junio, thanks for your quick and elaborate response.
> Have you dug into the list archive to see _why_ we decided not to
> allow this option in the real run in the first place?
Actually I did, before submitting this patch.
From what I could find, the original patch [1] only cared about having this
feature available in dry run, and came with this "only in dry run" restriction,
merely because it was the only use case considered.
I couldn't find any evidence of this restriction actually being needed nor
any discussion of this matter. I added Jens to this mail, as he wrote
the original patch.
> You would need
> to find "By letting the command ignore missing paths, the user can
> get into X and Y situations and we would want to avoid it. We however
> need to give users a way to see if there is something missing, hence
> we add it when we are under dry-run option." and refute that previous
> justification, arguing why X and Y is something we should _not_ be
> worrying about, to make a good case for this change.
Yes, ignoring missing files can lead to files not actually being added, if they are missing.
But that's why this is an optional flag to needs to explicitly passed.
The flag is clear about what it does, so if users enable it, I don't see the problem?
> If somebody is writing a script using "git add" (which is not
> recommended to begin with), it is tempting to say 'git add
> $list_of_possible_files' in such a script when the script _knows_
> that the list it is giving to "git add" may contain a path that does
> not exist, and wants to ignore missing ones.
>
> But then the script could easily filter what does not exist before
> compiling such a list, so that is not a very strong reason to advocate
> it.
The use case is as follows:
I'm working on a tool [2] which runs in the background, and automatically synchronizes file/directory trees,
by using inotify events, and synchronizing changes in the working tree to the
index automatically, committing automatically and push/pulling automatically.
Basically for when you want to version a tree with git, but without needing to manually
commit all the time. (useful for a directory with notes as text files, for example)
the problem is, you can have a constant stream of inotify events (if files are being
edited/deleted/(re)created all the time), and at the point where my tool decides to automatically commit the changes it just saw,
more changes (deletes, renames, readding a file that was just deleted, ..) can happen around the same time.
So basically, if this tool needs to check which files still/no-longer exist before calling git-add,
that's vulnerable to race conditions.
The only real solution against race conditions is to deal with (ignore) missing files right at the point where git
adds them to the index.
But if "git add" is not the right way, please let me know the alternative.
From what I can find "git add --all --ignore-missing <file>" (with my patch for allowing ignore-missing without dry run) would be the most appropriate,
this would never accidentially modify the working tree (as "git rm" for a deleted file could, if the file gets readded at the same point
where we call git), and it would gracefully handle changes we didn't see yet (such as new/modified files disappearing again)
thanks again for the feedback,
Dieter
[1] http://kerneltrap.org/mailarchive/git/2010/7/9/34077
[2] https://gitorious.org/search?q=dvcs-autosync
^ permalink raw reply
* Re: Interactive rebase with submodules
From: John Keeping @ 2012-01-19 10:48 UTC (permalink / raw)
To: Jens Lehmann; +Cc: git
In-Reply-To: <4F172DBB.4080303@web.de>
On 18/01/12 20:38, Jens Lehmann wrote:
> Am 18.01.2012 12:21, schrieb John Keeping:
>> On 17/01/12 21:29, Jens Lehmann wrote:
>>> Am 17.01.2012 19:47, schrieb John Keeping:
>>>> I can understand not updating submodules while running the rebase, but I expected that having resolved a conflict and added my change to the index it would be applied by `git rebase --continue`, as indeed it is if there happen to be other (non-submodule) changes in the same commit.
>>>
>>> The irony is that you would have to update submodules (or at least
>>> their HEAD and use "--ignore-submodules=dirty") while running rebase
>>> to make that work in all cases ;-)
>>
>> I don't this this is the case, since diff-tree is being invoked with --cached won't it ignore changes in the work tree anyway?
>
> Right, thanks for nudging me with the clue bat ...
>
> I missed the "--cached" option and did not question if the code does
> what the commit message of 6848d58c6 (where the --ignore-submodules
> option was introduced) said:
>
> Ignore dirty submodule states during rebase and stash
>
> When rebasing or stashing, chances are that you do not care about
> dirty submodules, since they are not updated by those actions anyway.
> So ignore the submodules' states.
>
> Note: the submodule states -- as committed in the superproject --
> will still be stashed and rebased, it is _just_ the state of the
> submodule in the working tree which is ignored.
>
> I think this logic misses the case when only submodule changes are left
> in a commit.
Yes, this is precisely the case that doesn't work as I expect.
>>> But just updating the HEAD would be dangerous as you would have to be
>>> very careful to restore the submodules HEAD after the rebase, or the
>>> submodule's work tree will be out of sync.
>>
>> Just updating HEAD in the submodule without touching its work tree doesn't seem like a good idea. I think it will cause a lot more confusion when running `git status` which will show unexpected modified content for the submodule.
>
> Yes, we agree here.
>
>> Since I did not expect rebase to perform a submodule update, I was not surprised to see unstaged submodule changes when rebasing, but I did expect rebase to commit anything I had added to the index.
>
> Right.
>
> I'll have to add some tests for that case, but I doubt I'll manage that
> today. Until I can provide a complete patch, this diff should fix your
> problem (no, I did not test if that change is enough to fix the problem,
> but at least it does not break the test suite ;-):
>
> ---------------8<--------------
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index 5812222..4546749 100644
> --- a/git-rebase--interactive.sh
> +++ b/git-rebase--interactive.sh
> @@ -672,7 +672,7 @@ rearrange_squash () {
> case "$action" in
> continue)
> # do we have anything to commit?
> - if git diff-index --cached --quiet --ignore-submodules HEAD --
> + if git diff-index --cached --quiet HEAD --
> then
> : Nothing to commit -- skip this
> else
This patch does indeed fix the problem I was seeing.
Thanks,
--
John
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Thomas Rast @ 2012-01-19 10:24 UTC (permalink / raw)
To: Yves Goergen
Cc: Holger Hellmuth, Jeff King, Carlos Martín Nieto, git,
Erik Faye-Lund
In-Reply-To: <4F15B65A.8070009@unclassified.de>
Glad that you could fix your repository.
Yves Goergen <nospam.list@unclassified.de> writes:
> Just like that stupid autocrlf that causes more issues than it solves. I
> regularly see files with all lines changed and the diff says that both
> files only differ in line endings. But I have no sure observation on
> whether that value was set or unset in those cases. I'll have to look
> after that, too.
Just please remember what I tried to teach you in this thread: copy and
paste actual command invocations and outputs, and let us do the
interpretation. With CRLF problems, it may in addition help to pipe
through a utility that shows the presence or absence of \r, such as 'cat
-v'.
> These two config settings are not cloned with the repository, are they?
Neither config nor hooks are cloned.
> Also, TortoiseGit already sets ignorecase = true. So maybe the Visual
> Studio provider does the init on its own and is missing that. Or I have
> at some time cloned the repository and the setting wasn't copied over.
git-clone also autodetects the setting as part of initializing the
clone. (Copying over the repository from a case-sensitive medium using
a case-sensitive OS would of course leave it unset.)
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Unexpected "clean -Xd" behavior
From: Jonathan Nieder @ 2012-01-19 10:03 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Pete Harlan, Git Mailing List, Shawn Bohrer
In-Reply-To: <CACsJy8AE+rwmOVUZez5GRXRHJsTy+W8ekzr59NTd7_C+gB0Byw@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> -X is to remove ignored files _only_ (DIR_SHOW_IGNORED flag). And
> "foo" is not ignored according to .gitignore, so it cuts short there
> and never gets to "foo/a". -x works.
Makes sense.
I guess the internal logic is that "git clean -fdX" cleans up files
that "git clean -fd" would miss, and this is not such a file ("git
clean -fd" removes it). But as Pete mentioned, in this edge case the
behavior renders "git clean -fdX" less effective than expected at its
primary task as poor man's "make clean".
I'd be happy to see a patch that moves to a different set of semantics
or an addition to t/t7300-clean.sh and BUGS section in
Documentation/git-clean.txt explaining the current limitations, if
someone wants to work on that.
Thanks, both.
Jonathan
^ permalink raw reply
* [PATCHv4 5/5] git-p4: label import fails with multiple labels at the same changelist
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
git-p4 has an array of changelists with one label per changelist.
But you can have multiple labels on a single changelist and so this
code fails.
Add a test case demonstrating the problem.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9804-git-p4-label.sh | 41 +++++++++++++++++++++++++++++++++++++++++
1 files changed, 41 insertions(+), 0 deletions(-)
diff --git a/t/t9804-git-p4-label.sh b/t/t9804-git-p4-label.sh
index 5fa2bcf..80d01ea 100755
--- a/t/t9804-git-p4-label.sh
+++ b/t/t9804-git-p4-label.sh
@@ -65,6 +65,47 @@ test_expect_success 'basic p4 labels' '
)
'
+# Test some label corner cases:
+#
+# - two tags on the same file; both should be available
+# - a tag that is only on one file; this kind of tag
+# cannot be imported (at least not easily).
+
+test_expect_failure 'two labels on the same changelist' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$cli" &&
+ mkdir -p main &&
+
+ p4 edit main/f1 main/f2 &&
+ echo "hello world" >main/f1 &&
+ echo "not in the tag" >main/f2 &&
+ p4 submit -d "main/f[12]: testing two labels" &&
+
+ p4 tag -l tag_f1_1 main/... &&
+ p4 tag -l tag_f1_2 main/... &&
+
+ p4 labels ... &&
+
+ "$GITP4" clone --dest="$git" --detect-labels //depot@all &&
+ cd "$git" &&
+
+ git tag | grep tag_f1 &&
+ git tag | grep -q tag_f1_1 &&
+ git tag | grep -q tag_f1_2 &&
+
+ cd main &&
+
+ git checkout tag_tag_f1_1 &&
+ ls &&
+ test -f f1 &&
+
+ git checkout tag_tag_f1_2 &&
+ ls &&
+ test -f f1
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 4/5] git-p4: add test for p4 labels
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
Add basic test of p4 label import. Checks label import and
import with shell metachars; labels with different length
descriptions.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
t/t9804-git-p4-label.sh | 72 +++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 72 insertions(+), 0 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
diff --git a/t/t9804-git-p4-label.sh b/t/t9804-git-p4-label.sh
new file mode 100755
index 0000000..5fa2bcf
--- /dev/null
+++ b/t/t9804-git-p4-label.sh
@@ -0,0 +1,72 @@
+test_description='git-p4 p4 label tests'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+# Basic p4 label tests.
+#
+# Note: can't have more than one label per commit - others
+# are silently discarded.
+#
+test_expect_success 'basic p4 labels' '
+ test_when_finished cleanup_git &&
+ (
+ cd "$cli" &&
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ echo f2 >main/f2 &&
+ p4 add main/f2 &&
+ p4 submit -d "main/f2" &&
+
+ echo f3 >main/file_with_\$metachar &&
+ p4 add main/file_with_\$metachar &&
+ p4 submit -d "file with metachar" &&
+
+ p4 tag -l tag_f1_only main/f1 &&
+ p4 tag -l tag_with\$_shell_char main/... &&
+
+ echo f4 >main/f4 &&
+ p4 add main/f4 &&
+ p4 submit -d "main/f4" &&
+
+ p4 label -i <<-EOF &&
+ Label: long_label
+ Description:
+ A Label first line
+ A Label second line
+ View: //depot/...
+ EOF
+
+ p4 tag -l long_label ... &&
+
+ p4 labels ... &&
+
+ "$GITP4" clone --dest="$git" --detect-labels //depot@all &&
+ cd "$git" &&
+
+ git tag &&
+ git tag >taglist &&
+ test_line_count = 3 taglist &&
+
+ cd main &&
+ git checkout tag_tag_f1_only &&
+ ! test -f f2 &&
+ git checkout tag_tag_with\$_shell_char &&
+ test -f f1 && test -f f2 && test -f file_with_\$metachar &&
+
+ git show tag_long_label | grep -q "A Label second line"
+ )
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 3/5] git-p4: importing labels should cope with missing owner
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
In p4, the Owner field is optional. If it is missing,
construct something sensible rather than crashing.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 63 ++++++++++++++++++++++++-------------------
1 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 5b59bc8..58551b9 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -563,6 +563,26 @@ class Command:
class P4UserMap:
def __init__(self):
self.userMapFromPerforceServer = False
+ self.myP4UserId = None
+
+ def p4UserId(self):
+ if self.myP4UserId:
+ return self.myP4UserId
+
+ results = p4CmdList("user -o")
+ for r in results:
+ if r.has_key('User'):
+ self.myP4UserId = r['User']
+ return r['User']
+ die("Could not find your p4 user id")
+
+ def p4UserIsMe(self, p4User):
+ # return True if the given p4 user is actually me
+ me = self.p4UserId()
+ if not p4User or p4User != me:
+ return False
+ else:
+ return True
def getUserCacheFilename(self):
home = os.environ.get("HOME", os.environ.get("USERPROFILE"))
@@ -700,7 +720,6 @@ class P4Submit(Command, P4UserMap):
self.verbose = False
self.preserveUser = gitConfig("git-p4.preserveUser").lower() == "true"
self.isWindows = (platform.system() == "Windows")
- self.myP4UserId = None
def check(self):
if len(p4CmdList("opened ...")) > 0:
@@ -808,25 +827,6 @@ class P4Submit(Command, P4UserMap):
return 1
return 0
- def p4UserId(self):
- if self.myP4UserId:
- return self.myP4UserId
-
- results = p4CmdList("user -o")
- for r in results:
- if r.has_key('User'):
- self.myP4UserId = r['User']
- return r['User']
- die("Could not find your p4 user id")
-
- def p4UserIsMe(self, p4User):
- # return True if the given p4 user is actually me
- me = self.p4UserId()
- if not p4User or p4User != me:
- return False
- else:
- return True
-
def prepareSubmitTemplate(self):
# remove lines in the Files section that show changes to files outside the depot path we're committing into
template = ""
@@ -1675,6 +1675,12 @@ class P4Sync(Command, P4UserMap):
if self.stream_file.has_key('depotFile'):
self.streamOneP4File(self.stream_file, self.stream_contents)
+ def make_email(self, userid):
+ if userid in self.users:
+ return self.users[userid]
+ else:
+ return "%s <a@b>" % userid
+
def commit(self, details, files, branch, branchPrefixes, parent = ""):
epoch = details["time"]
author = details["user"]
@@ -1698,10 +1704,7 @@ class P4Sync(Command, P4UserMap):
committer = ""
if author not in self.users:
self.getUserMapFromPerforceServer()
- if author in self.users:
- committer = "%s %s %s" % (self.users[author], epoch, self.tz)
- else:
- committer = "%s <a@b> %s %s" % (author, epoch, self.tz)
+ committer = "%s %s %s" % (self.make_email(author), epoch, self.tz)
self.gitStream.write("committer %s\n" % committer)
@@ -1746,11 +1749,15 @@ class P4Sync(Command, P4UserMap):
self.gitStream.write("from %s\n" % branch)
owner = labelDetails["Owner"]
- tagger = ""
- if author in self.users:
- tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
+
+ # Try to use the owner of the p4 label, or failing that,
+ # the current p4 user id.
+ if owner:
+ email = self.make_email(owner)
else:
- tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
+ email = self.make_email(self.p4UserId())
+ tagger = "%s %s %s" % (email, epoch, self.tz)
+
self.gitStream.write("tagger %s\n" % tagger)
description = labelDetails["Description"]
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 2/5] git-p4: cope with labels with empty descriptions
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
Use an explicit length for the data in a label, rather
than EOT, so that labels with empty descriptions are
passed through correctly.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 163e95a..5b59bc8 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1752,9 +1752,11 @@ class P4Sync(Command, P4UserMap):
else:
tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
self.gitStream.write("tagger %s\n" % tagger)
- self.gitStream.write("data <<EOT\n")
- self.gitStream.write(labelDetails["Description"])
- self.gitStream.write("EOT\n\n")
+
+ description = labelDetails["Description"]
+ self.gitStream.write("data %d\n" % len(description))
+ self.gitStream.write(description)
+ self.gitStream.write("\n")
else:
if not self.silent:
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 1/5] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
In-Reply-To: <1326966749-9077-1-git-send-email-luke@diamand.org>
Don't use shell expansion when detecting branches, as it will
fail if the branch name contains a shell metachar. Similarly
for labels.
Add additional test for branches with shell metachars.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++---
t/t9803-git-p4-shell-metachars.sh | 48 +++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 5aacea8..163e95a 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -799,7 +799,7 @@ class P4Submit(Command, P4UserMap):
def canChangeChangelists(self):
# check to see if we have p4 admin or super-user permissions, either of
# which are required to modify changelists.
- results = p4CmdList("protects %s" % self.depotPath)
+ results = p4CmdList(["protects", self.depotPath])
for r in results:
if r.has_key('perm'):
if r['perm'] == 'admin':
@@ -1769,7 +1769,7 @@ class P4Sync(Command, P4UserMap):
def getLabels(self):
self.labels = {}
- l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
+ l = p4CmdList(["labels"] + ["%s..." % p for p in self.depotPaths])
if len(l) > 0 and not self.silent:
print "Finding files belonging to labels in %s" % `self.depotPaths`
@@ -1811,7 +1811,7 @@ class P4Sync(Command, P4UserMap):
command = "branches"
for info in p4CmdList(command):
- details = p4Cmd("branch -o %s" % info["branch"])
+ details = p4Cmd(["branch", "-o", info["branch"]])
viewIdx = 0
while details.has_key("View%s" % viewIdx):
paths = details["View%s" % viewIdx].split(" ")
@@ -1949,7 +1949,7 @@ class P4Sync(Command, P4UserMap):
sourceRef = self.gitRefForBranch(sourceBranch)
#print "source " + sourceBranch
- branchParentChange = int(p4Cmd("changes -m 1 %s...@1,%s" % (sourceDepotPath, firstChange))["change"])
+ branchParentChange = int(p4Cmd(["changes", "-m", "1", "%s...@1,%s" % (sourceDepotPath, firstChange)])["change"])
#print "branch parent: %s" % branchParentChange
gitParent = self.gitCommitByP4Change(sourceRef, branchParentChange)
if len(gitParent) > 0:
diff --git a/t/t9803-git-p4-shell-metachars.sh b/t/t9803-git-p4-shell-metachars.sh
index db04375..db67020 100755
--- a/t/t9803-git-p4-shell-metachars.sh
+++ b/t/t9803-git-p4-shell-metachars.sh
@@ -57,6 +57,54 @@ test_expect_success 'deleting with shell metachars' '
)
'
+# Create a branch with a shell metachar in its name
+#
+# 1. //depot/main
+# 2. //depot/branch$3
+
+test_expect_success 'branch with shell char' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ (
+ cd "$cli" &&
+
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ p4 integrate //depot/main/... //depot/branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ echo f1 >branch\$3/shell_char_branch_file &&
+ p4 add branch\$3/shell_char_branch_file &&
+ p4 submit -d "branch\$3/shell_char_branch_file" &&
+
+ p4 branch -i <<-EOF &&
+ Branch: branch\$3
+ View: //depot/main/... //depot/branch\$3/...
+ EOF
+
+ p4 edit main/f1 &&
+ echo "a change" >> main/f1 &&
+ p4 submit -d "a change" main/f1 &&
+
+ p4 integrate -b branch\$3 &&
+ p4 resolve -am branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ cd "$git" &&
+
+ git config git-p4.branchList main:branch\$3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch\$3 &&
+ test -f shell_char_branch_file &&
+ test -f f1
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCHv4 0/5] git-p4: small fixes to branches and labels
From: Luke Diamand @ 2012-01-19 9:52 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Vitor Antunes, Luke Diamand
This is the fourth version of some small fixes to git-p4 branch and
label handling, incorporating a fix from Pete Wyckoff and an
additional failing test.
This change does not fix the other problems with git-p4 labels:
- two p4 labels on the same changelist will fall over
- labels must match exactly the list of files imported
- you can't import a label without a p4 commit
Luke Diamand (5):
git-p4: handle p4 branches and labels containing shell chars
git-p4: cope with labels with empty descriptions
git-p4: importing labels should cope with missing owner
git-p4: add test for p4 labels
git-p4: label import fails with multiple labels at the same
changelist
contrib/fast-import/git-p4 | 79 ++++++++++++++-----------
t/t9803-git-p4-shell-metachars.sh | 48 ++++++++++++++++
t/t9804-git-p4-label.sh | 113 +++++++++++++++++++++++++++++++++++++
3 files changed, 205 insertions(+), 35 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-19 9:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ævar Arnfjörð, Git Mailing List
In-Reply-To: <7vfwfclf4v.fsf@alter.siamese.dyndns.org>
On Thu, Jan 19, 2012 at 01:17, Junio C Hamano <gitster@pobox.com> wrote:
> So we need "MY_GETTEXT_IS_BROKEN" to decline the use of system gettext
> in addition to "NO_GETTEXT" to ask Git not to translate the messages. Is
> that correct?
I think yes.
> If that is the case, should we do something like
>
> LANG=C LC_ALL=C
> export LANG LC_ALL
>
> in our shell scripts, when building for NO_GETTEXT target?
Just for the record: gettext here stays broken with LANG and LC_ALL set to C.
But the locale-dependent formatting in C functions will change. Wont be a
problem here, though. The named formatting is broken, too: strftime, for
instance, always formats in C locale.
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-19 9:15 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Git Mailing List, Junio C Hamano, Ævar Arnfjörð
In-Reply-To: <20120119001225.GA13975@burratino>
On Thu, Jan 19, 2012 at 01:12, Jonathan Nieder <jrnieder@gmail.com> wrote:
> I like the unindenting. Alas, I get
>
> 1: test: type: unexpected operator
>
> I suspect this should just say "elif type gettext.sh >/dev/null 2>&1".
Indeed. Copy-paste error. I wonder why I didn't notice it...
Yes, ran the tests, both with and without NO_GETTEXT.
> The rest looks good. Thanks for writing it.
Was Junios idea, I just liked it.
^ permalink raw reply
* Re: [PATCH] i18n: disable i18n for shell scripts if NO_GETTEXT defined
From: Alex Riesen @ 2012-01-19 9:13 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <CACBZZX4tB6DGV-1tiuOamq7ACPk0a-=1Pb9Vk1SgyDqAq-EFOw@mail.gmail.com>
On Thu, Jan 19, 2012 at 00:18, Ævar Arnfjörð Bjarmason <avarab@gmail.com> wrote:
> On Wed, Jan 18, 2012 at 19:57, Alex Riesen <raa.lkml@gmail.com> wrote:
>>
>> Well, if I say NO_GETTEXT, I kind of want none of local gettext,
>> whether it works, or not.
>
> That's not what NO_GETTEXT means, and not what it *should* mean. It
> means that your output won't be translated, but we might still make
> use of a locally installed library to provide the gettext() and
> eval_gettext() functions.
I would never guess all that by its name: NO_GETTEXT. I wanted to
say: there is no gettext in this installation, don't even try it.
> This approach has worked everywhere so far (Linux, OSX, *BSD etc.),
> and you want to change *everywhere* because you have some completely
> broken Cygwin install.
Just as I said.
> How did you even get that install? Is it a known issue? Some ancient
> now-fixed bug?
It is very likely. Or probably just a one installation problem: the
problem is not consistently everywhere here. Some installations
work (if slow).
> What version of Cygwin / gettext etc.
No idea. The person or persons who did this to me have no idea either.
> Now I'm not saying that we shouldn't fix this, I just don't think that
> this is the right way to go about it.
And I agree.
> But in summary: We shouldn't be *always* using fallback functions
> whether they're the C stuff in compat/* or the gettext fallbacks in
> git-sh-i18n.sh just because there's some version out there of the
> system-supplied functions that's broken.
>
> It makes sense to prefer the system functions by default in both
> cases, but when the OS one can be broken or lacking we can just add
> probes or Makefile options like we do for fnmatch() with the
> NO_FNMATCH_CASEFOLD switch.
Yes, and I personally shall welcome a chance to insult the local IT
by suggesting BROKEN_SH_GETTEXT. Not that they get the point...
^ permalink raw reply
* Re: [PATCH 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2012-01-19 9:12 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20120117223949.GA811@padd.com>
On 17/01/12 22:39, Pete Wyckoff wrote:
> luke@diamand.org wrote on Mon, 16 Jan 2012 23:14 +0000:
>> Don't use shell expansion when detecting branches, as it will
>> fail if the branch name contains a shell metachar. Similarly
>> for labels.
>>
>> Add additional test for branches with shell metachars.
>
> Nice. There will be a fixup on a command in Vitor's series,
> depending on which goes first. He'll have a couple of
> un-listified read_pipe{,_lines} that we should treat similarly.
>
>> @@ -1758,7 +1758,7 @@ class P4Sync(Command, P4UserMap):
>> def getLabels(self):
>> self.labels = {}
>>
>> - l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
>> + l = p4CmdList(["labels", "%s..." % ' '.join (self.depotPaths)])
>> if len(l)> 0 and not self.silent:
>> print "Finding files belonging to labels in %s" % `self.depotPaths`
>
> I suspect the command "p4" "labels" "//depot/foo/... //depot/bar/..."
> might confuse p4, but haven't tested. Maybe tuck each one in its
> own argument?
>
> ["labels"] + ["%s..." % p for p in self.depotPaths]
Yes, you're right. I'll resubmit. I suspect the previous code was
actually broken as well as you end up with the "..." only on the last depot.
>
> What happened to your failing test? It's fun to keep the broken
> ones around to inspire others to fix them.
I'll send that one through as well. I actually had a fix, but it needs
to be reworked now. I'm reluctant to try to do much more on this though
unless someone can tell me how the --detect-labels code can ever really
work.
i.e. if you do:
p4 submit
git-p4 rebase --detect-labels
p4 tag LABEL_A
git-p4 rebase --detect-labels
At this point, LABEL_A won't show up in git until the _next_ p4 commit.
It's slowly working it's way towards the top of my todo list though!
Regards!
Luke
^ permalink raw reply
* Re: [BUG] Git bisect not finding the right commit
From: Johannes Sixt @ 2012-01-19 8:23 UTC (permalink / raw)
To: Andreas J. Koenig; +Cc: git
In-Reply-To: <87r4yw8j4i.fsf@franz.ak.mind.de>
Am 1/19/2012 4:29, schrieb Andreas J. Koenig:
> - A -> B -> C - D ->
> \ /
> - E - F -
>
> A v5.15.5
> B v5.15.5-20-gfd76d40
> C v5.15.5-81-gcfe287a
> D v5.15.5-159-ga71d67b
> E v5.15.4-110-g27b29ec
> F v5.15.4-169-g3582575
I haven't looked at the actual history, but given the names of the commits
as produced by git-describe, I doubt that your history graph sketched
above is correct. Doesn't it look more like this:
A -- B -- C -- D --
/ /
-- X -- E -- F
where X is v5.15.4?
To find a commit between A and B, you must declare F as "good".
-- Hannes
^ 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