230 lines
9.5 KiB
Markdown
230 lines
9.5 KiB
Markdown
---
|
|
created_at: '2012-10-04T14:09:35.000Z'
|
|
title: Linus on keeping a clean git history (2009)
|
|
url: http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html
|
|
author: pushingbits
|
|
points: 227
|
|
story_text: ''
|
|
comment_text:
|
|
num_comments: 84
|
|
story_id:
|
|
story_title:
|
|
story_url:
|
|
parent_id:
|
|
created_at_i: 1349359775
|
|
_tags:
|
|
- story
|
|
- author_pushingbits
|
|
- story_4612331
|
|
objectID: '4612331'
|
|
|
|
---
|
|
[Source](https://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg39091.html "Permalink to Re: [git pull] drm-next")
|
|
|
|
# Re: [git pull] drm-next
|
|
|
|
[Skip to site navigation (Press enter)][1]
|
|
|
|
# [Re: [git pull] drm-next][2]
|
|
|
|
[Linus Torvalds][3] [Sun, 29 Mar 2009 14:48:18 -0700][4]
|
|
|
|
|
|
|
|
On Sun, 29 Mar 2009, Dave Airlie wrote:
|
|
>
|
|
> My plans from now on are just to send you non-linear trees, whenever I
|
|
> merge a patch into my next tree thats when it stays in there, I'll pull
|
|
> Eric's tree directly into my tree and then I'll send the results, I
|
|
> thought we cared about a clean merge history but as I said without some
|
|
> document in the kernel tree I've up until now had no real idea what you
|
|
> wanted.
|
|
|
|
|
|
|
|
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.
|
|
|
|
But if you want to sync up with major releases, do a
|
|
|
|
git pull linus-repo v2.6.29
|
|
|
|
or similar to synchronize with that kind of _non_random_ point. That
|
|
all makes sense. A "Merge v2.6.29 into devel branch" makes complete
|
|
sense as a merge message, no? That's not a problem.
|
|
|
|
But if I see a lot of "Merge branch 'linus'" in your logs, I'm not
|
|
going to pull from you, because your tree has obviously had random crap
|
|
in it that shouldn't be there. You also lose a lot of testability,
|
|
since now all your tests are going to be about all my random code.
|
|
|
|
- Don't merge _downstream_ code at random points either.
|
|
|
|
Here the "random points" comment is a dual thing. You should not mege
|
|
random points as far as downstream is concerned (they should tell you
|
|
what to merge, and why), but also not random points as far as your tree
|
|
is concerned.
|
|
|
|
Simple version: "Don't merge unrelated downstream stuff into your own
|
|
topic branches."
|
|
|
|
Slightly more complex version: "Always have a _reason_ for merging
|
|
downstream stuff". That reason might be: "This branch is the release
|
|
branch, and is _not_ the 'random development' branch, and I want to
|
|
merge that ready feature into my release branch because it's going to
|
|
be part of my next release".
|
|
|
|
See? All the rules really are pretty simple. There's that somewhat subtle
|
|
interaction between "keep your own history clean" and "never try to clean
|
|
up _other_ proples histories", but if you follow the rules for pulling,
|
|
you'll never have that problem.
|
|
|
|
Of course, in order for all this to work, you also have to make sure that
|
|
the people you pull _from_ also have clean histories.
|
|
|
|
And how do you make sure of that? Complain to them if they don't. Tell
|
|
them what they should do, and what they do wrong. Push my complaints down
|
|
to the people you pull from. You're very much allowed to quote me on this
|
|
and use it as an explanation of "do this, because that is what Linus
|
|
expects from the end result".
|
|
|
|
Linus
|
|
|
|
------------------------------------------------------------------------------
|
|
--
|
|
_______________________________________________
|
|
Dri-devel mailing list
|
|
Dri-devel@lists.sourceforge.net
|
|
<https://lists.sourceforge.net/lists/listinfo/dri-devel>
|
|
|
|
|
|
* [Previous message][5]
|
|
* [View by thread][6]
|
|
* [View by date][7]
|
|
* [Next message][8]
|
|
* [[git pull] drm-next][9] Dave Airlie
|
|
* * [Re: [git pull] drm-next][10] Linus Torvalds
|
|
* * [Re: [git pull] drm-next][5] Dave Airlie
|
|
* * Re: [git pull] drm-next Linus Torvalds
|
|
* * [Re: [git pull] drm-next][8] Dave Airlie
|
|
* * [Re: [git pull] drm-next][11] Linus Torvalds
|
|
|
|
## Reply via email to
|
|
|
|
![The Mail Archive][12]
|
|
|
|
Search the site
|
|
|
|
* [The Mail Archive home][13]
|
|
* [dri-devel - all messages][14]
|
|
* [dri-devel - about the list][15]
|
|
* [Expand][16]
|
|
* [Previous message][17]
|
|
* [Next message][18]
|
|
* [The Mail Archive home][13]
|
|
* [Add your mailing list][19]
|
|
* [FAQ][20]
|
|
* [Support][21]
|
|
* [Privacy][22]
|
|
* alpine.LFD.2.00.0903291409030.3994@localhost.localdomain
|
|
|
|
[1]: https://www.mail-archive.com#nav
|
|
[2]: https://www.mail-archive.com/search?l=dri-devel@lists.sourceforge.net&q=subject:%22Re%5C%3A+%5C%5Bgit+pull%5C%5D+drm%5C-next%22&o=newest
|
|
[3]: https://www.mail-archive.com/search?l=dri-devel@lists.sourceforge.net&q=from:%22Linus+Torvalds%22
|
|
[4]: https://www.mail-archive.com/search?l=dri-devel@lists.sourceforge.net&q=date:20090329
|
|
[5]: https://www.mail-archive.com/msg39090.html
|
|
[6]: https://www.mail-archive.com/index.html#39091
|
|
[7]: https://www.mail-archive.com/maillist.html#39091
|
|
[8]: https://www.mail-archive.com/msg39093.html
|
|
[9]: https://www.mail-archive.com/msg39088.html
|
|
[10]: https://www.mail-archive.com/msg39089.html
|
|
[11]: https://www.mail-archive.com/msg39094.html
|
|
[12]: https://www.mail-archive.com/logo.png
|
|
[13]: https://www.mail-archive.com/
|
|
[14]: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/
|
|
[15]: https://www.mail-archive.com/dri-devel@lists.sourceforge.net/info.html
|
|
[16]: https://www.mail-archive.com/search?l=dri-devel@lists.sourceforge.net&q=subject:%22Re%5C%3A+%5C%5Bgit+pull%5C%5D+drm%5C-next%22&o=newest&f=1 "e"
|
|
[17]: https://www.mail-archive.com/msg39090.html "p"
|
|
[18]: https://www.mail-archive.com/msg39093.html "n"
|
|
[19]: https://www.mail-archive.com/faq.html#newlist
|
|
[20]: https://www.mail-archive.com/faq.html
|
|
[21]: https://www.mail-archive.com/faq.html#support
|
|
[22]: https://www.mail-archive.com/faq.html#privacy
|
|
|