On Mon, Mar 26, 2012 at 5:53 PM, Neal Kreitzinger
<nkreitzinger@xxxxxxxxx> wrote:
> On 3/26/2012 12:20 PM, Neil Horman wrote:
>>
>> On Mon, Mar 26, 2012 at 10:12:48AM -0700, Junio C Hamano wrote:
>>>
>>> Neil Horman<nhorman@xxxxxxxxxxxxx> writes:
>>>
>>>> I agree, I think perhaps adding an --allow-empty option to the rebase
>>>> logic, so
>>>> that empty commits (or perhaps just initially empty, as opposed to
>>>> commits made
>>>> empty) would be very beneficial.
>>>
>>>
>>> Yeah, that probably may make sense.
>>>
>> Ok, cool, I'll have a patch in a few days, thanks!
>>
> IMO, it seems like --allow-empty is an appropriate patch for git-rebase
> (non-interactive), and that git-rebase -i would need a command like "k"eep
> to distinguish which empty commits are not to be discarded and which empty
> commits are ok to discard automatically. git-rebase -i should allow
> explicit control on a commit by commit basis as opposed to blanket rules
> like "discard all empty commits" or "keep all empty commits" that apply to
> all commits in the rebase-to-do list based on a single cli option.
But I don't want a 'keep-even-if-empty' option in interactive. I want
a 'purge-if-empty' option instead. But I don't want to be bothered
with telling git this for every commit.
I recently had a long-running branch to clean up. It was polluted
with commits pulled in by a ham-fisted developer collaborating on
this and another branch. He's not quite got the git mental model yet
and he had lots of commits doing things and then undoing them later
on. Rebase scares him.
So I did a lot of interactive rebasing on this branch to reorder the
"good" change commits to the front of the line where they could be
pushed to code review sooner. In the meantime, I wanted to keep the
rest of the branch in place so I could see what was left to tackle.
I cherry-picked replacements for many of the "good" commits -- from
their original topic branches HamFist swiped them from -- so I would
have the current, reviewable commit to push. Then I tested the
long-running branch on top of these commits. This involved about 8 or
10 passes through 'git rebase -i master' for one reason or another.
On this branch of 40 commits, git interrupted me about 10 times on
each pass to ask me what to do. The reason is always one of these:
1. There is a new conflict I need to resolve
examine / mergetool / test / --continue
2. There is a rerere autoresolved conflict git wants me to approve
examine / test / --continue
3. There are no changes left in this commit because either
a. they were introduced into earlier commits, or
b. git-rerere-membered that I don't want those changes
examine / --skip
I went through this process about 5 or 6 times as I massaged the stink
out of this branch. Cases 2 and 3 became more common as I went along.
But git always wanted to stop and ask my approval before continuing.
It was frustrating.
I always had my original branch to go compare to. This one is really
a trial rework of these commits. So I wish I could tell git to only
bother me when he sees a new conflict. Don't stop and ask me for
something every 3 or 4 commits.
I really wanted something like this:
$ git rebase --purge-empty --accept-rerere-authority -i master
So, even though this is an "interactive" rebase, I wish git would do
more of the busywork for me. That is, I only want it to be as
interactive as it needs to be, and no more so.
Phil
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html