>
> I want clean history, but that really means (a) clean and (b) history.
>
> People can (and probably should) rebase their _private_ trees (their own
> work). That's a _cleanup_. But never other peoples code. That's a "destroy
> history"
>
> So the history part is fairly easy. There's only one major rule, and one
> minor clarification:
>
> - You must never EVER destroy other peoples history. You must not rebase
> commits other people did. Basically, if it doesn't have your sign-off
> on it, it's off limits: you can't rebase it, because it's not yours.
>
> Notice that this really is about other peoples _history_, not about
> other peoples _code_. If they sent stuff to you as an emailed patch,
> and you applied it with "git am -s", then it's their code, but it's
> _your_ history.
>
> So you can go wild on the "git rebase" thing on it, even though you
> didn't write the code, as long as the commit itself is your private
> one.
>
> - Minor clarification to the rule: once you've published your history in
> some public site, other people may be using it, and so now it's clearly
> not your _private_ history any more.
>
> So the minor clarification really is that it's not just about "your
> commit", it's also about it being private to your tree, and you haven't
> pushed it out and announced it yet.
>
> That's fairly straightforward, no?
>
> Now the "clean" part is a bit more subtle, although the first rules are
> pretty obvious and easy:
>
> - Keep your own history readable
>
> Some people do this by just working things out in their head first, and
> not making mistakes. but that's very rare, and for the rest of us, we
> use "git rebase" etc while we work on our problems.
>
> So "git rebase" is not wrong. But it's right only if it's YOUR VERY OWN
> PRIVATE git tree.
>
> - Don't expose your crap.
>
> This means: if you're still in the "git rebase" phase, you don't push
> it out. If it's not ready, you send patches around, or use private git
> trees (just as a "patch series replacement") that you don't tell the
> public at large about.
>
> It may also be worth noting that excessive "git rebase" will not make
> things any cleaner: if you do too many rebases, it will just mean that all
> your old pre-rebase testing is now of dubious value. So by all means
> rebase your own work, but use _some_ judgement in it.
>
> NOTE! The combination of the above rules ("clean your own stuff" vs "don't
> clean other peoples stuff") have a secondary indirect effect. And this is
> where it starts getting subtle: since you most not rebase other peoples
> work, that means that you must never pull into a branch that isn't already
> in good shape. Because after you've done a merge, you can no longer rebase
> you commits.
>
> Notice? Doing a "git pull" ends up being a synchronization point. But it's
> all pretty easy, if you follow these two rules about pulling:
>
> - Don't merge upstream code at random points.
>
> You should _never_ pull my tree at random points (this was my biggest
> issue with early git users - many developers would just pull my current
> random tree-of-the-day into their development trees). It makes your
> tree just a random mess of random development. Don't do it!
>
> And, in fact, preferably you don't pull my tree at ALL, since nothing
> in my tree should be relevant to the development work _you_ do.
> Sometimes you have to (in order to solve some particularly nasty
> dependency issue), but it should be a very rare and special thing, and
> you should think very hard about it.
The only case I can think off here, is when I send a tree of bug fixes to
your tree during -rc and I want to make sure the drm-next tree is tested
with those fixes applied to it. Is that an acceptable time to pull in your
tree? Normally I rebase the drm-next tree on top of the drm-fixes tree so
I know the testing is done with all known fixes in it, however it seems I
should merge your tree at that point instead into drm-next.
Thanks for all this, its quite clear now, I should clean this mail up and
put it into the kernel documentation.
Dave.
------------------------------------------------------------------------------
--
_______________________________________________
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel