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

[Linus Torvalds]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/