Thanks for pointing that out. Rebase is very helpful for topic branches, and
pretty much required when managing patches that will be pushed to a review tool
like Gerrit. You can also make this the default behavior for a particular branch
by setting the rebase option to true:
git config --add branch.<branch-name>.rebase true
thanks,
robert
On Sep 28, 2010, at 17:38 , Christopher J. Morrone wrote:
> I''ve noticed that lustre developers may not be aware of the
"git pull
> --rebase" option.
>
> In the git history, there are frequently little forks and merges that
> can be avoided. For instance, around many of the tags on master: one
> person will create the tag and push it to prime, meanwhile someone else
> has created a couple of commits on their local branch. When they try to
> push to prime, they probably get a reject message because their local
> copy is out of date. To resolve, they do "git pull", which
results in a
> merge, then "git push".
>
> This results in the little forks and "Merge branch
''master'' of
> git.lustre.org:prime/lustre" commits" in the history. At least I
think
> that is how it happens.
>
> This can be avoided by using "git pull --rebase" when you want to
bring
> your local branch up to date with prime. Where as "git pull"
> essentially does:
>
> git fetch
> git merge
>
> "git pull --rebase" more-or-less does:
>
> git fetch
> git rebase
>
> Its a little more complicated than that under the covers, but
> essentially it just temporarily removes your local commits,
> fast-forwards your local branch to catch up with the remote branch, and
> then replays the commits.
>
> It is not a big deal, but using --rebase would keep the history a little
> cleaner.
>
> Chris
> _______________________________________________
> Lustre-devel mailing list
> Lustre-devel at lists.lustre.org
> http://lists.lustre.org/mailman/listinfo/lustre-devel