[Lustre-devel] Fwd: The Lustre community and GIT
dillowda at ornl.gov
Wed Dec 16 18:53:13 PST 2009
On Wed, 2009-12-16 at 15:01 -0800, Christopher J. Morrone wrote:
> Andreas Dilger wrote:
> > For developers that aren't keeping a huge number of patches, and
> > especially not a large number of dependent patches, "git rebase" is
> > probably sufficient. That will refresh the patches against changes in
> > the upstream repository.
> Except that "git rebase" is a destructive operation, right? It is fine
> for the single developer to do that, but you basically can't rebase a
> branch that you have published. Here is the kind of comment that I see
> associate with git rebase over and over on the web:
> "You should only use git rebase on your local-only branches. Its purpose
> is to keep your local, invisible changes up-to-date so that when you
> publish them they'll be more relevant and easy to understand for others."
> So rebase is off limits to us when managing our published "llnl" branch.
> (This is also why topgit uses "git merge" internally, not "git rebase".)
It's not a rule written in stone. If you have branches on which you
expect others to base their work, rebasing is painful for them as they
have to keep rebasing their work on top of the ones you do. But, this
can be OK if this is communicated to those that would follow your work.
Dave Miller used to rebase often with the net-2.6 tree, but stopped due
to the pain it was causing people working with him; it does occasionally
get rebased (and an email sent to netdev) if there is a problem that
would result in intolerable ugliness in the history.
linux-next is essentially rebased every day, but keeps tags to the
previous heads so that they don't get lost. Ie, if one wants to develop
against linux-next, they should use a tag such as next-20091216 to get a
stable base as master gets rewound daily. Similarly, the "pu" branch of
git is often rewound, and this fact is well advertised.
Certainly, if your changes are to go upstream via git pull and not via
an email patch series, then I think rebasing -- at least before the send
-- is a good idea, just to keep the history clean of distracting commits
like "Oops, forgot to add this file."
National Center for Computational Science
Oak Ridge National Laboratory
(865) 241-6602 office
More information about the lustre-devel