Re: [git pull] x86 updates for v2.6.28, phase #2 - PAT updates

Linus Torvalds
2008-10-10T17:24:22Z

On Fri, 10 Oct 2008, Ingo Molnar wrote:
>
> Correction: i did the reverts shortly before applying the v2 series - so
> it was fully technical. I wanted to do a line by line review of the fix
> (and did it), because the lockup took quite some time to pin down. To
> avoid this mistake i could also have hard-reset the full v1 series and
> could have redone the whole topic.
>
> What's the best Git way to avoid such mishaps? I try to avoid resets and
> rebases of already pushed out bits as much as possible, because that is
> both risky because information can be lost and asocial because ongoing
> work of contributors can be disturbed.

There's a couple of things you could have done.

The simplest approach is to kill the branch. Of course, you could do that
with just a "git reset", but if you had already pushed the branch out and
it wasn't one of the "gets rebased" branches, that's not very nice either.

But rather than doing "git reset" on an old branch, what I think is nicer
is to just create a new branch instead, and call it "PAT-v2" or something
like that - leaving the old one around, but simply never _using_ it for
anything (and obviously not merging it). That seems to match how you work
otherwise.

Just opening another branch has the advantage that it also allows you to
easily do cross-branch compares. It's actually how I work a lot personally
when I work with the git repo and do some new thing: I start a topic
branch for it, but it's inevitably going to be ugly in the end because I'm
finding problems as I go, so I just start another branch and basically
re-create a cleaner version in that.

(I don't end up merging with Junio with git - I just send him patches, so
all those branches end up being just private things, but it doesn't change
the basic workflow).

And the nice thing with starting a new branch is that you can do your
cleanups etc in it, and then things like

git diff broken..new-branch

work fine to check the differences _between_ branches. In other words,
this is also a good way to just take a "v2" of a patch-series, and then
you basically get a inter-patch-series diff for free that shows what the
differences were.

Of cource, once you do that, you can also decide that you're not actually
going to use the new branch, you're just going to append the fixes from v2
to the old branch instead. So you may decide that your new branch (that
you never pushed out) is not worth making a new branch for, and that it's
actually going to be easier for people involved if you just turn the
second patch-series into a single (or multiple, for that matter)
fix-commit on top of the old patch-series.

Finally, one option that I do not recommend in this case (simply because
all of the commits got rewritten) is to actually keep both branches, but
do a merge between them and just pick the correct end result in the merge.
That can be useful as a way to show both histories, but I'd generally
suggest that only if there is some big reason why you'd really want to
have both sets of patches around later.

A reason for the last case could be two different approaches that were
both valid, and actually ended up both with a very similar end result, and
where the way they got to it was interesting and/or relevant exactly
because they were different. Or even if they weren't that technically
different, maybe they were done by different people, and keeping both ends
up showing the real development history _and_ gives credit to both.

There are other ways to do this too, but they all boil down to the "make a
new branch that starts at the common point". For example, instead of
creating a diff with "git diff broken..fixed" (whether to just see what
the breakage was, or to actually fix up the broken branch with), if the
series are very similar in structure and in many of the sub-commits, you
can end up using "git rebase" to rebase the fixed sequence on top of the
broken branch.

That last "git rebase" approach will generally cause a lot of conflicts
that you have to fix up by hand (since by definition the two branches will
obviously be touching the same area, and in slightly different ways), but
sometimes that can actually be exactly what you _want_, since the merge
conflicts are going to be exactly the things that changed, and if the
series was clean and didn't have lots of patches where one patch in the
series changed something that an earlier patch already modified, then the
rebase can be a nice way to get the incremental fixes on top of the old
broken branch from the fixed one.

So there are certainly different things you can do.

Linus