> > 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