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.
On 07/03/2013 02:36, Junio C Hamano wrote:
Kevin Bracey 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
On 07/03/2013 04:23, David Aguilar wrote:
On Wed, Mar 6, 2013 at 12:32 PM, Kevin Bracey wrote:
+make_virtual_base() {
+ # Copied from git-merge-one-file.sh.
I think the reasoning behind these patches is good.
How do we feel about this duplication?
Bad.
Should we make a common
On 07/03/2013 09:23, Junio C Hamano wrote:
If p4merge GUI labels one side clearly as "theirs" and the other
"ours", and the way we feed the inputs to it makes the side that is
actually "ours" appear in p4merge GUI labelled as "theirs", then I do
not think backward compatibility argument does no
new base) appear in blue; changes that do not
appear in the rebased commit (from the new base, or common to both) are
in green. If Perforce had rebase, they'd probably not swap ours/theirs,
but make P4Merge show common changes in blue, picking out our changes in
green. We can't do that, so
ch without
this flaw.
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 1236fbf..70f36f1 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-fil
ption, and I failed to come up with anything remotely elegant.
Kevin Bracey (3):
mergetools/p4merge: swap LOCAL and REMOTE
mergetools/p4merge: create a base if none available
git-merge-one-file: revise merge error reporting
git-merge-one-file.sh | 38
same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.
Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files. As with the other merge
"git help" translated the "See 'git help ' for more
information..." message, but "git" didn't.
Signed-off-by: Kevin Bracey
---
git.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git.c b/git.c
index d33f9b3..e484644 100644
--
o the only change to existing command behaviour is that "git help" or
"git help -w" now opens the git manual page, rather than showing common
commands.
"git -h cmd" is also accepted as a synonym for "git cmd -h", as per
Linus's rationale for treatin
Re-ordered option list in command-line usage to match the manual page.
Also makes it less than 80-characters wide.
Signed-off-by: Kevin Bracey
---
git.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index d33f9b3..2a98624 100644
--- a/git.c
+++ b/git.c
On 11/03/2013 21:58, Junio C Hamano wrote:
Kevin Bracey writes:
Re-ordered option list in command-line usage to match the manual page.
Also makes it less than 80-characters wide.
Thanks (s/Re-ordered/reorder/ and s/makes/make/, though).
Got it. But I'm going to reword it, to follo
Make the command line use the narrower synopsis layout that the man page
has used since commit 68e4b55.
Signed-off-by: Kevin Bracey
---
git.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/git.c b/git.c
index d33f9b3..2a98624 100644
--- a/git.c
+++ b/git.c
@@ -6,10
On 11/03/2013 05:03, Junio C Hamano wrote:
Hmm, I feel more confused than convinced after reading the above
three times. Perhaps that is because I am too used to the way how
"git" potty itself behaves, especially the part that "git help git"
is the way to ask "git" (the first token on the comman
same as the technique used in resolve and octopus
merges, so we relocate that code to a shared function.
Note that if there are no differences at the same location, this
technique can lead to automatic resolution without conflict, combining
everything from the 2 files. As with the other merge
ch without
this flaw.
Signed-off-by: Kevin Bracey
---
git-merge-one-file.sh | 20 +++-
1 file changed, 7 insertions(+), 13 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 0f164e5..78b07a8 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-fil
new base) appear in blue; changes that do not
appear in the rebased commit (from the new base, or common to both) are
in green. If Perforce had rebase, they'd probably not swap ours/theirs,
but make P4Merge show common changes in blue, picking out our changes in
green. We can't do that, so
On 13/03/2013 19:57, Junio C Hamano wrote:
Kevin Bracey writes:
- echo "Added $4 in both, but differently."
+ echo "ERROR: Added $4 in both, but differently."
+ ret=1
The problem you identified may be worth fixing, but I do not
On 14/03/2013 16:56, Junio C Hamano wrote:
Kevin Bracey writes:
Maybe the virtual base itself should be different. Maybe it should put
a ??? marker in place of every unique line. So you get:
Left ABCEFGH
Right XABCDEFJH -> Merge result <|X>ABC<|D>EFH
VBase ?ABC?EF??H
On 14/03/2013 19:31, Kevin Bracey wrote:
On 14/03/2013 16:56, Junio C Hamano wrote:
Well, yes, but I would assume that we would forcibly select normal
diff here somehow, if we aren't already. We should be - turning
ABCDEFGH vs ABCD into ABCD is silly.
Doh. But anyway, we don'
101 - 120 of 120 matches
Mail list logo
