Re: Upcoming memcached releases + rambling.

[Jakub Narebski <jnareb@fuw.edu.pl>]

"George Spelvin" <linux@horizon.com> writes:

> A few notes about git that may be causing confusion:
> 
> 1) "git pull" does more than you think, and is for developers only.
> 
>    To just follow some other work, use only "git fetch".
> 
>    "git pull" does a fetch, and then merges the fetched branch into your
>    current HEAD.  If your current HEAD is a copy of the remote branch,
>    this will be harmless, but if it's not, it will produce code changes.

Note that "git fetch" usually fetches multiple branches; with default
configuration it fetches _all_ the branches. "git pull" would merge
the one marked for merge into current branch (HEAD is current branch),
either the one marked explicitely, or the first/main branch.
 
>    "git fetch" will fetch the remote branch, and then do a "fast-forward"
>    update of the corresponding local tracking branch.  If the local
>    tracking branch is not an ancestor of the fetched branch, it will
>    abort with an error.

But you can force fetching even if branch(es) in remote repository are
not ancestors of local tracking branches, which is needed if tracked
branch is rewound, reforked or rebased. Moreover by default this check
is disabled: all fetches are "forced".

You can always go to the previous value of branch thanks to reflogs,
so it is not really less safe, and avoids some hassle.

>    So, in summary, don't use "pull" unless you want to do a merge.
>    It will suppress the merge in the obvious trivial cases (no changes
>    on one side or the other), but will happily combine things.
> 
>    (The reason that "pull" is such a prominent command is that it's what
>    Linus does all day: merges other people's development into his tree.)

BTW. with newest git "git pull" _can_ rebase instead of merge.

> 2) "git log old..new" is a special case of a very general mechanism
>    for specifying a set of commits to examine.

>    The syntax is "include1 include2 ^exclude1 ^exclude2 include3...".

>    There is one magic bit of syntax, the symmetric difference operator
>    "rev1...rev2" (note three dots).  That means all ancestors of rev1,
>    and all ancestors of rev2, but excluding all common ancestors of both.
>    It's also equivalent to an include-exclude list, but the computation
>    of the exclude set is a bit more complicated.  (It's usually just
>    one common ancestor, but there can be multiples in nasty criss-cross
>    merge cases.)

"rev1...rev2" is equivalent to "rev1 rev2 --not $(git merge-base rev1 rev2)"
which I think explains what it does.
 
> 3) "git diff old..new" uses the same syntax for a different purpose.
>    diff only works with two commits, so that's simply an alias for
>    "git diff old new".  (Whether this is a useful conveience or is too
>    misleading for the beginner has been the subject of heated discussion
>    on the git mailing list.)

By the way, "git diff rev1...rev2" also works, and shows diff between
rev2 and common ancestor of rev1 and rev2 (merge base).

-- 
Jakub Narebski
Poland
ShadeHawk on #git