Excerpts from Junio C Hamano's message of Thu Jun 27 13:52:33 -0700 2013:
> Two issues here, which I'll locally amend (no need to resend):
Great! Thank you for your help and patience.
> cat >expected <<-EOF &&
> pick ...
> ...
> EOF
> test_cmp expe
Andrew Pimlott writes:
> Updated for recommended here-doc style.
Thanks.
> +test_auto_fixup_fixup () {
> + git reset --hard base &&
> + echo 1 >file1 &&
> + git add -u &&
> + test_tick &&
> + git commit -m "$1! first" &&
> + echo 2 >file1 &&
> + git add -u &&
> +
Excerpts from Andrew Pimlott's message of Wed Jun 26 17:20:32 -0700 2013:
> Excerpts from Junio C Hamano's message of Wed Jun 26 16:48:57 -0700 2013:
> > Andrew Pimlott writes:
> > > In order to test this, I wrote a helper function to dump the rebase -i
> > > todo list. Would you like this introd
Excerpts from Junio C Hamano's message of Wed Jun 26 16:48:57 -0700 2013:
> Andrew Pimlott writes:
> > In order to test this, I wrote a helper function to dump the rebase -i
> > todo list. Would you like this introduced in its own patch, or
> > combined? See below.
>
> Depends on how involved t
Andrew Pimlott writes:
> In order to test this, I wrote a helper function to dump the rebase -i
> todo list. Would you like this introduced in its own patch, or
> combined? See below.
Depends on how involved the addition of the tests that actually use
the helper, but in general it would be a g
Excerpts from Andrew Pimlott's message of Tue Jun 25 16:03:52 -0700 2013:
> Thomas's patch didn't do this: fixup! or squash! after the first is
> simply discarded, so you see:
>
> pick d78c915 original
> fixup 0c6388e fixup! original
> fixup d15b556 fixup! original
> fixup 1e39bcd
Excerpts from Junio C Hamano's message of Tue Jun 25 14:33:18 -0700 2013:
> Andrew Pimlott writes:
>
> Just reponding for the "procedual" part for now.
>
> > So if I don't want to break the discussion, should I append the unedited
> > format-patch output to my message after "scissors", or should
Excerpts from Junio C Hamano's message of Tue Jun 25 14:45:07 -0700 2013:
> After all, autosquash will give the user an opportunity to eyeball
> the result of automatic rearrangement. If the user did this:
>
> git commit -m original
> git commit --fixup original ;# obviously fixing th
Junio C Hamano writes:
I guess I made typoes in the examples that made then unusable...
> I think it is fine not to be too smart, as long as we do not lose
> information that would help the user to compensate.
>
> After all, autosquash will give the user an opportunity to eyeball
> the result of
Andrew Pimlott writes:
> I agree that it is better to preserve information as long as feasible.
> If we are going to strip it, it may as well be later. That is Thomas's
> rearrange_squash patch, which I will send again.
Thanks.
> The next question is, do we go all the way and respect the neste
Andrew Pimlott writes:
> diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
> index c84854a..6b2e1c8 100644
> --- a/Documentation/git-rebase.txt
> +++ b/Documentation/git-rebase.txt
> @@ -389,7 +389,9 @@ squash/fixup series.
> the same ..., automatically modify the tod
Andrew Pimlott writes:
Just reponding for the "procedual" part for now.
> So if I don't want to break the discussion, should I append the unedited
> format-patch output to my message after "scissors", or should I send it
> as a whole new message with --in-reply-to? Or something else? I'll try
Excerpts from Junio C Hamano's message of Mon Jun 17 07:27:20 -0700 2013:
> Thomas Rast writes:
> > I'm not sure it's worth arguing about whether the "fixup! fixup!" is a
> > symptom of some underlying problem, and changing rebase is only tapering
> > over the symptom; or whether it's actually a
Thomas Rast writes:
> Conveniently enough we have seen both already ;-) Andrew's version for
> commit.c could use a bit of refactorization, since it inserts the same
> code in two places, but then it's about the same complexity as the
> change for rebase.
>
> I'm not sure it's worth arguing abou
Junio C Hamano writes:
> Thomas Rast writes:
>
>> Isn't it a bit of an academic question?
>> ...
>> And once you have that, it seems a nicer and cleaner idea to generate
>> 'fixup! A' each time, instead of a successive sequence of
>>
>> fixup! A
>> fixup! fixup! A
>> fixup! fixup! fixup! A
Thomas Rast writes:
> Isn't it a bit of an academic question?
> ...
> And once you have that, it seems a nicer and cleaner idea to generate
> 'fixup! A' each time, instead of a successive sequence of
>
> fixup! A
> fixup! fixup! A
> fixup! fixup! fixup! A
> ...
As to reordering, you are
Junio C Hamano writes:
> Andrew Pimlott writes:
>
>> Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013:
>>> It happened to work and I added a test. But then it occurred to me that
>>> it might have been better to fix commit --fixup/--squash to strip the
>>> fixup! or squa
Junio C Hamano writes:
> Andrew Pimlott writes:
>
>> Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013:
>>> It happened to work and I added a test. But then it occurred to me that
>>> it might have been better to fix commit --fixup/--squash to strip the
>>> fixup! or squa
Andrew Pimlott writes:
> Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013:
>> It happened to work and I added a test. But then it occurred to me that
>> it might have been better to fix commit --fixup/--squash to strip the
>> fixup! or squash! from the referenced commit i
Excerpts from Andrew Pimlott's message of Fri Jun 14 12:31:57 -0700 2013:
> It happened to work and I added a test. But then it occurred to me that
> it might have been better to fix commit --fixup/--squash to strip the
> fixup! or squash! from the referenced commit in the first place.
> Anyhow, b
Excerpts from Thomas Rast's message of Tue Jun 11 11:50:07 -0700 2013:
> Andrew Pimlott writes:
> > git commit -m 'fix nasty bug'
> > ...
> > git commit --fixup :/nasty
> > ...
> > git commit --fixup :/nasty
> >
> > The second :/nasty resolves to the previous fixup, not the ini
21 matches
Mail list logo
