[Development] Rebasing a contribution

[Oswald Buddenhagen]

On Thu, Nov 24, 2011 at 12:21:55AM +0100, ext Thiago Macieira wrote:
> On Wednesday, 23 de November de 2011 21:33:14 Oswald Buddenhagen wrote:
> > On Wed, Nov 23, 2011 at 07:07:17PM +0100, ext Thiago Macieira wrote:
> > > So, if I have reviewed your patch #6 in the contribution and you
> > > need to rebase in order to modify something, then rebase, push #7,
> > > leave a comment saying it was a rebase, modify and submit #8. That
> > > way, I can compare #7 to #8 and note that you made the change I
> > > requested.
> > 
> > my guess is that most of the time the pull --rebase is the *last*
> > thing people do, because that's what they always have done before
> > pushing.
> 
> I don't see that as a problem. As long as you push the rebased version
> with no *other* modification.
>
you missed my point. this is exactly what i expect to *not* happen.
typically, people do their own changes, then rebase, and then push.

> You don't need to rebase to update a contribution, you 
> only rebase because you want or need to for other reasons.
> 
people do it out of habit, and sometimes consciously to check for new
merge conflicts, or to simply see whether the stuff still works
(remember that even an empty rebase may break) - it's annoying when
these issues pop up only after the review, so minimizing the window kind
of makes sense.

> > consequently, the right fix would be git reset --hard to the pre-rebase
> > version from the reflog if the rebase is empty. except that nobody will
> > do it. however, i have a todo item to write a git-gpush script which
> > does just that automatically in the background.
> 
> Huh? You lost me completely here. Why would you need to go back?
> 
to undo the git-wise needless rebase, and thus push only the actual
change. done right, it wouldn't touch the working dir, so it would be
reasonably cheap for the contributor.

> > more interesting is the question what to do with non-empty rebases.
> > 
that's a serious question, btw. you can't just ignore a rebase which
required conflict resolution. how do you want to minimize the diffs?

> > fwiw, http://code.google.com/p/gerrit/issues/detail?id=217
> 
> Yes, this is the issue in question.
> I don't know of a generic way of solving it with Git.
>
i don't think a generic solution can even exist without true
intelligence.

> That's why I am asking that, if people are going to submit rebases,
> submit ONLY the rebase, with no extra changes.
> 
well, that's noble, but it just won't happen in most cases. been there,
tried it, didn't even get a t-shirt.