* Re: feature suggestion: optimize common parts for checkout --conflict=diff3
From: Jeff King @ 2013-03-06 20:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antoine Pelisse, Uwe Kleine-König, git, kernel
In-Reply-To: <7vvc94p8hb.fsf@alter.siamese.dyndns.org>
On Wed, Mar 06, 2013 at 12:40:48PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > then it will produce the output that Uwe expects. While it can be
> > misleading,...
>
> Misleading is one thing but in this case isn't it outright wrong?
>
> If you remove <<< ours ||| portion from the combined diff output,
> I would expect that the hunk will apply to the base, but that is no
> longer true, no?
It shifts the concept of what is the "base" and what is the "conflict".
In Uwe's example, no, it would not apply to the single-line file that is
the true 3-way base. But it would apply to the content that is outside
of the hunk marker; we have changed the concept of what is in the base
and what is in the conflict by shrinking the conflict to its smallest
size. The same is true of the conflict markers produced in the non-diff3
case. It is a property of XDL_MERGE_ZEALOUS, not of the conflict style.
If your argument is "diff3 means something different than regular
conflict markers; it should have the property of being
machine-convertible into a patch, but regular markers do not", I'm not
sure I agree. It may be used that way, but I think it is mostly used in
git to give the reader more context when making a resolution. And
anyway, I think the proposed change would not be to change diff3, but to
introduce a new diff3-like format that also shrinks the hunk size, so it
would not hurt existing users of diff3.
-Peff
^ permalink raw reply
* [PATCH 2/2] p4merge: create a virtual base if none available
From: Kevin Bracey @ 2013-03-06 20:32 UTC (permalink / raw)
To: git; +Cc: David Aguilar, Ciaran Jessup, Scott Chacon
In-Reply-To: <1362601978-16911-1-git-send-email-kevin@bracey.fi>
Originally, with no base, Git gave P4Merge $LOCAL as a dummy base:
p4merge "$LOCAL" "$LOCAL" "$REMOTE" "$MERGED"
Commit 0a0ec7bd changed this to:
p4merge "empty file" "$LOCAL" "$REMOTE" "$MERGED"
to avoid the problem of being unable to save in some circumstances.
Unfortunately this approach does not produce good results at all on
differing inputs. P4Merge really regards the blank file as the base, and
once you have just a couple of differences between the two branches you
end up with one a massive full-file conflict. The diff is not readable,
and you have to invoke "difftool MERGE_HEAD HEAD" manually to see a
2-way diff.
The original form appears to have invoked special 2-way comparison
behaviour that occurs only if the base filename is "" or equal to the
left input. You get a good diff, and it does not auto-resolve in one
direction or the other. (Normally if one branch equals the base, it
would autoresolve to the other branch).
But there appears to be no way of getting this 2-way behaviour and being
able to reliably save. Having base=left appears to be triggering other
assumptions. There are tricks the user can use to force the save icon
on, but it's not intuitive.
So we now follow a suggestion given in the original patch's discussion:
generate a virtual base, consisting of the lines common to the two
branches. It produces a much nicer 3-way diff view than either of the
original forms, and than I suspect other mergetools are managing.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
---
git-mergetool--lib.sh | 14 ++++++++++++++
mergetools/p4merge | 2 +-
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index e338be5..5b60cf5 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -108,6 +108,20 @@ check_unchanged () {
fi
}
+make_virtual_base() {
+ # Copied from git-merge-one-file.sh.
+ # This starts with $LOCAL, and uses git apply to
+ # remove lines that are not in $REMOTE.
+ cp -- "$LOCAL" "$BASE"
+ sz0=`wc -c <"$BASE"`
+ @@DIFF@@ -u -L"a/$BASE" -L"b/$BASE" "$BASE" "$REMOTE" | git apply --no-add
+ sz1=`wc -c <"$BASE"`
+
+ # If we do not have enough common material, it is not
+ # worth trying two-file merge using common subsections.
+ expr $sz0 \< $sz1 \* 2 >/dev/null || : >"$BASE"
+}
+
valid_tool () {
setup_tool "$1" && return 0
cmd=$(get_merge_tool_cmd "$1")
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 46b3a5a..f0a893b 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -21,7 +21,7 @@ diff_cmd () {
merge_cmd () {
touch "$BACKUP"
- $base_present || >"$BASE"
+ $base_present || make_virtual_base
"$merge_tool_path" "$BASE" "$REMOTE" "$LOCAL" "$MERGED"
check_unchanged
}
--
1.8.2.rc2.5.g1a80410.dirty
^ permalink raw reply related
* Re: feature suggestion: optimize common parts for checkout --conflict=diff3
From: Junio C Hamano @ 2013-03-06 21:09 UTC (permalink / raw)
To: Jeff King; +Cc: Antoine Pelisse, Uwe Kleine-König, git, kernel
In-Reply-To: <20130306205400.GA29604@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But it would apply to the content that is outside
> of the hunk marker; we have changed the concept of what is in the base
> and what is in the conflict by shrinking the conflict to its smallest
> size.
Hmm, unless you mean by "base" something entirely different from
"what was in the common ancestor version", I do not think I can
agree. The point of diff3 mode is to show how it looked line in the
common ancestor and what the conflicting sides want to change that
common version into; letting the user view three versions to help
him decide what to do by only looking at the part inside conflict
markers.
We show "both sides added, either identically or differently" as
noteworthy events, but the patched code pushes "both sides added
identically" case outside the conflicting hunk, as if what was added
relative to the common ancestor version (in Uwe's case, is it 1-14
that is common, or just 10-14?) is not worth looking at when
considering what the right resolution is. If it is not worth
looking at what was in the original for the conflicting part, why
would we be even using diff3 mode in the first place?
^ permalink raw reply
* Re: feature suggestion: optimize common parts for checkout --conflict=diff3
From: Jeff King @ 2013-03-06 21:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antoine Pelisse, Uwe Kleine-König, git, kernel
In-Reply-To: <7vr4jsp756.fsf@alter.siamese.dyndns.org>
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > But it would apply to the content that is outside
> > of the hunk marker; we have changed the concept of what is in the base
> > and what is in the conflict by shrinking the conflict to its smallest
> > size.
>
> Hmm, unless you mean by "base" something entirely different from
> "what was in the common ancestor version", I do not think I can
> agree.
I don't know. I didn't use the word "base" in the first place. I was
trying to figure out what you meant. :)
My point is that the hunk (everything from "<<<" to ">>>") is
self-consistent. It's just misleading in that the hunk has been shrunk
not to include identical bits from each side. IMHO, this is not much
different than a nearby change being auto-resolved. The conflict hunks
the user sees do not represent the original files, but rather the
remains after a first pass at resolving.
> The point of diff3 mode is to show how it looked line in the
> common ancestor and what the conflicting sides want to change that
> common version into; letting the user view three versions to help
> him decide what to do by only looking at the part inside conflict
> markers.
Right, I agree.
> We show "both sides added, either identically or differently" as
> noteworthy events, but the patched code pushes "both sides added
> identically" case outside the conflicting hunk, as if what was added
> relative to the common ancestor version (in Uwe's case, is it 1-14
> that is common, or just 10-14?) is not worth looking at when
> considering what the right resolution is. If it is not worth
> looking at what was in the original for the conflicting part, why
> would we be even using diff3 mode in the first place?
I think Uwe's example shows that it _is_ useful. Yes, you no longer have
the information about what happened through 1-14 (whether it was really
there in the ancestor file, or whether it was simply added identically).
But that information might or might not be relevant. In Uwe's example,
it is just noise that detracts from the interesting part of the change
(or does it? I think the answer is in the eye of the reader). I think
it can be helpful to have both types available, and they can pick which
one they want; it's just another tool.
Another argument is that some people (including me) set
merge.conflictstyle to diff3, because they like seeing the extra context
when resolving (I find it helps a lot with rebasing, when it is
sometimes hard to remember which side is which in the merge). I'd
consider setting it to zdiff3 to get the benefits of XDL_MERGE_ZEALOUS,
and using "git checkout --conflict-style=diff3" if I need to get more
information about a specific case.
-Peff
^ permalink raw reply
* [PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool
From: Kevin Bracey @ 2013-03-06 20:32 UTC (permalink / raw)
To: git; +Cc: David Aguilar, Ciaran Jessup, Scott Chacon
In-Reply-To: <1362601978-16911-1-git-send-email-kevin@bracey.fi>
Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
the incoming branch is now in the left-hand, blue triangle pane, and the
current branch is in the right-hand, green circle pane.
This change makes use of P4Merge consistent with its built-in help, its
reference documentation, and Perforce itself. But most importantly, it
makes merge results clearer. P4Merge is not totally symmetrical between
left and right; despite changing a few text labels from "theirs/ours" to
"left/right" when invoked manually, it still retains its original
Perforce "theirs/ours" viewpoint.
Most obviously, in the result pane P4Merge shows changes that are common
to both branches in green. This is on the basis of the current branch
being green, as it is when invoked from Perforce; it means that lines in
the result are blue if and only if they are being changed by the merge,
making the resulting diff clearer. Whereas if you use blue as the
current branch, then there is no single colour highlighting changes -
a green line in the result could be a change, but it could also be
something already in the current branch that isn't changed by the merge.
There is no need to swap LOCAL/REMOTE order for difftool; P4Merge is
symmetrical in this case, and a 0- or 1-revision difftool invocation
already gives the working tree ("ours") on the right in green, matching
Perforce's equivalent "Diff Against Have Revision". And you couldn't
swap it anyway, as it would make 2-revision difftool invocation
back-to-front.
Note that P4Merge now shows "ours" on the right for both diff and merge,
unlike other diff/mergetools, which always have REMOTE on the right.
But observe that REMOTE is the working tree (ie "ours") for a diff,
while it's another branch (ie "theirs") for a merge.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
---
mergetools/p4merge | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mergetools/p4merge b/mergetools/p4merge
index 8a36916..46b3a5a 100644
--- a/mergetools/p4merge
+++ b/mergetools/p4merge
@@ -22,7 +22,7 @@ diff_cmd () {
merge_cmd () {
touch "$BACKUP"
$base_present || >"$BASE"
- "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" "$MERGED"
+ "$merge_tool_path" "$BASE" "$REMOTE" "$LOCAL" "$MERGED"
check_unchanged
}
--
1.8.2.rc2.5.g1a80410.dirty
^ permalink raw reply related
* Re: feature suggestion: optimize common parts for checkout --conflict=diff3
From: Uwe Kleine-König @ 2013-03-06 21:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Antoine Pelisse, git, kernel
In-Reply-To: <7vr4jsp756.fsf@alter.siamese.dyndns.org>
Hello Junio,
On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > But it would apply to the content that is outside
> > of the hunk marker; we have changed the concept of what is in the base
> > and what is in the conflict by shrinking the conflict to its smallest
> > size.
>
> Hmm, unless you mean by "base" something entirely different from
> "what was in the common ancestor version", I do not think I can
> agree. The point of diff3 mode is to show how it looked line in the
> common ancestor and what the conflicting sides want to change that
> common version into; letting the user view three versions to help
> him decide what to do by only looking at the part inside conflict
> markers.
>
> We show "both sides added, either identically or differently" as
> noteworthy events, but the patched code pushes "both sides added
> identically" case outside the conflicting hunk, as if what was added
I didn't test, but "both sides removed identically" should be moved out,
too, shouldn't it?
> relative to the common ancestor version (in Uwe's case, is it 1-14
> that is common, or just 10-14?) is not worth looking at when
> considering what the right resolution is. If it is not worth
> looking at what was in the original for the conflicting part, why
> would we be even using diff3 mode in the first place?
because even zdiff3 contains more information than merge. And compared
to diff3 it's smaller sometimes and so easier to understand.
Other than that I agree fully to the things Jeff said so far.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: feature suggestion: optimize common parts for checkout --conflict=diff3
From: Junio C Hamano @ 2013-03-06 21:32 UTC (permalink / raw)
To: Jeff King; +Cc: Antoine Pelisse, Uwe Kleine-König, git, kernel
In-Reply-To: <7vr4jsp756.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> But it would apply to the content that is outside
>> of the hunk marker; we have changed the concept of what is in the base
>> and what is in the conflict by shrinking the conflict to its smallest
>> size.
>
> Hmm, unless you mean by "base" something entirely different from
> "what was in the common ancestor version", I do not think I can
> agree. The point of diff3 mode is to show how it looked line in the
> common ancestor and what the conflicting sides want to change that
> common version into; letting the user view three versions to help
> him decide what to do by only looking at the part inside conflict
> markers.
>
> We show "both sides added, either identically or differently" as
> noteworthy events, but the patched code pushes "both sides added
> identically" case outside the conflicting hunk, as if what was added
> relative to the common ancestor version (in Uwe's case, is it 1-14
> that is common, or just 10-14?) is not worth looking at when
> considering what the right resolution is. If it is not worth
> looking at what was in the original for the conflicting part, why
> would we be even using diff3 mode in the first place?
I vaguely recall we did this "clip to eager" as an explicit bugfix
at 83133740d9c8 (xmerge.c: "diff3 -m" style clips merge reduction
level to EAGER or less, 2008-08-29). The list archive around that
time may give us more contexts.
^ permalink raw reply
* [PATCH] In partial SVN merges, the ranges contains additional character "*"
From: Jan Pešta @ 2013-03-06 21:35 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Matthieu Moy
See http://www.open.collab.net/community/subversion/articles/merge-info.html
Extract:
The range r30430:30435 that was added to 1.5.x in this merge has a '*'
suffix for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo is explicitly set
has had this range merged into it.
Signed-off-by: Jan Pesta <jan.pesta@certicon.cz>
---
perl/Git/SVN.pm | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0ebc68a..74d49bb 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1493,6 +1493,11 @@ sub lookup_svn_merge {
my @merged_commit_ranges;
# find the tip
for my $range ( @ranges ) {
+ if ($range =~ /[*]$/) {
+ warn "W:Ignoring partial merge in svn:mergeinfo "
+ ."dirprop: $source:$range\n";
+ next;
+ }
my ($bottom, $top) = split "-", $range;
$top ||= $bottom;
my $bottom_commit = $gs->find_rev_after( $bottom, 1, $top );
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH v2] tests: make sure rename pretty print works
From: Antoine Pelisse @ 2013-03-06 21:36 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Antoine Pelisse
In-Reply-To: <1362235092-16914-1-git-send-email-apelisse@gmail.com>
Add basic use cases and corner cases tests for
"git diff -M --summary/stat".
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
list of fixes:
- Test using diff instead of show
(that is more consistent with commit message).
- add extra spaces around paths
- Use better commit messages
- Moved to existing t4001
t/t4001-diff-rename.sh | 54 ++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 54 insertions(+)
diff --git a/t/t4001-diff-rename.sh b/t/t4001-diff-rename.sh
index 844277c..2f327b7 100755
--- a/t/t4001-diff-rename.sh
+++ b/t/t4001-diff-rename.sh
@@ -102,4 +102,58 @@ test_expect_success 'setup for many rename source candidates' '
grep warning actual.err
'
+test_expect_success 'rename pretty print with nothing in common' '
+ mkdir -p a/b/ &&
+ : >a/b/c &&
+ git add a/b/c &&
+ git commit -m "create a/b/c" &&
+ mkdir -p c/b/ &&
+ git mv a/b/c c/b/a &&
+ git commit -m "a/b/c -> c/b/a" &&
+ git diff -M --summary HEAD^ HEAD >output &&
+ test_i18ngrep " a/b/c => c/b/a " output &&
+ git diff -M --stat HEAD^ HEAD >output &&
+ test_i18ngrep " a/b/c => c/b/a " output
+'
+
+test_expect_success 'rename pretty print with common prefix' '
+ mkdir -p c/d &&
+ git mv c/b/a c/d/e &&
+ git commit -m "c/b/a -> c/d/e" &&
+ git diff -M --summary HEAD^ HEAD >output &&
+ test_i18ngrep " c/{b/a => d/e} " output &&
+ git diff -M --stat HEAD^ HEAD >output &&
+ test_i18ngrep " c/{b/a => d/e} " output
+'
+
+test_expect_success 'rename pretty print with common suffix' '
+ mkdir d &&
+ git mv c/d/e d/e &&
+ git commit -m "c/d/e -> d/e" &&
+ git diff -M --summary HEAD^ HEAD >output &&
+ test_i18ngrep " {c/d => d}/e " output &&
+ git diff -M --stat HEAD^ HEAD >output &&
+ test_i18ngrep " {c/d => d}/e " output
+'
+
+test_expect_success 'rename pretty print with common prefix and suffix' '
+ mkdir d/f &&
+ git mv d/e d/f/e &&
+ git commit -m "d/e -> d/f/e" &&
+ git diff -M --summary HEAD^ HEAD >output &&
+ test_i18ngrep " d/{ => f}/e " output &&
+ git diff -M --stat HEAD^ HEAD >output &&
+ test_i18ngrep " d/{ => f}/e " output
+'
+
+test_expect_success 'rename pretty print common prefix and suffix overlap' '
+ mkdir d/f/f &&
+ git mv d/f/e d/f/f/e &&
+ git commit -m "d/f/e d/f/f/e" &&
+ git diff -M --summary HEAD^ HEAD >output &&
+ test_i18ngrep " d/f/{ => f}/e " output &&
+ git diff -M --stat HEAD^ HEAD >output &&
+ test_i18ngrep " d/f/{ => f}/e " output
+'
+
test_done
--
1.7.9.5
^ permalink raw reply related
* fetch --no-tags with and w/o --all
From: Cristian Tibirna @ 2013-03-06 21:33 UTC (permalink / raw)
To: git
Hello
$ git --version
git version 1.7.10.4
$ git fetch origin --no-tags
does what it says
$ git fetch --all --no-tags
still gets all the tags from the remote.
Is this known?
Thanks.
--
Cristian Tibirna (1-418-) 656-2131 / 4340
Laval University - Quebec, CAN ... http://www.giref.ulaval.ca/~ctibirna
Research professional at GIREF ... ctibirna@giref.ulaval.ca
^ permalink raw reply
* Re: feature suggestion: optimize common parts for checkout --conflict=diff3
From: Junio C Hamano @ 2013-03-06 21:50 UTC (permalink / raw)
To: Jeff King; +Cc: Antoine Pelisse, Uwe Kleine-König, git, kernel
In-Reply-To: <20130306212140.GA30202@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think Uwe's example shows that it _is_ useful. Yes, you no longer have
> the information about what happened through 1-14 (whether it was really
> there in the ancestor file, or whether it was simply added identically).
> But that information might or might not be relevant.
I think it is more like "I added bread and my wife added bread to
our common shopping list" and our two-way "RCS merge" default is to
collapse that case to "one loaf of bread on the shopping list". My
impression has always been that people who use "diff3" mode care
about this case and want to know that the original did not have
"bread" on the list in order to decide if one or two loaves of bread
should remain in the result.
> In Uwe's example,
> it is just noise that detracts from the interesting part of the change
> (or does it? I think the answer is in the eye of the reader).
In other words, you would use the "RCS merge" style because most of
the time you would resolve to "one loaf of bread" and the fact that
it was missing in the original is not needed to decide that. So, it
feels strange to use "diff3" and still want to discard that
information---if it is not relevant, why are you using diff3 mode in
the first place? That is the question that is still not answered.
^ permalink raw reply
* Re: fetch --no-tags with and w/o --all
From: Junio C Hamano @ 2013-03-06 21:56 UTC (permalink / raw)
To: Cristian Tibirna; +Cc: git
In-Reply-To: <1879950.i2j8pjGADy@gandalf>
Cristian Tibirna <ctibirna@giref.ulaval.ca> writes:
> Hello
>
> $ git --version
> git version 1.7.10.4
>
> $ git fetch origin --no-tags
> does what it says
>
> $ git fetch --all --no-tags
> still gets all the tags from the remote.
>
> Is this known?
Because --all (or --multiple) to iterate through all remotes
does not pass accept any command line refspecs, using these options
with --no-tags and/or --tags should be diagnosed as an error, but it
appears that the error checking is not done.
^ permalink raw reply
* "Already up-to-date!" merge isn't a no-op?
From: Stephen Bash @ 2013-03-06 21:48 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <1826064298.2151517.1362605175796.JavaMail.root@genarts.com>
Hi all-
I have a branch history that looks like this:
----------M-----M-- master
\ / /
x---------------- feature
\ \
x-------------A- maint
In other words we had a new feature that was "so cool" that after testing on master was back-ported to maint (luckily we knew ahead of time this was likely). When it came time to merge feature into maint the process looked something like this:
Yesterday (not shown above):
$ git checkout master
$ git merge maint
Today:
$ git checkout maint
$ git merge feature
Merge made by the 'recursive' strategy.
$ git checkout master
$ git merge maint
Already up-to-date!
Merge made by the 'recursive' strategy.
$ git --version
git version 1.8.1.5
In the past, I've only seen "Already up-to-date!" when there is literally nothing to do (all commits are reachable from HEAD). In this case, the merge of feature into maint (commit A) is the only commit not reachable from HEAD, and Git does create a merge commit (though the new commit and the first parent point to the same tree). The fact that a commit is created makes me call this something more than a no-op, even though no content changed.
So what is the actual meaning of "Already up-to-date!"? Is it based on the tree, the reachable commits, or something more complicated?
Thanks,
Stephen
^ permalink raw reply
* Re: [PATCH v2] tests: make sure rename pretty print works
From: Junio C Hamano @ 2013-03-06 22:03 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <1362605772-14639-1-git-send-email-apelisse@gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> Add basic use cases and corner cases tests for
> "git diff -M --summary/stat".
>
> Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
> ---
> list of fixes:
> - Test using diff instead of show
> (that is more consistent with commit message).
> - add extra spaces around paths
> - Use better commit messages
> - Moved to existing t4001
>
> t/t4001-diff-rename.sh | 54 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 54 insertions(+)
Nice.
Will queue, but we may want to make these tests more independent
from each other later. For example, if the first test fails before
its "git mv a/b/c c/b/a", the set-up of the second test to further
move it to c/d/e will fail, which is probably not very desirable.
Thanks.
> +test_expect_success 'rename pretty print with nothing in common' '
> + mkdir -p a/b/ &&
> + : >a/b/c &&
> + git add a/b/c &&
> + git commit -m "create a/b/c" &&
> + mkdir -p c/b/ &&
> + git mv a/b/c c/b/a &&
> + git commit -m "a/b/c -> c/b/a" &&
> + git diff -M --summary HEAD^ HEAD >output &&
> + test_i18ngrep " a/b/c => c/b/a " output &&
> + git diff -M --stat HEAD^ HEAD >output &&
> + test_i18ngrep " a/b/c => c/b/a " output
> +'
> +
> +test_expect_success 'rename pretty print with common prefix' '
> + mkdir -p c/d &&
> + git mv c/b/a c/d/e &&
> + git commit -m "c/b/a -> c/d/e" &&
> + git diff -M --summary HEAD^ HEAD >output &&
> + test_i18ngrep " c/{b/a => d/e} " output &&
> + git diff -M --stat HEAD^ HEAD >output &&
> + test_i18ngrep " c/{b/a => d/e} " output
> +'
> +
> +test_expect_success 'rename pretty print with common suffix' '
> + mkdir d &&
> + git mv c/d/e d/e &&
> + git commit -m "c/d/e -> d/e" &&
> + git diff -M --summary HEAD^ HEAD >output &&
> + test_i18ngrep " {c/d => d}/e " output &&
> + git diff -M --stat HEAD^ HEAD >output &&
> + test_i18ngrep " {c/d => d}/e " output
> +'
> +
> +test_expect_success 'rename pretty print with common prefix and suffix' '
> + mkdir d/f &&
> + git mv d/e d/f/e &&
> + git commit -m "d/e -> d/f/e" &&
> + git diff -M --summary HEAD^ HEAD >output &&
> + test_i18ngrep " d/{ => f}/e " output &&
> + git diff -M --stat HEAD^ HEAD >output &&
> + test_i18ngrep " d/{ => f}/e " output
> +'
> +
> +test_expect_success 'rename pretty print common prefix and suffix overlap' '
> + mkdir d/f/f &&
> + git mv d/f/e d/f/f/e &&
> + git commit -m "d/f/e d/f/f/e" &&
> + git diff -M --summary HEAD^ HEAD >output &&
> + test_i18ngrep " d/f/{ => f}/e " output &&
> + git diff -M --stat HEAD^ HEAD >output &&
> + test_i18ngrep " d/f/{ => f}/e " output
> +'
> +
> test_done
> --
> 1.7.9.5
^ permalink raw reply
* Re: "Already up-to-date!" merge isn't a no-op?
From: Junio C Hamano @ 2013-03-06 22:08 UTC (permalink / raw)
To: Stephen Bash; +Cc: Git Mailing List
In-Reply-To: <142915274.2151729.1362606487755.JavaMail.root@genarts.com>
Stephen Bash <bash@genarts.com> writes:
> So what is the actual meaning of "Already up-to-date!"? Is it
> based on the tree, the reachable commits, or something more
> complicated?
The resulting tree of the merge happened to be the same as the
original tree (i.e. "git diff HEAD^ HEAD" is empty).
This happens quite often and is perfectly normal. After merging
topics that has been cooking in 'next' to 'master', merging the
resulting 'master' to 'next' is likely to result in that situation,
unless 'master' has gained some other changes, such as updating the
draft release notes with a commit on it, or applying an obvious and
trivial fix before cooking it in 'next'.
^ permalink raw reply
* [PATCH 0/2] Improve P4Merge mergetool invocation
From: Kevin Bracey @ 2013-03-06 20:32 UTC (permalink / raw)
To: git; +Cc: David Aguilar, Ciaran Jessup, Scott Chacon
Two changes to the same piece of code that have greatly improved the behaviour
of P4Merge for me. Some of it may also be applicable to other mergetools.
I've put probably overly-long-winded explanations in the commit messages.
Comments welcome. In particular, I know almost nothing of sh, so I may have
made some blunder there.
Kevin Bracey (2):
p4merge: swap LOCAL and REMOTE for mergetool
p4merge: create a virtual base if none available
git-mergetool--lib.sh | 14 ++++++++++++++
mergetools/p4merge | 4 ++--
2 files changed, 16 insertions(+), 2 deletions(-)
--
1.8.2.rc2.5.g1a80410.dirty
^ permalink raw reply
* Re: [PATCH v2 1/4] wt-status: split wt_status_state parsing function out
From: Junio C Hamano @ 2013-03-06 23:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Matthieu Moy, Jonathan Niedier
In-Reply-To: <7v4ngoqs8m.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> In other words, with the new world order, wouldn't a saner function
> signature be:
>
> static const char *read_and_strip_branch(const char **path);
Eh, discard an asterisk from there. "Given a string to name the
file, read it to find the branch name recorded in it".
> after this patch?
>
> Also I notice that the error-return cases of this function may be
> wrong even before your patch. Shouldn't it be doing *branch = NULL
> (and 'return NULL' after the suggested change)?
^ permalink raw reply
* Re: [PATCH] help: show manpage for aliased command on git <alias> --help
From: Junio C Hamano @ 2013-03-06 23:55 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jeff King, Ævar Arnfjörð Bjarmason, git,
Jonathan Nieder, H.Merijn Brand
In-Reply-To: <51374029.6080906@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Well, even in the simple case one has to wonder: Why does the user
> invoke help for "co"? There are two very likely cases:
>
> A) User does not remember what "co" is aliased to.
> B) User wants to see the man page.
>
> If A is not the case then it's easy for the user to request help for
> "checkout" (or "commit" or ...).
>
> Removing the only easy way to look up the definition of an alias is a
> major regression.
Very well said ;-).
^ permalink raw reply
* Re: [PATCH] In partial SVN merges, the ranges contains additional character "*"
From: Junio C Hamano @ 2013-03-07 0:04 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Matthieu Moy, Jan Pešta
In-Reply-To: <000001ce1ab2$903fbc40$b0bf34c0$@certicon.cz>
Jan Pešta <jan.pesta@certicon.cz> writes:
> See http://www.open.collab.net/community/subversion/articles/merge-info.html
> Extract:
> The range r30430:30435 that was added to 1.5.x in this merge has a '*'
> suffix for 1.5.x\www.
> This '*' is the marker for a non-inheritable mergeinfo range.
> The '*' means that only the path on which the mergeinfo is explicitly set
> has had this range merged into it.
>
> Signed-off-by: Jan Pesta <jan.pesta@certicon.cz>
> ---
> perl/Git/SVN.pm | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
> index 0ebc68a..74d49bb 100644
> --- a/perl/Git/SVN.pm
> +++ b/perl/Git/SVN.pm
> @@ -1493,6 +1493,11 @@ sub lookup_svn_merge {
> my @merged_commit_ranges;
> # find the tip
> for my $range ( @ranges ) {
> + if ($range =~ /[*]$/) {
> + warn "W:Ignoring partial merge in svn:mergeinfo "
> + ."dirprop: $source:$range\n";
> + next;
> + }
> my ($bottom, $top) = split "-", $range;
> $top ||= $bottom;
> my $bottom_commit = $gs->find_rev_after( $bottom, 1, $top );
^ permalink raw reply
* Re: fetch --no-tags with and w/o --all
From: Jeff King @ 2013-03-07 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Cristian Tibirna, git
In-Reply-To: <7vboawp4zy.fsf@alter.siamese.dyndns.org>
On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote:
> Cristian Tibirna <ctibirna@giref.ulaval.ca> writes:
>
> > Hello
> >
> > $ git --version
> > git version 1.7.10.4
> >
> > $ git fetch origin --no-tags
> > does what it says
> >
> > $ git fetch --all --no-tags
> > still gets all the tags from the remote.
> >
> > Is this known?
>
> Because --all (or --multiple) to iterate through all remotes
> does not pass accept any command line refspecs, using these options
> with --no-tags and/or --tags should be diagnosed as an error, but it
> appears that the error checking is not done.
Or we could just pass them through. Looks like this was already fixed by
8556646 (fetch --all: pass --tags/--no-tags through to each remote,
2012-09-05), which is in v1.7.12.2 and higher.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] p4merge: swap LOCAL and REMOTE for mergetool
From: Junio C Hamano @ 2013-03-07 0:36 UTC (permalink / raw)
To: Kevin Bracey; +Cc: git, David Aguilar, Ciaran Jessup, Scott Chacon
In-Reply-To: <1362601978-16911-2-git-send-email-kevin@bracey.fi>
Kevin Bracey <kevin@bracey.fi> writes:
> Reverse LOCAL and REMOTE when invoking P4Merge as a mergetool, so that
> the incoming branch is now in the left-hand, blue triangle pane, and the
> current branch is in the right-hand, green circle pane.
Given that the ordering of the three variants has been the way it is
since the very initial version by Scott, I'll sit on this patch
until hearing from those Cc'ed (who presumably do use p4merge,
unlike I who don't) that it is a good change.
Thanks.
^ permalink raw reply
* Re: fetch --no-tags with and w/o --all
From: Junio C Hamano @ 2013-03-07 0:41 UTC (permalink / raw)
To: Jeff King; +Cc: Cristian Tibirna, git
In-Reply-To: <20130307002038.GA31571@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Wed, Mar 06, 2013 at 01:56:01PM -0800, Junio C Hamano wrote:
>
>> Cristian Tibirna <ctibirna@giref.ulaval.ca> writes:
>>
>> > Hello
>> >
>> > $ git --version
>> > git version 1.7.10.4
>> >
>> > $ git fetch origin --no-tags
>> > does what it says
>> >
>> > $ git fetch --all --no-tags
>> > still gets all the tags from the remote.
>> >
>> > Is this known?
>>
>> Because --all (or --multiple) to iterate through all remotes
>> does not pass accept any command line refspecs, using these options
>> with --no-tags and/or --tags should be diagnosed as an error, but it
>> appears that the error checking is not done.
>
> Or we could just pass them through. Looks like this was already fixed by
> 8556646 (fetch --all: pass --tags/--no-tags through to each remote,
> 2012-09-05), which is in v1.7.12.2 and higher.
;-) No wonder this looked somewhat familiar.
^ permalink raw reply
* Re: feature suggestion: optimize common parts for checkout --conflict=diff3
From: Jeff King @ 2013-03-07 1:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Antoine Pelisse, Uwe Kleine-König, git, kernel
In-Reply-To: <7vip54p58p.fsf@alter.siamese.dyndns.org>
On Wed, Mar 06, 2013 at 01:50:46PM -0800, Junio C Hamano wrote:
> I think it is more like "I added bread and my wife added bread to
> our common shopping list" and our two-way "RCS merge" default is to
> collapse that case to "one loaf of bread on the shopping list". My
> impression has always been that people who use "diff3" mode care
> about this case and want to know that the original did not have
> "bread" on the list in order to decide if one or two loaves of bread
> should remain in the result.
I think that is only the case sometimes. It depends on what is in the
conflict, and what your data is. I think you are conflating two things,
though: zealousness of merge, and having the original content handy when
resolving. To me, diff3 is about the latter. It can also be a hint that
the user cares about the former, but not necessarily.
> > In Uwe's example,
> > it is just noise that detracts from the interesting part of the change
> > (or does it? I think the answer is in the eye of the reader).
>
> In other words, you would use the "RCS merge" style because most of
> the time you would resolve to "one loaf of bread" and the fact that
> it was missing in the original is not needed to decide that. So, it
> feels strange to use "diff3" and still want to discard that
> information---if it is not relevant, why are you using diff3 mode in
> the first place? That is the question that is still not answered.
Because for the lines that _are_ changed, you may want to see what the
original looked like. Here's a more realistic example:
git init repo
cd repo
# Some baseline C code.
cat >foo.c <<\EOF
int foo(int bar)
{
return bar + 5;
}
EOF
git add foo.c
git commit -m base
git tag base
# Simulate a modification to the function.
sed -i '2a\
if (bar < 3)\
bar *= 2;
' foo.c
git commit -am multiply
git tag multiply
# And another modification.
sed -i 's/bar + 5/bar + 7/' foo.c
git commit -am plus7
# Now on a side branch...
git checkout -b side base
# let's cherry pick the first change. Obviously
# we could just fast-forward in this toy example,
# but let's try to simulate a real history.
#
# We insert a sleep so that the cherry-pick does not
# accidentally end up with the exact same commit-id (again,
# because this is a toy example).
sleep 1
git cherry-pick multiply
# and now let's make a change that conflicts with later
# changes on master
sed -i 's/bar + 5/bar + 8/' foo.c
git commit -am plus8
# and now merge, getting a conflict
git merge master
# show the result with various marker styles
for i in merge diff3 zdiff3; do
echo
echo "==> $i"
git.compile checkout --conflict=$i foo.c
cat foo.c
done
which produces:
==> merge
int foo(int bar)
{
if (bar < 3)
bar *= 2;
<<<<<<< ours
return bar + 8;
=======
return bar + 7;
>>>>>>> theirs
}
The ZEALOUS level has helpfully cut out the shared cherry-picked bits,
and let us focus on the real change.
==> diff3
int foo(int bar)
{
<<<<<<< ours
if (bar < 3)
bar *= 2;
return bar + 8;
||||||| base
return bar + 5;
=======
if (bar < 3)
bar *= 2;
return bar + 7;
>>>>>>> theirs
}
Here we get to see all of the change, but the interesting difference is
overwhelmed by the shared cherry-picked bits. It's only 2 lines here,
but of course it could be much larger in a real example, and the reader
is forced to manually verify that the early parts are byte-for-byte
identical.
==> zdiff3
int foo(int bar)
{
if (bar < 3)
bar *= 2;
<<<<<<< ours
return bar + 8;
||||||| base
return bar + 5;
=======
return bar + 7;
>>>>>>> theirs
}
Here we see the hunk cut-down again, removing the cherry-picked parts.
But the presence of the base is still interesting, because we see
something that was not in the "merge" marker: that we were originally
at "5", and moved to "7" on one side and "8" on the other.
I see conflicts like this when I rebase my topics forward; you may pick
up part of my series, or even make a tweak to a patch in the middle. I
prefer diff3 markers because they carry more information (and use them
automatically via merge.conflictstyle). But in some cases, the lack of
zealous reduction means that I end having to figure out whether and if
anything changed in the seemingly identical bits. Sometimes it is
nothing, and sometimes you tweaked whitespace or fixed a typo, and it
takes a lot of manual looking to figure it out. I hadn't realized it was
related to the use of diff3 until the discussion today.
-Peff
^ permalink raw reply
* Please pull l10n updates for 1.8.2 round 4
From: Jiang Xin @ 2013-03-07 1:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Thielow, Tran Ngoc Quan, Peter Krefting, Git List
Hi Junio,
The following changes since commit 7799588faa2a8071da8ef047c87f9a1520fb8903:
Merge git://github.com/git-l10n/git-po (2013-03-04 01:16:02 -0800)
are available in the git repository at:
git://github.com/git-l10n/git-po master
for you to fetch changes up to a7409dfbc1c0d7e0c62f704a03a61bf669e90ae9:
l10n: zh_CN.po: translate 1 new message (2013-03-07 08:46:19 +0800)
----------------------------------------------------------------
Jiang Xin (2):
l10n: git.pot: v1.8.2 round 4 (1 changed)
l10n: zh_CN.po: translate 1 new message
Peter Krefting (1):
l10n: Update Swedish translation (2009t0f0u)
Ralf Thielow (1):
l10n: de.po: translate 1 new message
Tran Ngoc Quan (1):
l10n: vi.po: Update translation (2009t0f0u)
po/de.po | 16 +++++++++-------
po/git.pot | 4 ++--
po/sv.po | 8 ++++----
po/vi.po | 20 ++++++++++----------
po/zh_CN.po | 8 ++++----
5 files changed, 29 insertions(+), 27 deletions(-)
--
Jiang Xin
^ permalink raw reply
* Re: fetch --no-tags with and w/o --all
From: Jeff King @ 2013-03-07 1:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Cristian Tibirna, git
In-Reply-To: <7vhakonirb.fsf@alter.siamese.dyndns.org>
On Wed, Mar 06, 2013 at 04:41:44PM -0800, Junio C Hamano wrote:
> > Or we could just pass them through. Looks like this was already fixed by
> > 8556646 (fetch --all: pass --tags/--no-tags through to each remote,
> > 2012-09-05), which is in v1.7.12.2 and higher.
>
> ;-) No wonder this looked somewhat familiar.
I still find it somewhat gross that we actually re-construct the
command-line from the parsed flag variables. It seems like it would be
easier to simply propagate the argv we got in the first place, and then
we would not have any chance of omitting a new option that is added
later.
Probably not worth worrying about now, though, as the fix is long since
shipped. The next person who is adding an option can look at doing that
refactoring. And it may be that there are some options we don't
propagate intentionally (I didn't look closely).
-Peff
^ 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