Re: Upcoming memcached releases + rambling.

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.

   "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.

   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.)

2) "git log old..new" is a special case of a very general mechanism
   for specifying a set of commits to examine.  See the man page for
   "git-rev-parse" for the full complete rules.  You specify a set of
   commits to include, and a set to exclude.

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

   A commit is included in the final set if it is an ancestor of one of
   the explicitly listed "include" commits, *and* it is *not* an ancestor
   of any of the listed "exclude" commits.

   old..new is a convenient equivalent for "^old new": everything in new's
   history that is not included in old's history.  Thus, "old1..new1
   old2..new2" is exactly synonymous with "old1..new2 old2..new1".
   They both mean that new1, new2, and all their ancestors are included,
   except that old1, old2, and all their ancestors are excluded.

   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.)

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.)

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

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.
 

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.

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

"rev1...rev2" is equivalent to "rev1 rev2 --not $(git merge-base rev1 rev2)"
which I think explains what it does.
 

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