{"thread":{"id":"24518","subject":"need advice on usage patterns","startedAt":"2010-07-26T00:34:31Z","lastAt":"2010-07-27T09:13:32Z","messageCount":8,"participants":["Geoff Russell","Jonathan Nieder","Thomas Rast","Ævar Arnfjörð Bjarmason"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"146336","messageId":"AANLkTi=g2YNQtiH7+xzqWeoOV6p5r+Nwtt2kkCd3u6JN@mail.gmail.com","threadId":"24518","inReplyTo":null,"subject":"need advice on usage patterns","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2010-07-26T00:34:31Z","receivedAt":"2010-07-26T00:34:31Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"Hi,\n\nI'm after advice on usage patterns.\n\nWe are looking to use git to manage our release+patching process. We\nrelease our\nsoftware as a couple of directories (bin+tables). Mostly we then send updates\nto single customers without always testing that the update will work\nfor all customers.\nOther updates apply to everybody.\n\nOur thought is to have a \"central\" repository with the well tested\nprograms and branches for\neach customer for versions that should not be sent to everybody. The\ndevelopers work on their\nown local repositories and push branches to the central one for final\ntesting prior to distribution.\nThe most common usage would be to rebase the branches on the latest master.\nA developer should be able to just \"git pull\" and get updates to\nbranches for all customers.\n\nThere are notes on the \"git pull\" man page about not working on a remote branch\nbut having a local branch with a different name and merging the remote branch.\nWhy is this necessary?\n\nDoes anyone have comments or advice on alternative ways to manage\nthis? The remote branch\ncommands seem rather complex, has anybody written scripts to\nsimplify the process of interacting with remote branches?\n\nCheers and thanks,\n\nGeoff Russell\n"},{"id":"146338","messageId":"20100726033634.GA30877@burratino","threadId":"24518","inReplyTo":"AANLkTi=g2YNQtiH7+xzqWeoOV6p5r+Nwtt2kkCd3u6JN@mail.gmail.com","subject":"git pull (Re: need advice on usage patterns)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-26T03:36:34Z","receivedAt":"2010-07-26T03:36:34Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Geoff,\n\nGeoff Russell wrote:\n\n> There are notes on the \"git pull\" man page about not working on a remote branch\n> but having a local branch with a different name and merging the remote branch.\n> Why is this necessary?\n\nThe \"git pull\" man page is very unclear, I agree. Especially when\nstarting out, I would recommend looking at the User’s Manual (and the\nother resources the git(1) man page recommends).\n\nIn this case, the section to look at would be Chapter 4, on Sharing\ndevelopment with others[1].\n\nThanks for noticing.\nJonathan\n\n[1] http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#sharing-development\n\n-- 8< --\nSubject: pull documentation: Flesh out description\n\nThe current description in the pull man page does not say much more\nthan that “git pull” is fetch + merge. Though that is all a person\nneeds to know in the end, it would be useful to summarize a bit about\nwhat those commands do for new readers.\n\nMost of this description is taken from the “git merge” docs.\n\nCc: Thomas Rast \nSigned-off-by: Jonathan Nieder \n---\n Documentation/git-pull.txt | 61 +++++++++++++++++++++++++++++++++++--------\n 1 files changed, 49 insertions(+), 12 deletions(-)\n\ndiff --git a/Documentation/git-pull.txt b/Documentation/git-pull.txt\nindex ab4de10..8803680 100644\n--- a/Documentation/git-pull.txt\n+++ b/Documentation/git-pull.txt\n@@ -8,29 +8,66 @@ git-pull - Fetch from and merge with another repository or a local branch\n \n SYNOPSIS\n --------\n-'git pull' ...\n+'git pull' ...\n \n \n DESCRIPTION\n -----------\n-Runs 'git fetch' with the given parameters, and calls 'git merge'\n-to merge the retrieved head(s) into the current branch.\n-With `--rebase`, calls 'git rebase' instead of 'git merge'.\n \n-Note that you can use `.` (current directory) as the\n- to pull from the local repository -- this is useful\n-when merging local branches into the current branch.\n+Incorporates changes from a remote repository into the current\n+branch. In its default mode, a `git pull` is shorthand for\n+`git fetch` followed by `git merge FETCH_HEAD`.\n \n-Also note that options meant for 'git pull' itself and underlying\n-'git merge' must be given before the options meant for 'git fetch'.\n+More precisely, 'git pull' runs 'git fetch' with the given\n+parameters and calls 'git merge' to merge the retrieved branch\n+heads into the current branch.\n+With `--rebase`, it runs 'git rebase' instead of 'git merge'.\n \n-*Warning*: Running 'git pull' (actually, the underlying 'git merge')\n-with uncommitted changes is discouraged: while possible, it leaves you\n-in a state that is hard to back out of in the case of a conflict.\n+ should be the name of a remote repository as\n+passed to linkgit:git-fetch[1]. can be an\n+arbitrary refspec (for example, the name of a tag), but\n+usually it is the name of a branch in the remote repository.\n+\n+Default values for and are read from the\n+\"remote\" and \"merge\" configuration for the current branch\n+as set by linkgit:git-branch[1] `--track`.\n+\n+Assume the following history exists and the current branch is\n+\"`master`\":\n+\n+------------\n+ A---B---C master on origin\n+ /\n+ D---E---F---G master\n+------------\n+\n+Then \"`git pull`\" will fetch and replay the changes from the remote\n+`master` branch since it diverged from the local `master` (i.e., `E`)\n+until its current commit (`C`) on top of `master` and record the\n+result in a new commit along with the names of the two parent commits\n+and a log message from the user describing the changes.\n+\n+------------\n+ A---B---C remotes/origin/master\n+ / \\\n+ D---E---F---G---H master\n+------------\n+\n+See linkgit:git-merge[1] for details, including how conflicts\n+are presented and handled. To cancel a conflicting merge,\n+use `git reset --merge`.\n+\n+If any of the remote changes overlap with local uncommitted changes,\n+the merge will be automatically cancelled and the work tree untouched.\n+It is generally best to get any local changes in working order before\n+pulling or stash them away with linkgit:git-stash[1].\n \n OPTIONS\n -------\n \n+Options meant for 'git pull' itself and the underlying 'git merge'\n+must be given before the options meant for 'git fetch'.\n+\n -q::\n --quiet::\n \tThis is passed to both underlying git-fetch to squelch reporting of\n-- \n1.7.1\n"},{"id":"146349","messageId":"201007260916.27306.trast@student.ethz.ch","threadId":"24518","inReplyTo":"20100726033634.GA30877@burratino","subject":"Re: git pull (Re: need advice on usage patterns)","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-07-26T07:16:27Z","receivedAt":"2010-07-26T07:16:27Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jonathan Nieder wrote:\n> +Incorporates changes from a remote repository into the current\n> +branch. In its default mode, a `git pull` is shorthand for\n> +`git fetch` followed by `git merge FETCH_HEAD`.\n\nIn my ears, \"a `git pull` is...\" sounds weird. I would remove the\n'a'. But maybe it's just my non-native English hard(ly) at work...\n\n> -*Warning*: Running 'git pull' (actually, the underlying 'git merge')\n> -with uncommitted changes is discouraged: while possible, it leaves you\n> -in a state that is hard to back out of in the case of a conflict.\n[...]\n> +See linkgit:git-merge[1] for details, including how conflicts\n> +are presented and handled. To cancel a conflicting merge,\n> +use `git reset --merge`.\n> +\n> +If any of the remote changes overlap with local uncommitted changes,\n> +the merge will be automatically cancelled and the work tree untouched.\n> +It is generally best to get any local changes in working order before\n> +pulling or stash them away with linkgit:git-stash[1].\n\nThere's a slight risk with it because people might read this version\nof the manpage online and then conclude that it is safe to try a merge\nwith uncommitted changes, only to find that their git-reset doesn't\nsupport --merge yet. Or worse, verify that their git-reset has\n--merge by a quick test (1b5b465 is in 1.6.2) but then find that it\ndoes not help with backing out of a merge (e11d7b5 is only in 1.7.0!).\n\nThen again, who reads these manpages anyway? And we shouldn't let old\nversions get in the way of having consistent and up-to-date docs. So,\n\nAcked-by: Thomas Rast \n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"},{"id":"146363","messageId":"AANLkTikPHARaosHLwaKUqL12va4F7O3WMp1I4LIpu7Mp@mail.gmail.com","threadId":"24518","inReplyTo":"20100726033634.GA30877@burratino","subject":"Re: git pull (Re: need advice on usage patterns)","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-07-26T10:26:35Z","receivedAt":"2010-07-26T10:26:35Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Mon, Jul 26, 2010 at 03:36, Jonathan Nieder wrote:\n\n> -'git pull' ...\n> +'git pull' ...\n\nWasn't it \"refspec\" because git-pull can take args like\n\"refs/remotes/origin/*:refs/heads/*\", not just branch names?\n"},{"id":"146366","messageId":"AANLkTimP8oQ-482QMuTjnX0zvCfadoQvq+=MkADfkTbV@mail.gmail.com","threadId":"24518","inReplyTo":"AANLkTikPHARaosHLwaKUqL12va4F7O3WMp1I4LIpu7Mp@mail.gmail.com","subject":"Re: git pull (Re: need advice on usage patterns)","fromName":"Geoff Russell","fromEmail":"geoffrey.russell@gmail.com","sentAt":"2010-07-26T10:37:19Z","receivedAt":"2010-07-26T10:37:19Z","isPatch":false,"sender":{"key":"geoffrey.russell@gmail.com","avatar":"https://gravatar.com/avatar/c30f497ccfa6bf06d86f30bd2ba092a2dd124c61c6bc902f7cb5c3f6486947de?d=mp&s=160"},"body":"On Mon, Jul 26, 2010 at 7:56 PM, Ævar Arnfjörð Bjarmason\n wrote:\n> On Mon, Jul 26, 2010 at 03:36, Jonathan Nieder wrote:\n>\n>> -'git pull' ...\n>> +'git pull' ...\n>\n> Wasn't it \"refspec\" because git-pull can take args like\n> \"refs/remotes/origin/*:refs/heads/*\", not just branch names?\n>\n\nYes.\n\nThinking about the pull as 2 operations \"fetch+merge\" should have\nalerted me to the\npossibility that it could update 2 branches, ... the one in the\n as well\nas the current branch ... if they are different.\n\nThanks,\n\nGeoff\n"},{"id":"146378","messageId":"20100726141752.GA1745@burratino","threadId":"24518","inReplyTo":"AANLkTikPHARaosHLwaKUqL12va4F7O3WMp1I4LIpu7Mp@mail.gmail.com","subject":"Re: git pull (Re: need advice on usage patterns)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-26T14:17:52Z","receivedAt":"2010-07-26T14:17:52Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Mon, Jul 26, 2010 at 03:36, Jonathan Nieder wrote:\n\n>> -'git pull' ...\n>> +'git pull' ...\n>\n> Wasn't it \"refspec\" because git-pull can take args like\n> \"refs/remotes/origin/*:refs/heads/*\", not just branch names?\n\nYes, by abuse of language that might be called the noble lie (or\nsomething; notice later where it says \" can be an arbitrary\nrefspec). Better ways to achieve the same effect would be welcome.\n"},{"id":"146427","messageId":"20100726200613.GB1451@burratino","threadId":"24518","inReplyTo":"201007260916.27306.trast@student.ethz.ch","subject":"Re: git pull (Re: need advice on usage patterns)","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2010-07-26T20:06:13Z","receivedAt":"2010-07-26T20:06:13Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Thomas Rast wrote:\n\n> In my ears, \"a `git pull` is...\" sounds weird. I would remove the\n> 'a'.\n\nGood idea.\n\n> Jonathan Nieder wrote:\n\n>> -*Warning*: Running 'git pull' (actually, the underlying 'git merge')\n>> -with uncommitted changes is discouraged: while possible, it leaves you\n>> -in a state that is hard to back out of in the case of a conflict.\n>[...]\n>> +See linkgit:git-merge[1] for details, including how conflicts\n>> +are presented and handled. To cancel a conflicting merge,\n>> +use `git reset --merge`.\n[...]\n> Or worse, verify that their git-reset has\n> --merge by a quick test (1b5b465 is in 1.6.2) but then find that it\n> does not help with backing out of a merge (e11d7b5 is only in 1.7.0!).\n> \n> Then again, who reads these manpages anyway? And we shouldn't let old\n> versions get in the way of having consistent and up-to-date docs. So,\n\nAgh, surely we can do better. Maybe:\n\n\tSee linkgit:git-merge[1] for details, including how conflicts\n\tare presented and handled.\n\n\tifdef::stalenotes[]\n\tIn git 1.7.0 or later, to cancel a conflicting merge, use\n\t`git reset --merge`.\n\t*Warning*: In older versions of git, running 'git pull'\n\twith uncommited changes is discouraged: while possible,\n\tit leaves you in a state that may be hard to back out of\n\tin the case of a conflict.\n\telse::stalenotes[]\n\tTo cancel a conflicting merge, use `git reset --merge`.\n\tendif::stalenotes[]\n\nwith the appropriate corresponding change to todo:dodoc.sh.\n"},{"id":"146458","messageId":"201007271113.32711.trast@student.ethz.ch","threadId":"24518","inReplyTo":"20100726200613.GB1451@burratino","subject":"Re: git pull (Re: need advice on usage patterns)","fromName":"Thomas Rast","fromEmail":"trast@student.ethz.ch","sentAt":"2010-07-27T09:13:32Z","receivedAt":"2010-07-27T09:13:32Z","isPatch":false,"sender":{"key":"tr@thomasrast.ch","avatar":"https://avatars.githubusercontent.com/u/153510?v=4"},"body":"Jonathan Nieder wrote:\n> Thomas Rast wrote:\n> [...]\n> > Or worse, verify that their git-reset has\n> > --merge by a quick test (1b5b465 is in 1.6.2) but then find that it\n> > does not help with backing out of a merge (e11d7b5 is only in 1.7.0!).\n> > \n> > Then again, who reads these manpages anyway? And we shouldn't let old\n> > versions get in the way of having consistent and up-to-date docs. So,\n> \n> Agh, surely we can do better. Maybe:\n> \n> \tSee linkgit:git-merge[1] for details, including how conflicts\n> \tare presented and handled.\n> \n> \tifdef::stalenotes[]\n> \tIn git 1.7.0 or later, to cancel a conflicting merge, use\n> \t`git reset --merge`.\n> \t*Warning*: In older versions of git, running 'git pull'\n> \twith uncommited changes is discouraged: while possible,\n> \tit leaves you in a state that may be hard to back out of\n> \tin the case of a conflict.\n> \telse::stalenotes[]\n> \tTo cancel a conflicting merge, use `git reset --merge`.\n> \tendif::stalenotes[]\n\nSounds good. Maybe you can call this attribute 'webdocs' or so, so\nthat we have a generic means of modifying the kernel.org hosted docs?\n\nAlso, apparently there is no else::...[] so you have to do an\nendif/ifndef pair.\n\n-- \nThomas Rast\ntrast@{inf,student}.ethz.ch\n"}]}