Re: VCS comparison table
- From
Matthieu Moy <matthieu.moy@imag.fr>
- Date
- Oct 18, 2006, 06:22 UTC
- Message-ID
- <vpqpscqm9d6.fsf@ecrins.imag.fr>
- In-Reply-To
- <200610172351.17377.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
Show 11 quoted lines
>>> Fast-forward is a really good idea. Perhaps you could implement it, >>> if it is not hidden under different name? >> >> We support it as 'pull', but merge doesn't do it automatically, because >> we'd rather have merge behave the same all the time, and because 'pull' >> throws away your local commit ordering. > > I smell yet another terminology conflict (although this time fault is > on the git side), namely that in git terminology "pull" is "fetch" > (i.e. getting changes done in remote repository since laste "fetch" > or since "clone") followed by merge. pull = fetch + merge.
AAUI, the initial claim was that after a rebase, git can do a fast-forward, but Aaron has missed the /after a rebase/ part.
And yes, it the bzr terminology, bzr can do a "pull" after a "graft". I don't think there's a fundamental difference here.