{"thread":{"id":"12005","subject":"Re: Upcoming memcached releases + rambling.","startedAt":"2008-02-10T09:47:53Z","lastAt":"2008-02-11T12:50:53Z","messageCount":2,"participants":["George Spelvin","Jakub Narebski"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"68184","messageId":"20080210094753.23234.qmail@science.horizon.com","threadId":"12005","inReplyTo":null,"subject":"Re: Upcoming memcached releases + rambling.","fromName":"George Spelvin","fromEmail":"linux@horizon.com","sentAt":"2008-02-10T09:47:53Z","receivedAt":"2008-02-10T09:47:53Z","isPatch":false,"sender":{"key":"linux@horizon.com","avatar":null},"body":"A few notes about git that may be causing confusion:\n\n1) \"git pull\" does more than you think, and is for developers only.\n\n   To just follow some other work, use only \"git fetch\".\n\n   \"git pull\" does a fetch, and then merges the fetched branch into your\n   current HEAD.  If your current HEAD is a copy of the remote branch,\n   this will be harmless, but if it's not, it will produce code changes.\n\n   \"git fetch\" will fetch the remote branch, and then do a \"fast-forward\"\n   update of the corresponding local tracking branch.  If the local\n   tracking branch is not an ancestor of the fetched branch, it will\n   abort with an error.\n\n   So, in summary, don't use \"pull\" unless you want to do a merge.\n   It will suppress the merge in the obvious trivial cases (no changes\n   on one side or the other), but will happily combine things.\n\n   (The reason that \"pull\" is such a prominent command is that it's what\n   Linus does all day: merges other people's development into his tree.)\n\n\n2) \"git log old..new\" is a special case of a very general mechanism\n   for specifying a set of commits to examine.  See the man page for\n   \"git-rev-parse\" for the full complete rules.  You specify a set of\n   commits to include, and a set to exclude.\n\n   The syntax is \"include1 include2 ^exclude1 ^exclude2 include3...\".\n\n   A commit is included in the final set if it is an ancestor of one of\n   the explicitly listed \"include\" commits, *and* it is *not* an ancestor\n   of any of the listed \"exclude\" commits.\n\n   old..new is a convenient equivalent for \"^old new\": everything in new's\n   history that is not included in old's history.  Thus, \"old1..new1\n   old2..new2\" is exactly synonymous with \"old1..new2 old2..new1\".\n   They both mean that new1, new2, and all their ancestors are included,\n   except that old1, old2, and all their ancestors are excluded.\n\n   There is one magic bit of syntax, the symmetric difference operator\n   \"rev1...rev2\" (note three dots).  That means all ancestors of rev1,\n   and all ancestors of rev2, but excluding all common ancestors of both.\n   It's also equivalent to an include-exclude list, but the computation\n   of the exclude set is a bit more complicated.  (It's usually just\n   one common ancestor, but there can be multiples in nasty criss-cross\n   merge cases.)\n\n3) \"git diff old..new\" uses the same syntax for a different purpose.\n   diff only works with two commits, so that's simply an alias for\n   \"git diff old new\".  (Whether this is a useful conveience or is too\n   misleading for the beginner has been the subject of heated discussion\n   on the git mailing list.)\n"},{"id":"68385","messageId":"m33arzfyhe.fsf@localhost.localdomain","threadId":"12005","inReplyTo":"20080210094753.23234.qmail@science.horizon.com","subject":"Re: Upcoming memcached releases + rambling.","fromName":"Jakub Narebski","fromEmail":"jnareb@fuw.edu.pl","sentAt":"2008-02-11T12:50:53Z","receivedAt":"2008-02-11T12:50:53Z","isPatch":false,"sender":{"key":"jnareb@fuw.edu.pl","avatar":null},"body":"\"George Spelvin\" <linux@horizon.com> writes:\n\n> A few notes about git that may be causing confusion:\n> \n> 1) \"git pull\" does more than you think, and is for developers only.\n> \n>    To just follow some other work, use only \"git fetch\".\n> \n>    \"git pull\" does a fetch, and then merges the fetched branch into your\n>    current HEAD.  If your current HEAD is a copy of the remote branch,\n>    this will be harmless, but if it's not, it will produce code changes.\n\nNote that \"git fetch\" usually fetches multiple branches; with default\nconfiguration it fetches _all_ the branches. \"git pull\" would merge\nthe one marked for merge into current branch (HEAD is current branch),\neither the one marked explicitely, or the first/main branch.\n \n>    \"git fetch\" will fetch the remote branch, and then do a \"fast-forward\"\n>    update of the corresponding local tracking branch.  If the local\n>    tracking branch is not an ancestor of the fetched branch, it will\n>    abort with an error.\n\nBut you can force fetching even if branch(es) in remote repository are\nnot ancestors of local tracking branches, which is needed if tracked\nbranch is rewound, reforked or rebased. Moreover by default this check\nis disabled: all fetches are \"forced\".\n\nYou can always go to the previous value of branch thanks to reflogs,\nso it is not really less safe, and avoids some hassle.\n\n>    So, in summary, don't use \"pull\" unless you want to do a merge.\n>    It will suppress the merge in the obvious trivial cases (no changes\n>    on one side or the other), but will happily combine things.\n> \n>    (The reason that \"pull\" is such a prominent command is that it's what\n>    Linus does all day: merges other people's development into his tree.)\n\nBTW. with newest git \"git pull\" _can_ rebase instead of merge.\n\n> 2) \"git log old..new\" is a special case of a very general mechanism\n>    for specifying a set of commits to examine.\n\n>    The syntax is \"include1 include2 ^exclude1 ^exclude2 include3...\".\n\n>    There is one magic bit of syntax, the symmetric difference operator\n>    \"rev1...rev2\" (note three dots).  That means all ancestors of rev1,\n>    and all ancestors of rev2, but excluding all common ancestors of both.\n>    It's also equivalent to an include-exclude list, but the computation\n>    of the exclude set is a bit more complicated.  (It's usually just\n>    one common ancestor, but there can be multiples in nasty criss-cross\n>    merge cases.)\n\n\"rev1...rev2\" is equivalent to \"rev1 rev2 --not $(git merge-base rev1 rev2)\"\nwhich I think explains what it does.\n \n> 3) \"git diff old..new\" uses the same syntax for a different purpose.\n>    diff only works with two commits, so that's simply an alias for\n>    \"git diff old new\".  (Whether this is a useful conveience or is too\n>    misleading for the beginner has been the subject of heated discussion\n>    on the git mailing list.)\n\nBy the way, \"git diff rev1...rev2\" also works, and shows diff between\nrev2 and common ancestor of rev1 and rev2 (merge base).\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"}]}