{"thread":{"id":"7626","subject":"[RFC] git-clone: add --track <headname> support","startedAt":"2007-04-12T10:08:59Z","lastAt":"2007-04-13T03:50:35Z","messageCount":9,"participants":["Martin Langhoff","Junio C Hamano","Carl Worth"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"39211","messageId":"1176372539871-git-send-email-martin@catalyst.net.nz","threadId":"7626","inReplyTo":null,"subject":"[RFC] git-clone: add --track <headname> support","fromName":"Martin Langhoff","fromEmail":"martin@catalyst.net.nz","sentAt":"2007-04-12T10:08:59Z","receivedAt":"2007-04-12T10:08:59Z","isPatch":false,"sender":{"key":"martin@laptop.org","avatar":null},"body":"Add support for a simplified workflow where users\nwant to clone and start working on a head that is\ndifferent from the HEAD of the repository.\n\nCalling\n\n   git-clone --track maint <repo>\n\nIs equivalent to\n\n   git-clone <repo> mydir\n   cd mydir\n   git-checkout --track -b maint origin/maint\n\n--\n\nNot sure if Junio wants this, but if I am going to migrate\naway from cogito, I'd like these common operations to be\ndead simple. \n\nThis is something cogito supports using the <repo>#branchname\nsyntax. I am pretty sure git supports it when fetching\nbut alas, no longer for cloning. \n\nAnd if we want it, there are 2 things I'd ask review for\n\n - The --track parameter handling - I merely copied the \n   handling for other parameters. Clearly shell doesn't\n   do this very elegantly, or at least we don't. \n\n - The block that defines head_points_at (@360-370) looks \n   very brittle so I didn't want to mess with it. \n\n---\n git-clone.sh |   39 +++++++++++++++++++++++++++------------\n 1 files changed, 27 insertions(+), 12 deletions(-)\n\ndiff --git a/git-clone.sh b/git-clone.sh\nindex e98e064..c7b3e99 100755\n--- a/git-clone.sh\n+++ b/git-clone.sh\n@@ -14,7 +14,7 @@ die() {\n }\n \n usage() {\n-\tdie \"Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--depth <n>] [-n] <repo> [<dir>]\"\n+\tdie \"Usage: $0 [--template=<template_directory>] [--reference <reference-repo>] [--bare] [-l [-s]] [-q] [-u <upload-pack>] [--origin <name>] [--track <head>] [--depth <n>] [-n] <repo> [<dir>]\"\n }\n \n get_repo_base() {\n@@ -85,6 +85,7 @@ bare=\n reference=\n origin=\n origin_override=\n+track=\n use_separate_remote=t\n depth=\n no_progress=\n@@ -105,6 +106,11 @@ while\n \t\tshift; template=\"--template=$1\" ;;\n \t*,--template=*)\n \t  template=\"$1\" ;;\n+\t1,--track) usage ;;\n+\t*,--track)\n+\t\tshift; track=\"$1\" ;;\n+\t*,--track=*)\n+\t  track=\"$1\" ;;\n \t*,-q|*,--quiet) quiet=-q ;;\n \t*,--use-separate-remote) ;;\n \t*,--no-separate-remote)\n@@ -344,17 +350,22 @@ if test -z \"$bare\" && test -f \"$GIT_DIR/REMOTE_HEAD\"\n then\n \t# a non-bare repository is always in separate-remote layout\n \tremote_top=\"refs/remotes/$origin\"\n-\thead_sha1=`cat \"$GIT_DIR/REMOTE_HEAD\"`\n-\tcase \"$head_sha1\" in\n-\t'ref: refs/'*)\n-\t\t# Uh-oh, the remote told us (http transport done against\n-\t\t# new style repository with a symref HEAD).\n-\t\t# Ideally we should skip the guesswork but for now\n-\t\t# opt for minimum change.\n-\t\thead_sha1=`expr \"z$head_sha1\" : 'zref: refs/heads/\\(.*\\)'`\n-\t\thead_sha1=`cat \"$GIT_DIR/$remote_top/$head_sha1\"`\n-\t\t;;\n-\tesac\n+\tif test ! -z \"$track\" && test -f \"refs/remotes/$origin/$track\"\n+\tthen\n+\t\thead_sha1=`cat \"refs/remotes/$origin/$track\"`\n+\telse\n+\t\thead_sha1=`cat \"$GIT_DIR/REMOTE_HEAD\"`\n+\t\tcase \"$head_sha1\" in\n+\t\t'ref: refs/'*)\n+\t\t\t# Uh-oh, the remote told us (http transport done against\n+\t\t\t# new style repository with a symref HEAD).\n+\t\t\t# Ideally we should skip the guesswork but for now\n+\t\t\t# opt for minimum change.\n+\t\t\thead_sha1=`expr \"z$head_sha1\" : 'zref: refs/heads/\\(.*\\)'`\n+\t\t\thead_sha1=`cat \"$GIT_DIR/$remote_top/$head_sha1\"`\n+\t\t\t;;\n+\t\tesac\n+\tfi\n \n \t# The name under $remote_top the remote HEAD seems to point at.\n \thead_points_at=$(\n@@ -376,6 +387,10 @@ then\n \t\tdone\n \t\t)\n \t)\n+\tif test -n \"$track\" && test -f \"$GIT_DIR/$remote_top/$track\"\n+\tthen\n+\t\thead_points_at=\"$track\"\n+\tfi\n \n \t# Write out remote.$origin config, and update our \"$head_points_at\".\n \tcase \"$head_points_at\" in\n-- \n1.5.1.106.ga32037\n"},{"id":"39212","messageId":"7vk5whki24.fsf@assigned-by-dhcp.cox.net","threadId":"7626","inReplyTo":"1176372539871-git-send-email-martin@catalyst.net.nz","subject":"Re: [RFC] git-clone: add --track <headname> support","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-12T10:23:15Z","receivedAt":"2007-04-12T10:23:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin@catalyst.net.nz> writes:\n\n> Add support for a simplified workflow where users\n> want to clone and start working on a head that is\n> different from the HEAD of the repository.\n>\n> Calling\n>\n>    git-clone --track maint <repo>\n>\n> Is equivalent to\n>\n>    git-clone <repo> mydir\n>    cd mydir\n>    git-checkout --track -b maint origin/maint\n>\n> --\n>\n> Not sure if Junio wants this, but if I am going to migrate\n> away from cogito, I'd like these common operations to be\n> dead simple. \n\nI am not interested in moving people away from cogito ;-).\n\nWith the talk about making more things built-in, I think the\nchanges to clone and fetch should be done by first rewriting\ngit-clone as a very thin shell wrapper that essentially does:\n\n\tfigure out the directory name to use\n        mkdir that directory and cd into it\n        run git init with appropriate options\n        run git remote add with appropriate options\n        run git fetch with appropriate options\n        run git checkout with appropriate options (unless -n)\n\nAlso you might want to check \"branch.autosetupmerge\" config.  It\nseems to be described in git-branch manual page without being\nlisted in Documentation/config.txt, which is a bad that happend\nsome time ago X-<.\n\nIt seems that today has been a day to discover many bads that\nhappened some time ago for me X-<.  I should quit and call it a\nday now...\n"},{"id":"39221","messageId":"87veg1tuuv.wl%cworth@cworth.org","threadId":"7626","inReplyTo":"1176372539871-git-send-email-martin@catalyst.net.nz","subject":"Re: [RFC] git-clone: add --track <headname> support","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-12T16:34:16Z","receivedAt":"2007-04-12T16:34:16Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 12 Apr 2007 22:08:59 +1200, Martin Langhoff wrote:\n> Not sure if Junio wants this, but if I am going to migrate\n> away from cogito, I'd like these common operations to be\n> dead simple.\n\nHi Martin,\n\nWhether we're talking about cogito migration or not, I also want these\noperations to be dead simple. So I really appreciate seeing your\nefforts on this front.\n\n> This is something cogito supports using the <repo>#branchname\n> syntax. I am pretty sure git supports it when fetching\n> but alas, no longer for cloning.\n\nI seem to recall Linus complaining about the <repo>#branchname syntax\nbecause it allows for only one branch name. So one thing to think\nabout is how to allow for multiple branches to be tracked while\ncloning, (\"--track branch1 --track branch2\" ?).\n\nSeparately, something I've always wanted is a succint way to advertise\na complete specification of a branch that users could conveniently\ntake, (read, \"cut-and-paste, preferably with double-click\"), and use\nwhether they wanted to do any one of the following operations:\n\n1. Make a new clone, and checkout that branch\n\n2. Fetch that branch into an existing clone\n\n3. Add that branch to an existing clone as something to start tracking\n\nSo, if you wanted to try to tackle that problem as well, that would be\ngreat. (It's basically an extension of your \"git clone --track\"\nidea---allowing it to be performed after a clone as well, but without\nany more complication in the user interface.)\n\nFor this, I think the <repo>#branch syntax is actually worthing\nthinking about. With it, the above three operations could be provided\nwith operations something like:\n\n\tgit clone <repo>#branch\n\n\tgit fetch <repo>#branch\n\n\tgit track <repo>#branch\n\nWhere this new git-track command would encompass a lot of the work\nthat git-clone is doing currently. That is, the git-clone rewrite\nthat Junio is envisioning could be implemented something like:\n\n\tmkdir <branch>\n\tcd <branch>\n\tgit init-db\n\tgit track <repo>#branch\n\nIn other words, most of the interesting stuff that git-clone does\nwould still be available in an existing clone by using this new\ngit-track command.\n\nBy the way, the <repo>#branch syntax isn't essential for what I'm\ndescribing here. This syntax does provide something that could be\nusefully provided to either git-clone or git-fetch as a single\ncommand. This is opposed to the current state where I have to say\nthings like:\n\n\tIf you've got a clone already, do: [*]\n\n\t\tgit fetch <repo> branch:branch\n\t\tgit checkout branch\n\n\tIf you don't have a clone yet, do:\n\n\t\tgit clone <repo>\n\t\tgit checkout -b branch origin/branch\n\nBut whether or not <repo>#branch syntax is adopted, providing the\npost-init-db guts of git-track would still be useful, and it could\nstill accept the same means of specifying multiple branches that git\nfetch accepts:\n\n\tgit track <repo> branch1 branch2 ...\n\nAnyway, there's some food for thought for anyone that's working on\nadding these kind of conveniences to git, (which I would find\nextremely valuable).\n\n-Carl\n"},{"id":"39233","messageId":"461EA56B.5000400@catalyst.net.nz","threadId":"7626","inReplyTo":"7vk5whki24.fsf@assigned-by-dhcp.cox.net","subject":"Re: [RFC] git-clone: add --track <headname> support","fromName":"Martin Langhoff","fromEmail":"martin@catalyst.net.nz","sentAt":"2007-04-12T21:32:27Z","receivedAt":"2007-04-12T21:32:27Z","isPatch":false,"sender":{"key":"martin@laptop.org","avatar":null},"body":"Junio C Hamano wrote:\n> Martin Langhoff <martin@catalyst.net.nz> writes:\n>> Not sure if Junio wants this, but if I am going to migrate\n>> away from cogito, I'd like these common operations to be\n>> dead simple. \n> \n> I am not interested in moving people away from cogito ;-).\n\nWell... ;-) in any case, I suspect some of the semantics cogito uses are\nstarting to break... it's kinda-supported-but-legacy.\n\nSo I think we need these niceties in core git for large projects. Right\nnow we have an explosion of ways of doing things, and many of them\nerror-prone. The basic idioms should be simple and fool-proof.\n\n> With the talk about making more things built-in...\n\nCan we not have something like this merged into the shell version? When\nthe C version comes, the functionality can be modelled on this.\n\n> Also you might want to check \"branch.autosetupmerge\" config.  It\n> seems to be described in git-branch manual page without being\n> listed in Documentation/config.txt, which is a bad that happend\n> some time ago X-<.\n\nWill to. Thanks.\n\n> It seems that today has been a day to discover many bads that\n> happened some time ago for me X-<.  I should quit and call it a\n> day now...\n\nHope your next day is better. Hugs from NZ.\n\n\n\nm\n-- \n-----------------------------------------------------------------------\nMartin @ Catalyst .Net .NZ  Ltd, PO Box 11-053, Manners St,  Wellington\nWEB: http://catalyst.net.nz/           PHYS: Level 2, 150-154 Willis St\nOFFICE: +64(4)916-7224  UK: 0845 868 5733 ext 7224  MOB: +64(21)364-017\n      Make things as simple as possible, but no simpler - Einstein\n-----------------------------------------------------------------------\n"},{"id":"39234","messageId":"461EA8C5.1070503@catalyst.net.nz","threadId":"7626","inReplyTo":"87veg1tuuv.wl%cworth@cworth.org","subject":"Re: [RFC] git-clone: add --track <headname> support","fromName":"Martin Langhoff","fromEmail":"martin@catalyst.net.nz","sentAt":"2007-04-12T21:46:45Z","receivedAt":"2007-04-12T21:46:45Z","isPatch":false,"sender":{"key":"martin@laptop.org","avatar":null},"body":"Carl Worth wrote:\n> Whether we're talking about cogito migration or not, I also want these\n> operations to be dead simple. So I really appreciate seeing your\n> efforts on this front.\n\nHi Carl! Yes - this stuff should be simple, and _really hard to fsck up_.\n\n> I seem to recall Linus complaining about the <repo>#branchname syntax\n> because it allows for only one branch name. So one thing to think\n> about is how to allow for multiple branches to be tracked while\n> cloning, (\"--track branch1 --track branch2\" ?).\n\nThat wouldn't be hard to implement. Actually, we could support both.\n\n> Separately, something I've always wanted is a succint way to advertise\n> a complete specification of a branch that users could conveniently\n> take, (read, \"cut-and-paste, preferably with double-click\"), and use\n> whether they wanted to do any one of the following operations:\n(...)\n> For this, I think the <repo>#branch syntax is actually worthing\n> thinking about. With it, the above three operations could be provided\n> with operations something like:\n> \n> \tgit clone <repo>#branch\n> \n> \tgit fetch <repo>#branch\n> \n> \tgit track <repo>#branch\n\nSo you are proposing (or maybe I am re-interpreting things so) that\n\n  git track <repo>#branch\n\nshould Do The Right Thing:\n\n - perform a clone if we aren't in a repo\n - set things up for tracking the branch if we are in a repo\n\nI like the idea. :-)\n\n> Where this new git-track command would encompass a lot of the work\n> that git-clone is doing currently. That is, the git-clone rewrite\n> that Junio is envisioning could be implemented something like:\n> \n> \tmkdir <branch>\n> \tcd <branch>\n> \tgit init-db\n> \tgit track <repo>#branch\n\nOops - looks like we are talking about different things. What you write\nabove can be done with \"git-branch --track\" on 1.5.1 so it's already in\nexistence.\n\n> By the way, the <repo>#branch syntax isn't essential for what I'm\n> describing here. This syntax does provide something that could be\n> usefully provided to either git-clone or git-fetch as a single\n> command. This is opposed to the current state where I have to say\n> things like:\n> \n> \tIf you've got a clone already, do: [*]\n> \n> \t\tgit fetch <repo> branch:branch\n> \t\tgit checkout branch\n> \n> \tIf you don't have a clone yet, do:\n> \n> \t\tgit clone <repo>\n> \t\tgit checkout -b branch origin/branch\n\nWith my proposed git-track as a wrapper around git-clone _and_\ngit-branch --track, you only need to say\n\n    To start working on foo, do\n\n      git track <repo>#branch\n\nAnd if the user has an existing checkout they can do if from inside the\ncheckout, or perhaps better, saying\n\n     git track --reference <myoldcheckout> <repo>#branch\n\nto avoid the biiig download.\n\n\ncheers,\n\n\n\nm\n-- \n-----------------------------------------------------------------------\nMartin @ Catalyst .Net .NZ  Ltd, PO Box 11-053, Manners St,  Wellington\nWEB: http://catalyst.net.nz/           PHYS: Level 2, 150-154 Willis St\nOFFICE: +64(4)916-7224  UK: 0845 868 5733 ext 7224  MOB: +64(21)364-017\n      Make things as simple as possible, but no simpler - Einstein\n-----------------------------------------------------------------------\n"},{"id":"39244","messageId":"87slb5tbvu.wl%cworth@cworth.org","threadId":"7626","inReplyTo":"461EA8C5.1070503@catalyst.net.nz","subject":"Re: [RFC] git-clone: add --track <headname> support","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-04-12T23:24:05Z","receivedAt":"2007-04-12T23:24:05Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 13 Apr 2007 09:46:45 +1200, Martin Langhoff wrote:\n> Hi Carl! Yes - this stuff should be simple, and _really hard to fsck up_.\n\nI definitely agree. I think the use case of \"tracking some branch\nother than the default\" is a really important one to make\neasy. Precisely because there are a lot of users who will initially\nuse git for nothing other than this tracking, (not initially making\ncommits, or pushing, etc.).\n\nSo we would do well if this initial exposure were really easy. And\nright now it's a bit too hard in my opinion, (in terms of commands,\nconcepts, and syntax the user has to use).\n\nIs this correct sequence for the operation in 1.5.1 ?\n\n\tgit clone <repo>\n\tcd <project>\n\tgit branch --track <branch> origin/<branch>\n\tgit checkout branch\n\tgit pull # as needed\n\nI'd love to get that down to:\n\n\tgit clone <something with <repo> and <branch>>\n\tcd <project>\n\tgit pull # as needed\n\nand then adding a subsequent branch to track would be:\n\n\tgit track <something with <repo> and <branch>>\n\tgit checkout <branch>\n\tgit pull # as needed\n\n> Oops - looks like we are talking about different things. What you write\n> above can be done with \"git-branch --track\" on 1.5.1 so it's already in\n> existence.\n\nThe mechanics are there, yes. All that's missing is the common\n<something> syntax which, as shown above, can be shared for both\ncloning originally and later adding a branch to track.\n\nAnd <repo>#<branch> seems as good a <something> as anything else I\ncould imagine.\n\n> With my proposed git-track as a wrapper around git-clone _and_\n> git-branch --track, you only need to say\n>\n>     To start working on foo, do\n>\n>       git track <repo>#branch\n\nYeah, that's the idea. I had just planned on publishing the\n<repo>#branch part and the user would learn whether to pass that to\n\"git clone\" or \"git track\" as appropriate.\n\nMaking one command do either one seems a little too DWIM and\nerror-prone to me. But whatever works, (and more importantly, whatever\nyou can implement and get accepted).\n\n-Carl\n"},{"id":"39247","messageId":"461EC5DC.6060903@catalyst.net.nz","threadId":"7626","inReplyTo":"87slb5tbvu.wl%cworth@cworth.org","subject":"Re: [RFC] git-clone: add --track <headname> support","fromName":"Martin Langhoff","fromEmail":"martin@catalyst.net.nz","sentAt":"2007-04-12T23:50:52Z","receivedAt":"2007-04-12T23:50:52Z","isPatch":false,"sender":{"key":"martin@laptop.org","avatar":null},"body":"Carl Worth wrote:\n> Is this correct sequence for the operation in 1.5.1 ?\n> \n> \tgit clone <repo>\n> \tcd <project>\n> \tgit branch --track <branch> origin/<branch>\n> \tgit checkout branch\n> \tgit pull # as needed\n> \n\nActually you don't need the git-checkout line\n\n\tgit clone <repo>\n\tcd <project>\n\tgit branch --track <branch> origin/<branch>\n\tgit pull # as needed\n\n> I'd love to get that down to:\n> \n> \tgit clone <something with <repo> and <branch>>\n> \tcd <project>\n> \tgit pull # as needed\n\nThat's what this patch does.\n\n> and then adding a subsequent branch to track would be:\n> \n> \tgit track <something with <repo> and <branch>>\n> \tgit checkout <branch>\n> \tgit pull # as needed\n\nIf your tree is reasonably clean (so that the implied git-checkout won't\nfail), then on 1.5.1 this Just Works\n\n        git branch --track <branch> origin/<branch>\n        git pull # as needed\n\ncheers,\n\n\nm\n-- \n-----------------------------------------------------------------------\nMartin @ Catalyst .Net .NZ  Ltd, PO Box 11-053, Manners St,  Wellington\nWEB: http://catalyst.net.nz/           PHYS: Level 2, 150-154 Willis St\nOFFICE: +64(4)916-7224  UK: 0845 868 5733 ext 7224  MOB: +64(21)364-017\n      Make things as simple as possible, but no simpler - Einstein\n-----------------------------------------------------------------------\n"},{"id":"39253","messageId":"7v3b35i0db.fsf@assigned-by-dhcp.cox.net","threadId":"7626","inReplyTo":"461EC5DC.6060903@catalyst.net.nz","subject":"Re: [RFC] git-clone: add --track <headname> support","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-13T00:28:16Z","receivedAt":"2007-04-13T00:28:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Martin Langhoff <martin@catalyst.net.nz> writes:\n\n> If your tree is reasonably clean (so that the implied git-checkout won't\n> fail), then on 1.5.1 this Just Works\n>\n>         git branch --track <branch> origin/<branch>\n>         git pull # as needed\n\nAt least in theory, with branch.autosetupmerge, you shouldn't\neven have to say --track there.  I've never used it myself,\nthough.\n"},{"id":"39256","messageId":"7vps69gcfo.fsf@assigned-by-dhcp.cox.net","threadId":"7626","inReplyTo":"87slb5tbvu.wl%cworth@cworth.org","subject":"Re: [RFC] git-clone: add --track <headname> support","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-13T03:50:35Z","receivedAt":"2007-04-13T03:50:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth <cworth@cworth.org> writes:\n\n> I'd love to get that down to:\n>\n> \tgit clone <something with <repo> and <branch>>\n> \tcd <project>\n> \tgit pull # as needed\n>\n> and then adding a subsequent branch to track would be:\n>\n> \tgit track <something with <repo> and <branch>>\n> \tgit checkout <branch>\n> \tgit pull # as needed\n\nI have a different suggestion.  Why not forget about 'git clone'?\n\nAfter working in a clone of git.git, if you want to use the\nproject history from another related repository, say Shawn's\nfastimport, what would you do?\n\nYes.  You add it with \"git remote add\".\n\n\tgit remote add [options] gfi git://repo.or.cz/git/fastimport.git/\n\nIf you are _not_ working off of anybody else's work, how would\nyou start a repository?\n\nYes, you just do \"git init\" in an empty repository.\n\n\tgit init\n\nAnd after that, in such a repository, certainly \"git remote add\"\nto add the FIRST remote would work, wouldn't it?\n\nSo, how about this two-command sequence instead?\n\n (0) Have this in $HOME/.gitconfig:\n\n\t$ cat >>$HOME/.gitconfig <<\\EOF\n\t[branch]\n        \tautosetupmerge\n\tEOF\n\n (1) Prepare your working area and add the remote you want to\n     track, with initial fetch:\n\n        $ git remote add -f origin git://repo.or.cz/alt-git.git/\n\n (2) If you want to fork off of next, you can:\n\n\t$ git checkout -b next origin/next\n\nThe result of (2) reads like this:\n\n\t$ cat .git/config\n        [remote \"origin\"]\n                url = /opt/packrat/playpen/public/in-place/git/git.junio/\n                fetch = +refs/heads/*:refs/remotes/origin/*\n        [branch \"next\"]\n                remote = origin\n                merge = refs/heads/next\n\nThe [remote \"origin\"] section was added with (1), and [branch\n\"next\"] was done with (2).  It means \"When I am on 'next', if I\ndid not give any parameter to 'git pull', I want a fetch from\n'origin', and then get their 'next' branch merged.\".\n\nSo after setting up your 'next' branch with a single command (2),\nwhen you are finished working in your 'next' and are ready to\nmerge the corresponding 'next' branch of 'origin', you can just\nsay 'git pull'.  Isn't this what you want?\n\nAnd I do not think trying to mix up (1) and (2) is a great idea.\nWhenever you are interested in yet another person's work, you do\n(1).  And whenever you want to fork off of some remote tracking\nbranch you have already done (1) for, you do (2).  IOW, you can\ndo more than one (2) for a single remote repository.\n"}]}