{"thread":{"id":"12385","subject":"Which freedesktop.org \"design flaws\" in git are still relevant?","startedAt":"2008-02-29T20:32:49Z","lastAt":"2008-02-29T22:58:15Z","messageCount":9,"participants":["Elijah Newren","Nicolas Pitre","Jakub Narebski","Junio C Hamano","Daniel Barkalow","Jay Soffian"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"70414","messageId":"51419b2c0802291232w166b3100yabd30ba30df6ef1f@mail.gmail.com","threadId":"12385","inReplyTo":null,"subject":"Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-02-29T20:32:49Z","receivedAt":"2008-02-29T20:32:49Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nThe page http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws\ncontains a number of claimed UI flaws of git. I suspect that a number\nof them are out-of-date; it doesn't seem to jive with my recent\nreading of the documentation. Could anyone point out which are still\naccurate with recent git, and which aren't?\n\nThanks,\nElijah\n"},{"id":"70415","messageId":"alpine.LFD.1.00.0802291551310.4911@xanadu.home","threadId":"12385","inReplyTo":"51419b2c0802291232w166b3100yabd30ba30df6ef1f@mail.gmail.com","subject":"Re: Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-02-29T20:56:44Z","receivedAt":"2008-02-29T20:56:44Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Fri, 29 Feb 2008, Elijah Newren wrote:\n\n> Hi,\n> \n> The page http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws\n> contains a number of claimed UI flaws of git. I suspect that a number\n> of them are out-of-date; it doesn't seem to jive with my recent\n> reading of the documentation. Could anyone point out which are still\n> accurate with recent git, and which aren't?\n\nIt says:\n\n\tInfrastructure/git/UIFlaws (last edited 2007-06-03 18:41:26 by \n\tJakubNarebski) \n\nand despite being updated almost 9 months ago, the content feels even \nolder than that.\n\nJakub?\n\n\nNicolas\n"},{"id":"70421","messageId":"m3hcfrjwnk.fsf@localhost.localdomain","threadId":"12385","inReplyTo":"51419b2c0802291232w166b3100yabd30ba30df6ef1f@mail.gmail.com","subject":"Re: Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-29T21:11:15Z","receivedAt":"2008-02-29T21:11:15Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"\"Elijah Newren\" writes:\n\n> The page http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws\n> contains a number of claimed UI flaws of git. I suspect that a number\n> of them are out-of-date; it doesn't seem to jive with my recent\n> reading of the documentation. Could anyone point out which are still\n> accurate with recent git, and which aren't?\n\nI'll examine them point by point, and write replies when I know the\nanswer. Probably should correct wiki page, too...\n\n\n> * git-revert will refuse to back out multi-parent commits, ie,\n> merges. The obvious behaviour is to do basically what git-show\n> [commit] | patch -p1 -R would do, ie, roll back the tree state to\n> the branch you came from.\n\nIf I remember correctly there was some work done on cherry-picking,\nreverting (revert is cherry-picking reverse of a commit in the diff -R\nor patch -R sense) and rebase with multiparent commits, telling which\nof parent to treat. But I do not remember details.\n\nThe advice is of no use: git-show for merge (multi-parent) commits\neither doesn't show diff at all, or show compact combined diff \n(diff --cc) which cannot be applied. Another issue of note is that\n\"git revert\" does not roll back the tree state, but applies reversion\nof given change, i.e. reverts / undoes given _changeset_.\n\n> * 'git-rebase foo' is a noop, when foo is the name of local\n> branch. You would expect it to fetch the branch named foo from\n> upstream, and rebase your foo branch on top of it.\n\nNo, I would never expect git-rebase to fetch somthing. And \"git rebase\n\" is *not* no-op: it rebases (rebuilds) _current_ branch on\ntop of given branch.\n\nTo do fetch+rebase, i.e. update branch in rebase based workflow, use\n\"git pull --rebase\".\n\n> * git-fetch requires that the branch be named on both sides of\n> the :. It should treat 'foo' as an alias for 'foo:foo'.\n\n>From git-fetch(1):\n\n - A parameter without a colon is equivalent to : when\n pulling/fetching, so it merges into the current branch\n without storing the remote branch anywhere locally\n\nSo 'foo' is treated as 'foo:' (which means fetch, and not store), and\nnot as 'foo:foo'. It is perhaps a bit strange, but backward\ncompatibility would I think prohibit us to change it, even if it would\nmake more sense to have it be shortcut for 'foo:foo' instead.\n\nBesides now that we have git-remote it might be a moot point: setting\nup remotes and remote branches info is very easy now.\n\n> * git-rebase claims you should git-rebase --continue after you fix\n> up the merges; it really means you should git-update-index\n> followed by git-rebase --continue.\n\nIt is git-add now, not git-update-index.\n\nI'm not sure what is exact wording of interrupted rebase in current\ngit, as it was some time since I used it, but IIRC it talks about\n\"resolving conflicts\", and doing \"git add\"[*1*] is a part of this\nstep.\n\n[*1*] There is/was a floating idea to add \"git resolved\" command,\nwhich would be limited porcelain calling git-update-index, used _only_\nto mark resolved conflicts, and having checks etc. for that.\n\n> * The command to merge branch B onto branch A is not \n> \"git-merge A B\". Instead it's \"git-checkout A && git-pull . B\".\n\nLong fixed, although not in the matter mentioned. To merge branch B\ninto _current_ branch (you cannot merge to non-current branch because\nof possibility of conflicts) you can use \"git merge B\".\n\n> * There is no way to tell git-fetch (or therefore git-pull) to grab\n> all newly available branches. You have to ask for them by two\n> names (as above), and then there's no way to get those names\n> automatically into your remotes list (also as above).\n\nIt is possible with globbing refspec, like this example:\n\"refs/heads/*:refs/remotes/origin/*\". You can use git-remote to do\nthis for you.\n\n> * git pull's default behaviour on a branch is unhelpful: even when\n> there is an explicit Pull: branch1:branch1 line, a git pull with\n> branch1 checked out will still pull in master.\n\nThere is now branch..merge configuration variable to change the\n\"first pull line\" default; note that globbing refspec requires this,\nIIRC.\n\n> * Fundamentally, the entire approach of making the UI painful to\n> deal with and forcing the user to deal with all the warts (instead\n> of just making the hairy low-level commands available), because\n> people will write nice wrappers around it, is the same reason\n> people laughed at tla, and still do.\n\nThis was I guess written in the \"git is not an SCM' times. Those are\nlong past, gone with Cogito ;-)\n\n> * The index should be second-class, i.e. no -a flags to avoid the\n> index.\n\nTo much opposition for that. Adding '-a' option is not such a burden\n(you most probably ass '-s' option anyway), and you can always use\nalias for this.\n\n> * branch:branch-origin (or something) should be the default pull.\n\nYou can configure from which remote to fetch (to pull) with\nbranch..remote, and which branch to merge with\nbranch..merge. And branch.autosetupmerge if you want git to set\nthis up for you...\n\n> * branch:branch should be the default push for all branches, but\n> only push the current branch unless a flag is added.\n\nYou can now push only current branch with \"git push HEAD\",\nand IIRC also with magic \"git push HEAD\".\n\nThere was talk about whether make current --matching, or proposed\n--current, behaviour the default for git-push. Any changes in behavior\nmust be done with long obsolescence period (half a year for git).\n\n> * An update command should be created that:\n> * fetches the current branch's upstream to its -origin locally\n> (or all branches, perhaps);\n> * merges the current branch origin to the branch locally;\n> * commits if it was a fast-forward, and leaves uncommitted diffs\n> otherwise.\n\nNot done, and probably has no much sense otherwise (merging is done\nusing 3-way merge, not by taking diff and applying it as a patch).\n\n> Infrastructure/git/UIFlaws (last edited 2007-06-03)\n\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"70422","messageId":"200802292216.29788.jnareb@gmail.com","threadId":"12385","inReplyTo":"alpine.LFD.1.00.0802291551310.4911@xanadu.home","subject":"Re: Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-02-29T21:16:29Z","receivedAt":"2008-02-29T21:16:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"On Fri, 29 Feb 2008, Nicolas Pitre wrote:\n> On Fri, 29 Feb 2008, Elijah Newren wrote:\n> \n>> The page http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws\n>> contains a number of claimed UI flaws of git. I suspect that a number\n>> of them are out-of-date; it doesn't seem to jive with my recent\n>> reading of the documentation. Could anyone point out which are still\n>> accurate with recent git, and which aren't?\n> \n> It says:\n> \n> \tInfrastructure/git/UIFlaws (last edited 2007-06-03 18:41:26 by \n> \tJakubNarebski) \n> \n> and despite being updated almost 9 months ago, the content feels even \n> older than that.\n> \n> Jakub?\n\nhttp://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws?action=info\n\nI have just fixed one error there, and didn't take time to correct\nall the things.\n\nP.S. I have replied in another message in this thread, discussion those\nmentioned \"flaws\" one by one.\n-- \nJakub Narebski\nPoland\n"},{"id":"70426","messageId":"7vmypjbfex.fsf@gitster.siamese.dyndns.org","threadId":"12385","inReplyTo":"m3hcfrjwnk.fsf@localhost.localdomain","subject":"Re: Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-02-29T21:50:46Z","receivedAt":"2008-02-29T21:50:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jakub Narebski writes:\n\n>> * git-fetch requires that the branch be named on both sides of\n>> the :. It should treat 'foo' as an alias for 'foo:foo'.\n>\n> So 'foo' is treated as 'foo:' (which means fetch, and not store), and\n> not as 'foo:foo'. It is perhaps a bit strange, but backward\n> compatibility would I think prohibit us to change it, even if it would\n> make more sense to have it be shortcut for 'foo:foo' instead.\n\nIt is not strange nor b/c requirement at all. If anything, it\ncould default to \"foo:remotes/$remote/foo\", not \"foo:foo\", but\neven then, it shouldn't.\n\nYou are missing a bigger picture. I think the list predates the\nintroduction of separate remotes, which has been the default for\nmore than a year.\n\nYou would have \"fetch = refs/heads/*:refs/remotes/origin/*\"\nthese days in the configuration by default. What this means is\nthat you would have much less reason to run \"fetch $there foo\"\nto begin with. The only time you would fetch in that way is\nwhen you want an unconfigured, single-shot fetch, in which case\nyou do _NOT_ want tracking. So there is no valid reason to\ndefault \"foo\" to \"foo:\", unless that is\nempty. Not to foo:foo, not to foo:remotes/$remote/foo.\n\nMany of the remaining parts of the complaint list share the\nmisunderstanding coming from the lack of understanding of\nseparate remotes layout.\n"},{"id":"70431","messageId":"alpine.LNX.1.00.0802291614230.19665@iabervon.org","threadId":"12385","inReplyTo":"m3hcfrjwnk.fsf@localhost.localdomain","subject":"Re: Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-29T21:58:16Z","receivedAt":"2008-02-29T21:58:16Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 29 Feb 2008, Jakub Narebski wrote:\n\n> \"Elijah Newren\" writes:\n> \n> > The page http://www.freedesktop.org/wiki/Infrastructure/git/UIFlaws\n> > contains a number of claimed UI flaws of git. I suspect that a number\n> > of them are out-of-date; it doesn't seem to jive with my recent\n> > reading of the documentation. Could anyone point out which are still\n> > accurate with recent git, and which aren't?\n> \n> I'll examine them point by point, and write replies when I know the\n> answer. Probably should correct wiki page, too...\n> \n> \n> > * git-revert will refuse to back out multi-parent commits, ie,\n> > merges. The obvious behaviour is to do basically what git-show\n> > [commit] | patch -p1 -R would do, ie, roll back the tree state to\n> > the branch you came from.\n> \n> If I remember correctly there was some work done on cherry-picking,\n> reverting (revert is cherry-picking reverse of a commit in the diff -R\n> or patch -R sense) and rebase with multiparent commits, telling which\n> of parent to treat. But I do not remember details.\n> \n> The advice is of no use: git-show for merge (multi-parent) commits\n> either doesn't show diff at all, or show compact combined diff \n> (diff --cc) which cannot be applied. Another issue of note is that\n> \"git revert\" does not roll back the tree state, but applies reversion\n> of given change, i.e. reverts / undoes given _changeset_.\n\nI think the idea there is \"git diff $1 $1^ | git-apply\"; that is, \nreverting the content changes between the merge and its (first) parent.\n\n> > * 'git-rebase foo' is a noop, when foo is the name of local\n> > branch. You would expect it to fetch the branch named foo from\n> > upstream, and rebase your foo branch on top of it.\n> \n> No, I would never expect git-rebase to fetch somthing. And \"git rebase\n> \" is *not* no-op: it rebases (rebuilds) _current_ branch on\n> top of given branch.\n\nFurthermore, you can rebase branches on other local branches. (E.g., if I \nrealize that I need in speculative branch A a fix I made in maintence \nbranch B, I'll rebase A on B so that, when B hits mainline, rebasing A on \nit will do the right thing and get B out of the series.)\n\n> To do fetch+rebase, i.e. update branch in rebase based workflow, use\n> \"git pull --rebase\".\n> \n> > * git-fetch requires that the branch be named on both sides of\n> > the :. It should treat 'foo' as an alias for 'foo:foo'.\n> \n> From git-fetch(1):\n> \n> - A parameter without a colon is equivalent to : when\n> pulling/fetching, so it merges into the current branch\n> without storing the remote branch anywhere locally\n> \n> So 'foo' is treated as 'foo:' (which means fetch, and not store), and\n> not as 'foo:foo'. It is perhaps a bit strange, but backward\n> compatibility would I think prohibit us to change it, even if it would\n> make more sense to have it be shortcut for 'foo:foo' instead.\n\nActually, what would make sense would be, perhaps, to update local \ntracking branches that match a fetch \"foo:\". For that matter, you *really* \ndon't want \"foo\" to mean \"foo:foo\", because \"foo:foo\" is undesireable; you \nwant \"foo:origin/foo\" or something of that sort.\n\n> > * git-rebase claims you should git-rebase --continue after you fix\n> > up the merges; it really means you should git-update-index\n> > followed by git-rebase --continue.\n> \n> It is git-add now, not git-update-index.\n> \n> I'm not sure what is exact wording of interrupted rebase in current\n> git, as it was some time since I used it, but IIRC it talks about\n> \"resolving conflicts\", and doing \"git add\"[*1*] is a part of this\n> step.\n> \n> [*1*] There is/was a floating idea to add \"git resolved\" command,\n> which would be limited porcelain calling git-update-index, used _only_\n> to mark resolved conflicts, and having checks etc. for that.\n\nI think it's still not terribly explicit in the instructions for resolving \nthe conflicts. I think the worse thing is that you have to pick out the \nconflicting files from the ones that were handled, rather than getting a \nsection of \"fix , mark them handled with \"git add\", and \ncontinue\".\n\n> > * The command to merge branch B onto branch A is not \n> > \"git-merge A B\". Instead it's \"git-checkout A && git-pull . B\".\n> \n> Long fixed, although not in the matter mentioned. To merge branch B\n> into _current_ branch (you cannot merge to non-current branch because\n> of possibility of conflicts) you can use \"git merge B\".\n\nI have to wonder if this person actually wants:\n\"git merge A && git push . A\" (which is to say, resolve the conflicts on \nthe topic branch and update the mainline branch with the now-fast-forward \nresult). Of course, there's no major need for a local A branch, but that's \noften not obvious to new users.\n\n> > * There is no way to tell git-fetch (or therefore git-pull) to grab\n> > all newly available branches. You have to ask for them by two\n> > names (as above), and then there's no way to get those names\n> > automatically into your remotes list (also as above).\n> \n> It is possible with globbing refspec, like this example:\n> \"refs/heads/*:refs/remotes/origin/*\". You can use git-remote to do\n> this for you.\n\nHeck, git clone does this for you these days.\n\n> > * The index should be second-class, i.e. no -a flags to avoid the\n> > index.\n> \n> To much opposition for that. Adding '-a' option is not such a burden\n> (you most probably ass '-s' option anyway), and you can always use\n> alias for this.\n\nI wonder if commit shouldn't use -a by default if there are changes but \nnone staged. But people adding new files would trip over that.\n\n> > * branch:branch should be the default push for all branches, but\n> > only push the current branch unless a flag is added.\n> \n> You can now push only current branch with \"git push HEAD\",\n> and IIRC also with magic \"git push HEAD\".\n\nThe *real* magic is \"remote.*.push: HEAD\". (The reason it's real magic is \nthat I implemented it, and I didn't know I'd implemented it until Junio \nmentioned it in release notes. Validation of the design of a weak UI \naround a strong core.)\n\n> > * An update command should be created that:\n> > * fetches the current branch's upstream to its -origin locally\n> > (or all branches, perhaps);\n> > * merges the current branch origin to the branch locally;\n> > * commits if it was a fast-forward, and leaves uncommitted diffs\n> > otherwise.\n> \n> Not done, and probably has no much sense otherwise (merging is done\n> using 3-way merge, not by taking diff and applying it as a patch).\n\nActually, isn't this \"git pull --no-commit\"? It:\n\n * fetches the current branch's remote, updating the tracking refs for it \n (not branch-origin, but remotes/origin/*, a better name)\n * merges the remote branch in \"merge\" for the current branch into the \n current branch\n * if it was not a fast-forward (if it was, there's no new state to leave \n uncommitted), it doesn't commit it, but leaves the changes merged (or \n conflicting, if there were conflicts) in the index.\n\nNobody agrees on what, exactly, \"git update\" should do, but I think all of \nthe sane options are easy aliases. Maybe we should have a recipies section \nof them. (Actually, it would be amusing to have recipies in a man page for \n\"git update\": \"It's up to you to make this do what you want. Here are some \nsuggestions...\").\n\nI wonder if it would be nice to have per-branch aliases, so that you could \nhave \"git update\" do whatever is appropriate to update this particular \nbranch, whether it be \"git pull --no-commit\" or \"git reset --hard \norigin/next && git merge\" or \"git rebase\".\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"70438","messageId":"76718490802291440x60896c93i26d8d0c2cf5678b2@mail.gmail.com","threadId":"12385","inReplyTo":"alpine.LNX.1.00.0802291614230.19665@iabervon.org","subject":"Re: Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-02-29T22:40:36Z","receivedAt":"2008-02-29T22:40:36Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Feb 29, 2008 at 4:58 PM, Daniel Barkalow wrote:\n\n> I wonder if it would be nice to have per-branch aliases, so that you\n> could have \"git update\" do whatever is appropriate to update this\n> particular branch, whether it be \"git pull --no-commit\" or \"git reset\n> --hard origin/next && git merge\" or \"git rebase\".\n\nWell, you effectively have this via\nbranch.*.{merge,mergeoptions,rebase,remote}. e.g.:\n\nTo effect fetch + non-committing merge:\n\n branch..remote = origin\n branch..merge = refs/heads/\n branch..mergeoptions = --no-commit\n\nTo effect fetch + rebasing:\n\n branch..remote = origin\n branch..merge = refs/heads/\n branch..rebase = true\n\n(Not sure if there is a way to get \"rebase -m\" though...)\n\nTo effect reset --hard origin/next, add another fetch line to your\nremote. e.g.:\n\n [remote \"origin\"]\n url = git://git.kernel.org/pub/scm/git/git.git\n fetch = +refs/heads/*:refs/remotes/origin/*\n fetch = refs/heads/pu:/refs/heads/pu-readonly\n\nNow \"git pull\" does the right thing whichever branch I'm on.\n\nj.\n"},{"id":"70439","messageId":"76718490802291452x7b9c91adlb48c55f5737a1a33@mail.gmail.com","threadId":"12385","inReplyTo":"76718490802291440x60896c93i26d8d0c2cf5678b2@mail.gmail.com","subject":"Re: Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Jay Soffian","fromEmail":"jaysoffian@gmail.com","sentAt":"2008-02-29T22:52:20Z","receivedAt":"2008-02-29T22:52:20Z","isPatch":false,"sender":{"key":"jaysoffian@gmail.com","avatar":"https://avatars.githubusercontent.com/u/155970?v=4"},"body":"On Fri, Feb 29, 2008 at 5:40 PM, Jay Soffian wrote:\n> fetch = refs/heads/pu:/refs/heads/pu-readonly\n\nObviously missing a '+', though I'm not sure why anyone would do\nthis anyway.\n\nj.\n"},{"id":"70442","messageId":"alpine.LNX.1.00.0802291743330.19665@iabervon.org","threadId":"12385","inReplyTo":"76718490802291440x60896c93i26d8d0c2cf5678b2@mail.gmail.com","subject":"Re: Which freedesktop.org \"design flaws\" in git are still relevant?","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2008-02-29T22:58:15Z","receivedAt":"2008-02-29T22:58:15Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Fri, 29 Feb 2008, Jay Soffian wrote:\n\n> On Fri, Feb 29, 2008 at 4:58 PM, Daniel Barkalow wrote:\n> \n> > I wonder if it would be nice to have per-branch aliases, so that you\n> > could have \"git update\" do whatever is appropriate to update this\n> > particular branch, whether it be \"git pull --no-commit\" or \"git reset\n> > --hard origin/next && git merge\" or \"git rebase\".\n> \n> Well, you effectively have this via\n> branch.*.{merge,mergeoptions,rebase,remote}. e.g.:\n> \n> To effect fetch + non-committing merge:\n> \n> branch..remote = origin\n> branch..merge = refs/heads/\n> branch..mergeoptions = --no-commit\n> \n> To effect fetch + rebasing:\n> \n> branch..remote = origin\n> branch..merge = refs/heads/\n> branch..rebase = true\n\nAh, good point. I'd forgotten mergeoptions.\n\n> To effect reset --hard origin/next, add another fetch line to your\n> remote. e.g.:\n> \n> [remote \"origin\"]\n> url = git://git.kernel.org/pub/scm/git/git.git\n> fetch = +refs/heads/*:refs/remotes/origin/*\n> fetch = refs/heads/pu:/refs/heads/pu-readonly\n\nThis case is actually tougher. I've got:\n\n[branch \"good-stuff\"]\n\tremote = .\n\tmerge = refs/heads/\n\tmerge = refs/heads/\n\tmerge = refs/heads/\n\nThis branch is my local equivalent of \"pu\" for my own topics, which gets \nnext + each topic I have in a testable state (by way of an octopus merge). \nSo I reset to origin/next and merge a lot of local branches.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"}]}