* Re: jgit merge question
From: Shawn O. Pearce @ 2009-01-15 4:01 UTC (permalink / raw)
To: David Birchfield; +Cc: git
In-Reply-To: <7F1F22DF-7E4F-4888-A404-2A68F663989A@asu.edu>
David Birchfield <dbirchfield@asu.edu> wrote:
> thanks again for your help, and really sorry for the newbie questions.
>
> how do I grab those 8 commits?
>
> I did originally use git clone on this uri: git://
> android.git.kernel.org/tools/egit.git - but I don't see the
> modifications there.
They are in a side branch:
git pull git://android.git.kernel.org/tools/egit.git for-gerrit2
--
Shawn.
^ permalink raw reply
* Re: [PATCH v3] parse-opt: migrate builtin-ls-files.
From: Miklos Vajna @ 2009-01-15 3:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, git
In-Reply-To: <7vljtdw961.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 567 bytes --]
On Wed, Jan 14, 2009 at 07:16:38PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> I am not fundamentally opposed to the parseopt conversion, but I was
> somewhat discouraged from taking another one, after we got burned by the
> one that converted git-apply without much visible gain but with a new bug.
>
> Because ls-files is a plumbing, it has somewhat lower priority for user
> friendliness than any other patches currently in-flight on the list; hence
> it has been backburnered. It still is kept in my Inbox.
Makes sense, thanks for the answer.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: jgit merge question
From: David Birchfield @ 2009-01-15 3:47 UTC (permalink / raw)
To: git
In-Reply-To: <20090114231222.GB10179@spearce.org>
thanks again for your help, and really sorry for the newbie questions.
how do I grab those 8 commits?
I did originally use git clone on this uri: git://
android.git.kernel.org/tools/egit.git - but I don't see the
modifications there.
thanks again,
david
On Jan 14, 2009, at 4:12 PM, Shawn O. Pearce wrote:
>>
>
> Instead of copying 4 files, why don't you actually fetch the 8
> commits and merge them into your local repository? You are getting
> build errors because you didn't get an exception type in the errors
> directory, and at least two existing classes had new methods added
> to them in order to support the merge API.
>
> --
> Shawn.
^ permalink raw reply
* Re: [RFC PATCH] Zooko's merge testcase
From: Johannes Schindelin @ 2009-01-15 3:36 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git, zooko
In-Reply-To: <1231980818-24812-1-git-send-email-vmiklos@frugalware.org>
Hi,
On Thu, 15 Jan 2009, Miklos Vajna wrote:
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
I think the idea can be simplified. Given lines A, B, C in the base
commit, one branch _prepending_ the same triplet, and the other branch
changing the B to a D.
Only this time, nobody has a chance, even Darcs, because from the diff,
you would not know if it was prepended or appended.
(Which happens to be the same problem as 3-way merge has with the example
you were implementing; only when looking at the detailed history becomes
it clear what was done.)
This all just proves again that there can be no perfect merge strategy;
you'll always have to verify that the right thing was done.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make t3411 executable
From: Junio C Hamano @ 2009-01-15 3:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1231979599-24534-1-git-send-email-vmiklos@frugalware.org>
Thanks.
^ permalink raw reply
* Re: [PATCH v3] parse-opt: migrate builtin-ls-files.
From: Junio C Hamano @ 2009-01-15 3:16 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Pierre Habouzit, git
In-Reply-To: <20090115001410.GE30710@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Was this dropped on the floor by accident?
I am not fundamentally opposed to the parseopt conversion, but I was
somewhat discouraged from taking another one, after we got burned by the
one that converted git-apply without much visible gain but with a new bug.
Because ls-files is a plumbing, it has somewhat lower priority for user
friendliness than any other patches currently in-flight on the list; hence
it has been backburnered. It still is kept in my Inbox.
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Boyd Stephen Smith Jr. @ 2009-01-15 2:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anders Melchiorsen, git, Johannes.Schindelin
In-Reply-To: <7vfxjlxuu5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1190 bytes --]
On Wednesday 14 January 2009, Junio C Hamano <gitster@pobox.com> wrote
about 'Re: [RFC PATCH] Make the rebase edit mode really end up in an edit
state':
>Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>> I always have a hard time figuring out what to do during an
>> interactive rebase. Recently, it dawned on me that the reason is that
>> I have to do different things: one thing when editing on purpose, and
>> a different thing when resolving a conflict.
>>
>> With this change, I propose to make the UI more uniform. I think that
>> the new way is more intuitive, too, if you will agree that a Git UI
>> can be intuitive.
>>
>> I expect this to not be acceptable due to compatibility concerns.
>
>We may need a version bump to 1.7.0 to update the UI for this command,
> but please do test rigorously to build a stronger case for a saner UI.
Instead of changing the meaning of edit, how about introducing a "replace"
command?
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [ANNOUNCE] tig-0.13
From: bill lam @ 2009-01-15 1:46 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20090114235607.GA5546@diku.dk>
On Thu, 15 Jan 2009, Jonas Fonseca wrote:
> Yes, it works. You can either create a file called config.make with a
> line saying:
>
> LDLIBS = -lncursesw
>
> or use the configure file. If you are not using the tarball generate it
> with:
>
> make configure
I use the git source. Even after make configure and ./configure, it
still links to the non-unicode ncurses. Should it make ncursesw as
default if detected available albeit this can be changed manually?
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩319 李白 清平調三首之三
名花傾國兩相歡 常得君王帶笑看 解釋春風無限恨 沈香亭北倚闌干
^ permalink raw reply
* Re: [PATCH 4/4] color-words: make regex configurable via attributes
From: Johannes Schindelin @ 2009-01-15 1:43 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Santi Béjar, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0901150233121.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 15 Jan 2009, Johannes Schindelin wrote:
> @@ -136,10 +131,11 @@ cat > expect <<\EOF
> aaa (aaa) <GREEN>aaa<RESET>
> EOF
>
> -test_expect_success "test parsing words for newline" '
> +test_expect_success 'test parsing words for newline' '
> +
> + word_diff --color-words="a+"
>
> - word_diff --color-words="a+" &&
> - word_diff_check expect
> + word_diff --color-words=.
>
> '
D'oh. please remove the last word_diff, this comes from my "fix" for your
smiley issue.
Ciao,
Dscho "off to bed"
--
"The night was so dark that he hardly coulx srr tje keuboarf."
^ permalink raw reply
* Re: how to apply patch in the middle
From: Shawn O. Pearce @ 2009-01-15 1:39 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20090115013535.GB6937@b2j>
bill lam <cbill.lam@gmail.com> wrote:
> I want to change history to rewrite
>
> - A - B - C - D - E - ..
>
> as
>
> - A - C' - D - E - ..
Uh, "git rebase -i A", change "pick" on line "C" to "squash".
This should have the same impact as what you are trying.
> because rebase/squash cannot automatically resolve conflicts, I
> generate a patch file from A to C
>
> git diff A C >pat
>
> However I don't know how apply this patch and cancel the old B and C.
One way you can insert this is:
git rebase -i A^
change "pick" on line "A" to "edit"
delete lines "B" and "C".
when it stops for amend, don't amend.
git apply --index pat
git commit -m "my new B and C"
git rebase --continue
--
Shawn.
^ permalink raw reply
* Re: [PATCH replacement for take 3 4/4] color-words: take an optional regular expression describing words
From: Johannes Schindelin @ 2009-01-15 1:36 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Santi Béjar, Junio C Hamano, Teemu Likonen
In-Reply-To: <alpine.DEB.1.00.0901150211120.3586@pacific.mpi-cbg.de>
Hi,
On Thu, 15 Jan 2009, Johannes Schindelin wrote:
> On Thu, 15 Jan 2009, Thomas Rast wrote:
>
> > Johannes Schindelin wrote:
> > > This basically contains the fix I sent earlier.
> >
> > Unfortunately I found another case where it breaks. It even comes
> > with a fairly neat test case:
> >
> > $ g diff --no-index test_a test_b
> > diff --git 1/test_a 2/test_b
> > index 289cb9d..2d06f37 100644
> > --- 1/test_a
> > +++ 2/test_b
> > @@ -1 +1 @@
> > -(:
> > +(
>
> The diff of the words would look like this:
>
> diff --git a/a1 b/a2
> index 8309acb..2d06f37 100644
> --- a/a1
> +++ b/a2
> @@ -2 +1,0 @@
> -:
>
>
> Notice the "+1,0"? I fully expected this to be "+2,0", but apparently I
> was mistaken...
>
> Can anybody explain to me why this is so?
[PATCH to be squashed into the word regex patch] Fix for strange '@@ -2 +1,0 @@' hunk header
If a hunk header '@@ -2 +1,0 @@' is found that logically should be
'@@ -2 +2,0 @@', diff_words got confused.
It would bee squashed into 4/4.
This might be a libxdiff issue, though.
Not sure yet.
---
diff.c | 18 ++++++++++++++++++
t/t4034-diff-words.sh | 16 ++++++++++++++++
2 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/diff.c b/diff.c
index c5f7c57..3709651 100644
--- a/diff.c
+++ b/diff.c
@@ -360,6 +360,24 @@ static void fn_out_diff_words_aux(void *priv, char *line, unsigned long len)
plus_end = plus_len == 0 ? plus_begin :
diff_words->plus.orig[plus_first + plus_len - 1].end;
+ /*
+ * since this is a --unified=0 diff, it can result in a single hunk
+ * with a header like this: @@ -2 +1,0 @@
+ *
+ * This breaks the assumption that minus_first == plus_first.
+ *
+ * So we have to fix it: whenever we reach the end of pre and post
+ * texts, but nothing was added, we need to shift the plus part
+ * to the end of the buffer.
+ *
+ * It is only necessary for the plus part, as we show the common
+ * words from that buffer.
+ */
+ if (plus_len == 0 && minus_first + minus_len
+ == diff_words->minus.orig_nr)
+ plus_begin = plus_end =
+ diff_words->plus.orig[diff_words->plus.orig_nr - 1].end;
+
if (diff_words->current_plus != plus_begin)
fwrite(diff_words->current_plus,
plus_begin - diff_words->current_plus, 1,
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 07e48d1..817fba6 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -135,6 +135,22 @@ test_expect_success 'test parsing words for newline' '
word_diff --color-words="a+"
+'
+
+echo '(:' > pre
+echo '(' > post
+
+cat > expect <<\EOF
+<WHITE>diff --git a/pre b/post<RESET>
+<WHITE>index 289cb9d..2d06f37 100644<RESET>
+<WHITE>--- a/pre<RESET>
+<WHITE>+++ b/post<RESET>
+<BROWN>@@ -1 +1 @@<RESET>
+(<RED>:<RESET>
+EOF
+
+test_expect_success 'test when words are only removed at the end' '
+
word_diff --color-words=.
'
--
1.6.1.300.gbc493
^ permalink raw reply related
* how to apply patch in the middle
From: bill lam @ 2009-01-15 1:35 UTC (permalink / raw)
To: git
I want to change history to rewrite
- A - B - C - D - E - ..
as
- A - C' - D - E - ..
because rebase/squash cannot automatically resolve conflicts, I
generate a patch file from A to C
git diff A C >pat
However I don't know how apply this patch and cancel the old B and C.
Sorry for this newbie question.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
唐詩008 杜甫 望嶽
岱宗夫如何 齊魯青未了 造化鍾神秀 陰陽割昏曉
盪胸生層雲 決眥入歸鳥 會當凌絕頂 一覽眾山小
^ permalink raw reply
* Re: [PATCH 4/4] color-words: make regex configurable via attributes
From: Johannes Schindelin @ 2009-01-15 1:33 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Santi Béjar, Junio C Hamano
In-Reply-To: <b404fdfe0f5af535b35d1f239a68f6a7911ede19.1231971446.git.trast@student.ethz.ch>
Hi Thomas,
could you please squash this in?
-- snipsnap --
[PATCH to be squashed into the attributes patch] Decomplicate t4034 again
---
t/t4034-diff-words.sh | 50 ++++++++++++++++++++++--------------------------
1 files changed, 23 insertions(+), 27 deletions(-)
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 631ca44..07e48d1 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -22,10 +22,8 @@ decrypt_color () {
word_diff () {
test_must_fail git diff --no-index "$@" pre post > output &&
- decrypt_color < output > output.decrypted
-}
-word_diff_check () {
- test_cmp "$1" output.decrypted
+ decrypt_color < output > output.decrypted &&
+ test_cmp expect output.decrypted
}
cat > pre <<\EOF
@@ -82,12 +80,25 @@ EOF
test_expect_success 'word diff with a regular expression' '
- word_diff --color-words="[a-z]+" &&
- word_diff_check expect
+ word_diff --color-words="[a-z]+"
'
-cat > expect-by-chars <<\EOF
+test_expect_success 'set a diff driver' '
+ git config diff.testdriver.wordregex "[^[:space:]]" &&
+ cat <<EOF > .gitattributes
+pre diff=testdriver
+post diff=testdriver
+EOF
+'
+
+test_expect_success 'option overrides default' '
+
+ word_diff --color-words="[a-z]+"
+
+'
+
+cat > expect <<\EOF
<WHITE>diff --git a/pre b/post<RESET>
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
@@ -102,25 +113,9 @@ a = b + c<RESET>
<GREEN>aeff = aeff * ( aaa )<RESET>
EOF
-test_expect_success 'set a diff driver' '
- git config diff.testdriver.wordregex "[^[:space:]]" &&
- cat <<EOF > .gitattributes
-pre diff=testdriver
-post diff=testdriver
-EOF
-'
-
test_expect_success 'use default supplied by driver' '
- word_diff --color-words &&
- word_diff_check expect-by-chars
-
-'
-
-test_expect_success 'option overrides default' '
-
- word_diff --color-words="[a-z]+" &&
- word_diff_check expect
+ word_diff --color-words
'
@@ -136,10 +131,11 @@ cat > expect <<\EOF
aaa (aaa) <GREEN>aaa<RESET>
EOF
-test_expect_success "test parsing words for newline" '
+test_expect_success 'test parsing words for newline' '
+
+ word_diff --color-words="a+"
- word_diff --color-words="a+" &&
- word_diff_check expect
+ word_diff --color-words=.
'
--
1.6.1.300.gbc493
^ permalink raw reply related
* Re: [PATCH replacement for take 3 4/4] color-words: take an optional regular expression describing words
From: Johannes Schindelin @ 2009-01-15 1:12 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Santi Béjar, Junio C Hamano, Teemu Likonen
In-Reply-To: <200901150132.14106.trast@student.ethz.ch>
Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> Johannes Schindelin wrote:
> > This basically contains the fix I sent earlier.
>
> Unfortunately I found another case where it breaks. It even comes
> with a fairly neat test case:
>
> $ g diff --no-index test_a test_b
> diff --git 1/test_a 2/test_b
> index 289cb9d..2d06f37 100644
> --- 1/test_a
> +++ 2/test_b
> @@ -1 +1 @@
> -(:
> +(
The diff of the words would look like this:
diff --git a/a1 b/a2
index 8309acb..2d06f37 100644
--- a/a1
+++ b/a2
@@ -2 +1,0 @@
-:
Notice the "+1,0"? I fully expected this to be "+2,0", but apparently I
was mistaken...
Can anybody explain to me why this is so?
Ciao,
Dscho
^ permalink raw reply related
* Re: [PATCH] git-am: add --directory=<dir> option
From: Stephan Beyer @ 2009-01-15 1:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Simon 'corecode' Schubert, Kevin Ballard
In-Reply-To: <7vzlhtxvu5.fsf@gitster.siamese.dyndns.org>
Hi,
Junio C Hamano wrote:
> > Do I have a thinko or should it be this:
> >
> > + sed -e 's/'\''/'\''\\\'\'''\''/g' -e 's/.*/ '\''&'\''/'
> > ^^
> > (added for escaping ' outside single quotes)
>
> Almost.
>
> Certainly my original was bad; shell unquotes to "s/'/'\''/g", but that
> backslash is not protected from further interpretation by sed, which
> happily turns backslash-single quote into a single quote, which I forgot.
>
> You feed "s/'/'\\\''/g" which correctly protects one backslash from sed by
> doubling it, but it has one unnecessary extra backslash.
My attempt was to escape one backslash and to escape one single quote.
> The extra one
> does not hurt because the backslash + single quote is eaten by sed to
> produce a single quote, but it is not quite right.
Well, this explains why my syntax highlighting has "gone mad" in your
former and in my version.
> We should be feeding sed with "s/'/'\\''/g", so you need to add one
> backslash to mine.
Ok, works like a charm :-)
> > Have you forgotten to add the files prefixed with "am-test-5-" or is this
> > patch based on another one?
>
> The one I actually queued is b47dfe9 (git-am: add --directory=<dir>
> option, 2009-01-11) and it does include these test vectors. My bad.
Ohh, I did not even notice that you queued it, because I do not track "next".
And in my git-am.txt snippet I even forgot adding the option to the synopsis.
Oh, boy. :-)
I think it's fine now. :-)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* [PATCH/RFC v1 1/1] +5 cases (4 fail), diff whitespace tests
From: Keith Cascio @ 2009-01-15 0:48 UTC (permalink / raw)
To: git
+5 cases (4 fail), diff whitespace tests
There are 2^3 = eight possible combinations of the three flags:
-w -b --ignore-space-at-eol
Three of those combinations were already being tested:
[none]
-w
-b
Add tests of the other five combinations,
four of which fail with git
3cf3b838c7b379824c68ee87799aaaa9028b36cd
from Tue Jan 13 23:41:32 2009 -0800.
Signed-off-by: Keith Cascio <keith@cs.ucla.edu>
---
All four failures involve combining whitespace ignore options. It's likely the
fix will involve one or both of the following two functions in xdiff/xutils.c:
xdl_hash_record_with_whitespace()
xdl_recmatch()
I played around with it and discovered I could make
"git diff -b --ignore-space-at-eol" work by changing
if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
to
else if (flags & XDF_IGNORE_WHITESPACE_AT_EOL
But I don't know if that would break something else.
-- Keith
t/t4015-diff-whitespace.sh | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/t/t4015-diff-whitespace.sh b/t/t4015-diff-whitespace.sh
index fc2307e..dbb608c 100755
--- a/t/t4015-diff-whitespace.sh
+++ b/t/t4015-diff-whitespace.sh
@@ -98,6 +98,12 @@ index d99af23..8b32fb5 100644
EOF
git diff -w > out
test_expect_success 'another test, with -w' 'test_cmp expect out'
+git diff -w -b > out
+test_expect_failure 'another test, with -w -b' 'test_cmp expect out'
+git diff -w --ignore-space-at-eol > out
+test_expect_failure 'another test, with -w --ignore-space-at-eol' 'test_cmp expect out'
+git diff -w -b --ignore-space-at-eol > out
+test_expect_failure 'another test, with -w -b --ignore-space-at-eol' 'test_cmp expect out'
tr 'Q' '\015' << EOF > expect
diff --git a/x b/x
@@ -116,6 +122,27 @@ index d99af23..8b32fb5 100644
EOF
git diff -b > out
test_expect_success 'another test, with -b' 'test_cmp expect out'
+git diff -b --ignore-space-at-eol > out
+test_expect_failure 'another test, with -b --ignore-space-at-eol' 'test_cmp expect out'
+
+tr 'Q' '\015' << EOF > expect
+diff --git a/x b/x
+index d99af23..8b32fb5 100644
+--- a/x
++++ b/x
+@@ -1,6 +1,6 @@
+-whitespace at beginning
+-whitespace change
+-whitespace in the middle
++ whitespace at beginning
++whitespace change
++white space in the middle
+ whitespace at end
+ unchanged line
+ CR at endQ
+EOF
+git diff --ignore-space-at-eol > out
+test_expect_success 'another test, with --ignore-space-at-eol' 'test_cmp expect out'
test_expect_success 'check mixed spaces and tabs in indent' '
--
1.6.1.137.gb17b6
^ permalink raw reply related
* [RFC PATCH] Zooko's merge testcase
From: Miklos Vajna @ 2009-01-15 0:53 UTC (permalink / raw)
To: git; +Cc: zooko
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
The original page is here:
https://zooko.com/badmerge/simple.html
IIRC it was Robin who mentioned it on IRC.
I obviously not send this patch for inclusion, but to raise a
discussion: if I were a naive user I would think the merge will at least
result in a conflict, however actually it just gaves a wrong result.
t/t7608-merge-zooko.sh | 88 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 88 insertions(+), 0 deletions(-)
create mode 100755 t/t7608-merge-zooko.sh
diff --git a/t/t7608-merge-zooko.sh b/t/t7608-merge-zooko.sh
new file mode 100755
index 0000000..32609c0
--- /dev/null
+++ b/t/t7608-merge-zooko.sh
@@ -0,0 +1,88 @@
+#!/bin/sh
+
+test_description='git merge
+
+Testing merge with the examples of Zooko.'
+
+. ./test-lib.sh
+
+#
+# A - D \
+# \ B - C - E
+#
+test_expect_success 'setup' '
+ cat <<EOF >file &&
+A
+B
+C
+D
+E
+EOF
+ git add file &&
+ git commit -m A &&
+ git tag A &&
+ cat <<EOF >file &&
+G
+G
+G
+A
+B
+C
+D
+E
+EOF
+ git add file &&
+ git commit -m B &&
+ git tag B &&
+ cat <<EOF >file &&
+A
+B
+C
+D
+E
+G
+G
+G
+A
+B
+C
+D
+E
+EOF
+ git add file &&
+ git commit -m C &&
+ git tag C &&
+ git reset --hard A &&
+ cat <<EOF >file &&
+A
+B
+X
+D
+E
+EOF
+ git add file &&
+ git commit -m D &&
+ git tag D
+'
+
+test_expect_failure 'merge C' '
+ cat <<EOF >expected &&
+A
+B
+C
+D
+E
+G
+G
+G
+A
+B
+X
+D
+E
+EOF
+ git merge C &&
+ test_cmp expected file
+'
+
+test_done
--
1.6.1
^ permalink raw reply related
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Johannes Schindelin @ 2009-01-15 0:53 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster
In-Reply-To: <87ab9th0rh.fsf@cup.kalibalik.dk>
Hi,
On Thu, 15 Jan 2009, Anders Melchiorsen wrote:
> Previously, the interactive rebase edit mode placed the user after the
> commit in question. That was awkward because a commit is supposedly
> immutable. Thus, she was forced to use "git commit --amend" for her
> changes.
Maybe, maybe not. I frequently rebase with "edit" when I actually mean
"stop" (but "s" was taken from "squash" already). Then I test things,
possibly fixing them.
So in that case, I do not want a git reset --soft HEAD^.
In any case, there is a pretty obvious difference between a merge conflict
and a stop at "edit": the latter even shows you a pretty verbose
explanation what to do next.
I also have to admit that it escapes me why you would want to force a new
commit if nothing was changed to begin with.
However, I often would like to have "amend message" or some such, and I
remember having seen patches, but I do not remember why they did not make
it in.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Stephan Beyer @ 2009-01-15 0:49 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, gitster, Johannes.Schindelin
In-Reply-To: <87ab9th0rh.fsf@cup.kalibalik.dk>
Hi,
Anders Melchiorsen wrote:
> As I expect this to not be acceptable due to compatibility concerns, I
> have not tested it much. The patch is mostly to catch some attention,
> but I will be happy to complete it if there is interest in the change.
I think I like it and I think it's not the first time this comes up on
the list. (Not sure, and too lazy to grab the archives.)
Also, in the design process of "git-sequencer" we (at least my mentors
and I) discussed about doing this ("edit" vs "pause"), too, but it is
always bad to change behavior many people are used, too.
But sequencer instructions support options. So this could be solved as
an option for "edit", e.g. "edit --no-commit" (or "edit -n").
So I'm writing this on my TODO list for the time after sequencer is
merged into git...
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] checkout: implement "-" shortcut name for last branch
From: Johannes Schindelin @ 2009-01-15 0:45 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano
In-Reply-To: <1231977976-8739-1-git-send-email-trast@student.ethz.ch>
Hi,
On Thu, 15 Jan 2009, Thomas Rast wrote:
> Let git-checkout save the old branch as a symref in LAST_HEAD, and
> make 'git checkout -' switch back to LAST_HEAD, like 'cd -' does in
> the shell.
Actually, what you want is in the reflog, no? So... parsing
.git/logs/HEAD for the latest occurrence of "checkout: moving from " and
then using everything up until the next space should give you the branch
name, right?
It could be a SHA-1, though, if the last branch switch was from a detached
HEAD, though.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH] Make the rebase edit mode really end up in an edit state
From: Junio C Hamano @ 2009-01-15 0:43 UTC (permalink / raw)
To: Anders Melchiorsen; +Cc: git, Johannes.Schindelin
In-Reply-To: <87ab9th0rh.fsf@cup.kalibalik.dk>
Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
> I always have a hard time figuring out what to do during an
> interactive rebase. Recently, it dawned on me that the reason is that
> I have to do different things: one thing when editing on purpose, and
> a different thing when resolving a conflict. So my fingers never learn.
>
> With this change, I propose to make the UI more uniform. I think that
> the new way is more intuitive, too, if you will agree that a Git UI
> can be intuitive.
>
> As I expect this to not be acceptable due to compatibility concerns, I
> have not tested it much. The patch is mostly to catch some attention,
> but I will be happy to complete it if there is interest in the change.
>
> It was surprising for me to find the needed code already present. Now
> I know that I do not have to do "git commit --amend", it will happen
> automatically if I add some files. That trick alone is worth the time
> that I have spent on this :-).
We may need a version bump to 1.7.0 to update the UI for this command, but
please do test rigorously to build a stronger case for a saner UI.
I've always had trouble with the instruction we give for splitting one
commit into two using the interactive rebase in the documentation, as it
always had a strong "Huh?" effect on me when it suddenly starts talking
about doing a "git reset HEAD^"; I suspect your change may improve this
situation quite a bit.
^ permalink raw reply
* Re: [Q] git rebase -i -p conflicts with squash
From: Johannes Schindelin @ 2009-01-15 0:38 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50901140813r6e62ae53u1dbcd48cc472dbcc@mail.gmail.com>
Hi,
On Wed, 14 Jan 2009, Constantine Plotnikov wrote:
> If I run git rebase --interactive with --preserve-merges option and
> select "squash" for one of the commit, the rebase process fails with the
> message "Refusing to squash a merge:
> 5e775c536654640c173ba71a0af7e84bf8bc618a". However the neither commit
> participating in the squash is a merge commit. Even more, there are no
> merge commits in the repository at all.
>
> From my limited understanding of squash operation, it should fail only
> if one of squashed commits is a merge commit, but it should be possible
> to squash non-merge commits without problem as it looks like quite safe
> and local operation (and I might want to preserve merges that happened
> after squashed commits). Is it the current behaviour a bug or a feature?
>From your description, it seems that you are hitting an ordering bug of
rebase -i -p.
But without a reproduction recipe (preferably as a patch against our
testsuite), I cannot tell.
Ciao,
Dscho
^ permalink raw reply
* Re: git submodule merge madness
From: Johannes Schindelin @ 2009-01-15 0:36 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: git
In-Reply-To: <AE1922C4-0543-424B-A635-494445E17E45@develooper.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1197 bytes --]
Hi,
On Wed, 14 Jan 2009, Ask Bjørn Hansen wrote:
> On Jan 14, 2009, at 2:55 PM, Johannes Schindelin wrote:
>
> > >We've (again) replaced a few directories with submodules. Man, it's
> > >madness!
> > >
> > >The typical problem is that we get an error trying to merge a
> > >"pre-submodule" branch into master:
> > >
> > > fatal: cannot read object 894c77319a18c4d48119c2985a9275c9f5883584
> > >'some/sub/dir': It is a submodule!
> > >Mark Levedahl wrote an example in July, but I don't think he got any
> > >replies:
> > >http://marc.info/?l=git&m=121587851313303
> >
> >So.... Which Git version are you are using? Did you test any Git version
> >containing the commit d5a84fb(merge-recursive: fail gracefully with
> >directory/submodule conflicts)?
>
> IIRC I tried 1.6.1 and master as of about a week ago.
>
> I don't see d5a84fb in my repository (and google doesn't find it referenced
> anywhere when I search for "directory/submodule conflicts".
Well. Can do arithmetics in my head after midnight, but not think
straight...
In any case, could you please provide a patch to the testsuite
demonstrating the problem? History shows that such patches are very
helpful.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Make t3411 executable
From: Miklos Vajna @ 2009-01-15 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I just wanted had an old script, which did:
for i in *merge*
do
./$i
if [ $? != 0 ]; then
...
fi
done
which pointed out this permission problem.
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 t/t3411-rebase-preserve-around-merges.sh
diff --git a/t/t3411-rebase-preserve-around-merges.sh b/t/t3411-rebase-preserve-around-merges.sh
old mode 100644
new mode 100755
--
1.6.1
^ permalink raw reply
* Re: git submodule merge madness
From: Sverre Rabbelier @ 2009-01-15 0:32 UTC (permalink / raw)
To: Ask Bjørn Hansen; +Cc: Johannes Schindelin, git
In-Reply-To: <AE1922C4-0543-424B-A635-494445E17E45@develooper.com>
On Thu, Jan 15, 2009 at 00:49, Ask Bjørn Hansen <ask@develooper.com> wrote:
> On Jan 14, 2009, at 2:55 PM, Johannes Schindelin wrote:
>> So.... Which Git version are you are using? Did you test any Git version
>> containing the commit d5a84fb(merge-recursive: fail gracefully with
>> directory/submodule conflicts)?
>
> IIRC I tried 1.6.1 and master as of about a week ago.
>
> I don't see d5a84fb in my repository (and google doesn't find it referenced
> anywhere when I search for "directory/submodule conflicts".
I checked current master:
$ git log --grep="fail gracefully with"
returns nothing. Searching the archive I don't see any reference to
"fail gracefully with" either. I don't see it on your gitweb [0]
either. Did that commit magically dissapear?
[0] http://repo.or.cz/w/git/dscho.git
--
Cheers,
Sverre Rabbelier
^ 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