Re: odd behavior with git-rebase

On Wed, Mar 28, 2012 at 2:18 AM, Neal Kreitzinger
[off-list ref] wrote:

On 3/26/2012 5:53 PM, Phil Hord wrote:

quoted

On Mon, Mar 26, 2012 at 5:53 PM, Neal Kreitzinger
[off-list ref] wrote:

quoted

On 3/26/2012 12:20 PM, Neil Horman wrote:

quoted

On Mon, Mar 26, 2012 at 10:12:48AM -0700, Junio C Hamano wrote:

quoted

Neil Horman[off-list ref] writes:

quoted

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.

That's why its called an option.  Don't use it if you don't want it.  ;-)

Yeah, I didn't mean I don't want it to exist in git.  I just meant
that it's not what I'm seeking atm.

But you seem to have forgotten that you were arguing against it at the
beginning of the paragraph I was responding to.

quoted

I want a 'purge-if-empty' option instead.

That's the default behavior currently.  We're not proposing to change that.

It ostensibly is the current behavior.  But Peff and I think we've
seen it misbehave in --interactive mode.  However, I may have been
confused by its doppelgänger, the "rerere autoresolved to empty
commit" situation, where the behavior is to announce "Could not apply"
and pause the process to wait for human intervention.

quoted

But I don't want to be bothered with telling git this for every
commit.

You only tell it which empty commits you want to "k"eep (to not
"auto-purge").  In your case, you don't want to keep any so you don't have
to tell it anything.  The default behavior will purge them all (empty
commits) because you didn't mark any as "k"eep.

quoted

I recently had a long-running branch to clean up.

I have users with branches over a year old.

I don't understand this comment.  Is this a pissing contest?

quoted

It was polluted with commits pulled in by a ham-fisted developer
collaborating on this and another branch.

My users cp files from other worktrees and do merges manually without using
git-merge, git-rebase, or git-cherry-pick.

quoted

He's not quite got the git mental model yet and he had lots of
commits doing things and then undoing them later on.

Most of my users think git is cvs 3.0.

I see what you did there.  I like that one.

quoted

Rebase scares him.

git as a whole scares most of my users.

quoted

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.

You should create a "backup" branch of the before state so you don't get
blamed for breaking their stuff.

Apologies for failing to mention that his branch remained "backed up"
in origin/shared/dumbass as well as on a local branch and in my
reflog.

quoted

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.

Sounds like you may also be a little scared of git-rebase yourself.  Be a
man and do it all in one pass.  (You have the backup branch to startover if
need be.)  ;-)

Oh, it IS a pissing contest then.  Whip it out, boy!

No, I'm not scared of rebase.  There were 40 commits full of crap and
gems.  I made several pass through rebase-interactive not because
git-rebase is a problem but simply because I was sifting methodically
for gems and flushing turds.

quoted

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

You trust rerere?  I take back my earlier comment, you are a brave man.

Uh huh. That's what I thought!. Hmmph.

Also, you're starting to sound like some of my users who think that git
magically does their work for them.

Git does do my work for me, and it does require more work from me.
But in this case, it saved me sifting the same turds over and over.

I do trust rerere to redo what it previously remembered I did for
resolution.  In that respect, rerere is only as reliable as I am.  But
I also have a backup that I'll consult periodically, these commits are
headed for the CI-Server and human reviewers, and there's plenty of
time to catch my stupid mistakes.

quoted

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

git-rerere-membered -- that's a good one.  I felt like
git-rerere-dismembered my merge the one time I tried it.  But seriously, I
have no experience with this --skip scenario.

I think rerere seemed to butcher my first ugly merge, too.  But it was
really my fault.  I knew I was on a throwaway branch previously, so I
was not as careful with the merge.  Later when I revisited it to do it
"for real", rerere stepped in and was as un-careful as I had been.
:-)  I think he was rubbing my nose in it.

quoted

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

--accept-rerere-authority sounds like another recent thread (maybe from
you).

Maybe.

quoted

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.

FWIW, I think we may be a little spoiled.  git rebase -i is one of the, if
not the, most powerful, flexible, amazing change control commands in
existence if you think about it.  I guess we could switch to another SCM
that does it better.  Oh, I forgot, there isn't one.

Yes, definitely spoiled.  rebase-interactive,  add-patch, and
checkout-patch have changed the way I manage my project.  I have a
much better project history because of them, but I'm also much more
intimate with my SCM than I ever was under Subversion, cvs, SourceSafe
or tar.  :-)

I never thought I would be excited about an SCM, but I've become the
resident evangelist at $dayjob.

Hopefully, my sympathetically-inspired comments based on some shared
experiences are helpful at some level.  :-)

Yes, thanks.  Sometimes I'm long-winded.  I usually tone it down after
a couple of rewrites, but this time I left most of the elucidating
back story in.

Thanks for reading along.

Phil