| Re: [epsilon-dev] Git: pull vs (fetch then rebase) |
Hi,
On Thursday 11 December 2014 14:51:14 Louis Rose wrote:
> To keep our Git commit history clean, please consider using “git fetch”
> followed by “git rebase origin” when updating your local copy. This means
> that any merge conflicts that result from your update can be resolved
> cleanly in a separate commit.
>
> The alternative approach (i.e., “git pull”) is likely to create needless
> commits, and will make our commit history non-linear (making it harder to
> read).
Good point. This is indeed, something we need to adjust to now we are migrated
to git.
Some additional (easy to understand) information on this subject (including
ASCII art images) can be found at http://stackoverflow.com/a/3357174/246263
Also notice that rebase might be dangerous and should be understand
thoroughly:
"This is a potentially dangerous mode of operation. It rewrites history, which
does not bode well when you published that history already. Do not use this
option unless you have read git-rebase carefully."
(From https://www.kernel.org/pub/software/scm/git/docs/git-pull.html)
It might not be a bad idea to read the git-rebase page
(https://www.kernel.org/pub/software/scm/git/docs/git-rebase.html) as well to
get a better understanding what git rebase does and what are potentially pit-
falls (and how to circumvent or solve them)
Also note that 'git pull --rebase <remote name> <branch name>' is an
alternative to 'git fetch <remote name>' + 'git rebase <branch name>'.
(Convenient for lazy people ;) )
Cheers,
Maarten
_______________________________________________
epsilon-dev mailing list
epsilon-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/epsilon-dev