> I'd also recommand "git pull --rebase" if the goal is to keep history > linear. Note that this has to go with a big, fat, warning, telling the > user that rebasing published history is bad. Rebase is a very good tool > to work with private history, but as soon as you've pushed it to some > place visible by other people, you should stop using it.This is enormously important - once submodule maintainers starts rebasing, we're screwed.
FlyLanguage <flylanguage at gmail.com> writes:>> I'd also recommand "git pull --rebase" if the goal is to keep history >> linear. Note that this has to go with a big, fat, warning, telling the >> user that rebasing published history is bad. Rebase is a very good tool >> to work with private history, but as soon as you've pushed it to some >> place visible by other people, you should stop using it. > > This is enormously important - once submodule maintainers starts > rebasing, we're screwed.I've long argued that git submodule is inherently broken. I prefer git-subtree. I didn't address it in the document because it is somewhat orthogonal to setting up git repositories for the components. How to aggregate components is an easier question in that multiple people can easily set up aggregators and users can pick what they like. Once we've transitioned to git (assume that we will do so, of course), I plan to set up an aggregator repository using git-subtree and publishing it for anyone to use. -Dave
On Aug 23, 2011, at 12:35 AM, FlyLanguage wrote:>> I'd also recommand "git pull --rebase" if the goal is to keep history >> linear. Note that this has to go with a big, fat, warning, telling the >> user that rebasing published history is bad. Rebase is a very good tool >> to work with private history, but as soon as you've pushed it to some >> place visible by other people, you should stop using it. > > This is enormously important - once submodule maintainers starts > rebasing, we're screwed.Why do we care about the development history of a patch? Patches sent to mainline should be simple, small, and obvious. Any conversion to git doesn't change this. -Chris
Chris Lattner <clattner at apple.com> writes:> On Aug 23, 2011, at 12:35 AM, FlyLanguage wrote: >>> I'd also recommand "git pull --rebase" if the goal is to keep history >>> linear. Note that this has to go with a big, fat, warning, telling the >>> user that rebasing published history is bad. Rebase is a very good tool >>> to work with private history, but as soon as you've pushed it to some >>> place visible by other people, you should stop using it. >> >> This is enormously important - once submodule maintainers starts >> rebasing, we're screwed. > > Why do we care about the development history of a patch? Patches sent > to mainline should be simple, small, and obvious. Any conversion to > git doesn't change this.It doesn't change what goes in the upstream repository. It does greatly improve the tools developers have to manage the private history of their patches (i.e. changes made between first submission and the second following reviewers comments for example). rebase is a great tool to manage your private history, and to avoid bothering reviewers with your own mistakes (which I think you do care about). So encouraging people to use rebase and rebase -i on their private history saves time for reviewers. The warning is important to avoid people shooting themselves in the foot while trying to save time. -- Matthieu Moy http://www-verimag.imag.fr/~moy/
>>> I'd also recommand "git pull --rebase" if the goal is to keep history >>> linear. Note that this has to go with a big, fat, warning, telling the >>> user that rebasing published history is bad. Rebase is a very good tool >>> to work with private history, but as soon as you've pushed it to some >>> place visible by other people, you should stop using it. >> >> This is enormously important - once submodule maintainers starts >> rebasing, we're screwed. > > Why do we care about the development history of a patch? Patches sent to mainline should be simple, small, and obvious. Any conversion to git doesn't change this.'When you rebase a branch, you are changing its history in a way that will cause problems for anyone who already has a copy of the branch in their repository and tries to pull updates from you.' So I guess it all depends on how submodules (will they have their own maintainers?) are organized into the workflow.