* Re: [PATCH RFC] rebase: add --revisions flag
From: Christian Couder @ 2009-12-09 5:30 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Stephan Beyer, Christian Couder, Daniel Barkalow,
Git List, Johannes Schindelin
In-Reply-To: <fabb9a1e0912081229l7990a148j9cd2daa338662dd@mail.gmail.com>
Hi,
On mardi 08 décembre 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Tue, Dec 8, 2009 at 21:22, Junio C Hamano <gitster@pobox.com> wrote:
> > But I think it is a reasonable thing to _implement_ the feature to
> > range-pick commits reusing the sequencing logic already in "rebase" and
> > "rebase -i". That essentially is what we wanted to do with "git
> > sequencer" that would be a sequencing logic backend shared among
> > rebase, cherry-pick, and perhaps am.
>
> Speaking of which, what's the status of git sequencer? I seem to
> remember some activity recently to slowly rewrite git rebase in c, but
> I haven't seen anything since then. Is it still moving forward? Is
> anyone interested in doing so? Just curious...
Last June and July, I sent some patch series to port "rebase -i" to C using
code from the sequencer project. My goal was to save some interesting code
from the sequencer GSoC 2008 project and at the same time to move
forward "rebase -i" code toward a sequencer.
But Dscho and Junio didn't like the fact that the code from the sequencer I
added was duplicating existing code and was not properly refactored, though
it also added things that would be needed later for the sequencer. My plan
was to refactor later, once I had a sequencer, but Junio and Dscho did not
like that plan. They said it would be a too big maintenance burden.
So I agreed to not duplicate any existing code and to properly refactor
everything. And I have been trying to take interesting and useful code from
the sequencer project and to integrate it into existing commands. And this
is why I sent yesterday the 4th version of my '"git reset --merge" related
improvements' patch series.
Best regards,
Christian.
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Junio C Hamano @ 2009-12-09 5:32 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, git
In-Reply-To: <4B1E798C.5050204@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
>> Michael J Gruber wrote:
>>
>>> +decrypt_color () {
>>> + sed \
>>> + -e 's/.\[1m/<WHITE>/g' \
>>> + -e 's/.\[31m/<RED>/g' \
>>> + -e 's/.\[32m/<GREEN>/g' \
>>> + -e 's/.\[34m/<BLUE>/g' \
>>> + -e 's/.\[m/<RESET>/g'
>>> +}
>>
>> Shouldn't this be better in test-lib.sh, or some common lib
>> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
>> in naming here)?
>
> Well, so far it's used in two places (and somewhat differently). I would
> say test-libification starts at 3 :)
That is a pretty lame excuse and is a bad way to keep things maintainable.
Having two copies now means that you will *double* the chance for the next
person to copy and paste one of the existing copies that are found in the
non-library-ish part of the test script set to create the third duplicate,
without even realizing that there already are two copies that should have
been consolidated in the first place. The worst part is that once that
duplication is pointed out, s/he will use the existing two copies as an
excuse for copy and paste.
Please don't.
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Junio C Hamano @ 2009-12-09 5:44 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, git
In-Reply-To: <7vzl5sww3w.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
>>> Michael J Gruber wrote:
>>>
>>>> +decrypt_color () {
>>>> + sed \
>>>> + -e 's/.\[1m/<WHITE>/g' \
>>>> + -e 's/.\[31m/<RED>/g' \
>>>> + -e 's/.\[32m/<GREEN>/g' \
>>>> + -e 's/.\[34m/<BLUE>/g' \
>>>> + -e 's/.\[m/<RESET>/g'
>>>> +}
>>>
>>> Shouldn't this be better in test-lib.sh, or some common lib
>>> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
>>> in naming here)?
>>
>> Well, so far it's used in two places (and somewhat differently). I would
>> say test-libification starts at 3 :)
> ...
> Please don't.
I'll squash this in to fix it up.
I don't know where 36->BROWN mistake came from when color.h has a
series of #define that can be used to make the decoding script
mechanically, though ;-)
t/t4034-diff-words.sh | 23 ++++---------
t/t7508-status.sh | 83 ++++++++++++++++++++++---------------------------
t/test-lib.sh | 11 ++++++
3 files changed, 55 insertions(+), 62 deletions(-)
diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
index 4508eff..ea895b0 100755
--- a/t/t4034-diff-words.sh
+++ b/t/t4034-diff-words.sh
@@ -11,18 +11,9 @@ test_expect_success setup '
'
-decrypt_color () {
- sed \
- -e 's/.\[1m/<WHITE>/g' \
- -e 's/.\[31m/<RED>/g' \
- -e 's/.\[32m/<GREEN>/g' \
- -e 's/.\[36m/<BROWN>/g' \
- -e 's/.\[m/<RESET>/g'
-}
-
word_diff () {
test_must_fail git diff --no-index "$@" pre post > output &&
- decrypt_color < output > output.decrypted &&
+ test_decode_color <output >output.decrypted &&
test_cmp expect output.decrypted
}
@@ -47,7 +38,7 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1,3 +1,7 @@<RESET>
+<CYAN>@@ -1,3 +1,7 @@<RESET>
<RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
<RESET>
a = b + c<RESET>
@@ -68,7 +59,7 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1,3 +1,7 @@<RESET>
+<CYAN>@@ -1,3 +1,7 @@<RESET>
h(4),<GREEN>hh<RESET>[44]
<RESET>
a = b + c<RESET>
@@ -104,7 +95,7 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1,3 +1,7 @@<RESET>
+<CYAN>@@ -1,3 +1,7 @@<RESET>
h(4)<GREEN>,hh[44]<RESET>
<RESET>
a = b + c<RESET>
@@ -146,7 +137,7 @@ cat > expect <<\EOF
<WHITE>index 330b04f..5ed8eff 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1,3 +1,7 @@<RESET>
+<CYAN>@@ -1,3 +1,7 @@<RESET>
h(4),<GREEN>hh[44<RESET>]
<RESET>
a = b + c<RESET>
@@ -168,7 +159,7 @@ cat > expect <<\EOF
<WHITE>index c29453b..be22f37 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1 +1 @@<RESET>
+<CYAN>@@ -1 +1 @@<RESET>
aaa (aaa) <GREEN>aaa<RESET>
EOF
@@ -187,7 +178,7 @@ cat > expect <<\EOF
<WHITE>index 289cb9d..2d06f37 100644<RESET>
<WHITE>--- a/pre<RESET>
<WHITE>+++ b/post<RESET>
-<BROWN>@@ -1 +1 @@<RESET>
+<CYAN>@@ -1 +1 @@<RESET>
(<RED>:<RESET>
EOF
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 50554a0..cf67fe3 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -8,45 +8,36 @@ test_description='git status'
. ./test-lib.sh
test_expect_success 'setup' '
- : > tracked &&
- : > modified &&
+ : >tracked &&
+ : >modified &&
mkdir dir1 &&
- : > dir1/tracked &&
- : > dir1/modified &&
+ : >dir1/tracked &&
+ : >dir1/modified &&
mkdir dir2 &&
- : > dir1/tracked &&
- : > dir1/modified &&
+ : >dir1/tracked &&
+ : >dir1/modified &&
git add . &&
git status >output &&
test_tick &&
git commit -m initial &&
- : > untracked &&
- : > dir1/untracked &&
- : > dir2/untracked &&
- echo 1 > dir1/modified &&
- echo 2 > dir2/modified &&
- echo 3 > dir2/added &&
+ : >untracked &&
+ : >dir1/untracked &&
+ : >dir2/untracked &&
+ echo 1 >dir1/modified &&
+ echo 2 >dir2/modified &&
+ echo 3 >dir2/added &&
git add dir2/added
'
-decrypt_color () {
- sed \
- -e 's/.\[1m/<WHITE>/g' \
- -e 's/.\[31m/<RED>/g' \
- -e 's/.\[32m/<GREEN>/g' \
- -e 's/.\[34m/<BLUE>/g' \
- -e 's/.\[m/<RESET>/g'
-}
-
test_expect_success 'status (1)' '
grep "use \"git rm --cached <file>\.\.\.\" to unstage" output
'
-cat > expect << \EOF
+cat >expect <<\EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
@@ -72,12 +63,12 @@ EOF
test_expect_success 'status (2)' '
- git status > output &&
+ git status >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M dir1/modified
A dir2/added
?? dir1/untracked
@@ -90,7 +81,7 @@ EOF
test_expect_success 'status -s (2)' '
- git status -s > output &&
+ git status -s >output &&
test_cmp expect output
'
@@ -112,8 +103,8 @@ cat >expect <<EOF
EOF
test_expect_success 'status -uno' '
mkdir dir3 &&
- : > dir3/untracked1 &&
- : > dir3/untracked2 &&
+ : >dir3/untracked1 &&
+ : >dir3/untracked2 &&
git status -uno >output &&
test_cmp expect output
'
@@ -258,7 +249,7 @@ test_expect_success 'status -s (status.showUntrackedFiles all)' '
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
@@ -284,12 +275,12 @@ EOF
test_expect_success 'status with relative paths' '
- (cd dir1 && git status) > output &&
+ (cd dir1 && git status) >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M modified
A ../dir2/added
?? untracked
@@ -301,12 +292,12 @@ A ../dir2/added
EOF
test_expect_success 'status -s with relative paths' '
- (cd dir1 && git status -s) > output &&
+ (cd dir1 && git status -s) >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M dir1/modified
A dir2/added
?? dir1/untracked
@@ -319,7 +310,7 @@ EOF
test_expect_success 'status --porcelain ignores relative paths setting' '
- (cd dir1 && git status --porcelain) > output &&
+ (cd dir1 && git status --porcelain) >output &&
test_cmp expect output
'
@@ -330,7 +321,7 @@ test_expect_success 'setup unique colors' '
'
-cat > expect << \EOF
+cat >expect <<\EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
@@ -357,7 +348,7 @@ EOF
test_expect_success 'status with color.ui' '
git config color.ui always &&
- git status | decrypt_color > output &&
+ git status | test_decode_color >output &&
test_cmp expect output
'
@@ -366,12 +357,12 @@ test_expect_success 'status with color.status' '
git config --unset color.ui &&
git config color.status always &&
- git status | decrypt_color > output &&
+ git status | test_decode_color >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
<RED>M<RESET> dir1/modified
<GREEN>A<RESET> dir2/added
<BLUE>??<RESET> dir1/untracked
@@ -386,7 +377,7 @@ test_expect_success 'status -s with color.ui' '
git config --unset color.status &&
git config color.ui always &&
- git status -s | decrypt_color > output &&
+ git status -s | test_decode_color >output &&
test_cmp expect output
'
@@ -395,12 +386,12 @@ test_expect_success 'status -s with color.status' '
git config --unset color.ui &&
git config color.status always &&
- git status -s | decrypt_color > output &&
+ git status -s | test_decode_color >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M dir1/modified
A dir2/added
?? dir1/untracked
@@ -415,7 +406,7 @@ test_expect_success 'status --porcelain ignores color.ui' '
git config --unset color.status &&
git config color.ui always &&
- git status --porcelain | decrypt_color > output &&
+ git status --porcelain | test_decode_color >output &&
test_cmp expect output
'
@@ -424,7 +415,7 @@ test_expect_success 'status --porcelain ignores color.status' '
git config --unset color.ui &&
git config color.status always &&
- git status --porcelain | decrypt_color > output &&
+ git status --porcelain | test_decode_color >output &&
test_cmp expect output
'
@@ -433,7 +424,7 @@ test_expect_success 'status --porcelain ignores color.status' '
git config --unset color.status
git config --unset color.ui
-cat > expect << \EOF
+cat >expect <<\EOF
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
@@ -461,12 +452,12 @@ EOF
test_expect_success 'status without relative paths' '
git config status.relativePaths false
- (cd dir1 && git status) > output &&
+ (cd dir1 && git status) >output &&
test_cmp expect output
'
-cat > expect << \EOF
+cat >expect <<\EOF
M dir1/modified
A dir2/added
?? dir1/untracked
@@ -479,7 +470,7 @@ EOF
test_expect_success 'status -s without relative paths' '
- (cd dir1 && git status -s) > output &&
+ (cd dir1 && git status -s) >output &&
test_cmp expect output
'
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5fdc5d9..d63ad2d 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -208,6 +208,17 @@ test_set_editor () {
export VISUAL
}
+test_decode_color () {
+ sed -e 's/.\[1m/<WHITE>/g' \
+ -e 's/.\[31m/<RED>/g' \
+ -e 's/.\[32m/<GREEN>/g' \
+ -e 's/.\[33m/<YELLOW>/g' \
+ -e 's/.\[34m/<BLUE>/g' \
+ -e 's/.\[35m/<MAGENTA>/g' \
+ -e 's/.\[36m/<CYAN>/g' \
+ -e 's/.\[m/<RESET>/g'
+}
+
test_tick () {
if test -z "${test_tick+set}"
then
^ permalink raw reply related
* Re: error: git-svn died of signal 13
From: Eric Wong @ 2009-12-09 5:58 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091209053602.GA2739@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> wrote:
> Hi,
>
> Just wanted to pass on a few reports about git-svn dying with SIGPIPE
> when trying to fetch large repositories. It seems to fetch a few
> revisions, then die; the repositories can eventually be fetched
> successfully by restarting 'git svn fetch' again and again.
>
> Some bug reporters have been very patient, but I don’t really know
> where to look or ask in solving this. Attempts at tracing so far have
> given either too little or too much information to make any sense.
>
> The problem goes back at least to v1.5.6.5.
Hi Jonathan,
Thanks for taking the time to look into this. This has been a
problem for a long time and very difficult to track down.
One factor is that git svn continues happily afterwards so it's hard to
reproduce and there's less incentive to look for a fix.
> At the end of the git-svn process’s life, the last few function calls
> are these:
>
> - SVN::Ra::Reporter::finish_report and related functions
> - _p_apr_pool_t::DESTROY (libsvn-perl cleaning up, presumably)
> - SVN::Ra::Callbacks::open_tmp_file, called from
> SVN::_Ra::svn_ra_do_update, called from
> Git::SVN::Ra::do_update, called from
> Git::SVN::Ra::gs_do_update
> - Git::SVN::_set_repos_root
> - starting a 'git update-index -z --index-info' to feed commands to
>
> Maybe /tmp is filling up? It is hard to know, since the SIGPIPE stops
> everything and we do not get any nice, simple error message describing
> what read or write would have received EPIPE.
>
> See <http://bugs.debian.org/526989>, <http://bugs.debian.org/540150>,
> <http://thread.gmane.org/gmane.comp.version-control.git/85868/>.
>
> Any insights?
Can somebody get an strace or core dump for the "git update-index"
call? Or even an strace -f of the entire git svn invocation as well...
--
Eric Wong
^ permalink raw reply
* Re: Weird message when pulling git version 1.6.6.rc1.39.g9a42
From: Junio C Hamano @ 2009-12-09 6:00 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Alejandro Riveira, git, Horst H. von Brand
In-Reply-To: <20091209125556.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Reverting them will still keep 76bf488 (Do not misidentify "git merge foo
>> HEAD" as an old-style invocation, 2009-12-02) that resulted in the change
>> we are reverting here, so we are still ahead ;-)
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/134103/focus=134145
>
> Sorry for causing too much trouble. I feel bad.
Oh, please don't be. You reported a real problem, and we do not shoot the
messengers.
^ permalink raw reply
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Junio C Hamano @ 2009-12-09 6:16 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Johannes Schindelin, Matthieu Moy, Michael J Gruber,
Michael Haggerty, git
In-Reply-To: <7viqchhl7h.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nanako Shiraishi <nanako3@lavabit.com> writes:
>
>> @@ -519,6 +521,43 @@ get_saved_options () {
>> test -f "$DOTEST"/rebase-root && REBASE_ROOT=t
>> }
>>
>> +# Rearrange the todo list that has both "pick sha1 msg" and
>> +# "pick sha1 !fixup/!squash msg" appears in it so that the latter
>> +# comes immediately after the former, and change "pick" to
>> +# "fixup"/"squash".
>> +rearrange_squash () {
>> + sed -n -e 's/^pick \([0-9a-f]*\) !\(squash\) /\1 \2 /p' \
>> + -e 's/^pick \([0-9a-f]*\) !\(fixup\) /\1 \2 /p' \
>> + "$1" >"$1.sq"
>> + test -s "$1.sq" || return
>> +
>> + sed -e '/^pick [0-9a-f]* !squash /d' \
>> + -e '/^pick [0-9a-f]* !fixup /d' \
>> + "$1" |
>> + (
>> + used=
>> + while read pick sha1 message
>> + do
>> + ...
>> + done >"$1.rearranged"
>> + )
>> + cat "$1.rearranged" >"$1"
>> + rm -f "$1.sq"
>> +}
>
> The logic to move the lines seem to have been improved since the last
> round, which is good. I've amended this to remove "$1.rearranged" as well.
Actually I think the logic in the version from the June is more correct;
doesn't this version drop commits that are marked as "squash! <message>"
but with a misspelled <message> part? I think your old version, when it
didn't find a matching one in early part, left such an unmatched "fixup"
in place.
Here is a fix-up patch I think should be squashed in. I added a test to
make sure that a mismatching "squash!" is kept in place. Please double
check for sanity.
Thanks.
git-rebase--interactive.sh | 38 ++++++++++++++++----------------------
t/t3415-rebase-autosquash.sh | 15 +++++++++++++++
2 files changed, 31 insertions(+), 22 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index c68cc5b..935e9e1 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -531,29 +531,23 @@ rearrange_squash () {
"$1" >"$1.sq"
test -s "$1.sq" || return
- sed -e '/^pick [0-9a-f]* squash! /d' \
- -e '/^pick [0-9a-f]* fixup! /d' \
- "$1" |
- (
- used=
- while read pick sha1 message
+ used=
+ while read pick sha1 message
+ do
+ case " $used" in
+ *" $sha1 "*) continue ;;
+ esac
+ echo "$pick $sha1 $message"
+ while read squash action msg
do
- echo "$pick $sha1 $message"
- while read squash action msg
- do
- case " $used" in
- *" $squash "*)
- continue ;;
- esac
- case "$message" in
- "$msg"*)
- echo "$action $squash $action! $msg"
- used="$used$squash "
- ;;
- esac
- done <"$1.sq"
- done >"$1.rearranged"
- )
+ case "$message" in
+ "$msg"*)
+ echo "$action $squash $action! $msg"
+ used="$used$squash "
+ ;;
+ esac
+ done <"$1.sq"
+ done >"$1.rearranged" <"$1"
cat "$1.rearranged" >"$1"
rm -f "$1.sq" "$1.rearranged"
}
diff --git a/t/t3415-rebase-autosquash.sh b/t/t3415-rebase-autosquash.sh
index f7a0f7a..b63f4e2 100755
--- a/t/t3415-rebase-autosquash.sh
+++ b/t/t3415-rebase-autosquash.sh
@@ -55,4 +55,19 @@ test_expect_success 'auto squash' '
test 2 = $(git cat-file commit HEAD^ | grep first | wc -l)
'
+test_expect_success 'misspelled auto squash' '
+ git reset --hard base &&
+ echo 1 >file1 &&
+ git add -u &&
+ test_tick &&
+ git commit -m "squash! forst"
+ git tag final-missquash &&
+ test_tick &&
+ git rebase --autosquash -i HEAD^^^ &&
+ git log --oneline >actual &&
+ test 4 = $(wc -l <actual) &&
+ git diff --exit-code final-missquash &&
+ test 0 = $(git rev-list final-missquash...HEAD | wc -l)
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH RFC] rebase: add --revisions flag
From: Christian Couder @ 2009-12-09 6:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Stephan Beyer, Christian Couder, Daniel Barkalow,
Git List, Johannes Schindelin
In-Reply-To: <200912090630.28506.chriscool@tuxfamily.org>
On mercredi 09 décembre 2009, Christian Couder wrote:
> Hi,
>
> On mardi 08 décembre 2009, Sverre Rabbelier wrote:
> > Heya,
> >
> > On Tue, Dec 8, 2009 at 21:22, Junio C Hamano <gitster@pobox.com> wrote:
> > > But I think it is a reasonable thing to _implement_ the feature to
> > > range-pick commits reusing the sequencing logic already in "rebase"
> > > and "rebase -i". That essentially is what we wanted to do with "git
> > > sequencer" that would be a sequencing logic backend shared among
> > > rebase, cherry-pick, and perhaps am.
> >
> > Speaking of which, what's the status of git sequencer? I seem to
> > remember some activity recently to slowly rewrite git rebase in c, but
> > I haven't seen anything since then. Is it still moving forward? Is
> > anyone interested in doing so? Just curious...
>
> Last June and July, I sent some patch series to port "rebase -i" to C
> using code from the sequencer project. My goal was to save some
> interesting code from the sequencer GSoC 2008 project and at the same
> time to move forward "rebase -i" code toward a sequencer.
>
> But Dscho and Junio didn't like the fact that the code from the sequencer
> I added was duplicating existing code and was not properly refactored,
> though it also added things that would be needed later for the sequencer.
> My plan was to refactor later, once I had a sequencer, but Junio and
> Dscho did not like that plan. They said it would be a too big maintenance
> burden.
>
> So I agreed to not duplicate any existing code and to properly refactor
> everything. And I have been trying to take interesting and useful code
> from the sequencer project and to integrate it into existing commands.
> And this is why I sent yesterday the 4th version of my '"git reset
> --merge" related improvements' patch series.
After that I plan to work on cherry-pick and that could be useful to
implement something like "git cherry-pick A..B".
See patch 11/15 from Stephan Beyer in my last "port rebase -i to C" series:
http://thread.gmane.org/gmane.comp.version-control.git/127256/focus=127259
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH v2 1/3] refactor ref status logic for pushing
From: Daniel Barkalow @ 2009-12-09 7:13 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Shawn O. Pearce, Sverre Rabbelier, Clemens Buchacher,
Jeff King, Junio C Hamano
In-Reply-To: <be6fef0d0912081940p63628d5eoab93a1a1f2676baa@mail.gmail.com>
On Wed, 9 Dec 2009, Tay Ray Chuan wrote:
> Hi,
>
> On Wed, Dec 9, 2009 at 1:17 AM, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > On Tue, 8 Dec 2009, Tay Ray Chuan wrote:
> >
> >> Move the logic that detects up-to-date and non-fast-forward refs to a
> >> new function in remote.[ch], set_ref_status_for_push().
> >
> > Is there some reason to not have set_ref_status_for_push() be static in
> > transport.c now? (Sorry for not suggesting this before.)
>
> it can't be static, because builtin-send-pack.c::main() needs it too.
Oh, right, fair enough.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: error: git-svn died of signal 13
From: Jonathan Nieder @ 2009-12-09 7:53 UTC (permalink / raw)
To: Frederik Hohlfeld, Adam Borowski, David Förster; +Cc: Eric Wong, git
In-Reply-To: <20091209055824.GA22941@dcvr.yhbt.net>
CCing those who reported the problem. There is some debugging advice below,
for anyone who wants to take a further stab at tracking this down.
Eric Wong wrote:
> Jonathan Nieder <jrnieder@gmail.com> wrote:
>> Just wanted to pass on a few reports about git-svn dying with SIGPIPE
>> when trying to fetch large repositories. It seems to fetch a few
>> revisions, then die; the repositories can eventually be fetched
>> successfully by restarting 'git svn fetch' again and again.
>>
>> Some bug reporters have been very patient, but I don’t really know
>> where to look or ask in solving this. Attempts at tracing so far have
>> given either too little or too much information to make any sense.
>>
>> The problem goes back at least to v1.5.6.5.
>
> Hi Jonathan,
>
> Thanks for taking the time to look into this. This has been a
> problem for a long time and very difficult to track down.
>
> One factor is that git svn continues happily afterwards so it's hard to
> reproduce and there's less incentive to look for a fix.
>
>> At the end of the git-svn process’s life, the last few function calls
>> are these:
>>
>> - SVN::Ra::Reporter::finish_report and related functions
>> - _p_apr_pool_t::DESTROY (libsvn-perl cleaning up, presumably)
>> - SVN::Ra::Callbacks::open_tmp_file, called from
>> SVN::_Ra::svn_ra_do_update, called from
>> Git::SVN::Ra::do_update, called from
>> Git::SVN::Ra::gs_do_update
>> - Git::SVN::_set_repos_root
>> - starting a 'git update-index -z --index-info' to feed commands to
>>
>> Maybe /tmp is filling up? It is hard to know, since the SIGPIPE stops
>> everything and we do not get any nice, simple error message describing
>> what read or write would have received EPIPE.
>>
>> See <http://bugs.debian.org/526989>, <http://bugs.debian.org/540150>,
>> <http://thread.gmane.org/gmane.comp.version-control.git/85868/>.
>>
>> Any insights?
>
> Can somebody get an strace or core dump for the "git update-index"
> call? Or even an strace -f of the entire git svn invocation as well...
^ permalink raw reply
* Re: help: bisect single file from repos
From: Nanako Shiraishi @ 2009-12-09 8:27 UTC (permalink / raw)
To: szeder; +Cc: Junio C Hamano, git, Christian Couder, Michael J Gruber, wharms
In-Reply-To: <20091209012855.GA3208@neumann>
Quoting SZEDER Gábor <szeder@ira.uka.de>
> [1] - 'git cherry-pick' doc says the following:
>
> <commit>
> Commit to cherry-pick. For a more complete list of ways to spell
> commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
>
> What? "A _more_ complete list"!? Well, it's not very hard to be more
> complete than this, there is not a single way described here (;
I agree that "more" shouldn't be in that sentence, and I understand your hesitation to read plumbing manual pages, but I don't think it is a sane solution to the issue to repeat how to name a commit in manual pages for every single command to bloat the two line description you quoted into a half-page paragraph. Even within that two lines, the real information that should be in the manual for cherry-pick is only three words "Commit to cherry-pick" and the rest is to help people who don't know.
Maybe it is a better idea to rewrite this to "See 'basic concepts' manual for how to specify a commit", and create a new 'basic concepts' manual that describes these things the readers must know to effectively use the main part of the manual. And make sure that we try very hard to keep the 'basic concepts' manual short, by eg. making a goal to keep it less than N printed pages.
To decide the value of 'N', somebody needs to first think and list the topics that need to be covered by 'basic concepts'. Something like this?
* What are committed states, the state in the index and the state in the working tree.
* How to name a commit.
* How to name a range of commit (move part from the rev-parse manual).
* How to specify options, revisions and files on command line (move part from the gitcli manual).
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* rerere failed to parse conflict hunks
From: Uwe Kleine-König @ 2009-12-09 8:46 UTC (permalink / raw)
To: git
Hello,
I just tried to merge linux-next
(5c1af82119f11c5b322156b09d38cc37318849c4) into my private tree
(based on 2b876f95d03e226394b5d360c86127cbefaf614b) and this
happened:
...
Removing sound/soc/au1x/sample-ac97.c
Recorded preimage for 'arch/Kconfig'
Recorded preimage for 'arch/arm/mach-s3c2440/mach-anubis.c'
Recorded preimage for 'arch/arm/plat-mxc/Makefile'
error: Could not parse conflict hunks in arch/arm/plat-s3c/dev-hsmmc2.c
Recorded preimage for 'arch/arm/plat-s3c/include/plat/sdhci.h'
Recorded preimage for 'arch/arm/plat-samsung/Kconfig'
Recorded preimage for 'arch/x86/include/asm/x86_init.h'
Recorded preimage for 'arch/x86/kernel/x86_init.c'
Recorded preimage for 'drivers/net/wireless/ray_cs.c'
Recorded preimage for 'kernel/Makefile'
Recorded preimage for 'kernel/power/hibernate.c'
Recorded preimage for 'net/sctp/sysctl.c'
Automatic merge failed; fix conflicts and then commit the result.
If you are interested, I can provide you the two trees above. When
reproducing the line "error: ..." came later, but is still present.
I guess this should be reproduceable with
git clone -n git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git remote add -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git checkout 2b876f95d03e226394b5d360c86127cbefaf614b
git merge 5c1af82119f11c5b322156b09d38cc37318849c4
I havn't tried though.
The only non-trivial conflict is:
#include <plat/sdhci.h>
#include <plat/devs.h>
<<<<<<< HEAD
=======
<<<<<<< HEAD
#include <plat/cpu.h>
=======
>>>>>>> next-s5pc1xx
>>>>>>> next/master
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Peter Krefting @ 2009-12-09 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
In-Reply-To: <7vfx7lcj18.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Many people wanted to have "pick many commits onto the current HEAD" and I
> think it would be a natural, uncontroversial and welcome addition to allow
> "git cherry-pick A..B".
Or even "git cherry-pick branch", as I naïvely tried doing before I
understood what it did. This is definitely a feature that would help me.
The question of where it goes is actually a bit difficult, it is the same
mode of operation as "git rebase", only the other way around. It is the same
as "git cherry-pick", but called multiple times. And it is the same as "git
merge --squash", but without squashing the commits into one.
So does this new mode go into rebase, cherry-pick or merge, or into all
three? No matter which, proper documentation is needed.
Maybe this could also be used to implement a "git merge --squash A..B", a.k.a
a "partial merge". (And if it could be implemented to allow a "git merge A..B"
and later do a "git merge B" to merge the rest of the side-branch, that
would be interesting).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [REROLL PATCH 3/8] Pass unknown protocols to external protocol handlers
From: Bert Wesarg @ 2009-12-09 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, git
In-Reply-To: <7vskbl59ai.fsf@alter.siamese.dyndns.org>
On Wed, Dec 9, 2009 at 00:35, Junio C Hamano <gitster@pobox.com> wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>> + } else if (!is_url(url)
>> + || !prefixcmp(url, "file://")
>> + || !prefixcmp(url, "git://")
>> + || !prefixcmp(url, "ssh://")
>> + || !prefixcmp(url, "git+ssh://")
>> + || !prefixcmp(url, "ssh+git://")) {
>> + /* These are builtin smart transports. */
>
> Hmm, what is !is_url(url) at the beginning for, if this lists "builtin"
> smart transports?
I think/hope this should catch theses use cases:
? [user@]host.xz:/path/to/repo.git/
? [user@]host.xz:~user/path/to/repo.git/
? [user@]host.xz:path/to/repo.git
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Sverre Rabbelier @ 2009-12-09 9:08 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, Stephan Beyer, Christian Couder, Daniel Barkalow,
Git List, Johannes Schindelin
In-Reply-To: <200912090752.51609.chriscool@tuxfamily.org>
Heya,
On Wed, Dec 9, 2009 at 07:52, Christian Couder <chriscool@tuxfamily.org> wrote:
<snip>
> After that I plan to work on cherry-pick and that could be useful to
> implement something like "git cherry-pick A..B".
Ah, okay, thanks for the update!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Michael J Gruber @ 2009-12-09 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vmy1swvjc.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 09.12.2009 06:32/06:44:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> > Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
>>> >> Michael J Gruber wrote:
>>> >>
>>>> >>> +decrypt_color () {
>>>> >>> + sed \
>>>> >>> + -e 's/.\[1m/<WHITE>/g' \
>>>> >>> + -e 's/.\[31m/<RED>/g' \
>>>> >>> + -e 's/.\[32m/<GREEN>/g' \
>>>> >>> + -e 's/.\[34m/<BLUE>/g' \
>>>> >>> + -e 's/.\[m/<RESET>/g'
>>>> >>> +}
>>> >>
>>> >> Shouldn't this be better in test-lib.sh, or some common lib
>>> >> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
>>> >> in naming here)?
>> >
>> > Well, so far it's used in two places (and somewhat differently). I would
>> > say test-libification starts at 3 :)
> That is a pretty lame excuse and is a bad way to keep things maintainable.
>
> Having two copies now means that you will *double* the chance for the next
> person to copy and paste one of the existing copies that are found in the
> non-library-ish part of the test script set to create the third duplicate,
> without even realizing that there already are two copies that should have
> been consolidated in the first place. The worst part is that once that
> duplication is pointed out, s/he will use the existing two copies as an
> excuse for copy and paste.
>
> Please don't.
>
Okay okay, I guess I have to spell out my smileys better in the future.
The real question for us (Jakub and me) was where to put the code. I
think by giving that info I could have been easily convinced to do that
step...
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
>>>> Michael J Gruber wrote:
>>>>
>>>>> +decrypt_color () {
>>>>> + sed \
>>>>> + -e 's/.\[1m/<WHITE>/g' \
>>>>> + -e 's/.\[31m/<RED>/g' \
>>>>> + -e 's/.\[32m/<GREEN>/g' \
>>>>> + -e 's/.\[34m/<BLUE>/g' \
>>>>> + -e 's/.\[m/<RESET>/g'
>>>>> +}
>>>>
>>>> Shouldn't this be better in test-lib.sh, or some common lib
>>>> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
>>>> in naming here)?
>>>
>>> Well, so far it's used in two places (and somewhat differently). I would
>>> say test-libification starts at 3 :)
>> ...
>> Please don't.
>
> I'll squash this in to fix it up.
>
> I don't know where 36->BROWN mistake came from when color.h has a
> series of #define that can be used to make the decoding script
> mechanically, though ;-)
I don't know either, I didn't make it - I even corrected it in my copy -
which proves your former point, of course.
> t/t4034-diff-words.sh | 23 ++++---------
> t/t7508-status.sh | 83 ++++++++++++++++++++++---------------------------
> t/test-lib.sh | 11 ++++++
> 3 files changed, 55 insertions(+), 62 deletions(-)
>
> diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
> index 4508eff..ea895b0 100755
> --- a/t/t4034-diff-words.sh
> +++ b/t/t4034-diff-words.sh
> @@ -11,18 +11,9 @@ test_expect_success setup '
>
> '
>
> -decrypt_color () {
> - sed \
> - -e 's/.\[1m/<WHITE>/g' \
> - -e 's/.\[31m/<RED>/g' \
> - -e 's/.\[32m/<GREEN>/g' \
> - -e 's/.\[36m/<BROWN>/g' \
> - -e 's/.\[m/<RESET>/g'
> -}
> -
> word_diff () {
> test_must_fail git diff --no-index "$@" pre post > output &&
> - decrypt_color < output > output.decrypted &&
> + test_decode_color <output >output.decrypted &&
> test_cmp expect output.decrypted
> }
>
> @@ -47,7 +38,7 @@ cat > expect <<\EOF
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1,3 +1,7 @@<RESET>
> +<CYAN>@@ -1,3 +1,7 @@<RESET>
> <RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
> <RESET>
> a = b + c<RESET>
> @@ -68,7 +59,7 @@ cat > expect <<\EOF
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1,3 +1,7 @@<RESET>
> +<CYAN>@@ -1,3 +1,7 @@<RESET>
> h(4),<GREEN>hh<RESET>[44]
> <RESET>
> a = b + c<RESET>
> @@ -104,7 +95,7 @@ cat > expect <<\EOF
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1,3 +1,7 @@<RESET>
> +<CYAN>@@ -1,3 +1,7 @@<RESET>
> h(4)<GREEN>,hh[44]<RESET>
> <RESET>
> a = b + c<RESET>
> @@ -146,7 +137,7 @@ cat > expect <<\EOF
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1,3 +1,7 @@<RESET>
> +<CYAN>@@ -1,3 +1,7 @@<RESET>
> h(4),<GREEN>hh[44<RESET>]
> <RESET>
> a = b + c<RESET>
> @@ -168,7 +159,7 @@ cat > expect <<\EOF
> <WHITE>index c29453b..be22f37 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1 +1 @@<RESET>
> +<CYAN>@@ -1 +1 @@<RESET>
> aaa (aaa) <GREEN>aaa<RESET>
> EOF
>
> @@ -187,7 +178,7 @@ cat > expect <<\EOF
> <WHITE>index 289cb9d..2d06f37 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1 +1 @@<RESET>
> +<CYAN>@@ -1 +1 @@<RESET>
> (<RED>:<RESET>
> EOF
>
> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
> index 50554a0..cf67fe3 100755
> --- a/t/t7508-status.sh
> +++ b/t/t7508-status.sh
> @@ -8,45 +8,36 @@ test_description='git status'
> . ./test-lib.sh
>
> test_expect_success 'setup' '
> - : > tracked &&
> - : > modified &&
> + : >tracked &&
> + : >modified &&
> mkdir dir1 &&
> - : > dir1/tracked &&
> - : > dir1/modified &&
> + : >dir1/tracked &&
> + : >dir1/modified &&
> mkdir dir2 &&
> - : > dir1/tracked &&
> - : > dir1/modified &&
> + : >dir1/tracked &&
> + : >dir1/modified &&
> git add . &&
>
> git status >output &&
>
> test_tick &&
> git commit -m initial &&
> - : > untracked &&
> - : > dir1/untracked &&
> - : > dir2/untracked &&
> - echo 1 > dir1/modified &&
> - echo 2 > dir2/modified &&
> - echo 3 > dir2/added &&
> + : >untracked &&
> + : >dir1/untracked &&
> + : >dir2/untracked &&
> + echo 1 >dir1/modified &&
> + echo 2 >dir2/modified &&
> + echo 3 >dir2/added &&
> git add dir2/added
> '
>
> -decrypt_color () {
> - sed \
> - -e 's/.\[1m/<WHITE>/g' \
> - -e 's/.\[31m/<RED>/g' \
> - -e 's/.\[32m/<GREEN>/g' \
> - -e 's/.\[34m/<BLUE>/g' \
> - -e 's/.\[m/<RESET>/g'
> -}
> -
> test_expect_success 'status (1)' '
>
> grep "use \"git rm --cached <file>\.\.\.\" to unstage" output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> @@ -72,12 +63,12 @@ EOF
>
> test_expect_success 'status (2)' '
>
> - git status > output &&
> + git status >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M dir1/modified
> A dir2/added
> ?? dir1/untracked
> @@ -90,7 +81,7 @@ EOF
>
> test_expect_success 'status -s (2)' '
>
> - git status -s > output &&
> + git status -s >output &&
> test_cmp expect output
>
> '
> @@ -112,8 +103,8 @@ cat >expect <<EOF
> EOF
> test_expect_success 'status -uno' '
> mkdir dir3 &&
> - : > dir3/untracked1 &&
> - : > dir3/untracked2 &&
> + : >dir3/untracked1 &&
> + : >dir3/untracked2 &&
> git status -uno >output &&
> test_cmp expect output
> '
> @@ -258,7 +249,7 @@ test_expect_success 'status -s (status.showUntrackedFiles all)' '
> test_cmp expect output
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> @@ -284,12 +275,12 @@ EOF
>
> test_expect_success 'status with relative paths' '
>
> - (cd dir1 && git status) > output &&
> + (cd dir1 && git status) >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M modified
> A ../dir2/added
> ?? untracked
> @@ -301,12 +292,12 @@ A ../dir2/added
> EOF
> test_expect_success 'status -s with relative paths' '
>
> - (cd dir1 && git status -s) > output &&
> + (cd dir1 && git status -s) >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M dir1/modified
> A dir2/added
> ?? dir1/untracked
> @@ -319,7 +310,7 @@ EOF
>
> test_expect_success 'status --porcelain ignores relative paths setting' '
>
> - (cd dir1 && git status --porcelain) > output &&
> + (cd dir1 && git status --porcelain) >output &&
> test_cmp expect output
>
> '
> @@ -330,7 +321,7 @@ test_expect_success 'setup unique colors' '
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> @@ -357,7 +348,7 @@ EOF
> test_expect_success 'status with color.ui' '
>
> git config color.ui always &&
> - git status | decrypt_color > output &&
> + git status | test_decode_color >output &&
> test_cmp expect output
>
> '
> @@ -366,12 +357,12 @@ test_expect_success 'status with color.status' '
>
> git config --unset color.ui &&
> git config color.status always &&
> - git status | decrypt_color > output &&
> + git status | test_decode_color >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> <RED>M<RESET> dir1/modified
> <GREEN>A<RESET> dir2/added
> <BLUE>??<RESET> dir1/untracked
> @@ -386,7 +377,7 @@ test_expect_success 'status -s with color.ui' '
>
> git config --unset color.status &&
> git config color.ui always &&
> - git status -s | decrypt_color > output &&
> + git status -s | test_decode_color >output &&
> test_cmp expect output
>
> '
> @@ -395,12 +386,12 @@ test_expect_success 'status -s with color.status' '
>
> git config --unset color.ui &&
> git config color.status always &&
> - git status -s | decrypt_color > output &&
> + git status -s | test_decode_color >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M dir1/modified
> A dir2/added
> ?? dir1/untracked
> @@ -415,7 +406,7 @@ test_expect_success 'status --porcelain ignores color.ui' '
>
> git config --unset color.status &&
> git config color.ui always &&
> - git status --porcelain | decrypt_color > output &&
> + git status --porcelain | test_decode_color >output &&
> test_cmp expect output
>
> '
> @@ -424,7 +415,7 @@ test_expect_success 'status --porcelain ignores color.status' '
>
> git config --unset color.ui &&
> git config color.status always &&
> - git status --porcelain | decrypt_color > output &&
> + git status --porcelain | test_decode_color >output &&
> test_cmp expect output
>
> '
> @@ -433,7 +424,7 @@ test_expect_success 'status --porcelain ignores color.status' '
> git config --unset color.status
> git config --unset color.ui
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> @@ -461,12 +452,12 @@ EOF
> test_expect_success 'status without relative paths' '
>
> git config status.relativePaths false
> - (cd dir1 && git status) > output &&
> + (cd dir1 && git status) >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M dir1/modified
> A dir2/added
> ?? dir1/untracked
> @@ -479,7 +470,7 @@ EOF
>
> test_expect_success 'status -s without relative paths' '
>
> - (cd dir1 && git status -s) > output &&
> + (cd dir1 && git status -s) >output &&
> test_cmp expect output
>
> '
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 5fdc5d9..d63ad2d 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -208,6 +208,17 @@ test_set_editor () {
> export VISUAL
> }
>
> +test_decode_color () {
> + sed -e 's/.\[1m/<WHITE>/g' \
> + -e 's/.\[31m/<RED>/g' \
> + -e 's/.\[32m/<GREEN>/g' \
> + -e 's/.\[33m/<YELLOW>/g' \
> + -e 's/.\[34m/<BLUE>/g' \
> + -e 's/.\[35m/<MAGENTA>/g' \
> + -e 's/.\[36m/<CYAN>/g' \
> + -e 's/.\[m/<RESET>/g'
> +}
> +
> test_tick () {
> if test -z "${test_tick+set}"
> then
Regarding the larger part of your change: Is there a specific reason for
">output" rather than "> output" or just a style issue? I was simply
following the style which I found present in t7508 (same goes for empty
leading and trailing lines in the test bodies).
Michael
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-09 9:37 UTC (permalink / raw)
To: Peter Krefting; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0912090941420.470@ds9.cixit.se>
On Wed, Dec 09, 2009 at 09:47:56AM +0100, Peter Krefting wrote:
> Junio C Hamano:
>
>> Many people wanted to have "pick many commits onto the current HEAD"
>> and I think it would be a natural, uncontroversial and welcome addition
>> to allow "git cherry-pick A..B".
>
> Or even "git cherry-pick branch", as I naïvely tried doing before I
> understood what it did. This is definitely a feature that would help me.
>
> The question of where it goes is actually a bit difficult, it is the same
> mode of operation as "git rebase", only the other way around. It is the
> same as "git cherry-pick", but called multiple times. And it is the same
> as "git merge --squash", but without squashing the commits into one.
>
> So does this new mode go into rebase, cherry-pick or merge, or into all
> three? No matter which, proper documentation is needed.
>
>
> Maybe this could also be used to implement a "git merge --squash A..B",
> a.k.a a "partial merge".
What exactly should it do?
> (And if it could be implemented to allow a "git
> merge A..B" and later do a "git merge B" to merge the rest of the
> side-branch, that would be interesting).
rebase already tries to detect previously applied commits.
Maybe we can teach it to use more heuristics.
> --
> \\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: help: bisect single file from repos
From: SZEDER Gábor @ 2009-12-09 9:45 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, git, Christian Couder, Michael J Gruber, wharms
In-Reply-To: <20091209172737.6117@nanako3.lavabit.com>
Hi,
On Wed, Dec 09, 2009 at 05:27:37PM +0900, Nanako Shiraishi wrote:
> Quoting SZEDER Gábor <szeder@ira.uka.de>
>
> > [1] - 'git cherry-pick' doc says the following:
> >
> > <commit>
> > Commit to cherry-pick. For a more complete list of ways to spell
> > commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
> >
> > What? "A _more_ complete list"!? Well, it's not very hard to be more
> > complete than this, there is not a single way described here (;
>
> I agree that "more" shouldn't be in that sentence, and I understand
> your hesitation to read plumbing manual pages, but I don't think it
> is a sane solution to the issue to repeat how to name a commit in
> manual pages for every single command to bloat the two line
> description you quoted into a half-page paragraph. Even within that
> two lines, the real information that should be in the manual for
> cherry-pick is only three words "Commit to cherry-pick" and the rest
> is to help people who don't know.
I agree, that's why I proposed "a _section_ about specifying these
commits" in the more relevant part of my previous email you did not
quote.
The description of the "<commit>" option would remain almost the same,
but it will now refer to a dedicated section about specifying commits
below, but still in the same manpage. This new dedicated section
would contain the list of three, five, N most common ways to specify a
commit, avoiding the bloatage in the options section. And for those
who really want to dig deep, this dedicated section will refer to 'git
rev-parse' for the complete list.
And this would not be the first time we document something in many
places, think of '--pretty' and diff options, for example.
Best,
Gábor
^ permalink raw reply
* Re: rerere failed to parse conflict hunks
From: Michael J Gruber @ 2009-12-09 9:47 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20091209084648.GA30139@pengutronix.de>
Uwe Kleine-König venit, vidit, dixit 09.12.2009 09:46:
> Hello,
>
> I just tried to merge linux-next
> (5c1af82119f11c5b322156b09d38cc37318849c4) into my private tree
> (based on 2b876f95d03e226394b5d360c86127cbefaf614b) and this
> happened:
>
> ...
> Removing sound/soc/au1x/sample-ac97.c
> Recorded preimage for 'arch/Kconfig'
> Recorded preimage for 'arch/arm/mach-s3c2440/mach-anubis.c'
> Recorded preimage for 'arch/arm/plat-mxc/Makefile'
> error: Could not parse conflict hunks in arch/arm/plat-s3c/dev-hsmmc2.c
> Recorded preimage for 'arch/arm/plat-s3c/include/plat/sdhci.h'
> Recorded preimage for 'arch/arm/plat-samsung/Kconfig'
> Recorded preimage for 'arch/x86/include/asm/x86_init.h'
> Recorded preimage for 'arch/x86/kernel/x86_init.c'
> Recorded preimage for 'drivers/net/wireless/ray_cs.c'
> Recorded preimage for 'kernel/Makefile'
> Recorded preimage for 'kernel/power/hibernate.c'
> Recorded preimage for 'net/sctp/sysctl.c'
> Automatic merge failed; fix conflicts and then commit the result.
>
> If you are interested, I can provide you the two trees above. When
> reproducing the line "error: ..." came later, but is still present.
>
> I guess this should be reproduceable with
>
> git clone -n git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> cd linux-2.6
> git remote add -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git checkout 2b876f95d03e226394b5d360c86127cbefaf614b
> git merge 5c1af82119f11c5b322156b09d38cc37318849c4
>
> I havn't tried though.
>
> The only non-trivial conflict is:
>
> #include <plat/sdhci.h>
> #include <plat/devs.h>
> <<<<<<< HEAD
> =======
> <<<<<<< HEAD
> #include <plat/cpu.h>
> =======
> >>>>>>> next-s5pc1xx
> >>>>>>> next/master
>
Someone committed a file with conflict markers. Bad bad boy. I guess
a8c4f01 (fixup sdhci merge failure, 2009-11-23) did not quite what it
promised.
Michael
^ permalink raw reply
* Re: rerere failed to parse conflict hunks
From: Uwe Kleine-König @ 2009-12-09 10:00 UTC (permalink / raw)
To: Ben Dooks; +Cc: git, Michael J Gruber
In-Reply-To: <4B1F721E.9050609@drmicha.warpmail.net>
Best regards
Uwe
On Wed, Dec 09, 2009 at 10:47:10AM +0100, Michael J Gruber wrote:
> Uwe Kleine-König venit, vidit, dixit 09.12.2009 09:46:
> > Hello,
> >
> > I just tried to merge linux-next
> > (5c1af82119f11c5b322156b09d38cc37318849c4) into my private tree
> > (based on 2b876f95d03e226394b5d360c86127cbefaf614b) and this
> > happened:
> >
> > ...
> > Removing sound/soc/au1x/sample-ac97.c
> > Recorded preimage for 'arch/Kconfig'
> > Recorded preimage for 'arch/arm/mach-s3c2440/mach-anubis.c'
> > Recorded preimage for 'arch/arm/plat-mxc/Makefile'
> > error: Could not parse conflict hunks in arch/arm/plat-s3c/dev-hsmmc2.c
> > Recorded preimage for 'arch/arm/plat-s3c/include/plat/sdhci.h'
> > Recorded preimage for 'arch/arm/plat-samsung/Kconfig'
> > Recorded preimage for 'arch/x86/include/asm/x86_init.h'
> > Recorded preimage for 'arch/x86/kernel/x86_init.c'
> > Recorded preimage for 'drivers/net/wireless/ray_cs.c'
> > Recorded preimage for 'kernel/Makefile'
> > Recorded preimage for 'kernel/power/hibernate.c'
> > Recorded preimage for 'net/sctp/sysctl.c'
> > Automatic merge failed; fix conflicts and then commit the result.
> >
> > If you are interested, I can provide you the two trees above. When
> > reproducing the line "error: ..." came later, but is still present.
> >
> > I guess this should be reproduceable with
> >
> > git clone -n git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > cd linux-2.6
> > git remote add -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > git checkout 2b876f95d03e226394b5d360c86127cbefaf614b
> > git merge 5c1af82119f11c5b322156b09d38cc37318849c4
> >
> > I havn't tried though.
> >
> > The only non-trivial conflict is:
> >
> > #include <plat/sdhci.h>
> > #include <plat/devs.h>
> > <<<<<<< HEAD
> > =======
> > <<<<<<< HEAD
> > #include <plat/cpu.h>
> > =======
> > >>>>>>> next-s5pc1xx
> > >>>>>>> next/master
> >
>
> Someone committed a file with conflict markers. Bad bad boy. I guess
> a8c4f01 (fixup sdhci merge failure, 2009-11-23) did not quite what it
> promised.
obviously, yes.
Ben, you might want to redo commit a8c4f018ba69266aeb3cccf73c36b6663189e730
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-09 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx7lcj18.fsf@alter.siamese.dyndns.org>
On Tue, Dec 08, 2009 at 12:22:59PM -0800, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
> > Add --revisions flag to rebase, so that it can be used
> > to apply an arbitrary range of commits on top
> > of a current branch.
>
> Many people wanted to have "pick many commits onto the current HEAD" and I
> think it would be a natural, uncontroversial and welcome addition to allow
> "git cherry-pick A..B". In fact, historically, people who wanted to have
> "pick many commits" complained that the "rebase" interface was backwards,
> because it works in the _wrong_ direction for _their_ usecase. Of course,
> when you _are_ rebasing a branch on top of some other branch, the way
> "rebase" currently works is the _right_ direction.
>
> But I think it is a reasonable thing to _implement_ the feature to
> range-pick commits reusing the sequencing logic already in "rebase" and
> "rebase -i". That essentially is what we wanted to do with "git
> sequencer" that would be a sequencing logic backend shared among rebase,
> cherry-pick, and perhaps am.
>
> So perhaps a good way to move forward is to teach "git cherry-pick A..B"
> to be a thin wrapper that invokes a new hidden mode of operation added to
> "rebase" that is not advertised to the end user.
>
> I would suggest calling the option to invoke that hidden mode not
> "--revisions", but "--reverse" or "--opposite" or something of that
> nature, though. It makes "rebase" work in different direction.
cherry-pick is a binary though while rebase is a shell script.
Should I just exec git rebase? git-rebase?
--
MST
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Peter Krefting @ 2009-12-09 10:52 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20091209093758.GA2977@redhat.com>
Michael S. Tsirkin:
>> Maybe this could also be used to implement a "git merge --squash A..B",
>> a.k.a a "partial merge".
> What exactly should it do?
The same thing, apply a set of changes on top of the current branch, just
using the "merge" name, and not "rebase" or "cherry-pick". "merge --squash"
is just "cherry-pick" with a different name.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Matthieu Moy @ 2009-12-09 10:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20091209103850.GD2977@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> cherry-pick is a binary though while rebase is a shell script.
> Should I just exec git rebase? git-rebase?
See run-command.h :
#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
int run_command_v_opt(const char **argv, int opt);
That should do the trick (grep 'run_command_v_opt.*GIT_CMD' *.c for
some example of uses).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-09 11:22 UTC (permalink / raw)
To: Peter Krefting; +Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0912091150470.470@ds9.cixit.se>
On 2009.12.09 11:52:41 +0100, Peter Krefting wrote:
> Michael S. Tsirkin:
>
> >>Maybe this could also be used to implement a "git merge --squash
> >>A..B", a.k.a a "partial merge".
> >What exactly should it do?
>
> The same thing, apply a set of changes on top of the current branch,
> just using the "merge" name, and not "rebase" or "cherry-pick".
> "merge --squash" is just "cherry-pick" with a different name.
Err, no. "git merge --squash foo" merges all changes from the merge base
of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
from foo^ to foo. For example:
A---B---C (master)
\
D---E---F (foo)
git cherry-pick foo # Tries to create a new commit with the changes from
# "git diff D F"
git merge --squash foo # Tries to create a new commit with the changes
# from "git diff A F"
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Andreas Schwab @ 2009-12-09 11:48 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Peter Krefting, Michael S. Tsirkin, Junio C Hamano,
Git Mailing List
In-Reply-To: <20091209112237.GA27740@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Err, no. "git merge --squash foo" merges all changes from the merge base
> of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
> from foo^ to foo. For example:
>
> A---B---C (master)
> \
> D---E---F (foo)
>
> git cherry-pick foo # Tries to create a new commit with the changes from
> # "git diff D F"
Did you mean "git diff E F"?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-09 12:06 UTC (permalink / raw)
To: Andreas Schwab
Cc: Peter Krefting, Michael S. Tsirkin, Junio C Hamano,
Git Mailing List
In-Reply-To: <m2pr6ocqrb.fsf@igel.home>
On 2009.12.09 12:48:24 +0100, Andreas Schwab wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > Err, no. "git merge --squash foo" merges all changes from the merge base
> > of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
> > from foo^ to foo. For example:
> >
> > A---B---C (master)
> > \
> > D---E---F (foo)
> >
> > git cherry-pick foo # Tries to create a new commit with the changes from
> > # "git diff D F"
>
> Did you mean "git diff E F"?
Ugh, yes, of course. Thanks.
Björn
^ 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