{"thread":{"id":"6919","subject":"[PATCH for \"next\"] pretty-formats: add 'format:'","startedAt":"2006-11-14T16:42:49Z","lastAt":"2007-02-24T01:25:50Z","messageCount":240,"participants":["Johannes Schindelin","Han-Wen Nienhuys","Junio C Hamano","Robin Rosenberg","Michael K. Edwards","Jakub Narebski","Nicolas Pitre","Carl Worth","Andreas Ericsson","Anand Kumria","Karl Hasselström","Linus Torvalds","Santi Béjar","Petr Baudis","Josef Weidendorfer","Alan Chandler","Shawn Pearce","Andy Parkins","Sean","Steven Grimm","Theodore Tso","Jerome Lovy","Marko Macek","Richard CURNOW","Andy Whitcroft","Alexandre Julliard"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"295786","messageId":"87k61yt1x2.wl%cworth@cworth.org","threadId":"6919","inReplyTo":null,"subject":"[PATCH] commit: Steer new users toward \"git commit -a\" rather than update-index","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-14T16:42:49Z","receivedAt":"2006-11-14T16:42:49Z","isPatch":true,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"As has been discussed recently, update-index isn't intended as a\n\"porcelain\" command so the mention of it in the output of git-commit\ndoes lead to some user confusion.\n---\n wt-status.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 7dd6857..4edabcd 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s\n \tint i;\n \tif (q->nr)\n \t\twt_status_print_header(\"Changed but not updated\",\n-\t\t\t\t\"use git-update-index to mark for commit\");\n+\t\t\t\t\"use \\\"git commit \\\" to commit or \\\"git commit -a\\\" for all\");\n \tfor (i = 0; i < q->nr; i++)\n \t\twt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);\n \tif (q->nr)\n--\n1.4.3.3.gf040\n\n"},{"id":"297088","messageId":"455A1137.8030301@shadowen.org","threadId":"6919","inReplyTo":"87k61yt1x2.wl%cworth@cworth.org","subject":"Re: [PATCH] commit: Steer new users toward \"git commit -a\" rather than update-index","fromName":"Andy Whitcroft","fromEmail":"apw@shadowen.org","sentAt":"2006-11-14T18:55:51Z","receivedAt":"2006-11-14T18:55:51Z","isPatch":true,"sender":{"key":"apw@shadowen.org","avatar":"https://gravatar.com/avatar/d3088262854661a913ef35cc40fedcc270142d4461791142bc1ea0b2a4e2e147?d=mp&s=160"},"body":"Carl Worth wrote:\n> As has been discussed recently, update-index isn't intended as a\n> \"porcelain\" command so the mention of it in the output of git-commit\n> does lead to some user confusion.\n> ---\n> wt-status.c | 2 +-\n> 1 files changed, 1 insertions(+), 1 deletions(-)\n> \n> diff --git a/wt-status.c b/wt-status.c\n> index 7dd6857..4edabcd 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -126,7 +126,7 @@ static void wt_status_print_changed_cb(s\n> \tint i;\n> \tif (q->nr)\n> \t\twt_status_print_header(\"Changed but not updated\",\n> -\t\t\t\t\"use git-update-index to mark for commit\");\n> +\t\t\t\t\"use \\\"git commit \\\" to commit or \\\"git commit -a\\\" for all\");\n> \tfor (i = 0; i < q->nr; i++)\n> \t\twt_status_print_filepair(WT_STATUS_CHANGED, q->queue[i]);\n> \tif (q->nr)\n> --\n> 1.4.3.3.gf040\n\nAre we sure this isn't porcelain-ish? We need to use it in merge\nconflict correction and the like? You can't use git-commit there as a\nreplacement. I'd expect it to be 'git update-index' rather than\n'git-update-index' of course.\n\n"},{"id":"295625","messageId":"87hcx1u934.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"455A1137.8030301@shadowen.org","subject":"Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-14T19:22:39Z","receivedAt":"2006-11-14T19:22:39Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Nov 2006 18:55:51 +0000, Andy Whitcroft wrote:\n> Carl Worth wrote:\n> > As has been discussed recently, update-index isn't intended as a\n> > \"porcelain\" command so the mention of it in the output of git-commit\n> > does lead to some user confusion.\n>\n> Are we sure this isn't porcelain-ish? We need to use it in merge\n> conflict correction and the like? You can't use git-commit there as a\n> replacement. I'd expect it to be 'git update-index' rather than\n> 'git-update-index' of course.\n\nIt was Junio that recently said update-index is plumbing, not\nporcelain.\n\nSo, the fact that conflict resolution still requires the use of\nupdate-index would just be the next thing to fix. A name for a\nreplacement to use there could be \"git resolve \", (since the\nold git-resolve is now officially deprecated). That's a name that\nmatches what hg uses in this situation, (another option is \"resolved\"\nwhich is what stg uses, but I think verbs for commands work better in\ngeneral).\n\nIt would be really nice if none of the \"common\" commands had a hyphen\nin them, for example.\n\nAnd then, the next phase of my evil plan would be to introduce a -i\noption for git-commit making it commit the state in the index. Then\ngit-commit with no options could work like \"git-commit -a\" does now,\n(with the additional protection of not committing any unmerged\nfiles---that is the new \"git resolve\" would be required before \"git\ncommit\" would work after a conflict). Users who really, really like\nthe current behavior of git-commit could use the new alias support to\npass the new -i option in order to maintain compatible behavior.\n\nThen, the last thing I'd really like to fix is to allow a usage of\n\"git merge \" instead of the awkward \"git pull . \".\n\nWith that, most of the user-interface warts that I regularly run into\nwith git would be solved. Oh, except it would also be nice to\neliminate the \"plumbing\" commands in a couple of places:\n\n 1) From the \"man git\" man page\n\n 2) From git-, (maybe the solution for this is to make\n \"git \" work and only do tab-completion for the commands\n blessed enough to appear in \"git --help\"? Also push the tab\n completion stuff out as a standard part of packages.\n\nAnyway, now I've just gone and blown all my secret plans for changing\ngit in ways to make it less intimidating for new users.\n\nFor reference, the latest potential batch of new users that I'm\ndealing with is the set of Fedora package maintainers who are looking\nat replacing CVS for their tree of package-building scripts. They are\ncurrently evaluating systems and liking the interface of hg. Here's\nthe top of the current thread:\n\nhttps://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html\n\nHere's the report about \"git commit -a\" confusion that led to my patch\nabove:\n\nhttps://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html\n\nAnd here's my reply where I suggest that git UI might still be\nimproved in these areas:\n\nhttps://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html\n\n-Carl\n"},{"id":"297453","messageId":"20061114192914.GD4299@spearce.org","threadId":"6919","inReplyTo":"87hcx1u934.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-14T19:29:14Z","receivedAt":"2006-11-14T19:29:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Carl Worth wrote:\n> 2) From git-, (maybe the solution for this is to make\n> \"git \" work and only do tab-completion for the commands\n> blessed enough to appear in \"git --help\"? Also push the tab\n> completion stuff out as a standard part of packages.\n\nUh, see contrib/completion/git-completion.bash.\n\n\"git \" completes commands. It offers too many completions\nfor your taste it sounds like, as it also offers plumbing... but\nthat's fixable. :-)\n\n-- \n"},{"id":"298319","messageId":"20061114194707.GH7201@pasky.or.cz","threadId":"6919","inReplyTo":"87hcx1u934.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-14T19:47:07Z","receivedAt":"2006-11-14T19:47:07Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Tue, Nov 14, 2006 at 08:22:39PM CET, Carl Worth wrote:\n> For reference, the latest potential batch of new users that I'm\n> dealing with is the set of Fedora package maintainers who are looking\n> at replacing CVS for their tree of package-building scripts. They are\n> currently evaluating systems and liking the interface of hg. Here's\n> the top of the current thread:\n> \n> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00030.html\n> \n> Here's the report about \"git commit -a\" confusion that led to my patch\n> above:\n> \n> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00141.html\n> \n> And here's my reply where I suggest that git UI might still be\n> improved in these areas:\n> \n> https://www.redhat.com/archives/fedora-maintainers/2006-November/msg00149.html\n\nHmm, did they (not) consider Cogito? They wouldn't have those issues.\n;-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Uh, see contrib/completion/git-completion.bash.\n\nOops. I had seen this and thought I had installed it properly a while\nago, (copied it to /etc/bash_completion.d/git), but I hadn't realized\nit wasn't active in the shell I used to test while composing that\nemail.\n\n> \"git \" completes commands. It offers too many completions\n> for your taste it sounds like, as it also offers plumbing... but\n> that's fixable. :-)\n\nYes, I think we'd all be better off if we could designate some subset\nof the current git commands as not being intended for users to type on\nthe command line and pulled them out of the completion scripts.\n\nIt is tough though. Looking through what's available in the short list\nfrom \"git --help\" I notice that update-index isn't there, and that's\ncurrently still required, (as we've been discussing here). But even\nthings as \"core plumbing\" as git rev-list I find extremely useful on\nthe command like with simple pipelines.\n\nOn the other hand, there are definitely some commands I've never\ntyped, and are not intended to be typed by the user. Here are a few I\nsee as fairly obvious just from skimming the list:\n\n\tmerge-*\n\thttp-*\n\tssh-*\n\tupload-*\n\tmktag\n\tmktree\n\tcheck-ref-format\n\t...\n\nThere are a bunch of others as well. Maybe it would be easier to start\nwith the list in git --help and see what should be added to that.\n\nThe documentation for some of the above commands have phrases such as\n\"Invoked by \" and \"usually not invoked by the end user\"\nwhich does make the distinction quite clear. So it would be nice if\ngit could keep these away from the user more.\n\n-Carl\n"},{"id":"294211","messageId":"20061114204628.GA14741@diana.vm.bytemark.co.uk","threadId":"6919","inReplyTo":"87hcx1u934.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-14T20:46:28Z","receivedAt":"2006-11-14T20:46:28Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-14 11:22:39 -0800, Carl Worth wrote:\n\n> So, the fact that conflict resolution still requires the use of\n> update-index would just be the next thing to fix. A name for a\n> replacement to use there could be \"git resolve \", (since the\n> old git-resolve is now officially deprecated). That's a name that\n> matches what hg uses in this situation, (another option is\n> \"resolved\" which is what stg uses, but I think verbs for commands\n> work better in general).\n\nYes, \"resolve\" sounds better than \"resolved\". The latter is arguably\nmore correct, since you're telling git that you have already resolved\nthe file and not asking it to resolve it for you, but I still prefer\n\"resolve\".\n\n> And then, the next phase of my evil plan would be to introduce a -i\n> option for git-commit making it commit the state in the index. Then\n> git-commit with no options could work like \"git-commit -a\" does now,\n> (with the additional protection of not committing any unmerged\n> files---that is the new \"git resolve\" would be required before \"git\n> commit\" would work after a conflict). Users who really, really like\n> the current behavior of git-commit could use the new alias support\n> to pass the new -i option in order to maintain compatible behavior.\n\nSeems very sane. Default to simple behavior, and provide a switch to\nget more complicated behavior.\n\n> Then, the last thing I'd really like to fix is to allow a usage of\n> \"git merge \" instead of the awkward \"git pull . \".\n\nThis should reduce newbie confusion a lot.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"294155","messageId":"Pine.LNX.4.64.0611141518590.2591@xanadu.home","threadId":"6919","inReplyTo":"87hcx1u934.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-14T20:52:47Z","receivedAt":"2006-11-14T20:52:47Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 14 Nov 2006, Carl Worth wrote:\n\n> Anyway, now I've just gone and blown all my secret plans for changing\n> git in ways to make it less intimidating for new users.\n\nI just cannot do otherwise than cheer this with applause.\n\nEven if I have a clear preference for GIT's _technology_, I still think \nthat the HG user interface is more convivial. I even been thinking \nabout writing something like an hg-like frontend to GIT from time to \ntime just so that GIT could then be better compared to (and actually \njust used like) HG.\n\nI still think that the GIT user interface sucks in many ways. The \nconfusion between pull, fetch and push is still my favorite, along with \nthe locale vs remote branch issue. Maybe we'll better handle the branch \nissue eventually, but it would be so much intuitive to split branch \nmerging out of git-pull, and make git-pull be the same as git-fetch \n(maybe deprecating git-fetch in the process) so push and pull are really \n_only_ opposite of each other.\n\nIf the fetch+merge behavior (which I think should really be refered as \npull+merge) is still desirable, then it should be called git-update and \nbe no more than a single shell script line such as\n\n\tgit_pull && git_merge\"\n\nThis is really what most people expect from such a command name based \non obvious historical reasons. The lack of any branch argument to \ngit-pull and git-merge could be defined as using the first defined \nremote branch by default. But having git-pull performing merges is IMHO \noverloading the word and goes against most people's expectations.\n\n\n"},{"id":"295917","messageId":"87d57pu4qa.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"20061114194707.GH7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-14T20:56:45Z","receivedAt":"2006-11-14T20:56:45Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:\n> Hmm, did they (not) consider Cogito? They wouldn't have those issues.\n\nI didn't ask.\n\nFrankly, I don't see a lot of value in the git/cogito split right now.\n\nWhen I first learned git and cogito (January 2006) and switched cairo\nfrom cvs to git (the repository storage), I recommended cogito to\ncairo programmers as a \"more cvs-like\" way to work with the new\nrepository.\n\nSince then, having worked with git (the command-line program)\nexclusively for my own work, and having introduced it to dozens of new\nusers, I don't bother recommending cogito anymore. It's just not that\nhard to learn git itself, so there's not that much value in learning\ncogito instead.\n\nAnd this is particularly true since there's quite a large cost to\nhaving to learn cogito _in addition to_ git. And I think that's what\nmost people would have to do anyway. For example, cogito doesn't wrap\nall git commands. So users have to dip down into git for things like\ngit-bisect or else miss out an important functionality.\n\nAnd for something like the Fedora transition, where I'm working with\nthe people who will be training the community in the new tools, the\ntrainers would have to learn both if they want to support a community\nusing both git and cogito. These trainers are already complaining\nabout the ~140 git commands, so adding 40 more cogito commands as well\ndoesn't make the story better.\n\nIt's great that git is written in a script-friendly way so that new\ninterfaces can be built on top of it. And I think the benefits of new\nuser interfaces are clear when they work in fundamentally different\nways, (say, being operated through a GUI). But where git and cogito\nare both command-line utilities and have the same basic functionality,\nI don't see how its helpful to maintain both tools. (Certainly some of\nmy attitude here is due to the timing of my introduction to git\ncontrasted with the timing of the inception of cogito. I'm sure git\nimproved a lot between those two events.)\n\nThere are some things that cogito does that git does not that I would\nlike to have in git. One is having a \"commit\" command that commits\neverything by default without an extra command-line option. Another\n(that I _think_ cogito has) is a way to switch away from a branch with\ndirty changes to a clean branch, do work there, and come back to the\noriginal branch with the dirty stuff still there.\n\nI don't see any defining difference that justifies cogito's\nexistence (\"hide the index\" maybe? let's just hide it a tiny bit more\nin git). And I would like to help work to get the remaining good\nstuff that has been proven in cogito---to get it pushed down into git\nitself.\n\n-Carl\n"},{"id":"293997","messageId":"ejdapj$vc0$1@sea.gmane.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611141518590.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-14T21:01:50Z","receivedAt":"2006-11-14T21:01:50Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> If the fetch+merge behavior (which I think should really be refered as \n> pull+merge) is still desirable, then it should be called git-update and \n> be no more than a single shell script line such as\n> \n>         git_pull && git_merge\"\n> \n> This is really what most people expect from such a command name based \n> on obvious historical reasons.  The lack of any branch argument to \n> git-pull and git-merge could be defined as using the first defined \n> remote branch by default.  But having git-pull performing merges is IMHO \n> overloading the word and goes against most people's expectations.\n\nBy the way, is anyone doing _remote_ octopus pull (true pull, not with . as\nrepository)?\n\nWe can always have --merge arguments to git-pull, and --fetch argument to\ngit-merge.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297292","messageId":"87bqn9u43s.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611141518590.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-14T21:10:15Z","receivedAt":"2006-11-14T21:10:15Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:\n> Even if I have a clear preference for GIT's _technology_, I still think\n> that the HG user interface is more convivial. I even been thinking\n> about writing something like an hg-like frontend to GIT from time to\n> time just so that GIT could then be better compared to (and actually\n> just used like) HG.\n\nI've actually been tempted to do the same myself. I really think that\nthe technology is a more important criterion than the UI so the\nimagined hg-on-git interface would be an attempt to get people to look\npast the interface differences and look at the technology when\ndeciding.\n\nBut, then, I'd be guilty of creating another cogito, and I just argued\nagainst its existence in a separate thread. So I think we're better\noff just fixing the git interface.\n\n> I still think that the GIT user interface sucks in many ways. The\n> confusion between pull, fetch and push is still my favorite, along with\n> the locale vs remote branch issue. Maybe we'll better handle the branch\n> issue eventually,\n\nThe --use-separate-remotes thing is technology in the right direction\nhere. But I think it's another example of very useful stuff being\nimproperly hidden behind another command-line option. Getting rid of\nthe \"remote-tracking branches\" as user-visible branches possible for\ncommitting should be a priority. And that should be the default for\neveryone, not just people who happen to clone with this obscure\noption.\n\nSimilarly, the reflog stuff was often trumpeted in the recent git\nvs. bzr debate. Why is that very useful functionality buried in a\nconfig file option and not just stored by default?\n\n> This is really what most people expect from such a command name based\n> on obvious historical reasons. The lack of any branch argument to\n> git-pull and git-merge could be defined as using the first defined\n> remote branch by default.\n\nOnce again, there's lots of useful work on \"branch configuration\" that\nallows for commands to be able to get the \"right\" default repository\nfor push and pull. I hope that that stuff can be enabled by default\nand not require --use-separate-remotes or manual configuration for\npeople to benefit from it.\n\nI apologize if I sound like I'm ranting here. I love to see the many\ngood improvements being made to git. It's just that there seems to be\na sort of shyness about new features, (perhaps a fear of changing\nexisting behavior?). When it improves the user experience, let's make\nthe improvement the default and not add any more\n\n\t--make-this-command-do-what-it-really-should-have-always-done\n\noptions.\n\n-Carl\n"},{"id":"296235","messageId":"ejdcg5$4fl$1@sea.gmane.org","threadId":"6919","inReplyTo":"87bqn9u43s.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-14T21:30:56Z","receivedAt":"2006-11-14T21:30:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"The git interface refactoring should be I think the cause for git 2.0.0\nrelease...\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298317","messageId":"Pine.LNX.4.64.0611141627200.2591@xanadu.home","threadId":"6919","inReplyTo":"ejdapj$vc0$1@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-14T21:32:58Z","receivedAt":"2006-11-14T21:32:58Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 14 Nov 2006, Jakub Narebski wrote:\n\n> Nicolas Pitre wrote:\n> \n> > If the fetch+merge behavior (which I think should really be refered as \n> > pull+merge) is still desirable, then it should be called git-update and \n> > be no more than a single shell script line such as\n> > \n> >         git_pull && git_merge\"\n> > \n> > This is really what most people expect from such a command name based \n> > on obvious historical reasons.  The lack of any branch argument to \n> > git-pull and git-merge could be defined as using the first defined \n> > remote branch by default.  But having git-pull performing merges is IMHO \n> > overloading the word and goes against most people's expectations.\n> \n> By the way, is anyone doing _remote_ octopus pull (true pull, not with . as\n> repository)?\n> \n> We can always have --merge arguments to git-pull, and --fetch argument to\n> git-merge.\n\nThat would be a complete abomination if you want my opinion.\n\nPlease let git-pull actually pull stuff from a remote place, and \ngit-merge actually merge stuff only. Let's keep simple concepts mapped \nto simple commands please. Nothing prevents _you_ from scripting more \ninvolved operations with a single command of your liking afterwards.\n\n\nNicolas\n"},{"id":"294427","messageId":"Pine.LNX.4.64.0611141633430.2591@xanadu.home","threadId":"6919","inReplyTo":"ejdcg5$4fl$1@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-14T21:34:18Z","receivedAt":"2006-11-14T21:34:18Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 14 Nov 2006, Jakub Narebski wrote:\n\n> The git interface refactoring should be I think the cause for git 2.0.0\n> release...\n\nGood idea indeed.\n\n\n"},{"id":"295487","messageId":"200611142304.33673.jnareb@gmail.com","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611141627200.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-14T22:04:33Z","receivedAt":"2006-11-14T22:04:33Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n> On Tue, 14 Nov 2006, Jakub Narebski wrote:\n\n>> We can always have --merge arguments to git-pull, and --fetch argument to\n>> git-merge.\n> \n> That would be a complete abomination if you want my opinion.\n> \n> Please let git-pull actually pull stuff from a remote place, and \n> git-merge actually merge stuff only. Let's keep simple concepts mapped \n> to simple commands please. Nothing prevents _you_ from scripting more \n> involved operations with a single command of your liking afterwards.\n\nDo we want to abandon completely \"single-branch\" workflow, where you\ndon't use tracking branch, only merge directly into your working branch?\nThat is the cause to (unused by most) future git-merge (replacement for\ngit-pull .) --fetch=[#] option.\n\nI'm not that sure about --merge option, but it could be useful, at least\nto have current automatic \"Merge branch '' of \" commit message.\n-- \nJakub Narebski\n"},{"id":"297651","messageId":"Pine.LNX.4.64.0611141718480.2591@xanadu.home","threadId":"6919","inReplyTo":"200611142304.33673.jnareb@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-14T22:29:16Z","receivedAt":"2006-11-14T22:29:16Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 14 Nov 2006, Jakub Narebski wrote:\n\n> Nicolas Pitre wrote:\n> > On Tue, 14 Nov 2006, Jakub Narebski wrote:\n> \n> >> We can always have --merge arguments to git-pull, and --fetch argument to\n> >> git-merge.\n> > \n> > That would be a complete abomination if you want my opinion.\n> > \n> > Please let git-pull actually pull stuff from a remote place, and \n> > git-merge actually merge stuff only. Let's keep simple concepts mapped \n> > to simple commands please. Nothing prevents _you_ from scripting more \n> > involved operations with a single command of your liking afterwards.\n> \n> Do we want to abandon completely \"single-branch\" workflow, where you\n> don't use tracking branch, only merge directly into your working branch?\n\nI really think we should. Let's admit it: such a work flow has nothing \nto do with the tool. It would certainly be much easier to teach new \nusers about \"this is a read-only view of the remote content that you can \nmerge into your working branch\" than trying to explain why the tool is \nso weird for the sake of supporting different work flows directly.\n\nAgain I think it is easier to grasp two simple commands than a single \nbut complex one with multiple ramifications.\n\n> That is the cause to (unused by most) future git-merge (replacement for\n> git-pull .) --fetch=[#] option.\n> \n> I'm not that sure about --merge option, but it could be useful, at least\n> to have current automatic \"Merge branch '' of \" commit message.\n\nA \"remote\" branch should obviously have a corresponding URL. So if you \ndo \"git-merge remote\" then you may as well prepare a commit message with \nthat URL given the local name for that branch if you want.\n\n\n"},{"id":"295960","messageId":"7vr6w5y7to.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"87bqn9u43s.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-14T22:36:19Z","receivedAt":"2006-11-14T22:36:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> On Tue, 14 Nov 2006 15:52:47 -0500 (EST), Nicolas Pitre wrote:\n>> Even if I have a clear preference for GIT's _technology_, I still think\n>> that the HG user interface is more convivial. I even been thinking\n>> about writing something like an hg-like frontend to GIT from time to\n>> time just so that GIT could then be better compared to (and actually\n>> just used like) HG.\n>\n> I've actually been tempted to do the same myself. I really think that\n> the technology is a more important criterion than the UI so the\n> imagined hg-on-git interface would be an attempt to get people to look\n> past the interface differences and look at the technology when\n> deciding.\n>...\n>> I still think that the GIT user interface sucks in many ways. The\n>...\n\nI've actually been tempted to do that too, and my earlier \"if I\nwere to redo git from scratch\" message was the beginning of it\nto summarize my preference about some of the issues raised in\nthis thread.\n\nCommenting on the messages in this thread:\n\n - \"resolve / resolved\" are both confusing, when you are talking\n about \"mark-resolved\" operation.\n\n - \"pull/push/fetch\" have undesired confusion depending on where\n people learned the term. I'd perhaps vote for replacing\n fetch with download and push with upload.\n\n - I think it would be sensible to make remote tracking branches\n less visible. For example:\n\n\tgit diff origin\n\n where origin is the shorthand for your upstream (e.g. you\n have .git/remotes/origin that records the URL and the branch\n you are tracking) should be easier to understand than\n\n \tgit diff remotes/origin/HEAD\n\n The latter is an implementation detail. I could imagine we\n might even want to allow\n\n\tgit diff origin#next\n\n to name the branch of the remote repository. The notion of\n \"where the tips of remote repository's branches are\" is\n probably be updated by \"git download\" (in other words, the\n above \"git diff\" does not automatically initiate network\n transfer).\n\n - \"git merge\" to merge another branch into the current would\n make sense. \"git pull . remotes/origin/next\" is showing too\n much implementation detail. It should just be:\n\n\tgit merge origin#next\n\nAnd I agree with Pasky that fixing UI is hard unless you are\nwilling to get rid of historical warts. Syntax of the command\nline arguments the current set of Porcelain-ish takes are\nsometimes just horrible. It may not be a bad idea to start\nbuilding the fixed UI from scratch, using different prefix than\n\"git\" (say \"gu\" that stands for \"git UI\" or \"gh\" that stands for\n\"git for humans\").\n\nOf course, it could even be \"cg\" ;-).\n\n"},{"id":"297479","messageId":"7virhhy76h.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"7vr6w5y7to.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-14T22:50:14Z","receivedAt":"2006-11-14T22:50:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> - I think it would be sensible to make remote tracking branches\n> less visible. For example:\n>...\n> - \"git merge\" to merge another branch into the current would\n> make sense. \"git pull . remotes/origin/next\" is showing too\n> much implementation detail. It should just be:\n>\n> \tgit merge origin#next\n\nThis and other examples in \"making remote tracking branches less\nvisible\" are hard to read because I used the word \"origin\" in\ntwo different sense. So here is a needed clarification.\n\nIf you have remotes/upstream that says:\n\n\tURL: git://git.xz/repo.git\n Pull: refs/heads/master:remotes/origin/master\n Pull: refs/heads/next:remotes/origin/next\n\nThen, currently the users need to say:\n\n\tgit diff remotes/origin/master\n git merge remotes/origin/next\n\nBy \"making tracking branches less visible\", what I mean is to\nlet the users say this instead:\n\n\tgit diff upstream\n git merge upstream#next\n\n\n\n"},{"id":"296435","messageId":"7vbqn9y6w6.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611141633430.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-14T22:56:25Z","receivedAt":"2006-11-14T22:56:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Tue, 14 Nov 2006, Jakub Narebski wrote:\n>\n>> The git interface refactoring should be I think the cause for git 2.0.0\n>> release...\n>\n> Good idea indeed.\n\nWe need to avoid user confusion, so making a command that used\nto do one thing to suddenly do something completely different is\na no-no. However, I do not think it needs to wait for 2.0.0.\nWe can start with a separate namespace (or even a separate\n\"Improved git UI project\") and introduce the \"improved UI set\"\nin 1.5.0 timeframe.\n\nIf managed properly, the \"improved git UI\" can coexist with the\ncurrent set of tools and over time we can give an option not to\neven install the older Porcelain-ish commands.\n"},{"id":"296196","messageId":"7vfyclwqr2.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"455A1137.8030301@shadowen.org","subject":"Re: [PATCH] commit: Steer new users toward \"git commit -a\" rather than update-index","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-14T23:30:25Z","receivedAt":"2006-11-14T23:30:25Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Whitcroft writes:\n\n> Are we sure this isn't porcelain-ish? We need to use it in merge\n> conflict correction and the like? You can't use git-commit there as a\n> replacement. I'd expect it to be 'git update-index' rather than\n> 'git-update-index' of course.\n\nI think status should be taken as Porcelain-ish so it should\nnotice more about the environment to see why the user has\nchanged but not updated files and recommend the possible action\ndepending on the context.\n\nFor that, you would need to enumerate what kind of 'context'\nthere could be with the current set of tools. Here is a\nstrawman.\n\n 1. None of the below.\n 2. A merge was attempted and resulted in a conflict.\n 3. An am or rebase without --merge was attempted and\n resulted in a conflict or patch rejection.\n 4. A \"rebase --merge was attempted and resulted in a conflict.\n\nIn the normal case, the next user action would be:\n\n 1-1. The user wants that change in the next commit, and should\n run \"git update-index $that_path\" to prepare the index for\n partial commit, or \"git commit -a\" to commit all the\n changes made to the working tree so far. Carl's patch\n helps the user in this case.\n\n 1-2. The user realizes that the some of the changes in the\n working tree were not desirable, and \"git checkout --\n $that_path\" to revert them before continuing. Before\n deciding to revert, the user may want to check what the\n difference is by running \"git diff -- $that_path\" so\n suggesting these two might also be helpful.\n\n 1-3. The user wants to keep that change a strictly local change\n in the working tree (this is often very useful and making\n \"commit -a\" the default will not be acceptable unless\n there is a very compelling reason to do so). This means\n the suggestion we would make should clearly be\n _suggestion_.\n\nThe earlier wording was bad in that it suggested to use a\nPlumbing command update-index, but was attempting to convey that\nit was merely a conditional suggestion by saying \"use it TO MARK\nFOR COMMIT\", implying that if the user does not want to mark\nthem for commit, it is Ok not to use update-index.\n\nWhen a merge is in progress, we would have .git/MERGE_HEAD and\nthat would be the way to tell case 2. In that case, the next\nuser action would be:\n\n 2-1. The user resolves conflicts and marks them as resolved,\n with update-index (or \"git mark-resolved\"), to prepare the\n index for the merge commit. But this is not done for\n \"Changed but not updated\" files but \"unmerged\" files. We\n should strongly suggest not to do _anything_ to \"Changed\n but not updated\" files here.\n\n 2-2. The user decides this conflict is too much to handle right\n now, and abandones the change by \"git reset --hard\". This\n would lose the local changes (\"Changed but not updated\"),\n so we should suggest to save the change before doing so.\n\n\tIf you are going to abandone this merge with \"reset\n\t--hard\", your changes to these files will be lost. You\n\tcan save them with \"git diff HEAD -- $this_path\n\t$that_path...\"\n\n which is probably too long for that part of the output but\n that is what we would want to say if we want to be\n helpful.\n\nWhen either rebase without --merge or am is in progress, there\nwould be .dotest/ directory (whose name could be changed but I\nthink this was a mistake and we would be better off using fixed\nnames for this kind of application) for git-status to notice.\nThe next user action would be:\n\n 3-1. The user resolves the conflict or manually apply the\n patch, update-index the paths involved and proceeds with\n \"rebase --continue\" or \"am --resolved\". \"Changed but not\n updated\" paths should not be touched in this case,\n similarly to 2-1.\n\n 3-2. The user gives up. Same as 2-2.\n\nDesigning for the \"rebase --merge\" case and coming up with other\ncases are left as exercise to the list for further discussion.\n\n"},{"id":"295052","messageId":"7v3b8lv9c9.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"87d57pu4qa.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T00:31:50Z","receivedAt":"2006-11-15T00:31:50Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:\n>> Hmm, did they (not) consider Cogito? They wouldn't have those issues.\n>\n> I didn't ask.\n>\n> Frankly, I don't see a lot of value in the git/cogito split right now.\n> ...\n> It's great that git is written in a script-friendly way so that new\n> interfaces can be built on top of it. And I think the benefits of new\n> user interfaces are clear when they work in fundamentally different\n> ways, (say, being operated through a GUI). But where git and cogito\n> are both command-line utilities and have the same basic functionality,\n> ...\n> There are some things that cogito does that git does not that I would\n> like to have in git.\n> ...\n> I don't see any defining difference that justifies cogito's\n> existence (\"hide the index\" maybe? let's just hide it a tiny bit more\n> in git). And I would like to help work to get the remaining good\n> stuff that has been proven in cogito---to get it pushed down into git\n> itself.\n\nI am of two minds here.\n\nI do not think the Porcelain-ish UI that is shipped with git\nshould be taken with the same degree of \"authority\" as git\nPlumbing. The plumbing needed to have something that worked for\none particular workflow (namely, workflow of the people in the\nintegrator role of kernel-style project) and that is where the\ncurrent set of Porcelain-ish originates. Linus works primarily\nas an integrator so the toolsets he did tend to be more pleasant\nto use for integrators and less so for contributors. I started\nas a contributor and added some commands like format-patch and\nrebase that Linus never would have felt the need for. I think\nsingle isolated developers, contributors and CVS style shared\nrepository usage could be a lot improved because neither of us\nwere concentrating in their workflows. This needs somebody\nmotivated enough to improve things in that area. For example,\nStGIT with its 'float' command is a great improvement over what\nrebase does for people in the contributor role.\n\nBy now, perhaps git may be good enough for the kernel folks,\neven for those not in the integrator role, but I have no doubt\nthat they have many dislikes to the way some commands work.\nThey and X.org folks are using git primarily because Linus and\nKeith forced them to ;-), and being interoperable is more\nimportant than having to tolerate sucky UI here and there.\nEverybody knows that git Porcelain-ish sucks, and making it more\nusable is a worthy goal.\n\nBut making it more usable for whom is a big question. \n\nQuite frankly, I do not think there can be _the_ single UI that\nwould satisfy different types of workflows for some of the\ncommands. The commands related to software archaeology, in\nwhich my main interest and strength lie, would easily be usable\nacross workflows, but commands to build commits locally and\npropagate them to and from other repositories would be affected\nby the workflow.\n\nFor example, fetching and merging from many places without\nnecessarily having corresponding tracking branches is a great\nthing for people in the integrator role. On the other hand, for\npeople doing CVS-style centralized repository interaction, it is\noften more useful to have tracking branches. You could support\nboth but it has been painful.\n\nFor another example, having a commit command to commit\neverything by default is disastrous for people who allow their\nworkflows to often be interrupted. When I respond to a message\nfrom the list with an example patch, my repository is often in\nthe middle of doing something completely unrelated, and I edit\nand make diff to send the message out and I do not necessarily\nrevert that change afterwards immediately. For more organized\npeople it may not be a problem so you either support both types\nof workflows or do a specialized toolset.\n\nIt is not just command line syntax and the defaults, but\nconcepts as well. People in the integrator role often need to\ndeal with merges and you would need to be aware of the role of\nthe index and need to be able to manipulate the index, a lot\nmore often than people in the contributor role. To satisify\nboth kinds of workflows, you would either have switches, or do a\nspecialized toolset, like Cogito, that tries to hide the index.\n\nA Porcelain that does a very similar thing in slightly different\nway is obviously a waste, but otherwise I do not think it is a\nproblem to have different Porcelains. StGIT does not compete\nwith the \"sucky\" Porcelain-ish shipped with git but makes the\nuser's life a lot more pleasant by complementing what the sucky\none does not do well. It is not very useful while I am playing\nthe integrator role, but when I am doing my own thing it is a\ngreat addition to my toolchest.\n\nI am from the camp that does _not_ want to hide the index, so\nobviously I do not see any value in its effort to hide the\nindex. But other aspects of it, most notably being friendly to\nsimpler workflows, is a very good thing.\n\n"},{"id":"294589","messageId":"Pine.LNX.4.64.0611142007010.2591@xanadu.home","threadId":"6919","inReplyTo":"7vbqn9y6w6.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T01:48:09Z","receivedAt":"2006-11-15T01:48:09Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 14 Nov 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Tue, 14 Nov 2006, Jakub Narebski wrote:\n> >\n> >> The git interface refactoring should be I think the cause for git 2.0.0\n> >> release...\n> >\n> > Good idea indeed.\n> \n> We need to avoid user confusion, so making a command that used\n> to do one thing to suddenly do something completely different is\n> a no-no. However, I do not think it needs to wait for 2.0.0.\n> We can start with a separate namespace (or even a separate\n> \"Improved git UI project\") and introduce the \"improved UI set\"\n> in 1.5.0 timeframe.\n\nDunno. I feel this is a bit overboard. Actually the naming problem is \nrather localized to one command, namely git-pull. In my opinion going \nwith yet another namespace which would rather add to the confusion not \nclear it.\n\nThe best way to avoid user confusion is to remove the source of the \nconfusion not let it live. In other words I think we should _fix_ \ngit-pull instead of replacing it. People are already confused about it \nso simply fixing this command will have a net confusion reduction. Yet \nwe're not talking about \"suddenly doing something completely different\" \neither. If git-pull doesn't merge automatically anymore it is easy to \ntell people to use git-merge after a pull.\n\n\"You pull the remote changes with 'git-pull upstream,, then you can \nmerge them in your current branch with 'git-merge upstream'.\"\n\nIsn't it much simpler to understand (and to teach) that way?\n\nAlso I don't think using git-upload and git-download is much better. \nThis adds yet more commands that do almost the same as existing ones but \nwith a different name which is yet not necessarily fully adequate. I \nfor example would think that \"download\" is more like git-clone than \ngit-fetch or git-pull.\n\nLet's face it: HG got it right with pull and push and newbies have much \nless difficulty grokking it. We screwed it by not using the most \nintuitive semantic of a pull and locking the word \"pull\" away is not the \nbetter solution given all considerations. Why just not admit it and \navoid being different than HG just for the sake of it?\n\n\n"},{"id":"298493","messageId":"7v3b8ltq7r.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611142007010.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T02:10:16Z","receivedAt":"2006-11-15T02:10:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> \"You pull the remote changes with 'git-pull upstream,, then you can \n> merge them in your current branch with 'git-merge upstream'.\"\n>\n> Isn't it much simpler to understand (and to teach) that way?\n\nIf it were \"you download the remote changes with 'git download\nupstream' and then merge with 'git merge'\", then perhaps, but if\nyou used the word \"pull\" or \"fetch\", I do not think so.\n\nI would be all for changing the semantics of \"pull\" from one\nthing to another, if the new semantics were (1) what everybody\nwelcomed, (2) what \"pull\" traditionally meant everywhere else.\nIn that case, we have been misusing it to be confusing to\noutsiders and I agree it makes a lot of sense to remove the\nsource of confusion. But I do not think CVS nor SVN ever used\nthe term, and I was told that BK was what introduced the term,\nand the word meant something different from what you are\nproposing.\n\nYou have to admit both pull and fetch have been contaminated\nwith loaded meanings from different backgrounds. I was talking\nabout killing the source of confusion in the longer term by\nremoving fetch/pull/push, so we are still on the same page.\n\nThat's where my \"you download from the upstream and merge\" comes\nfrom.\n\n"},{"id":"295323","messageId":"f2b55d220611141827m5ebe27bfvf59eb04fd5b20cfc@mail.gmail.com","threadId":"6919","inReplyTo":"7v3b8ltq7r.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-15T02:27:52Z","receivedAt":"2006-11-15T02:27:52Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"I would kind of like to see \"git poll\" -- visit all remote branches,\nfetching objects and tags into the local repository, so that I can\ninspect changes off-line and merge, cherry-pick, etc. to my heart's\ncontent. That would fit the platform integrator's workflow nicely --\n\"git poll\" into a tracking tree, do some merges there (such as\nbackporting a subsystem to a \"stable\" base kernel), then merge this\nbackport branch to each platform working copy and cherry-pick other\nchanges as necessary.\n\nCheers,\n"},{"id":"296024","messageId":"20061115040852.GL7201@pasky.or.cz","threadId":"6919","inReplyTo":"7v3b8lv9c9.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-15T04:08:52Z","receivedAt":"2006-11-15T04:08:52Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:\n> Carl Worth writes:\n> \n> > On Tue, 14 Nov 2006 20:47:07 +0100, Petr Baudis wrote:\n> >> Hmm, did they (not) consider Cogito? They wouldn't have those issues.\n> >\n> > I didn't ask.\n> >\n> > Frankly, I don't see a lot of value in the git/cogito split right now.\n> > ...\n> > It's great that git is written in a script-friendly way so that new\n> > interfaces can be built on top of it. And I think the benefits of new\n> > user interfaces are clear when they work in fundamentally different\n> > ways, (say, being operated through a GUI). But where git and cogito\n> > are both command-line utilities and have the same basic functionality,\n> > ...\n> > There are some things that cogito does that git does not that I would\n> > like to have in git.\n> > ...\n> > I don't see any defining difference that justifies cogito's\n> > existence (\"hide the index\" maybe? let's just hide it a tiny bit more\n> > in git). And I would like to help work to get the remaining good\n> > stuff that has been proven in cogito---to get it pushed down into git\n> > itself.\n> \n> I am of two minds here.\n> \n> I do not think the Porcelain-ish UI that is shipped with git\n> should be taken with the same degree of \"authority\" as git\n> Plumbing.\n..snip passage about workflows..\n\nControversy's fun, so...\n\n (But yeah, it still looks silly that I'm\nsaying this.)\n\n From the current perspective, I think it has been a mistake that the\nporcelain and plumbing was not kept separate in independent packages,\nand perhaps even maintained separately (and perhaps not; at least having\na single tree with plumbing/ and porcelain/ directories and separate\npackages in distributions might already help something), so that \"git\"\nwould be kept as a kind of library and then there would be a separate\npackage providing an interface to it. Or you could select one of several\npackages. Not only would that make Cogito prevail in the world and bring\nme a flood of marriage proposals, but look at how would it help the\ngeneral public:\n\n (i) Clearly divided porcelain/plumbing interface, so that you can\nreally isolate the two UI-wise; endless confusion reigns there now. Is\ngit-update-index porcelain or plumbing? _You_ call git-merge a proper\nporcelain? From my perspective, git-update-ref is as plumbing as it\ngets, but it's classified as porcelain. Etc, etc. This would be by far\nthe most important advantage.\n\n (ii) The plumbing and porcelain would not share the same namespace,\nleading to clearer UI. (I'm just inflating (i).)\n\n (iii) The documentation would not be a strange mix of porcelain and\nplumbing. (More (i) inflation.)\n\n (iv) (i) is troublesome because I have a feeling that Junio declared\nseveral times that he doesn't care that much about stable API for\nporcelain compared to the plumbing. But with the current mix it's\ndesirable to use some porcelain even in other porcelains and in scripts.\n\n (v) Git would be properly libified by now. If you wanted to convert\nbits of porcelain to C, it would be at least much higher priority.\n\n (vi) You wouldn't need to make the gruesome choice on what is the\ncanonical workflow the _the_ Git porcelain supports (see the snipped\npassage). Or you would, but it would have less impact.\n\n (vii) The world would be a happier place.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Nicolas Pitre writes:\n> \n> > \"You pull the remote changes with 'git-pull upstream,, then you can \n> > merge them in your current branch with 'git-merge upstream'.\"\n> >\n> > Isn't it much simpler to understand (and to teach) that way?\n> \n> If it were \"you download the remote changes with 'git download\n> upstream' and then merge with 'git merge'\", then perhaps, but if\n> you used the word \"pull\" or \"fetch\", I do not think so.\n> \n> I would be all for changing the semantics of \"pull\" from one\n> thing to another, if the new semantics were (1) what everybody\n> welcomed, (2) what \"pull\" traditionally meant everywhere else.\n> In that case, we have been misusing it to be confusing to\n> outsiders and I agree it makes a lot of sense to remove the\n> source of confusion. But I do not think CVS nor SVN ever used\n> the term, and I was told that BK was what introduced the term,\n> and the word meant something different from what you are\n> proposing.\n> \n> You have to admit both pull and fetch have been contaminated\n> with loaded meanings from different backgrounds. I was talking\n> about killing the source of confusion in the longer term by\n> removing fetch/pull/push, so we are still on the same page.\n> \n> That's where my \"you download from the upstream and merge\" comes\n> from.\n\nBut the fact is that HG (which has a growing crowd of happy campers, \nmaybe even larger than the BK crowd now) did work with and got used to a \nsensible definition of what a \"pull\" is. This means that their \ndefinition is becoming rather more relevant with time than what it used \nto, and because it is a saner definition than what GIT has for the same \nword which HG users really have no issue with, I think we really should \nleverage the \"common wisdom\" and consider aligning ourselves with them \nin this case rather than trying to go into a totally different \ndirection. We simply won't gain anything trying to teach people \"a pull \nin HG is a download in GIT\". If a pull becomes the same thing for both \nthen it's one less oddball in the GIT interface.\n\n\n"},{"id":"297544","messageId":"Pine.LNX.4.64.0611142048350.2591@xanadu.home","threadId":"6919","inReplyTo":"7virhhy76h.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T04:32:06Z","receivedAt":"2006-11-15T04:32:06Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 14 Nov 2006, Junio C Hamano wrote:\n\n> Junio C Hamano writes:\n> \n> > - I think it would be sensible to make remote tracking branches\n> > less visible. For example:\n> >...\n> > - \"git merge\" to merge another branch into the current would\n> > make sense. \"git pull . remotes/origin/next\" is showing too\n> > much implementation detail. It should just be:\n> >\n> > \tgit merge origin#next\n> \n> This and other examples in \"making remote tracking branches less\n> visible\" are hard to read because I used the word \"origin\" in\n> two different sense. So here is a needed clarification.\n> \n> If you have remotes/upstream that says:\n> \n> \tURL: git://git.xz/repo.git\n> Pull: refs/heads/master:remotes/origin/master\n> Pull: refs/heads/next:remotes/origin/next\n> \n> Then, currently the users need to say:\n> \n> \tgit diff remotes/origin/master\n> git merge remotes/origin/next\n> \n> By \"making tracking branches less visible\", what I mean is to\n> let the users say this instead:\n> \n> \tgit diff upstream\n> git merge upstream#next\n\nWhat is the point of hiding tracking branches? Why just not making them \neasier to use instead? There are currently so many ways to specify \nremote branches that even I get confused.\n\nOK..... let's pretend this is my follow-up to your \"If I were redoing \ngit from scratch\" query. Actually I would not redo it from scratch \nsince the vast majority of it is rather sane already. But here's some \nchanges that I would do:\n\n1) make \"git init\" an alias for \"git init-db\".\n\nWhat's the point of \"-db\"? Sure we're initializing the GIT database. \nBut who cares? The user doesn't care if GIT uses a \"database\" or \nwhatever. And according to some people's definition of a \"database\" it \ncould be argued that GIT doesn't use a database at all in the purist \nsense of it. What the user wants is to get started and \"init\" (without \nthe \"-db\" is so much more to the point. Doesn't matter if incidentally \nit happens to be the same keyword HG uses for the same operation because \nwe are not afflicted by the NIH disease, right? And it has 3 chars less \nto type which is for sure a premium improvement to the very first GIT \nuser experience!\n\n2) \"pull\" and \"push\" should be symmetrical operations\n\nThey are symmetrical in the dictionary and in people's mind. OK but what \nif I merge content from another _local_ branch into the current one? \nIsn't that kind of a pull as well? Answer: NO IT IS NOT! Reason: \nbecause we already have \"merge\" for that very operation for damn sake! \nAnd because \"merging\" isn't a synonym for \"pulling\" at all, we cannot \npretend it should sort of become more true if taken the other way \naround.\n\nActually, if we _merge_ stuff together, we certainly have to /pull/ some \nof it, meaning that \"merge\" might imply a \"pull\", even in real life \nsituations outside of the GIT context (think merging Vodka and Kahlua in \na glass where you might have to pull the Vodka bottle out of the freezer \nbefore you can merge it). And thankfully we got it right with git-merge \nwhich can take either a branch or an URL as argument which in the later \ncase will perform a pull implicitly (OK currently a fetch but you know \nwhat I mean).\n\nBut trying to put in people's head that \"pulling\" implies a \"merge\"? No \nthat doesn't work really well. OK if you pull too hard on the Vodka \nbottle that might imply a merge at some point but it would certainly be \naccidental. And it is not without coincidence that some people had \naccidental GIT merges by using git-pull.\n\nConclusion: git-pull must not perform any merge. It is the symmetrical \noperation of a push meaning that it pulls content from a remote branch \nand does no more. People understands that pretty well, . This makes \ngit-fetch redundant (or an alias to git-pull) in that case, and again we \ndon't mind it becoming similar to in HG because we admit HG was right \nabout it.\n\n3) remote branch handling should become more straight forward.\n\nOK! Now that we've solved the pull issue and that everybody agrees with \nme (how can't you all agree with me anyway) let's have a look at remote \nbranches. It should be simple:\n\na)\tgit-pull git://repo.com/time_machine.git\n\nThis pulls every branches from the time_machine.git repository and \ncreate identically named branches locally, except for the remote \nmaster becoming origin locally. All those branches are marked read-only \n(i.e. cannot commit to them) and _each_ of those branches get an URL \nassociated to them somehow (the association is an implementation \ndetail).\n\nIf then you do:\n\nb)\tgit-pull origin\n\nThen it will pull the git://repo.com/time_machine.git:master branch into \nthe local \"origin\" branch. IOW, local tracking branches becomes \nsynonyms for their remote URLs after they've been pulled once. If the \nremote branch \"next\" became a local \"next\" with the first pull (because \nit didn't specify any branch meaning that they were all pulled), doing \na:\n\nc)\tgit-pull next\n\nwould actually be the same as:\n\nd)\tgit-pull git://repo.com/time_machine.git:next\n\nNow to have different remote and local names for those tracking \nbranches:\n\ne)\tgit-pull git://repo.com/time_machine.git:master upstream\n\nwould be a variation where a remote branch gets a different local name. \nThis pulls the remote master branch but calls it \"upstream\" locally. \nIf that \"upstream\" branch does exist locally already then fail with \nappropriate error message, unless the local branch happens to have the \nsame URL attribute already. You then have two local branches tracking \nthe same remote branch which is weird but still fine if someone wants\nto have different views (today's pull and yesterday's pull). This is \nnot necessarily something to encourage but only a fallout of the branch \nsemantic. And again a simple:\n\nf)\tgit-pull upstream\n\nwould update the \"upstream\" branch from the remote master branch.\n\nI think the concept of \"branch group\" should be preserved too. So if \nyou create a group called \"warp\", then add \"origin\", \"next\", and \n\"upstream\" to it, then:\n\ng)\tgit-pull warp\n\nwould pull all the included branches. One way to create a branch group \nwith the initial pull is not to specify the remote branch but only the \nrepository URL, like:\n\nh)\tgit-pull git://repo.com/time_machine.git warp\n\nBecause no specific branch in the remote repository was specified just \nlike in (a) then all branches are pulled, but because a local name was \nprovided then this becomes a branch group.\n\nBranch groups could be used to extend the branch namespace as well to \navoid clashes with different remote repositories. In this case the \nbranch groups could be a way to arrange branches in a hierarchy so \n\"warp\" refer to all branches included in the warp group while \n\"warp/upstream\" refer to only one branch. In this case \"upstream\" and \n\"warp/upstream\" would be the same branch if \"upstream\" was effectively \nadded to the \"warp\" group, but it doesn't need to be so. And branches \nin a group don't have to come from the same remote repository either \nsince the source of each branch (the URL) is a per branch attribute.\n\nTo make it \"easy\" on the user, I think that any branch (or tag) down the \nhierarchy should be used without the \"path\" leading to it if there is no \nconflict. We already do that with heads and tags, So if for example the \n\"warp\" group contained a branch named \"lightspeed\" but no such branch \n(or tag) existed anywhere else then it could be referenced with simply \n\"lightspeed\" or \"warp/lightspeed\".\n\nThen you don't need any strange scheme for diff and merge. Just using \n\"git-diff upstream\" or \"git-merge origin next\" suffice. Oh and I don't \nthink it would be a good idea to have a completely separate namespace \nfor local vs remote aka tracking branches. Maybe in .git/refs/ they \nshould be separate to distinguish which ones are read-only remote \ntracking ones and which ones are local, but that must not be forced on \nthe UI.\n\nThinking about it some more, maybe (a) should create a default branch \ngroup if the remote repository has more than one branches, say \"origin\". \nThis way, git-pull without any argument would be the same as \n\"git-pull origin\" by default. If \"origin\" is a single branch then \n(git-pull\" would pull only one branch, but if \"origin\" is a branch group \nthen all included branches would be pulled.\n\nThis becomes formalized as:\n\n\tgit_pull [] []\n\nIf includes a branch name then is a single branch \nname. If doesn't include any branch name then \nbecomes a local branch group name containing all branches in the remote \nrepository. If is specified but not then \nis set to \"origin\" by default, unless it already exists in which case it \nis an error and the pull fails. If is not specified then the URL \nattribute to the specified branch(es) is used. If nothing is specified \nthen \"origin\" is used for by default and URL attribute of \nthe origin branch or the origin branch group is/are used.\n\n*****\n\nOK I think this is enough for now. I know that parts of what I've said \ncan already be found in GIT, but I wanted the explanation to be \ncomplete and therefore tentatively coherent.\n\n\n"},{"id":"298682","messageId":"7vd57ps51c.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"20061115040852.GL7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T04:33:03Z","receivedAt":"2006-11-15T04:33:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> On Wed, Nov 15, 2006 at 01:31:50AM CET, Junio C Hamano wrote:\n>> \n>> I am of two minds here.\n>> \n>> I do not think the Porcelain-ish UI that is shipped with git\n>> should be taken with the same degree of \"authority\" as git\n>> Plumbing.\n> ..snip passage about workflows..\n>\n> Controversy's fun, so...\n>\n> (But yeah, it still looks silly that I'm\n> saying this.)\n\nIt appears that you are not grumpy as you were anymore ;-). I\nmostly agree with what you said in your message.\n\n> (i) Clearly divided porcelain/plumbing interface, so that you can\n> really isolate the two UI-wise; endless confusion reigns there now. Is\n> git-update-index porcelain or plumbing? _You_ call git-merge a proper\n> porcelain? From my perspective, git-update-ref is as plumbing as it\n> gets, but it's classified as porcelain. Etc, etc. This would be by far\n> the most important advantage.\n\nYes. The current \"merge\" started its life as Linus's porcelain\n(we did not have fetch and pull infrastructure back then) but\nquickly has become just a helper for pull to produce a merge\ncommit. If anybody thinks its UI is good as a general end-user\nlevel command, there is a need for \"head examination\".\n\nAs you say, update-ref is as plumbing as it gets and it should\nnot be listed as Porcelain; I am a bit surprised that it is\nlabelled as such myself.\n\nNo disagreement here, nor (ii) nor (iii).\n\n> (ii) The plumbing and porcelain would not share the same namespace,\n> leading to clearer UI. (I'm just inflating (i).)\n>\n> (iii) The documentation would not be a strange mix of porcelain and\n> plumbing. (More (i) inflation.)\n>\n> (iv) (i) is troublesome because I have a feeling that Junio declared\n> several times that he doesn't care that much about stable API for\n> porcelain compared to the plumbing. But with the current mix it's\n> desirable to use some porcelain even in other porcelains and in scripts.\n\nThis is true and it is a problem.\n\nWhile we encourage Porcelain writers to use plumbing in order to\ngive git Porcelain-ish more freedom to evolve to give better UI\nfor humans, not having a clear distinction between the two makes\nit harder.\n\n> (v) Git would be properly libified by now. If you wanted to convert\n> bits of porcelain to C, it would be at least much higher priority.\n\nI am not sure about \"libified\" part and I do not know what bits\nof porcelain wants to become C right now. But I do not think\nthis point is important part of your list.\n\n> (vi) You wouldn't need to make the gruesome choice on what is the\n> canonical workflow the _the_ Git porcelain supports (see the snipped\n> passage). Or you would, but it would have less impact.\n\nYes. This is really important.\n\nLinus and me having done Porcelain-ish that supports integrator\nrole workflow better than other workflows such as contributor\nrole should not discourage people from working on alternative or\ncomplementary Porcelains to help other workflows better (see the\nsnipped passage).\n\nStGIT sets a great example, and efforts like it is encoraged\nmore.\n\nI think both Linus and myself tried to make it clear that the\npurpose of Porcelain-ish that comes with core git is 50% to make\nplumbing (perhaps minimally) usable and the other 50% to serve\nas an example for Porcelain writers to learn how to use the\nplumbing, but we should probably have stressed the latter\nbetter.\n"},{"id":"294067","messageId":"Pine.LNX.4.64.0611142342160.2591@xanadu.home","threadId":"6919","inReplyTo":"7vd57ps51c.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T04:46:48Z","receivedAt":"2006-11-15T04:46:48Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 14 Nov 2006, Junio C Hamano wrote:\n\n> Yes. The current \"merge\" started its life as Linus's porcelain\n> (we did not have fetch and pull infrastructure back then) but\n> quickly has become just a helper for pull to produce a merge\n> commit. If anybody thinks its UI is good as a general end-user\n> level command, there is a need for \"head examination\".\n\nIf you mean \"git merge\" it sure needs to be brought forward. It can't \nbe clearer than:\n\n\tgit-merge the_other_branch\n\nor\n\n\tgit-merge git://repo.com/time_machine.git\n\nto instantaneously understand what is going on.\n\n\n"},{"id":"298140","messageId":"7vzmatqpb8.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611142306090.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T04:58:03Z","receivedAt":"2006-11-15T04:58:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> ... We simply won't gain anything trying to teach people \"a pull \n> in HG is a download in GIT\". If a pull becomes the same thing for both \n> then it's one less oddball in the GIT interface.\n\nI personally do not have any issue with that, as long as you\nwould help us convert existing users that what was known as pull\nis not available and new pull means fetching only.\n\nIf I recall correctly in this thread, you also advocated to\nalways have tracking branches. I am a bit worried about losing\nthe promiscuous pull usage, which can easily become a regression\nfor people like Linus in the integrator role unless done with an\nescape hatch.\n"},{"id":"294923","messageId":"7vu011qnl6.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611142048350.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T05:35:17Z","receivedAt":"2006-11-15T05:35:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> What is the point of hiding tracking branches? Why just not making them \n> easier to use instead? There are currently so many ways to specify \n> remote branches that even I get confused.\n\nOk, I think in essence we are saying the same thing except I\nwent overboard by suggsting to extend sha1_name to also look at\n.git/remotes/$name which is not necessary, because we already\nhave the .git/refs/remotes/%s/HEAD magic there. Consider the\nsuggestion of \"upstream#next\" syntax retracted, please.\n\n> 1) make \"git init\" an alias for \"git init-db\".\n\nOr even better, have \"gh init\".\n\n> 2) \"pull\" and \"push\" should be symmetrical operations\n\nI think that makes a lot of sense to have \"gh pull\" and \"gh\npush\" as symmetric operations, and make \"gh merge\" do the\nfast-forward and 3-way merge magic done in the current \"git\npull\". These three words would have a lot saner meaning.\n\n> 3) remote branch handling should become more straight forward.\n>\n> OK! Now that we've solved the pull issue and that everybody agrees with \n> me (how can't you all agree with me anyway) let's have a look at remote \n> branches.\n\nI would probably prefer making the default namespace under\n.git/refs/remotes/remote-name for the tracking branches this\nproposal creates, but other than that I agree with the general\ndirection this proposal is taking us, including branch groups.\nWe have .git/refs/remotes/%s/HEAD magic so I do not think we\neven need to treat one branch repository any specially as you\nsuggsted.\n\nThe reason I am suggsting \"gh\" instead of \"git\" is primarily to\ndeal with stale documentation people would find googling. I can\neasily see people get confused by reading \"pull = fetch + merge\"\nfrom either mailing list archive or Git cheat sheet various\nprojects seem to have developed.\n\nIt does not mean we need to redo _all_ UI. I think most of the\narchaeology commands have sane UI so during the transition\nperiod (git 1.99) we can have \"git log\" and \"gh log\" which are\none and the same program, and perhaps git 2.0 can be shipped\nwith clear distinction between plumbing (i.e. git-update-index\nand friends) and porcelain (e.g. \"gh pull\" that only fetches but\nwith the user friendliness you outlined here), with backward\ncompatibility wart to help old timers (e.g. \"git pull\" that\nstill does \"git fetch\" followed by \"git merge\").\n\n"},{"id":"296252","messageId":"20061115061833.GA6294@spearce.org","threadId":"6919","inReplyTo":"7vu011qnl6.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-15T06:18:33Z","receivedAt":"2006-11-15T06:18:33Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Or even better, have \"gh init\".\n\nWhy gh? Is Git just Mercurial backwards? :)\n\nI'm all in favor of this discussion, and in particular of just\nbreaking the entire UI in 2.0 by using a new frontend command.\nI'm just not sure that \"Mercurial backwards\" describes Git well.\n\n-- \n"},{"id":"296108","messageId":"7vpsbpp6fz.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"20061115061833.GA6294@spearce.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T06:30:56Z","receivedAt":"2006-11-15T06:30:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Junio C Hamano wrote:\n>> Or even better, have \"gh init\".\n>\n> Why gh? Is Git just Mercurial backwards? :)\n>\n> I'm all in favor of this discussion, and in particular of just\n> breaking the entire UI in 2.0 by using a new frontend command.\n> I'm just not sure that \"Mercurial backwards\" describes Git well.\n\nI do not have any obsession to any name as long as it is\ndifferent from \"git\" to avoid confusion coming from older\ndocuments that would be found by googling. gh was just\nshorthand for \"git for humans\" (and easy to type with index\nfingers). I think I listed a few other possibilities in my\nprevious message.\n"},{"id":"298360","messageId":"200611150917.23756.andyparkins@gmail.com","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611142048350.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-15T09:17:22Z","receivedAt":"2006-11-15T09:17:22Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:\n\n> OK..... let's pretend this is my follow-up to your \"If I were redoing\n\nPersonally, I agree with almost everything in this email. Except the \nimplementation of point 3.\n\n> 3) remote branch handling should become more straight forward.\n\nI was completely confused by this origin/master/clone stuff when I started \nwith git. In hindsight, now I understand git a bit more, this is what I \nwould have liked:\n\n * Don't use the name \"origin\" twice. In fact, don't use it at all. In a \ndistributed system there is no such thing as a true origin.\n\n * .git/remotes/origin should be \".git/remotes/default\". \"origin\" is only \nspecial because it is the default to push and pull - it's very nice to have a \ndefault, but it should therefore be /called/ \"default\".\n\n * Whatever git-clone calls the remote, it should be matched by a directory \nin .git/refs/remotes. So .git/remotes/$name contains \"Pull\"s to get all the \nremote branches to .git/refs/remotes/$name/*. This implies that \ngit /always/ does --use-separate-remote in clone. If a branch is practically \nread-only it should be technically read-only too.\n\n * If clone really wants to have a non-read-only master, then that should \nbe .git/refs/heads/master and will initialise \nto .git/refs/remotes/$name/master after cloning. Personally I think this is \ndangerous because it assumes there is a \"master\" upstream - which git doesn't \nmandate at all. Maybe it would be better to take the upstream HEAD and \ncreate a local branch for /that/ branch rather than require that it is \ncalled \"master\".\n\n * Ensuring we have /all/ upstream branches at a later date is hard, and not \nautomatic. Here is the .git/remotes/default file that should be possible:\n URL: git://host/project.git\n Pull: refs/heads/*:refs/remotes/default/*\n Now, every git-pull would check for new upstream branch refs and sync them \ninto the local remotes list. These are read-only so it'd be perfectly safe \nto delete any locally that no longer exist upstream.\n\n * git-clone should really just be a small wrapper around\n - git-init-db\n - create .git/remotes/default\n - maybe create specific .git/config\n - git-fetch default\n If git-clone does anything that can't be done with settings in the config \nand the remotes/default file then it's wrong. The reason I say this is that \nas soon as git-clone has special capabilities (like --shared, --local \nand --reference) then you are prevented from doing magic with existing \nrepositories. For example; how do you create a repository that contains \nbranches from two other local repositories that have the objects hard linked?\n\nWhile I'm writing wishes, I'd like to jump on Junio's integration with other \nfetch-backends wish. I use git-svn, and it would be fantastic if I could \nreplace:\n\ngit-svn init --id upstream/trunk svn://host/path/trunk\ngit-svn fetch --id upstream/trunk\ngit-svn init --id upstream/stable svn://host/path/branches/stable\ngit-svn fetch --id upstream/stable\n\nWith a .git/remotes/svn\n SVN-URL: svn://host/path\n Pull: trunk:refs/remotes/upstream/trunk\n Pull: branches/stable:refs/remotes/upstream/stable\nand\n git fetch svn\n\nObviously, the syntax is just made up; but you get the idea. Even better, \nwould be if it could cope with my \"*\" syntax suggested above:\n SVN-URL: svn://host/path\n Pull: trunk:refs/remotes/upstream/trunk\n Pull: branches/*:refs/remotes/upstream/*\n\n\nThere have been lots of \"wishlist\" posts lately; would it be useful if I tried \nto collect all these suggestions from various people into one place to try \nand get a picture of any consensus?\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"298247","messageId":"ejeocl$vrj$1@sea.gmane.org","threadId":"6919","inReplyTo":"200611150917.23756.andyparkins@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-15T09:59:54Z","receivedAt":"2006-11-15T09:59:54Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andy Parkins wrote:\n\n> * Don't use the name \"origin\" twice. In fact, don't use it at all. In a \n> distributed system there is no such thing as a true origin.\n\nThe remote 'origin' is true origin of the repository: it is repository\nwe cloned this repository from.\n\nI agree that having branch 'origin', at least in most common multi-branch\n(multi-head) repository, is just confusing.\n\n> * Ensuring we have /all/ upstream branches at a later date is hard, and not \n> automatic. Here is the .git/remotes/default file that should be possible:\n> URL: git://host/project.git\n> Pull: refs/heads/*:refs/remotes/default/*\n> Now, every git-pull would check for new upstream branch refs and sync them \n> into the local remotes list. These are read-only so it'd be perfectly safe \n> to delete any locally that no longer exist upstream.\n\nVery nice idea.\n \n> * git-clone should really just be a small wrapper around\n> - git-init-db\n> - create .git/remotes/default\n> - maybe create specific .git/config\n\nI'm not sure about \"create .git/remotes/default\" part. Isn't git moving from\nremotes file to having information about remotes (and branches) in config?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294817","messageId":"ejeomr$vrj$2@sea.gmane.org","threadId":"6919","inReplyTo":"20061115040852.GL7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-15T10:05:26Z","receivedAt":"2006-11-15T10:05:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Petr Baudis wrote:\n\n>   (i) Clearly divided porcelain/plumbing interface, so that you can\n> really isolate the two UI-wise; endless confusion reigns there now. Is\n> git-update-index porcelain or plumbing? _You_ call git-merge a proper\n> porcelain? From my perspective, git-update-ref is as plumbing as it\n> gets, but it's classified as porcelain. Etc, etc. This would be by far\n> the most important advantage.\n\nThe problem is that one man's plumbing is another man porcelain.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"297137","messageId":"ejeotu$vrj$3@sea.gmane.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611142342160.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-15T10:09:13Z","receivedAt":"2006-11-15T10:09:13Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Nicolas Pitre wrote:\n\n> On Tue, 14 Nov 2006, Junio C Hamano wrote:\n> \n>> Yes. The current \"merge\" started its life as Linus's porcelain\n>> (we did not have fetch and pull infrastructure back then) but\n>> quickly has become just a helper for pull to produce a merge\n>> commit. If anybody thinks its UI is good as a general end-user\n>> level command, there is a need for \"head examination\".\n> \n> If you mean \"git merge\" it sure needs to be brought forward. It can't \n> be clearer than:\n> \n> git-merge the_other_branch\n> \n> or\n> \n> git-merge git://repo.com/time_machine.git\n> \n> to instantaneously understand what is going on.\n\nYou mean\n\n git merge git://repo.com/time_machine.git#branch\n\ndon't you (perhaps with 'master' as default branch)?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294204","messageId":"8aa486160611150215n64bb01e6o49aeaf243ad8f817@mail.gmail.com","threadId":"6919","inReplyTo":"ejeotu$vrj$3@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2006-11-15T10:15:23Z","receivedAt":"2006-11-15T10:15:23Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 11/15/06, Jakub Narebski wrote:\n> Nicolas Pitre wrote:\n>\n> > On Tue, 14 Nov 2006, Junio C Hamano wrote:\n> >\n> >> Yes. The current \"merge\" started its life as Linus's porcelain\n> >> (we did not have fetch and pull infrastructure back then) but\n> >> quickly has become just a helper for pull to produce a merge\n> >> commit. If anybody thinks its UI is good as a general end-user\n> >> level command, there is a need for \"head examination\".\n> >\n> > If you mean \"git merge\" it sure needs to be brought forward. It can't\n> > be clearer than:\n> >\n> > git-merge the_other_branch\n> >\n> > or\n> >\n> > git-merge git://repo.com/time_machine.git\n> >\n> > to instantaneously understand what is going on.\n>\n> You mean\n>\n> git merge git://repo.com/time_machine.git#branch\n>\n> don't you (perhaps with 'master' as default branch)?\n\nperhaps with remote 'HEAD' as default branch?\n\n"},{"id":"294809","messageId":"20061115102523.GF5453@diana.vm.bytemark.co.uk","threadId":"6919","inReplyTo":"ejeomr$vrj$2@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-15T10:25:23Z","receivedAt":"2006-11-15T10:25:23Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-15 11:05:26 +0100, Jakub Narebski wrote:\n\n> The problem is that one man's plumbing is another man porcelain.\n\nNo; that way lies insanitation.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"296517","messageId":"ejeq20$5hn$1@sea.gmane.org","threadId":"6919","inReplyTo":"8aa486160611150215n64bb01e6o49aeaf243ad8f817@mail.gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-15T10:28:27Z","receivedAt":"2006-11-15T10:28:27Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Santi Béjar wrote:\n\n> On 11/15/06, Jakub Narebski wrote:\n\n>> You mean\n>>\n>> git merge git://repo.com/time_machine.git#branch\n>>\n>> don't you (perhaps with 'master' as default branch)?\n> \n> perhaps with remote 'HEAD' as default branch?\n\nNo! HEAD might change without your notice, and you want to know\nwhich branch you merge. With remotes the default could be first\nbranch in the pull/fetch list, but with bare URL...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295338","messageId":"200611151033.57415.andyparkins@gmail.com","threadId":"6919","inReplyTo":"ejeocl$vrj$1@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-15T10:33:55Z","receivedAt":"2006-11-15T10:33:55Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 November 15 09:59, Jakub Narebski wrote:\n\n> > * Don't use the name \"origin\" twice. In fact, don't use it at all. In\n> > a distributed system there is no such thing as a true origin.\n>\n> The remote 'origin' is true origin of the repository: it is repository\n> we cloned this repository from.\n\nBut that is not necessarily /the/ original, and \"origin\" is the absolute \nreference in maths. It doesn't bother me that much I suppose, it's just that \nas far as unambiguous names go, I'm not wild about it - it's got too \nmany \"central repository\" connotations, which is of course anathema to git.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"295507","messageId":"20061115104858.GG5453@diana.vm.bytemark.co.uk","threadId":"6919","inReplyTo":"200611151033.57415.andyparkins@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-15T10:48:58Z","receivedAt":"2006-11-15T10:48:58Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-15 11:33:55 +0100, Andy Parkins wrote:\n\n> But that is not necessarily /the/ original, and \"origin\" is the\n> absolute reference in maths. It doesn't bother me that much I\n> suppose, it's just that as far as unambiguous names go, I'm not wild\n> about it - it's got too many \"central repository\" connotations,\n> which is of course anathema to git.\n\nTo me, \"origin\" just means \"where \noriginated\". If you think of it that way, it's perfectly obvious that\neach repository can have its own origin.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"297962","messageId":"200611151128.57917.andyparkins@gmail.com","threadId":"6919","inReplyTo":"20061115104858.GG5453@diana.vm.bytemark.co.uk","subject":"Re: Cleaning up git user-interface warts","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-15T11:28:56Z","receivedAt":"2006-11-15T11:28:56Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006 November 15 10:48, Karl Hasselström wrote:\n\n> To me, \"origin\" just means \"where \n> originated\". If you think of it that way, it's perfectly obvious that\n> each repository can have its own origin.\n\nOf course. I wasn't saying that I didn't understand why origin was chosen. \nIt's not a completely crazy name - it does have /a/ meaning. However, it's \nnot an unambiguous meaning. What if the repository I clone was itself a \nclone? What if the repository it cloned was pulling from three other \nrepositories? What if those three repositories pull/push from/to each other?\n\n * -- * -- *\n \\ | / \\\n \\ | / /\n \\ | / / \n * /\n | / \n | /\n * <--- \"origin\"\n |\n * <--- cloned repository\n\nThe name \"origin\" is too close to having an \"ultimate source\" feel to it IMO. \nIn a distributed system, it's not the right idea to be pushing. After the \nclone is complete, the \"origin\" is no more special than any other repository, \nand if you felt like it you could change the URL for \"origin\" and it would \nmake very little difference to you.\n\nIn short: I don't think \"origin\" is wrong, I just think it's not right.\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIEE\n"},{"id":"294063","messageId":"455B04DE.1040107@op5.se","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611142048350.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-11-15T12:15:26Z","receivedAt":"2006-11-15T12:15:26Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Nicolas Pitre wrote:\n\n[ axed a lot of stuff that I didn't fully grok ]\n\n> \n> This becomes formalized as:\n> \n> \tgit_pull [] []\n> \n> If includes a branch name then is a single branch \n> name. If doesn't include any branch name then \n> becomes a local branch group name containing all branches in the remote \n> repository.\n\nI would change that so \"local_name\" is always a branch group name, but \nbranch group names can be used as refs. That is,\n\ngit pull startrek.com/kirk.git:master kirk\n\nwould always create the branch-head .git/refs/remote/kirk/master which \nfor short can be referenced as just \"kirk\" (barring clashes ofc), so \nlong as it only has one branch tracked.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294834","messageId":"ejf18p$tbt$1@sea.gmane.org","threadId":"6919","inReplyTo":"455B04DE.1040107@op5.se","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-15T12:31:32Z","receivedAt":"2006-11-15T12:31:32Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Andreas Ericsson wrote:\n\n> Nicolas Pitre wrote:\n> \n> [ axed a lot of stuff that I didn't fully grok ]\n> \n>> \n>> This becomes formalized as:\n>> \n>> git_pull [] []\n>> \n>> If includes a branch name then is a single branch \n>> name. If doesn't include any branch name then \n>> becomes a local branch group name containing all branches in the remote \n>> repository.\n> \n> I would change that so \"local_name\" is always a branch group name, but \n> branch group names can be used as refs. That is,\n> \n> git pull startrek.com/kirk.git:master kirk\n\nI'd rather use Cogito (not gitweb) notation startrek.com/kirk.git#master\nThis way we can change the name of local branch\n startrek.com/kirk.git#master:kirk\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296244","messageId":"Pine.LNX.4.63.0611151454250.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"7vu011qnl6.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-15T14:01:47Z","receivedAt":"2006-11-15T14:01:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 14 Nov 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > 1) make \"git init\" an alias for \"git init-db\".\n> \n> Or even better, have \"gh init\".\n\nPlease no. It only makes things even more confusing. \"git init\" is perfect \nas it is. We can always have internal aliases from \"init-db\" to \"init\" to \naccount for older usages.\n\n> > 2) \"pull\" and \"push\" should be symmetrical operations\n> \n> I think that makes a lot of sense to have \"gh pull\" and \"gh\n> push\" as symmetric operations, and make \"gh merge\" do the\n> fast-forward and 3-way merge magic done in the current \"git\n> pull\". These three words would have a lot saner meaning.\n\nI am really opposed to do \"gh pull\". Not only because of \"gh\" being \ncompletely confusing (we already _have_ \"git\", and for porcelains \ndifferent TLAs), but \"pull\" _really_ is confusing by now. And Mercurial \ndid not help one wit by insisting on their own interpretation.\n\nWhy not do something like \"get/put\" instead? It is\n\n- easier to remember\n- not bogus (AFAICT the meaning is not used in diametrical senses)\n- shorter to type than download/upload\n\nAs for \"git merge\": Just by the number of arguments you can discern \nbetween the original usage and the new usage, so I am all in favour of \nreplacing \"git pull \" by \"git merge \". Where \"\" \ncan be a branch or a remote or a URL (with cogito style #branchname).\n\nCiao,\nDscho\n"},{"id":"294646","messageId":"Pine.LNX.4.64.0611150954090.2591@xanadu.home","threadId":"6919","inReplyTo":"ejeotu$vrj$3@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T14:56:29Z","receivedAt":"2006-11-15T14:56:29Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Jakub Narebski wrote:\n\n> Nicolas Pitre wrote:\n> \n> > On Tue, 14 Nov 2006, Junio C Hamano wrote:\n> > \n> >> Yes. The current \"merge\" started its life as Linus's porcelain\n> >> (we did not have fetch and pull infrastructure back then) but\n> >> quickly has become just a helper for pull to produce a merge\n> >> commit. If anybody thinks its UI is good as a general end-user\n> >> level command, there is a need for \"head examination\".\n> > \n> > If you mean \"git merge\" it sure needs to be brought forward. It can't \n> > be clearer than:\n> > \n> > git-merge the_other_branch\n> > \n> > or\n> > \n> > git-merge git://repo.com/time_machine.git\n> > \n> > to instantaneously understand what is going on.\n> \n> You mean\n> \n> git merge git://repo.com/time_machine.git#branch\n> \n> don't you (perhaps with 'master' as default branch)?\n\nSomething like that. I wantee to enphasize on the \"merge\" command that \nshould deal with, hey, merges.\n\nI don't know if # is a good choice for branch indicator though.\n\n\n"},{"id":"298620","messageId":"BAYC1-PASMTP1131061C6974A86FF033D3AEEA0@CEZ.ICE","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611151454250.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Cleaning up git user-interface warts","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-15T15:03:59Z","receivedAt":"2006-11-15T15:03:59Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 15:01:47 +0100 (CET)\nJohannes Schindelin wrote:\n\n> I am really opposed to do \"gh pull\". Not only because of \"gh\" being \n> completely confusing (we already _have_ \"git\", and for porcelains \n> different TLAs), but \"pull\" _really_ is confusing by now. And Mercurial \n> did not help one wit by insisting on their own interpretation.\n\nThis makes a lot of sense. The \"git\" command isn't damaged so bad\nthat it can't be saved in a backward compatible way, at least for\na transition period. Adding a new command name seems like a step\nbackward.\n \n> Why not do something like \"get/put\" instead? It is\n> \n> - easier to remember\n> - not bogus (AFAICT the meaning is not used in diametrical senses)\n> - shorter to type than download/upload\n> \n> As for \"git merge\": Just by the number of arguments you can discern \n> between the original usage and the new usage, so I am all in favour of \n> replacing \"git pull \" by \"git merge \". Where \"\" \n> can be a branch or a remote or a URL (with cogito style #branchname).\n\nBoth these ideas sound like a step in the right direction too.\n\n"},{"id":"296275","messageId":"Pine.LNX.4.64.0611151000460.2591@xanadu.home","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611151454250.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T15:10:50Z","receivedAt":"2006-11-15T15:10:50Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Johannes Schindelin wrote:\n\n> On Tue, 14 Nov 2006, Junio C Hamano wrote:\n> \n> > Nicolas Pitre writes:\n> > \n> > > 2) \"pull\" and \"push\" should be symmetrical operations\n> > \n> > I think that makes a lot of sense to have \"gh pull\" and \"gh\n> > push\" as symmetric operations, and make \"gh merge\" do the\n> > fast-forward and 3-way merge magic done in the current \"git\n> > pull\". These three words would have a lot saner meaning.\n> \n> I am really opposed to do \"gh pull\". Not only because of \"gh\" being \n> completely confusing (we already _have_ \"git\", and for porcelains \n> different TLAs), but \"pull\" _really_ is confusing by now. And Mercurial \n> did not help one wit by insisting on their own interpretation.\n\nI completely agree that creating yet another command prefix for \nbasically the same tools would be a disaster. We have \"git\" already so \nlet's stick to it and make its usage just more sane.\n\n> Why not do something like \"get/put\" instead? It is\n> \n> - easier to remember\n> - not bogus (AFAICT the meaning is not used in diametrical senses)\n> - shorter to type than download/upload\n\nWell, of all compromizes this is probably the best one so far. I would \nhave prefered to bite the bullet and fix \"pull\" instead of adding yet \nmore commands. But if the consensus is that there is no way on earth \nthat \"pull\" can be salvaged then get/put is probably more enjoyable than \ndownload/upload. This way pull/fetch/push could still be available \n(albeit burried somewhere out of sight).\n\n\n"},{"id":"294273","messageId":"Pine.LNX.4.64.0611151023160.2591@xanadu.home","threadId":"6919","inReplyTo":"200611150917.23756.andyparkins@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T15:41:34Z","receivedAt":"2006-11-15T15:41:34Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Andy Parkins wrote:\n\n> On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:\n> \n> > OK..... let's pretend this is my follow-up to your \"If I were redoing\n> \n> Personally, I agree with almost everything in this email. Except the \n> implementation of point 3.\n> \n> > 3) remote branch handling should become more straight forward.\n> \n> I was completely confused by this origin/master/clone stuff when I started \n> with git. In hindsight, now I understand git a bit more, this is what I \n> would have liked:\n> \n> * Don't use the name \"origin\" twice. In fact, don't use it at all. In a \n> distributed system there is no such thing as a true origin.\n\nI agree, sort of. Not because\"origin\" is ambigous as a name. But \nrather because there is a magic translation from \"master\" to \"origin\", \nand I think this is wrong to do that.\n\nAs mentioned elsewhere (and let's start using \"get\" instead of \"pull\" as \nsuggested by Johannes), a \"get\" should probably always create a branch \ngroup even if it contains only one branch. This way the remote branch \ncalled \"master\" will still be called \"master\" locally, under the branch \ngroup used to represent the remote repository. And if a local name is \nnot provided then let's just call it \"default\". This way, amongst the \nremote references, there would be a \"default/master\" that would be used \nwhen nothing else is provided by the user. So...\n\n\tgit get repo.com/time_machine.git\n\nwould create a local branch named \"remotes/default/master\" if the remote \nrepo has only a master branch.\n\nThen, a simple:\n\n\tgit merge\n\ncould be the same as\n\n\tgit merge default\n\nwhich would be equivalent to\n\n\tgit merge default/master\n\nAfterwards, because the \"default\" remote already exists, then:\n\n\tgit get\n\nwould be the same as\n\n\tgit get default\n\nto get changes for all branches in the \"default\" remote branches, of \nwhich \"master\" might be the only one in the simple case.\n\nBut again I think it is important that the URL to use must be a per \nbranch attribute i.e. attached to \"default/master\" and not just \n\"default\". This way someone could add all branches of interest into the \n\"default\" group even if they're from different repositories, and a \nsimple get without any argument would get them all.\n\n\n"},{"id":"297087","messageId":"7vk61woar5.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"200611150917.23756.andyparkins@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T17:55:26Z","receivedAt":"2006-11-15T17:55:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n>> 3) remote branch handling should become more straight forward.\n>\n> I was completely confused by this origin/master/clone stuff when I started \n> with git. In hindsight, now I understand git a bit more, this is what I \n> would have liked:\n>\n> * Don't use the name \"origin\" twice. In fact, don't use it at all. In a \n> distributed system there is no such thing as a true origin.\n>\n> * .git/remotes/origin should be \".git/remotes/default\". \"origin\" is only \n> special because it is the default to push and pull - it's very nice to have a \n> default, but it should therefore be /called/ \"default\".\n\nI think the naming is just a minor detail and can be overridden\nwith \"clone --origin\" already. Renaming it to default is just\nlike making separate-remote the default to me -- it is fine as\nlong as it does not break people's expectations.\n\n> * If clone really wants to have a non-read-only master, then that should \n> be .git/refs/heads/master and will initialise \n> to .git/refs/remotes/$name/master after cloning. Personally I think this is \n> dangerous because it assumes there is a \"master\" upstream - which git doesn't \n> mandate at all. Maybe it would be better to take the upstream HEAD and \n> create a local branch for /that/ branch rather than require that it is \n> called \"master\".\n\nI think the latter is what clone has done always; take remote's\nHEAD and use that to initialize local master (there is no\nconfusion coming from multiple peer repositories because you\nclone from only one place to initialize the repository -- that\none _is_ the origin), and we even keep the HEAD pointing at the\nremote's master or whatever it points at at the remote. Using\n\"$name\" as an object name uses .git/refs/remotes/$name/HEAD.\n\n> * git-clone should really just be a small wrapper around\n>...\n> If git-clone does anything that can't be done with settings in the config \n> and the remotes/default file then it's wrong. The reason I say this is that \n> as soon as git-clone has special capabilities (like --shared, --local \n> and --reference) then you are prevented from doing magic with existing \n> repositories.\n\nThat is not entirely true. clone has convenience because people\nasked. It does not have to mean you are not allowed to give\nsimilar convenience to other commands. Patches?\n\n> branches from two other local repositories that have the objects hard linked?\n\nfetch by second local repository with git-local-fetch perhaps.\n\n> There have been lots of \"wishlist\" posts lately; would it be\n> useful if I tried to collect all these suggestions from\n> various people into one place to try and get a picture of any\n> consensus?\n\nA list of common things wished by people certainly is a handy\nthing to have.\n\nA consensus would not write code and it generally does not take\ntechnology into account to tell what is realistic and what is\nnot, so the result needs to be take with a grain of salt,\nthough.\n"},{"id":"297794","messageId":"7vfyckoaju.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151023160.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T17:59:49Z","receivedAt":"2006-11-15T17:59:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> But again I think it is important that the URL to use must be a per \n> branch attribute i.e. attached to \"default/master\" and not just \n> \"default\". This way someone could add all branches of interest into the \n> \"default\" group even if they're from different repositories, and a \n> simple get without any argument would get them all.\n\nI think the \"one group per one remote repository\" model is a lot\neasier to explain. At least when I read your first \"branch\ngroup\" proposal that was I thought was going on and I found it\nquite sensible (and it maps more or less straightforwardly to\nthe way existing .git/refs/remotes is set up by default).\n"},{"id":"295830","messageId":"Pine.LNX.4.64.0611150950170.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611142306090.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-15T18:03:18Z","receivedAt":"2006-11-15T18:03:18Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 14 Nov 2006, Nicolas Pitre wrote:\n> \n> But the fact is that HG (which has a growing crowd of happy campers, \n> maybe even larger than the BK crowd now) did work with and got used to a \n> sensible definition of what a \"pull\" is.\n\nGuys, before you start thinking this way, the fact is, there's a lot of \nhappy git users. \n\nSo the reason for using \"git pull\" is\n\n - bk did it that way, and like it or not, bk was the first usable \n distributed system. hg is totally uninteresting.\n\n - git itself has now done it that way for the last 18 months, and the \n fact is, the people _complaining_ are a small subset of the people who \n actually use git on a daily basis and don't complain.\n\nSo don't fall for the classic \"second system syndrome\". The classic reason \nfor getting the second system wrong is because you focus on the issues \npeople complain about, and not on the issues that work well (because the \nissues that work fine are obviously not getting a lot of attention).\n\nIf you think \"pull\" is confusing, I can guarantee you that _changing_ the \nname is a hell of a lot more confusing. In fact, I think a lot of the \nconfusion comes from cogito, not from git - the fact that cogito used \ndifferent names and different syntax was a mistake, I think.\n\nAnd that '#' for branch naming in particular was (and is) total \nbraindamage. The native git branch naming convention is just fundamentally \nmuch better, and allows you to very naturally fetch multiple branches at \nonce, in a way that cogito's syntax does not.\n\nSo when I see suggestions of using that brain-damaged cogito syntax as an \n\"improvement\", I know for a fact that somebody hasn't thought things \nthrough, and only thinks it's a better syntax beause of totally bogus \nreasons.\n\nI do agree that we probably could/should re-use the \"git merge\" name. The \ncurrent \"git merge\" is an esoteric internal routine, and I doubt a lot of \npeople use it as-is. I don't think it would be a mistake to make \"git \nmerge\" basically be an alias for \"git pull\", for example, and I doubt many \npeople would really even notice.\n\nBut the fact is, git isn't really that hard to work out, and the commands \naren't that complicated. There's no reason to rename them. We do have \nother problems:\n\n - default branch selection for merging is broken (it should definitely \n take the current branch into account). When I do \"git pull\" with no \n branch specification, and I happen to be on a branch that is associated \n with something else than \"master\" in the remote, I shouldn't merge with \n master.\n\n - I agree that having to create temporary branches to just look at a tag \n that you don't want to actually develop on is just unnecessarily \n bothersome.\n\nBut trying to rename \"pull\" (or the \"git\" name itself) is just going to \ncause more confusion than you fix.\n\n"},{"id":"297867","messageId":"Pine.LNX.4.64.0611151309290.2591@xanadu.home","threadId":"6919","inReplyTo":"7vfyckoaju.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T18:11:36Z","receivedAt":"2006-11-15T18:11:36Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > But again I think it is important that the URL to use must be a per \n> > branch attribute i.e. attached to \"default/master\" and not just \n> > \"default\". This way someone could add all branches of interest into the \n> > \"default\" group even if they're from different repositories, and a \n> > simple get without any argument would get them all.\n> \n> I think the \"one group per one remote repository\" model is a lot\n> easier to explain. At least when I read your first \"branch\n> group\" proposal that was I thought was going on and I found it\n> quite sensible (and it maps more or less straightforwardly to\n> the way existing .git/refs/remotes is set up by default).\n\nI think one group per remote repo is how things should be by default \ntoo. But we should not limit it to that if possible.\n\n\n"},{"id":"298363","messageId":"7vbqn8o9st.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151000460.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T18:16:02Z","receivedAt":"2006-11-15T18:16:02Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n>> Why not do something like \"get/put\" instead? It is\n>> \n>> - easier to remember\n>> - not bogus (AFAICT the meaning is not used in diametrical senses)\n>> - shorter to type than download/upload\n>\n> Well, of all compromizes this is probably the best one so far. I would \n> have prefered to bite the bullet and fix \"pull\" instead of adding yet \n> more commands. But if the consensus is that there is no way on earth \n> that \"pull\" can be salvaged then get/put is probably more enjoyable than \n> download/upload. This way pull/fetch/push could still be available \n> (albeit burried somewhere out of sight).\n\nI still think in the long run you would be better off giving\nseparate names to Porcelains because I am sure you are going to\nfind the next command to \"fix\", you cannot suddenly change the\nsemantics of the command, and you soon run out of alternative\nways to name the action and you in addition have to explain the\ndifferences between fetch and get to new users. At least, with\n\"ig pull\", you can dismiss all the broken git-x Porcelain-ish by\nsaying \"Oh, git-x user-level commands had inconsistent semantics\nand broken UI so do not use them anymore -- they are still there\nonly to help old timers transition. The user level commands are\nnow called ig-x and ig stands for improved git\".\n\nBut that's a very minor detail and can be fixed when we hit the\nwall, so let's wait and see what happens. Please consider my\ngh/gu/cg/whatever dropped.\n\nI think get/put is much better than suddenly changing what pull\nmeans and is shorter to type than x-load; I am Ok with them.\nAlthough I think these words are tainted by SCCS, I do not think\nanybody cares.\n"},{"id":"295718","messageId":"ejfm6c$bu4$1@sea.gmane.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611150950170.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-15T18:28:41Z","receivedAt":"2006-11-15T18:28:41Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Linus Torvalds wrote:\n\n> But the fact is, git isn't really that hard to work out, and the commands \n> aren't that complicated. There's no reason to rename them. We do have \n> other problems:\n> \n>  - default branch selection for merging is broken (it should definitely \n>    take the current branch into account). When I do \"git pull\" with no \n>    branch specification, and I happen to be on a branch that is associated \n>    with something else than \"master\" in the remote, I shouldn't merge with \n>    master.\n\nThis problem is _slightly_ migitated by branch..merge config variable.\nSlightly because you have to specify branch to merge, instead of forbidding\nmerge if you are not on specific branch (and you don't override it).\n\n>  - I agree that having to create temporary branches to just look at a tag \n>    that you don't want to actually develop on is just unnecessarily \n>    bothersome.\n\nAgreed.\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294686","messageId":"Pine.LNX.4.64.0611151315291.2591@xanadu.home","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611150950170.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T18:43:44Z","receivedAt":"2006-11-15T18:43:44Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Linus Torvalds wrote:\n\n> \n> \n> On Tue, 14 Nov 2006, Nicolas Pitre wrote:\n> > \n> > But the fact is that HG (which has a growing crowd of happy campers, \n> > maybe even larger than the BK crowd now) did work with and got used to a \n> > sensible definition of what a \"pull\" is.\n> \n> Guys, before you start thinking this way, the fact is, there's a lot of \n> happy git users. \n> \n> So the reason for using \"git pull\" is\n> \n> - bk did it that way, and like it or not, bk was the first usable \n> distributed system. hg is totally uninteresting.\n> \n> - git itself has now done it that way for the last 18 months, and the \n> fact is, the people _complaining_ are a small subset of the people who \n> actually use git on a daily basis and don't complain.\n\nThose arguments are somewhat flawed. If we stick to \"BK did it that way \nand it was first\", then following that logic we would also carry a lot \nof CVS baggage because \"CVS did it that way, and it was the most \nsuccessful of its kind\". Still, we decided not to follow CVS nor BK in \nmany ways already.\n\nAs for the fraction of people complaining being a small fraction of \ncurrent GIT users: that is easily explainable by the fact that most \npeople who would have grown the complainers group are simply not GIT \nusers anymore since they were turned away by GIT's current user \ninterface issues. The only complainers remaining are those who see \nvalue in the GIT technology but who would like to bring more \nintuitiveness to the GIT interface instead of going for the alternative \ntechnology. And those kind of people are always few.\n\n> So don't fall for the classic \"second system syndrome\". The classic reason \n> for getting the second system wrong is because you focus on the issues \n> people complain about, and not on the issues that work well (because the \n> issues that work fine are obviously not getting a lot of attention).\n\nThe counter part of that is the possibility to fall for the \"ivory tower \nsyndrome\" where seasoned GIT users feel they are well satisfied with \nwhat is currently available and unwilling to consider changes that would \nreduce the barrier to entry for new users... simply because they are so \nused to the way things work that they can't see why others have problems \nwith it.\n\n> If you think \"pull\" is confusing, I can guarantee you that _changing_ the \n> name is a hell of a lot more confusing.\n\nAgreed. This is why the current discussion led to a proposition that \nallows for \"pull\" to remain as is but to have a \"get\" version that would \nbe the alternate (saner) version.\n\n> In fact, I think a lot of the \n> confusion comes from cogito, not from git - the fact that cogito used \n> different names and different syntax was a mistake, I think.\n> \n> And that '#' for branch naming in particular was (and is) total \n> braindamage. The native git branch naming convention is just fundamentally \n> much better, and allows you to very naturally fetch multiple branches at \n> once, in a way that cogito's syntax does not.\n> \n> So when I see suggestions of using that brain-damaged cogito syntax as an \n> \"improvement\", I know for a fact that somebody hasn't thought things \n> through, and only thinks it's a better syntax beause of totally bogus \n> reasons.\n\nDo you have comments on my proposed syntax (that would be implemented \nwith a git-get command) which I think doesn't really look like cogito?\n\n> I do agree that we probably could/should re-use the \"git merge\" name. The \n> current \"git merge\" is an esoteric internal routine, and I doubt a lot of \n> people use it as-is. I don't think it would be a mistake to make \"git \n> merge\" basically be an alias for \"git pull\", for example, and I doubt many \n> people would really even notice.\n\nAgreed.\n\n> But the fact is, git isn't really that hard to work out, and the commands \n> aren't that complicated.\n\nI agree with you in general, except for the \"pull\" behavior which is \nreally really odd. Maybe it made sense in the BK context, maybe it is \nfine _once_ you get used to it, but otherwise it is really overloaded.\n\n> But trying to rename \"pull\" (or the \"git\" name itself) is just going to \n> cause more confusion than you fix.\n\nAgreed again.\n\n\n"},{"id":"297691","messageId":"20061115184914.GA24122@spearce.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151315291.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-15T18:49:14Z","receivedAt":"2006-11-15T18:49:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Nicolas Pitre wrote:\n> As for the fraction of people complaining being a small fraction of \n> current GIT users: that is easily explainable by the fact that most \n> people who would have grown the complainers group are simply not GIT \n> users anymore since they were turned away by GIT's current user \n> interface issues. The only complainers remaining are those who see \n> value in the GIT technology but who would like to bring more \n> intuitiveness to the GIT interface instead of going for the alternative \n> technology. And those kind of people are always few.\n\nOr they are by proxy.\n\n*I* don't see that much of a problem with git pull; I can use it\nwithout trouble at this point. But I find it difficult to teach\nto others.\n\nMy complaints about git pull/fetch/push are by proxy for about 10\nother users who aren't on the mailing list but whom I interact with\nthrough Git. They don't like pull/fetch/push very much.\n\nSo count my complaints 10 times. :)\n\nOk, that's still a drop in the bucket of current Git users.\nBut still, I'm sure there are others. I think Carl was recently\ntalking about complaints from some Fedora folks...\n\n-- \n"},{"id":"298084","messageId":"200611151858.51833.andyparkins@gmail.com","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611150950170.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-15T18:58:50Z","receivedAt":"2006-11-15T18:58:50Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, November 15 18:03, Linus Torvalds wrote:\n\n> Guys, before you start thinking this way, the fact is, there's a lot of\n> happy git users.\n\nI'm a happy user, doesn't mean I wouldn't like changes. In fact, by that \nargument, that there are happy users means that there is no need to ever make \nchanges.\n\n> - git itself has now done it that way for the last 18 months, and the\n> fact is, the people _complaining_ are a small subset of the people who\n> actually use git on a daily basis and don't complain.\n\nThat's awfully like the argument I hear off my bank whenever I complain to \nthem too - \"well lots of other people don't complain so we must be right\". \nThe people who complain are a subset of the people who have complaints. I \ndon't think never changing is a good argument - leaving aside the actual \nchanges under discussion - in another 18 months lets say there are double the \nnumber of git users, and 18 months after that double again - in that case the \npotential new users needs outweigh the current users needs.\n\n> If you think \"pull\" is confusing, I can guarantee you that _changing_ the\n> name is a hell of a lot more confusing. In fact, I think a lot of the\n\n> But the fact is, git isn't really that hard to work out, and the commands\n\nOn the one hand you're arguing that git syntax is easy to learn, and on the \nother that no one will be able to learn a new syntax just as easily.\n\n> aren't that complicated. There's no reason to rename them. We do have\n> other problems:\n\nThat there are other problems doesn't negate these problems.\n\n> But trying to rename \"pull\" (or the \"git\" name itself) is just going to\n> cause more confusion than you fix.\n\nI don't think so. Mainly because the proposed new git pull would be a subset \nof the existing git pull. It's not changing function, it's just reducing in \nfunction.\n\n\nAndy\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"297696","messageId":"200611151902.16358.andyparkins@gmail.com","threadId":"6919","inReplyTo":"7vbqn8o9st.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-15T19:02:14Z","receivedAt":"2006-11-15T19:02:14Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:\n\n> I still think in the long run you would be better off giving\n> separate names to Porcelains because I am sure you are going to\n\nThe problem I think with that is that the line between plumbing and porcelain \nis not clear. If you have two names then for the ambiguous ones you are just \nmaking it more confusing because there is yet another variable to try before \nyou get the function you want.\n\n\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"297813","messageId":"455B64F7.9040506@gmx.net","threadId":"6919","inReplyTo":"20061115184914.GA24122@spearce.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Marko Macek","fromEmail":"marko.macek@gmx.net","sentAt":"2006-11-15T19:05:27Z","receivedAt":"2006-11-15T19:05:27Z","isPatch":false,"sender":{"key":"marko.macek@gmx.net","avatar":null},"body":"Shawn Pearce wrote:\n> Nicolas Pitre wrote:\n>> As for the fraction of people complaining being a small fraction of \n>> current GIT users: that is easily explainable by the fact that most \n>> people who would have grown the complainers group are simply not GIT \n>> users anymore since they were turned away by GIT's current user \n>> interface issues. The only complainers remaining are those who see \n>> value in the GIT technology but who would like to bring more \n>> intuitiveness to the GIT interface instead of going for the alternative \n>> technology. And those kind of people are always few.\n> \n> Or they are by proxy.\n> \n> *I* don't see that much of a problem with git pull; I can use it\n> without trouble at this point. But I find it difficult to teach\n> to others.\n> \n> My complaints about git pull/fetch/push are by proxy for about 10\n> other users who aren't on the mailing list but whom I interact with\n> through Git. They don't like pull/fetch/push very much.\n> \n> So count my complaints 10 times. :)\n> \n> Ok, that's still a drop in the bucket of current Git users.\n> But still, I'm sure there are others. I think Carl was recently\n> talking about complaints from some Fedora folks...\n\nAgreed. Personally, the first thing that I notice when trying to switch\n from Subversion to git is the behavior of 'index', mainly in git-diff, git-status and \ngit-commit.\n\nFor people switching from CVS and SVN it would be much better if the index was hidden \nbehind the scenes by using different defaults:\n\ngit-commit -a\ngit-status -a\ngit-diff HEAD\n\nBTW, currently there's a minor bug: git-diff HEAD doesn't work before you \nmake the first commit. Perhaps this should be special cased.\n\nI could personally get used to this, but I'd surely get blank \nstares from people when teaching them the difference.\n\nI guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.\n(which is very confusing for someone coming to _git_ home page, trying to learn git).\n\n"},{"id":"295996","messageId":"200611151914.50530.andyparkins@gmail.com","threadId":"6919","inReplyTo":"7vk61woar5.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2006-11-15T19:14:48Z","receivedAt":"2006-11-15T19:14:48Z","isPatch":false,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Wednesday 2006, November 15 17:55, Junio C Hamano wrote:\n\n> I think the latter is what clone has done always; take remote's\n> HEAD and use that to initialize local master (there is no\n\nIt's this sort of thing that is confusing though - the remote HEAD branch \ncould be anything, and yet that is made to be origin locally as a tracking \nbranch and then master as the writable branch. What if upstream /has/ a \nmaster but \"next\" is its HEAD? You'd then get\n\n next:remotes/origin\n master:remotes/master\n\nThen a local master which is actually upstream next! Oh dear.\n\nI may well have misunderstood what you've said above above clone always \ninitialising master from remote's HEAD; if so please disregard what I'm \nsaying.\n\n> > that as soon as git-clone has special capabilities (like --shared,\n> > --local and --reference) then you are prevented from doing magic with\n> > existing repositories.\n>\n> That is not entirely true. clone has convenience because people\n> asked. It does not have to mean you are not allowed to give\n> similar convenience to other commands. Patches?\n\nAbsolutely, that was why I said clone shouldn't have special abilities. In \nfact, if you're willing you don't need clone at all; you just need \ngit-init-db and to write the correct remotes file. \n\n> > branches from two other local repositories that have the objects hard\n> > linked?\n>\n> fetch by second local repository with git-local-fetch perhaps.\n\nIs that not plumbing? I thought this was about porcelain.\n\n> A consensus would not write code and it generally does not take\n> technology into account to tell what is realistic and what is\n> not, so the result needs to be take with a grain of salt,\n> though.\n\nOf course, I only suggested it because the same suggestions were popping up \nmultiple times. Anyway; I put it in the GitWiki at \nhttp://git.or.cz/gitwiki/Wishlist\n\nAndy\n\n-- \nDr Andrew Parkins, M Eng (Hons), AMIEE\n"},{"id":"295835","messageId":"Pine.LNX.4.64.0611151111250.3349@woody.osdl.org","threadId":"6919","inReplyTo":"200611151858.51833.andyparkins@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-15T19:18:36Z","receivedAt":"2006-11-15T19:18:36Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Nov 2006, Andy Parkins wrote:\n>\n> On the one hand you're arguing that git syntax is easy to learn, and on the \n> other that no one will be able to learn a new syntax just as easily.\n\nI'm saying that people who are new to git will _have_ to learn new \nconcepts ANYWAY.\n\nI don't think the naming is the hard part. \n\nThe fact is, git is one of the very few (essentially _only_) SCM's that \nmake it very clear that all real operations are local and that if you want \nto work with other repositories, you have to \"fetch\" those into local \nbranches first. The fact that \"pull\" exists at all is really just \nshorthand.\n\nIf people have trouble explaining this to others, and have trouble \ngrasping \"pull\", then I will bet that the _real_ issue has nothing at all \nto do with naming at all, and the real issue is that people are being \n_taught_ the concepts in the wrong order.\n\nBefore you learn \"pull\", you should learn \"fetch\". Don't even _mention_ \n\"pull\" until the person got what \"fetch\" means. Because the fact is, \n\"fetch\" is really the much more fundamental operation, and once you \nreally understand what \"fetch\" does, \"pull\" is obvious.\n\nSo I'll argue that the problem isn't naming, the \"problem\" is really that \ngit has a few fundamnetal concepts that people aren't used to. The most \nfundamnetal of those is the notion of the local branch-space. EVERY other \n(broken) SCM has branches as being some kind of totally idiotic separate \nsubdirectories, or doesn't really support branches at all (ie neither BK \nnor CVS really support \"branches\" - even if a concept of that name exists \nin CVS, it has nothing at all in common with the git model of branches).\n\nBut once you understand branches, and understand \"fetch\" (and it really \nisn't _that_ complicated: fetch really does exactly what the name says, so \nif you understand local branches, you will understand \"fetch\"), then it's \na much smaller step to explain \"pull = fetch + merge\".\n\nBut I bet people don't teach it that way. They _start_ by teaching \"pull\". \nRight?\n\n"},{"id":"298099","messageId":"7vzmasld43.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"200611151858.51833.andyparkins@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T19:32:44Z","receivedAt":"2006-11-15T19:32:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n>> But trying to rename \"pull\" (or the \"git\" name itself) is just going to\n>> cause more confusion than you fix.\n>\n> I don't think so. Mainly because the proposed new git pull would be a subset \n> of the existing git pull. It's not changing function, it's just reducing in \n> function.\n\nWe usually use the word \"regression\" to refer to that kind of\nchange.\n\nI think it makes a lot of sense having command x that does\nessentially the same thing as the current fetch but with more\nusability enhancements and more convention as built-in defaults,\nand another command y that does what the current 'pull .' does\nbut with more usability enhancements and more convention as\nbuilt-in defaults. I agree that kind of UI improvements would\nmake it easier to explain to new people. Calling x \"pull\",\nhowever, breaks the existing users and documents, and causes\nconfusion. I really do not think you can argue with that.\n\nThat's why we are talking about using an uncontaminated word\n\"get\". I think it is a good effort.\n\n>> aren't that complicated. There's no reason to rename them. We do have\n>> other problems:\n>\n> That there are other problems doesn't negate these problems.\n\nAnd I think Linus is right in pointing out that there are other\nproblems that are equally or even more pressing than _renaming_\nto break things for existing users.\n\nI personally do not think the current fetch/pull confusing, and\nI do see real downside in _renaming_ them, but I am open to the\ncurrent get/put discussion because I think the new commands'\nsemantics may be designed to match newcomers' expectation better\n(it's to match tools to newcomers instead of teaching them the\nnew language of the land) and I do not think that approach would\nbreak existing users and documents.\n\nFor some things \"matching tools to newcomers\" would not really\nwork, though. For example, I do not think you can get away with\nhiding index forever if you want your users to do real work in a\nworkflow that involves merging and cherry picking.\n\n"},{"id":"297538","messageId":"f2b55d220611151139v66fba16ax97ce6b9966b33ce7@mail.gmail.com","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151111250.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-15T19:39:01Z","receivedAt":"2006-11-15T19:39:01Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"On 11/15/06, Linus Torvalds wrote:\n> But once you understand branches, and understand \"fetch\" (and it really\n> isn't _that_ complicated: fetch really does exactly what the name says, so\n> if you understand local branches, you will understand \"fetch\"), then it's\n> a much smaller step to explain \"pull = fetch + merge\".\n>\n> But I bet people don't teach it that way. They _start_ by teaching \"pull\".\n> Right?\n\n\"git fetch\" is certainly the right thing for the platform integration\nrole, in which one is trying to maintain a series of integration\nbranches which track the bleeding edge of some subsystems while\nkeeping the core stable on each branch. This is not as impossible as\npeople make it out to be, but there certainly isn't much place for\nautomatic merges to _persistent_ branches.\n\nIt's fundamentally a backporting and cherry-picking effort, and the\ngit workflow puts it where it belongs: in the local repository, where\n_transient_ branches can and should be created and destroyed casually\nto track exploratory efforts. These may include automatic merges and\neven cruder techniques (git diff, hack on patch, apply patch). Once\nyou figure out which bits you actually want to backport, you go back\nto a fresh branch and cherry-pick the same bits with the tool instead\nof manually, so that there is less noise in future merges. When\nyou've tested a little, you merge this branch to the persistent branch\nthat other repositories track.\n\nCheers,\n"},{"id":"296139","messageId":"7vr6w4lcpr.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"200611151902.16358.andyparkins@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T19:41:20Z","receivedAt":"2006-11-15T19:41:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andy Parkins writes:\n\n> On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:\n>\n>> I still think in the long run you would be better off giving\n>> separate names to Porcelains because I am sure you are going to\n>\n> The problem I think with that is that the line between plumbing and porcelain \n> is not clear.\n\nThis is moot because we (at least tentatively) agreed not to do\n\"gh\" or \"ig\" or whatever, but I do not understand why you feel\nso.\n\nIf we had a separate Porcelain namespace (say \"ng\" for \"new\ngit\") you would know \"ng-commit\" is not a Plumbing and when you\nare writing a Porcelain script you would stay away from using it\nin your script.\n\nIn the longer term, when the new Porcelain UI Nico and friends\nare designing matures, and if it makes everybody (including\nexisting users who learned git-* Porcelain-ish during 18-months\nprocess) happy, we could gradually deprecate and eventually\nremove the git-* Porcelain-ish over time, at that point we would\nhave a very clear line between plumbing and porcelain.\n\nBut that would not be a flag-day change. During the transition\nperiod you cannot mechanically tell if git-foo is a plumbing or\na porcelain just like you cannot do so now.\n"},{"id":"294759","messageId":"Pine.LNX.4.64.0611151203450.3349@woody.osdl.org","threadId":"6919","inReplyTo":"f2b55d220611151139v66fba16ax97ce6b9966b33ce7@mail.gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-15T20:09:09Z","receivedAt":"2006-11-15T20:09:09Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Nov 2006, Michael K. Edwards wrote:\n> > \n> > But I bet people don't teach it that way. They _start_ by teaching \"pull\".\n> > Right?\n> \n> \"git fetch\" is certainly the right thing for the platform integration\n> role\n\nI'm saying that even if you _never_ end up using \"git fetch\" ever again \n(because in practice you always want to do a \"fetch + merge == pull\"), \npeople who teach others the concepts and usage of git should probably \nstart by talking about \"git fetch\".\n\nThen, when the user says (and he obviously will say this) \"but I don't \nwant to just fetch the other persons work into some local branch, I want \nto actually get it into _my_ branch\", you say \"Ahhah!\" and talk about how \n\"pull\" is a shorthand for first fetching and then merging the result into \nthe current branch.\n\nSee? Once you explain \"fetch\" to somebody, I can pretty much guarantee \nthat they'll explain \"pull\" to themselves without you having to even work \nat it. And then they'll probably happily use \"pull\" ever after, and never \nworry about fetch, but now they'll understand the _concepts_.\n\nIt's only if you start the other way around that \"pull\" vs \"fetch\" vs \n\"push\" become confusing. If you _start_ by explaining branches (and you \nmight use \"gitk --all\" on a small project as a visualization tool), \nsuddenly the concepts aren't all that complicated.\n\nSure, then you have to remember two words (\"pull\" vs \"fetch\"), but I'm \npretty sure that the thing that makes people confused is not the words \nthemselves, but their lack of understanding of the concepts behind them.\n\n"},{"id":"294837","messageId":"20061115201227.GM7201@pasky.or.cz","threadId":"6919","inReplyTo":"7v3b8ltq7r.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-15T20:12:27Z","receivedAt":"2006-11-15T20:12:27Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:\n> You have to admit both pull and fetch have been contaminated\n> with loaded meanings from different backgrounds. I was talking\n> about killing the source of confusion in the longer term by\n> removing fetch/pull/push, so we are still on the same page.\n\nHow was/is fetch contaminated?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i If we had a separate Porcelain namespace (say \"ng\" for \"new\n> git\") you would know \"ng-commit\" is not a Plumbing and when you\n> are writing a Porcelain script you would stay away from using it\n> in your script.\n\nThere is merit in trying to segregate porcelain vs plumbing... at least \nin theory. In practice though I don't think this is something we should \nabsolutely strive for.\n\nWhy? Because something is always going to fail the categorization. \nSure there are commands that are pure plumbing like git-commit-tree, \netc. Some are pure porcelain like git-commit or git-log. Yet we use \ngit-log's output for git-shortlog. Does it mean that git-log is \nplumbing? Also I have a script here that uses git-commit directly \nbecause it is so much convenient rather than futzing with the really \nbare plumbing. I don't think git-commit should be prevented from being \nused within another script even if it is classified as porcelain.\n\nSo we have that notion of plumbing vs porcelain but in practice there is \na whole spectrum between those two poles and I think it is a good thing.\n\n\n"},{"id":"298042","messageId":"87y7qcsbsa.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"7vr6w4lcpr.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-15T20:19:33Z","receivedAt":"2006-11-15T20:19:33Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 11:41:20 -0800, Junio C Hamano wrote:\n> Andy Parkins writes:\n> > On Wednesday 2006, November 15 18:16, Junio C Hamano wrote:\n> >\n> >> I still think in the long run you would be better off giving\n> >> separate names to Porcelains because I am sure you are going to\n> >\n> > The problem I think with that is that the line between plumbing and porcelain\n> > is not clear.\n>\n> This is moot because we (at least tentatively) agreed not to do\n> \"gh\" or \"ig\" or whatever, but I do not understand why you feel\n> so.\n\nI'm not the original poster, but I feel the same way about the line\nbeing unclear.\n\nHere's a real-world example from last week.\n\nFor cairo I wrote a little script that two revspecs, (or one in\nwhich case its first parent is used), and it goes off and checks out\nboth versions, builds each, runs a performance test on each, and then\ngenerates a report showing the performance impact.\n\nSo now I can do things like:\n\n\t# What's the performance impact of my latest change:\n\tcairo-perf-diff HEAD\n\n\t# Have my last few changes helped as much as I'd hoped:\n\tcairo-perf-diff HEAD~3 HEAD\n\n\t# How has performance changed since our last stable release:\n\tcairo-perf-diff 1.2.6 HEAD\n\nAnyway, when I announced this I also mentioned how easily someone\nmight generate an entire series of reports for a series of\ncommits. The command I gave as an example is:\n\n\tfor rev in $(git rev-list 1.2.6..HEAD); do\n\t cairo-perf-diff $rev\n\tdone\n\nI think that's a perfectly legitimate one-liner for users to use, and\nit really shows off the easy-scriptability of git. But certainly, no\n\"new porcelain\" author is going to consider rev-list to be porcelain\nrather than plumbing, right? So as soon as I start teaching people to\ndo useful stuff like this, they might have to reach down into the\n\"scary\" git interface.\n\nI think we're much better off just having one \"git\" namespace for the\nstandard command-line interface, and then making it as easy to use as\npossible.\n\n-Carl\n\n"},{"id":"294407","messageId":"Pine.LNX.4.64.0611151516360.2591@xanadu.home","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151203450.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T20:21:18Z","receivedAt":"2006-11-15T20:21:18Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Linus Torvalds wrote:\n\n> I'm saying that even if you _never_ end up using \"git fetch\" ever again \n> (because in practice you always want to do a \"fetch + merge == pull\"), \n> people who teach others the concepts and usage of git should probably \n> start by talking about \"git fetch\".\n> \n> Then, when the user says (and he obviously will say this) \"but I don't \n> want to just fetch the other persons work into some local branch, I want \n> to actually get it into _my_ branch\", you say \"Ahhah!\" and talk about how \n> \"pull\" is a shorthand for first fetching and then merging the result into \n> the current branch.\n\nActually I believe it would make things even clearer if \"merge\" was \ntaught at that point. Only when the user is comfortable with the \nseparate notions of fetching and merging might the pull shorthand \npossibly be mentioned.\n\n\n"},{"id":"293956","messageId":"Pine.LNX.4.64.0611151524000.2591@xanadu.home","threadId":"6919","inReplyTo":"20061115201227.GM7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T20:26:44Z","receivedAt":"2006-11-15T20:26:44Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Petr Baudis wrote:\n\n> On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:\n> > You have to admit both pull and fetch have been contaminated\n> > with loaded meanings from different backgrounds. I was talking\n> > about killing the source of confusion in the longer term by\n> > removing fetch/pull/push, so we are still on the same page.\n> \n> How was/is fetch contaminated?\n\nI think \"fetch\" is sane. Its only problem is a missing symetrical \ncounterpart verb, like \"get\" and \"put\".\n\n\n"},{"id":"295455","messageId":"200611152131.14883.Josef.Weidendorfer@gmx.de","threadId":"6919","inReplyTo":"ejfm6c$bu4$1@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-15T20:31:13Z","receivedAt":"2006-11-15T20:31:13Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 15 November 2006 19:28, you wrote:\n> Linus Torvalds wrote:\n> \n> > But the fact is, git isn't really that hard to work out, and the commands \n> > aren't that complicated. There's no reason to rename them. We do have \n> > other problems:\n> > \n> >  - default branch selection for merging is broken (it should definitely \n> >    take the current branch into account). When I do \"git pull\" with no \n> >    branch specification, and I happen to be on a branch that is associated \n> >    with something else than \"master\" in the remote, I shouldn't merge with \n> >    master.\n> \n> This problem is _slightly_ migitated by branch..merge config variable.\n> Slightly because you have to specify branch to merge, instead of forbidding\n> merge if you are not on specific branch (and you don't override it).\n\nWe should change this.\n\nThe problem is that whatever is the first Pull line in remotes config gets\nmerged by default into current branch, which most often is not the right\nthing to do.\n\nOften, I find myself doing \"git branch\" just to make sure that I am on\n\"master\", so that a following pull does not do a bogus merge.\n\nCan we please disable this behavior, e.g. by allowing a fake first\nPull line like \"Pull: (not-for-merge)\" to prohibit any merge?\n\nThis even could be written by default in git-clone somewhere in the future,\nand we suddenly get the behavior of pull being symmetric to push - at least\nby default. And still, it is fully compatible to existing repositories.\n\nTo make pull do the right thing, we _have_ to configure branch..merge\nwhenever we create a new branch (which matters for git-clone, too).\n\nJosef\n\n> \n> >  - I agree that having to create temporary branches to just look at a tag \n> >    that you don't want to actually develop on is just unnecessarily \n> >    bothersome.\n> \n> Agreed.\n"},{"id":"295867","messageId":"20061115203517.GN7201@pasky.or.cz","threadId":"6919","inReplyTo":"200611152131.14883.Josef.Weidendorfer@gmx.de","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-15T20:35:17Z","receivedAt":"2006-11-15T20:35:17Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:\n> Often, I find myself doing \"git branch\" just to make sure that I am on\n> \"master\", so that a following pull does not do a bogus merge.\n> \n> Can we please disable this behavior, e.g. by allowing a fake first\n> Pull line like \"Pull: (not-for-merge)\" to prohibit any merge?\n\nWait, if you don't want pull to merge, why do you pull and not fetch?\n\n(Disclaimer: I'm not intimately familiar with git pull/fetch and I\ndidn't read the whole thread yet.)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Petr Baudis writes:\n> > (v) Git would be properly libified by now. If you wanted to convert\n> > bits of porcelain to C, it would be at least much higher priority.\n> \n> I am not sure about \"libified\" part and I do not know what bits\n> of porcelain wants to become C right now. But I do not think\n> this point is important part of your list.\n\nMerge strategies. Or wait, is that already plumbing?\n\nOr git-status. git-add. Plenty more.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i \n> Actually I believe it would make things even clearer if \"merge\" was \n> taught at that point. Only when the user is comfortable with the \n> separate notions of fetching and merging might the pull shorthand \n> possibly be mentioned.\n\nI agree. I just expect that \"merge\" is such a simple concept that it \ndoesn't really need a whole lot of explaining. \n\nPeople kind of expect merging to be hard, but I think it's because CVS et \nal have tought people that merging is _painful_. I don't think it's a very \ncomplicated concept per se, especially if you have explained branches with \ngitk already.\n\nBut yes, the order should be:\n\n (a) explain what \"branches\" mean in git (and in that situation, \"fetch\" \n is very natural - I think fetching itself is probably easier to \n explain than \"branches\" are).\n (b) once you've explained branches, the notion of \"merge\" comes next, and \n I _think_ that is very obvious. This is where UI issues come in, \n because \"git merge\" is really a totally internal program with a \n pretty horrid UI, but I think we could fix the syntax, and even with \n the current syntax you can really just gloss it over, because nobody \n is really going to care.\n (c) once \"fetching branches\" and \"merging\" have been explained, \"pull\" is \n really pretty damn trivial, and in fact, if you then explain that \n it's just easier to do \"git pull . branchname\" than to use \"git \n merge\", I think people may just even agree with you.\n\nI think I saw that particular discussion on #git: somebody didn't expect \n\"git pull . branch\" to be the way to merge. And again, I think it's \nnot _really_ because \"pull\" is hard to understand, it's because people \nhaven't been walked through the thing in this way.\n\nOnce you understand local branches, fetching and merging, it's actually \n_easier_ to explain why we merge even local branches with \"git pull .\": \nyou just tell them that this way you can use the same command regardless \nof whether you're merging something local or something remote. Again, if \nit's explained that way, I bet a lot of people react with \"ahh, that's \nclever\", and _like_ the fact that they only really need to learn _one_ \ncommand, instead of learning two.\n\nSee? Explain it that way: \"pull\" really is simple. By using \"pull\", you \ndon't have to learn about \"merge\" syntax. You -can- use \"merge\" as a \nseparate program if you want to, but the syntax isn't very nice, exactly \nbecause you're not really expected to.\n\nBut the real issue here is to explain local branches. I will happily admit \nthat local branches are very VERY different from just about any other SCM, \nbut I also claim that git is just much BETTER than other SCM's in this \nrespect.\n\nAnd yes, this is why you should NOT try to use the same naming as \"hg\", \nfor example. Last I saw, hg still didn't even have local branches, To \nmercurial, repository == branch, and that's it. It was what I came from \ntoo, and I used to argue for using git that way too. I've since seen the \nerror of my ways, and git is simply BETTER. \n\nAnd the concept of local branches is exactly _why_ you have to have \nseparate \"fetch\" and \"pull\", but why you do _not_ need a separate \"merge\" \n(because \"pull .\" does it for you).\n\nIf you don't understand local branches, you'll never understand git usage. \nAnd once you _do_ understand local branches, \"fetch\" vs \"pull\" actually is \nrather simple.\n\n"},{"id":"294134","messageId":"7vejs4l9wy.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"455B64F7.9040506@gmx.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T20:41:49Z","receivedAt":"2006-11-15T20:41:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marko Macek writes:\n\n> For people switching from CVS and SVN it would be much better if the\n> index was hidden behind the scenes by using different defaults:\n>\n> git-commit -a\n> git-status -a\n> git-diff HEAD\n>\n> BTW, currently there's a minor bug: git-diff HEAD doesn't work before\n> you make the first commit. Perhaps this should be special cased.\n\nThat's only a _bug_ in your implementation of the synonym for\n\"svn diff\" which blindly used \"git diff HEAD\".\n\n\"git diff HEAD\" is not a synonym for \"svn diff\" when HEAD does\nnot exist yet, because you are asking \"please give me a diff\nbetween the tree in the HEAD commit and my working tree files\nthrough the index\". So if you are doing \"git-svnish-diff\"\nPorcelain script, it should notice that HEAD does not exist yet\nand take an appropriate action. We do something similar in\ngit-status; the porcelain notices and acts differently when HEAD\nis not there yet.\n\nThis \"there is no HEAD yet\" is not related to the index, but I\nam skeptical about trying to hide the index from the end user.\n\nYou can make some things map more naturally to systems like SVN\nand CVS than other things. For example, Nico's proposal to\nalways use remote tracking branches and defaulting to use\nrefs/remotes/ would be a way to match UI of pull/push to another\nexisting system and that would work well (I am not agreeing to\nthe change to make 'pull' not to do the merge which would break\nexisting users -- I am just saying that the result would be self\nconsistent). But things that have difference at the concept\nlevel, I suspect no clever mapping to hide the differences would\nwork well.\n\nThe index is quite central to the way git works at the concept\nlevel, and I think it is doing disservice to the end user to try\nhiding it forever from them and failing to do so, rather than\nbeing honest and teaching them the concept upfront.\n\nBut me thinking so does not necessarily mean you are forbidden\nfrom trying. Your efforts may result in a system where the\nindex is totally invisible and the end user never has to know\nabout it.\n"},{"id":"294173","messageId":"Pine.LNX.4.64.0611151243030.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151524000.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-15T20:50:10Z","receivedAt":"2006-11-15T20:50:10Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Nov 2006, Nicolas Pitre wrote:\n> \n> I think \"fetch\" is sane. Its only problem is a missing symetrical \n> counterpart verb, like \"get\" and \"put\".\n\nIf you're a dog owner, the obvious counterpart for \"fetch\" is \"throw\" ;)\n\nI think \"get\" and \"put\" would be bad, just because of confusion with \n\"sccs get\" (ie it has that \"get this file\" connotations).\n\nMaybe \"fetch\" and \"push\" aren't totally diametrically opposite, but \nreally, I don't think they are that hard to understand either. We do have \nthe BK legacy of \"pull\" implying a merge, and that's fairly fundamental. \n\nIt's also true that in a lot of usage schenarios, what people actually \n_use_ is \"pull\" and \"push\", and no, they aren't mirror images (since push \nwill _not_ do the merge), but at the same time, from a _usage_ standpoint \nthey really _are_ each others opposites. \n\nYou \"pull\" to get other peoples data into your branch (and once you've \ninternalized local branches and the merge thing, you know what this \nmeans), and you \"push\" to push your changes out. It really _is_ the usage \nschenario, and using \"opposite\" words really _does_ make sense.\n\nIt's true that _technically_ \"fetch\" is the opposite of \"push\", but at the \nsame time, that really is about technology, not about usage models. You \nnormally wouldn't do a \"git fetch + git push\" pair. You _can_ do so, but \nit's not the natural way to work - unless you're just doing a mirror \nservice.\n\n"},{"id":"295881","messageId":"87wt5wsabs.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"7v3b8lv9c9.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-15T20:51:03Z","receivedAt":"2006-11-15T20:51:03Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:\n> I do not think the Porcelain-ish UI that is shipped with git\n> should be taken with the same degree of \"authority\" as git\n> Plumbing.\n\nI think we should fix this. \"This is great technology with a crap\ninterface on top\" really isn't a good story. I don't actually agree\nwith that---I don't think the git interface is really all that bad,\nit's just got a few little things that tend to trip up new users in my\nexperience.\n\nAnd what git does really well, (history exploring, allowing for\npipeline on-liners to iterate over revisions in A..B), are things that\ndon't even exist in other tools, nor even in the \"alternate\"\nporcelains for git. This stuff is where git's interface is really\nfantastic, and it would be a shame to write it off.\n\n> I think\n> single isolated developers, contributors and CVS style shared\n> repository usage could be a lot improved because neither of us\n> were concentrating in their workflows. This needs somebody\n> motivated enough to improve things in that area. For example,\n> StGIT with its 'float' command is a great improvement over what\n> rebase does for people in the contributor role.\n\nYes, there are some specific workflow-oriented operations that git\ndoesn't handle as well as it could. Things like commit --amend are\ncertainly improvements. One that is still totally broken is \"follow\nall the development in another repository\" where clone followed by\nrepeated fetch doesn't do the job as soon as the remote adds or\ndeletes a branch.\n\n> But making it more usable for whom is a big question.\n>\n> Quite frankly, I do not think there can be _the_ single UI that\n> would satisfy different types of workflows for some of the\n> commands.\n\nI strongly disagree. Or at least, I don't think we've tried hard\nenough yet that we should give up on this.\n\nI do agree that people in different roles will have different lists of\n\"most used operations\" and that some operations won't appear on some\nusers lists at all, (someone who's just \"watching\" development won't\ncommit or merge, for example---[or so they thing when they start]).\n\nBut I really don't think that for any given operation that different\nroles impose a different desire on the behavior of the operation. We\nhave different people with different background and disagreement on\nnames and silly things like that, but I don't think that's related to\nthe roles in which they are working with the tool.\n\n> For example, fetching and merging from many places without\n> necessarily having corresponding tracking branches is a great\n...\n\nI don't think we've ever had this right in git. The new\n--use-separate-remotes stuff or similar will start to help as it\nbecomes the default. I don't see how this won't benefit everybody.\n\n> For another example, having a commit command to commit\n> everything by default is disastrous for people who allow their\n> workflows to often be interrupted.\n\nWorkflow-interruption is an important thing to support, but separating\nupdate-index and commit really doesn't address it nearly as much as I\nwould like. The lack of really good workflow-interruption support has\nbeen one of my longest-running annoyances with git, (perhaps because I\nhave a problem with trying to do too many things at once). Git can\ncreate and change branches fast enough that it really should be able\nto help me better with this. The only missing piece is being able to\nstash the dirty stuff on the current branch, to be able to come back\nto it later. I've talked a bit about what I would like in this area\nbefore, and I really just need to code it up.\n\n> It is not just command line syntax and the defaults, but\n> concepts as well. People in the integrator role often need to\n> deal with merges and you would need to be aware of the role of\n> the index and need to be able to manipulate the index, ...\n\nAgain, I think it's more that the specific operations bring in\nconcepts, (merge bringing in the index here). As such, someone never\ndoing a merge could easily get by not having to understand the index.\n\n> A Porcelain that does a very similar thing in slightly different\n> way is obviously a waste, but otherwise I do not think it is a\n> problem to have different Porcelains. StGIT does not compete\n> with the \"sucky\" Porcelain-ish shipped with git but makes the\n> user's life a lot more pleasant by complementing what the sucky\n> one does not do well. It is not very useful while I am playing\n> the integrator role, but when I am doing my own thing it is a\n> great addition to my toolchest.\n\nBut even here, there's a bunch of waste in StGit. For example, there\nare a lot of commands in StGit whose only purpose is to translate back\nand forth between the StGit and non-StGit views of the world, (init,\nassimilate, commit, uncommit). Those could all be discarded if the\nfunctionality of StGit were brought down into git itself. Then there\nare a myriad of StGit commands which are basically just the same as\ntheir git counterparts.\n\nNow, StGit is a great tool, and I know that it works really well for\nsome people in the role of just maintaining a stack of changes against\nsome upstream, and can use StGit alone and never touch \"git\" the\ncommand-line.\n\nBut for someone like me who already uses git regularly, and\noccasionally just wants to pop back a few commits, amend it, and then\npush again, StGit is not helpful, (the series of init, assimilate, and\nuncommits just to get started is prohibitive compared to just working\nout the awkward steps needed to make a temporary branch and\nrebase). So I'd love to see just a couple of commands added to \"git\"\nto support these kinds of operations more smoothly.\n\n> I am from the camp that does _not_ want to hide the index, so\n> obviously I do not see any value in its effort to hide the\n> index. But other aspects of it, most notably being friendly to\n> simpler workflows, is a very good thing.\n\nI don't think \"hide or not-to-hide\" is the right way to frame the\ndiscussion about the index. I regularly use update-index to stage\npartial commits, and I find that very useful. And obviously the index\nis involved in resolving merge conflicts.\n\nBut I don't think the user-interface for either of those operations\n(partial commit, resolve conflicts), is ideal, and the current\nrequirement to use either \"update-index \" or \"commit -a\" after\nmodifying a file for the first time is demonstrably a hangup for a lot\nof new users. So I really think it's possible to address both of these\nat once.\n\nAnyone, that's enough generic rambling from me without any specific\ncontent. I'll try to keep future messages focused on specific\ndesirable operations that have problematic interfaces in git right\nnow, along with proposals for improving them.\n\n-Carl\n"},{"id":"294041","messageId":"ejfutp$cgc$1@sea.gmane.org","threadId":"6919","inReplyTo":"87wt5wsabs.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-15T20:57:42Z","receivedAt":"2006-11-15T20:57:42Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n>On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:\n>>\n>> For another example, having a commit command to commit\n>> everything by default is disastrous for people who allow their\n>> workflows to often be interrupted.\n> \n> Workflow-interruption is an important thing to support, but separating\n> update-index and commit really doesn't address it nearly as much as I\n> would like. The lack of really good workflow-interruption support has\n> been one of my longest-running annoyances with git, (perhaps because I\n> have a problem with trying to do too many things at once). Git can\n> create and change branches fast enough that it really should be able\n> to help me better with this. The only missing piece is being able to\n> stash the dirty stuff on the current branch, to be able to come back\n> to it later. I've talked a bit about what I would like in this area\n> before, and I really just need to code it up.\n\nThere is git-stash/git-unstash floating somewhere in the archive.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295391","messageId":"87velgs9hx.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151226590.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-15T21:08:58Z","receivedAt":"2006-11-15T21:08:58Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 12:40:43 -0800 (PST), Linus Torvalds wrote:\n> On Wed, 15 Nov 2006, Nicolas Pitre wrote:\n> >\n> > Actually I believe it would make things even clearer if \"merge\" was\n> > taught at that point. Only when the user is comfortable with the\n> > separate notions of fetching and merging might the pull shorthand\n> > possibly be mentioned.\n>\n> I agree. I just expect that \"merge\" is such a simple concept that it\n> doesn't really need a whole lot of explaining.\n\nWell, one of the problems is that with current git I can teach, (and I\nhave), that there's a conceptual:\n\n\tpull = fetch + merge\n\nBut then shortly after I have to teach an interface notion:\n\n\tmerge = pull .\n\nSo there's this goofy circular notion that people end up with\nmentally. If we fix it so that a local merge really is performed with\n\"git merge \" instead of \"git pull . \" then teaching\npull=fetch+merge really is a lot easier.\n\nIn the meantime, pull would still be useless to me, I think. But maybe\nthat's just the \"default branch to merge\" selection being broken. If\nthat were fixed, maybe I would start using pull.\n\n> (a) explain what \"branches\" mean in git (and in that situation, \"fetch\"\n> is very natural - I think fetching itself is probably easier to\n> explain than \"branches\" are).\n\nThere's a piece missing here, namely the mapping between remote and\nlocal branch names and any notion of \"tracking branches\". I think a\nsane story for that is still being invented, (or if it exists now, I\nhaven't seen it yet).\n\n> (c) once \"fetching branches\" and \"merging\" have been explained, \"pull\" is\n> really pretty damn trivial, and in fact, if you then explain that\n> it's just easier to do \"git pull . branchname\" than to use \"git\n> merge\", I think people may just even agree with you.\n\nWell, they get pretty darn confused at this point, in my experience.\n\n> Once you understand local branches, fetching and merging, it's actually\n> _easier_ to explain why we merge even local branches with \"git pull .\":\n> you just tell them that this way you can use the same command regardless\n> of whether you're merging something local or something remote. Again, if\n> it's explained that way, I bet a lot of people react with \"ahh, that's\n> clever\", and _like_ the fact that they only really need to learn _one_\n> command, instead of learning two.\n\nNo. It's really, really broken to use \"pull .\" for local merging. Not\na feature at all. We just got done establishing that pull is a\nshorthand for doing fetch+merge, so reusing it when there is _no_\nfetch at all is insane.\n\nYou just established quite clearly hat git has a huge advantge over\nall other systems by having a model that everything is fetched in\nand then worked with locally. I agree that this is a major\nselling-point of git, and I'm also baffled that systems like bzr and\nhg try so hard to push every branch into a separate repository.\n\nBut I think that git's \"work with everything locally\" story is undercut\na bit by regular usage being to use a transfer-inducing command like\n\"pull\" for a totally local merge.\n\nAnyway, I think we all agree that we'd really rather have \"git merge\n\" be usable for local merges, so let's get that in place and\nusers can pick whichever they like.\n\n> But the real issue here is to explain local branches. I will happily admit\n> that local branches are very VERY different from just about any other SCM,\n> but I also claim that git is just much BETTER than other SCM's in this\n> respect.\n\nTotally agree.\n\n-Carl\n"},{"id":"294344","messageId":"200611152212.35978.Josef.Weidendorfer@gmx.de","threadId":"6919","inReplyTo":"20061115203517.GN7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2006-11-15T21:12:35Z","receivedAt":"2006-11-15T21:12:35Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 15 November 2006 21:35, Petr Baudis wrote:\n> On Wed, Nov 15, 2006 at 09:31:13PM CET, Josef Weidendorfer wrote:\n> > Often, I find myself doing \"git branch\" just to make sure that I am on\n> > \"master\", so that a following pull does not do a bogus merge.\n> > \n> > Can we please disable this behavior, e.g. by allowing a fake first\n> > Pull line like \"Pull: (not-for-merge)\" to prohibit any merge?\n> \n> Wait, if you don't want pull to merge, why do you pull and not fetch?\n\nI am not really opposed to pull doing a merge. It only should work in\na useful way: ie. only do the merge of updated origin branch when\ncurrent branch is master (given \"Pull: master:origin\").\n\nI want \"git pull\" being harmless if I find myself accidently on a\nbranch != master. I always can do \"git checkout master; git pull . origin\"\nafterwards.\n\nFor this to work, I currently need to specify a \"branch..merge\"\nconfig for _every_ branch I have, as otherwise I get this bogus pull\nmerge behavior. This is not needed if there was a way to configure no\nmerge at all as default pull behavior.\n\nI just noted that allowing such a config option would be kind of a\nworking compromise for all the people which want\npull to be the opposite of push.\n\n"},{"id":"295691","messageId":"7vmz6sjtw8.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"87y7qcsbsa.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T21:13:11Z","receivedAt":"2006-11-15T21:13:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> I'm not the original poster, but I feel the same way about the line\n> being unclear.\n>\n> Here's a real-world example from last week.\n>...\n> Anyway, when I announced this I also mentioned how easily someone\n> might generate an entire series of reports for a series of\n> commits. The command I gave as an example is:\n>\n> \tfor rev in $(git rev-list 1.2.6..HEAD); do\n> \t cairo-perf-diff $rev\n> \tdone\n>\n> I think that's a perfectly legitimate one-liner for users to use, and\n> it really shows off the easy-scriptability of git. But certainly, no\n> \"new porcelain\" author is going to consider rev-list to be porcelain\n> rather than plumbing, right? So as soon as I start teaching people to\n> do useful stuff like this, they might have to reach down into the\n> \"scary\" git interface.\n\nThat is a very fine example, but I do not see why it is a\nproblem. I do not think the goal of Porcelain is to make it\ntotally unnecessary for users to know about the plumbing.\n\nThe one-liner is essentially a new Porcelain command that is\nuseful in the cairo developers' workflow, and implementing it\nwith a plumbing command makes perfect sense. The whole point of\ngit plumbing is to be friendly for scripted use. If the user\nwho learns that one-liner from you gets curious why and how that\none-liner works, that would be a good gentle introduction to the\nplumbing, but otherwise the user is not forced to know about it.\n\nAlso I do not see a problem if some plumbing commands happen to\nbe also useful by themselves (\"[alias] less = -p cat-file -p\"\ncomes to mind for example).\n\nSome plumbing commands may be too deep magic and users do not\nhave to directly deal with them every day. Some other plumbing\ncommands are so low-level and needs combination with others to\nbe any useful, and it is cumbersome to type the combination\nevery day. For the latter kind, we have Porcelain commands that\nimplement the frequently used combination and the end users do\nnot have to know about them.\n\nSo it is true that by having a rich and usable set of Porcelain,\nthere is less need for the users to know about all the plumbing\ndetails, but I consider that is a happy consequence. It does\nnot have to be the goal of having a good Porcelain to hide the\nwhole plumbing.\n\n\n"},{"id":"296575","messageId":"Pine.LNX.4.64.0611151559470.2591@xanadu.home","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151243030.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T21:18:21Z","receivedAt":"2006-11-15T21:18:21Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Linus Torvalds wrote:\n\n> \n> \n> On Wed, 15 Nov 2006, Nicolas Pitre wrote:\n> > \n> > I think \"fetch\" is sane. Its only problem is a missing symetrical \n> > counterpart verb, like \"get\" and \"put\".\n> \n> If you're a dog owner, the obvious counterpart for \"fetch\" is \"throw\" ;)\n\nYeah. You could always throw a branch to your dog.\n\nOr maybe we should introduce the concept of \"bones\" to GIT in place of \nbranches? ;-)\n\n> I think \"get\" and \"put\" would be bad, just because of confusion with \n> \"sccs get\" (ie it has that \"get this file\" connotations).\n\nHas SCCS really had a similar level of influence than BK or CVS in that \nmatter?\n\n> Maybe \"fetch\" and \"push\" aren't totally diametrically opposite, but \n> really, I don't think they are that hard to understand either. We do have \n> the BK legacy of \"pull\" implying a merge, and that's fairly fundamental. \n> \n> It's also true that in a lot of usage schenarios, what people actually \n> _use_ is \"pull\" and \"push\", and no, they aren't mirror images (since push \n> will _not_ do the merge), but at the same time, from a _usage_ standpoint \n> they really _are_ each others opposites. \n\nThe problem is the \"usage standpoint\" distinction that has to be made. \nExactly because in GIT it is a bit distorted from what most people \nexpect from other standpoints.\n\n> You \"pull\" to get other peoples data into your branch (and once you've \n> internalized local branches and the merge thing, you know what this \n> means), and you \"push\" to push your changes out. It really _is_ the usage \n> schenario, and using \"opposite\" words really _does_ make sense.\n\nBut that's exactly why newbies have problems. Instead of simply \nunderstanding the bare operation (fetch data in a branch _then_ merge \nit) they sort of need to abstract the concept of branch away because a \n\"pull\" does it all automagically. Which is fine as long as you're \nwilling to ignore branch concepts altogether. But once branches are \nback in the picture for more involved operations then the \"pull\" word \nsimply feels odd. Even more so with the local merge syntax.\n\nWhen I say to someone \"just merge branch weezee with your current \nbranch\" the most intuitive command would be:\n\n\tgit merge weezee\n\nBut because \"pull\" mixes two concepts together this makes the thing more \nesoteric. Unless, of course, you get used to the mental model you \noutlined above, but IMHO simply needing a mental model to explain the \ntool is a sign that something is mapped wrong.\n\n\n"},{"id":"298563","messageId":"7virhgjt25.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"87velgs9hx.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T21:31:14Z","receivedAt":"2006-11-15T21:31:14Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> So there's this goofy circular notion that people end up with\n> If we fix it so that a local merge really is performed with\n> \"git merge \" instead of \"git pull . \" then teaching\n> pull=fetch+merge really is a lot easier.\n\nI am wondering if that could be \"git merge ...\"\ninstead. I do not care too much about the ... part (i.e. an\nOctopus), but I often find myself doing:\n\n\tgit checkout next\n git merge \"Merge early part of branch 'foo'\" HEAD foo~3\n\nwhen earlier part of \"foo\" topic are worthy to be in 'next' but\nnot the later ones.\n\n> In the meantime, pull would still be useless to me, I think. But maybe\n> that's just the \"default branch to merge\" selection being broken.\n\nHave you looked into per-branch configuration for default merge\nsource recently? It might not be documented well enough,\nthough, because I do not use it myself, but you should be able\nto improve on that (meaning both documentation and setting up\nthe defaults upon cloning and fetching).\n"},{"id":"297382","messageId":"Pine.LNX.4.64.0611151329420.3349@woody.osdl.org","threadId":"6919","inReplyTo":"200611152212.35978.Josef.Weidendorfer@gmx.de","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-15T21:31:48Z","receivedAt":"2006-11-15T21:31:48Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Nov 2006, Josef Weidendorfer wrote:\n> \n> I am not really opposed to pull doing a merge. It only should work in\n> a useful way: ie. only do the merge of updated origin branch when\n> current branch is master (given \"Pull: master:origin\").\n\nI absolutely agree.\n\nWe should _only_ use the default head when pulling from the default head \n(\"master\"). If we don't pull from within the default branch, we should \neither require an explicit head _or_ we should require that an explicit \nmapping has been set up in .git/config or in .git/remotes/..\n\nSo doing a \"git pull\" from any other branch than \"master\" should probably \nby default say \"which branch do you want to pull from today\"?\n\n"},{"id":"295139","messageId":"Pine.LNX.4.64.0611151638550.2591@xanadu.home","threadId":"6919","inReplyTo":"7virhgjt25.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T21:40:03Z","receivedAt":"2006-11-15T21:40:03Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Junio C Hamano wrote:\n\n> I am wondering if that could be \"git merge ...\"\n> instead. I do not care too much about the ... part (i.e. an\n> Octopus), but I often find myself doing:\n> \n> \tgit checkout next\n> git merge \"Merge early part of branch 'foo'\" HEAD foo~3\n> \n> when earlier part of \"foo\" topic are worthy to be in 'next' but\n> not the later ones.\n\nIndeed !\n\n\n"},{"id":"295887","messageId":"Pine.LNX.4.64.0611151339500.3349@woody.osdl.org","threadId":"6919","inReplyTo":"87velgs9hx.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-15T21:45:58Z","receivedAt":"2006-11-15T21:45:58Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Nov 2006, Carl Worth wrote:\n> \n> Well, one of the problems is that with current git I can teach, (and I\n> have), that there's a conceptual:\n> \n> \tpull = fetch + merge\n> \n> But then shortly after I have to teach an interface notion:\n> \n> \tmerge = pull .\n\nThis is why I would suggest teaching the _concept_ of the \"merge\", and not \nthe actual command.\n\nI don't think you should basically ever use the \"git merge\" command \nitself, not in teaching, and not in real life. So after talking about \nbranches and having taught people to use \"git fetch\", the next stage is \nnot so much to teach people to use \"git merge\", but to explain to them the \n_concept_ of merging. \n\nI really think that's a fairly quick thing, partly exactly _because_ you \nshouldn't at that point need to worry about syntax or details or anything \nlike that at all. You just tell them that there's a notion of \"merging\" \ntwo branches by joining them together and havign the result have the \nchanges from both branches. So it's a _conceptual_ issue, and that's why I \nsaid I think you should just totally gloss over the whole issue of \"git \nmerge\" syntax.\n\nOnce you've explained the _concept_ of merging, you then introduce the \ncommand to actually _execute_ the merge: it's \"git pull\".\n\nSee? No circular thinking at all. One is a _concept_ (\"join two branches \ntogether by including both in the result\") and the other is a command \n(\"pull will fetch the remote data if any, and merge it into the current \nbranch\").\n\nIf you explain it that way, then _obviously_ if you don't need to fetch \nany remote data, doing \"git pull . xyzzy\" will merge the local branch \n\"xyzzy\" into the current branch.\n\n"},{"id":"298472","messageId":"7vac2sjs28.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151638550.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-15T21:52:47Z","receivedAt":"2006-11-15T21:52:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nicolas Pitre writes:\n\n> On Wed, 15 Nov 2006, Junio C Hamano wrote:\n>\n>> I am wondering if that could be \"git merge ...\"\n>> instead. I do not care too much about the ... part (i.e. an\n>> Octopus), but I often find myself doing:\n>> \n>> \tgit checkout next\n>> git merge \"Merge early part of branch 'foo'\" HEAD foo~3\n>> \n>> when earlier part of \"foo\" topic are worthy to be in 'next' but\n>> not the later ones.\n>\n> Indeed !\n\nIndeed, what?\n\nThat means that updated \"git merge\" (not the current one) would\nnot be able to assume it's parameter is a branch name, and still\nhas to come up with the merge message \"Merge \".\n\nMerging only within the local branch namespace already has the\nproblem you need to solve to come up with a nicely formatted\n\"Merge of \" some way. I am not\nsaying that this is unsolvable (you can look at remotes/ files\nto see what remote tracking branch the branch is about), but\nsomething you need to keep in mind when implementing the\nimproved \"git merge\".\n"},{"id":"295699","messageId":"Pine.LNX.4.64.0611151656300.2591@xanadu.home","threadId":"6919","inReplyTo":"7vac2sjs28.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-15T21:59:38Z","receivedAt":"2006-11-15T21:59:38Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Junio C Hamano wrote:\n\n> Nicolas Pitre writes:\n> \n> > On Wed, 15 Nov 2006, Junio C Hamano wrote:\n> >\n> >> I am wondering if that could be \"git merge ...\"\n> >> instead. I do not care too much about the ... part (i.e. an\n> >> Octopus), but I often find myself doing:\n> >> \n> >> \tgit checkout next\n> >> git merge \"Merge early part of branch 'foo'\" HEAD foo~3\n> >> \n> >> when earlier part of \"foo\" topic are worthy to be in 'next' but\n> >> not the later ones.\n> >\n> > Indeed !\n> \n> Indeed, what?\n\nWhat you propose would be excellent indeed.\n\n> That means that updated \"git merge\" (not the current one) would\n> not be able to assume it's parameter is a branch name, and still\n> has to come up with the merge message \"Merge \".\n> \n> Merging only within the local branch namespace already has the\n> problem you need to solve to come up with a nicely formatted\n> \"Merge of \" some way. I am not\n> saying that this is unsolvable (you can look at remotes/ files\n> to see what remote tracking branch the branch is about), but\n> something you need to keep in mind when implementing the\n> improved \"git merge\".\n\nRight. But that is an _implementation_ detail, not a usability issue.\n\n\n"},{"id":"294741","messageId":"20061115220054.GA24861@spearce.org","threadId":"6919","inReplyTo":"ejfutp$cgc$1@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-15T22:00:54Z","receivedAt":"2006-11-15T22:00:54Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jakub Narebski wrote:\n> Carl Worth wrote:\n> >On Tue, 14 Nov 2006 16:31:50 -0800, Junio C Hamano wrote:\n> >>\n> >> For another example, having a commit command to commit\n> >> everything by default is disastrous for people who allow their\n> >> workflows to often be interrupted.\n> > \n> > Workflow-interruption is an important thing to support, but separating\n> > update-index and commit really doesn't address it nearly as much as I\n> > would like. The lack of really good workflow-interruption support has\n> > been one of my longest-running annoyances with git, (perhaps because I\n> > have a problem with trying to do too many things at once). Git can\n> > create and change branches fast enough that it really should be able\n> > to help me better with this. The only missing piece is being able to\n> > stash the dirty stuff on the current branch, to be able to come back\n> > to it later. I've talked a bit about what I would like in this area\n> > before, and I really just need to code it up.\n> \n> There is git-stash/git-unstash floating somewhere in the archive.\n\nI find that a \"git commit -a -m parked; git checkout -b ...\" works\nwell to stash my current stuff off. Then I just amend the commit\nwhen I come back to that branch.\n\n\nThe problem I just ran into today was \"git checkout\" doesn't double\ncheck the file stat data against the index before switching branches.\nIf the file is unchanged between the two branches there's no error.\nSo I switched branches with dirty files that I forgot to park on\nthe old branch.\n\n-- \n"},{"id":"295923","messageId":"20061115220723.GB24861@spearce.org","threadId":"6919","inReplyTo":"7vejs4l9wy.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-15T22:07:23Z","receivedAt":"2006-11-15T22:07:23Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> The index is quite central to the way git works at the concept\n> level, and I think it is doing disservice to the end user to try\n> hiding it forever from them and failing to do so, rather than\n> being honest and teaching them the concept upfront.\n> \n> But me thinking so does not necessarily mean you are forbidden\n> from trying. Your efforts may result in a system where the\n> index is totally invisible and the end user never has to know\n> about it.\n\nI agree with what you are saying about the index.\n\nBut in git-gui I found myself writing code on Monday which tries to\nhide the index from the user unless he/she requested that the index\nbe made visible.\n\nThe reason is there are some users who I'd like to give git-gui to\nwho I'm not sure I trust to make sure their index is in sync with\ntheir working directory before they commit. In some cases I'm lucky\nthat the user even knows what directory their file is stored in. :-(\nYes, there really are computer users who are afraid of directories\nand command lines.\n\nI probably could try to teach them to make sure the final file\nis included in the index before committing, but I think that for\nmost of them they would find this to be just another couple of\nmouse clicks they have to perform before every commit, meaning its\nsomething that the #$@!*@!*@$# tool should just do for them.\n\n-- \n"},{"id":"296630","messageId":"87slgks6b0.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"20061115220054.GA24861@spearce.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-15T22:17:55Z","receivedAt":"2006-11-15T22:17:55Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 17:00:54 -0500, Shawn Pearce wrote:\n> > There is git-stash/git-unstash floating somewhere in the archive.\n\nYes, I did write those once upon a time. ;-)\n\nIt's the manual stash/unstash that I don't want though. I want to be\nable to make this happen automatically when switching branches.\n\n> I find that a \"git commit -a -m parked; git checkout -b ...\" works\n> well to stash my current stuff off. Then I just amend the commit\n> when I come back to that branch.\n\nYes, I do stuff like that as well. And often \"reset HEAD~\" instead of\namend, (always with a moment's pause as reset justly deserves).\n\n> The problem I just ran into today was \"git checkout\" doesn't double\n> check the file stat data against the index before switching branches.\n> If the file is unchanged between the two branches there's no error.\n> So I switched branches with dirty files that I forgot to park on\n> the old branch.\n\nRight, so that's just more evidence that this approach is a little\nawkward.\n\nAnyway, the stashing thing I want is a minor thing that should be easy\nto fix in git, (as is everything we're talking about here I think).\n\n-Carl\n"},{"id":"297303","messageId":"BAYC1-PASMTP117DBD278A79F6239D9DA1AEEA0@CEZ.ICE","threadId":"6919","inReplyTo":"455B64F7.9040506@gmx.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-15T22:28:34Z","receivedAt":"2006-11-15T22:28:34Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 20:05:27 +0100\nMarko Macek wrote:\n\n> I guess this is the reason that the GIT Tutorial for CVS/SVN users is talking about _cogito_ instead.\n> (which is very confusing for someone coming to _git_ home page, trying to learn git).\n\nIMHO this is really bad. Pasky runs the Git web site and feels\nthat Cogito comes hand in hand with Git. When I asked him about\nit he mentioned that Junio had approved. But it's very confusing\nto click a link that purports to show you how to use Git and get\nshown a bunch of Cogito stuff.\n\nGit is confusing enough for new users without \"Git\" and \"Cogito\"\nbeing mixed without comment on the Git webpage. At the very\nleast, the links should be changed to \"Cogito for CVS/SVN users\".\n\n"},{"id":"296831","messageId":"87r6w4s5ga.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"7vmz6sjtw8.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-15T22:36:21Z","receivedAt":"2006-11-15T22:36:21Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 13:13:11 -0800, Junio C Hamano wrote:\n> That is a very fine example, but I do not see why it is a\n> problem. I do not think the goal of Porcelain is to make it\n> totally unnecessary for users to know about the plumbing.\n\nIf not, then the promise of the porcelain fails. If cogito offers\n\"Here are 40 commands so you don't have to learn git's 140\" and then\nnext says \"Oh, and you'll still want to learn all those git commands\ntoo\", then its existence only makes the \"too much stuff to learn\"\nproblem worse, not better.\n\nBut I think you agree with me (for now) that fixing the git UI should\nnot involve creating a new primary command to replace \"git\".\n\n-Carl\n"},{"id":"295089","messageId":"87psbos4pb.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151339500.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-15T22:52:32Z","receivedAt":"2006-11-15T22:52:32Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 13:45:58 -0800 (PST), Linus Torvalds wrote:\n> On Wed, 15 Nov 2006, Carl Worth wrote:\n> >\n> > Well, one of the problems is that with current git I can teach, (and I\n> > have), that there's a conceptual:\n> >\n> > \tpull = fetch + merge\n> >\n> > But then shortly after I have to teach an interface notion:\n> >\n> > \tmerge = pull .\n>\n> This is why I would suggest teaching the _concept_ of the \"merge\", and not\n> the actual command.\n>\n> I don't think you should basically ever use the \"git merge\" command\n> itself, not in teaching, and not in real life.\n\nI think that's just and accident of git-merge having such a bad\nsyntax, (requiring a merge message, not using -m for that, requiring\ntwo heads instead of defaulting to current, etc.). So the result is\naccepting another bad syntax \"pull .\" for an operation that really is\nmerge.\n\n> Once you've explained the _concept_ of merging, you then introduce the\n> command to actually _execute_ the merge: it's \"git pull\".\n\nI think we'll be doing better when there is a stronger correlation\nbetween the concepts of the operations and the command names for\ncarrying them out.\n\nPlus, when I'm teaching \"fetch everything first, then manipulate it\nlocally\", (which is what I teach, since that's the only way I use\ngit), then the \".\" looks really out of place when I teach the 'merge'\ncommand. I end up saying, \"Oh, that's there because you could do the\nfetch and merge all in one step if you really wanted, but I never do\nthat.\".\n\nAnd that's because I _do_ teach fetch first, as you've suggested.\n\n> changes from both branches. So it's a _conceptual_ issue, and that's why I\n> said I think you should just totally gloss over the whole issue of \"git\n> merge\" syntax.\n\nThat doesn't work. I know I went looking at the git-merge\ndocumentation when I started to learn git. \"It can't really be this\nhard, can it?\" was my reaction to it. And then only after attending a\ntutorial did I learn that \"pull .\" is the way it's really done.\n\nThat's nothing more than a user-interface trap for new users, plain\nand simple.\n\nThe real fix is to stop glossing over git-merge and just give it a\nusable syntax.\n\n-Carl\n"},{"id":"295944","messageId":"20061115230252.GH24861@spearce.org","threadId":"6919","inReplyTo":"87psbos4pb.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-15T23:02:52Z","receivedAt":"2006-11-15T23:02:52Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Carl Worth wrote:\n> Plus, when I'm teaching \"fetch everything first, then manipulate it\n> locally\", (which is what I teach, since that's the only way I use\n> git), then the \".\" looks really out of place when I teach the 'merge'\n> command. I end up saying, \"Oh, that's there because you could do the\n> fetch and merge all in one step if you really wanted, but I never do\n> that.\".\n> \n> And that's because I _do_ teach fetch first, as you've suggested.\n\nDitto. In every way.\n\nI've taught the same fetch first, then merge strategy. Nobody I\nknow in meat-space pulls from a remote URL and merges in one shot;\nthey always fetch locally, look at the incoming changes, decide if\nits worthwhile/ok, *then* merge with \"git pull . branch\".\n\nThe \".\" looks out of place for everyone...\n\n-- \n"},{"id":"295383","messageId":"BAYC1-PASMTP0196D3AFDB259DEF356AF8AEEA0@CEZ.ICE","threadId":"6919","inReplyTo":"87psbos4pb.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-15T23:07:22Z","receivedAt":"2006-11-15T23:07:22Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 14:52:32 -0800\nCarl Worth wrote:\n\n> The real fix is to stop glossing over git-merge and just give it a\n> usable syntax.\n\nAgreed 100% There's just no good reason to hide the user level\nmerge command inside of pull.\n\n"},{"id":"296974","messageId":"20061115231542.GB25270@spearce.org","threadId":"6919","inReplyTo":"20061115180722.83ff8990.seanlkml@sympatico.ca","subject":"Re: Cleaning up git user-interface warts","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-15T23:15:42Z","receivedAt":"2006-11-15T23:15:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Sean wrote:\n> On Wed, 15 Nov 2006 14:52:32 -0800\n> Carl Worth wrote:\n> \n> > The real fix is to stop glossing over git-merge and just give it a\n> > usable syntax.\n> \n> Agreed 100% There's just no good reason to hide the user level\n> merge command inside of pull.\n\nSo what about making git-merge take a -m \"msg\" argument to supply\nthe commit message, in which case it does the current behavior\n(and thus git-pull needs to change to supply -m); and then make\ngit-merge without any -m parameter invoke \"git pull . $@\" ?\n\nA minor tweak to both apps, a minor breakage to git-merge, but one\nthat I think anyone who invokes it by hand today would find sane\n(using -m like we do elsewhere) and since the vintage of both\ngit-pull and git-merge should always match shouldn't break anyone\nwho uses git-pull today.\n\n-- \n"},{"id":"296604","messageId":"Pine.LNX.4.64.0611151523290.3349@woody.osdl.org","threadId":"6919","inReplyTo":"20061115230252.GH24861@spearce.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-15T23:33:43Z","receivedAt":"2006-11-15T23:33:43Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Nov 2006, Shawn Pearce wrote:\n> \n> I've taught the same fetch first, then merge strategy. Nobody I\n> know in meat-space pulls from a remote URL and merges in one shot;\n\nActually, with different people involved it's _much_ better to do it in \none shot.\n\nWhy? Because doing a separate \"fetch to local space\" + \"merge from local \nspace\" actually loses the information on what you are merging.\n\nIt's a lot more useful to have a merge message like\n\n\tMerge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6\n\nthan one like\n\n\tMerge branch 'for-linus'\n\nwhich is what you get if you fetched it first.\n\nOf course, in a situation like git itself, where most of the merges are \nstuff that Junio has had pending in his own tree ('maint' branch etc), \nthings are different. But in a system where people actually use separate \ntrees, there really is an advantage to consider the fundamental operation \nto be the \"pull\", not the \"merge\".\n\nAgain, the kernel really is more distributed than most projects, but this \nis another thing people should recognize: git has been designed for \"true \ndistributed development\". Not the \"fake\" kind. Not the \"I merge mainly my \nown branches\" kind of thing. Truly distributed.\n\nAnd in a truly distributed situation, \"pull\" is strictly more powerful \nthan a separate \"fetch\" + separate \"merge\".\n\nIn other words, an SCM that does \"pull\" is _better_ than an SCM that does \n\"merge\". You can implement \"merge\" as a special case of \"pull\" (which we \ndo), but you cannot conveniently do it the other way around without having \nto tie them together some other way (ie you could have a \"remember the \nlast place we fetched this branch from in order to tie the fetch and the \nmerge together\" - but please realize that that is exactly what \"pull\" \n_is_).\n\nSo I will generally do a \"git pull\" (possibly followed by a \"git reset \n--hard ORIG_HEAD\" if I decided it wasn't good) over a \"git fetch\" + \"git \nmerge\". Exactly because the \"pull\" operation is actually more powerful.\n\nMaybe people who aren't in my position don't always appreciate the _power_ \nof git. The reason \"merge\" is a second-class citizen is simply because IT \nSHOULD BE.\n\n"},{"id":"294640","messageId":"Pine.LNX.4.64.0611151905460.2591@xanadu.home","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151523290.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-16T00:08:11Z","receivedAt":"2006-11-16T00:08:11Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Linus Torvalds wrote:\n\n> \n> \n> On Wed, 15 Nov 2006, Shawn Pearce wrote:\n> > \n> > I've taught the same fetch first, then merge strategy. Nobody I\n> > know in meat-space pulls from a remote URL and merges in one shot;\n> \n> Actually, with different people involved it's _much_ better to do it in \n> one shot.\n> \n> Why? Because doing a separate \"fetch to local space\" + \"merge from local \n> space\" actually loses the information on what you are merging.\n> \n> It's a lot more useful to have a merge message like\n> \n> \tMerge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6\n> \n> than one like\n> \n> \tMerge branch 'for-linus'\n\nThat is an implementation detail that should be easily overcome once the \nnotion of tracking branch with URL attribute is implemented. Then it \nwill be really easy to notice whether the branch argument is a local \nbranch or a tracking branch with remote reference.\n\n\n"},{"id":"294645","messageId":"455BAF75.90506@xs4all.nl","threadId":"6919","inReplyTo":"7vbqn8o9st.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T00:23:17Z","receivedAt":"2006-11-16T00:23:17Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Junio C Hamano escreveu:\n> I still think in the long run you would be better off giving\n> separate names to Porcelains because I am sure you are going to\n> find the next command to \"fix\", you cannot suddenly change the\n\n > \"ig pull\", you can dismiss all the broken git-x Porcelain-ish by\n > saying \"Oh, git-x user-level commands had inconsistent semantics\n > and broken UI so do not use them anymore -- they are still there\n > only to help old timers transition. The user level commands are\n > now called ig-x and ig stands for improved git\".\n\n\nI think it would be good if there were different commands for \nporcelains. Not because fixing the current commands is too much work, \nbut rather because it would clarify the structure of git. GIT is a \n3-layer approach:\n\n - index+workdir+refs over\n - a DAG of commits over\n - a file based SHA1 database\n\nat first sight it is difficult to tell for each command on which layer \nit operates. It would help understanding GIT a lot if each layer got \nit's own command, eg.\n\n git - sha1 content db\n gic - sequences of commits\n giu - UI\n\n(Of course, these names are completely silly, but you get the idea)\n\n\n> I think get/put is much better than suddenly changing what pull\n> means and is shorter to type than x-load; I am Ok with them.\n> Although I think these words are tainted by SCCS, I do not think\n> anybody cares.\n\nthey're also tainted by darcs, but that's a minor problem, I suppose.\n\n\n-- \n"},{"id":"298281","messageId":"20061116011411.GB10512@thunk.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611150950170.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-11-16T01:14:11Z","receivedAt":"2006-11-16T01:14:11Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Nov 15, 2006 at 10:03:18AM -0800, Linus Torvalds wrote:\n> So the reason for using \"git pull\" is\n> \n> - bk did it that way, and like it or not, bk was the first usable \n> distributed system. hg is totally uninteresting.\n\nYes, \"bk pull\" had an implied merge. But, the reason why bk pull was\nnever really a problem with Bitkeeper is because it didn't really have\nsupport for multiple branches active within the same repository ---\nwhat Larry called \"lines of development\". Or rather, Larry started\ndown the path of implementing lines of development, and then never\nfully supported it, mainly because making it easy for people to use\nwas the tricky part. \n\nSo with Bitkeeper, with \"bk pull\" there was never any question about\nwhich branch (\"line of development\") you would be merging into after\ndoing a \"bk pull\", since there was only one LOD, and given that BK had\nthe rule that a within a LOD only one tip was allowed, a \"bk pull\"\n_had_ to do do a merge operation. \n\nThe moment you start supporting multiple unmerged tips in a repository\ni.e., branches, it raises the question, \"which branch should the pull\noperation merge onto\"? And git's answer, \"the current branch\", is\noften not the right one. *That's* why always doing a merge isn't\nalways the right answer, and so in the git world, people are told, use\n\"git fetch\" instead, and in the hg world, \"hg pull\" doesn't do the\nmerge. IMO, it's a fundamental result of the fact that both git and\nhg have chosen to support mulitple LOD's, whereas BK punted on the\nconcept.\n\nIf you are operating on your local development branch, the reality is\nthat merging is probably not the right answer in the general case,\nwhich is why the hg world have omitted doing the merge. And by\ntelling people, use \"git fetch\" instead, that's also an implicit\nadmission that merging onto the current branch is often not the Right\nThing.\n\nThe problem is that \"pull\" is a very evocative word, especially given\nthe existence \"push\", and so in the git world we are reduced to\ntelling people, \"you really don't want to use pull, trust me\". \n\nIs this a major issue? Not really; I can think of a number of other\nissues that make git hard to learn, and why hg has a more gentle\nlearning curve, and the \"don't use pull\" is probably a relatively\nminor annoyance in the grand scheme of things.\n\nIf people are looking for a simple way out, maybe it would be enough\nto have an option where if \"git pull\" is called from an interactive\nterminal, and the \"novice user\" option is enabled, \"git pull\" returns\na warning message, \"You probably want to use 'git fetch' instead; are\nyou sure?\" If people are saying that we shouldn't be teaching \"git\npull\" until fairly late in the game, maybe we should have a way of\ndiscouraging novices from using, simply because they they are used to\nseeing \"pull\" from other distributed SCM's.\n\n"},{"id":"297111","messageId":"455BBCE9.4050503@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611150950170.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T01:20:41Z","receivedAt":"2006-11-16T01:20:41Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Linus Torvalds escreveu:\n> - git itself has now done it that way for the last 18 months, and the \n> fact is, the people _complaining_ are a small subset of the people who \n> actually use git on a daily basis and don't complain.\n\n\nthat's not a good argument; the set of git users is a small subset of \nthose that looked at git, and dismissed it because they couldn't wrap \ntheir heads around it. It's worth trying to get those on board by \nfixing the annoying little issues that have popped up in this thread. \nThe technical base for GIT is excellent, and the only reason for not \nusing it is its arcane interface.\n\nA version control system is often only tangentially related to the real \nwork that needs to be done, so the incentive to learn it well is small, \n and a steep learning curve only makes it worse.\n\nFWIW, I regularly mess up with the differences between fetching, pulling \nand merging. In particular, having to do a two step process to get \nremote changes in,\n\n git pull url-to-server master:master\n ..error message about not being a fast-forward..\n\n git pull --update-head-ok url-to-server master:master\n ..still an error message about update not being a fast-forward..\n\n (sigh)\n\n git pull url-to-server master:scrap-branch\n\n git pull . scrap-branch:my-current-branch\n\n (make mental note of deleting scrap-branch)\n\n\n-- \n"},{"id":"294105","messageId":"ejgfjb$bm7$2@sea.gmane.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151111250.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Anand Kumria","fromEmail":"wildfire@progsoc.org","sentAt":"2006-11-16T01:40:59Z","receivedAt":"2006-11-16T01:40:59Z","isPatch":false,"sender":{"key":"wildfire@progsoc.org","avatar":null},"body":"On Wed, 15 Nov 2006 11:18:36 -0800, Linus Torvalds wrote:\n\n> On Wed, 15 Nov 2006, Andy Parkins wrote:\n>>\n>> On the one hand you're arguing that git syntax is easy to learn, and on the \n>> other that no one will be able to learn a new syntax just as easily.\n> \n> I'm saying that people who are new to git will _have_ to learn new \n> concepts ANYWAY.\n> \n> I don't think the naming is the hard part. \n\nIt isn't - the unexpectedness of what happens is.\n\nI've started by teaching how to do stuff locally, then \"pushing\" it out to\nothers (me). All the while being able to point out how this is either all\nlocal, or sends stuff (without any local modifications) to others.\n\nCome up to 'pull' and ere you have to point out that not only will you get\nthe remote changes but they are also merged into your repository. On the\nwrong branch?\n\nToo bad.\n\nThe problem with git-pull behaving illogically drove me to look at cogito\n(an aside, perhaps cg-throw should be the corrollary to cg-fetch?)\ninstead. Alas it has problems with a cogito branch not being something you\ncan mentally map back to a git branch.\n\n> But I bet people don't teach it that way. They _start_ by teaching \"pull\". \n> Right?\n\nNope.\n\nAnand\n"},{"id":"295613","messageId":"ejgg69$bm7$3@sea.gmane.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151524000.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Anand Kumria","fromEmail":"wildfire@progsoc.org","sentAt":"2006-11-16T01:51:05Z","receivedAt":"2006-11-16T01:51:05Z","isPatch":false,"sender":{"key":"wildfire@progsoc.org","avatar":null},"body":"On Wed, 15 Nov 2006 15:26:44 -0500, Nicolas Pitre wrote:\n\n> On Wed, 15 Nov 2006, Petr Baudis wrote:\n> \n>> On Wed, Nov 15, 2006 at 03:10:16AM CET, Junio C Hamano wrote:\n>> > You have to admit both pull and fetch have been contaminated\n>> > with loaded meanings from different backgrounds. I was talking\n>> > about killing the source of confusion in the longer term by\n>> > removing fetch/pull/push, so we are still on the same page.\n>> \n>> How was/is fetch contaminated?\n> \n> I think \"fetch\" is sane. Its only problem is a missing symetrical \n> counterpart verb, like \"get\" and \"put\".\n\n\"throw\" ?\n\nBut I think \"I'll just 'throw' this set of patches at you\" is a lot\nharshers sounding than \"I'll just 'push' this set of patches at you\".\n\nAnand\n"},{"id":"297631","messageId":"ejgg7l$3gb$1@sea.gmane.org","threadId":"6919","inReplyTo":"455BBCE9.4050503@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-16T01:53:08Z","receivedAt":"2006-11-16T01:53:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Han-Wen Nienhuys wrote:\n\n> FWIW, I regularly mess up with the differences between fetching, pulling \n> and merging.  In particular, having to do a two step process to get \n> remote changes in,\n> \n>    git pull url-to-server master:master\n>       ..error message about not being a fast-forward..\n> \n>    git pull --update-head-ok url-to-server master:master\n>       ..still an error message about update not being a fast-forward..\n\nWhat about:\n\n git pull --update-head-ok url-to-server +master:master\n\n(or --force, but be careful with that one)?\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294172","messageId":"7vhcx0gnbq.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"455BBCE9.4050503@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T02:03:21Z","receivedAt":"2006-11-16T02:03:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han-Wen Nienhuys writes:\n\n> FWIW, I regularly mess up with the differences between fetching,\n> pulling and merging. In particular, having to do a two step process\n> to get remote changes in,\n>\n> git pull url-to-server master:master\n> ..error message about not being a fast-forward..\n>\n> git pull --update-head-ok url-to-server master:master\n> ..still an error message about update not being a fast-forward..\n>\n> (sigh)\n\nSigh indeed.\n\nWhy don't you do the simple and obvious\n\n\tgit pull url master\n\nor \"git pull url\" if you already know the master is the branch\nyou are interested in.\n\nThe more advanced form of using tracking branches are there and\ndocumentation talks about them for completeness but that does\nnot mean you have to use it.\n"},{"id":"295989","messageId":"455BCD2B.6060603@xs4all.nl","threadId":"6919","inReplyTo":"7vhcx0gnbq.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T02:30:03Z","receivedAt":"2006-11-16T02:30:03Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Junio C Hamano escreveu:\n>> FWIW, I regularly mess up with the differences between fetching,\n>> pulling and merging. In particular, having to do a two step process\n>> to get remote changes in,\n>>\n>> git pull url-to-server master:master\n>> ..error message about not being a fast-forward..\n>>\n>> git pull --update-head-ok url-to-server master:master\n>> ..still an error message about update not being a fast-forward..\n>>\n>> (sigh)\n> \n> Sigh indeed.\n> \n> Why don't you do the simple and obvious\n> \n> \tgit pull url master\n\nIt is not all evident from the git-pull man-page that this is the \nobvious and most common usage.\n\n> or \"git pull url\" if you already know the master is the branch\n> you are interested in.\n\nBecause I usually replace verbose commands with shortcuts only when I \nunderstand exactly what the shortcut is.\n\nTo me it's very unlogical that\n\n master:current-branch\n\ndoesn't work, but\n\n master:\n\ndoes work, and does what I'd expect\n\n master:current-branch\n\nto do. Interestingly, doing\n\n pull ..url.. master:HEAD\n\nalso doesn't merge into the current branch, but rather creates a bogus \nrefs/heads/HEAD\n\nI use the remote:local syntax, because I started using GIT in scripted \ncompiles from copied branches of remote repositories. There the explicit \nremote:local statements are necessary because there is no default branch.\n\n-- \n"},{"id":"298742","messageId":"20061116024321.GP7201@pasky.or.cz","threadId":"6919","inReplyTo":"ejeq20$5hn$1@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-16T02:43:21Z","receivedAt":"2006-11-16T02:43:21Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 15, 2006 at 11:28:27AM CET, Jakub Narebski wrote:\n> Santi Béjar wrote:\n> \n> > On 11/15/06, Jakub Narebski wrote:\n> \n> >> You mean\n> >>\n> >> git merge git://repo.com/time_machine.git#branch\n> >>\n> >> don't you (perhaps with 'master' as default branch)?\n> > \n> > perhaps with remote 'HEAD' as default branch?\n> \n> No! HEAD might change without your notice, and you want to know\n> which branch you merge. With remotes the default could be first\n> branch in the pull/fetch list, but with bare URL...\n\nNo! If HEAD changed without your notice, it means that the remote\nrepository admin _wants_ you to start fetching another branch now.\nImagine a setup of these branches:\n\n\tphooey-1.2\tlegacy lineage\n\tphooey-2.0\tlast stable\n\tphooey-3.0\tcurrent development (no releases yet)\n\tphooey-4.0\tstash for futuristic functionality, heavily\n\t\t\texperimental\n\nIn this case, HEAD now points to phooey-3.0 but when it becomes stable,\nit would change to phooey-4.0.\n\nThe common practice of having 'master' pointing on whatever you\ncurrently have now and and \"cutting out\" the branches from it at random\ntimes is something heavily influenced by CVS where this is the only sane\nway of branching (the cutting out even hardcoded in numbering scheme).\nIn more advanced systems, you may want to be much more flexible wrt. this\n(note that I'm not saying you necessarily _should_ be).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> Actually, with different people involved it's _much_ better to do it in\n> one shot.\n>\n> Why? Because doing a separate \"fetch to local space\" + \"merge from local\n> space\" actually loses the information on what you are merging.\n>\n> It's a lot more useful to have a merge message like\n>\n> Merge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6\n>\n> than one like\n>\n> Merge branch 'for-linus'\n>\n> which is what you get if you fetched it first.\n\nFull ACK from a platform integrator's perspective. Local merge is\ngreat for trial runs but the history in a persistent branch should be\nas self-contained and self-explanatory as possible. It shouldn't\ndepend on what I name local tracking branches, which are just a\nconvenience so that I can still do trial runs when my connectivity is\nbroken.\n\nI don't have to manually log the _mechanical_origin_ of a given delta;\ngit does that for me, and mostly just DTRT when the same delta arrives\nvia several paths. When I use git pull from a remote branch (with or\nwithout an entry in remotes/heads, which for this purpose is just\nshorthand), I don't have to manually log what conflicts I have and\nhaven't resolved, either; I must have assimilated whatever I cared\nabout in the remote branch's history up to that point, because as long\nas there are things in that remote branch that I haven't decided how\nto handle, I stick to cherry-picking.\n\nObviously, fetch to local space is great (especially when you spend\nsome of your working hours behind a firewall that blocks outbound TCP\n9418). Fetch from local space is also great, when the local space you\nare fetching from reflects local work (such as a sync point and\nreconciliation of several upstream sources, which then needs to be\nported forward or back to the chosen core version for each platform).\nFetch from a local space that is just a tracker for remote work is not\ngreat, because it doesn't capture the editorial decision implied by a\nremote pull: I looked at what the remote branch had to offer as of\nthis date, systematically decided which bits did and didn't belong in\nthe branch to which I was pulling, and pulled.\n\nThe record of that pull becomes a first-class object because it's\nattached to an actual content delta in the target branch. So it\npropagates into branches that pull from it. Pulling this delta into\nanother branch is different from cherry-picking a feature delta; it\nimplies acceptance of the reconciliation and editorial work associated\nwith the merge in the source branch.\n\nComing from me, this is all rather theoretical, as I haven't been\nusing this particular tool for the purpose long enough to have an\nindependent opinion. But for what it's worth, the workflow Linus\ndescribes isn't just for the guy at the top of the pyramid.\n\nCheers,\n"},{"id":"297348","messageId":"Pine.LNX.4.64.0611151859370.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151905460.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T03:07:11Z","receivedAt":"2006-11-16T03:07:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Wed, 15 Nov 2006, Nicolas Pitre wrote:\n> \n> That is an implementation detail that should be easily overcome once the \n> notion of tracking branch with URL attribute is implemented.\n\nNope.\n\nI simply don't _have_ those branches.\n\nWhy? Because the kernel is _distributed_. There is no central place \n(certainly not my repository) that tracks all the possible branches that \nmight get merged.\n\nIn other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more \nsense to have a \"pull\" that fetches and merges, over something that \nfetches separately and then merges. Because in a truly distributed \nenvironment, you simply DO NOT HAVE static branches that you can associate \nwith particular sources.\n\nSee?\n\nAnd the thing is, I think the git design should be geared towards true \ndistribution. It should NOT be geared toward a fairly static set of \nbranches that all have a fairly static set of other repositories \nassociated with them. Can you see the difference?\n\nI'm personally convinced that one of the reasons people tend to use git in \na centralized manner is just a mental disease that has its roots in how \nthey used _other_ SCM's. I don't want git design to be polluted by such a \ncentralized notion.\n\nSo to repeat: you can always make \"pull\" boil down to \"pull from myself\" \n(aka just \"merge\"), but you can _not_ make \"fetch + merge\" boil down to \n\"pull\" without meking up extra state to track separately. In other words, \n\"pull\" really is the strictly more powerful operation.\n\n"},{"id":"296674","messageId":"20061116030728.GQ7201@pasky.or.cz","threadId":"6919","inReplyTo":"20061115172834.0a328154.seanlkml@sympatico.ca","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-16T03:07:28Z","receivedAt":"2006-11-16T03:07:28Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 15, 2006 at 11:28:34PM CET, Sean wrote:\n> Git is confusing enough for new users without \"Git\" and \"Cogito\"\n> being mixed without comment on the Git webpage. At the very\n> least, the links should be changed to \"Cogito for CVS/SVN users\".\n\nIt's not being mixed without comment, in the very first paragraph I'm\ntrying to explain what the difference is and why is Cogito used for\nintroduction to Git. I've tried to clear it up even more now.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Linus Torvalds escreveu:\n> > - git itself has now done it that way for the last 18 months, and the\n> > fact is, the people _complaining_ are a small subset of the people who\n> > actually use git on a daily basis and don't complain.\n> \n> \n> that's not a good argument; the set of git users is a small subset of those\n> that looked at git, and dismissed it because they couldn't wrap their heads\n> around it. \n\nAnd I've said this again, and I'll say it once more: that has basically \n_nothing_ to do with whether you spell \"pull\" as \"pull\" or \"merge\".\n\nThe reason people have trouble wrapping their heads around git is because \nthey have been braindamaged by CVS and SVN, and just don't understand the \nfairly fundamental new concepts and workflow.\n\nThat's totally different from then arguing about stupid naming issues.\n\nPeopel seem to believe that changign a few names or doing other totally \n_minimal_ UI changes would somehow magically make things understandable. I \nclaim that isn't so at all. The fact is, git is different from CVS and \nSVN, and git _has_ to be different from CVS and SVN. It has to be \ndifferent because the whole model of CVS and SVN is simpyl fundamentally \nBROKEN.\n\n> It's worth trying to get those on board by fixing the annoying\n> little issues that have popped up in this thread.\n\nI claim that those \"annoying little issues\" are totally made up by people \nwho had trouble wrapping their minds about git, and then make up reasons \nthat have nothing to do with reality for why that might be so.\n\nLet's face it, you could just alias \"merge\" to \"pull\", and it wouldn't \nreally change ANYTHING. You'd still have to learn the new model. \n\n"},{"id":"297938","messageId":"20061116032157.GR7201@pasky.or.cz","threadId":"6919","inReplyTo":"87r6w4s5ga.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-16T03:21:57Z","receivedAt":"2006-11-16T03:21:57Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 15, 2006 at 11:36:21PM CET, Carl Worth wrote:\n> On Wed, 15 Nov 2006 13:13:11 -0800, Junio C Hamano wrote:\n> > That is a very fine example, but I do not see why it is a\n> > problem. I do not think the goal of Porcelain is to make it\n> > totally unnecessary for users to know about the plumbing.\n> \n> If not, then the promise of the porcelain fails. If cogito offers\n> \"Here are 40 commands so you don't have to learn git's 140\" and then\n> next says \"Oh, and you'll still want to learn all those git commands\n> too\", then its existence only makes the \"too much stuff to learn\"\n> problem worse, not better.\n\nI didn't get this argument before either - why do you need to learn \"all\nthose git commands\" too? You'll never have to learn \"git add\" or even\n\"git commit\". If you want to pick specific git commands later (like \"git\nbisect\", which even seeks in a Cogito-compatible way), that's fine, go\nahead! But you by no means have to learn _other_ commands than those you\nneed. If you want to bisect, you have to learn no other Git commands\nthan \"git bisect\".\n\nAnother point is, if using _just_ _git_ requires you to learn \"all those\ngit commands too\" from git-commit-tree up (yes it does! if you want your\nauthorship information to be correct), something is wrong.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n> Junio C Hamano escreveu:\n>>...\n>> Sigh indeed.\n>>\n>> Why don't you do the simple and obvious\n>>\n>> \tgit pull url master\n>\n> It is not all evident from the git-pull man-page that this is the\n> obvious and most common usage.\n\nIn the git user poll a few months ago, many people recommended\n\"everyday git\" as a good cheat sheet, and indeed it does not\ntalk anything about directing the underlying git-fetch to\nmanipulate tracking branches by giving explicit refspec pairs to\ngit pull. You are obviously tripped by both the overeager\nmanpage (but manpage should strive to be complete so you cannot\nreally blame it) and less than optimally organized tutorial\nstyle documents.\n\nI myself do prefer, when learning a new tool, to use longhand\nuntil I understand the shorthand, but that attitude requires a\ntrue commitment to learn the tool, and most people do not go\nthat route. Tutorial style documents tend to give the commonly\nused shorthand first for that exact reason.\n\nShorthand to give only the branch name to fetch and merge\nimmediately without using a tracking branch is equivalent to\nlonghand \"branch:\" as you found out, so if that was what was\ndesired then people with the attitude \"before understanding what\nlonghand does I prefer using shorthand\" like myself and you\nwould have liked to learn \"git pull url branch:\" notation from\nTutorial. But I think we _are_ minority. People would not want\nto see that seemingly useless colon there.\n\n> To me it's very unlogical that\n>\n> master:current-branch\n>\n> doesn't work,\n\nThat shows that you did not understand what fetch does. Maybe\nyou do now, but a very natural consequence of directing fetch to\nupdate tracking branches with the colon notation is:\n\n - \"pull url master:master\", while on master, is almost always\n wrong and not something you would want to do, ever.\n\n \"fetch --update-head-ok url +master:master; reset --hard HEAD\"\n\n may make sense but never \"pull\".\n\n> I use the remote:local syntax, because I started using GIT in scripted\n> compiles from copied branches of remote repositories. There the\n> explicit remote:local statements are necessary because there is no\n> default branch.\n\nIf you perhaps wanted to ask \"is there a better way to do what\nI've been doing?\", then I am willing to think with you to come\nup with an answer. Unfortunately, however, I do not understand\nthe above paragraph, so I'd refrain from commenting on it in\nthis response.\n\n\n"},{"id":"298124","messageId":"7v7ixwgj2d.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"7vbqn8gjeo.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T03:35:22Z","receivedAt":"2006-11-16T03:35:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n(not changing what I said but editorial)\n> I myself do prefer, when learning a new tool, to use longhand\n> until I understand the shorthand, but that attitude requires a\n> true commitment to learn the tool, and most people do not go\n> that route. Tutorial style documents tend to give the commonly\n> used shorthand first for that exact reason.\n\nEh, sorry, \"prefer to use longhand until I understand what is\ngoing on before using the shorthand\" is what I wanted to say.\n\n> Shorthand to give only the branch name to fetch and merge\n> immediately without using a tracking branch is equivalent to\n> longhand \"branch:\" as you found out, so if that was what was\n> desired then people with the attitude \"before understanding what\n> longhand does I prefer using shorthand\" like myself and you\n\n\"prefer not using shorthand\", sorry again.\n\n> would have liked to learn \"git pull url branch:\" notation from\n> Tutorial. But I think we _are_ minority. People would not want\n> to see that seemingly useless colon there.\n"},{"id":"296644","messageId":"Pine.LNX.4.64.0611152228540.2591@xanadu.home","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151859370.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2006-11-16T03:43:58Z","receivedAt":"2006-11-16T03:43:58Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 15 Nov 2006, Linus Torvalds wrote:\n\n> \n> \n> On Wed, 15 Nov 2006, Nicolas Pitre wrote:\n> > \n> > That is an implementation detail that should be easily overcome once the \n> > notion of tracking branch with URL attribute is implemented.\n> \n> Nope.\n> \n> I simply don't _have_ those branches.\n> \n> Why? Because the kernel is _distributed_. There is no central place \n> (certainly not my repository) that tracks all the possible branches that \n> might get merged.\n> \n> In other words, I repeat: in a TRULY DISTRIBUTED ENVIRONMENT it makes more \n> sense to have a \"pull\" that fetches and merges, over something that \n> fetches separately and then merges.\n[...]\n\nOK fine. git-pull is there to stay and let's make sure it remains the \nsame.\n\nLet's see if, for example, git-merge can be made more useful in the mean \ntime for those evidently inferior people that would prefer an interface \nthat maps more closely to the actual operation that is being performed. \nAnd although I do understand what \"pull\" does, I think I should qualify \nmyself as one of those inferior people nevertheless since /pull . blah\" \nreally irritates me. OK I must be really dumb to let myself being \ndisturbed by such an insignificant detail... but apparently I'm not \nalone.\n\nBut I promise to never change the \"pull\" behavior if I ever attempt to \nfix the \"merge\" command for the inferior mortals as myself. All power \nto those with superior minds shall never be removed.\n\n;-)\n\n\n"},{"id":"297401","messageId":"20061116035338.GS7201@pasky.or.cz","threadId":"6919","inReplyTo":"200611150917.23756.andyparkins@gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-16T03:53:38Z","receivedAt":"2006-11-16T03:53:38Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 15, 2006 at 10:17:22AM CET, Andy Parkins wrote:\n> On Wednesday 2006 November 15 04:32, Nicolas Pitre wrote:\n> \n> > 3) remote branch handling should become more straight forward.\n> \n> I was completely confused by this origin/master/clone stuff when I started \n> with git. In hindsight, now I understand git a bit more, this is what I \n> would have liked:\n> \n> * Don't use the name \"origin\" twice. In fact, don't use it at all. In a \n> distributed system there is no such thing as a true origin.\n> \n> * .git/remotes/origin should be \".git/remotes/default\". \"origin\" is only \n> special because it is the default to push and pull - it's very nice to have a \n> default, but it should therefore be /called/ \"default\".\n\n But \"default\" is way too generic a name, it's much more confusing I\nthink. As the one guilty of inventing master and origin, I agree that\nthey are somewhat silly, but if I would have to pick which one to\nreplace with something \"better\", I'd much rather pick master.\n\n Yes, Git can operate in a completely distributed manner. People do use\nit as it. And there are also people that have no origin branch in their\nrepository. But the vast (overwhelming!) majority of people _does_ work\nin some kind of hierarchical setup, and for them origin does have a\nmeaning. And origin URL can even change over time!\n\n> * git-clone should really just be a small wrapper around\n> - git-init-db\n> - create .git/remotes/default\n> - maybe create specific .git/config\n> - git-fetch default\n> If git-clone does anything that can't be done with settings in the config \n> and the remotes/default file then it's wrong. The reason I say this is that \n> as soon as git-clone has special capabilities (like --shared, --local \n> and --reference) then you are prevented from doing magic with existing \n> repositories. For example; how do you create a repository that contains \n> branches from two other local repositories that have the objects hard linked?\n\n Here I think that modulo the lack of remotes support (which is not a\nfundamental thing here), the general setup of how Cogito does stuff is\nmuch more saner than the current Git mess. It does basically exactly\nwhat you've said above, and even the fetching itself is IMHO written\nmuch more cleanly than in Git. In an ideal world, Git would just take\nCogito's code here. :-)\n\n> While I'm writing wishes, I'd like to jump on Junio's integration with other \n> fetch-backends wish. I use git-svn, and it would be fantastic if I could \n> replace:\n> \n> git-svn init --id upstream/trunk svn://host/path/trunk\n> git-svn fetch --id upstream/trunk\n> git-svn init --id upstream/stable svn://host/path/branches/stable\n> git-svn fetch --id upstream/stable\n> \n> With a .git/remotes/svn\n> SVN-URL: svn://host/path\n> Pull: trunk:refs/remotes/upstream/trunk\n> Pull: branches/stable:refs/remotes/upstream/stable\n> and\n> git fetch svn\n> \n> Obviously, the syntax is just made up; but you get the idea. Even better, \n> would be if it could cope with my \"*\" syntax suggested above:\n> SVN-URL: svn://host/path\n> Pull: trunk:refs/remotes/upstream/trunk\n> Pull: branches/*:refs/remotes/upstream/*\n\n It shouldn't be hard to do at all. Have the porcelain call \"protocol\ndrivers\" based on protocol in some generic way, like\n/usr/lib/git/protocol/$proto.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n> Han-Wen Nienhuys writes:\n>\n>> Junio C Hamano escreveu:\n>>>...\n>>> Sigh indeed.\n>>>\n>>> Why don't you do the simple and obvious\n>>>\n>>> \tgit pull url master\n>>\n>> It is not all evident from the git-pull man-page that this is the\n>> obvious and most common usage.\n>\n> In the git user poll a few months ago, many people recommended\n> \"everyday git\" as a good cheat sheet, and indeed it does not\n> talk anything about ...\n\nSorry, I must have been very grumpy mood when I wrote the\nmessage (cf. Pasky's utterance on #git a few days ago). What I\nwrote was a bit incoherent, so here is an attempt to clarify.\n\nI should point out that the colon separated refspec pairs you\ncan give to \"pull\" was designed with considerable thought; it is\nnot a convenience hack that we give them to \"pull\" that \"fetches\nand merges\". Linus's and Michael's other messages in this\nthread may seem to be saying that using tracking branches is not\na kosher way to use git, but I do not think that is a correct\ninterpretation of their messages.\n\nThe workflow that does not use any tracking branches is the\nsimplest and truly distributed way as Linus says. The command\nrecommended in \"everyday git\" document:\n\n\tgit pull $url $branchname\n\nis the most natural way to express it, and simplest variant that\nyou do not have to say anything \"colon\" in it.\n\nHowever that does not mean it is a bad practice to use tracking\nbranches. Sometimes it is handy to be able to refer to what you\nfetched from the remote the last time, possibly which is what\nyou merged into your branch if that last fetch was done via \"git\npull\", so that you can later examine its history without your\nown development. For that purpose, you need to store what you\nfetched in your local refs/ namespace, and that is what tracking\nbranches are.\n\nThe workflow that fetches to tracking branches and then merges\nwithin local repository as two separate steps loses the true\norigin information (\"Merge branch 'foo'\" vs \"Merge branch 'foo'\nof git://git.bar.xz/foo.git\"). That's the reason why not just\n\"git fetch\" but also \"git pull\" take the colon separated refspec\npairs to direct git to update the tracking branches when \"pull\"\nhappenes. The longhands are cumbersome to type all the time,\nand we have shorthand, both to store URL: and Pull: lines in\nremotes/ hierarchy, and also $branchname alone is a shorthand\nfor saying \"${branchname}:\", meaning \"do not use a tracking\nbranch to store this\".\n\nSo you have options to use or not to use tracking branches.\nAfter cloning we happen to default to track all remote branches\nwith corresponding local tracking branches, but that is only\nbecause may people on the list wanted to make life easier to CVS\nmigrants where following mostly static set of branches is the\nnorm (\"set\" is the static part: I do not mean the branches stay\nstill) and we wanted to make it easier for them.\n\n"},{"id":"296174","messageId":"7vd57of2cv.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"20061116011411.GB10512@thunk.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T04:21:36Z","receivedAt":"2006-11-16T04:21:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> So with Bitkeeper, with \"bk pull\" there was never any question about\n> which branch (\"line of development\") you would be merging into after\n> doing a \"bk pull\", since there was only one LOD, and given that BK had\n> the rule that a within a LOD only one tip was allowed, a \"bk pull\"\n> _had_ to do do a merge operation. \n\nI've never used Bk and I really appreciate your comments here.\n\n> If you are operating on your local development branch, the reality is\n> that merging is probably not the right answer in the general case,\n\nI agree, but I wonder why you are pulling/fetching (with or\nwithout merge) if you are operating on your local development\nbranch (implying that you are in the middle of something else).\n\n> ... And by\n> telling people, use \"git fetch\" instead, that's also an implicit\n> admission that merging onto the current branch is often not the Right\n> Thing.\n>\n> The problem is that \"pull\" is a very evocative word, especially given\n> the existence \"push\", and so in the git world we are reduced to\n> telling people, \"you really don't want to use pull, trust me\". \n\nI would rather say \"use 'git branch' to make sure if you are\nready to merge\". Who teaches not to use \"git pull\"?\n\n> If people are looking for a simple way out, maybe it would be enough\n> to have an option where if \"git pull\" is called from an interactive\n> terminal, and the \"novice user\" option is enabled, \"git pull\" returns\n> a warning message,\n\nI have to disagree with this. In the simplest CVS-like central\nrepository with single branch setup in which many \"novice users\"\nstart out with, there is almost no need for \"git fetch\" nor\ntracking branch. You pull, resolve conflicts, attempt to push\nback, perhaps gets \"oh, no fast forward somebody pushed first\",\npull again, then push back. So I am not sure where \"you really\ndo not want to use pull. trust me\" comes from.\n\nIt is a different story for people who _know_ git enough to know\nwhat is going on. They may be using multiple branches and\ninteracting with multiple remote branches, and there are times\nyou would want fetch and there are other times you would want\npull. But for them, I do think the suggestion would never end\nwith \"trust me\" -- they would understand what the differences\nare.\n\n\n\n"},{"id":"296023","messageId":"20061116042639.GA23026@thunk.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151226590.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2006-11-16T04:26:39Z","receivedAt":"2006-11-16T04:26:39Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:\n> And yes, this is why you should NOT try to use the same naming as \"hg\", \n> for example. Last I saw, hg still didn't even have local branches, To \n> mercurial, repository == branch, and that's it. It was what I came from \n> too, and I used to argue for using git that way too. I've since seen the \n> error of my ways, and git is simply BETTER. \n\nActually, that's not true. Mercurial has local branches, just as git\ndoes. Some people choose not to *use* this particular feature, and\nuse the BK style repository == branch, but that's mainly because it's\nconceptually easy for them, and a number of BK refugees are very\nhappily using Hg. \n\nIt's probably because of the BK refugee population that after you do\nan hg pull, it will warn you that you need to do an \"hg update\" in\norder to merge the working directory up to the latest version that was\njust pulled --- and this change was made precisely because Hg supports\nlocal branches, and merging with the current branch isn't always the\nright thing, unlike with BK.\n\n> And the concept of local branches is exactly _why_ you have to have \n> separate \"fetch\" and \"pull\", but why you do _not_ need a separate \"merge\" \n> (because \"pull .\" does it for you).\n\nIt's just that the semantics are different, and many developers have\nto use multiple DSCM's, depending on what project they happen to be\ndeveloping on. So the reality is that there are people who have to\nuse bzr, git, and hg, all at the same time. And while eventually\nnewbies will figure out and remember that \"git pull .\" == \"merge\", the\nnaming is simply confusing, that's all. (What does \"pull\" have to do\nwith \"merge\"? It's not at all obvious.) \n\nFor somoene who uses git full-time, and to the exclusion of all other\nsystems, I'm sure it's not a problem at all.\n\t\n"},{"id":"296117","messageId":"20061116043050.GU7201@pasky.or.cz","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611150950170.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-16T04:30:50Z","receivedAt":"2006-11-16T04:30:50Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Wed, Nov 15, 2006 at 07:03:18PM CET, Linus Torvalds wrote:\n> If you think \"pull\" is confusing, I can guarantee you that _changing_ the \n> name is a hell of a lot more confusing. In fact, I think a lot of the \n> confusion comes from cogito, not from git - the fact that cogito used \n> different names and different syntax was a mistake, I think.\n\n I would agree that having \"pull\" mean something different in Cogito\nthan in Git was a bad idea (explanation: historically, for some period\nof time Cogito had cg-pull which meant the same as cg-fetch or hg pull;\nlater it got renamed to cg-fetch). But I'm also happy that Cogito just\ndoes not use the \"pull\" expression at all currently: \"updating\" seems to\nbe a clear and unloaded enough concept for new people. Pull is really\n_very_ confusing, with it meaning something different (but not different\nenough) in _all_ other systems but BK (which is basically irrelevant\nnowadays).\n\n That said, I agree with your argument that changing it in Git now\nmight just result in more confusion. I'm just trying to explain Cogito's\nchoice here, and I believe it does no good nor harm to Core Git if it\njust uses different name for the concept and avoids the original name at\nall (except explaining in the docs that updating in Cogito is what\npulling is in Git).\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Commenting on the messages in this thread:\n> \n> - \"resolve / resolved\" are both confusing, when you are talking\n> about \"mark-resolved\" operation.\n\nWell that's what \"resolved\" is saying. But speaking of which, it took me\n_weeks_ of regular (though not extensive) usage to train my fingers to\nwrite \"stg resolved\" and not \"stg resolve\".\n\n> - \"pull/push/fetch\" have undesired confusion depending on where\n> people learned the term. I'd perhaps vote for replacing\n> fetch with download and push with upload.\n\nIt's too long. :-(\n\nI think if some people have a real problem with something it's \"pull\",\nnot push or fetch. Without \"pull\" name, there's no confusion about\nmerging or not merging; and without it, there's also no confusion about\n\"push\" and the fetch/push duality. I'm not saying that this is enough an\nargument to ditch pull from Git at this point.\n\n> - I think it would be sensible to make remote tracking branches\n> less visible. For example:\n> \n> \tgit diff origin\n> \n> where origin is the shorthand for your upstream (e.g. you\n> have .git/remotes/origin that records the URL and the branch\n> you are tracking) should be easier to understand than\n> \n> \tgit diff remotes/origin/HEAD\n> \n> The latter is an implementation detail.\n\nHmm, wait. I didn't start using refs/remotes/ yet for obvious reasons,\nbut wasn't it generally agreed when implementing them that what you\nwrote above would work? (That a ref not found in refs/{heads,tags}/ is\nlooked up in remotes and if it's a directory, /HEAD is appended.) So it\ndoesn't for some reason?\n\n> I could imagine we might even want to allow\n> \n> \tgit diff origin#next\n> \n> to name the branch of the remote repository. The notion of\n> \"where the tips of remote repository's branches are\" is\n> probably be updated by \"git download\" (in other words, the\n> above \"git diff\" does not automatically initiate network\n> transfer).\n\nYes, that little syntax extension would be cute to have.\n\n> Of course, it could even be \"cg\" ;-).\n\nSo, here is an arbitrary list of random reasons why cg commands are not\npart of git yet:\n\n(i) Naming issues. Example: \"pull\" vs. \"update\".\n\n(ii) Namespace issues. Big selling point of Cogito is that it's\n_simple_. A very important part of that is that your command set is\nlimited, so that even someone who wants to fully grok Cogito is not\noverwhelmed and has just few commands in front of him. I think we're\ndoing pretty good here, and I very carefully weight adding another\ncommand to the set (I'm actually pondering removing some now). The\nsimilar applies to actual commands' usage, though certainly not so\nheavily; and there are few warts here.\n\nBut overally, I think this point is pretty much unsolvable and this is\nwhere I actually think the main \"incompatibleness\" of Cogito and Git\nwith its free mix of high- and mid- and low- level commands lies. I\ndon't think the thread provided any solution to this either.\n\n(ii) Behaviour issues. Example: Cogito tries to deal with uncommitted\nlocal changes in your repository when doing stuff. It didn't shine at it\nbefore recent improvements (post-v0.18), but it tried to preserve your\nlocal uncommitted changes during various operations (merging,\nfast-forwarding, switching branches, seeking, ...). I think historically\nGit's stance to this was negative (it'd rather block the operation), I'm\nnot sure what the current situation is, though.\n\n(iii) Output format issues. Example: \"status\" in Git and Cogito\nhas a completely different format in both. I'm a die-hard fan of\nCogito's format but there're surely die-hard fans of Git's.\n\n(iv) Control issues. I'm reluctant to give up a final word on how the UI\nlooks like, mostly for the reason of enforcing (ii) and proper\ndocumentation. But this is not a blocker point.\n\n(v) Library issues. Cogito has a pretty neat shell library which it\nprices; but that could be carried around. Also, Cogito requires\n/bin/bash, but mostly for performance reasons (using builtins instead of\nforking for external commands at some points); Git has the advantage of\nsimply putting that part in C, which is though something I should've\nbeen doing more frequently too.\n\n(vi) Coding issues. This is probably very subjective, but a blocker for\nme. I have no issues about C here, but about the shell part of Git.\nWell, how to say it... It's just fundamentally incompatible with me. I\n*could* do things in/with it, but it's certainly something I wouldn't\n_enjoy_ doing _at all_, on a deep level. I think the current shell code\nis really hard to read, the ancient constructs are frequently strange at\nbest, etc. It's surely fine code at functional level and there'll be\npeople who hate _my_ style of coding and my shell code which isn't\nperfect either, but it's just how it is with me.\n\n\nNow, it would be absolutely awesome if we could start to bridge at least\nsome of these points, shuffle some functionality around and overally\nreduce the code duplication, increase features count and improve general\nlevel of world happiness.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Marko Macek writes:\n> \n>> For people switching from CVS and SVN it would be much better if the\n>> index was hidden behind the scenes by using different defaults:\n>>\n>> git-commit -a\n>> git-status -a\n>> git-diff HEAD\n>>\n>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before\n>> you make the first commit. Perhaps this should be special cased.\n> \n> That's only a _bug_ in your implementation of the synonym for\n> \"svn diff\" which blindly used \"git diff HEAD\".\n\n\nMy \"implementation\" is taken from git-diff man page. It seems obvious\nthat the situation before the first commit is just a special case if \nwe consider git-diff to be Porcelain (which I do).\n\n \n> This \"there is no HEAD yet\" is not related to the index, but I\n\nI agree, this is a separate issue.\n\n"},{"id":"296881","messageId":"20061116075153.GA29363@tigerwolf.bri.st.com","threadId":"6919","inReplyTo":"20061115231542.GB25270@spearce.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Richard CURNOW","fromEmail":"richard.curnow@st.com","sentAt":"2006-11-16T07:51:53Z","receivedAt":"2006-11-16T07:51:53Z","isPatch":false,"sender":{"key":"richard.curnow@st.com","avatar":null},"body":"* Shawn Pearce [2006-11-15]:\n> \n> So what about making git-merge take a -m \"msg\" argument to supply\n> the commit message, in which case it does the current behavior\n> (and thus git-pull needs to change to supply -m); and then make\n> git-merge without any -m parameter invoke \"git pull . $@\" ?\n\nSounds good to me.\n\nWhen I'm merging in my own projects, I currently always use merge\n(possibly preceded by fetch) rather than pull. Why? Because I don't\nwant my history full of commit messages like\n\nMerge branch \"trial_hack\" from \"../scratch_dir_with_silly_name\"\n\nIn contrast to Linus's case of wanting to record where the remote merge\ncame from, I expressly don't want to record that - I want the merge\ncommit to describe conceptually what was being merged with what.\n\nOK, I could use probably use pull with --no-commit, but I've already\ntrained my fingers to type out the merge syntax. They'd be happier with\n'git merge -m \"Merge feature foo with fixes for bar\" bar\" though.\n"},{"id":"296940","messageId":"200611161109.13883.robin.rosenberg.lists@dewire.com","threadId":"6919","inReplyTo":"20061116032157.GR7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2006-11-16T10:09:13Z","receivedAt":"2006-11-16T10:09:13Z","isPatch":false,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"torsdag 16 november 2006 04:21 skrev Petr Baudis:\n> Another point is, if using _just_ _git_ requires you to learn \"all those\n> git commands too\" from git-commit-tree up (yes it does! if you want your\n> authorship information to be correct), something is wrong.\n\nWhen/why do I need git-commit-tree? Isn't git-commit enough?\n\n"},{"id":"298020","messageId":"7vejs3d6nb.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151908130.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T10:31:52Z","receivedAt":"2006-11-16T10:31:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> And I've said this again, and I'll say it once more: that has basically \n> _nothing_ to do with whether you spell \"pull\" as \"pull\" or \"merge\".\n>\n> The reason people have trouble wrapping their heads around git is because \n> they have been braindamaged by CVS and SVN, and just don't understand the \n> fairly fundamental new concepts and workflow.\n> ...\n> Let's face it, you could just alias \"merge\" to \"pull\", and it wouldn't \n> really change ANYTHING. You'd still have to learn the new model. \n\nI had a bit different feeling about yesterday's discussion\nmyself.\n\nIf somebody uses git like you do in \"truly distributed way\", the\ncurrent pull behaviour and pull being an operational mirror to\npush are natural consequence of the model and concepts, and\nthere is nothing to fix (modulo \"the default merge source per\nbranch\" should be made easier to use). Renaming the pull to\nmerge would not make it any easier to use unless the underlying\nmodel is understood, and I fully agree with you on that.\n\nBut for people working in a project organized around central\nrepository in the CVS/SVN fashion, the workflow is quite\ndifferent. CVS does not even let you \"fetch\" without either\nmerging (co) or throwing away your work (co -C), and we already\ndo support that model with:\n\n\tgit clone\n git pull\n work work work; git commit\n git push\n : oops not fast forward?\n git pull\n resolve work; git commit\n\tgit push\n\nwithout ever using a local branch, any tracking branch, nor\nuse of git-fetch. So we do support both extremes (\"truly\ndistributed\" and \"not distributed at all\") reasonably well.\n\nThe trouble starts when the users hear about this wonderful\n\"distributed\" stuff git offers, and try to use it without\nunderstanding the key concepts. People tend to learn by doing\nand there is a leap the user need to make because now they need\nto understand branched development, branches and fetching like\nyou explained if they want to use git the same way as you do.\nOnce they understand them, then the current set of tools offer\nthem a simple and very straightforward user interface (the tools\ndirectly reflect the concepts and it is straightforward only\nbecause we are talking about users who understood the concepts).\n\nBut we have to admit that this leap may rather be difficult for\npeople who are used to other models. Telling them that our\nmodel is different and it is different for a good reason does\nnot change the fact that the more different something is, the\nmore difficult to learn it.\n\nI suspect that there could be a way to use git, not like you or\nI do. Our workflows are already quite different (e.g. you\nalmost never do topic branch merge yourself in your repository,\nbut I have abundance of them). There is no reason to think\nthere won't be other workflows that are suitable for other\npeople. Some workflows might be classified less distributed and\ninferiour compared to the \"truly git way\" from \"truly\ndistributed is the point of git\" point of view, but nevertheless\ncould be \"good enough\" for those people. In other words, a\nworkflow that is a bit more advanced than just a single trunk\nCVS/SVN usage could still take advantage of some of the features\nto support distributed development model git has, while not\ntaking full advantage of truly distributed nature of git.\n\nI think the complaints in the yesterday's discussion are mostly\nabout frustration that, while we have a reasonable support for\nthe both extremes, we do not either know what that middle ground\nworkflow is, or even if we know what that is, we do not support\nit very well.\n\nAnd I am not opposed to people exploring what that different\nworkflow would be, and while they do so if they come up with a\nset of commands (get/put perhaps) to suppor that slightly\ndifferent workflow, that would be a very good thing.\n\nAdd foreign SCM importers in the mix and the situation becomes\nmore difficult and interesting. cvsimport mostly works and\nquacks like git-fetch with set of tracking branches, which I\nthink is the right model for the importers, and would integrate\nwell with the current set of tools. I believe svnimport is the\nsame way. But I do not know about git-svn.\n"},{"id":"296613","messageId":"7v1wo3d6g4.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"455C0033.2020309@gmx.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T10:36:11Z","receivedAt":"2006-11-16T10:36:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marko Macek writes:\n\n>>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before\n>>> you make the first commit. Perhaps this should be special cased.\n>>\n>> That's only a _bug_ in your implementation of the synonym for\n>> \"svn diff\" which blindly used \"git diff HEAD\".\n>\n> My \"implementation\" is taken from git-diff man page. It seems obvious\n> that the situation before the first commit is just a special case if\n> we consider git-diff to be Porcelain (which I do).\n\nYes, \"git diff\" is a Porcelain. No question about it.\n\nI do not consider the current behaviour of \"git diff HEAD\" that\ncomplains instead of giving runs of \"foo is a new file and no\ndiff is available for it\" a bug; you asked for diff from some\ncommit but the commit you gave was bogus (does not exist yet).\nBut if you feel strongly about it, it should be trivial to\nspecial case the yet-to-be-born HEAD case and run the\nequilvalent of:\n\n\tgit ls-files | sed -e 's/$/ is a new file, no diff is available./'\n\nin such a case. Or you could even go fancier and do an\nequivalent of:\n\n\tgit ls-files |\n while read path\n do\n\t\tl=`wc -l <\"$path\"`\n \techo \"diff --git a/$path b/$path\"\n echo \"--- a/$path\"\n echo \"--- b/$path\"\n echo \"@@ -0,0 +1,$l @@\"\n sed -e 's/^/+/' <\"$path\"\n\tdone\n\nand you can claim that it makes it consistent with the case\nwhere you already have commits.\n\nBut I happen to think that consistency is only of academic\ninterest. After all, how often would one create a true \"root\"\ncommit? We are not talking about creating a new repository that\nstarts its life as a clone of something else, but a truly empty\none in which the initial commit is made. And how often would\none want to view \"diff\" from void while preparing for that\ninitial commit? Both that low frequency _and_ general\nuselessness of the output from either of the above shell\nscripts, would it be worth \"fixing\" it?\n\nI do not think it adds any real practical value, and does not\neven have much to do with being user friendly. I would put it\nin the \"when somebody is really bored and has nothing better to\ndo, then this _could_ be done\" category.\n"},{"id":"294674","messageId":"455C412D.1030408@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151908130.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T10:45:01Z","receivedAt":"2006-11-16T10:45:01Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Linus Torvalds escreveu:\n>>> - git itself has now done it that way for the last 18 months, and the\n>>> fact is, the people _complaining_ are a small subset of the people who\n>>> actually use git on a daily basis and don't complain.\n>>\n>> that's not a good argument; the set of git users is a small subset of those\n>> that looked at git, and dismissed it because they couldn't wrap their heads\n>> around it. \n> \n> And I've said this again, and I'll say it once more: that has basically \n> _nothing_ to do with whether you spell \"pull\" as \"pull\" or \"merge\".\n> \n> The reason people have trouble wrapping their heads around git is because \n> they have been braindamaged by CVS and SVN, and just don't understand the \n> fairly fundamental new concepts and workflow.\n\n > I claim that those \"annoying little issues\" are totally made up by\n > people\n > who had trouble wrapping their minds about git, and then make up\n > reasons\n > that have nothing to do with reality for why that might be so.\n\nLet me put this more personally: I continue to be bitten by stupid \nnaming issues, and the myriad of little mostly non-orthogonal commands.\nMy head is doing just fine otherwise, and has no problems wrapping it \naround the core of GIT. I've also used Darcs for almost a year. Darcs, \nwhich is much less overwhelming.\n\nThis is not about CVS or SVN, so don't put them up as a strawman.\nIf you want to argue that my brain is warped, use other distributed VCs \nas an example.\n\nThe following\n\n mkdir x y\n cd x\n hg init\n echo hoi > bla\n hg add\n hg commit -m 'yes, I am also too stupid to refuse explicit empty \ncommit messages'\n cd ../y\n hg init\n hg pull ../x\n\npretty much works the same in Darcs, bzr and mercurial.\n\nWith GIT, this is what happens\n\n[hanwen@haring y]$ git pull ../x\nfatal: Needed a single revision\nPulling into a black hole?\n\n[hanwen@haring y]$ git fetch ../x\nwarning: no common commits\nremote: Generating pack...\nDone counting 3 objects.\nDeltifying 3 objects.\n 100% (3/3) done\nTotal 3, wremote: ritten 3 (delta 0), reused 0 (delta 0)\nUnpacking 3 objects\n 100% (3/3) done\n\n[hanwen@haring y]$ git checkout\nfatal: ambiguous argument 'HEAD': unknown revision or path not in the \nworking tree.\nUse '--' to separate paths from revisions\nfatal: Not a valid object name HEAD\n\n[hanwen@haring y]$ git branch master\nfatal: Needed a single revision\n\nat this point, I resort to adding a bogus commit and/or editing \n.git/HEAD by hand. I'm sure there is a saner way of doing it, but I \nstill haven't found out what it is.\n\nThis might not be typical GIT use, but it does show the typical GIT user \nexperience, at least mine.\n\nIf you want to have another example of how not to design a \nuser-interface, try the above on Monotone.\n\n> That's totally different from then arguing about stupid naming issues.\n> \n> Peopel seem to believe that changign a few names or doing other totally \n> _minimal_ UI changes would somehow magically make things understandable. I \n> claim that isn't so at all. The fact is, git is different from CVS and \n> SVN, and git _has_ to be different from CVS and SVN. It has to be \n> different because the whole model of CVS and SVN is simpyl fundamentally \n> BROKEN.\n> \n>> It's worth trying to get those on board by fixing the annoying\n>> little issues that have popped up in this thread.\n> \n> \n> Let's face it, you could just alias \"merge\" to \"pull\", and it wouldn't \n> really change ANYTHING.\n\nI don't want ANYTHING to really change, I just want a sane interface to it.\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"296182","messageId":"7vodr7brfp.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"20061116051240.GV7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T10:45:46Z","receivedAt":"2006-11-16T10:45:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> (v) Library issues...\n> Git has the advantage of\n> simply putting that part in C, which is though something I should've\n> been doing more frequently too.\n\nIt should be stressed that git-core plumbing written in C is not\njust for git Porcelain-ish, and it will continue to be shared\nservice. We would add core support for what Porcelains need and\nwe would try hard to keep them generic enough so that other\nPorcelains can use them. Keeping the core and Porcelain-ish in\nthe same project has made it easier to keep them in sync and to\nfind and add missing features that would benefit Porcelains (not\nlimited to git Porcelain-ish). But that should not be mistaken\nas plumbing somehow belongs more to git Porcelain-ish than to\nCogito or others.\n\nI also think you should take credit for some core improvements\nyou did yourself (e.g \"ls-files -t\" format was originally added\nfor the sole purpose of helping Cogito, but now others use it,\ntoo).\n"},{"id":"294237","messageId":"7v7ixvbq80.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"455C412D.1030408@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T11:11:59Z","receivedAt":"2006-11-16T11:11:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han-Wen Nienhuys writes:\n\nYou claim it is _an interface_ issue but it is not.\n\n> With GIT, this is what happens\n>\n> [hanwen@haring y]$ git pull ../x\n> fatal: Needed a single revision\n> Pulling into a black hole?\n\nYou asked it to fetch from the neighbour repository and merge it\ninto your current branch which does not exist (I presume that\nyou omitted to describe what you did in directory y/ and I am\nassuming you did \"mkdir y && cd y && git initdb\" and nothing\nelse). You are pulling into a black hole.\n\n> [hanwen@haring y]$ git fetch ../x\n>...\n> [hanwen@haring y]$ git checkout\n\nYou fetched without telling it in which tracking branch to store\nwhat you fetched, and as a result your HEAD is not updated, so\nyour current branch still does not exist. A failure from\nchecking out nothingness is not an interface issue; expectation\nfor it to work is a concept level issue.\n\n> [hanwen@haring y]$ git branch master\n> fatal: Needed a single revision\n\nYou are not at any commit yet and you try to create a branch?\n\nOf course, the \"right\" (in some sense of the word) thing is to\ndo \"git clone x y\" in the parent directory, without creating y\nupfront.\n\nIf you have an empty y to begin with, then you can do this:\n\n\t$ git fetch ../x :origin\n $ git reset --hard origin\n\nwhich would mirror a part of what \"git clone\" would have done\nfor you. It copies from the other repository, stores the tip in\nyour tracking branch called \"origin\", and make your HEAD to be\nthe same as origin. After these two commands, you would have\ntwo branches, origin and master, and you will be on master.\n\nYou can name 'origin' any way you want. You might want to name\nit 'x' to make it clear (to yourself) that it is used to track\nwhat will happen in the neighboring repository 'x'. Also, you\nwould most likely be fetching and merging from the same ../x\nfrom now on, so it might be handy to set up the remotes for it:\n\n\t$ cat >.git/remotes/x <> Let's face it, you could just alias \"merge\" to \"pull\", and it\n>> wouldn't really change ANYTHING.\n>\n> I don't want ANYTHING to really change, I just want a sane interface to it.\n\nI agree that you do not want to change anything. You just\nneeded a bit of handholding, because you deviated from the\ncookbook usage, to correct your course.\n\n\n\n"},{"id":"298676","messageId":"8764dflj5o.fsf@wine.dyndns.org","threadId":"6919","inReplyTo":"7vd57of2cv.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2006-11-16T11:34:27Z","receivedAt":"2006-11-16T11:34:27Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Junio C Hamano writes:\n\n> I would rather say \"use 'git branch' to make sure if you are\n> ready to merge\". Who teaches not to use \"git pull\"?\n\nWe do that for Wine. The problem is that we recommend using git-rebase\nto make it easier for occasional developers to keep a clean history,\nand rebase and pull interfere badly.\n\nThe result is that we recommend always using fetch+rebase to keep up\nto date, but this is confusing many people too, because git-fetch\nappears to do a lot of work yet leaves the working tree completely\nunchanged, and git-rebase doesn't do anything (since in most cases\nthey don't have commits to rebase) but has an apparently magical\nside-effect of updating the working tree.\n\nIdeally it should be possible to have git-rebase do the right thing\neven if the branch has been merged into; then we could tell people to\nalways use git-pull, and when they get confused by seeing merges in\ntheir history have them do a git-rebase to clean things up.\n\n-- \nAlexandre Julliard\n"},{"id":"295041","messageId":"455C4D1B.1040002@op5.se","threadId":"6919","inReplyTo":"f2b55d220611151902v794edd77i9f76815e4b03a966@mail.gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-11-16T11:35:55Z","receivedAt":"2006-11-16T11:35:55Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Michael K. Edwards wrote:\n> On 11/15/06, Linus Torvalds wrote:\n>> Actually, with different people involved it's _much_ better to do it in\n>> one shot.\n>>\n>> Why? Because doing a separate \"fetch to local space\" + \"merge from local\n>> space\" actually loses the information on what you are merging.\n>>\n>> It's a lot more useful to have a merge message like\n>>\n>> Merge branch 'for-linus' of \n>> git://one.firstfloor.org/home/andi/git/linux-2.6\n>>\n>> than one like\n>>\n>> Merge branch 'for-linus'\n>>\n>> which is what you get if you fetched it first.\n> \n> Full ACK from a platform integrator's perspective. Local merge is\n> great for trial runs but the history in a persistent branch should be\n> as self-contained and self-explanatory as possible. It shouldn't\n> depend on what I name local tracking branches, which are just a\n> convenience so that I can still do trial runs when my connectivity is\n> broken.\n> \n\n[...]\n\n> \n> Coming from me, this is all rather theoretical, as I haven't been\n> using this particular tool for the purpose long enough to have an\n> independent opinion. But for what it's worth, the workflow Linus\n> describes isn't just for the guy at the top of the pyramid.\n> \n\nI think it's unfortunate that git was originally written by Linus, since \nhe so obviously is \"the guy at the top of the pyramid\" in many more \nsenses than just \"Linus said this and that patch was OK to commit\", \nsince git was designed to work like king Arthur's round table; \"Linus is \nin the same circle as me, so ofcourse we help each other out\".\n\nAll suggestions I've been reading about tracking branches, \nseparate-remotes and whatnot have their merit. If any of it gets \nimplemented, I'd still like to be able to do one-shot pulls from remote \nrepos *without* creating specific tracking branches for it. It's \nextremely useful to fetch other peoples topic-branches into my own \n\"master\" (or topic-branch) when I trust their changes to be good. Please \nconsider that when you're hacking away on whatever changes to do.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"294886","messageId":"455C5079.3010701@op5.se","threadId":"6919","inReplyTo":"20061116042639.GA23026@thunk.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-11-16T11:50:17Z","receivedAt":"2006-11-16T11:50:17Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Theodore Tso wrote:\n> On Wed, Nov 15, 2006 at 12:40:43PM -0800, Linus Torvalds wrote:\n>> And yes, this is why you should NOT try to use the same naming as \"hg\", \n>> for example. Last I saw, hg still didn't even have local branches, To \n>> mercurial, repository == branch, and that's it. It was what I came from \n>> too, and I used to argue for using git that way too. I've since seen the \n>> error of my ways, and git is simply BETTER. \n> \n> Actually, that's not true. Mercurial has local branches, just as git\n> does. Some people choose not to *use* this particular feature, and\n> use the BK style repository == branch, but that's mainly because it's\n> conceptually easy for them, and a number of BK refugees are very\n> happily using Hg. \n> \n> It's probably because of the BK refugee population that after you do\n> an hg pull, it will warn you that you need to do an \"hg update\" in\n> order to merge the working directory up to the latest version that was\n> just pulled --- and this change was made precisely because Hg supports\n> local branches, and merging with the current branch isn't always the\n> right thing, unlike with BK.\n> \n>> And the concept of local branches is exactly _why_ you have to have \n>> separate \"fetch\" and \"pull\", but why you do _not_ need a separate \"merge\" \n>> (because \"pull .\" does it for you).\n> \n> It's just that the semantics are different, and many developers have\n> to use multiple DSCM's, depending on what project they happen to be\n> developing on. So the reality is that there are people who have to\n> use bzr, git, and hg, all at the same time. And while eventually\n> newbies will figure out and remember that \"git pull .\" == \"merge\", the\n> naming is simply confusing, that's all. (What does \"pull\" have to do\n> with \"merge\"? It's not at all obvious.) \n> \n> For somoene who uses git full-time, and to the exclusion of all other\n> systems, I'm sure it's not a problem at all.\n\n\nIt seems we should, cheaply, be able to avoid a large part of the \nconfusion by\n\n* Mentioning git-fetch before git-pull in all documentation newborn \ngitizens are likely to come across. Most git-users aren't Linus, and for \nevery successful project the maintainers are outnumbered 100 to 1 by the \ncontributors. Those projects successful *because* maintainers are \nheavily outnumbered so we should make it easier for contributors by \nteaching them the right things from the start and possibly have a \nseparate man-page for maintainer (git-{maintainer,developer} man-pages, \nanyone?).\n* Creating \"git update\" which might possibly be an internal alias to \n\"git pull\", except that it should read .git/remotes/* by default unless \na specific remotes-file is specified.\n* Renaming git-merge to git-merge-driver\n* Implementing a git-merge that actually does what its name implies, \npossibly by making it an internal alias to pull, but with these differences:\n - It always merges into your current branch.\n - It understands \"git merge branch\" as well as \"git merge . branch\".\n\nThis is just the very low-hanging fruit. If we take these steps and let \nthings cool down a bit, it would probably be proper to take a fresh look \nat this in a couple of months.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\n"},{"id":"298256","messageId":"455C618A.7080309@xs4all.nl","threadId":"6919","inReplyTo":"7v7ixvbq80.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T13:03:06Z","receivedAt":"2006-11-16T13:03:06Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Junio C Hamano escreveu:\n> You claim it is _an interface_ issue but it is not.\n\n >> I don't want ANYTHING to really change, I just want a sane interface \n >> to it.\n >\n > I agree that you do not want to change anything. You just\n > needed a bit of handholding, because you deviated from the\n > cookbook usage, to correct your course.\n\nUsers (well, I do at least) start fiddling with systems to find out how \nthey work. Reading the manual is usually done as a last resort. I \nthink this is pretty well documented in usability research.\n\nI'm trying to show how GIT is badly suited to this. Your response is to \nexplain to me what I should have done. That's nice, but that approach \ndoesn't scale, because you don't reach the dozens of users out there who \ntry the same, fail and give up.\n\nIf you really want to find out the weaknesses, you'd have to sit someone \nnew to git in front of a computer, and let him figure how to operate it, \nwhile videotaping everything.\n\nWriting a manual for newbies is also an effective (and simpler and \ncheaper) approach of figuring out what needs to be changed.\n\n\n\nAs another example: annoyances regarding program invocation\n\n - option handling: -x -f -z != -xfz , \"--max-count 1\" doesn't work, \nbut needs an '='\n\n - git --help lists an unordered set, which is too long scan quickly. \nI'd expect that list to either contain everything or the minimum set for \ndaily use. I.e. the set introduced in a first tutorial. Why are merge, \nprune, verify-tag there?\n\nTry \"bzr help\" for comparison.\n\n - --pretty option with wholly uninformative options full, medium, \nshort, raw. It's not even documented what each option does.\n\n\nI can go on with listing idiosyncrasies, but my point is not to get help \nfrom you, but rather to show how git can be improved.\n\n\n>> With GIT, this is what happens\n>>\n>> [hanwen@haring y]$ git pull ../x\n>> fatal: Needed a single revision\n>> Pulling into a black hole?\n> \n> You asked it to fetch from the neighbour repository and merge it\n> into your current branch which does not exist (I presume that\n> you omitted to describe what you did in directory y/ and I am\n> assuming you did \"mkdir y && cd y && git initdb\" and nothing\n> else). You are pulling into a black hole.\n\nas you remark in the other reply, there is IMO no reason for not having \nan empty 'master' branch. If master + HEAD gets created on the first \ncommit, it might as well be created on the init-db.\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"298727","messageId":"455C6399.5020407@xs4all.nl","threadId":"6919","inReplyTo":"455C618A.7080309@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T13:11:53Z","receivedAt":"2006-11-16T13:11:53Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Han-Wen Nienhuys escreveu:\n\n> I can go on with listing idiosyncrasies, but my point is not to get help \n> from you, but rather to show how git can be improved.\n\noh, and another annoying one: git's insistence on firing up a pager if \nthere is nothing to page, eg. try\n\n git-log je-n-existe-pas\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"294159","messageId":"20061116132119.GH5453@diana.vm.bytemark.co.uk","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151309290.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-16T13:21:19Z","receivedAt":"2006-11-16T13:21:19Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-15 13:11:36 -0500, Nicolas Pitre wrote:\n\n> On Wed, 15 Nov 2006, Junio C Hamano wrote:\n>\n> > Nicolas Pitre writes:\n> >\n> > > But again I think it is important that the URL to use must be a\n> > > per branch attribute i.e. attached to \"default/master\" and not\n> > > just \"default\". This way someone could add all branches of\n> > > interest into the \"default\" group even if they're from different\n> > > repositories, and a simple get without any argument would get\n> > > them all.\n> >\n> > I think the \"one group per one remote repository\" model is a lot\n> > easier to explain. At least when I read your first \"branch group\"\n> > proposal that was I thought was going on and I found it quite\n> > sensible (and it maps more or less straightforwardly to the way\n> > existing .git/refs/remotes is set up by default).\n>\n> I think one group per remote repo is how things should be by default\n> too. But we should not limit it to that if possible.\n\nWithout the limitation, we risk name collisions when getting all\nbranches from the remote repository (that is, including any new\nbranches we previously didn't know about).\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"295394","messageId":"20061116134358.GW7201@pasky.or.cz","threadId":"6919","inReplyTo":"7vodr7brfp.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-16T13:43:58Z","receivedAt":"2006-11-16T13:43:58Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Nov 16, 2006 at 11:45:46AM CET, Junio C Hamano wrote:\n> Petr Baudis writes:\n> \n> > (v) Library issues...\n> > Git has the advantage of\n> > simply putting that part in C, which is though something I should've\n> > been doing more frequently too.\n> \n> It should be stressed that git-core plumbing written in C is not\n> just for git Porcelain-ish, and it will continue to be shared\n> service. We would add core support for what Porcelains need and\n> we would try hard to keep them generic enough so that other\n> Porcelains can use them. Keeping the core and Porcelain-ish in\n> the same project has made it easier to keep them in sync and to\n> find and add missing features that would benefit Porcelains (not\n> limited to git Porcelain-ish). But that should not be mistaken\n> as plumbing somehow belongs more to git Porcelain-ish than to\n> Cogito or others.\n\n Of course, I didn't mean to say that. I should do more often things\nlike adding --stdin to the fetchers. From one part, I'm used to work\nwith a fixed set of system tools and extending Git with the\nfunctionality I want means changing my thinking mode and \"jumping out of\nthe system\" a bit. The other part is that I cannot use the improvements\nin Cogito right away (at least not in the main branch) but I have to\nwait for the next Git release; but this is mostly just an excuse. :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i torsdag 16 november 2006 04:21 skrev Petr Baudis:\n> > Another point is, if using _just_ _git_ requires you to learn \"all those\n> > git commands too\" from git-commit-tree up (yes it does! if you want your\n> > authorship information to be correct), something is wrong.\n> \n> When/why do I need git-commit-tree? Isn't git-commit enough?\n\nAs I said, when you need to find out how to setup your authorship\ninformation. It's documented as deep as on the git-commit-tree level.\nBTW, the documentation is another important part of the\nplumbing/porcelain separation, it's not only about the list of commands\nbut also that porcelain documentation should be reasonably\nself-contained and not require users to peek at plumbing docs in order\nto find out many stuff. It's also a consideration I take when\nmaintaining Cogito documentation.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i 1) make \"git init\" an alias for \"git init-db\".\n> \n> What's the point of \"-db\"? Sure we're initializing the GIT database. \n> But who cares? The user doesn't care if GIT uses a \"database\" or \n> whatever. And according to some people's definition of a \"database\" it \n> could be argued that GIT doesn't use a database at all in the purist \n> sense of it. What the user wants is to get started and \"init\" (without \n> the \"-db\" is so much more to the point. Doesn't matter if incidentally \n> it happens to be the same keyword HG uses for the same operation because \n> we are not afflicted by the NIH disease, right? And it has 3 chars less \n> to type which is for sure a premium improvement to the very first GIT \n> user experience!\n\n(This is somewhat related to the HEAD issue, e.g.\n<7v1wo3d6g4.fsf@assigned-by-dhcp.cox.net>, by virtue of basically\neliminating it.)\n\nLet's see. If you are adding the alias, you can as well add some\nporcelain stuffing in it, too.\n\nWhat are the 99% of use cases when doing \"init\"?\n\n(a) You are going to do an initial commit right away; the repository is\nat this point basically useless for anything but initial commit. So you\nmight have \"init\" well just perform it for you right away.\n\n(b) You are setting up a bare repository on a server and you will push\nto it in a minute. Cogito has a separate cg-admin-setuprepo command for\nit, which will also prepare it for usage by dumb servers and optionally\nfor shared usage in a group of users. Git could have something similar.\n\n\n> 2) \"pull\" and \"push\" should be symmetrical operations\n..snip..\n> Conclusion: git-pull must not perform any merge. It is the symmetrical \n> operation of a push meaning that it pulls content from a remote branch \n> and does no more. People understands that pretty well, . This makes \n> git-fetch redundant (or an alias to git-pull) in that case, and again we \n> don't mind it becoming similar to in HG because we admit HG was right \n> about it.\n\nIf you _really_ want to do it in Git, the only sensible way to do it is\nto stop using the \"pull\" verb for a command name altogether for at least\nsome rather long period of time, otherwise that's a blatant backwards\ncompatibility breakage.\n\n> 3) remote branch handling should become more straight forward.\n> \n> OK! Now that we've solved the pull issue and that everybody agrees with \n> me (how can't you all agree with me anyway) let's have a look at remote \n> branches. It should be simple:\n..snip..\n\nBy the way, due to the way you describe it, it's not all that clear to\nme how is this (in)compatible with the current way we do it, on other\nthan the usage and git-pull's auto-creation magic level.\n\nIs it that what you are describing _is_ in fact what we do support now,\nwith \"branch groups\" meaning \"remotes\" etc, and you are only proposing\nsome enhancements to automatically create remotes in git-pull, or are\nthere some other differences I've missed?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i Junio C Hamano writes:\n> \n> > I would rather say \"use 'git branch' to make sure if you are\n> > ready to merge\". Who teaches not to use \"git pull\"?\n> \n> We do that for Wine. The problem is that we recommend using git-rebase\n> to make it easier for occasional developers to keep a clean history,\n> and rebase and pull interfere badly.\n\nHow do those developers submit their changes? Do they push? If they do,\ngit-rebase can be saving one merge at most, and the merge is actually a\ngood thing (someone should write some nice standalone writeup about\nthat).\n\nIf they don't have push access and maintain their patches locally until\nthey get accepted, perhaps it would be far simpler for them to use\nStGIT?\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i writes:\n\n> How do those developers submit their changes? Do they push? If they do,\n> git-rebase can be saving one merge at most, and the merge is actually a\n> good thing (someone should write some nice standalone writeup about\n> that).\n\nNo, they use git-format-patch and mail them in.\n\n> If they don't have push access and maintain their patches locally until\n> they get accepted, perhaps it would be far simpler for them to use\n> StGIT?\n\nFor regular developers, sure. But regular developers will need to\nproperly understand the git model anyway, and then they will able to\nmake sense even of the standard git commands ;-) The problem is that\nthere isn't a smooth progression to that point.\n\nAt first, a user will simply want to download and build the code, and\nfor that git-pull works great, it's a one-stop command to update their\ntree.\n\nThen after a while the user will fix a bug here and there, and at that\npoint git-rebase is IMO the best tool, it's reasonably easy to use,\ndoesn't require learning other commands, and once the patch is\naccepted upstream it nicely gets the tree back to the state that the\nuser is familiar with.\n\nThe problem is that rebase doesn't work with pull, so the user needs\nto un-learn git-pull and start using git-fetch; it's to avoid this\nthat we recommend using git-fetch from the start, which is unfortunate\nsince it makes things harder for beginners.\n\n-- \nAlexandre Julliard\n"},{"id":"294980","messageId":"Pine.LNX.4.64.0611160814560.3349@woody.osdl.org","threadId":"6919","inReplyTo":"455C412D.1030408@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T16:23:08Z","receivedAt":"2006-11-16T16:23:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:\n> \n> This is not about CVS or SVN, so don't put them up as a strawman.\n> If you want to argue that my brain is warped, use other distributed VCs as an\n> example.\n\nYour example has nothing at all to do with \"pull\" vs \"fetch\", though.\n\nYour example is about something totally _different_, namely that under \ngit, \"git init-db\" is _only_ for creating a _new_ project.\n\n> The following\n> \n> mkdir x y\n> cd x\n> hg init\n> echo hoi > bla\n> hg add\n> hg commit -m 'yes, I am also too stupid to refuse explicit empty commit messages'\n> cd ../y\n> hg init\n> hg pull ../x\n> \n> pretty much works the same in Darcs, bzr and mercurial.\n> \n> With GIT, this is what happens\n> \n> [hanwen@haring y]$ git pull ../x\n\nBzzt. This is where you went wrong, and you blamed \"pull\".\n\nThe way you do this in git is to NOT do \"git init\". Instead, you replace \nall the\n\n\tmkdir y\n\tcd ../y\n\thg init\n\thg pull ../x\n\nwith a simple\n\n\tgit clone x y\n\nand YOU ARE DONE.\n\nNow, we could certainly _make_ \"git pull\" work on an empty git project, \nbut that has _nothing_ to do with what people have been talking about.\n\nIn fact, the fact that \"git fetch\" kind of works is not exactly accidental \n(because \"git fetch\" _is_ meant to add new local branches too), but all \nthe problems you have with it are due to the SAME issue. You started \nwithout any branch at all, because you started with an empty git repo, and \nyou're simply not _supposed_ to do that.\n\nSo current rule (and this is not new, it's always been true): the ONLY \ntime you use \"git init-db\" is when you are going to start a totally new \nproject. Never _ever_ otherwise. If you want to track another project, use \n\"git clone\".\n\n> This might not be typical GIT use, but it does show the typical GIT user\n> experience, at least mine.\n\nIt's not that it isn't typical, it's that you are using the wrong model. \nMaybe it's not well documented, I can easily give you that, but ALL your \nproblems come from that fundamental starting point: you shouldn't have \nused \"git init-db\" in the first place.\n\nSomebody want to document it?\n\nAlternatively, we certainly _could_ make \"git pull\" just accept an empty \ngit repo, and make it basically create the current branch.\n\n(And we probably should improve the error messahe)\n\n> I don't want ANYTHING to really change, I just want a sane interface to it.\n\nThe sane interface _exists_. It's called \"git clone\".\n\n"},{"id":"298386","messageId":"Pine.LNX.4.64.0611160824040.3349@woody.osdl.org","threadId":"6919","inReplyTo":"455C5079.3010701@op5.se","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T16:30:55Z","receivedAt":"2006-11-16T16:30:55Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Andreas Ericsson wrote:\n> \n> * Mentioning git-fetch before git-pull in all documentation newborn gitizens\n> are likely to come across.\n\nHowever, I also think it might make sense to talk about the _simple_ form \nof \"git pull\" first.\n\nThe form I use is actually a lot simpler (conceptually) than the \"short\" \nform.\n\nWhen you do\n\n\tgit pull \n\nthere are very few things that can confuse you (although trying to do it \nwithout a current branch at all is apparently one such thing ;). \n\nThere are no local branches to worry about, and there aren't any issues \nabout what the default repository or branchname on the remote side would \nbe either.\n\nSo in many ways, if you use this format, you simply never have to worry. \nYou may have to _type_ a bit more, so it's not the short or concise \nformat, but it sure is the _simple_ format. There simply isn't anything to \nbe confused about.\n\nAnd yes, I actually tend to use this even for project that I don't develop \non, partly because the defaults for the short and concise formats are bad. \nFor example, I follow the \"modesetting\" branch on the xorg intel graphics \ndriver tree, and because I'm always on that branch, what I do is\n\n\tgit pull origin modesetting\n\nwhich works correctly (while \"git pull\" would _not_ have done the right \nthing: it would have picked the right repository, but it would have picked \nthe \"master\" branch of that repository, not the \"modesetting\" branch).\n\nAnd notice how I don't do _any_ development there, I just follow that \nbranch. The \"merge\" will obviously always be a fast-forward, but that's \nexactly what I want. \n\n> Most git-users aren't Linus, and for every successful project the \n> maintainers are outnumbered 100 to 1 by the contributors.\n\nWell, as mentioned, I think even for non-developers, doing pulls with \nexplicit branchnames is actually perfectly sane.\n\n"},{"id":"295909","messageId":"87fycjs5yg.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151523290.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-16T16:37:43Z","receivedAt":"2006-11-16T16:37:43Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 15 Nov 2006 15:33:43 -0800 (PST), Linus Torvalds wrote:\n> It's a lot more useful to have a merge message like\n>\n> \tMerge branch 'for-linus' of git://one.firstfloor.org/home/andi/git/linux-2.6\n>\n> than one like\n>\n> \tMerge branch 'for-linus'\n\nThere's more information in the first, sure. But I absolutely don't\naccept that it's necessarily more useful, and definitely not that this\nis a good argument for using pull with a remote branch instead of\nfetch followed by merge with a local branch.\n\nFirst, the pull may just fast-forward in which case there's no message\nat all. And we've been through that topic enough recently that we all\nknow that no important information is lost by not doing any separate\nrecording in that case.\n\nSo you can't turn around and argue that the remote URL information is\nsuddenly important when it just so happens that it's not a fast\nforward.\n\n> And in a truly distributed situation, \"pull\" is strictly more powerful\n> than a separate \"fetch\" + separate \"merge\".\n\nI don't buy it. In my usage, I have several different remote\nrepositories I'm interested in tracking, each with any number of\nbranches. What I really want is an easy command that fetches all of\nthose branches, (even new ones that I've never heard about---but never\nany of their \"tracking branches\" that wouldn't be of interest to\nme). And I want to do that once, to get the online-access-required\npart over with and get all the data into my local repository where I\ncan start working with it.\n\nAs for the URL from which I'm fetching all this stuff, it's really not\ninteresting to me at all. The URL for \"Keith's stuff\" keeps changing\nanyway---I have no interest in recording that. But I do think it's\nworth recording that the commits came from Keith's repository. I do\nthat right now with a keith/ prefix for his branches. It could also be\ndone by bringing in his .git/description during the fetch and storing\nit somewhere. But I honestly don't see how storing something like that\nduring would make the system any less distributed in any sense.\n\n-Carl\n"},{"id":"295366","messageId":"455C94FA.3050903@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160814560.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T16:42:34Z","receivedAt":"2006-11-16T16:42:34Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Linus Torvalds escreveu:\n\n> So current rule (and this is not new, it's always been true): the ONLY \n> time you use \"git init-db\" is when you are going to start a totally new \n> project. Never _ever_ otherwise. If you want to track another project, use \n> \"git clone\".\n\nActually, only a 2 weeks ago, you suggested that I share the website\nand main source code for my project in a single repository for reasons\nof organization.\n\nIn this setup I find it logical to do\n\n git init-db\n git pull ..url.. website/master\n\nto wind up with just the 5mb website, instead of the complete 70mb\nof packed source code with all of its branches and tags.\n\n> It's not that it isn't typical, it's that you are using the wrong model. \n> Maybe it's not well documented, I can easily give you that, but ALL your \n> problems come from that fundamental starting point: you shouldn't have \n> used \"git init-db\" in the first place.\n> \n> Somebody want to document it?\n> \n> Alternatively, we certainly _could_ make \"git pull\" just accept an empty \n> git repo, and make it basically create the current branch.\n\nYes, I would like that. \n\n\n-- \n"},{"id":"294196","messageId":"87ejs3s4vn.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160824040.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-16T17:01:00Z","receivedAt":"2006-11-16T17:01:00Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:\n> The form I use is actually a lot simpler (conceptually) than the \"short\"\n> form.\n>\n> When you do\n>\n> \tgit pull \n\nYes, that's what the user almost always wants. The UI problem here is\nthat the conceptually simpler form is syntactically longer, (which\nmeans users aren't likely to find it).\n\nSo if we can just get and to default\ncorrectly, (based on the current branch name, and clone/fetch/pull\nhistory), then the conceptually simple form ends up syntactically\nsimple as \"git pull\".\n\nAnd I definitely don't have any problem with that. I'd love to be able\nto teach that kind of simple thing to new users.\n\n> driver tree, and because I'm always on that branch, what I do is\n>\n> \tgit pull origin modesetting\n...\n> Well, as mentioned, I think even for non-developers, doing pulls with\n> explicit branchnames is actually perfectly sane.\n\nThe behavior is sane, but having to always type the branch name\nspecifically because it never changes... that's a user-interface bug.\n\nThis is a good example of the kind of thing I wanted to hit when\nstarting this thread. I don't think there are any big conceptual\nchanges needed in git to make it easier for new users. But there are\nlittle things that are problems that really should be fixed. Wouldn't\nit be great to have the following exchange:\n\n\tUser: How do I track on-going development in a branch?\n\tMaster: Use \"git pull\"\n\nRather than:\n\n\tUser: How do I track on-going development in a branch?\n\tMaster Use \"git pull origin \"\n\n?\n\n-Carl\n"},{"id":"297622","messageId":"Pine.LNX.4.64.0611160904010.3349@woody.osdl.org","threadId":"6919","inReplyTo":"455C94FA.3050903@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T17:17:32Z","receivedAt":"2006-11-16T17:17:32Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:\n> \n> Actually, only a 2 weeks ago, you suggested that I share the website\n> and main source code for my project in a single repository for reasons\n> of organization.\n> \n> In this setup I find it logical to do\n> \n> git init-db\n> git pull ..url.. website/master\n\nI don't disagree per se. It should be easy to support, it's just that it's \nnot traditionally been something we've ever done.\n\nSo the way you'd normally set up a single repo that contains multiple \nother existing repositories is to basically start with one (\"git clone\") \nand then add the other branches and \"git fetch\" them.\n\nSo again, instead of \"git init-db\" + \"git pull\", you'd just use \"git \nclone\" instead.\n\nNote that there _is_ another difference between \"git pull\" and \n\"fetch+merge\". The difference being that \"git pull\" implicitly does the \ncheckout for you (I say \"implicitly\", because that's the way the git \nmerge conceptually works: we always merge in the working tree. That's not \nthe only way it _could_ be done, though - for trivial merges, we could do \nthem without any working tree at all, but we don't suppotr that).\n\nAnd that \"git pull\" semantic actually means that if you want a _bare_ \nrepository, I think \"git --bare init-db\" + \"git --bare fetch\" actually \ndoes exactly the right thing right now too. But \"git pull\" would not be \nthe right thing to use.\n\nBtw, another normal way to generate a central \"multi-headed repo\" for is \nto not use \"pull\" or \"fetch\" or \"clone\" at ALL, but I would likely do \nsomething like\n\n\tmkdir central-repo\n\tcd central-repo\n\tgit --bare init-db\n\nand that's it. You now have a central repository, and you _never_ touch it \nagain in the central place except to repack it and do other \"maintenance\" \n(eg pruning, fsck, whatever).\n\nInstead, from the _outside_, you'd probably just do\n\n\tgit push central-repo mybranch:refs/heads/central-branch-name\n\n(actually, you'd probably set up that branch-name translation of \n\"mybranch:refs/heads/central-branch-name\" in your remote description, but \nI'm writing it out in full as an example).\n\nSo there are many ways to do it. It just happens that \"git init-db\" \nfollowed by \"git pull\" is not one of them ;)\n\n(And the real reason for that is simple: \"git pull\" simply wants to have \nsomething to _start_ with. It's not hugely fundamental, it's just how it \nwas written).\n\n"},{"id":"294282","messageId":"Pine.LNX.4.64.0611160924250.3349@woody.osdl.org","threadId":"6919","inReplyTo":"87ejs3s4vn.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T17:30:47Z","receivedAt":"2006-11-16T17:30:47Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Carl Worth wrote:\n>\n> On Thu, 16 Nov 2006 08:30:55 -0800 (PST), Linus Torvalds wrote:\n> > The form I use is actually a lot simpler (conceptually) than the \"short\"\n> > form.\n> >\n> > When you do\n> >\n> > \tgit pull \n> \n> Yes, that's what the user almost always wants. The UI problem here is\n> that the conceptually simpler form is syntactically longer, (which\n> means users aren't likely to find it).\n\nYeah. \n\nAnd this is something I absolutely agree with. Our default branches for \n\"pull\" are horrible. You can \"fix\" it, but you can only fix it by adding \n_explicit_ branches to your .git/config file by hand, so I don't think \nthat's actually a real fix at all. We should just fix the default (where \neven a \"I don't know what branch you want\" _error_ would be preferable \nover the current situation).\n\nAlong with the \"git checkout \" thing, I think these two things are \ndefinitely worth just fixing.\n\n> The behavior is sane, but having to always type the branch name\n> specifically because it never changes... that's a user-interface bug.\n\nYeah. Each branch should\n\n (a) have a \"default source\" initialized on the initial \"clone\"\n\n (b) have a way to set the source afterwards\n\n (c) error out if you do just a \"git pull\" or \"git pull remotename\" if \n there is no default branch for the current local branch for that \n remote.\n\nWe actually have (b) in a weak form right now (\"weak\" because it requires \nyou to manually edit the config file: we've got the mechanism, but not a \nnice UI for it), but (a) and (c) are just broken.\n\nAnd yeah, we should allow pulling into a branch that hasn't been \ninitialized.\n\n"},{"id":"297590","messageId":"455CA2A8.5010700@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160904010.3349@woody.osdl.org","subject":"multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T17:40:56Z","receivedAt":"2006-11-16T17:40:56Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Linus Torvalds escreveu:\n> \n> On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:\n>> Actually, only a 2 weeks ago, you suggested that I share the website\n>> and main source code for my project in a single repository for reasons\n>> of organization.\n>>\n>> In this setup I find it logical to do\n>>\n>> git init-db\n>> git pull ..url.. website/master\n> \n> I don't disagree per se. It should be easy to support, it's just that it's \n> not traditionally been something we've ever done.\n> \n> So the way you'd normally set up a single repo that contains multiple \n> other existing repositories is to basically start with one (\"git clone\") \n\nYou're misunderstanding me: the multi-repo is at git.sv.gnu.org is the\nremote one. The example I gave was about locally creating a single\nproject repo from a remote multiproject repo. \n\nOn a tangent: why is there no reverse-clone? I have no shell access\nto the machine, so when I created the remote repo, I had to push, and\nended up putting 1.2 Gb data on the server.\n\n\n\nis this send-pack? From UI perspective it would be nice if this could\nalso be done with clone,\n\n git clone . ssh+git://....\n\n>And that \"git pull\" semantic actually means that if you want a _bare_ \n>repository, I think \"git --bare init-db\" + \"git --bare fetch\" actually\n\nyes, this works. Two remarks:\n\n\n* it needs\n\n website/master:master\n\notherwise you still don't have a branch.\n\n* why are objects downloaded twice? If I do\n\n git --bare fetch git://git.sv.gnu.org/lilypond.git web/master\n\nit downloads stuff, but I don't get a branch. If I then do \n\n git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master\n\nit downloads the same stuff again. \n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"298196","messageId":"BAYC1-PASMTP082D56B2460EFED9DA6D3BAEE90@CEZ.ICE","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160924250.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Sean","fromEmail":"seanlkml@sympatico.ca","sentAt":"2006-11-16T17:44:14Z","receivedAt":"2006-11-16T17:44:14Z","isPatch":false,"sender":{"key":"seanlkml@sympatico.ca","avatar":"https://gravatar.com/avatar/f92923f54fc08c401fc59b71829d4b89e9b8087fbba45ff87c82e6a83aee02ae?d=mp&s=160"},"body":"On Thu, 16 Nov 2006 09:30:47 -0800 (PST)\nLinus Torvalds wrote:\n\n> Yeah. Each branch should\n> \n> (a) have a \"default source\" initialized on the initial \"clone\"\n>\n> (b) have a way to set the source afterwards\n>\n> (c) error out if you do just a \"git pull\" or \"git pull remotename\" if \n> there is no default branch for the current local branch for that \n> remote.\n\nThis would be _great_. You just shouldn't have to hack at the\n.git/config file to get reasonable default sources after a clone.\nOr even for that matter after fetching a new branch into an\nexisting repo.\n\n"},{"id":"293924","messageId":"f2b55d220611160957s2e68059dk99bbe902e7e1f416@mail.gmail.com","threadId":"6919","inReplyTo":"87fycjs5yg.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-16T17:57:00Z","receivedAt":"2006-11-16T17:57:00Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"On 11/16/06, Carl Worth wrote:\n> First, the pull may just fast-forward in which case there's no message\n> at all. And we've been through that topic enough recently that we all\n> know that no important information is lost by not doing any separate\n> recording in that case.\n>\n> So you can't turn around and argue that the remote URL information is\n> suddenly important when it just so happens that it's not a fast\n> forward.\n\nWhen it's a fast forward, the puller hasn't had to make any judgment\ncalls, so there's no editorial history to record. When it's not, but\nthe puller chooses to retain the result on a persistent branch, that\n_is_ an editorial decision (even if the result of the auto-merge is\nclean); I like having that in the history.\n\n> > And in a truly distributed situation, \"pull\" is strictly more powerful\n> > than a separate \"fetch\" + separate \"merge\".\n>\n> I don't buy it. In my usage, I have several different remote\n> repositories I'm interested in tracking, each with any number of\n> branches. What I really want is an easy command that fetches all of\n> those branches, (even new ones that I've never heard about---but never\n> any of their \"tracking branches\" that wouldn't be of interest to\n> me). And I want to do that once, to get the online-access-required\n> part over with and get all the data into my local repository where I\n> can start working with it.\n\nWhat do you want all of those branches for? They haven't been\npublished to you (that's a human interaction that doesn't go through\ngit), so for all you know they're just upstream experiments, and doing\nthings with them is probably shooting yourself in the foot.\n\nI do agree that a robust form of \"for b in .git/remotes/*; do git\nfetch `basename $b`; done\" would be a nice bit of porcelain. The\nentries in .git/remotes would probably need to grow a \"Fetch-options:\"\nfield so that you could choose whether or not to follow tags, etc.\nPatch to follow.\n\nCheers,\n"},{"id":"294889","messageId":"Pine.LNX.4.64.0611160932340.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160904010.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T17:57:29Z","receivedAt":"2006-11-16T17:57:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Linus Torvalds wrote:\n> \n> (And the real reason for that is simple: \"git pull\" simply wants to have \n> something to _start_ with. It's not hugely fundamental, it's just how it \n> was written).\n\nHere's a very lightly tested patch that allows you to use \"git pull\" to \npopulate an empty repository.\n\nI'm not at all sure this is necessarily the nicest way to do it, but it's \nfairly straightforward.\n\nJunio, what do you think?\n\n\t\tLinus\n\n---\ndiff --git a/git-pull.sh b/git-pull.sh\nindex ed04e7d..7e5cee2 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -44,10 +44,10 @@ do\n \tshift\n done\n \n-orig_head=$(git-rev-parse --verify HEAD) || die \"Pulling into a black hole?\"\n+orig_head=$(git-rev-parse --verify HEAD 2> /dev/null)\n git-fetch --update-head-ok --reflog-action=pull \"$@\" || exit 1\n \n-curr_head=$(git-rev-parse --verify HEAD)\n+curr_head=$(git-rev-parse --verify HEAD 2> /dev/null)\n if test \"$curr_head\" != \"$orig_head\"\n then\n \t# The fetch involved updating the current branch.\n@@ -80,6 +80,11 @@ case \"$merge_head\" in\n \texit 0\n \t;;\n ?*' '?*)\n+\tif test -z \"$orig_head\"\n+\tthen\n+\t\techo >&2 \"Cannot merge multiple branches into empty head\"\n+\t\texit 1\n+\tfi\n \tvar=`git-repo-config --get pull.octopus`\n \tif test -n \"$var\"\n \tthen\n@@ -95,6 +100,12 @@ case \"$merge_head\" in\n \t;;\n esac\n \n+if test -z \"$orig_head\"\n+then\n+\tgit-update-ref -m \"initial pull\" HEAD $merge_head \"\" || exit 1\n+\texit\n+fi\n+\n case \"$strategy_args\" in\n '')\n"},{"id":"295001","messageId":"87slgjb6ow.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160904010.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-16T18:13:51Z","receivedAt":"2006-11-16T18:13:51Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 16 Nov 2006 09:17:32 -0800 (PST), Linus Torvalds wrote:\n> So the way you'd normally set up a single repo that contains multiple\n> other existing repositories is to basically start with one (\"git clone\")\n> and then add the other branches and \"git fetch\" them.\n\nFor that we'd also need a way for clone to be able to fetch just a\nsingle branch, and not all of them as well.\n\nThere is some clone vs. fetch asymmetry here that has annoyed me for a\nwhile, and that I don't think has been mentioned in this thread\nyet. Namely:\n\nclone: can only be executed once, fetches all branches, \"remembers\"\n URLs for later simplified use\n\nfetch: can be executed many times, fetches only named branches,\n doesn't remember anything for later\n\nI've often been in the situation where I cloned a long time ago, but\nI'd like to be able to fetch everything that I would get if I were to\nstart a fresh clone.\n\n-Carl\n"},{"id":"295068","messageId":"Pine.LNX.4.64.0611160958170.3349@woody.osdl.org","threadId":"6919","inReplyTo":"455CA2A8.5010700@xs4all.nl","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T18:21:37Z","receivedAt":"2006-11-16T18:21:37Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:\n> \n> You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the\n> remote one. The example I gave was about locally creating a single\n> project repo from a remote multiproject repo. \n\nAhh.\n\nOk, try the patch I just sent out, and see if it works for you. It \n_should_ allow you to do exactly that\n\n\tmkdir new-repo\n\tcd new-repo\n\tgit init-db\n\tgit pull \n\nand now your \"master\" branch should be initialized to \"onehead\".\n\nOh, except I just realized that I forgot to do a \"git checkout\" in my \npatch, so you'd need to add that (or do it by hand, but you really \nshouldn't need to, since the checkout is implied by the \"pull\").\n\nThe downside with this is that it does NOT populate your \"remotes\" \ninformation (like \"git clone\" would have done), so either we'd need to \nteach \"git pull\" to do that too, or you just have to do it by hand (so \nthat you then can do the shorthand \"git pull\" to update in the future).\n\n> On a tangent: why is there no reverse-clone? I have no shell access\n> to the machine, so when I created the remote repo, I had to push, and\n> ended up putting 1.2 Gb data on the server.\n\nYeah, you're supposed to \"init-db\" and \"push\". Right now, that tends to \nunpack everything (which is bad), although that is hopefully getting fixed \n(ie the receiving end shouldn't unpack any more if it is recent. Junio?)\n\n> \n> \n> is this send-pack?\n\n\"git push\" uses send-pack internally, you shouldn't ever need to use it \nyourself.\n\n> From UI perspective it would be nice if this could also be done with clone,\n> \n> git clone . ssh+git://....\n\nThe creation of a new archive tends to need special rights (with _real_ \nssh access and a shell you could do it, but \"ssh+git\" really means \"git \nprotocol over a connection that was opened with ssh, but doesn't \nnecessarily have a real shell at the other end\").\n\nSo for most protocols, you simply cannot (and shouldn't) do it. Think \nabout services like the one that Pasky has set up, that allow you to set \nup a new git repo - the setup phase really _has_ to be separate (because \nyou need to set up your keys etc).\n\nSo I think the above syntax is actually not a good one, because it cannot \nwork in the general case. It's much better to get used to setting up a \nrepo first, and then pushing into it, and just accepting that it's a \ntwo-phase thing.\n\nAlso, from a bandwidth standpoint, you can often (although obviously not \nalways) make the setup start with something that is _closer_ to what you \nwant to do. So, for example, you'd often do something like:\n\n (a) ssh to central repository\n (b) create the new repository by cloning it _locally_ at the central \n place from some other repository that is related\n (c) then, from your local (non-central) repository, do a \"git push --force\"\n to force your changes (which now only needs the _incremental_ thing).\n\nAn example of this is again the \"forking\" thing that he repos at at \nhttp://git.or.cz/ already supports. \n\n\n> >And that \"git pull\" semantic actually means that if you want a _bare_ \n> >repository, I think \"git --bare init-db\" + \"git --bare fetch\" actually\n> \n> yes, this works. Two remarks:\n> \n> * it needs\n> \n> website/master:master\n> \n> otherwise you still don't have a branch.\n\nRight. In fact, you should probably do\n\n\twebsite/master:refs/heads/master\n\njust to make it really explicit.\n\n> * why are objects downloaded twice? If I do\n> \n> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master\n> \n> it downloads stuff, but I don't get a branch.\n\nA \"fetch\" by default won't actually generate a local branch unless you \ntold it to. It just squirrels the end result into the magic FETCH_HEAD \nname, so that you can do\n\n\t# do the fetch\n\tgit fetch git://git.sv.gnu.org/lilypond.git web/master\n\n\t# look at changes\n\tgitk ..FETCH_HEAD\n\n\t# If you're happy with them, merge them in\n\tgit merge \"merge new code\" HEAD FETCH_HEAD\n\nand you never actually created a real local branch at all.\n\nIf you want \"git fetch\" to fetch _into_ a branch, you need to tell it so, \nby using the full \"src:dest\" format. Otherwise it doesn't know what branch \nto fetch it into.\n\n(And, of course, you can define that branch relationship in your remote \nconfiguration, so you don't actually have to say it explicitly every time)\n\n> If I then do \n> \n> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master\n> \n> it downloads the same stuff again. \n\nRight. So you can either\n\n (a) do it that way to begin with (because you now told it to put the \n results in \"master\", so you never needed to do the second fetch in \n the first place)\n\nor\n\n (b) after you did the first fetch (into FETCH_HEAD), you could also have \n just decided to do \n\n\tgit update-ref HEAD FETCH_HEAD \"\"\n\n (where that \"\" at the end is really not technically necessary, but it \n tells \"update-ref\" that you _only_ want to do this if the old HEAD \n was empty/undefined. Without it, \"git update-ref\" will just \n overwrite HEAD without caring what it contained before, so it can be \n a dangerous operation!)\n\nSee?\n\n"},{"id":"293987","messageId":"87r6w3b68p.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"f2b55d220611160957s2e68059dk99bbe902e7e1f416@mail.gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-16T18:23:34Z","receivedAt":"2006-11-16T18:23:34Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 16 Nov 2006 09:57:00 -0800, \"Michael K. Edwards\" wrote:\n> What do you want all of those branches for? They haven't been\n> published to you (that's a human interaction that doesn't go through\n> git), so for all you know they're just upstream experiments, and doing\n> things with them is probably shooting yourself in the foot.\n\nThe same \"what do you want them all for\" question could be asked of\ngit-clone which also fetches all available branches. I really just\nwant to be able to easily watch what's going on in multiple\nrepositories.\n\nI want to be able to just say \"git update\" (or whatever) and then be\nable to list and browse and explore the stuff locally.\n\nYes, there's still outside communication that's necessary, but with\nthe ability to easily track all the remote branches that communication\ncan be even less formal if I can easily browse and explore things\nlocally. For example, I might not even know the name of the branch:\n\nMe: Have you pushed a branch for your new work on the frob-widget?\nFriend: Yes\n\nAnd then I can \"get fetch\" and see \"cool-new-frob\" come in without\nhaving to be told that name. Or I could have even just fetched\nwithout the specific communication if I was already expecting it for\nsome reason.\n\n-Carl\n"},{"id":"294705","messageId":"7vlkmb9rgx.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160932340.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T18:27:58Z","receivedAt":"2006-11-16T18:27:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 16 Nov 2006, Linus Torvalds wrote:\n>> \n>> (And the real reason for that is simple: \"git pull\" simply wants to have \n>> something to _start_ with. It's not hugely fundamental, it's just how it \n>> was written).\n>\n> Here's a very lightly tested patch that allows you to use \"git pull\" to \n> populate an empty repository.\n>\n> I'm not at all sure this is necessarily the nicest way to do it, but it's \n> fairly straightforward.\n>\n> Junio, what do you think?\n\nYeah, I talked about making \"merge\" treat missing HEAD as a\nspecial case of fast forward, but I like yours better. It is a\nlot cleaner and to the point.\n"},{"id":"295552","messageId":"Pine.LNX.4.64.0611161027020.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160932340.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T18:28:35Z","receivedAt":"2006-11-16T18:28:35Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Linus Torvalds wrote:\n> @@ -95,6 +100,12 @@ case \"$merge_head\" in\n> \t;;\n> esac\n> \n> +if test -z \"$orig_head\"\n> +then\n> +\tgit-update-ref -m \"initial pull\" HEAD $merge_head \"\" || exit 1\n> +\texit\n> +fi\n> +\n\nSo this is the place that probably wants a \"git-checkout\" before the \nexit, otherwise you'd (illogically) have to do it by hand for that \nparticular case.\n\nOf course, we should _not_ do it if the \"--bare\" flag has been set, so you \nmigth want to tweak the exact logic here.\n\n"},{"id":"295539","messageId":"7vhcwz9r74.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160958170.3349@woody.osdl.org","subject":"Re: multi-project repos","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T18:33:51Z","receivedAt":"2006-11-16T18:33:51Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> Yeah, you're supposed to \"init-db\" and \"push\". Right now, that tends to \n> unpack everything (which is bad), although that is hopefully getting fixed \n> (ie the receiving end shouldn't unpack any more if it is recent. Junio?)\n\nCorrect.\n\n> See?\n>\n> \t\t\tLinus\n\nSaw.\n"},{"id":"295547","messageId":"Pine.LNX.4.64.0611161039160.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160958170.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T19:01:14Z","receivedAt":"2006-11-16T19:01:14Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Linus Torvalds wrote:\n> \n> A \"fetch\" by default won't actually generate a local branch unless you \n> told it to. It just squirrels the end result into the magic FETCH_HEAD \n> name [...]\n\nBtw, the magic heads are probably not all that well documented. They do \ncome up in the man-pages, but I don't think there is any central place \ntalking about them. We have:\n\n - \"HEAD\" itself, which is obviously the default pointer for a lot of \n operations, and that specifies the current branch (ie it should \n currently always be a symref, although we've talked about relaxing \n that)\n\n - \"ORIG_HEAD\" is very useful indeed, and it's the head _before_ a merge \n (or some other operations, like \"git rebase\" and \"git reset\": think of \n it as a \"original head before we did some uncontrolled operation \n where we otherwise can't use HEAD^ or similar\")\n\n I use \"gitk ORIG_HEAD..\" a lot, and if I don't like something I see \n when I do it, I end up doing \"git reset --hard ORIG_HEAD\" to undo a \n pull I've done. This is important exactly because ORIG_HEAD is _not_ \n the same as the first parent of a merge, since a merge could have been \n just a fast-forward.\n\n - \"FETCH_HEAD\" as mentioned. Normally you'd only use this in scripting, I \n suspect, but it's potentially useful if you prefer to do a fetch first \n and then check out it (perhaps cherry-picking stuff instead of merging, \n for example).\n\n So you could do (for example)\n\n\tgit fetch some-other-repo branch\n\tgitk ..FETCH_HEAD\n\tgit cherry-pick \n\n - \"MERGE_HEAD\" is kind of the opposite of \"ORIG_HEAD\" when you're in \n the middle of a merge: it's the \"other\" branch that you're merging.\n\n It's mainly useful for merge resolution, ie\n\n\tgit log -p HEAD...MERGE_HEAD -- some/file/with/conflicts\n\n is a great way to see what happened along both branches (note the \n _triple_ dot: it's a symmetric difference), to see _why_ the confict \n happened.\n\nMost of the above are used implicitly in various cases, not just HEAD. The \n\"--merge\" flag to git-rev-list (and thus git log and friends) is just \nshorthand for the above \"HEAD...MERGE_HEAD\" behaviour (with the addition \nof also limiting the result to just conflicting files), so\n\n\tgit log -p --merge\n\nis basically exactly the same as the above (except for _all_ files that \nhave conflicts in them rather than just one hand-specified one).\n\nAnyway, maybe somebody didn't know about these, and finds them useful. \nNormally, the only one you would _really_ use is \"ORIG_HEAD\" (which is \ndescribed in several of the tutorials and examples, so people hopefully \nalready know about it). Most of the others tend to mostly be used \nimplicitly, not by explicitly naming them - although you _can_.\n\n"},{"id":"297884","messageId":"7virhf8985.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161027020.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T19:47:22Z","receivedAt":"2006-11-16T19:47:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Linus Torvalds writes:\n\n> On Thu, 16 Nov 2006, Linus Torvalds wrote:\n>> @@ -95,6 +100,12 @@ case \"$merge_head\" in\n>> \t;;\n>> esac\n>> \n>> +if test -z \"$orig_head\"\n>> +then\n>> +\tgit-update-ref -m \"initial pull\" HEAD $merge_head \"\" || exit 1\n>> +\texit\n>> +fi\n>> +\n>\n> So this is the place that probably wants a \"git-checkout\" before the \n> exit, otherwise you'd (illogically) have to do it by hand for that \n> particular case.\n>\n> Of course, we should _not_ do it if the \"--bare\" flag has been set, so you \n> migth want to tweak the exact logic here.\n\nAs you said, pull inherently involve a merge which implies the\nexistence of associated working tree, so I do not think there is\nany room for --bare to get in the picture. We already do the\ncheckout when we recover from a fetch that is used incorrectly\nand updated the current branch head underneath us.\n\nTo give the list a summary of the discussion so far, here is a\nconsolidated patch.\n\n-- >8 --\nFrom: Linus Torvalds \nSubject: git-pull: allow pulling into an empty repository\n\nWe used to complain that we cannot merge anything we fetched\nwith a local branch that does not exist yet. Just treat the\ncase as a natural extension of fast forwarding and make the\nlocal branch'es tip point at the same commit we just fetched.\nAfter all an empty repository without an initial commit is an\nancestor of any commit.\n\nSigned-off-by: Junio C Hamano \n\n---\ndiff --git a/git-pull.sh b/git-pull.sh\nindex ed04e7d..e23beb6 100755\n--- a/git-pull.sh\n+++ b/git-pull.sh\n@@ -44,10 +44,10 @@ do\n \tshift\n done\n \n-orig_head=$(git-rev-parse --verify HEAD) || die \"Pulling into a black hole?\"\n+orig_head=$(git-rev-parse --verify HEAD 2>/dev/null)\n git-fetch --update-head-ok --reflog-action=pull \"$@\" || exit 1\n \n-curr_head=$(git-rev-parse --verify HEAD)\n+curr_head=$(git-rev-parse --verify HEAD 2>/dev/null)\n if test \"$curr_head\" != \"$orig_head\"\n then\n \t# The fetch involved updating the current branch.\n@@ -80,6 +80,11 @@ case \"$merge_head\" in\n \texit 0\n \t;;\n ?*' '?*)\n+\tif test -z \"$orig_head\"\n+\tthen\n+\t\techo >&2 \"Cannot merge multiple branches into empty head\"\n+\t\texit 1\n+\tfi\n \tvar=`git-repo-config --get pull.octopus`\n \tif test -n \"$var\"\n \tthen\n@@ -95,6 +100,13 @@ case \"$merge_head\" in\n \t;;\n esac\n \n+if test -z \"$orig_head\"\n+then\n+\tgit-update-ref -m \"initial pull\" HEAD $merge_head \"\" &&\n+\tgit-read-tree --reset -u HEAD || exit 1\n+\texit\n+fi\n+\n case \"$strategy_args\" in\n '')\n \tstrategy_args=$strategy_default_args\n"},{"id":"298538","messageId":"Pine.LNX.4.64.0611161152370.3349@woody.osdl.org","threadId":"6919","inReplyTo":"7virhf8985.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T19:53:30Z","receivedAt":"2006-11-16T19:53:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Junio C Hamano wrote:\n> \n> As you said, pull inherently involve a merge which implies the\n> existence of associated working tree, so I do not think there is\n> any room for --bare to get in the picture.\n\nFair enough. Feel free to add the signed-off-by from me too, \n\n"},{"id":"295898","messageId":"7vr6w33vv3.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"20061116051240.GV7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T21:49:36Z","receivedAt":"2006-11-16T21:49:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\n> (vi) Coding issues. This is probably very subjective, but a blocker for\n> me. I have no issues about C here, but about the shell part of Git.\n> Well, how to say it... It's just fundamentally incompatible with me. I\n> *could* do things in/with it, but it's certainly something I wouldn't\n> _enjoy_ doing _at all_, on a deep level. I think the current shell code\n> is really hard to read, the ancient constructs are frequently strange at\n> best, etc. It's surely fine code at functional level and there'll be\n> people who hate _my_ style of coding and my shell code which isn't\n> perfect either, but it's just how it is with me.\n\nI've been thinking about revamping the style of shell scripts in\ngit-core Porcelain-ish for some time, and I have a feeling that\nnow may be a good time to do so, after one feature release is\nout and the list is discussing UI improvements.\n\nBut before mentioning the specifics, let me mention one tangent.\nI recently installed an OpenBSD bochs (it was actually a qemu\nimage) without knowing much about the way of the land, and after\nadjusting myself to necessary glitches (like \"make\" being called\n\"gmake\" there), I saw git properly built and pass its selftest.\nI was pleasantly surprised when I noticed there was no 'bash' on\nthe system after all that.\n\nI would like to keep it that way.\n\nI'll list things I would want to and not want to change.\nComments from the list are very appreciated. You can say things\nin two ways:\n\n * I guarantee that the _default_ shell on all sane platforms we\n care about handle this construct correctly, although it was\n not in the original Bourne. There is no reason to stay away\n from it these days.\n\nor\n\n * You've stayed away from this construct but now you say you\n feel it is Ok to use it. Don't. It would break with the\n shell on my platform (or \"it is a bad practice because of\n such and such reasons\").\n\nI do not think many people can say the former with authority\nunless you have a portability lab (the company I work for used\nto be like that and it was an interesting experience to learn\nall about irritating implementation differences). And \"POSIX\nsays shell should behave that way\" is _not_ what I want to hear\nabout.\n\nBut the latter should be a lot easier to say, and would be\nappreciated because it would help us avoid regressions.\n\nThings I would want to change:\n\n - One indent level is one tab and the tab-width is eight\n columns. Some of our scripts tend to use less than eight\n spaces for indentation to avoid line wrapping.\n\n - More use of shell functions are fine. Especially if the\n above change makes lines too long, the logic should be\n refactored.\n\n - It is so 80-ish to follow certain portability and performance\n wisdom. The following should go:\n\n . Use \"case\" when you do not have to use \"if test\".\n\n . Avoid ${parameter##word} and friends and use `expr` instead\n to pick a string apart.\n\n . Avoid \"export name=word\", write \"name=word; export name\"\n instead.\n\n . Avoid ${parameter:-word} and friends when ${parameter-word}\n would do.\n\nThings I do not want to change:\n\n - The shell scripts should start with #!/bin/sh, not\n #!/bin/bash (nor even worse \"#!/usr/bin/env sh\").\n\n - Shell functions are written as \"name () { ... }\" without \n \"function\" noiseword.\n\n - 'foo && bar || exit' exits with the error code of what\n failed; no need to say 'exit $?'.\n\n - String equality check for \"test\" is a single =, not ==. \n\n - Do not use locals.\n\n - Do not use shell arrays.\n\n - In general, if something does not behave the same way in ksh,\n bash and dash, don't use it (that does not mean these three\n are special; it just means if something is not even portable\n across these three, it is a definite no-no).\n\nI do not think I need to list other common-sense shell idioms in\nthe latter category (e.g. 'using \"test z$name = zexpected\" when\nwe do not know what $name contains' falls into that).\n"},{"id":"298477","messageId":"20061116222008.GA7201@pasky.or.cz","threadId":"6919","inReplyTo":"7vr6w33vv3.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-16T22:20:08Z","receivedAt":"2006-11-16T22:20:08Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Thu, Nov 16, 2006 at 10:49:36PM CET, Junio C Hamano wrote:\n> I would like to keep it that way.\n\nI agree - I certainly don't want to infect Git with bash dependency.\n\n> And \"POSIX says shell should behave that way\" is _not_ what I want to\n> hear about.\n\nActually, which sane platforms we care about have /bin/sh that is NOT\nPOSIX compatible?\n\n> Things I would want to change:\n\nWhat about [ instead of test? And\n\n\tif foo; then\n\ninstead of\n\n\tif foo\n\tthen\n\n?\n\n\nAm I the only one who hates\n\ncase \"$log_given\" in\ntt*)\n die \"Only one of -c/-C/-F can be used.\" ;;\n*tm*|*mt*)\n die \"Option -m cannot be combined with -c/-C/-F.\" ;;\nesac\n\ninstead of having this stuff in explicit variables and writing out some\nexplicit boolean expressions? (There _are_ few cases where the case is\ncool, but they are rare.)\n\n\nIt would be really great if Git would have something alike the Cogito's\noptparse infrastructure. I'm not sure if you can implement it in Bourne\nsh with reasonable performance, though...\n\n\nI think addressing these three particular points would make the scripts\nhugely more coder-friendly. (And well, I usually say that coding style\nis not *that* important and is frequently overemphasised. But that holds\nonly to a certain point. ;-)\n\n\n> Things I do not want to change:\n..snip all those I agree with..\n> - Do not use locals.\n\nIt's a pity. :-( Which shell doesn't support them?\n\nIt's not that huge a deal, though.\n\n> - Do not use shell arrays.\n\nThis is quite a larger deal, I think; but the portability concerns are\nvery real, I guess. :|\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i On Thu, 16 Nov 2006, Han-Wen Nienhuys wrote:\n> > \n> > * why are objects downloaded twice? If I do\n> > \n> > git --bare fetch git://git.sv.gnu.org/lilypond.git web/master\n> > \n> > it downloads stuff, but I don't get a branch.\n> \n> A \"fetch\" by default won't actually generate a local branch unless you \n> told it to.\n\nThis is actually a perfect example for\n\n- a script that is porcelain as well as plumbing (you are supposed to use \nit directly, or via pull), and for\n\n- a terrible UI.\n\n_If_ you use git-fetch directly you virtually always want to store the \nresult. I was tempted quite often to submit a patch which adds a command \nline switch --no-warn, which is passed to git-fetch by git-pull, and \nwithout which git-fetch complains if the branch-to-be-fetched is not \nstored right away (and refuses to go along).\n\n_Also_, git-pull not storing the fetched branches at least temporarily \noften annoyed me: the pull did not work, and the SHA1 was so far away I \ncould not even scroll to it. The result: I had to pull (and fetch!) the \nwhole darned objects again. Again, I was tempted quite often to submit a \npatch which makes git-pull fetch the branches into refs/fetch-temp/* and \nonly throw them away when the merge succeeded.\n\nCiao,\nDscho\n"},{"id":"293872","messageId":"7vmz6r3tat.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611162315110.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: multi-project repos","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-16T22:44:58Z","receivedAt":"2006-11-16T22:44:58Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> _If_ you use git-fetch directly you virtually always want to store the \n> result. I was tempted quite often to submit a patch which adds a command \n> line switch --no-warn, which is passed to git-fetch by git-pull, and \n> without which git-fetch complains if the branch-to-be-fetched is not \n> stored right away (and refuses to go along).\n>\n> _Also_, git-pull not storing the fetched branches at least temporarily \n> often annoyed me: the pull did not work, and the SHA1 was so far away I \n> could not even scroll to it. The result: I had to pull (and fetch!) the \n> whole darned objects again. Again, I was tempted quite often to submit a \n> patch which makes git-pull fetch the branches into refs/fetch-temp/* and \n> only throw them away when the merge succeeded.\n\nI think the earlier write-up by Linus on magic HEADs would help\ndocumenting FETCH_HEAD better.\n"},{"id":"294771","messageId":"Pine.LNX.4.64.0611161436230.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611162315110.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T22:49:45Z","receivedAt":"2006-11-16T22:49:45Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Johannes Schindelin wrote:\n>\n> - a terrible UI.\n\nWhy? We _do_ have the temporary branch. It's called FETCH_HEAD.\n\n> _Also_, git-pull not storing the fetched branches at least temporarily \n> often annoyed me: the pull did not work, and the SHA1 was so far away I \n> could not even scroll to it.\n\nAgain, why didn't you use FETCH_HEAD?\n\nIf the user doesn't give us a head to write to, we clearly MUST NOT write \nto any long-term branch. That would be a _horrible_ mistake. \n\nSo all your complaints seem totally misplaced. The UI is both usable and \npractical, and your complaint that git pull doesn't store the fetched \nbranches is just NOT TRUE.\n\nAnd your \"solution\" is obviously totally unusable. git ABSOLUTELY MUST NOT \noverwrite any existing branches unless explicitly told to do so by the \nuser.\n\nSo I really don't see your point. \n\nA lot of the complaints seem to not be about the interfaces, but about \npeople not _understanding_ and knowing what the interfaces do. If you were \nconfused about something (like not realizing that FETCH_HEAD is there and \nvery much usable), how about sending in a patch to make FETCH_HEAD use \nclearer in whatever docs you looked at and didn't find it mentioned in.\n\nNow, there is no question that some of the interfaces can get a bit \n\"interesting\" to use. For example, if you really don't want to re-fetch \nfor some reason, FETCH_HEAD actually does contain enough information that \nyou should be able to just re-do a failed merge, for example, including \nthe message generation. But at that point it really _does_ get a bit \ncomplicated, and you end up doing something like\n\n\tgit merge \"$(git fmt-merge-msg < .git/FETCH_HEAD)\" HEAD FETCH_HEAD\n\nwhich should _work_, but I'm not going to claim that it's all that easy to \nunderstand.\n\n(That said, read that one-liner a few times, and suddenly it doesn't seem \n_that_ complicated any more, now does it? You can probably even guess what \nit's really going to do, even if you don't know git all that well. It's \nnot unreadable line noise, is it?)\n\nOf course, if I had a merge that failed (the most common reason being that \nI had some uncommitted patch in a file that wanted to be updated by the \nmerge), I'd never actually do the above one-liner. I'd just re-do the \npull. But if networking was _really_ slow, and I _really_ cared, maybe I'd \ndo the above.\n\n(And no, I didn't actually test the above one-liner. Maybe it doesn't work \nfor some reason. Somebody should check, just for fun).\n\n"},{"id":"296617","messageId":"Pine.LNX.4.63.0611162353250.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151908130.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-16T23:00:18Z","receivedAt":"2006-11-16T23:00:18Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 15 Nov 2006, Linus Torvalds wrote:\n\n> Peopel seem to believe that changign a few names or doing other totally \n> _minimal_ UI changes would somehow magically make things understandable. \n\nNever ever underestimate pet peeves. If we give many people an obvious \nreason (however trivial and bike-shed-coloured) to complain, they will \ncomplain.\n\nIf we pull (pun intended) that reason away under their collective \nbacksides, they will have to find another reason to complain. But by the \ntime they found something, they will already be happy git users!\n\nBut since you just provided a patch to make life easier on non-gitters, I \nguess you agree with that already.\n\nAnd hopefully you also agree that enhancing the syntax of git-merge to \ngrok \"git-merge [-m message] \" and \"git-merge [-m message] \n \" would be a lovely thing, luring even more \npeople into using git.\n\nMaybe they even start complaining about subversion and CVS calling a merge \n\"update\", who knows?\n\nCiao,\nDscho\n"},{"id":"295207","messageId":"Pine.LNX.4.63.0611170000420.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"20061116075153.GA29363@tigerwolf.bri.st.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-16T23:01:36Z","receivedAt":"2006-11-16T23:01:36Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 16 Nov 2006, Richard CURNOW wrote:\n\n> In contrast to Linus's case of wanting to record where the remote merge\n> came from, I expressly don't want to record that - I want the merge\n> commit to describe conceptually what was being merged with what.\n> \n> OK, I could use probably use pull with --no-commit, but I've already\n> trained my fingers to type out the merge syntax. They'd be happier with\n> 'git merge -m \"Merge feature foo with fixes for bar\" bar\" though.\n\nFor the moment, if you forget --no-commit, you can always do a \"git-commit \n--amend\" -- even with merges.\n\nHth,\nDscho\n"},{"id":"294862","messageId":"Pine.LNX.4.64.0611161452430.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161436230.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T23:08:30Z","receivedAt":"2006-11-16T23:08:30Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Thu, 16 Nov 2006, Linus Torvalds wrote:\n>\n> \tgit merge \"$(git fmt-merge-msg < .git/FETCH_HEAD)\" HEAD FETCH_HEAD\n\nBtw, I'd like to claim that this is a _great_ user interface.\n\nYeah, it's different from other SCM's. I don't think you'd really want to \nscript a merge like this in CVS, especially not using standard UNIX \npipelines etc. But it's an example of how a lot of git operations - even \nthe \"high level ones\" are pretty scriptable, using very basic and very \nsimple standard UNIX shell scripting.\n\nSo even though I'd not actually _do_ the above one-liner, I think it's a \ngreat example of how git really works, and how scriptable it can be, \nwithout a lot of huge problems.\n\nSo considering that \"FETCH_HEAD\" works pretty much everywhere, and that \nyou can also use the totally non-scripting approach of doing \"standard\" \nSCM things like\n\n\tgit diff ..FETCH_HEAD\n\nor \n\n\tgitk HEAD...FETCH_HEAD\n\nto look at what got fetched (and in the latter case look at both the \ncurrent HEAD _and_ FETCH_HEAD, and what was in one but not the other), I \nreally think it's unfair to say that \"git fetch\" does not have a nice UI.\n\nIt's just that \"git fetch\" can be used two totally different ways:\n\n - \"git fetch\" to get something temporary: use FETCH_HEAD, and do _not_ \n specify a destination branch\n\n - \"git fetch\" as a way to update the branches you already have, by either \n using explicit branch specifiers (which would be unusual, but works), \n or by just having the branch relationships listed in your .git/remotes/ \n file or .git/config file.\n\nboth are actually very natural things to do.\n\nWhat is probably _not_ that natural is to do the explicit branch \nspecifier, ie\n\n\tgit fetch somerepo remotebranch:localbranch\n\nwhich obviously works, but you wouldn't want to actually do this very \noften. Either you do something once (and use FETCH_HEAD, which is actually \nnicer than a real branch in some respects: it also tells you were you \nfetched _from_, and it can contain data on merging from _multiple_ \nbranches), or you set up a \"real translation\" in your configuration files.\n\nSo I would say that the natural thing to do is:\n\n - \"git pull somerepo\"\n\n This will _also_ fetch all the branches you've said you want to track, \n of course.\n\n - \"git fetch somerepo somebranch\"\n\n Look at FETCH_HEAD, and be happy\n\n - \"git fetch somerepo\"\n\n This is kind of strange, but it can be useful if you are basically just \n mirroring another repo, and want to fetch all the branches you've said \n you want to track, but don't actually want to check them out.\n\nwhile the \"complicated\" scenario like the following is something you \nshould generally _avoid_, because it's just confusing and complex:\n\n - \"git fetch somerepo branch1:mybranch1 branch2:mybranch2\"\n\n This works, and I'm sure it's useful, and I've even used it (usually \n with just one branch, though), but let's face it - it's too damn \n complicated to be anything you want to do _normally_.\n\nSo git is definitely powerful, but I think some people have looked at the \n_complicated_ cases more than the simple cases (ie maybe people have \nlooked too much at that last case, not realizing that there really isn't \nmuch reason to use it - and FETCH_HEAD is one big reason why you seldom \nneed the complicated format).\n\n"},{"id":"298273","messageId":"Pine.LNX.4.64.0611161508530.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611162353250.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-16T23:22:08Z","receivedAt":"2006-11-16T23:22:08Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 17 Nov 2006, Johannes Schindelin wrote:\n> \n> Never ever underestimate pet peeves. If we give many people an obvious \n> reason (however trivial and bike-shed-coloured) to complain, they will \n> complain.\n\nI do actually think that this discussion has been informative, partly \nbecause I never even realized that some people would ever think to do \n\"init-db\" + \"pull\". \n\nMaking things like that work is easy enough, it's just that I never saw \nany point until people complained. And when they complained, the initial \ncomplaint wasn't actually obvious. Only when Han-Wen actually gave \nsomething that didn't work, was it clear that the real issue wasn't so \nmuch _naming_, as just expectations about the _work_flow_.\n\n> And hopefully you also agree that enhancing the syntax of git-merge to \n> grok \"git-merge [-m message] \" and \"git-merge [-m message] \n> \" would be a lovely thing, luring even more \n> people into using git.\n\nI definitely think we can make \"git merge\" have a more pleasant syntax. \nI'm just still not sure that people should actually use it ;)\n\nMy real point was/is that usually it's really not the \"naming details\" \nthat people _really_ have problems with. The real problems tend to be in \nlearning a new workflow.\n\nWe can make some of those workflows easier, but I would heartily recommend \nthat people not worry about naming of \"pull\" vs \"fetch\", because that's \nalmost certainly not really the issue. Instead, if you have a problem, \nrather than concentrating on the names of the programs, say:\n\n - what do you want to get done.\n\n Most likely it's _trivial_ to do with git, it's just that somebody used \n the wrong approach, and then it didn't work at all.\n\n - give actual examples of a workflow that didn't work or was complex.\n\n (again, the \"init-db\" + \"pull\" example). \n\n And yes, in many cases, it might well be a case of \"sure, we can make \n that _other_ workflow work too\". But somebody like me, who has used git \n for a year and a half, and used BK before it, probably simply uses a \n different workflow than somebody who comes from CVS. \n\nFor example, I suspect that your gripe with \"git fetch\" was just from \nusing it in a really awkward manner. Maybe we could make your workflow \nwork with git too, but maybe it really already (and always) did, you just \nused a particular tool in a way that made the use be really really \npainful.\n\nSometimes it's just a question of \"ok, use it like _this_, and now it's \nactually really simple\". Other times it's \"ok, I didn't even realize that \nyou wanted to use it like _that_, and yeah, that's incredibly \ninconvenient, and we can change it\".\n\nI just got involved in this discussion because I thought people were \ntalking about all the wrong things. Command naming really can't be _that_ \nbig of a deal. I really don't believe that we should have some people use \n\"gh\" instead of \"git\" just because they think \"pull\" should mean not to \nmerge or something.\n\n"},{"id":"297618","messageId":"455CF517.9000101@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611160958170.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T23:32:39Z","receivedAt":"2006-11-16T23:32:39Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"\nLinus Torvalds escreveu:\n>> You're misunderstanding me: the multi-repo is at git.sv.gnu.org is the\n>> remote one. The example I gave was about locally creating a single\n>> project repo from a remote multiproject repo. \n> \n> Ahh.\n> \n> Ok, try the patch I just sent out, and see if it works for you. It \n> _should_ allow you to do exactly that\n\nI'm leaving for a short holiday tomorrow, but will do when I come back.\n\n>> From UI perspective it would be nice if this could also be done with clone,\n>>\n>> git clone . ssh+git://....\n> \n> The creation of a new archive tends to need special rights (with _real_ \n> ssh access and a shell you could do it, but \"ssh+git\" really means \"git \n> protocol over a connection that was opened with ssh, but doesn't \n> necessarily have a real shell at the other end\").\n\nWhat happens on savannah is that the sysadmins set up an empty GIT\nrepo with access, and leave it to you to push the stuff. Of course,\nif the initial import gets packed automatically, that's also ok.\n\n> So I think the above syntax is actually not a good one, because it cannot \n> work in the general case. It's much better to get used to setting up a \n> repo first, and then pushing into it, and just accepting that it's a \n> two-phase thing.\n\nPerhaps ; from a UI viewpoint, it would be nice though, even if it\nwere aliased to a simple push. (Darcs has a get command analogous to\ngit-clone, but also a put command to which git lacks the equivalent).\n\n>> * why are objects downloaded twice? If I do\n>>\n>> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master\n>>\n>> it downloads stuff, but I don't get a branch.\n> [..] \n>> If I then do \n>>\n>> git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master\n>>\n>> it downloads the same stuff again. \n> \n> Right. So you can either\n> [..]\n> See?\n\nNo, I don't understand. In the fetch all the objects with their SHA1s\nwere already downloaded. I'd expect that the fetch with a refspec\nwould simply write a HEAD and a refs/heads/master, and notice that all\nthe actual data was already downloaded, and doesn't download it again. \n\n\n-- \n"},{"id":"297289","messageId":"Pine.LNX.4.63.0611170013590.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161436230.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-16T23:36:31Z","receivedAt":"2006-11-16T23:36:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 16 Nov 2006, Linus Torvalds wrote:\n\n> On Thu, 16 Nov 2006, Johannes Schindelin wrote:\n> >\n> > - a terrible UI.\n> \n> Why? We _do_ have the temporary branch. It's called FETCH_HEAD.\n\nIt is a terrible UI, because it was not that obvious to me. And I consider \nmyself not a git newbie.\n\nBesides, it is not really a temporary branch. If it was, the pull would \n_not_ download all these objects again, would it?\n\n> > _Also_, git-pull not storing the fetched branches at least temporarily \n> > often annoyed me: the pull did not work, and the SHA1 was so far away I \n> > could not even scroll to it.\n> \n> Again, why didn't you use FETCH_HEAD?\n\nBecause I am a Jar-HEAD?\n\n> If the user doesn't give us a head to write to, we clearly MUST NOT write \n> to any long-term branch. That would be a _horrible_ mistake. \n\nI was _not_ suggesting a long-term branch. Just a way to do-what-i-want \nand not waste bandwidth.\n\n> And your \"solution\" is obviously totally unusable. git ABSOLUTELY MUST NOT \n> overwrite any existing branches unless explicitly told to do so by the \n> user.\n\nGuess three times why I did not post the patches.\n\nBut the real problem is not necessarily the behaviour; it is the obscure \nfashion of the behaviour. You may not understand that problem, because you \nwere there from the beginning. You saw the big-bang and how all the \nquarks formed all of a sudden, and how matter and eventually planets \nand suns came into being.\n\nBut others (me included) were not there. Or they did not really watch. And \nnow they see all these creatures, and plants, and bacteria, and they do \nnot understand how these are all connected, because of that. And now they \nthink \"wow that must have been some intelligent design, and really a \nmiracle, and I cannot understand how it works.\" But that is not true \n(the latter part of course).\n\nThere is something to be said about the simplicity of Mercurial. It's \ninner workings may suck, but people get easily attracted by it.\n\nI do not claim we should imitate Mercurial, or even hide the index (even \nif I sometimes wonder if the index is not just a clever way to accelerate \ncommits, and nothing more).\n\n> So I really don't see your point. \n> \n> A lot of the complaints seem to not be about the interfaces, but about \n> people not _understanding_ and knowing what the interfaces do.\n\nBut the interfaces should be usable interfaces! They should _explain_ what \nthey do. Other software does so, it can't be _that_ hard.\n\n> \tgit merge \"$(git fmt-merge-msg < .git/FETCH_HEAD)\" HEAD FETCH_HEAD\n\nI find that quite easy to understand. Why? Because I happen to _know_ the \nsyntax of -merge and -fmt-merge-msg. For similar reasons I _understand_ \nwhy -pull behaves like it does. But others don't; they will shudder and \nthen run.\n\nMaybe it is not important that -pull fetches all objects all over again. \nBut it _is_ important to make things like merging branches (local or \nremote) trivial. It _is_ important to make the user experience be fun.\n\nCiao,\nDscho\n"},{"id":"295920","messageId":"455CF6D3.9050507@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161436230.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-16T23:40:03Z","receivedAt":"2006-11-16T23:40:03Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Linus Torvalds escreveu:\n> A lot of the complaints seem to not be about the interfaces, but about \n> people not _understanding_ and knowing what the interfaces do. If you were \n\nFrom the point of view of a user, there is not really a difference\nbetween the two. As a user, you form a mental model of how things\nwork by looking at the interface. If the interface is bad, the user\ncreates a faulty model in his head, and starts doing things that\nare perfectly logical in the faulty model, but stupid and silly when\nyou consider the actual internals.\n\nA nice book about this is \"The Design of Everyday Things\" by Donald\nNorman.\n\n-- \n"},{"id":"297051","messageId":"455CFCBD.8040901@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161508530.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-17T00:05:17Z","receivedAt":"2006-11-17T00:05:17Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"\n\nLinus Torvalds escreveu:\n> My real point was/is that usually it's really not the \"naming details\" \n> that people _really_ have problems with. The real problems tend to be in \n> learning a new workflow.\n\nI agree that discussions on naming may cloud the issue, but \"learning\nthe workflow\" implies that people should adapt to the limitations of\ntheir tools. That's only a viable stance when the tools are finished\nand completely perfect.\n\nUntil that time, it would be good goal to remove all idiosyncrasies,\nall gratuitious asymetries and needless limitations in the commands of\ngit, eg.\n\n - clone but not a put-clone,\n\n - pull = merge + fetch, but no command for merge + throw\n\n - clone for getting all branches of a repo, but no command for\n updating all branches of a repo. \n\nOf course, when all warts are fixed, backward compatibility will force\nus to choose some new names. At that point, a discussion on naming is\nin place.\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"294921","messageId":"455CFE25.8040705@xs4all.nl","threadId":"6919","inReplyTo":"20061116051240.GV7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-17T00:11:17Z","receivedAt":"2006-11-17T00:11:17Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Petr Baudis escreveu:\n> (vi) Coding issues. This is probably very subjective, but a blocker for\n> me. I have no issues about C here, but about the shell part of Git.\n> Well, how to say it... It's just fundamentally incompatible with me. I\n\n(on a tangent)\n\nI concur, but probably in a different way.\n\nsome 10 years ago I vowed never to write perl code again, and some 5\nyears ago, I made the same pledge for shell scripts, because I spent\ninordinate amounts of time debugging them.\n\nWhen I see the GIT shell scripts, my hands start to itch to make a\nnice object oriented Python wrapper for it.\n\n-- \n"},{"id":"296303","messageId":"7vmz6r2amf.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"455CFCBD.8040901@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T00:13:44Z","receivedAt":"2006-11-17T00:13:44Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Han-Wen Nienhuys writes:\n\n> - clone but not a put-clone,\n\nWhat's put-clone? Care to explain?\n\n> - pull = merge + fetch, but no command for merge + throw\n\nWhat's merge+throw? Care to explain?\n\n> - clone for getting all branches of a repo, but no command for\n> updating all branches of a repo. \n\nThis one I can understand, but how would you propose to \"update\nall branches\", in other words what's your design for mapping\nremote branch names to local branch namespaces?\n\nIt would be nice if the design does not straightjacket different\nrepository layouts different people seem to like, but I think it\nwould be Ok to limit ourselves only to support the straight\none-to-one mapping and support only separate-remote layout.\n"},{"id":"296792","messageId":"455D0209.7070608@xs4all.nl","threadId":"6919","inReplyTo":"7vmz6r2amf.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-17T00:27:53Z","receivedAt":"2006-11-17T00:27:53Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Junio C Hamano escreveu:\n> Han-Wen Nienhuys writes:\n> \n>> - clone but not a put-clone,\n> \n> What's put-clone? Care to explain?\n\nput clone would be the putative inverse of clone, ie. make a clone of\na local repository on a remote server.\n\n>> - pull = merge + fetch, but no command for merge + throw\n> \n> What's merge+throw? Care to explain?\n\nthrow is the hypothetical opposite of fetch. I agree that this is\nacademical, because it's logical to only allow fast-forwards for\nsending revisions.\n\n>> - clone for getting all branches of a repo, but no command for\n>> updating all branches of a repo. \n> \n> This one I can understand, but how would you propose to \"update\n> all branches\", in other words what's your design for mapping\n> remote branch names to local branch namespaces?\n> \n> It would be nice if the design does not straightjacket different\n> repository layouts different people seem to like, but I think it\n> would be Ok to limit ourselves only to support the straight\n> one-to-one mapping and support only separate-remote layout.\n\nI think the whole clone design is a bit broken, in that the \"master\"\nbranch gets renamed or copied to \"origin\", but all of the other\nbranches remain unchanged in their names.\n\nIt's more logical for clone to either\n\n * leave all names unchanged\n\n * put all remote branches into a subdirectory. This would also make\n it easier to track branches from multiple servers.\n\n At present, I have in my build-daemon the following branches,\n\n\tcvs-head-repo.or.cz-lilypond.git\n\thanwen-repo.or.cz-lilypond.git\n\thwn-jcn-repo.or.cz-lilypond.git\n\tlilypond_1_0-repo.or.cz-lilypond.git\n\tlilypond_1_2-repo.or.cz-lilypond.git\n\tlilypond_1_4-repo.or.cz-lilypond.git\n\tlilypond_1_6-repo.or.cz-lilypond.git\n\tlilypond_1_8-repo.or.cz-lilypond.git\n\tlilypond_2_0-repo.or.cz-lilypond.git\n\tlilypond_2_2-repo.or.cz-lilypond.git\n\tlilypond_2_3_2b-repo.or.cz-lilypond.git\n\tlilypond_2_3_5b-repo.or.cz-lilypond.git\n\tlilypond_2_4-repo.or.cz-lilypond.git\n\tlilypond_2_6-repo.or.cz-lilypond.git\n\tlilypond_2_8-repo.or.cz-lilypond.git\n\tmaster-git.sv.gnu.org-lilypond.git\n\tmaster-hanwen\n\tmaster-repo.or.cz-lilypond.git\n\torigin-repo.or.cz-lilypond.git\n\tstable\n\tstable-2.10\n\tstable--2.10-git.sv.gnu.org-lilypond.git\n\n It would solve lots of problems for me if cloning and fetching would\n put branches into a subdirectory, ie.\n\n git clone git://repo.or.cz/lilypond.git\n\n leads to branches\n\n repo.or.cz/lilypond_2_8\n repo.or.cz/lilypond_2_6\n repo.or.cz/lilypond_2_4\n repo.or.cz/master\n (etc..)\n\n\t\n-- \n"},{"id":"297076","messageId":"Pine.LNX.4.63.0611170048270.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"7vmz6r3tat.fsf@assigned-by-dhcp.cox.net","subject":"Re: multi-project repos","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-17T00:29:14Z","receivedAt":"2006-11-17T00:29:14Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 16 Nov 2006, Junio C Hamano wrote:\n\n> I think the earlier write-up by Linus on magic HEADs would help \n> documenting FETCH_HEAD better.\n\nI am not sure that documenting FETCH_HEAD better would help. As Han-Wen \npointed out (and some colleagues of mine who would never subscribe to a \nmailing list), people do not read the manual, but rather try to wrap their \nheads around the inner workings from the interface. And FETCH_HEAD just \ndoes not meet _any_ expectation a sane (read: untainted) user might have.\n\nWhile I'm at it: the problem I pointed out with -pull may annoy just me.\n\nBut there is another problem with \"git fetch\": a common work flow is \ntracking other peoples branches. And since git makes it so easy to \nhave multiple branches, chances are that you track more than one \nbranch per remote repository.\n\nNow, an old gripe of mine was the lack of \"git fetch --all\". I wrote a \nscript for that (Linus would be proud of me!), which just does \"git \nls-remote\" and constructs a command line for \"git fetch\" from that.\n\nBut even if you agree with the common story that you should specify the \nbranches you want to track: it is hard!\n\nIf I were new to git, after reading some tutorials I would _expect_ \"git \nfetch\" to be the tool to track branches. (I posted a patch to at least be \nable to store the current \"git fetch\" command line under a nick IIRC). But \nit does not.\n\n(Of course, after reading several documentation, as a new user I would \neventually find that I should edit .git/remotes/, or even \nedit/-repo-config the remotes information in the config, but I would fully \nexpect a new user to give up before reaching that stage.)\n\nBut maybe I got it all wrong and this is not the common expectation...\n\nCiao,\nDscho\n"},{"id":"297585","messageId":"20061117003510.GB7201@pasky.or.cz","threadId":"6919","inReplyTo":"455D0209.7070608@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-17T00:35:11Z","receivedAt":"2006-11-17T00:35:11Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Nov 17, 2006 at 01:27:53AM CET, Han-Wen Nienhuys wrote:\n> put clone would be the putative inverse of clone, ie. make a clone of\n> a local repository on a remote server.\n\nSo effectively to tell git push not to unpack on the remote side, and to\npush all branches and relevant tags.\n\n..snip..\n> It's more logical for clone to either\n> \n> * leave all names unchanged\n> \n> * put all remote branches into a subdirectory. This would also make\n> it easier to track branches from multiple servers.\n> \n> At present, I have in my build-daemon the following branches,\n> \n> \tcvs-head-repo.or.cz-lilypond.git\n> \thanwen-repo.or.cz-lilypond.git\n> \thwn-jcn-repo.or.cz-lilypond.git\n> \tlilypond_1_0-repo.or.cz-lilypond.git\n> \tlilypond_1_2-repo.or.cz-lilypond.git\n> \tlilypond_1_4-repo.or.cz-lilypond.git\n> \tlilypond_1_6-repo.or.cz-lilypond.git\n> \tlilypond_1_8-repo.or.cz-lilypond.git\n> \tlilypond_2_0-repo.or.cz-lilypond.git\n> \tlilypond_2_2-repo.or.cz-lilypond.git\n> \tlilypond_2_3_2b-repo.or.cz-lilypond.git\n> \tlilypond_2_3_5b-repo.or.cz-lilypond.git\n> \tlilypond_2_4-repo.or.cz-lilypond.git\n> \tlilypond_2_6-repo.or.cz-lilypond.git\n> \tlilypond_2_8-repo.or.cz-lilypond.git\n> \tmaster-git.sv.gnu.org-lilypond.git\n> \tmaster-hanwen\n> \tmaster-repo.or.cz-lilypond.git\n> \torigin-repo.or.cz-lilypond.git\n> \tstable\n> \tstable-2.10\n> \tstable--2.10-git.sv.gnu.org-lilypond.git\n> \n> It would solve lots of problems for me if cloning and fetching would\n> put branches into a subdirectory, ie.\n> \n> git clone git://repo.or.cz/lilypond.git\n> \n> leads to branches\n> \n> repo.or.cz/lilypond_2_8\n> repo.or.cz/lilypond_2_6\n> repo.or.cz/lilypond_2_4\n> repo.or.cz/master\n> (etc..)\n\nThat's basically exactly what git clone --use-separate-remote should do.\nNow only if it would become the default... :-)\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i > - clone for getting all branches of a repo, but no command for\n> > updating all branches of a repo.\n\nI want this one as well.\n\n> This one I can understand, but how would you propose to \"update\n> all branches\", in other words what's your design for mapping\n> remote branch names to local branch namespaces?\n\nAs long as its consistent with \"clone\" I'll be happy, (I think as part\nof a separate topic we need to fix the mappings in clone, see\n--use-separate-remotes as default and related).\n\nThe current case is really annoying where I have to throw use clone\ninto a new repository just to get everything, rather than just being\nable to fetch everything into the repository I already have.\n\n-Carl\n"},{"id":"296198","messageId":"Pine.LNX.4.64.0611161623170.3349@woody.osdl.org","threadId":"6919","inReplyTo":"455CFCBD.8040901@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-17T00:39:11Z","receivedAt":"2006-11-17T00:39:11Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 17 Nov 2006, Han-Wen Nienhuys wrote:\n> \n> Until that time, it would be good goal to remove all idiosyncrasies,\n> all gratuitious asymetries and needless limitations in the commands of\n> git, eg.\n\nWell, a lot of the assymmetries aren't actually gratuitous at all.\n\n> - clone but not a put-clone,\n\nAs mentioned, in order to \"put-clone\", you generally have to \"create\" \nfirst, so the \"put-clone\" really makes no sense.\n\nThe _true_ reverse is really your\n\n - \"git init-db\" on both sides\n\n - \"git pull\" (your workflow ;) on receiving\n\n - \"git push\" on sending.\n\nThe fact that we can do \"git clone\" on the _receiving_ side is an \nassymmetry, but it's not gratutous: when receiving we don't need any extra \npermissions or setup to create a new archive. In contrast, when sending, \nyou do have to have that \"get permission to create new archive\" phase.\n\n> - pull = merge + fetch, but no command for merge + throw\n\nAgain, this is not gratuitous, and the reason is very similar: when you \npull, you're pulling into something that _you_ control and _you_ have \naccess to, namely your working directory. In order to merge you have to \nhave the ability to fix up conflicts (whether automatically or manually), \nand this is something that you _fundamentally_ can only do when you own \nthe repo space.\n\nAgain, when you do \"push\", the reason you can't merge is not a \"gratuitous \nassymmetry\", but a _fundamental_ assymmetry: by definition, you're pushing \nto a _remote_ thing, and as such you can't merge, because you can't fix up \nany merge problems.\n\nSee?\n\nIn many ways, if you want _symmetry_, you need to make sure that the \n_cases_ are symmetrical. If you have ssh shell access, you can often do \nthat, and the \"reverse\" of a \"git pull\" is actually just another \"git \npull\" from the other side:\n\n\tssh other-side \"cd repo ; git pull back\"\n\nNow they really _are_ symmetrical: \"git pull\" is really in many ways ITS \nOWN reverse operation. \n\nBut \"push\" and \"pull\" _fundamentally_ aren't symmetric operations, and you \nsimply cannot possibly make them symmetric. Any system that tries would be \nabsolutely horrible to use, exactly because it would be either:\n\n - making local/remote operations totally equivalent\n\n This sounds like a \"good\" thing, but from a real user perspective it's \n actually horribly horribly bad. Knowing the difference between local \n and remote is what allows a lot of performance optimizations, and a lot \n of security. Your local repo is _yours_, and nobody can take that away \n from you, and that's a really fundamental reason for why the symmetry \n cannot exist, and why local/remote operations MUST NOT be something \n that you can mix without thinking about them,\n\n - limit local operations in a way to make them effectively unusable and \n unscriptable.\n\n You'd basically have to do everything even _locally_ through some \n server interface, and you'd not be allowed to ever touch your local \n checked-out repository directly. Again: local repositories really _are_ \n special, because you can touch the checked out copy. If you try to \n suppress that, you're screwed.\n\n> - clone for getting all branches of a repo, but no command for\n> updating all branches of a repo. \n\nAs in sending? Sure there is: use \"git push --all\". It will push out every \nbranch (and tag) you have. Add \"--force\" if you want to make sure that it \nalso pushed out branches even if the result isn't a strict superset (of \ncourse, the receiving end may actually end up refusing to take it, there's \na option for the receiver to say \"I will refuse any update that isn't a \nstrict superset of what I had\").\n\nIf you mean as in \"receiving new branches\", then yeah, you do have to \nscript it, with some fairly trivial \"git ls-remote\" to make sure you get \nthe new remotes.\n\n"},{"id":"295831","messageId":"Pine.LNX.4.64.0611161642320.3349@woody.osdl.org","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611170013590.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-17T00:49:29Z","receivedAt":"2006-11-17T00:49:29Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 17 Nov 2006, Johannes Schindelin wrote:\n> > Why? We _do_ have the temporary branch. It's called FETCH_HEAD.\n> \n> It is a terrible UI, because it was not that obvious to me. And I consider \n> myself not a git newbie.\n\nHeh. The \"temporary branches\" are actually the _original_ branches as far \nas git is concerned. The long-term branches only came later.\n\nSo in many ways, HEAD, FETCH_HEAD, MERGE_HEAD and ORIG_HEAD are more \nfundamental than any long-term branch has ever been, and maybe they should \nbe taught first as such.\n\nSo you're newbie enough that you've only seen those new-fangled \"real\" \nbranches.\n\nWhen I was young, we had to walk to school up-hill in three feet of snow \nevery day. And we _liked_ our FETCH_HEAD's.\n\n> Besides, it is not really a temporary branch. If it was, the pull would \n> _not_ download all these objects again, would it?\n\nWell, exactly because they are temporary, we can't actually trust the \nobjects they point to. They have no \"real\" long-term life, so no, I'm \nafraid that we always will have to re-fetch the objects, because fetching \nthem is the only way to know that we still have them. \n\nThat said, we could certainly _make_ them be honored by things like \"git \nprune\" and friends. But yes, they really _are_ temporary branches right \nnow, and part of the meaning of that \"temporary\" is exactly the fact that \ngit fetch will not trust that you still have the objects. \n\nFor example, if you used one of the old-fashioned commit walkers, maybe we \ngot the initial commit, but we may not have gotten the whole _chain_. See?\n\nTemporary branch indeed.\n\n> > Again, why didn't you use FETCH_HEAD?\n> \n> Because I am a Jar-HEAD?\n\nWell, we clearly should document them better. Anybody?\n\n"},{"id":"297129","messageId":"455D07C1.1090207@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161623170.3349@woody.osdl.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-17T00:52:17Z","receivedAt":"2006-11-17T00:52:17Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Linus Torvalds escreveu:\n> The fact that we can do \"git clone\" on the _receiving_ side is an \n> assymmetry, but it's not gratutous: when receiving we don't need any extra \n> permissions or setup to create a new archive. In contrast, when sending, \n> you do have to have that \"get permission to create new archive\" phase.\n> \n>> - pull = merge + fetch, but no command for merge + throw\n> \n> Again, this is not gratuitous, and the reason is very similar: when you \n> pull, you're pulling into something that _you_ control and _you_ have \n\n>But \"push\" and \"pull\" _fundamentally_ aren't symmetric operations, and you \n>simply cannot possibly make them symmetric. \n\nPoint taken; thank you. \n\nIn that case, we're full circle with the command naming issues. Push\nand pull are fundamentally asymmetric operations, but then a\nconsistent UI would dictate that they wouldn't be named symmetrically,\nas they are now.\n\n\n-- \n"},{"id":"294797","messageId":"87r6w2ribu.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161642320.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-17T01:08:05Z","receivedAt":"2006-11-17T01:08:05Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 16 Nov 2006 16:49:29 -0800 (PST), Linus Torvalds wrote:\n> So in many ways, HEAD, FETCH_HEAD, MERGE_HEAD and ORIG_HEAD are more\n> fundamental than any long-term branch has ever been, and maybe they should\n> be taught first as such.\n\nOlder in git's history as it developed is not a good match for more\nfundamental in the concepts that git makes available today.\n\n> > > Again, why didn't you use FETCH_HEAD?\n> >\n> > Because I am a Jar-HEAD?\n>\n> Well, we clearly should document them better. Anybody?\n\nI for one am totally unsatisfied with this approach.\n\nHere's an operations I'd like to be able to do:\n\n\tGiven a (URL, branch) pair I'd like I'd like to be able to\n\tinvestigate that code, (say with the fancy new \"read-only\n\tbranch\" concept we've been talking about).\n\nWhat are my options for this operation? What might a new user's\nreaction to them be?\n\na) git fetch URL branch\n git checkout FETCH_HEAD\n\n This is really ugly. A name like \"FETCH_HEAD\" is something a user\n should really never have to type. It's hideously hard to type and\n has no natural discoverability. Yuck, yuck, yuck.\n\nb) vi .git/remotes/something\n git fetch something\n git checkout branch\n\n Also yuck. I hope it's obvious that having to edit a configuration\n for this simple operation is a non-starter.\n\nc) git fetch URL branch:local-branch\n git checkout local-branch\n\n We're getting close to the desired functionality now, but the UI\n makes users cringe? \"What's that : for?\" Why do I need another\n name?\" etc. Linus, you yourself said this is a form that users\n should generally avoid.\n\nd) git fetch URL branch:branch\n git checkout branch\n\n One step closer. But there's still that goofy extra ':' and a\n doubled name in the first command. \"Why is that there? Git sure is\n weird...\".\n\nWhat I think this operation should look like is:\n\n\tgit fetch URL branch\n\tgit checkout branch\n\nAnd the fetch should just complain if there's a name clash. Or better,\nthe fetch should tuck the fetched branch into its own URL-specific\nnamespace and then the checkout command can kindly prompt if there is\nany ambiguity:\n\n\tWhich \"branch\" do you want?\n\t\tlocal/branch\n\t\tremote-url/branch\n\nor whatever.\n\nSee? That's what reasonable UI should look like.\n\nPlease feel free to keep using vestiges like FETCH_HEAD as much as you\nlike, but please don't recommend documenting them better as a solution\nfor UI warts in git. (If you would only look at these warts closer,\nyou'd see they have some lovely locks of hair on them.)\n\n-Carl\n"},{"id":"297284","messageId":"Pine.LNX.4.63.0611170216190.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161642320.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-17T01:22:35Z","receivedAt":"2006-11-17T01:22:35Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 16 Nov 2006, Linus Torvalds wrote:\n\n> On Fri, 17 Nov 2006, Johannes Schindelin wrote:\n> \n> > Besides, it is not really a temporary branch. If it was, the pull would \n> > _not_ download all these objects again, would it?\n> \n> Well, exactly because they are temporary, we can't actually trust the \n> objects they point to.\n\nNonono.\n\nWe made _sure_ that FETCH_HEAD is only written once _all_ the objects were \nreceived. So, actually, we _can_, and we _should_ trust the objects they \npoint to!\n\nOr did I miss something?\n\n> For example, if you used one of the old-fashioned commit walkers, maybe we \n> got the initial commit, but we may not have gotten the whole _chain_. See?\n\nHuh? I am quite certain that FETCH_HEAD is not updated in that case. If it \nis, that's a bug.\n\nCiao,\n"},{"id":"298167","messageId":"87psbmrhig.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"7vmz6r2amf.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-17T01:25:43Z","receivedAt":"2006-11-17T01:25:43Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Thu, 16 Nov 2006 16:13:44 -0800, Junio C Hamano wrote:\n> This one I can understand, but how would you propose to \"update\n> all branches\", in other words what's your design for mapping\n> remote branch names to local branch namespaces?\n\nWhat I want here is a command \"git update\" that fetches and\nfast-forwards the all branches which are designated as \"tracking\" a\nbranch in some known remote repository. And git-clone would setup all\nbranches appropriately so that they would be updated by git-update.\n\nAdditionally, it would be nice if git-update would also create new\ntracking branches for all remotes repositories that had been\ndesignated as being tracked, (and git-clone would do this as well).\n\nThere should also be a mechanism to easily create new tracking support\nfor specific branches or all branches of a repository, (could be \"git\nfetch URL branch\" or \"git fetch --all URL\", for example).\n\nWith this kind of setup, I would use \"git update\" regularly, and only\never merge locally. And by definition merging with any local tracking\nbranch would have just as much information available as \"pull URL\nbranch\" so the message would be the same.\n\nI've been using git for 10-11 months, so I think I understand the\nmodels fairly well, and I'd be really happy with a setup like that. I\nalso have talked with a fair number of (non-git-using) users who think\ngit is confusing, but I think would find the above scenario just fine.\n\nIn this scenario, git pull would still work just fine, but it would\nalso be much easy to teach a workflow that didn't use pull at all, so\nif there's any git-pull confusion that's an actual problem, it could\nbe avoided.\n\nJunio, what do you think of a setup something like that? I really\ndon't want to create a command other than \"git\" to implement it.\n\n-Carl\n"},{"id":"297232","messageId":"f2b55d220611161734m49136e6fneda5b002eb67618b@mail.gmail.com","threadId":"6919","inReplyTo":"455CFCBD.8040901@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-17T01:34:38Z","receivedAt":"2006-11-17T01:34:38Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"I think there's a fundamental assumption built into the design of git\nthat most programmers accustomed to a corporate environment don't\nunderstand. Namely, that each programmer owns his or her entire\n\"repository\", and can do whatever he or she darn well pleases with it\nat any time. Go ahead and create hundreds of transient branches as\npart of a scripted \"merge complexity metric\" calculation. Try three\ndifferent refactoring strategies on different branches, abandon two of\nthem, and prune them months later. And generally use the power of the\nSCM to juggle a lot of things at once, because there's no sysadmin\ngatekeeper stopping you, and the thing is designed and coded scalably\nso it doesn't grind to a halt as soon as everyone has dozens of\nprivate branches.\n\nEven if you do find a way to push git in a direction that it doesn't\nscale, it's no one's problem but your own -- people who pull from you\nare pulling the _content_ on the branches they care about, not the\nstructure of your repository.\n\nOn 11/16/06, Han-Wen Nienhuys wrote:\n> I agree that discussions on naming may cloud the issue, but \"learning\n> the workflow\" implies that people should adapt to the limitations of\n> their tools. That's only a viable stance when the tools are finished\n> and completely perfect.\n>\n> Until that time, it would be good goal to remove all idiosyncrasies,\n> all gratuitious asymetries and needless limitations in the commands of\n> git, eg.\n\nOne person's gratuitous asymmetry is another's minimalism. (If the\nsymmetric thing doesn't make any sense or can't be implemented\nscalably, leave it out.) It is more important that git continue to\nwork than that it appear symmetric without reference to its function.\n\n> - clone but not a put-clone,\n\nWhat possible use would that be? git is not rsync.\n\n> - pull = merge + fetch, but no command for merge + throw\n\npull = fetch + merge. It is (almost?) always followed by a judgment\ncall based on the merge results. merge + throw doesn't make any sense\nin terms of the job at hand, which is facilitating human judgments\nabout whether to accept someone else's work into one's working tree.\n\n> - clone for getting all branches of a repo, but no command for\n> updating all branches of a repo.\n\nclone is shorthand for the steps involved in setting up a new\nrepository with content similar to an existing one. There isn't any\nmerge involved, and no scope for human judgment, so it's simplest to\nclone the whole state of the remote repository (including tags and\nbranches) and let the user blow away any branches he doesn't need.\nBut once the clone is done, all of those branches are _truly_ _local_\n-- they don't retain any reference to the remote branches, and you can\ncommit to all of them. The only entry placed in .git/remotes is the\n\"origin\" of the new clone, which is the \"master\" of the remote\nrepository. That's for the user's convenience, and is about the only\nthing in the new clone that _isn't_ a copy of something in the remote\ntree.\n\nSo the \"update all\" process wouldn't look anything like a clone, it\nwould be a fetch and replay of each remote branch onto the\ncorresponding local branch. You and Carl seem to want \"git clone\" not\nonly to copy the heads of the remote branches but to populate\n.git/remotes with trackers for all of those branches, and then to\nstart each \"git update\" by polling all of the remote repositories to\nsee if branches have been created or deleted, then pull every branch\nin sight. What do you do when \"upstream\" creates a branch with the\nsame name as a local branch you have created? How do you deal with\nbranch points that don't exist in your repository because you touched\none of the \"tracker\" branches between pulls?\n\nIn short, if you want a local, read-only tracker for a whole remote\nrepository instead of a branch that's actually published to you (and\nmaintained accordingly), you might consider s/git/rsync/.\n\nCheers,\n"},{"id":"295018","messageId":"7vejs2zvu1.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"20061116222008.GA7201@pasky.or.cz","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T01:49:10Z","receivedAt":"2006-11-17T01:49:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Petr Baudis writes:\n\nYou already said this kind of details are subjective so I'd omit\nthe usual \"I would think\" and answer them without worrying about\na big style flamewar. People, please be civil ;-).\n\n> What about [ instead of test?\n\n[ ] is not more readable.\n\n> \tif foo; then\n>\n> instead of\n>\n> \tif foo\n> \tthen\n\nHaving \"then\" on the beginning of line is much more readable.\n\n> Am I the only one who hates\n>\n> case \"$log_given\" in\n> tt*)\n> die \"Only one of -c/-C/-F can be used.\" ;;\n> *tm*|*mt*)\n> die \"Option -m cannot be combined with -c/-C/-F.\" ;;\n> esac\n\nThis is much more readable without \"case\". \"abandon the old\nrule that told us to avoid if when case would do\" applies.\nAlthough it is about multiple possibility switch (so a case can\nbe made that \"case\" is appropriate here), we should reduce the\nuse of \"case\" to cases like the outermost big \"case\" you find in\ngit-merge-one-file-script.\n\n> It would be really great if Git would have something alike the Cogito's\n> optparse infrastructure. I'm not sure if you can implement it in Bourne\n> sh with reasonable performance, though...\n\ngetopt(1) is fine, unless somebody screams that it is not\navailable on his platform.\n"},{"id":"294250","messageId":"20061117015238.GD7201@pasky.or.cz","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611170216190.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-17T01:52:38Z","receivedAt":"2006-11-17T01:52:38Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:\n> On Thu, 16 Nov 2006, Linus Torvalds wrote:\n> > For example, if you used one of the old-fashioned commit walkers, maybe we \n> > got the initial commit, but we may not have gotten the whole _chain_. See?\n> \n> Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it \n> is, that's a bug.\n\nIt may be updated and then things may break _afterwards_. git-prune will\nhappily blow anything referenced by FETCH_HEAD, it's not considered by\nthe fsck-objects reachability analysis.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i On Fri, Nov 17, 2006 at 02:22:35AM CET, Johannes Schindelin wrote:\n> > On Thu, 16 Nov 2006, Linus Torvalds wrote:\n> > > For example, if you used one of the old-fashioned commit walkers, maybe we \n> > > got the initial commit, but we may not have gotten the whole _chain_. See?\n> > \n> > Huh? I am quite certain that FETCH_HEAD is not updated in that case. If it \n> > is, that's a bug.\n> \n> It may be updated and then things may break _afterwards_. git-prune will\n> happily blow anything referenced by FETCH_HEAD, it's not considered by\n> the fsck-objects reachability analysis.\n\nThis actually underlines my point: FETCH_HEAD is no _real_ branch, not \neven a temporary one. If it was, git-prune would not lose the related \nobjects.\n\nCiao,\nDscho\n"},{"id":"295276","messageId":"f2b55d220611162242s48dc42d6g4cbfd9173e712ff8@mail.gmail.com","threadId":"6919","inReplyTo":"f2b55d220611161734m49136e6fneda5b002eb67618b@mail.gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Michael K. Edwards","fromEmail":"medwards.linux@gmail.com","sentAt":"2006-11-17T06:42:55Z","receivedAt":"2006-11-17T06:42:55Z","isPatch":false,"sender":{"key":"medwards.linux@gmail.com","avatar":null},"body":"On 11/16/06, Michael K. Edwards wrote\n> The only entry placed in .git/remotes is the\n> \"origin\" of the new clone, which is the \"master\" of the remote\n> repository. That's for the user's convenience, and is about the only\n> thing in the new clone that _isn't_ a copy of something in the remote\n> tree.\n\nActually, this \"origin\" entry does contain \"Pull:\" lines for all of\nthe branches that were cloned, so that \"git pull\" fetches and merges\nupdates to all of these branches. (If upstream is in the habit of\nreverting things, you may need \"git pull -f\"; I just did that on the\ngit repo to handle a failure to fast-forward on the \"pu\" branch.)\n\nPresumably \"git branch -D\" should inspect everything under\n.git/remotes to see whether one or more Pull: lines need to be deleted\nalong with the branch. Currently, it looks like \"remotes\" entries are\ncreated only by \"git clone\" or by hand. Junio, are there any plans to\nmanage the contents of \"remotes\" through the tool instead of by hand?\n\nCheers,\n"},{"id":"296385","messageId":"7v64dev88t.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"f2b55d220611162242s48dc42d6g4cbfd9173e712ff8@mail.gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T07:32:18Z","receivedAt":"2006-11-17T07:32:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Michael K. Edwards\" writes:\n\n> Presumably \"git branch -D\" should inspect everything under\n> .git/remotes to see whether one or more Pull: lines need to be\n> deleted along with the branch.\n\nI am not sure what you mean. .git/remotes files do not describe\nany relationship between local branches (and that is where one\nof the problem raised in recent thread -- pull does not notice\non which branch you are on and change its behaviour depending on\nit), so I do not think there is anything gained for \"git branch\n-D\" by going through them.\n\n> Currently, it looks like \"remotes\" entries are\n> created only by \"git clone\" or by hand. Junio, are there any plans to\n> manage the contents of \"remotes\" through the tool instead of by hand?\n\nI muttered something in a near-by thread\n\n\tMessage-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>\n\nI am reasonably sure a separate tool (what I tentatively called\n\"maint-remote\" in the message) is necessary, because, while it\nwould be relatively easy to make \"git fetch\" and friends to add\nnew mappings in the default way under a new option, people with\ndifferent workflows would want differnt \"default mappings\", and\nadding new mappings for _all_ remote branches is useful only for\npeople who work in one particular way (namely, the CVS-style\n\"the central distribution point is where everybody meet\" model).\n\nThe tool, under \"interactive\" mode, would probably take one\nparameter, the short name of a remote ($name), and would give\nyou a form to update its URL:, shows ls-remote output against\nthat repository and would let you:\n\n - update the URL: which would probably cause the ls-remote to\n be re-run;\n\n - remove existing mappings;\n\n - add mappings for a remote branch for which you do not have a\n corresponding tracking branch, with a straightforward default\n mapping:\n\n \trefs/heads/$branch:refs/remotes/$name/$branch\n\nBut I haven't thought things through yet.\n\n"},{"id":"296822","messageId":"7vu00ysbwi.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"87r6w3b68p.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T08:41:33Z","receivedAt":"2006-11-17T08:41:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> On Thu, 16 Nov 2006 09:57:00 -0800, \"Michael K. Edwards\" wrote:\n>> What do you want all of those branches for? They haven't been\n>> published to you (that's a human interaction that doesn't go through\n>> git), so for all you know they're just upstream experiments, and doing\n>> things with them is probably shooting yourself in the foot.\n>\n> The same \"what do you want them all for\" question could be asked of\n> git-clone which also fetches all available branches. I really just\n> want to be able to easily watch what's going on in multiple\n> repositories.\n>\n> I want to be able to just say \"git update\" (or whatever) and then be\n> able to list and browse and explore the stuff locally.\n>...\n\nI have no objection to this if it is done in a controlled way\nthat does not make life more difficult for people who work with\nmultiple remote repositories.\n\nAnd I think \"git fetch\" is the tool for what you want if\nenhanced properly; see Linus's message that explaind that we\nalready have that support in \"manually configurable\" form but\ninitializing and maintaining the configuration is currently all\nmanual and can be improved.\n\n"},{"id":"295503","messageId":"87ejs2qvmb.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"7vu00ysbwi.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-17T09:18:36Z","receivedAt":"2006-11-17T09:18:36Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 17 Nov 2006 00:41:33 -0800, Junio C Hamano wrote:\n> I have no objection to this if it is done in a controlled way\n> that does not make life more difficult for people who work with\n> multiple remote repositories.\n\nThat's fine with me. Maybe I didn't explain this well before, but my\ndesire is exactly for this to work with multiple repositories.\n\nSpecifically, what we have in cairo is a \"central\" shared tree that\nmany people push to. But we only have two branches there, (one for\nbug-fixes only for our stable releases, and one for ongoing\ndevelopment of new features, and that only of stuff that's well\ncooked).\n\nSo that tree looks and acts an awful lot like our cvs tree back in the\npast. It's often very linear and often fairly boring to look at in gitk.\n\nMeanwhile, all the really interesting stuff happens in personal\nrepositories where people have their own branches for stuff that is\nstill getting cooked. This is what's a lot more fun to watch, and\nthere's a lot more distributed back-and-forth that goes on here as\npeople collaborate on things. And it's all this kind of collaboration\nthat cvs never helped with at all, but git has been great.\n\nSo, what I want is both \"git update\" for the central tree. I said we\nonly have two branches, but that's really only two that are\nactive---the \"stable\" branch is actually a new branch after every\nmajor release. It was 1.0 for a while, is 1.2 now, and will be 1.4\nlater. So I want \"git update\" to automatically pick those new branches\nup as they get created.\n\nMeanwhile, I also want to use \"git update\" to track everything that\npeople are working on in the more wild personal trees. So, yes, I do\nwant \"git update\" to be able to track lots of remote repositories in a\nsane way.\n\nWhat I have been doing up to this point is a little script I wrote\nthat does git-ls-remote on the repository I want to track and writes a\n.git/remotes file to bring in all their branches. So if I want to see\nwhat behdad is up to, I first refresh his .git/remotes file with my:\n\n\tcairo-git-setup-remotes behdad\nthen:\n\tgit fetch behdad\n\nAnd I end up with a bunch of branch names with \"behdad-\" prefixes that\nI can explore or blow away if I'm no longer interested, (could have\nused a \"behdad/\" prefix as well).\n\nThe first problem we ran into when doing that months ago was that I\ndon't want any tracking branches to come across this way. Or else I\nend up with behdad-origin, he then gets cworth-behdad-origin, ad\nnauseum. So we filtered \"origin\" out, but it will be nice to revisit\nthis if there's a sane distinction in git now to separate tracking\nbranches from heads.\n\n> And I think \"git fetch\" is the tool for what you want if\n> enhanced properly; see Linus's message that explaind that we\n> already have that support in \"manually configurable\" form but\n> initializing and maintaining the configuration is currently all\n> manual and can be improved.\n\nYes, git-fetch is lovely, and it's the need for manual configuration\nthat's a problem, (and the mixing up of heads and remote tracking\nbranches that has been in git historically).\n\nSo, yes, I'll definitely look into improving this. I think the details\nwill involve:\n\n1. Making clone do the --use-separate-remotes behavior by default\n\n2. Taking advantage of that consistently for all branches instead of a\n special master:origin mapping in clone\n\n3. Enhancing git-fetch (or other) to modify .git/remotes, (or was\n there a desire for some other branch-specific section in the config\n file?)\n\n4. Making git-fetch handle the disappearance of a remote branch\n gracefully\n\n5. Adding something like git-fetch --all to allow it to pick up all new\n branches\n\n6. Adding a \"git update\" that does a fetch for all appropriately\n marked remotes.\n\nOn this last point, maybe we do something like:\n\n\tupdate=no|yes|all\n\nin .git/remotes. Then git-clone would set this up with update=all for\norigin so git-update would do a \"fetch --all\" on the origin\nrepository. Then step 3 above would have to provide for setting this\nupdate option as appropriate.\n\nAnyway, something along those lines perhaps. Any feedback?\n\n-Carl\n"},{"id":"298397","messageId":"Pine.LNX.4.63.0611171103150.13772@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"87ejs2qvmb.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-11-17T10:11:19Z","receivedAt":"2006-11-17T10:11:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 17 Nov 2006, Carl Worth wrote:\n\n> 1. Making clone do the --use-separate-remotes behavior by default\n\nFully agree.\n\n> 2. Taking advantage of that consistently for all branches instead of a\n> special master:origin mapping in clone\n\nFully agree, too.\n\n> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was\n> there a desire for some other branch-specific section in the config\n> file?)\n\nI introduced the remote..{url,fetch,push} entries into the config \nwith the goal to enhance -fetch to remember the current command line with \na setting. I was the only one to find that useful.\n\nBTW I still would argue that it is better to write the remote information \ninto the config, because you have a saner way to manipulate that from \nscripts than .git/remotes/.\n\n> 4. Making git-fetch handle the disappearance of a remote branch\n> gracefully\n\nI think a message like \"This remote branch no longer exists. Maybe you \nwant to use 'git branch -d ' to remove it locally?\" should \nsuffice.\n\n> 5. Adding something like git-fetch --all to allow it to pick up all new\n> branches\n\nIIRC this idea was rejected, but I would find it useful. Especially with \nwhat Han-Wen said: you can store the branches you fetch with \"git fetch \n--all \" under .git/refs/remotes//.\n\n> 6. Adding a \"git update\" that does a fetch for all appropriately\n> marked remotes.\n> \n> On this last point, maybe we do something like:\n> \n> \tupdate=no|yes|all\n> \n> in .git/remotes. Then git-clone would set this up with update=all for\n> origin so git-update would do a \"fetch --all\" on the origin\n> repository. Then step 3 above would have to provide for setting this\n> update option as appropriate.\n\nFirst thought was: it is only useful if you want to track multiple \nrepositories. But next thought: if you mark the correct remotes in every \nof your local repositories, you don't have to remember which nick your \nupstream has. Yeah, I like it. But maybe do it as \"git fetch --update\" to \navoid more cluttering of the bindir?\n\nCiao,\nDscho\n"},{"id":"295407","messageId":"7v3b8inwf7.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"87ejs2qvmb.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T11:29:32Z","receivedAt":"2006-11-17T11:29:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> What I have been doing up to this point is a little script I wrote\n> that does git-ls-remote on the repository I want to track and writes a\n> .git/remotes file to bring in all their branches. So if I want to see\n> what behdad is up to, I first refresh his .git/remotes file with my:\n>\n> \tcairo-git-setup-remotes behdad\n> then:\n> \tgit fetch behdad\n>\n> And I end up with a bunch of branch names with \"behdad-\" prefixes that\n> I can explore or blow away if I'm no longer interested, (could have\n> used a \"behdad/\" prefix as well).\n\nI would suggest refs/remotes/behdad.\n\n> So, yes, I'll definitely look into improving this. I think the details\n> will involve:\n>\n> 1. Making clone do the --use-separate-remotes behavior by default\n>\n> 2. Taking advantage of that consistently for all branches instead of a\n> special master:origin mapping in clone\n\nThis already should be the case if you use separate-remote. I\nhaven't run \"clone --separate-remote\" myself for a long time,\nbut the design was certainly to make it behave that way.\nSpecifically, map everything in refs/heads/ at remote to\nrefs/remotes/$origin/ with corresponding names, one-to-one.\n\nI do not see much reason to change the mapping of master:origin\nwhich is done for the traditional layout. The traditional\nlayout is not suitable for your workflow anyway, and that is why\nyou prefer separate-remote layout for your project, and I fully\nagree it would suit you better.\n\n> 3. Enhancing git-fetch (or other) to modify .git/remotes, (or was\n> there a desire for some other branch-specific section in the config\n> file?)\n>\n> 4. Making git-fetch handle the disappearance of a remote branch\n> gracefully\n>\n> 5. Adding something like git-fetch --all to allow it to pick up all new\n> branches\n\nThese three are easily done for separate-remote layout but at\nthat point you would not want --all but more powerful --mirror\n(or --update if you want to use that word), which goes the whole\nnine yards of noticing disappearance of remote branch, making\nmatching deletion of local tracking branch, updating\n.git/remotes, etc. I've muttered something similar in a nearby\nthread; see below.\n\n> 6. Adding a \"git update\" that does a fetch for all appropriately\n> marked remotes.\n>\n> On this last point, maybe we do something like:\n>\n> \tupdate=no|yes|all\n>\n> in .git/remotes. Then git-clone would set this up with update=all for\n> origin so git-update would do a \"fetch --all\" on the origin\n> repository. Then step 3 above would have to provide for setting this\n> update option as appropriate.\n\nI would prefer this to be kept in contrib/; it feels like it is\nfilling rather very narrow need.\n\n> Anyway, something along those lines perhaps. Any feedback?\n\nI muttered something less elaborate in the nearby thread.\n\n\tMessage-ID: <7vr6w78b4x.fsf@assigned-by-dhcp.cox.net>\n\tMessage-ID: <7v64dev88t.fsf@assigned-by-dhcp.cox.net>\n\nThe part that deals with manual configuration (the last point in\nthe first message, and the second in message its entirety) is\nsomething your workflow would not need nor want to worry about,\nbut I think it is necessary for different ref namespace layouts\nand different workflows. I think the automatable part (the\nfirst two points in the \"sensible thing to do\" list in the first\nmessage) is very relevant to what you talked about in your\nmessage.\n"},{"id":"298030","messageId":"7vpsbmmhbh.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611171103150.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T11:41:06Z","receivedAt":"2006-11-17T11:41:06Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> 5. Adding something like git-fetch --all to allow it to pick up all new\n>> branches\n>\n> IIRC this idea was rejected, but I would find it useful. Especially with \n> what Han-Wen said: you can store the branches you fetch with \"git fetch \n> --all \" under .git/refs/remotes//.\n\nWith separate-remote layout, this can be done without risk of\ntracking refname clashing with local refname, which was the\nprimary reason for an earlier reluctance. \n\nWhile separate-remote layout also solves Carl's \"do not want to\ntrack tracking branches remote has\" problem, local branch\nnamespace can have both for-others (not necessarily \"public\" but\ncould be \"for colleagues\") and throwaway branches, so --all is\nprobably not the right thing to do in most cases. But I am Ok\nwith the approach of seeing how well it works out in practice by\ndoing the simplest \"--all\" and giving options to restrict it\nlater.\n"},{"id":"296525","messageId":"20061117122045.GC20729@diana.vm.bytemark.co.uk","threadId":"6919","inReplyTo":"7vac2sjs28.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-11-17T12:20:45Z","receivedAt":"2006-11-17T12:20:45Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-11-15 13:52:47 -0800, Junio C Hamano wrote:\n\n> That means that updated \"git merge\" (not the current one) would not\n> be able to assume it's parameter is a branch name, and still has to\n> come up with the merge message \"Merge \".\n\nOften, it would be a branch or a tag, so no problem there. For commits\nin general, it should not be hard to compute the set of branches and\ntags the commit is part of, and in the (probably) common case where\nthis set has exactly one element, the problem is solved. For the\nremaining cases, it should not be too horrible to ask the user to\ndescribe what is being merged.\n\n-- \nKarl Hasselström, kha@treskal.com\n"},{"id":"297187","messageId":"ejk9l0$l2s$1@sea.gmane.org","threadId":"6919","inReplyTo":"f2b55d220611162242s48dc42d6g4cbfd9173e712ff8@mail.gmail.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-17T12:25:23Z","receivedAt":"2006-11-17T12:25:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Michael K. Edwards wrote:\n\n> Currently, it looks like \"remotes\" entries are\n> created only by \"git clone\" or by hand.  Junio, are there any plans to\n> manage the contents of \"remotes\" through the tool instead of by hand?\n\nDon't forget quite new work with managing remotes (and per-branch\nconfiguration) in the config instead of separate remotes/ (or even older\nbranches/) file\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"298494","messageId":"ejkb8p$rgk$1@sea.gmane.org","threadId":"6919","inReplyTo":"455CF517.9000101@xs4all.nl","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-17T12:53:00Z","receivedAt":"2006-11-17T12:53:00Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Han-Wen Nienhuys wrote:\n> Linus Torvalds escreveu:\n\n>>> If I then do \n>>>\n>>>   git --bare fetch git://git.sv.gnu.org/lilypond.git web/master:master\n>>>\n>>> it downloads the same stuff again. \n>> \n>> Right. So you can either\n>> [..]\n>> See?\n> \n> No, I don't understand. In the fetch all the objects with their SHA1s\n> were already downloaded. I'd expect that the fetch with a refspec\n> would simply write a HEAD and a refs/heads/master, and notice that all\n> the actual data was already downloaded, and doesn't download it again. \n\nBut how git is to know that you have this already downloaded? Git compares\n_refs_ on the local and remote side to calculate what needs to be\ndownloaded. It does not (and should not) send all the objects IDs local\nside has.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296295","messageId":"ejkd6g$vog$1@sea.gmane.org","threadId":"6919","inReplyTo":"455C618A.7080309@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-17T13:25:56Z","receivedAt":"2006-11-17T13:25:56Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Han-Wen Nienhuys wrote:\n\n> As another example:  annoyances regarding program invocation\n> \n>   - option handling: -x -f -z != -xfz , \"--max-count 1\" doesn't work, \n> but needs an '='\n\nThat's true, and the probable cause is that git tries to first, avoid\ndependency on options parsers like getopt/getopt_long/argp or popt for\ncommands in C, getopt for commands in shell, Getopt::Std/Getopt::Long for\ncommands in Perl, and something for commands in Python (if there are any\nleft); second, existing options parsers do not deal (I think) with\ndistinction between arguments to wrapper and arguments to command, '--' to\nseparate revisions from pathnames not options from arguments, and the whole\nrevisions and revision list specifying syntax (where \"a --not b\" is not\nequivalent to \"--not a b\").\n\nThat said, perhaps we should craft our own options parsing (or modify\nexisting one)...\n\n>   - git --help lists an unordered set, which is too long scan quickly. \n\nIt is one page of alphabetically ordered commands.\n\ngit(7) gives whole list of commands, divided into categories, by the way.\n\n> I'd expect that list to either contain everything or the minimum set for \n> daily use. I.e. the set introduced in a first tutorial.  Why are merge, \n> prune, verify-tag there?\n> \n> Try \"bzr help\" for comparison.\n\nI wonder why \"repack\" isn't there, if \"prune\" is.\n\n>   - --pretty option with wholly uninformative options full, medium, \n> short, raw.  It's not even documented what each option does.\n\nAnd 'oneline' and undocumented 'email'. True, git lacks documentation (and\nthis one of main complaints in git survey).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"296724","messageId":"ejkdhv$vog$2@sea.gmane.org","threadId":"6919","inReplyTo":"8764dflj5o.fsf@wine.dyndns.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-17T13:32:03Z","receivedAt":"2006-11-17T13:32:03Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Alexandre Julliard wrote:\n\n> Junio C Hamano writes:\n> \n>> I would rather say \"use 'git branch' to make sure if you are\n>> ready to merge\". Who teaches not to use \"git pull\"?\n> \n> We do that for Wine. The problem is that we recommend using git-rebase\n> to make it easier for occasional developers to keep a clean history,\n> and rebase and pull interfere badly.\n\nWhat about proposed (and I think not accepted) merge strategy\n\"rebase\" (formerly called \"subordinate\" or something like that)?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"294630","messageId":"ejkebm$4a2$1@sea.gmane.org","threadId":"6919","inReplyTo":"7v1wo3d6g4.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-17T13:45:46Z","receivedAt":"2006-11-17T13:45:46Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Marko Macek writes:\n> \n>>>> BTW, currently there's a minor bug: git-diff HEAD doesn't work before\n>>>> you make the first commit. Perhaps this should be special cased.\n>>>\n>>> That's only a _bug_ in your implementation of the synonym for\n>>> \"svn diff\" which blindly used \"git diff HEAD\".\n>>\n>> My \"implementation\" is taken from git-diff man page. It seems obvious\n>> that the situation before the first commit is just a special case if\n>> we consider git-diff to be Porcelain (which I do).\n> \n> Yes, \"git diff\" is a Porcelain. No question about it.\n> \n> I do not consider the current behaviour of \"git diff HEAD\" that\n> complains instead of giving runs of \"foo is a new file and no\n> diff is available for it\" a bug; you asked for diff from some\n> commit but the commit you gave was bogus (does not exist yet).\n\ngit diff --root HEAD, perhaps?\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295983","messageId":"20061117162605.GA32597@spearce.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611161039160.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-17T16:26:05Z","receivedAt":"2006-11-17T16:26:05Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> - \"ORIG_HEAD\" is very useful indeed, and it's the head _before_ a merge \n> (or some other operations, like \"git rebase\" and \"git reset\": think of \n> it as a \"original head before we did some uncontrolled operation \n> where we otherwise can't use HEAD^ or similar\")\n> \n> I use \"gitk ORIG_HEAD..\" a lot, and if I don't like something I see \n> when I do it, I end up doing \"git reset --hard ORIG_HEAD\" to undo a \n> pull I've done. This is important exactly because ORIG_HEAD is _not_ \n> the same as the first parent of a merge, since a merge could have been \n> just a fast-forward.\n\nAlthough if you have reflog enabled on your current branch there\nis a 1 character shorter syntax:\n\n\tgitk HEAD@{1}..\n\nas recent Git understands that to mean the value that HEAD just had,\nwhich is also what is in ORIG_HEAD. Except that unlike ORIG_HEAD\nit can also show even older values (e.g. HEAD@{3}, 3 ops back)\nand it works very, very well on tracking branches. \"What did I\njust fetch in next?\" `git log next@{1}..next`\n\n-- \n"},{"id":"298406","messageId":"Pine.LNX.4.64.0611170836120.3349@woody.osdl.org","threadId":"6919","inReplyTo":"20061117162605.GA32597@spearce.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-11-17T16:45:39Z","receivedAt":"2006-11-17T16:45:39Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Fri, 17 Nov 2006, Shawn Pearce wrote:\n> \n> Although if you have reflog enabled on your current branch there\n> is a 1 character shorter syntax:\n> \n> \tgitk HEAD@{1}..\n\nHeh. With a finnish keyboard, that \"@\" is AltGr+'2', and the '{'/'}' is \nAltGr+'7'/'0', I guarantee that it's not \"1 character shorter\", it's \n\"three pretty complicated characters longer\" and \"off the normal path \nwhere you hold your fingers on the keyboard ;)\n\nAnd that's not even mentioning that '{'/'}' is a magic sequence for \nfilename expansion to the shell, so every time I see that, I have to think \nabout it (and it turns out that because there is no comma in between \nthere, it's ok. Otherwise you would need to quote it or escape them...)\n\nSo the reflog syntax is fine, but it's definitely not a \"simple\" syntax. \nI'd only use it for things where I want something that ORIG_HEAD won't \ngive me (\"ORIG_HEAD\" you can type by just holding the shift key down all \nthe time, and letting your fingers dance over the keyboard, both on a US \nand a Finnish keyboard).\n\nAnd yes, I actually use a Finnish keyboard, still. Don't ask me why. I \ndon't actually need the åäö characters often enough for it to matter, and \nI have used US keyboards elsewhere enough that I can switch between the \ntwo without thinking, but I still ended up having my sister ship me a \nkeyboard from Finland when I wanted to upgrade..\n\n\t\t\tLinus"},{"id":"294136","messageId":"87bqn6qav2.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"20061117162605.GA32597@spearce.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-17T16:46:57Z","receivedAt":"2006-11-17T16:46:57Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 17 Nov 2006 11:26:05 -0500, Shawn Pearce wrote:\n> Linus Torvalds wrote:\n> > - \"ORIG_HEAD\" is very useful indeed, and it's the head _before_ a merge\n...\n> Although if you have reflog enabled on your current branch there\n> is a 1 character shorter syntax:\n>\n> \tgitk HEAD@{1}..\n\nYes, this was my exact thought when reading what Linus\nwrote. ORIG_HEAD might be fine and all, but it pales in functionality\ncompared to what reflog provides.\n\nI would very much like to see reflog getting first-class citizen\nsupport in git:\n\n1. Be on by default\n\n2. Get documented in all the right places, (much better than adding\n documentation for ORIG_HEAD in my opinion)\n\n3. Tighter integration with branch manipulations. Do we already delete\n reflog when deleting a branch? We don't have a branch rename\n operation, but if we get one, renaming the reflog should go\n hand-in-hand, etc.\n\n-Carl\n"},{"id":"298720","messageId":"87y7qahvbp.fsf@wine.dyndns.org","threadId":"6919","inReplyTo":"ejkdhv$vog$2@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Alexandre Julliard","fromEmail":"julliard@winehq.org","sentAt":"2006-11-17T16:49:46Z","receivedAt":"2006-11-17T16:49:46Z","isPatch":false,"sender":{"key":"julliard@winehq.org","avatar":null},"body":"Jakub Narebski writes:\n\n> Alexandre Julliard wrote:\n>\n>> Junio C Hamano writes:\n>> \n>>> I would rather say \"use 'git branch' to make sure if you are\n>>> ready to merge\". Who teaches not to use \"git pull\"?\n>> \n>> We do that for Wine. The problem is that we recommend using git-rebase\n>> to make it easier for occasional developers to keep a clean history,\n>> and rebase and pull interfere badly.\n>\n> What about proposed (and I think not accepted) merge strategy\n> \"rebase\" (formerly called \"subordinate\" or something like that)?\n\nThat sounds very interesting. Has it ever been implemented, or only\ndiscussed?\n\n-- \nAlexandre Julliard\n"},{"id":"297610","messageId":"87ac2qqanl.wl%cworth@cworth.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611170836120.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-11-17T16:51:26Z","receivedAt":"2006-11-17T16:51:26Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Fri, 17 Nov 2006 08:45:39 -0800 (PST), Linus Torvalds wrote:\n> > Although if you have reflog enabled on your current branch there\n> > is a 1 character shorter syntax:\n> >\n> > \tgitk HEAD@{1}..\n>\n> Heh. With a finnish keyboard, that \"@\" is AltGr+'2', and the '{'/'}' is\n> AltGr+'7'/'0', I guarantee that it's not \"1 character shorter\", it's\n> \"three pretty complicated characters longer\" and \"off the normal path\n> where you hold your fingers on the keyboard ;)\n\nIt's not even all that convenient on a U.S. keyboard. My pinky suffers\na bit having to pop on and off of shift for the '{', '1', '}'. Then\nagain, I don't like having to hold shift down for all of ORIG_HEAD\neither, (but it's definitely easier in comparison).\n\nBut since reflog does everything ORIG_HEAD does and more, shall we\njust clean up the syntax somehow? Ideas anyone? And then fix the\ndocumentation to explain that?\n\n-Carl\n"},{"id":"295858","messageId":"20061117165849.GC32597@spearce.org","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0611171103150.13772@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Cleaning up git user-interface warts","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-17T16:58:49Z","receivedAt":"2006-11-17T16:58:49Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Johannes Schindelin wrote:\n> I introduced the remote..{url,fetch,push} entries into the config \n> with the goal to enhance -fetch to remember the current command line with \n> a setting. I was the only one to find that useful.\n> \n> BTW I still would argue that it is better to write the remote information \n> into the config, because you have a saner way to manipulate that from \n> scripts than .git/remotes/.\n\nI'm *fully* in favor of the remote..{url,fetch,push} entries\nin the config file. I've pretty much switched every repository to\nthat format at this point.\n\nIn writing git-gui I'm finding it much, much easier to manage\nthings through repo-config than to do any mucking around in the\n.git/remotes directory. Yes, the remote files have simple format,\nbut I can get everything in one \"git repo-config --list\" pull it\nall into a Tcl array and work with it; using .git/remotes means I\nhave to open the file and read each line too. :-(\n\n-- \n"},{"id":"296829","messageId":"20061117170836.GD32597@spearce.org","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611170836120.3349@woody.osdl.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-17T17:08:36Z","receivedAt":"2006-11-17T17:08:36Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Linus Torvalds wrote:\n> On Fri, 17 Nov 2006, Shawn Pearce wrote:\n> > \n> > Although if you have reflog enabled on your current branch there\n> > is a 1 character shorter syntax:\n> > \n> > \tgitk HEAD@{1}..\n> \n> Heh. With a finnish keyboard, that \"@\" is AltGr+'2', and the '{'/'}' is \n> AltGr+'7'/'0', I guarantee that it's not \"1 character shorter\", it's \n> \"three pretty complicated characters longer\" and \"off the normal path \n> where you hold your fingers on the keyboard ;)\n\nI forgot that you use a finnish keyboard. :-)\n\nI agree with you; its not easier to type, for you. Me, I'm a dumb\nAmerican who uses a Kinesis keyboard, therefore my left foot is\nmy shift key and its in sync with my fingers. I have no extra\npinky load for either syntax. And since the reflog syntax works\nin a lot more contexts (e.g. after a fetch into a tracking branch)\nI have just forgotten about ORIG_HEAD entirely. Oh sure, I know\nits there, but its not something I think about using...\n\n-- \n"},{"id":"295160","messageId":"20061117171532.GE32597@spearce.org","threadId":"6919","inReplyTo":"87bqn6qav2.wl%cworth@cworth.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-17T17:15:32Z","receivedAt":"2006-11-17T17:15:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Carl Worth wrote:\n> Yes, this was my exact thought when reading what Linus\n> wrote. ORIG_HEAD might be fine and all, but it pales in functionality\n> compared to what reflog provides.\n> \n> I would very much like to see reflog getting first-class citizen\n> support in git:\n> \n> 1. Be on by default\n\nI have:\n\n\tgit repo-config --global core.logAllRefUpdates true\n\nespecially since Junio fixed it to only create logs for heads and\nnot tags. That way its on by default for me. But I think it should\nbe on by default in the next version of Git.\n \n> 2. Get documented in all the right places, (much better than adding\n> documentation for ORIG_HEAD in my opinion)\n\nAgreed. I'm not likely to do it anytime soon however, so I'm hoping\nsomeone else will do it... :-)\n \n> 3. Tighter integration with branch manipulations. Do we already delete\n> reflog when deleting a branch? We don't have a branch rename\n> operation, but if we get one, renaming the reflog should go\n> hand-in-hand, etc.\n\nYes, we delete the log when we delete the branch, and we prune\nback the empty directories too just like we do on the branch side,\nso that new branches can be correctly created.\n\nThere was a recent discussion about that from Junio if I recall.\nSeveral people that I work with have asked that branch rename\nsupport be added to Git, and that if you rename the branch the\nreflog follows. Because in their mind they are simply changing\nthe name of the branch, any old history of that branch should\nstick around.\n\nI tried to think of an option to \"git branch\" to do the rename but\nkept thinking that:\n\n\tgit rename-branch old new\n\nis the better syntax... even though that's command number 133\nor something like that...\n\nWe should stick a \"null\" event into the reflog during a branch\nrename. Make both the old and new SHA1 the current SHA1 but drop\na message in saying \"renamed branch old -> new\" (for example).\n\n-- \n"},{"id":"297643","messageId":"7virhem0ps.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"20061117162605.GA32597@spearce.org","subject":"Re: multi-project repos","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T17:39:43Z","receivedAt":"2006-11-17T17:39:43Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Linus Torvalds wrote:\n>> - \"ORIG_HEAD\" is very useful indeed, and it's the head _before_ a merge \n>> (or some other operations, like \"git rebase\" and \"git reset\": think of \n>> it as a \"original head before we did some uncontrolled operation \n>> where we otherwise can't use HEAD^ or similar\")\n>> \n>> I use \"gitk ORIG_HEAD..\" a lot, and if I don't like something I see \n>> when I do it, I end up doing \"git reset --hard ORIG_HEAD\" to undo a \n>> pull I've done. This is important exactly because ORIG_HEAD is _not_ \n>> the same as the first parent of a merge, since a merge could have been \n>> just a fast-forward.\n>\n> Although if you have reflog enabled on your current branch there\n> is a 1 character shorter syntax:\n>\n> \tgitk HEAD@{1}..\n\nAre you sure about this? I've seen \"next@{1}\" to look at\nhistory of the named branch, but never history of \"HEAD\".\n"},{"id":"293929","messageId":"200611171841.44379.jnareb@gmail.com","threadId":"6919","inReplyTo":"87y7qahvbp.fsf@wine.dyndns.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-17T17:41:43Z","receivedAt":"2006-11-17T17:41:43Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Alexandre Julliard wrote:\n> Jakub Narebski writes:\n>> Alexandre Julliard wrote:\n>>> Junio C Hamano writes:\n>>> \n>>>> I would rather say \"use 'git branch' to make sure if you are\n>>>> ready to merge\". Who teaches not to use \"git pull\"?\n>>> \n>>> We do that for Wine. The problem is that we recommend using git-rebase\n>>> to make it easier for occasional developers to keep a clean history,\n>>> and rebase and pull interfere badly.\n>>\n>> What about proposed (and I think not accepted) merge strategy\n>> \"rebase\" (formerly called \"subordinate\" or something like that)?\n> \n> That sounds very interesting. Has it ever been implemented, or only\n> discussed?\n\nThere was some implementation with warts\n\n http://thread.gmane.org/gmane.comp.version-control.git/30068\n Message-Id: <20061025155009.GD5591@parisc-linux.org>\n\nwhich didn't got corrected and resent.\n-- \nJakub Narebski\n"},{"id":"297018","messageId":"455DF676.3090001@gmx.net","threadId":"6919","inReplyTo":"20061117171532.GE32597@spearce.org","subject":"Re: multi-project repos (was Re: Cleaning up git user-interface warts)","fromName":"Marko Macek","fromEmail":"marko.macek@gmx.net","sentAt":"2006-11-17T17:50:46Z","receivedAt":"2006-11-17T17:50:46Z","isPatch":false,"sender":{"key":"marko.macek@gmx.net","avatar":null},"body":"Shawn Pearce wrote:\n> Carl Worth wrote:\n>> Yes, this was my exact thought when reading what Linus\n>> wrote. ORIG_HEAD might be fine and all, but it pales in functionality\n>> compared to what reflog provides.\n>>\n>> I would very much like to see reflog getting first-class citizen\n>> support in git:\n>>\n>> 1. Be on by default\n\nI agree.\n\n> I have:\n> \n> \tgit repo-config --global core.logAllRefUpdates true\n> \n> especially since Junio fixed it to only create logs for heads and\n> not tags. That way its on by default for me. But I think it should\n> be on by default in the next version of Git.\n\nWhy is it not useful for tags for having logs? \n\nI also have a question:\n\nDoes git-fsck-objects/prune check the ref logs?\n\nMark\n"},{"id":"294439","messageId":"7vhcwxlt2z.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"455DF676.3090001@gmx.net","subject":"Re: multi-project repos","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T20:24:36Z","receivedAt":"2006-11-17T20:24:36Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Marko Macek writes:\n\n> Shawn Pearce wrote:\n>...\n>> I have:\n>>\n>> \tgit repo-config --global core.logAllRefUpdates true\n>>\n>> especially since Junio fixed it to only create logs for heads and\n>> not tags. That way its on by default for me. But I think it should\n>> be on by default in the next version of Git.\n>\n> Why is it not useful for tags for having logs?\n\nWhen I make a tag that says \"this is the v1.2.0 release\", it is\nexpected it won't change in the future, ever. I _can_ make\nmistake and tag a wrong commit under v1.2.0 name, in which case\nI may have to replace it with another corrected tag, but\nrecoding that mistake does not really add value. So most of the\ntime ref-log for a tag would contain only one entry per file, its\ncreation, but that creation time is already recorded in the tag\nobject itself anyway.\n\nAt times, it may be useful to have some floating tag that point\nat the \"latest\", or \"today's\", but that use is a minority. For\nthese minority cases, you can manually create an empty file\nunder .git/logs/ directory to record their updates.\n\nThe configuration mechanism only kicks in when there is no such\nexisting file to prime the process, and not creating ref-log for\ntags by default is the sensible thing to do.\n\n> I also have a question:\n>\n> Does git-fsck-objects/prune check the ref logs?\n\nThey deliberately ignore ref-log for the same reason lost-found\ndoes not drop found refs under .git/refs hierarchy.\n\nThis only matters if you somehow rewind an existing branch in\norder to lose part of its history, using \"reset --hard HEAD~n\"\nor \"rebase\". If the updates to your branch tips always build on\ntop of the previous (either by commiting on top of the current,\nmerging on top of the current, or fast-forwarding), and if you\nnever rewind the branch, the commits recorded in the ref-log for\nthe branch are always ancestors of the tip of the branch, so\nchecking ref-log does not give you anything other than slowing\nthe operation down.\n\nHowever, if you rewind the tip of a branch, the story changes.\nUntil the next \"prune\", objects reachable from the ref-log of\nthe branch but not reachable from the tip of the branch are\nstill available in your object store and in a pinch you can\nrecover them, but after a \"prune\" they will be lost forever if\nthey do not have any other references. So it might seem that\nthey should be protected from pruning.\n\nBut if you did so, you can never remove cruft from your object\nstore once you make a mistake. You can clean up your history by\na reset and/or a rebase, and cleaning up to _lose_ part of the\nhistory was the reason you rewound the branch in the first\nplace.\n\nIn other words, running 'prune' is a conscious act of saying \"I\nknow I am not in the middle of something; I thought over what\nI've done recently, salvaged necessary bits from what I\ndiscarded earlier, and there is nothing that need to be salvaged\nlater anymore -- I have refs to what I need. Now go clean up\nthe cruft from my object store\".\n\n\n\n"},{"id":"295907","messageId":"455E1BF1.1030003@midwinter.com","threadId":"6919","inReplyTo":"87d57pu4qa.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Steven Grimm","fromEmail":"koreth@midwinter.com","sentAt":"2006-11-17T20:30:41Z","receivedAt":"2006-11-17T20:30:41Z","isPatch":false,"sender":{"key":"koreth@midwinter.com","avatar":"https://gravatar.com/avatar/71b4d2e8b62f168bdc9e9205341159e3567003b4f9e2127c617c5fa0a1f5bad2?d=mp&s=160"},"body":"Jumping into this a day late, but:\n\nCarl Worth wrote:\n> I don't see any defining difference that justifies cogito's\n> existence (\"hide the index\" maybe? let's just hide it a tiny bit more\n> in git). And I would like to help work to get the remaining good\n> stuff that has been proven in cogito---to get it pushed down into git\n> itself.\n> \n\nAgreed totally on the second point. It would be great if git natively \nsupported everything people use in Cogito.\n\nI find myself using native git commands for the most part, except for \none Cogito command: \"cg-update\". It is vastly more convenient than \ngit-pull in large part because it automatically merges upstream changes \nwith uncommitted working-copy changes. I suppose you could classify this \nas \"hide the index\" in some sense.\n\nMaybe I should give an example of what I mean. Suppose I have two child \nrepositories (owned by different developers, say):\n\ncg-clone repo child1\ncg-clone repo child2\n\nNow I go into both of them and make different (hopefull non-conflicting) \nedits to the same file.\n\necho foo >> child1/testfile\nperl -pi -e 's/tree/shrub/' child2/testfile\n\nI push the change from child1 into the integration repo.\n\ncd child1\ngit-commit -a\ngit-push\n\nNow I want to incorporate the change into child2, where I'm still doing \nwork. With Cogito, I go to child2 and run:\n\ncg-update\n\nand afterwards, the upstream changes are merged into testfile and \"git \ndiff\" still shows my local edits. With Git native commands, updating \nchild2 if I'm not ready to commit yet is more like:\n\ngit-diff --binary > /tmp/patch\ngit-reset --hard\ngit-pull\ngit-apply /tmp/patch\n\nI might have gotten that slightly wrong, but I think I have the general \nidea right; in any event, it's not nearly as convenient! The alternative \nis to commit then pull, but then when I want to look at my local edits, \nI have to remember to diff my working copy against the correct revision, \nwhich gets increasingly annoying if I update more than once.\n\nLike others on this list, I'm also trying to sell an existing user base \n(in this case, they're using Subversion) on Git. The lack of a built-in \nequivalent to \"svn update\" is actually a pretty big UI annoyance for \npeople whose workflow doesn't require git's more sophisticated feature \nset at a given point in time. Even a sophisticated user doesn't need the \nfull power of the tool 100% of the time, so this isn't just a novice vs. \nexpert thing in my opinion.\n\nAbsent Cogito, would the lack of a simple \"svn update\" equivalent be a \ndeal-killing \"throw your hands up in disgust and give up\" thing? Maybe \nnot, but it's a daily \"ugh, why am I having to type extra commands to do \nsomething that only took one command in svn?\" thing. So it's nice to \nhave Cogito to paper over that particular wart.\n\nIf there is a native git equivalent to cg-update including the \nworking-copy automatic merges, I'll be delighted to stand corrected!\n\n"},{"id":"295279","messageId":"7virhdiwon.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"455E1BF1.1030003@midwinter.com","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-17T21:35:04Z","receivedAt":"2006-11-17T21:35:04Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Steven Grimm writes:\n\n> echo foo >> child1/testfile\n> perl -pi -e 's/tree/shrub/' child2/testfile\n>...\n> git-diff --binary > /tmp/patch\n> git-reset --hard\n> git-pull\n> git-apply /tmp/patch\n>\n> I might have gotten that slightly wrong, but I think I have the\n> general idea right.\n\nstg pull would help you in such a situation as well, but I see\nwhat you mean.\n\nJust like we have an explicit -m option to \"checkout\" to allow\nfile-level merging of local changes, I think it is reasonable to\nhav an option that allows file-level merging of local changes\nwhen doing a pull that you _know_ will not conflict.\n\nWhen there will be a conflict between your HEAD and MERGE_HEAD\neven without your local changes, you somehow need to sort out\nthe resulting mess that come from conflicts due to the branch\ndiversion (i.e. log HEAD...MERGE_HEAD) and conflicts between\nyour local change and what the other branch did. The resulting\nmerge commit obviously needs to record resolutions only to the\nformer and should not even record anything you did locally,\nconflicted or not. Which is a pain for the end user and giving\nthem a way to revert to the state before this three-and-half\nway merge started also needs to be there.\n\nUnfortunately the only way to know if there will be a file-level\nconflict is to try one, and stashing away the current state just\nin case it conflicted is a performance penalty, so this probably\nshould stay as an option just like \"-m\" to the \"checkout\".\n\nBut the basic mechanism to do this three-and-half way merge is\nsimple and I have no objection if somebody wanted to add such an\noption to \"git pull\".\n\n"},{"id":"297506","messageId":"20061117220713.GH7201@pasky.or.cz","threadId":"6919","inReplyTo":"7virhdiwon.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2006-11-17T22:07:13Z","receivedAt":"2006-11-17T22:07:13Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Fri, Nov 17, 2006 at 10:35:04PM CET, Junio C Hamano wrote:\n> Unfortunately the only way to know if there will be a file-level\n> conflict is to try one, and stashing away the current state just\n> in case it conflicted is a performance penalty, so this probably\n> should stay as an option just like \"-m\" to the \"checkout\".\n\nI think it would be just great if it worked at least for fast-forwarding\ncase; I think this is where it is actually most useful. Cogito tries to\nsupport even the three-way case as long as the changes touch different\nfiles, but I'm not sure if it was a good idea to begin with.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nStuff: http://pasky.or.cz/\n#!/bin/perl -sp0777i wrote:\n> \"Michael K. Edwards\" writes:\n>\n> > Presumably \"git branch -D\" should inspect everything under\n> > .git/remotes to see whether one or more Pull: lines need to be\n> > deleted along with the branch.\n>\n> I am not sure what you mean. .git/remotes files do not describe\n> any relationship between local branches (and that is where one\n> of the problem raised in recent thread -- pull does not notice\n> on which branch you are on and change its behaviour depending on\n> it), so I do not think there is anything gained for \"git branch\n> -D\" by going through them.\n\n.git/remotes/foo does contain Pull: lines which indicate the local\nbranch onto which to _fetch_ remote changes. It's the subsequent\n_merge_ that doesn't notice which branch you have checked out.\n\nCheers,\n"},{"id":"295926","messageId":"20061118060243.GB2125@spearce.org","threadId":"6919","inReplyTo":"7virhem0ps.fsf@assigned-by-dhcp.cox.net","subject":"Re: multi-project repos","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-18T06:02:43Z","receivedAt":"2006-11-18T06:02:43Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> Shawn Pearce writes:\n> > Although if you have reflog enabled on your current branch there\n> > is a 1 character shorter syntax:\n> >\n> > \tgitk HEAD@{1}..\n> \n> Are you sure about this? I've seen \"next@{1}\" to look at\n> history of the named branch, but never history of \"HEAD\".\n \nYes. :-)\n\nIf the ref name is a symref then we resolve the symref all the\nway down to the real ref before we open and walk the reflog.\nTherefore this works.\n\n-- \n"},{"id":"297552","messageId":"7vvelddxcx.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"20061118060243.GB2125@spearce.org","subject":"Re: multi-project repos","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-11-18T07:31:42Z","receivedAt":"2006-11-18T07:31:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Shawn Pearce writes:\n\n> Junio C Hamano wrote:\n>> Shawn Pearce writes:\n>> > Although if you have reflog enabled on your current branch there\n>> > is a 1 character shorter syntax:\n>> >\n>> > \tgitk HEAD@{1}..\n>> \n>> Are you sure about this? I've seen \"next@{1}\" to look at\n>> history of the named branch, but never history of \"HEAD\".\n> \n> Yes. :-)\n>\n> If the ref name is a symref then we resolve the symref all the\n> way down to the real ref before we open and walk the reflog.\n> Therefore this works.\n\nTrue, except if you did:\n\n $ git pull\n $ git checkout otherbranch\n $ git show HEAD@{1}\n\nMy real point was that I was wondering if it also makes sense\nfor ref-log to record switching branches for the symref itself.\n\nBut after sending that message I thought about it a bit more and\nconcluded that it is not an interesting information. It is more\ncode that affects unrelated places even if we were to implement\nit and without real gain, so let's not log symref itself and\nkeep the current implementation.\n\n\n"},{"id":"295683","messageId":"20061118074502.GB2338@spearce.org","threadId":"6919","inReplyTo":"7vvelddxcx.fsf@assigned-by-dhcp.cox.net","subject":"Re: multi-project repos","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-11-18T07:45:02Z","receivedAt":"2006-11-18T07:45:02Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Junio C Hamano wrote:\n> True, except if you did:\n> \n> $ git pull\n> $ git checkout otherbranch\n> $ git show HEAD@{1}\n> \n> My real point was that I was wondering if it also makes sense\n> for ref-log to record switching branches for the symref itself.\n> \n> But after sending that message I thought about it a bit more and\n> concluded that it is not an interesting information. It is more\n> code that affects unrelated places even if we were to implement\n> it and without real gain, so let's not log symref itself and\n> keep the current implementation.\n\nI agree completely.\n\nI have no interest in a history of what branches I've recently\nbeen on. All I care about is the history of this branch. And I\nconsider HEAD to be nothing but a shortcut that always points to\nthe current branch... so its darn useful for that.\n\nIn retrospect CURR may have been a better name for the HEAD symref\nbut its far too late to even consider changing that, so lets not\ngo down that road. :-)\n\n-- \n"},{"id":"294757","messageId":"200611180759.52021.alan@chandlerfamily.org.uk","threadId":"6919","inReplyTo":"7vr6w5y7to.fsf@assigned-by-dhcp.cox.net","subject":"Re: Cleaning up git user-interface warts","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-11-18T07:59:51Z","receivedAt":"2006-11-18T07:59:51Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Tuesday 14 November 2006 22:36, Junio C Hamano wrote:\n...\n>\n> And I agree with Pasky that fixing UI is hard unless you are\n> willing to get rid of historical warts. Syntax of the command\n> line arguments the current set of Porcelain-ish takes are\n> sometimes just horrible. It may not be a bad idea to start\n> building the fixed UI from scratch, using different prefix than\n> \"git\" (say \"gu\" that stands for \"git UI\" or \"gh\" that stands for\n> \"git for humans\").\n>\n> Of course, it could even be \"cg\" ;-).\n\nI have been away on business last week and have been following this thread \nfrom the archives. There is a comment I want to make about split of \nPorcelain and Plumbing namespaces that is not particularly an answer to this \nparticular post, but it does seem an appropriate place to insert it.\n\nI think there were three (historic) mistakes in the development of git\n\t- to split git and cogito so that some of the commands started git and some \ncg (aided and abetted by putting them in separate repositories).\n\t- to try and make the distinction between plumbing and porcelein a line in \nthe sand (after all this is exactly why git and cg separated) when in \npractice it isn't that straight forward\n\t- for cogito to (initially) not support the internal branches, but in fact \ndeal with them via cloned repositories\n\nOn the other hand, it was a good move to bring gitk and gitweb into the core \nrepository.\n\nThese were not technical mistakes, but social ones.\n\nMuch of the discussion on UI warts doesn't exist in the cogito world (not that \nI use it at all anymore, despite its more user friendly interface - just \nbecause I didn't want to learn two parallel sets of commands and I prefered \ngit's branch model so stuck with the slightly less friendly git command set) \nbut if you look at any of the SCM comparison discussions that happen now, \nthey are always comparing the core git with the other SCM, not git plus all \nits porcelains.\n\nSo I think it would be a mistake (which hopefully does seem to be the \nconcensus reached in the list) to try and introduce new namespaces to the \ncommand set.\n-- \nAlan Chandler\n"},{"id":"294587","messageId":"200611181109.14675.alan@chandlerfamily.org.uk","threadId":"6919","inReplyTo":"Pine.LNX.4.64.0611151023160.2591@xanadu.home","subject":"Re: Cleaning up git user-interface warts","fromName":"Alan Chandler","fromEmail":"alan@chandlerfamily.org.uk","sentAt":"2006-11-18T11:09:14Z","receivedAt":"2006-11-18T11:09:14Z","isPatch":false,"sender":{"key":"alan@chandlerfamily.org.uk","avatar":"https://gravatar.com/avatar/1862247e5ea8eac114c842f9dc3a5db6253754e24ef7171757cf97eedce48b8c?d=mp&s=160"},"body":"On Wednesday 15 November 2006 15:41, Nicolas Pitre wrote:\n> On Wed, 15 Nov 2006, Andy Parkins wrote:\n> > * Don't use the name \"origin\" twice. In fact, don't use it at all. In\n> > a distributed system there is no such thing as a true origin.\n>\n> I agree, sort of. Not because\"origin\" is ambigous as a name. But\n> rather because there is a magic translation from \"master\" to \"origin\",\n> and I think this is wrong to do that.\n>\n> As mentioned elsewhere (and let's start using \"get\" instead of \"pull\" as\n> suggested by Johannes), a \"get\" should probably always create a branch\n> group even if it contains only one branch. This way the remote branch\n> called \"master\" will still be called \"master\" locally, under the branch\n> group used to represent the remote repository. And if a local name is\n> not provided then let's just call it \"default\". This way, amongst the\n> remote references, there would be a \"default/master\" that would be used\n> when nothing else is provided by the user. So...\n>\n> \tgit get repo.com/time_machine.git\n>\n> would create a local branch named \"remotes/default/master\" if the remote\n> repo has only a master branch.\n\nWhy not call it remotes/repo.com/time_machine.git/master and have a \nDEFAULT_ORIGIN that is a symref to it in the same way as HEAD is a symref to \na local branch\n\n-- \nAlan Chandler\n"},{"id":"296284","messageId":"ejuv2a$atg$1@sea.gmane.org","threadId":"6919","inReplyTo":"87velgs9hx.wl%cworth@cworth.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Jerome Lovy","fromEmail":"t2a2e9z8ncbs9qg@brefemail.com","sentAt":"2006-11-21T13:25:56Z","receivedAt":"2006-11-21T13:25:56Z","isPatch":false,"sender":{"key":"t2a2e9z8ncbs9qg@brefemail.com","avatar":null},"body":"On Wed, 15 Nov 2006, Carl Worth wrote:\n> Well, one of the problems is that with current git I can teach, (and I\n> have), that there's a conceptual:\n> \n> \tpull = fetch + merge\n> \n> But then shortly after I have to teach an interface notion:\n> \n> \tmerge = pull .\n> \n> So there's this goofy circular notion that people end up with\n> mentally. If we fix it so that a local merge really is performed with\n> \"git merge \" instead of \"git pull . \" then teaching\n> pull=fetch+merge really is a lot easier.\n\nOn a conceptual level, can we not perhaps explain that if\n\n\tpull = fetch + merge\n\nthen\n\n\tmerge = pull - fetch\n\nand that the latter (pull - fetch) happens to be expressed with the \ninterface as 'git pull .' ?\n\nMy 2 cents.\nJérôme\n"},{"id":"296274","messageId":"4566E512.4010405@xs4all.nl","threadId":"6919","inReplyTo":"ejkd6g$vog$1@sea.gmane.org","subject":"Re: Cleaning up git user-interface warts","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2006-11-24T12:26:58Z","receivedAt":"2006-11-24T12:26:58Z","isPatch":false,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Jakub Narebski escreveu:\n\n>> - --pretty option with wholly uninformative options full, medium, \n>> short, raw. It's not even documented what each option does.\n> \n> And 'oneline' and undocumented 'email'. True, git lacks documentation (and\n> this one of main complaints in git survey).\n\nThe recently posted patch documenting is an improvement, but why not\nadd an option so you can do\n\n --format 'committer %c\\nauthor %a\\n'\n \nthis catches all combinations, and is easier for scripting.\n\nRight now, I have some scripts that have to munge log output with\nregular expressions to strip out the \"author:\" prefixes.\n\n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"294483","messageId":"ek6p6j$r6p$1@sea.gmane.org","threadId":"6919","inReplyTo":"4566E512.4010405@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2006-11-24T12:41:29Z","receivedAt":"2006-11-24T12:41:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Han-Wen Nienhuys wrote:\n\n> Jakub Narebski escreveu:\n> \n>>> - --pretty option with wholly uninformative options full, medium, \n>>> short, raw. It's not even documented what each option does.\n>> \n>> And 'oneline' and undocumented 'email'. True, git lacks documentation (and\n>> this one of main complaints in git survey).\n> \n> The recently posted patch documenting is an improvement, but why not\n> add an option so you can do\n> \n> --format 'committer %c\\nauthor %a\\n'\n> \n> this catches all combinations, and is easier for scripting.\n> \n> Right now, I have some scripts that have to munge log output with\n> regular expressions to strip out the \"author:\" prefixes.\n\nIf we ever implemented this, I'd rather to separate what is now of format\nparsing in git-for-each-ref (although I'd like to make it more like rpm's\n--query-format argument, with %-n{header}, %[array] etc.) into separate\nmodule, and reuse it for git-log and friends --pretty/--format handling.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n\n"},{"id":"295535","messageId":"Pine.LNX.4.63.0612052340260.28348@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"4566E512.4010405@xs4all.nl","subject":"Re: Cleaning up git user-interface warts","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-12-05T22:42:46Z","receivedAt":"2006-12-05T22:42:46Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:\n\n> The recently posted patch documenting is an improvement, but why not\n> add an option so you can do\n> \n> --format 'committer %c\\nauthor %a\\n'\n> \n> this catches all combinations, and is easier for scripting.\n\nYes, it would be easier for scripting, and it would probably be relatively \neasy, what with the addition of interpolate.[ch] to git. However, it is \nwork, and I am lazy.\n\nWhat information would you like, anyway? IOW can you provide me with a \nlist like this:\n\n%c\tcommitter\n%a\tauthor\n%d\tcommitter_date\n...\n\nCiao,\nDscho\n"},{"id":"296387","messageId":"7vy7pmdk60.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0612052340260.28348@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: Cleaning up git user-interface warts","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-12-05T22:58:47Z","receivedAt":"2006-12-05T22:58:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> On Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:\n>\n>> The recently posted patch documenting is an improvement, but why not\n>> add an option so you can do\n>> \n>> --format 'committer %c\\nauthor %a\\n'\n>> \n>> this catches all combinations, and is easier for scripting.\n>\n> Yes, it would be easier for scripting, and it would probably be relatively \n> easy, what with the addition of interpolate.[ch] to git. However, it is \n> work, and I am lazy.\n\nLazy is good when the details should not matter. If some people\nare scripting, they are fully capable of reading raw or fuller.\n\n\n"},{"id":"35281","messageId":"Pine.LNX.4.63.0702230125270.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"4566E512.4010405@xs4all.nl","subject":"[PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-23T00:35:03Z","receivedAt":"2007-02-23T00:35:03Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"\nWith this patch,\n\n$ git show -s \\\n\t--pretty=format:' Ze komit %h woss%n dunn buy ze great %an'\n\nshows something like\n\n Ze komit 04c5c88 woss\n dunn buy ze great Junio C Hamano\n\nThe supported placeholders are:\n\n\t'%H': commit hash\n\t'%h': abbreviated commit hash\n\t'%T': tree hash\n\t'%t': abbreviated tree hash\n\t'%P': parent hashes\n\t'%p': abbreviated parent hashes\n\t'%an': author name\n\t'%ae': author email\n\t'%ad': author date\n\t'%aD': author date, RFC2822 style\n\t'%ar': author date, relative\n\t'%at': author date, UNIX timestamp\n\t'%cn': committer name\n\t'%ce': committer email\n\t'%cd': committer date\n\t'%cD': committer date, RFC2822 style\n\t'%cr': committer date, relative\n\t'%ct': committer date, UNIX timestamp\n\t'%e': encoding\n\t'%s': subject\n\t'%b': body\n\t'%Cred': switch color to red\n\t'%Cgreen': switch color to green\n\t'%Cblue': switch color to blue\n\t'%Creset': reset color\n\t'%n': newline\n\nSigned-off-by: Johannes Schindelin \n---\n\n\tOn Fri, 24 Nov 2006, Han-Wen Nienhuys wrote:\n\n\t> The recently posted patch documenting is an improvement, but why \n\t> not add an option so you can do\n\t> \n\t> --format 'committer %c\\nauthor %a\\n'\n\t> \n\t> this catches all combinations, and is easier for scripting.\n\n\tSo, I overcame my laziness after 91 days...\n\n\tOf course, this is not as efficient as it could be: it _will_ get \n\t_all_ variables from the commit, even if not needed. However, I \n\tdon't think that it matters in reality.\n\n\tBTW I have not found any implementation of xstrndup(), so I let it \n\tbe static.\n\n Documentation/pretty-formats.txt | 44 +++++++++\n commit.c | 195 ++++++++++++++++++++++++++++++++++++++\n commit.h | 1 +\n log-tree.c | 2 +-\n 4 files changed, 241 insertions(+), 1 deletions(-)\n\ndiff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt\nindex fb0b0b9..2fe6c31 100644\n--- a/Documentation/pretty-formats.txt\n+++ b/Documentation/pretty-formats.txt\n@@ -77,9 +77,53 @@ displayed in full, regardless of whether --abbrev or\n true parent commits, without taking grafts nor history\n simplification into account.\n \n+\t* 'format:'\n++\n+The 'format:' format allows you to specify which information\n+you want to show. It works a little bit like printf format,\n+with the notable exception that you get a newline with '%n'\n+instead of '\\n'.\n+\n+E.g, 'format:\"The author of %h was %an, %ar%nThe title was >>%s<<\"'\n+would show something like this:\n+\n+The author of fe6e0ee was Junio C Hamano, 23 hours ago\n+The title was >>t4119: test autocomputing -p for traditional diff input.<<\n+\n+The placeholders are:\n+\n+- '%H': commit hash\n+- '%h': abbreviated commit hash\n+- '%T': tree hash\n+- '%t': abbreviated tree hash\n+- '%P': parent hashes\n+- '%p': abbreviated parent hashes\n+- '%an': author name\n+- '%ae': author email\n+- '%ad': author date\n+- '%aD': author date, RFC2822 style\n+- '%ar': author date, relative\n+- '%at': author date, UNIX timestamp\n+- '%cn': committer name\n+- '%ce': committer email\n+- '%cd': committer date\n+- '%cD': committer date, RFC2822 style\n+- '%cr': committer date, relative\n+- '%ct': committer date, UNIX timestamp\n+- '%e': encoding\n+- '%s': subject\n+- '%b': body\n+- '%Cred': switch color to red\n+- '%Cgreen': switch color to green\n+- '%Cblue': switch color to blue\n+- '%Creset': reset color\n+- '%n': newline\n+\n+\n --encoding[=]::\n \tThe commit objects record the encoding used for the log message\n \tin their encoding header; this option can be used to tell the\n \tcommand to re-code the commit log message in the encoding\n \tpreferred by the user. For non plumbing commands this\n \tdefaults to UTF-8.\n+\ndiff --git a/commit.c b/commit.c\nindex 8d279b0..a97aef3 100644\n--- a/commit.c\n+++ b/commit.c\n@@ -3,6 +3,7 @@\n #include \"commit.h\"\n #include \"pkt-line.h\"\n #include \"utf8.h\"\n+#include \"interpolate.h\"\n \n int save_commit_buffer = 1;\n \n@@ -36,8 +37,11 @@ struct cmt_fmt_map {\n \t{ \"full\",\t5,\tCMIT_FMT_FULL },\n \t{ \"fuller\",\t5,\tCMIT_FMT_FULLER },\n \t{ \"oneline\",\t1,\tCMIT_FMT_ONELINE },\n+\t{ \"format:\",\t7,\tCMIT_FMT_USERFORMAT},\n };\n \n+static char *user_format;\n+\n enum cmit_fmt get_commit_format(const char *arg)\n {\n \tint i;\n@@ -46,6 +50,12 @@ enum cmit_fmt get_commit_format(const char *arg)\n \t\treturn CMIT_FMT_DEFAULT;\n \tif (*arg == '=')\n \t\targ++;\n+\tif (!prefixcmp(arg, \"format:\")) {\n+\t\tif (user_format)\n+\t\t\tfree(user_format);\n+\t\tuser_format = xstrdup(arg + 7);\n+\t\treturn CMIT_FMT_USERFORMAT;\n+\t}\n \tfor (i = 0; i < ARRAY_SIZE(cmt_fmts); i++) {\n \t\tif (!strncmp(arg, cmt_fmts[i].n, cmt_fmts[i].cmp_len) &&\n \t\t !strncmp(arg, cmt_fmts[i].n, strlen(arg)))\n@@ -710,6 +720,188 @@ static char *logmsg_reencode(const struct commit *commit,\n \treturn out;\n }\n \n+static char *xstrndup(const char *text, int len)\n+{\n+\tchar *result = xmalloc(len + 1);\n+\tmemcpy(result, text, len);\n+\tresult[len] = '\\0';\n+\treturn result;\n+}\n+\n+static void fill_person(struct interp *table, const char *msg, int len)\n+{\n+\tint start, end, tz = 0;\n+\tunsigned long date;\n+\tchar *ep;\n+\n+\t/* parse name */\n+\tfor (end = 0; end < len && msg[end] != '<'; end++)\n+\t\t; /* do nothing */\n+\tstart = end + 1;\n+\twhile (end > 0 && isspace(msg[end - 1]))\n+\t\tend--;\n+\ttable[0].value = xstrndup(msg, end);\n+\n+\tif (start >= len)\n+\t\treturn;\n+\n+\t/* parse email */\n+\tfor (end = start + 1; end < len && msg[end] != '>'; end++)\n+\t\t; /* do nothing */\n+\n+\tif (end >= len)\n+\t\treturn;\n+\n+\ttable[1].value = xstrndup(msg + start, end - start);\n+\n+\t/* parse date */\n+\tfor (start = end + 1; start < len && isspace(msg[start]); start++)\n+\t\t; /* do nothing */\n+\tif (start >= len)\n+\t\treturn;\n+\tdate = strtoul(msg + start, &ep, 10);\n+\tif (msg + start == ep)\n+\t\treturn;\n+\n+\ttable[5].value = xstrndup(msg + start, ep - msg + start);\n+\n+\t/* parse tz */\n+\tfor (start = ep - msg + 1; start < len && isspace(msg[start]); start++)\n+\t\t; /* do nothing */\n+\tif (start + 1 < len) {\n+\t\ttz = strtoul(msg + start + 1, NULL, 10);\n+\t\tif (msg[start] == '-')\n+\t\t\ttz = -tz;\n+\t}\n+\n+\tinterp_set_entry(table, 2, show_date(date, tz, 0));\n+\tinterp_set_entry(table, 3, show_rfc2822_date(date, tz));\n+\tinterp_set_entry(table, 4, show_date(date, tz, 1));\n+}\n+\n+static long format_commit_message(const struct commit *commit,\n+\t\tconst char *msg, char *buf, unsigned long space)\n+{\n+\tstruct interp table[] = {\n+\t\t{ \"%H\" },\t/* commit hash */\n+\t\t{ \"%h\" },\t/* abbreviated commit hash */\n+\t\t{ \"%T\" },\t/* tree hash */\n+\t\t{ \"%t\" },\t/* abbreviated tree hash */\n+\t\t{ \"%P\" },\t/* parent hashes */\n+\t\t{ \"%p\" },\t/* abbreviated parent hashes */\n+\t\t{ \"%an\" },\t/* author name */\n+\t\t{ \"%ae\" },\t/* author email */\n+\t\t{ \"%ad\" },\t/* author date */\n+\t\t{ \"%aD\" },\t/* author date, RFC2822 style */\n+\t\t{ \"%ar\" },\t/* author date, relative */\n+\t\t{ \"%at\" },\t/* author date, UNIX timestamp */\n+\t\t{ \"%cn\" },\t/* committer name */\n+\t\t{ \"%ce\" },\t/* committer email */\n+\t\t{ \"%cd\" },\t/* committer date */\n+\t\t{ \"%cD\" },\t/* committer date, RFC2822 style */\n+\t\t{ \"%cr\" },\t/* committer date, relative */\n+\t\t{ \"%ct\" },\t/* committer date, UNIX timestamp */\n+\t\t{ \"%e\" },\t/* encoding */\n+\t\t{ \"%s\" },\t/* subject */\n+\t\t{ \"%b\" },\t/* body */\n+\t\t{ \"%Cred\" },\t/* red */\n+\t\t{ \"%Cgreen\" },\t/* green */\n+\t\t{ \"%Cblue\" },\t/* blue */\n+\t\t{ \"%Creset\" },\t/* reset color */\n+\t\t{ \"%n\" }\t/* newline */\n+\t};\n+\tenum interp_index {\n+\t\tIHASH = 0, IHASH_ABBREV,\n+\t\tITREE, ITREE_ABBREV,\n+\t\tIPARENTS, IPARENTS_ABBREV,\n+\t\tIAUTHOR_NAME, IAUTHOR_EMAIL,\n+\t\tIAUTHOR_DATE, IAUTHOR_DATE_RFC2822, IAUTHOR_DATE_RELATIVE,\n+\t\tIAUTHOR_TIMESTAMP,\n+\t\tICOMMITTER_NAME, ICOMMITTER_EMAIL,\n+\t\tICOMMITTER_DATE, ICOMMITTER_DATE_RFC2822,\n+\t\tICOMMITTER_DATE_RELATIVE, ICOMMITTER_TIMESTAMP,\n+\t\tIENCODING,\n+\t\tISUBJECT,\n+\t\tIBODY,\n+\t\tIRED, IGREEN, IBLUE, IRESET_COLOR,\n+\t\tINEWLINE\n+\t};\n+\tstruct commit_list *p;\n+\tchar parents[1024];\n+\tint i;\n+\tenum { HEADER, SUBJECT, BODY } state;\n+\n+\tif (INEWLINE + 1 != ARRAY_SIZE(table))\n+\t\tdie(\"invalid interp table!\");\n+\n+\t/* these are independent of the commit */\n+\tinterp_set_entry(table, IRED, \"\\033[31m\");\n+\tinterp_set_entry(table, IGREEN, \"\\033[32m\");\n+\tinterp_set_entry(table, IBLUE, \"\\033[34m\");\n+\tinterp_set_entry(table, IRESET_COLOR, \"\\033[m\");\n+\tinterp_set_entry(table, INEWLINE, \"\\n\");\n+\n+\t/* these depend on the commit */\n+\tif (!commit->object.parsed)\n+\t\tparse_object(commit->object.sha1);\n+\tinterp_set_entry(table, IHASH, sha1_to_hex(commit->object.sha1));\n+\tinterp_set_entry(table, IHASH_ABBREV,\n+\t\t\tfind_unique_abbrev(commit->object.sha1,\n+\t\t\t\tDEFAULT_ABBREV));\n+\tinterp_set_entry(table, ITREE, sha1_to_hex(commit->tree->object.sha1));\n+\tinterp_set_entry(table, ITREE_ABBREV,\n+\t\t\tfind_unique_abbrev(commit->tree->object.sha1,\n+\t\t\t\tDEFAULT_ABBREV));\n+\tfor (i = 0, p = commit->parents;\n+\t\t\tp && i < sizeof(parents) - 1;\n+\t\t\tp = p->next)\n+\t\ti += snprintf(parents + i, sizeof(parents) - i - 1, \"%s \",\n+\t\t\tsha1_to_hex(p->item->object.sha1));\n+\tinterp_set_entry(table, IPARENTS, parents);\n+\tfor (i = 0, p = commit->parents;\n+\t\t\tp && i < sizeof(parents) - 1;\n+\t\t\tp = p->next)\n+\t\ti += snprintf(parents + i, sizeof(parents) - i - 1, \"%s \",\n+\t\t\tfind_unique_abbrev(p->item->object.sha1,\n+\t\t\t\tDEFAULT_ABBREV));\n+\tinterp_set_entry(table, IPARENTS_ABBREV, parents);\n+\n+\tfor (i = 0, state = HEADER; msg[i] && state < BODY; i++) {\n+\t\tint eol;\n+\t\tfor (eol = i; msg[eol] && msg[eol] != '\\n'; eol++)\n+\t\t\t; /* do nothing */\n+\n+\t\tif (state == SUBJECT) {\n+\t\t\ttable[ISUBJECT].value = xstrndup(msg + i, eol - i);\n+\t\t\ti = eol;\n+\t\t}\n+\t\tif (i == eol) {\n+\t\t\tstate++;\n+\t\t\t/* strip empty lines */\n+\t\t\twhile (msg[eol + 1] == '\\n')\n+\t\t\t\teol++;\n+\t\t} else if (!prefixcmp(msg + i, \"author \"))\n+\t\t\tfill_person(table + IAUTHOR_NAME,\n+\t\t\t\t\tmsg + i + 7, eol - i - 7);\n+\t\telse if (!prefixcmp(msg + i, \"committer \"))\n+\t\t\tfill_person(table + ICOMMITTER_NAME,\n+\t\t\t\t\tmsg + i + 10, eol - i - 10);\n+\t\telse if (!prefixcmp(msg + i, \"encoding \"))\n+\t\t\ttable[IENCODING].value = xstrndup(msg + i, eol - i);\n+\t\ti = eol;\n+\t}\n+\tif (msg[i])\n+\t\ttable[IBODY].value = xstrdup(msg + i);\n+\tfor (i = 0; i < ARRAY_SIZE(table); i++)\n+\t\tif (!table[i].value)\n+\t\t\tinterp_set_entry(table, i, \"\");\n+\n+\tinterpolate(buf, space, user_format, table, ARRAY_SIZE(table));\n+\tinterp_clear_table(table, ARRAY_SIZE(table));\n+\n+\treturn strlen(buf);\n+}\n+\n unsigned long pretty_print_commit(enum cmit_fmt fmt,\n \t\t\t\t const struct commit *commit,\n \t\t\t\t unsigned long len,\n@@ -727,6 +919,9 @@ unsigned long pretty_print_commit(enum cmit_fmt fmt,\n \tchar *reencoded;\n \tchar *encoding;\n \n+\tif (fmt == CMIT_FMT_USERFORMAT)\n+\t\treturn format_commit_message(commit, msg, buf, space);\n+\n \tencoding = (git_log_output_encoding\n \t\t ? git_log_output_encoding\n \t\t : git_commit_encoding);\ndiff --git a/commit.h b/commit.h\nindex c737444..83507a0 100644\n--- a/commit.h\n+++ b/commit.h\n@@ -47,6 +47,7 @@ enum cmit_fmt {\n \tCMIT_FMT_FULLER,\n \tCMIT_FMT_ONELINE,\n \tCMIT_FMT_EMAIL,\n+\tCMIT_FMT_USERFORMAT,\n \n \tCMIT_FMT_UNSPECIFIED,\n };\ndiff --git a/log-tree.c b/log-tree.c\nindex ac86194..6ce239d 100644\n--- a/log-tree.c\n+++ b/log-tree.c\n@@ -211,7 +211,7 @@ void show_log(struct rev_info *opt, const char *sep)\n \t\t\t\t sha1, sha1);\n \t\t\topt->diffopt.stat_sep = buffer;\n \t\t}\n-\t} else {\n+\t} else if (opt->commit_format != CMIT_FMT_USERFORMAT) {\n \t\tfputs(diff_get_color(opt->diffopt.color_diff, DIFF_COMMIT),\n \t\t stdout);\n \t\tif (opt->commit_format != CMIT_FMT_ONELINE)\n-- \n1.5.0.1.620.gac8f\n"},{"id":"35284","messageId":"45DE3D5C.5060105@xs4all.nl","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0702230125270.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Han-Wen Nienhuys","fromEmail":"hanwen@xs4all.nl","sentAt":"2007-02-23T01:03:24Z","receivedAt":"2007-02-23T01:03:24Z","isPatch":true,"sender":{"key":"hanwen@google.com","avatar":"https://avatars.githubusercontent.com/u/31547?v=4"},"body":"Johannes Schindelin escreveu:\n> With this patch,\n> \n> $ git show -s \\\n> \t--pretty=format:' Ze komit %h woss%n dunn buy ze great %an'\n> \n> shows something like\n> \n> Ze komit 04c5c88 woss\n> dunn buy ze great Junio C Hamano\n> \n> The supported placeholders are:\n\nnitpick:\n\n \\n\n\nfor newline would be nice. Similar for backslash, formfeed, alarm, etc.\n\n \n\n-- \n Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen\n"},{"id":"35285","messageId":"Pine.LNX.4.63.0702230204190.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"45DE3D5C.5060105@xs4all.nl","subject":"Re: [PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-23T01:07:59Z","receivedAt":"2007-02-23T01:07:59Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:\n\n> nitpick:\n> \n> \\n\n> \n> for newline would be nice. Similar for backslash, formfeed, alarm, etc.\n\nYes, I thought about that. But it would change behaviour (even if I don't \nthink it would do serious damage; the only user of interpolate.[ch] I saw \nis git-daemon, and that does not need \\n, I guess).\n\nBesides, \"%n\" is\n\n- more consistent,\n- date(1) does it the same way, and\n- you can put BS, FF, AL, etc. into the format string before passing \n it as an option to git; git does not have to help you there.\n\nCiao,\nDscho\n"},{"id":"35299","messageId":"7vslcx9ywx.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0702230125270.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-23T06:21:50Z","receivedAt":"2007-02-23T06:21:50Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n> With this patch,\n>\n> $ git show -s \\\n> \t--pretty=format:' Ze komit %h woss%n dunn buy ze great %an'\n>\n> shows something like\n>\n> Ze komit 04c5c88 woss\n> dunn buy ze great Junio C Hamano\n\nDoes it say \"This commit is by a fool whose name is blah\"?\n\n> The supported placeholders are:\n>\n> \t'%H': commit hash\n>...\n> \t'%b': body\n\nHmmm. Would we want to make them somehow interoperable with\ngit-for-each-ref format atoms?\n\nAlso, it _might_ be worthwhile to do something like \"%+4b\"\nwhich means \"indent each line of this field with 4 spaces\", for\na multi-line field like \"%b\".\n\n> \t'%Cred': switch color to red\n> \t'%Cgreen': switch color to green\n> \t'%Cblue': switch color to blue\n> \t'%Creset': reset color\n\nHmmm. I strongly suspect that we would want to reuse code to\ngrok colors and attributes in color.c.\n\n> \t> --format 'committer %c\\nauthor %a\\n'\n> \t> \n> \t> this catches all combinations, and is easier for scripting.\n\nI do not have strong preference between \"\\n\" and \"%n\".\n\n> \tSo, I overcame my laziness after 91 days...\n\nThanks.\n"},{"id":"35322","messageId":"Pine.LNX.4.63.0702231237500.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"7vslcx9ywx.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-23T11:48:07Z","receivedAt":"2007-02-23T11:48:07Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> > With this patch,\n> >\n> > $ git show -s \\\n> > \t--pretty=format:' Ze komit %h woss%n dunn buy ze great %an'\n> >\n> > shows something like\n> >\n> > Ze komit 04c5c88 woss\n> > dunn buy ze great Junio C Hamano\n> \n> Does it say \"This commit is by a fool whose name is blah\"?\n\nVy, it iss korrekt Churmen Inklish [Translation: Why, it is correct \nGerman \"English\"]... ;-)\n\n> > The supported placeholders are:\n> >\n> > \t'%H': commit hash\n> >...\n> > \t'%b': body\n> \n> Hmmm. Would we want to make them somehow interoperable with\n> git-for-each-ref format atoms?\n\nBut those placeholders are so long! Not even GNU date supports such long \nplaceholders... And I could not reuse interpolate.[ch] as is for that.\n\n> Also, it _might_ be worthwhile to do something like \"%+4b\" which means \n> \"indent each line of this field with 4 spaces\", for a multi-line field \n> like \"%b\".\n\nSame goes here: interpolate.[ch] does not (yet) allow for that.\n\n> > \t'%Cred': switch color to red\n> > \t'%Cgreen': switch color to green\n> > \t'%Cblue': switch color to blue\n> > \t'%Creset': reset color\n> \n> Hmmm. I strongly suspect that we would want to reuse code to grok \n> colors and attributes in color.c.\n\nAnd again...\n\n> > \t> --format 'committer %c\\nauthor %a\\n'\n> > \t> \n> > \t> this catches all combinations, and is easier for scripting.\n> \n> I do not have strong preference between \"\\n\" and \"%n\".\n\nThis would be easy, methink, to teach to interpolate().\n\nMaybe I can overcome my laziness, and extend interpolate() so that it can \nactually call callbacks with callback data...\n\nAlternatively, I could imitate for-each-ref, and roll my own \ninterpolate()? :-)\n\nCiao,\nDscho\n"},{"id":"35339","messageId":"7vabz44tgh.fsf@assigned-by-dhcp.cox.net","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0702231237500.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-23T18:30:54Z","receivedAt":"2007-02-23T18:30:54Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Schindelin writes:\n\n>> > The supported placeholders are:\n>> >\n>> > \t'%H': commit hash\n>> >...\n>> > \t'%b': body\n>> \n>> Hmmm. Would we want to make them somehow interoperable with\n>> git-for-each-ref format atoms?\n>\n> But those placeholders are so long! Not even GNU date supports such long \n> placeholders... And I could not reuse interpolate.[ch] as is for that.\n\nWhat I was hinting at was to fix (or extend) for-each-ref to\naccept these short-and-sweet placeholders.\n\n>> Also, it _might_ be worthwhile to do something like \"%+4b\" which means \n>> \"indent each line of this field with 4 spaces\", for a multi-line field \n>> like \"%b\".\n>\n> Same goes here: interpolate.[ch] does not (yet) allow for that.\n\nNah, if you feel it is too much work, I trust your judgement (I\ndo not recall details of how interpolate.c does its thing). I\ndo not think it's worth it.\n"},{"id":"35342","messageId":"Pine.LNX.4.63.0702231935560.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"7vabz44tgh.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-23T18:38:46Z","receivedAt":"2007-02-23T18:38:46Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Feb 2007, Junio C Hamano wrote:\n\n> Johannes Schindelin writes:\n> \n> >> > The supported placeholders are:\n> >> >\n> >> > \t'%H': commit hash\n> >> >...\n> >> > \t'%b': body\n> >> \n> >> Hmmm. Would we want to make them somehow interoperable with \n> >> git-for-each-ref format atoms?\n> >\n> > But those placeholders are so long! Not even GNU date supports such \n> > long placeholders... And I could not reuse interpolate.[ch] as is for \n> > that.\n> \n> What I was hinting at was to fix (or extend) for-each-ref to accept \n> these short-and-sweet placeholders.\n\nAh, the other way round...\n\n> >> Also, it _might_ be worthwhile to do something like \"%+4b\" which \n> >> means \"indent each line of this field with 4 spaces\", for a \n> >> multi-line field like \"%b\".\n> >\n> > Same goes here: interpolate.[ch] does not (yet) allow for that.\n> \n> Nah, if you feel it is too much work, I trust your judgement (I\n> do not recall details of how interpolate.c does its thing). I\n> do not think it's worth it.\n\nSure, it _would_ be nice to let interpolate call back, instead of having \nto fill a table with static strings (xstrdup()ing them, no less).\n\nHowever, I want to go play Snooker tonight, so this is up-for-grabs.\n\nCiao,\nDscho\n"},{"id":"35345","messageId":"200702232053.49489.robin.rosenberg.lists@dewire.com","threadId":"6919","inReplyTo":"Pine.LNX.4.63.0702230204190.22628@wbgn013.biozentrum.uni-wuerzburg.de","subject":"Re: [PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Robin Rosenberg","fromEmail":"robin.rosenberg.lists@dewire.com","sentAt":"2007-02-23T19:53:49Z","receivedAt":"2007-02-23T19:53:49Z","isPatch":true,"sender":{"key":"robin.rosenberg@dewire.com","avatar":"https://avatars.githubusercontent.com/u/46357?v=4"},"body":"fredag 23 februari 2007 02:07 skrev Johannes Schindelin:\n> Hi,\n> \n> On Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:\n> \n> > nitpick:\n> > \n> > \\n\n> > \n> > for newline would be nice. Similar for backslash, formfeed, alarm, etc.\n> \n> Yes, I thought about that. But it would change behaviour (even if I don't \n> think it would do serious damage; the only user of interpolate.[ch] I saw \n> is git-daemon, and that does not need \\n, I guess).\nOther tools that come to mind, rpm and clearcase use \\n vfor newline in the\nformat argument, which is good because I can guess that even without looking \nat the documentation. %n I'd guess would be for a number of some kind, e..g.\nthe ordinal number of the commit listed (in subset and order of the listed commits)\n\n> Besides, \"%n\" is\n> \n> - more consistent,\nwith...?\n> - date(1) does it the same way, and\nOk, I learnt something. Never fi\n> - you can put BS, FF, AL, etc. into the format string before passing \n> it as an option to git; git does not have to help you there.\nThey are hard to type in shells and even harder in gui's.\n\n-- robin\n"},{"id":"35373","messageId":"Pine.LNX.4.63.0702240222100.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6919","inReplyTo":"200702232053.49489.robin.rosenberg.lists@dewire.com","subject":"Re: [PATCH for \"next\"] pretty-formats: add 'format:'","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-02-24T01:25:50Z","receivedAt":"2007-02-24T01:25:50Z","isPatch":true,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Feb 2007, Robin Rosenberg wrote:\n\n> fredag 23 februari 2007 02:07 skrev Johannes Schindelin:\n> > \n> > On Fri, 23 Feb 2007, Han-Wen Nienhuys wrote:\n> > \n> > > nitpick:\n> > > \n> > > \\n\n> > > \n> > > for newline would be nice. Similar for backslash, formfeed, alarm, \n> > > etc.\n> > \n> > Yes, I thought about that. But it would change behaviour (even if I \n> > don't think it would do serious damage; the only user of \n> > interpolate.[ch] I saw is git-daemon, and that does not need \\n, I \n> > guess).\n>\n> Other tools that come to mind, rpm and clearcase use \\n vfor newline in \n> the format argument, which is good because I can guess that even without \n> looking at the documentation. %n I'd guess would be for a number of some \n> kind, e..g. the ordinal number of the commit listed (in subset and order \n> of the listed commits)\n\nOkay. Patch?\n\n> > Besides, \"%n\" is\n> > \n> > - more consistent,\n>\n> with...?\n\n... itself? Why should not _one_ escape character be enough?\n\n> > - you can put BS, FF, AL, etc. into the format string before passing\n> > it as an option to git; git does not have to help you there.\n>\n> They are hard to type in shells and even harder in gui's.\n\nYou would not do that all that often, but rather write a script. Even the \nconfig format allows for inclusion of special characters, so aliases \nshould be fine.\n\nCiao,\nDscho\n"}]}