{"thread":{"id":"6587","subject":"Difficulties in advertising a new branch to git newbies","startedAt":"2007-01-30T20:13:26Z","lastAt":"2007-02-06T19:58:35Z","messageCount":50,"participants":["Carl Worth","Jakub Narebski","Yann Dirson","Junio C Hamano","Matthias Lederhofer","Jeff King","Daniel Barkalow","Nicolas Pitre","Guilhem Bonnefille","J. Bruce Fields","Johannes Schindelin","Santi Béjar","Theodore Tso","Josef Weidendorfer"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"33082","messageId":"87odognuhl.wl%cworth@cworth.org","threadId":"6587","inReplyTo":null,"subject":"Difficulties in advertising a new branch to git newbies","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-30T20:13:26Z","receivedAt":"2007-01-30T20:13:26Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"So here's a scenario I'm in right now. A user of my software reported a\nbug. I put together some patches to fix the bug and pushed them out as\na new branch \"proposed-fix\" that I'd like the user to test.\n\nI'm trying to let the user know about the new branch, but I have some\nusers that know nothing about git. So I'm going to spell things out\nfairly carefully, (which I'm glad to do). I also don't know how recent\na version of git the user has, (for example if clone will give\nseparate remotes or not).\n\nAlso, these users are glad to follow instructions, but they're really\ninterested in just testing the fix I'm offering, and not interested in\ngetting involved in a git tutorial just yet. (Though, I'd be quite\nhappy if they found this a gentle and enjoyable introduction to git).\n\nI'm finding that the instructions I'm having to write are much more\ncomplicated than I would like them to be. And some of this is due to\nincompatibility between git 1.5 and previous versions. I would be glad\nto see improvements to my instructions, (or improvements to git to\nallow my instructions to be simpler).\n\nHere's what I've done historically:\n\n\tI've published a new \"proposed-fix\" that I'd like you to\n\ttest. You can obtain this code as follows:\n\n\t\tgit clone git://git.project.org/~cworth/project\n\t\tcd project\n\t\tgit checkout -b build proposed-fix\n\n\tor alternately, if you've already got a clone of the project\n\taround, just do:\n\n\t\tgit fetch git://git.project.org/~cworth/project proposed-fix:proposed-fix\n\t\tgit checkout -b build proposed-fix\n\nThe things I haven't liked in the above are:\n\n\t1. The doubled-up \"branch:branch\" thing in git-fetch, which\n just plain looks awkward. Yes, it's common for \"git pull\"\n to fetch something and not store it in any branch, but it\n seems that it could ask for that behavior explicitly and we\n could make \"fetch URL branch\" act as \"fetch URL\n branch:branch\".\n\n\t2. The \"-b build\" thing in git-checkout. Worse than just\n looking awkward, this causes a real problem, since my\n git-fetch instructions only work the first time, (if they\n follow them later they're going to run into \"branch build\n already exists\"). Detached head in 1.5 should help here,\n but see below.\n\n\t3. The separation between how to clone and how to fetch into\n an existing repository is annoying. What I'd really like to\n do is just publish something like:\n\n\t\tgit://git.project.org/~cworth/project proposed-fix\n\n\t and allow users to just cut-and-paste that to commands as\n\t needed. That is, I think it would be nice if \"git fetch\" or\n\t \"git clone\" could accept the \"URL branch\" string above and\n\t just do the right thing with it.\n\nI've been hoping that some of the recent 1.5 work on git would make\nthis process simpler. But in fact it makes things worse. First, my\nhistoric instructions don't work anymore with separate remotes. So I\nwould have to add something like:\n\n\tHowever, if you're using a very recent version of git, (1.5 or\n\tnewer), then you'll need to use this alternate checkout\n\tcommand instead:\n\n\t\tgit checkout -b build origin/proposed-fix\n\nI really like most of what separate-remotes does. But I don't like\nthat branch names no longer resolve the same way they used to. Could\nwe fix git to resolve \"branch\" as \"remotes/*/branch\" if unique? That\nwould allow the old instructions and old habits to continue to work,\n(making the change to separate-remotes much more compatible).\n\nAlso, if I'm willing to assume (or insist) that users have git 1.5 or\nnewer, it'd be nice to be able to drop the \"-b build\" thing thanks to\nthe new detached HEAD support. But if I suggest doing just:\n\n\t\tgit checkout origin/proposed-fix\n\nthe user is presented with the following message which is much more\nscary than useful in this situation:\n\n\twarning: you are not on ANY branch anymore.\n\tIf you meant to create a new branch from the commit, you need -b to\n\tassociate a new branch with the wanted checkout. Example:\n\t git checkout -b origin/proposed-fix\n\nThe user is getting warned, getting told they perhaps wanted to do\nsomething else, and getting told that if so they would need to use a\ndifferent command. But the command I gave does exactly what they\nwanted, and following git's advice here would be a bad idea.\n\nI propose this warning be removed here. Otherwise, I either add text\nto my instructions telling the user to ignore the warning message they\nget, or else I go back to \"-b build\" and back to all the old problems\nit causes.\n\nThanks for your time and attention,\n\n-Carl\n"},{"id":"33085","messageId":"epobn1$jv8$1@sea.gmane.org","threadId":"6587","inReplyTo":"87odognuhl.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-30T21:02:40Z","receivedAt":"2007-01-30T21:02:40Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> The things I haven't liked in the above are:\n> \n> 1. The doubled-up \"branch:branch\" thing in git-fetch, which\n> just plain looks awkward. Yes, it's common for \"git pull\"\n> to fetch something and not store it in any branch, but it\n> seems that it could ask for that behavior explicitly and we\n> could make \"fetch URL branch\" act as \"fetch URL\n> branch:branch\".\n\nIf youd don't mind fetching more, you can ask just to do \"git fetch\".\n \nBut, currently:\n\n * A parameter without a colon is equivalent to\n : when pulling/fetching, so it merges into the current\n branch without storing the remote branch anywhere locally\n\nI don't think it would be bad if we changed to mean :\nand require : to pull without storing remote branch anywhere locally;\nthe problem is that we probably want :/.\n\nAn alternative would be to tag a fix, and as to do the following\n\n $ git fetch origin tag proposed-fix\n\n> 2. The \"-b build\" thing in git-checkout. Worse than just\n> looking awkward, this causes a real problem, since my\n> git-fetch instructions only work the first time, (if they\n> follow them later they're going to run into \"branch build\n> already exists\"). Detached head in 1.5 should help here,\n> but see below.\n\nAn alternative would be to have some branch used only to bring\nworking directory to given state, by using \"git reset --hard \"\nwhile being on it.\n\nE.g.\n\n $ git checkout build\n $ git reset --hard proposed-fix\n\n(assuming that 'build' branch was created earlier).\n\n> 3. The separation between how to clone and how to fetch into\n> an existing repository is annoying. What I'd really like to\n> do is just publish something like:\n> \n> git://git.project.org/~cworth/project proposed-fix\n> \n> and allow users to just cut-and-paste that to commands as\n> needed. That is, I think it would be nice if \"git fetch\" or\n> \"git clone\" could accept the \"URL branch\" string above and\n> just do the right thing with it.\n> \n[...]\n> Also, if I'm willing to assume (or insist) that users have git 1.5 or\n> newer, it'd be nice to be able to drop the \"-b build\" thing thanks to\n> the new detached HEAD support. But if I suggest doing just:\n> \n> git checkout origin/proposed-fix\n> \n> the user is presented with the following message which is much more\n> scary than useful in this situation:\n> \n> warning: you are not on ANY branch anymore.\n> If you meant to create a new branch from the commit, you need -b to\n> associate a new branch with the wanted checkout. Example:\n> git checkout -b origin/proposed-fix\n> \n> The user is getting warned, getting told they perhaps wanted to do\n> something else, and getting told that if so they would need to use a\n> different command. But the command I gave does exactly what they\n> wanted, and following git's advice here would be a bad idea.\n> \n> I propose this warning be removed here. Otherwise, I either add text\n> to my instructions telling the user to ignore the warning message they\n> get, or else I go back to \"-b build\" and back to all the old problems\n> it causes.\n\nI rather leave warning, but (perhaps around 1.5.1) remove the\ninstructions. RTFM (err... I'm not sure we have one about detached HEAD).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33086","messageId":"20070130212511.GA5362@nan92-1-81-57-214-146.fbx.proxad.net","threadId":"6587","inReplyTo":"epobn1$jv8$1@sea.gmane.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Yann Dirson","fromEmail":"ydirson@altern.org","sentAt":"2007-01-30T21:25:11Z","receivedAt":"2007-01-30T21:25:11Z","isPatch":false,"sender":{"key":"ydirson@altern.org","avatar":"https://avatars.githubusercontent.com/u/1190950?v=4"},"body":"On Tue, Jan 30, 2007 at 10:02:40PM +0100, Jakub Narebski wrote:\n> > I propose this warning be removed here. Otherwise, I either add text\n> > to my instructions telling the user to ignore the warning message they\n> > get, or else I go back to \"-b build\" and back to all the old problems\n> > it causes.\n> \n> I rather leave warning, but (perhaps around 1.5.1) remove the\n> instructions. RTFM (err... I'm not sure we have one about detached HEAD).\n\nOr provide a \"-q\" flag to silence the warning ?\n\n-- \nYann.\n"},{"id":"33087","messageId":"200701302231.02295.jnareb@gmail.com","threadId":"6587","inReplyTo":"20070130212511.GA5362@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-30T21:31:01Z","receivedAt":"2007-01-30T21:31:01Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":" Yann Dirson wrote:\n> On Tue, Jan 30, 2007 at 10:02:40PM +0100, Jakub Narebski wrote:\n\n>>> I propose this warning be removed here. Otherwise, I either add text\n>>> to my instructions telling the user to ignore the warning message they\n>>> get, or else I go back to \"-b build\" and back to all the old problems\n>>> it causes.\n>> \n>> I rather leave warning, but (perhaps around 1.5.1) remove the\n>> instructions. RTFM (err... I'm not sure we have one about detached HEAD).\n> \n> Or provide a \"-q\" flag to silence the warning ?\n\nWell, it would be nice to have either when command is usually silent to\nhave \"-q\" option to it, or have \"-q\" option to git wrapper (especially\nfor gitweb).\n\n-- \nJakub Narebski\nPoland\n"},{"id":"33088","messageId":"7vwt34xksz.fsf@assigned-by-dhcp.cox.net","threadId":"6587","inReplyTo":"20070130212511.GA5362@nan92-1-81-57-214-146.fbx.proxad.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-30T21:32:28Z","receivedAt":"2007-01-30T21:32:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Yann Dirson writes:\n\n> On Tue, Jan 30, 2007 at 10:02:40PM +0100, Jakub Narebski wrote:\n>> > I propose this warning be removed here. Otherwise, I either add text\n>> > to my instructions telling the user to ignore the warning message they\n>> > get, or else I go back to \"-b build\" and back to all the old problems\n>> > it causes.\n>> \n>> I rather leave warning, but (perhaps around 1.5.1) remove the\n>> instructions. RTFM (err... I'm not sure we have one about detached HEAD).\n>\n> Or provide a \"-q\" flag to silence the warning ?\n\nOr maybe make \"-f\" to mean \"I know what I am doing, do not\nwarn\".\n\nP.S. Jakub, *please* do not break the thread.\n"},{"id":"33089","messageId":"200701302240.09212.jnareb@gmail.com","threadId":"6587","inReplyTo":"7vwt34xksz.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-30T21:40:08Z","receivedAt":"2007-01-30T21:40:08Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n> Yann Dirson writes:\n> \n>> On Tue, Jan 30, 2007 at 10:02:40PM +0100, Jakub Narebski wrote:\n>>>> I propose this warning be removed here. Otherwise, I either add text\n>>>> to my instructions telling the user to ignore the warning message they\n>>>> get, or else I go back to \"-b build\" and back to all the old problems\n>>>> it causes.\n>>> \n>>> I rather leave warning, but (perhaps around 1.5.1) remove the\n>>> instructions. RTFM (err... I'm not sure we have one about detached HEAD).\n>>\n>> Or provide a \"-q\" flag to silence the warning ?\n> \n> Or maybe make \"-f\" to mean \"I know what I am doing, do not\n> warn\".\n\nUnfortunately \"-f\" in git-checkout mean \"force a re-read of everything.\"\nBesides I'd like to have \"-q\" option for example for git-cat-file for\ngitweb...\n\n> P.S. Jakub, *please* do not break the thread.\n\nI'll try.\n-- \nJakub Narebski\nPoland\n"},{"id":"33091","messageId":"20070130223349.GA30623@moooo.ath.cx","threadId":"6587","inReplyTo":"87odognuhl.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-01-30T22:33:49Z","receivedAt":"2007-01-30T22:33:49Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"How about this:\n\nCreate a directory, change into it and run git-init-db.\nGet the latest version:\n$ git fetch --force URL branch:origin\n$ git reset --hard origin\nWarning: this will overwrite changes you made to files in the\nrepository (e.g. the Makefile).\n\nYou can also drop the --force if you're sure your branch will always\nfast-forward.\n"},{"id":"33092","messageId":"20070130223645.GB30623@moooo.ath.cx","threadId":"6587","inReplyTo":"20070130223349.GA30623@moooo.ath.cx","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Matthias Lederhofer","fromEmail":"matled@gmx.net","sentAt":"2007-01-30T22:36:45Z","receivedAt":"2007-01-30T22:36:45Z","isPatch":false,"sender":{"key":"matled@gmx.net","avatar":null},"body":"Matthias Lederhofer wrote:\n> How about this:\n> \n> [..]\nReading your original post again: this is not exactly nice but it\nshould work with any version of git, there shouldn't be many error\nconditions and it allows to use the same commands for the initial\ncheckout and later updates.\n"},{"id":"33094","messageId":"20070130231015.GB10075@coredump.intra.peff.net","threadId":"6587","inReplyTo":"87odognuhl.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-30T23:10:15Z","receivedAt":"2007-01-30T23:10:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 30, 2007 at 12:13:26PM -0800, Carl Worth wrote:\n\n> Also, if I'm willing to assume (or insist) that users have git 1.5 or\n> newer, it'd be nice to be able to drop the \"-b build\" thing thanks to\n> the new detached HEAD support. But if I suggest doing just:\n> \n> \t\tgit checkout origin/proposed-fix\n> \n> the user is presented with the following message which is much more\n> scary than useful in this situation:\n> \n> \twarning: you are not on ANY branch anymore.\n> \tIf you meant to create a new branch from the commit, you need -b to\n> \tassociate a new branch with the wanted checkout. Example:\n> \t git checkout -b origin/proposed-fix\n\nI don't see any reason why we can't scare the user when making a commit,\ninstead of just checkout out to look around. Something like the patch\nbelow. It needs a few things:\n - remove the old checkout message\n - we wrap the colorization over the multi-line message. Probably a\n color_printf_lines() function should be added\n - if colorization is enabled, print it using color.status.warning\n (default to red).\n\nI'm happy to make all those happen if there is interest (Junio, please\ncomment).\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 5567868..285c824 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -22,6 +22,12 @@ static const char use_add_rm_msg[] =\n \"use \\\"git add/rm ...\\\" to update what will be committed\";\n static const char use_add_to_include_msg[] =\n \"use \\\"git add ...\\\" to include in what will be committed\";\n+static const char detach_warn[] =\n+\"# Any commits you make may become inaccessible if you checkout\\n\"\n+\"# another branch. To save them, you may create a new branch\\n\"\n+\"# from the current HEAD using:\\n\"\n+\"# git checkout -b \\n\"\n+\"#\";\n \n static int parse_status_slot(const char *var, int offset)\n {\n@@ -303,16 +309,13 @@ void wt_status_print(struct wt_status *s)\n \ts->is_initial = get_sha1(s->reference, sha1) ? 1 : 0;\n \n \tif (s->branch) {\n-\t\tconst char *on_what = \"On branch \";\n-\t\tconst char *branch_name = s->branch;\n-\t\tif (!strncmp(branch_name, \"refs/heads/\", 11))\n-\t\t\tbranch_name += 11;\n-\t\telse if (!strcmp(branch_name, \"HEAD\")) {\n-\t\t\tbranch_name = \"\";\n-\t\t\ton_what = \"Not currently on any branch.\";\n+\t\tconst char *c = color(WT_STATUS_HEADER);\n+\t\tif (!strncmp(s->branch, \"refs/heads/\", 11))\n+\t\t\tcolor_printf_ln(c, \"# On branch %s\", s->branch+11);\n+\t\telse {\n+\t\t\tcolor_printf_ln(c, \"# Not currently on any branch.\");\n+\t\t\tcolor_printf_ln(c, detach_warn);\n \t\t}\n-\t\tcolor_printf_ln(color(WT_STATUS_HEADER),\n-\t\t\t\"# %s%s\", on_what, branch_name);\n \t}\n \n \tif (s->is_initial) {\n"},{"id":"33097","messageId":"Pine.LNX.4.64.0701301853300.20138@iabervon.org","threadId":"6587","inReplyTo":"87odognuhl.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-31T00:10:47Z","receivedAt":"2007-01-31T00:10:47Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 30 Jan 2007, Carl Worth wrote:\n\n> Also, if I'm willing to assume (or insist) that users have git 1.5 or\n> newer, it'd be nice to be able to drop the \"-b build\" thing thanks to\n> the new detached HEAD support. But if I suggest doing just:\n> \n> \t\tgit checkout origin/proposed-fix\n> \n> the user is presented with the following message which is much more\n> scary than useful in this situation:\n> \n> \twarning: you are not on ANY branch anymore.\n> \tIf you meant to create a new branch from the commit, you need -b to\n> \tassociate a new branch with the wanted checkout. Example:\n> \t git checkout -b origin/proposed-fix\n\nI think the warning should just be something where a user following your \ninstructions will say, \"ah, yes, that's actually what I want.\" Maybe:\n\n warning: you are now browsing the history without a local branch. You \n will not be able to commit changes unless you create a new local branch \n with \"git checkout -b \".\n\nIt's a bit silly for us to simply warn people that they're using this \nfeature, rather than telling them what the potential downside is. Since \nit's marked as a warning, with no further information, the intuitive \ninference is that all sorts of bad things could happen (like, too many for \nus to list). At least we don't say \"warning: your HEAD is now detatched\" \nbut still...\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"33099","messageId":"7vzm80vv1s.fsf@assigned-by-dhcp.cox.net","threadId":"6587","inReplyTo":"20070130231015.GB10075@coredump.intra.peff.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-31T01:34:07Z","receivedAt":"2007-01-31T01:34:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Jan 30, 2007 at 12:13:26PM -0800, Carl Worth wrote:\n>\n>> Also, if I'm willing to assume (or insist) that users have git 1.5 or\n>> newer, it'd be nice to be able to drop the \"-b build\" thing thanks to\n>> the new detached HEAD support. But if I suggest doing just:\n>> \n>> \t\tgit checkout origin/proposed-fix\n>> \n>> the user is presented with the following message which is much more\n>> scary than useful in this situation:\n>> \n>> \twarning: you are not on ANY branch anymore.\n>> \tIf you meant to create a new branch from the commit, you need -b to\n>> \tassociate a new branch with the wanted checkout. Example:\n>> \t git checkout -b origin/proposed-fix\n>\n> I don't see any reason why we can't scare the user when making a commit,\n> instead of just checkout out to look around. Something like the patch\n> below. It needs a few things:\n> - remove the old checkout message\n> - we wrap the colorization over the multi-line message. Probably a\n> color_printf_lines() function should be added\n> - if colorization is enabled, print it using color.status.warning\n> (default to red).\n>\n> I'm happy to make all those happen if there is interest (Junio, please\n> comment).\n\nThat does not protect anything other than interactive \"git\ncommit\". People often do \"git commit -m\" or \"git commit -C\".\nIn addition, rebasing a detached HEAD, merging into a detached\nHEAD, cherry-picking onto a detached HEAD or running reset on a\ndetached HEAD to move to a particular state you want to look at\nare all useful and valid operations, and you wouldn't get any\nwarning when you do so.\n\nI do not think warning at every step that you are \"in a funny\nstate\" does not help productivity, so I'd prefer warning upfront\nonce and be silent afterwards, until you try to come back with\n\"git checkout \", potentially losing your state,\nwhich is what we currently do.\n\nHaving said that, I think making \"git checkout -f\" not to issue\nthe warning might be enough. Actually, I would even say it\nwould make perfect sense.\n\nFor situations like Carl's intstruction where a user, who is\npurely a sightseer, uses the detached HEAD to go-and-look a\nparticular state, the fact that \"-f\" loses the previous local\nmodifications is not an issue at all. On the other hand, if the\nuser is a developer who uses git, the warning upfront (if we\nwant to keep it for educational purposes, to make people aware\nof what is happening) is useful without \"-f\", and when a user\nwho is using git to manage his own development, he hopefully\nknows what \"git checkout -f\" means to his local modifications\nalready.\n"},{"id":"33100","messageId":"Pine.LNX.4.64.0701302042160.3021@xanadu.home","threadId":"6587","inReplyTo":"20070130231015.GB10075@coredump.intra.peff.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T01:48:13Z","receivedAt":"2007-01-31T01:48:13Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 30 Jan 2007, Jeff King wrote:\n\n> On Tue, Jan 30, 2007 at 12:13:26PM -0800, Carl Worth wrote:\n> \n> > Also, if I'm willing to assume (or insist) that users have git 1.5 or\n> > newer, it'd be nice to be able to drop the \"-b build\" thing thanks to\n> > the new detached HEAD support. But if I suggest doing just:\n> > \n> > \t\tgit checkout origin/proposed-fix\n> > \n> > the user is presented with the following message which is much more\n> > scary than useful in this situation:\n> > \n> > \twarning: you are not on ANY branch anymore.\n> > \tIf you meant to create a new branch from the commit, you need -b to\n> > \tassociate a new branch with the wanted checkout. Example:\n> > \t git checkout -b origin/proposed-fix\n\nNote that the latest revision on the master branch of git has a slightly \nless scary message.\n\n> I don't see any reason why we can't scare the user when making a commit,\n> instead of just checkout out to look around. Something like the patch\n> below. It needs a few things:\n> - remove the old checkout message\n\nI don't think that is a good idea in general.\n\nIt is already kind of a challenge to teach people about git's branch \nconcept. The detached head is yet another exotic thing about git that \nis sure not to be really obvious to everyone. Now if you remove the \nmessage to hide the detached head state from the user just to come later \non with a \"hey btw did you know that your head was detached?\" message \nthen you can be assured that most people will simply go WTF.\n\n\nNicolas\n"},{"id":"33101","messageId":"Pine.LNX.4.64.0701302050520.3021@xanadu.home","threadId":"6587","inReplyTo":"7vzm80vv1s.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T01:51:59Z","receivedAt":"2007-01-31T01:51:59Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 30 Jan 2007, Junio C Hamano wrote:\n\n> Having said that, I think making \"git checkout -f\" not to issue\n> the warning might be enough. Actually, I would even say it\n> would make perfect sense.\n\nI agree entirely.\n\n\nNicolas\n"},{"id":"33102","messageId":"Pine.LNX.4.64.0701302052230.3021@xanadu.home","threadId":"6587","inReplyTo":"Pine.LNX.4.64.0701301853300.20138@iabervon.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T01:55:11Z","receivedAt":"2007-01-31T01:55:11Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 30 Jan 2007, Daniel Barkalow wrote:\n\n> warning: you are now browsing the history without a local branch. You \n> will not be able to commit changes unless you create a new local branch \n> with \"git checkout -b \".\n\nThis isn't true. You can commit on top of a detached head. In fact you \ncan do almost anything.\n\n\nNicolas\n"},{"id":"33104","messageId":"20070131032248.GA17504@coredump.intra.peff.net","threadId":"6587","inReplyTo":"7vzm80vv1s.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-31T03:22:48Z","receivedAt":"2007-01-31T03:22:48Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Jan 30, 2007 at 05:34:07PM -0800, Junio C Hamano wrote:\n\n> That does not protect anything other than interactive \"git\n> commit\". People often do \"git commit -m\" or \"git commit -C\".\n\nYes, those should be covered by a message.\n\n> In addition, rebasing a detached HEAD, merging into a detached\n> HEAD, cherry-picking onto a detached HEAD or running reset on a\n\nI'm not even sure what it means to rebase a detached HEAD. Merging\nand cherry picking should make a similar warning.\n\n> detached HEAD to move to a particular state you want to look at\n\nRunning reset on a detached HEAD isn't a problem unless you've done one\nof the other things.\n\n> I do not think warning at every step that you are \"in a funny\n> state\" does not help productivity, so I'd prefer warning upfront\n> once and be silent afterwards, until you try to come back with\n> \"git checkout \", potentially losing your state,\n> which is what we currently do.\n\nI didn't quite parse your first sentence, but I think I get the general\nmeaning. I just think it is awkward to have to either see such a warning\n(or use -f) just to _look_ at detached commits, when you aren't doing\nanything even remotely dangerous. The dangerous thing is _creating_\ncommits on top of a detached head. I honestly don't think it should be\nallowed at all, but since some people have argued that it is useful,\nthat seems like the place to put warnings. Anything else is just making\nthings more confusing for the sorts of people Carl is dealing with --\nthose who merely want to look around.\n\n> For situations like Carl's intstruction where a user, who is\n> purely a sightseer, uses the detached HEAD to go-and-look a\n> particular state, the fact that \"-f\" loses the previous local\n\nYes, though it would be nicer not to have to explain to them why '-f' is\nneeded.\n\n-Peff\n"},{"id":"33110","messageId":"Pine.LNX.4.64.0701302331440.20138@iabervon.org","threadId":"6587","inReplyTo":"Pine.LNX.4.64.0701302052230.3021@xanadu.home","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-31T05:09:42Z","receivedAt":"2007-01-31T05:09:42Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 30 Jan 2007, Nicolas Pitre wrote:\n\n> On Tue, 30 Jan 2007, Daniel Barkalow wrote:\n> \n> > warning: you are now browsing the history without a local branch. You \n> > will not be able to commit changes unless you create a new local branch \n> > with \"git checkout -b \".\n> \n> This isn't true. You can commit on top of a detached head. In fact you \n> can do almost anything.\n\n\"Commits you make will not be attached to permanent state unless you \ncreate a local branch\"? I'm not sure how the feature turned out to work, \nbut I know that (a) you're fine if you don't make any commits and (b) the \nbehavior is more like what happens with anonymous checkouts of other \npeople's repositories in non-distributed SCMs, so people will tend to\nunderestimate what they can do with this, rather than overestimating it \nand getting into trouble.\n\nI suppose it's reasonable to warn at commit time, if we ended up going \nwith allowing commits like normal.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"33128","messageId":"8b65902a0701310513s1f8bfa04o7e1c7e43b7453ac8@mail.gmail.com","threadId":"6587","inReplyTo":"87odognuhl.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Guilhem Bonnefille","fromEmail":"guilhem.bonnefille@gmail.com","sentAt":"2007-01-31T13:13:42Z","receivedAt":"2007-01-31T13:13:42Z","isPatch":false,"sender":{"key":"guilhem.bonnefille@gmail.com","avatar":"https://gravatar.com/avatar/375364bfee1f61197c540e37465abe3619fc24eb3a36b0edcea7f15b124036b0?d=mp&s=160"},"body":"On 1/30/07, Carl Worth wrote:\n> Also, these users are glad to follow instructions, but they're really\n> interested in just testing the fix I'm offering, and not interested in\n> getting involved in a git tutorial just yet. (Though, I'd be quite\n> happy if they found this a gentle and enjoyable introduction to git).\n\nIf the user is not a developer and only interested in testing, what\nabout a simple snapshot tarball?\nSo, you prepare the fix and then you pack everything in a\nmyapp-timestamp.tar.gz and send this tarball to the user.\n\n-- \nGuilhem BONNEFILLE\n-=- #UIN: 15146515 JID: guyou@im.apinc.org MSN: guilhem_bonnefille@hotmail.com\n-=- mailto:guilhem.bonnefille@gmail.com\n-=- http://nathguil.free.fr/\n"},{"id":"33132","messageId":"Pine.LNX.4.64.0701310923010.3021@xanadu.home","threadId":"6587","inReplyTo":"Pine.LNX.4.64.0701302331440.20138@iabervon.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T14:31:00Z","receivedAt":"2007-01-31T14:31:00Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 31 Jan 2007, Daniel Barkalow wrote:\n\n> On Tue, 30 Jan 2007, Nicolas Pitre wrote:\n> \n> > On Tue, 30 Jan 2007, Daniel Barkalow wrote:\n> > \n> > > warning: you are now browsing the history without a local branch. You \n> > > will not be able to commit changes unless you create a new local branch \n> > > with \"git checkout -b \".\n> > \n> > This isn't true. You can commit on top of a detached head. In fact you \n> > can do almost anything.\n> \n> \"Commits you make will not be attached to permanent state unless you \n> create a local branch\"? I'm not sure how the feature turned out to work, \n> but I know that (a) you're fine if you don't make any commits and (b) the \n> behavior is more like what happens with anonymous checkouts of other \n> people's repositories in non-distributed SCMs, so people will tend to\n> underestimate what they can do with this, rather than overestimating it \n> and getting into trouble.\n> \n> I suppose it's reasonable to warn at commit time, if we ended up going \n> with allowing commits like normal.\n\nI disagree.\n\nIt is not the commit which is dangerous when the head is detached. It \nis the checkout of another branch. And this case is covered already \nsuch that the checkout is refused unless you actually create a branch \nfor your detached head or you give -f to checkout to override the \nprotection.\n\nGiving a warning at commit time is not the place where the user has to \nbe aware of the issue since it is indeed not the place where there is \nany issue to worry about.\n\n\nNicolas\n"},{"id":"33133","messageId":"20070131143811.GC10646@fieldses.org","threadId":"6587","inReplyTo":"Pine.LNX.4.64.0701310923010.3021@xanadu.home","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"J. Bruce Fields","fromEmail":"bfields@fieldses.org","sentAt":"2007-01-31T14:38:11Z","receivedAt":"2007-01-31T14:38:11Z","isPatch":false,"sender":{"key":"bfields@citi.umich.edu","avatar":null},"body":"On Wed, Jan 31, 2007 at 09:31:00AM -0500, Nicolas Pitre wrote:\n> It is not the commit which is dangerous when the head is detached. It \n> is the checkout of another branch. And this case is covered already \n> such that the checkout is refused unless you actually create a branch \n> for your detached head or you give -f to checkout to override the \n> protection.\n> \n> Giving a warning at commit time is not the place where the user has to \n> be aware of the issue since it is indeed not the place where there is \n> any issue to worry about.\n\nBy the same argument, the original checkout of a non-branch is also not\nthe place for a warning; by the time you commit and then do a checkout\nto switch away from the new commit, that original checkout may be a\ndistant memory.\n\n--b.\n"},{"id":"33134","messageId":"epqaej$nug$1@sea.gmane.org","threadId":"6587","inReplyTo":"20070131143811.GC10646@fieldses.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-31T14:53:23Z","receivedAt":"2007-01-31T14:53:23Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"J. Bruce Fields wrote:\n> On Wed, Jan 31, 2007 at 09:31:00AM -0500, Nicolas Pitre wrote:\n\n>> It is not the commit which is dangerous when the head is detached. It \n>> is the checkout of another branch. And this case is covered already \n>> such that the checkout is refused unless you actually create a branch \n>> for your detached head or you give -f to checkout to override the \n>> protection.\n>> \n>> Giving a warning at commit time is not the place where the user has to \n>> be aware of the issue since it is indeed not the place where there is \n>> any issue to worry about.\n\nI'd like to have some configuration option to make git more careful\nand prohibit commiting in detached HEAD state (the default being that\nyou can commit on top of detached HEAD). More secure but less powerfull.\n \n> By the same argument, the original checkout of a non-branch is also not\n> the place for a warning; by the time you commit and then do a checkout\n> to switch away from the new commit, that original checkout may be a\n> distant memory.\n\nBut the initial checkout of a non-branch is place where we can notify\nuser that he does something unexpected / unusual. Though I think that\nsingle-line warning would be enough...\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33135","messageId":"Pine.LNX.4.64.0701310932320.3021@xanadu.home","threadId":"6587","inReplyTo":"20070131032248.GA17504@coredump.intra.peff.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T14:59:08Z","receivedAt":"2007-01-31T14:59:08Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 30 Jan 2007, Jeff King wrote:\n\n> I just think it is awkward to have to either see such a warning\n> (or use -f) just to _look_ at detached commits, when you aren't doing\n> anything even remotely dangerous. The dangerous thing is _creating_\n> commits on top of a detached head. I honestly don't think it should be\n> allowed at all, but since some people have argued that it is useful,\n> that seems like the place to put warnings. Anything else is just making\n> things more confusing for the sorts of people Carl is dealing with --\n> those who merely want to look around.\n\nI disagree again. Making commits on a detached head is not dangerous.\n\nWhat is dangerous is moving away from the tip of that detached head \nwithout attaching it somewhere. And that case is well covered already.\n\nAlso the warning when moving to a detached head is useful to make the \nuser aware of what just happened because there is really something \nspecial about such checkout. It is not meant to frighten users and if \nit does so then maybe it should be reworked some more. But IMHO it is \nimportant that the user be aware of this special state.\n\nBut making a warning at commit time is wrong. It is completely \ndisconnected from the actual issue and I think it'd create more \nconfusion because there is in fact nothing to worry about at the moment \nthe commit is made. The very fact that you think yourself that a \nwarning should be displayed at commit time indicates to me that you \nmight be a bit confused yourself and such warning if present at commit \ntime wouldn't help clearing that confusion at all.\n\n> > For situations like Carl's intstruction where a user, who is\n> > purely a sightseer, uses the detached HEAD to go-and-look a\n> > particular state, the fact that \"-f\" loses the previous local\n> \n> Yes, though it would be nicer not to have to explain to them why '-f' is\n> needed.\n\nIn Carl's case suggesting -f is probably not a good idea. Using -f _is_ \ndangerous and we better not get people into the habit of using -f \nwithout thinking.\n\nLet's focus on the real issue: the warning message when head gets \ndetached. This message is not meant to frighten users. It is meant to \nmake the user aware of a special state (pretty useful but special \nnevertheless) and give a suggestion about what to do if that state was \nentered by mistake. So if that message scares users away then it is the \nmessage itself which is buggy not its presence.\n\n\nNicolas\n"},{"id":"33138","messageId":"Pine.LNX.4.64.0701311007550.3021@xanadu.home","threadId":"6587","inReplyTo":"epqaej$nug$1@sea.gmane.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T15:15:32Z","receivedAt":"2007-01-31T15:15:32Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 31 Jan 2007, Jakub Narebski wrote:\n\n> I'd like to have some configuration option to make git more careful\n> and prohibit commiting in detached HEAD state (the default being that\n> you can commit on top of detached HEAD). More secure but less powerfull.\n\nAnd what is the purpose of such an artificial annoyance that no one will \nturn on on purpose?\n\nYou have to _realize_ that there is nothing wrong with such commits. \nMerely having a config option to prohibit them not only is senseless \ntechnically but it also send the wrong message to users.\n\n> > By the same argument, the original checkout of a non-branch is also not\n> > the place for a warning; by the time you commit and then do a checkout\n> > to switch away from the new commit, that original checkout may be a\n> > distant memory.\n> \n> But the initial checkout of a non-branch is place where we can notify\n> user that he does something unexpected / unusual. Though I think that\n> single-line warning would be enough...\n\nThere is a balance problem there. Too large a message might be annoying \nbut a too short one might not convey enough information not to be yet \nmore confusing.\n\n\nNicolas\n"},{"id":"33146","messageId":"87k5z3npsz.wl%cworth@cworth.org","threadId":"6587","inReplyTo":"8b65902a0701310513s1f8bfa04o7e1c7e43b7453ac8@mail.gmail.com","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-31T16:06:52Z","receivedAt":"2007-01-31T16:06:52Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 31 Jan 2007 14:13:42 +0100, \"Guilhem Bonnefille\" wrote:\n> If the user is not a developer and only interested in testing, what\n> about a simple snapshot tarball?\n> So, you prepare the fix and then you pack everything in a\n> myapp-timestamp.tar.gz and send this tarball to the user.\n\nThat's bad for all the same reasons we don't send tarballs around to\neach other.\n\nBut here are several concrete points:\n\n1. I want to be able to easily publicize a new branch with\n instructions that anyone can use, (regardless of git experience).\n\n2. I've got the stuff available in a git branch already, and I don't\n want to do any more work.\n\n3. I want the exchange to be as efficient as possible, (I might send\n multiple fixes in series to the user and it'd be really nice to\n take advantage of git's efficiency here).\n\n4. I don't want to condemn the user to never being able to learn\n git. If I make this easy for the user then I get a nice lead-in to\n teach the user new things, (which is good for me since it helps me\n if the user starts sending me git commits rather than random\n patches without commit messages connected to who-knows-what\n tar-file version of the software, etc.)\n\netc. etc.\n\n-Carl\n\nPS. All that being said, our project does publish periodic tar-file\nsnapshots. But that's really for a different situation: specifically,\nfor people with whom I'm not already engaged in any conversation at\nall.\n"},{"id":"33148","messageId":"Pine.LNX.4.63.0701311708470.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"6587","inReplyTo":"87k5z3npsz.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-01-31T16:15:33Z","receivedAt":"2007-01-31T16:15:33Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 31 Jan 2007, Carl Worth wrote:\n\n> On Wed, 31 Jan 2007 14:13:42 +0100, \"Guilhem Bonnefille\" wrote:\n> > If the user is not a developer and only interested in testing, what\n> > about a simple snapshot tarball?\n> > So, you prepare the fix and then you pack everything in a\n> > myapp-timestamp.tar.gz and send this tarball to the user.\n> \n> That's bad for all the same reasons we don't send tarballs around to \n> each other.\n\nWell, that's not completely fair. Guilhem has a point here.\n\n> 1. I want to be able to easily publicize a new branch with\n> instructions that anyone can use, (regardless of git experience).\n\nHow about gitweb, with a snapshot link? It's as easy as it gets. Even \nthose Windows idio^H^H^H^Husers can unpack tar.gz files by now, and you \nsend them just a link. They can even see what was fixed, and when, if they \ncare enough.\n \n> > 2. I've got the stuff available in a git branch already, and I don't\n> want to do any more work.\n\nThat is one of the lousiest excuses in this world. Unfortunately, I hear \nit very, very often. (I mean the second sentence.)\n\n> 3. I want the exchange to be as efficient as possible, (I might send\n> multiple fixes in series to the user and it'd be really nice to\n> take advantage of git's efficiency here).\n\nThere's two kinds of efficient here. Efficient in the sense of network \ntraffic, or in the sense of time spent talking back and forth, until the \npackage is finally tested.\n\nIf the efficiency you are thriving for is network traffic, go a head, make \nthe user use git.\n\nHowever, if it is the other efficiency you want to achieve, stay away from \ngit. Chances are that your user will never appreciate what git can to for \nher, and just wants to test the darned package, and be done with it, \nthank you very much.\n\n> 4. I don't want to condemn the user to never being able to learn\n> git. If I make this easy for the user then I get a nice lead-in to\n> teach the user new things, (which is good for me since it helps me\n> if the user starts sending me git commits rather than random\n> patches without commit messages connected to who-knows-what\n> tar-file version of the software, etc.)\n\nThat's nice of you. But it might just be that you royally p*ss the \ncustomer off, because he does not have time for that game.\n\nCiao,\nDscho\n"},{"id":"33151","messageId":"Pine.LNX.4.64.0701311102300.20138@iabervon.org","threadId":"6587","inReplyTo":"Pine.LNX.4.64.0701310923010.3021@xanadu.home","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2007-01-31T16:25:46Z","receivedAt":"2007-01-31T16:25:46Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 31 Jan 2007, Nicolas Pitre wrote:\n\n> On Wed, 31 Jan 2007, Daniel Barkalow wrote:\n> \n> > On Tue, 30 Jan 2007, Nicolas Pitre wrote:\n> > \n> > > On Tue, 30 Jan 2007, Daniel Barkalow wrote:\n> > > \n> > > > warning: you are now browsing the history without a local branch. You \n> > > > will not be able to commit changes unless you create a new local branch \n> > > > with \"git checkout -b \".\n> > > \n> > > This isn't true. You can commit on top of a detached head. In fact you \n> > > can do almost anything.\n> > \n> > \"Commits you make will not be attached to permanent state unless you \n> > create a local branch\"? I'm not sure how the feature turned out to work, \n> > but I know that (a) you're fine if you don't make any commits and (b) the \n> > behavior is more like what happens with anonymous checkouts of other \n> > people's repositories in non-distributed SCMs, so people will tend to\n> > underestimate what they can do with this, rather than overestimating it \n> > and getting into trouble.\n> > \n> > I suppose it's reasonable to warn at commit time, if we ended up going \n> > with allowing commits like normal.\n> \n> I disagree.\n> \n> It is not the commit which is dangerous when the head is detached. It \n> is the checkout of another branch. And this case is covered already \n> such that the checkout is refused unless you actually create a branch \n> for your detached head or you give -f to checkout to override the \n> protection.\n> \n> Giving a warning at commit time is not the place where the user has to \n> be aware of the issue since it is indeed not the place where there is \n> any issue to worry about.\n\nAt commit time, the user is reasonably likely to be doing something \nunintended (at least, it's more likely that the user is doing something \nunintended by committing with a detatched head than that the user is doing \nsomething unintended by detatching the head). Certainly the only time \nthere's any danger of losing work is when the head is detatched and a \ncommit has been made since it was set, because otherwise there's either no \nwork to lose, or no commits could be becoming unreachable.\n\nI suspect that there will be people from other SCMs who will assume \nthey're back on a local branch if the system lets them commit, because \nthey would be prohibited from committing on top of an anonymous checkout \nor a historical commit. Of course, they can cherry-pick the misplaced \ncommit, so it's not a big deal, but I think it's where a naive user would \nbe getting into a state they don't understand.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"33160","messageId":"20070131170752.GA19527@coredump.intra.peff.net","threadId":"6587","inReplyTo":"Pine.LNX.4.64.0701310932320.3021@xanadu.home","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-31T17:07:52Z","receivedAt":"2007-01-31T17:07:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 31, 2007 at 09:59:08AM -0500, Nicolas Pitre wrote:\n\n> I disagree again. Making commits on a detached head is not dangerous.\n> \n> What is dangerous is moving away from the tip of that detached head \n> without attaching it somewhere. And that case is well covered already.\n\nSure, the dangerous thing is moving away. But my point is there are many\nsteps leading up to that, and we can warn at any one. However, the\nwarning is _most_ useful as close to the dangerous thing as possible\n(ideally, we would warn when doing the actual dangerous thing, but IIRC,\nthere was some complexity with that).\n\nIOW, here's a rough flow chart of states and user actions:\n checkout non-branch commit, etc\n(1) regular ---------> (2) detached, --------> (3) detached,\n ^ no commits commits\n | checkout branch | checkout old branch /\\\n \\-----------------<-------------------------- |\n | checkout\n | new branch\n v\n (4) new regular branch\n\nHopefully my ASCII art skillz are coherent enough. The actual\n\"dangerous\" thing here is moving from 3 to 1. We can theoretically warn\nat any transition. Right now we warn moving from 1 to 2. But a large\nnumber of users are just going to go right back to 1, never even doing\nanything dangerous! For them, the warning is confusing. I'm proposing\nwarning between 2 and 3. I would also be happy with warning (and\nprobably blocking without -f) moving from 3 to 1, which is the actual\ndangerous thing. However, I think putting a warning between 2 and 3 is\nreasonable, because the next step the user will make from 3 is either\nmoving to 1 (dangerous) or to 4 (ok), and they must use the correct\ngit-checkout invocation. So basically, it's our last chance (besides the\nactual git-checkout itself) to warn them.\n\n> Also the warning when moving to a detached head is useful to make the \n> user aware of what just happened because there is really something \n> special about such checkout. It is not meant to frighten users and if \n> it does so then maybe it should be reworked some more. But IMHO it is \n> important that the user be aware of this special state.\n\nWhat is so special about it? My argument is that it is not really very\nspecial _until you make commits_. Are there other operations which we\nshould be warning people about if they have a detached head?\n\n> But making a warning at commit time is wrong. It is completely \n> disconnected from the actual issue and I think it'd create more \n> confusion because there is in fact nothing to worry about at the moment \n> the commit is made. The very fact that you think yourself that a \n> warning should be displayed at commit time indicates to me that you \n> might be a bit confused yourself and such warning if present at commit \n> time wouldn't help clearing that confusion at all.\n\nI think you are proving my point here. If you think warning at commit\ntime is too early, then how is warning _before_ that (when we detach)\nnot too early?\n\n> In Carl's case suggesting -f is probably not a good idea. Using -f _is_ \n> dangerous and we better not get people into the habit of using -f \n> without thinking.\n\nAgreed.\n\n> Let's focus on the real issue: the warning message when head gets \n> detached. This message is not meant to frighten users. It is meant to \n> make the user aware of a special state (pretty useful but special \n> nevertheless) and give a suggestion about what to do if that state was \n> entered by mistake. So if that message scares users away then it is the \n> message itself which is buggy not its presence.\n\nAgain, I don't understand why the state is special (aside from the\npossibility of losing commits).\n\n-Peff\n"},{"id":"33164","messageId":"Pine.LNX.4.64.0701311247510.3021@xanadu.home","threadId":"6587","inReplyTo":"Pine.LNX.4.64.0701311102300.20138@iabervon.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T18:25:20Z","receivedAt":"2007-01-31T18:25:20Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 31 Jan 2007, Daniel Barkalow wrote:\n\n> On Wed, 31 Jan 2007, Nicolas Pitre wrote:\n> \n> > Giving a warning at commit time is not the place where the user has to \n> > be aware of the issue since it is indeed not the place where there is \n> > any issue to worry about.\n> \n> At commit time, the user is reasonably likely to be doing something \n> unintended (at least, it's more likely that the user is doing something \n> unintended by committing with a detatched head than that the user is doing \n> something unintended by detatching the head). Certainly the only time \n> there's any danger of losing work is when the head is detatched and a \n> commit has been made since it was set, because otherwise there's either no \n> work to lose, or no commits could be becoming unreachable.\n\nThere is protection against losing a commit made on top of a detached \nhead already. And when reflog of detached head can be completed then \nthere won't be any ways to lose them regardless. Preventing or making \nit difficult or annoying to commit on top of a detached head 1) makes no \ntechnical sense and 2) doesn't address the real issue.\n\n> I suspect that there will be people from other SCMs who will assume \n> they're back on a local branch if the system lets them commit, because \n> they would be prohibited from committing on top of an anonymous checkout \n> or a historical commit.\n\nI don't follow you here.\n\nWhy would you be prevented from performing a commit on top of an \nhistorical commit? That is the whole point of a detached head: making \nthings to a checkout that usually should remain read-only. This is why \nyou can fetch and merge tracking branches, diff against taged commits or \ntracking branches, etc. But if you _checkout_ a read-only branch/tag \nthen either we checkout every file read-only to inforce that face and \npiss off users, or let them do as much as they wish _including_ commits \nbut have a safety gate for the only operation that could otherwise \nactualy lose work.\n\nAnd since the commit template already mention \"Not currently on any \nbranch\" I think the user is reminded already that she's still not on a \nlocal branch.\n\n> Of course, they can cherry-pick the misplaced \n> commit, so it's not a big deal, but I think it's where a naive user would \n> be getting into a state they don't understand.\n\nThat's why the warning when detaching head is important:\n\n|warning: you are not on ANY branch anymore.\n|If you meant to create a new branch from this checkout, you may still do\n|so (now or later) by using -b with the checkout command again. Example:\n| git checkout -b \n\nThe \"now or later\" is there exactly to tone down the warning. And \nactually we could do s/warning/note\" to make it even less frightening. \n\nBut I think it is important to tell the user up front about that fact. \nThen, when the user tries to commit and sees \"Not currently on any \nbranch\" then she'll go \"oh sure it told me so before\" and maybe even \n\"that's so cool I can perform commits even in this case!\". But if the \nuser sees that \"Not currently on any branch\" line without having been \nnotified at the moment it happened then she'll only think \"WTF did I do \nto get here\".\n\nBut if a user did work, even unexpectedly, on top of a detached head \nthen the worst thing you can trow at her face is :\"sorry, you cannot \ncommit your work here\" or \"committing on a detached head risk losing \nyour work\" because those are technically untrue and really unfriendly.\n\nWhen it is really possible to lose change unexpectedly is when \nperforming another checkout. And currently you simply won't be able to \ndo it. You'll get this instead:\n\n|You are not on any branch and switching to branch 'master'\n|may lose your changes. At this point, you can do one of two things:\n| (1) Decide it is Ok and say 'git checkout -f master';\n| (2) Start a new branch from the current commit, by saying\n| 'git checkout -b '.\n|Leaving your HEAD detached; not switching to branch 'master'.\n\nThere is no way the user might still be confused here. Any commit time \nwarning is useless and redundent when you have this message when it \nreally matters.\n\nThis is flexibility and safety together and I think this is really \npowerful.\n\n\nNicolas\n"},{"id":"33165","messageId":"Pine.LNX.4.64.0701311335150.3021@xanadu.home","threadId":"6587","inReplyTo":"20070131170752.GA19527@coredump.intra.peff.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-01-31T18:59:37Z","receivedAt":"2007-01-31T18:59:37Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 31 Jan 2007, Jeff King wrote:\n\n> On Wed, Jan 31, 2007 at 09:59:08AM -0500, Nicolas Pitre wrote:\n> \n> > I disagree again. Making commits on a detached head is not dangerous.\n> > \n> > What is dangerous is moving away from the tip of that detached head \n> > without attaching it somewhere. And that case is well covered already.\n> \n> Sure, the dangerous thing is moving away. But my point is there are many\n> steps leading up to that, and we can warn at any one. However, the\n> warning is _most_ useful as close to the dangerous thing as possible\n> (ideally, we would warn when doing the actual dangerous thing, but IIRC,\n> there was some complexity with that).\n\nThe _only_ dangerous thing is moving away. Warning at any step is far \nmore annoying than warning (actually only notifying) only once when the \ndetached head state is entered.\n\n> IOW, here's a rough flow chart of states and user actions:\n> checkout non-branch commit, etc\n> (1) regular ---------> (2) detached, --------> (3) detached,\n> ^ no commits commits\n> | checkout branch | checkout old branch /\\\n> \\-----------------<-------------------------- |\n> | checkout\n> | new branch\n> v\n> (4) new regular branch\n> \n> Hopefully my ASCII art skillz are coherent enough. The actual\n> \"dangerous\" thing here is moving from 3 to 1. We can theoretically warn\n> at any transition. Right now we warn moving from 1 to 2. But a large\n> number of users are just going to go right back to 1, never even doing\n> anything dangerous! For them, the warning is confusing.\n\nLet's fix the warning then. But it must stay just because it is \nimportant that the user know _why_ and _when_ the head became detached. \nRealizing that head is detached later is far more confusing if the user \njust don't know how that happened.\n\n> I'm proposing warning between 2 and 3.\n\nGiven that the commit template already says that the head is detached is \nIMHO far enough given the actual \"dangerousness\" of the operation.\n\n> I would also be happy with warning (and\n> probably blocking without -f) moving from 3 to 1, which is the actual\n> dangerous thing.\n\nAnd that is already what is happening.\n\n> However, I think putting a warning between 2 and 3 is\n> reasonable, because the next step the user will make from 3 is either\n> moving to 1 (dangerous) or to 4 (ok), and they must use the correct\n> git-checkout invocation. So basically, it's our last chance (besides the\n> actual git-checkout itself) to warn them.\n\nNo it is not. The user cannot escape the detached head state (moving \nfrom 3 to 1) without -f or creating a new branch already. Additional \nwarning between (2) and (3) does nothing but add annoyance to the user \nexperience.\n\n> > Also the warning when moving to a detached head is useful to make the \n> > user aware of what just happened because there is really something \n> > special about such checkout. It is not meant to frighten users and if \n> > it does so then maybe it should be reworked some more. But IMHO it is \n> > important that the user be aware of this special state.\n> \n> What is so special about it? My argument is that it is not really very\n> special _until you make commits_. Are there other operations which we\n> should be warning people about if they have a detached head?\n\nIt is a different state and the user must know why. When doing a commit \nit is too late to say \"oh btw your head was detached a while ago\".\n\n> > But making a warning at commit time is wrong. It is completely \n> > disconnected from the actual issue and I think it'd create more \n> > confusion because there is in fact nothing to worry about at the moment \n> > the commit is made. The very fact that you think yourself that a \n> > warning should be displayed at commit time indicates to me that you \n> > might be a bit confused yourself and such warning if present at commit \n> > time wouldn't help clearing that confusion at all.\n> \n> I think you are proving my point here. If you think warning at commit\n> time is too early, then how is warning _before_ that (when we detach)\n> not too early?\n\nDid I say anything about it being too early?\n\nI say that it is unnecessary and redundent, and that it would create \nmore confusion than it clears.\n\n> > In Carl's case suggesting -f is probably not a good idea. Using -f _is_ \n> > dangerous and we better not get people into the habit of using -f \n> > without thinking.\n> \n> Agreed.\n> \n> > Let's focus on the real issue: the warning message when head gets \n> > detached. This message is not meant to frighten users. It is meant to \n> > make the user aware of a special state (pretty useful but special \n> > nevertheless) and give a suggestion about what to do if that state was \n> > entered by mistake. So if that message scares users away then it is the \n> > message itself which is buggy not its presence.\n> \n> Again, I don't understand why the state is special (aside from the\n> possibility of losing commits).\n\nIt is special because it has an entry point and an exit point, unlike \nbeing on any branch where there is no such notion. So it is important \nto know when/how you enters it and how you may leave it. Intermediate \noperations don't have to be special with useless warnings.\n\n\nNicolas\n"},{"id":"33167","messageId":"8aa486160701311127v686929c8vb9b5771031776ed8@mail.gmail.com","threadId":"6587","inReplyTo":"87odognuhl.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-01-31T19:27:52Z","receivedAt":"2007-01-31T19:27:52Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 1/30/07, Carl Worth wrote:\n> So here's a scenario I'm in right now. A user of my software reported a\n> bug. I put together some patches to fix the bug and pushed them out as\n> a new branch \"proposed-fix\" that I'd like the user to test.\n\nActually it is the same \"problem\" as when you want to work on the\nnon-HEAD remote branch.\n\nCurrently I do (with current git):\n\ngit clone git://...\ngit checkout -b ${branch} origin/${branch}\ngit config branch.${branch}.merge refs/heads/${branch}\n\nthen they could update this with just:\n\ngit pull\n\nIt would be nice if:\n\ngit clone -b ${branch} git://...\n\nwould be equivalent of the above three commands.\n\nSanti\n"},{"id":"33168","messageId":"871wlbascq.wl%cworth@cworth.org","threadId":"6587","inReplyTo":"8aa486160701311127v686929c8vb9b5771031776ed8@mail.gmail.com","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-01-31T19:50:13Z","receivedAt":"2007-01-31T19:50:13Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Wed, 31 Jan 2007 20:27:52 +0100, \"=?ISO-8859-1?Q?Santi_B=E9jar?=\" wrote:\n> Actually it is the same \"problem\" as when you want to work on the\n> non-HEAD remote branch.\n\nYes, exactly.\n\n> It would be nice if:\n>\n> git clone -b ${branch} git://...\n>\n> would be equivalent of the above three commands.\n\nYes, something like that would be extremely helpful!\n\nIn addition, it would be great to have a command that did the same\nsetup within an existing repository.\n\nAnd I would be most happy if the two commands for these two use cases\nshared as much syntax as possible, so I could publish one string and\nusers could cut-and-paste it to either command as appropriate.\n\nOne string I would have liked would have been \"git://... ${branch}\",\nbut existing git-clone and git-fetch command syntax is not too\namenable for that, (git-clone interprets an argument after the URL as\nthe name of the local directory to create while git-fetch interprets\nthe argument after the URL as a refspec).\n\n-Carl\n"},{"id":"33172","messageId":"7vhcu7uewe.fsf@assigned-by-dhcp.cox.net","threadId":"6587","inReplyTo":"20070131170752.GA19527@coredump.intra.peff.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-31T20:20:33Z","receivedAt":"2007-01-31T20:20:33Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Wed, Jan 31, 2007 at 09:59:08AM -0500, Nicolas Pitre wrote:\n>\n>> Also the warning when moving to a detached head is useful to make the \n>> user aware of what just happened because there is really something \n>> special about such checkout. It is not meant to frighten users and if \n>> it does so then maybe it should be reworked some more. But IMHO it is \n>> important that the user be aware of this special state.\n>\n> What is so special about it? My argument is that it is not really very\n> special _until you make commits_. Are there other operations which we\n> should be warning people about if they have a detached head?\n\nI think you (and others in the thread) are forgetting that\nmoving to a particular state by resetting can create a state\nthat you may want to keep a pointer to, but you do not have any\nexisting ref. That's one of the reasons why we do not merely\ncheck if the detached HEAD is not reachable from any of the\nexisting refs when coming back. Instead, we check and warn if\nthe detached HEAD does not exactly match one of the existing\nrefs.\n\nImagine \"git bisect\" did not exist, or was not powerful enough,\nand the user was doing it by hand using something other than\n\"git bisect\" to guide him which state to go next, or the user\ndid not want to use the special \"bisect\" branch, or some\ncombination of the above. You move your detached HEAD around\nand finally you are at the commit you are interested in. You\nhaven't marked it in some way (perhaps \"git tag\") yet. You\nhaven't made any commit, and the commit is reachable in some\nway, but all the work to reach that state will be lost unless\nyou jot its commit object name down somewhere.\n\nSo \"until you make commits\" is not sufficient, which means that\ncovering all the way you can make commits isn't, either.\n"},{"id":"33182","messageId":"20070131225121.GC20514@thunk.org","threadId":"6587","inReplyTo":"7vhcu7uewe.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Theodore Tso","fromEmail":"tytso@mit.edu","sentAt":"2007-01-31T22:51:21Z","receivedAt":"2007-01-31T22:51:21Z","isPatch":false,"sender":{"key":"tytso@mit.edu","avatar":"https://avatars.githubusercontent.com/u/51416?v=4"},"body":"On Wed, Jan 31, 2007 at 12:20:33PM -0800, Junio C Hamano wrote:\n> I think you (and others in the thread) are forgetting that\n> moving to a particular state by resetting can create a state\n> that you may want to keep a pointer to, but you do not have any\n> existing ref. That's one of the reasons why we do not merely\n> check if the detached HEAD is not reachable from any of the\n> existing refs when coming back. Instead, we check and warn if\n> the detached HEAD does not exactly match one of the existing\n> refs.\n\nIs that an important distinction? The way the user got there was by\nmanually specifying the SHA-1 shash of the commit to git-checkout. So\nif the user could get there once, the user could get there again a\nsecond time. Just because we don't have a name to that precise commit\ninside the git system doesn't necessary mean the user can't get back\nthere. In fact, the user probably could via \"history | grep 'git checkout'\".\n\n> So \"until you make commits\" is not sufficient, which means that\n> covering all the way you can make commits isn't, either.\n\nMy personal belief is that covering all the way you can make commits\nis where you want to be putting the check. If I say something like\n\ngit checkout f00b51b8\n\nThere's nothing dangerous about that statement. To argue that this is\ndangerous and the git needs to warn me because I might not be able to\nget back to it seems silly. Of _course_ I can get back there; the\nsame way I got here in the first place --- By simply saying, \"git\ncheckout f00b51b8\" again!\n\nAnd if I tell a user that they should try out a particular version of\nthe code, issueing a scary message right then there is pointless if\nthey are only going to be doing a read-only browse of the tree, is\njust a Bad Thing. The best place to warn them really is when they\nmodify the tree.\n\nOtherwise, we'll be educating users to use the -f flag, or telling\nusers to \"ignore the warning, git's being silly\", neither of which is\ndesirable.\n\n\t\t\t\t\t\t- Ted\n"},{"id":"33183","messageId":"20070131225352.GA31145@coredump.intra.peff.net","threadId":"6587","inReplyTo":"Pine.LNX.4.64.0701311335150.3021@xanadu.home","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-01-31T22:53:52Z","receivedAt":"2007-01-31T22:53:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Jan 31, 2007 at 01:59:37PM -0500, Nicolas Pitre wrote:\n\n> > I would also be happy with warning (and\n> > probably blocking without -f) moving from 3 to 1, which is the actual\n> > dangerous thing.\n> And that is already what is happening.\n\nDoh! I'm a complete moron. Sorry, but I thought we were _not_ warning\nthere in favor of the warning at time of detachment. I even did a test,\nbut I botched it.\n\nSo please, accept my apology and assume I have hit myself over the head\nwith the clue stick several times. Warning at commit time _is_ stupid,\nsince we can complain at the correct time.\n\n> Let's fix the warning then. But it must stay just because it is \n> important that the user know _why_ and _when_ the head became detached. \n> Realizing that head is detached later is far more confusing if the user \n> just don't know how that happened.\n\nOK, I completely see your point now; it doesn't have to be a _warning_\nper se, but rather to let the user know this is when the state changed\n(so that later if they do get a warning, it makes more sense).\n\n> > > But making a warning at commit time is wrong. It is completely \n> > > disconnected from the actual issue and I think it'd create more \n> > > confusion because there is in fact nothing to worry about at the moment \n> > > the commit is made. The very fact that you think yourself that a \n> > > warning should be displayed at commit time indicates to me that you \n> > > might be a bit confused yourself and such warning if present at commit \n> > > time wouldn't help clearing that confusion at all.\n> > \n> > I think you are proving my point here. If you think warning at commit\n> > time is too early, then how is warning _before_ that (when we detach)\n> > not too early?\n> \n> Did I say anything about it being too early?\n> \n> I say that it is unnecessary and redundent, and that it would create \n> more confusion than it clears.\n\nYou said \"...there is in fact nothing to worry about at the moment the\ncommit is made.\" My point is that there is in fact nothing to worry\nabout at the moment that you detach, thus why should one get a warning\nand not the other. But I agree that if you want the later warning to\nmake sense, it might be helpful to note that point (and I think it's\ngetting too fancy to tuck away that information and have the actual\nwarning say \"When you moved your HEAD to foo~32, you were no longer on a\nbranch, therefore...\")\n\nSo IOW, I think I agree with you now. :)\n\nAgain, sorry for the (my) confusion.\n\n-Peff\n"},{"id":"33184","messageId":"7v1wlau7d8.fsf@assigned-by-dhcp.cox.net","threadId":"6587","inReplyTo":"20070131225121.GC20514@thunk.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-01-31T23:03:15Z","receivedAt":"2007-01-31T23:03:15Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Theodore Tso writes:\n\n> ... Just because we don't have a name to that precise commit\n> inside the git system doesn't necessary mean the user can't get back\n> there.\n> In fact, the user probably could via \"history | grep 'git checkout'\".\n\nIf you mean grep 'git checkout|git reset' perhaps. After\nchecking out a specific commit (because the user was told about\nthe commit out-of-band, say, via e-mail), the user can still\nvisit other commits with e.g. \"git reset --hard HEAD~20\".\n\n>> So \"until you make commits\" is not sufficient, which means that\n>> covering all the way you can make commits isn't, either.\n>\n> My personal belief is that covering all the way you can make commits\n> is where you want to be putting the check. If I say something like\n>\n> git checkout f00b51b8\n>\n> There's nothing dangerous about that statement.\n\nI do not think anybody is arguing that particular checkout is\ndangerous. The warning message is about the fact that your HEAD\nis now detached, which might not have been what you intended\n(and you will later get a real warning when you do a really\ndangerous thing, which is \"to come back and lose your point\").\n"},{"id":"33185","messageId":"epr81s$gaf$1@sea.gmane.org","threadId":"6587","inReplyTo":"20070131225121.GC20514@thunk.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-01-31T23:18:39Z","receivedAt":"2007-01-31T23:18:39Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Theodore Tso wrote:\n> On Wed, Jan 31, 2007 at 12:20:33PM -0800, Junio C Hamano wrote:\n\n>> I think you (and others in the thread) are forgetting that\n>> moving to a particular state by resetting can create a state\n>> that you may want to keep a pointer to, but you do not have any\n>> existing ref. That's one of the reasons why we do not merely\n>> check if the detached HEAD is not reachable from any of the\n>> existing refs when coming back. Instead, we check and warn if\n>> the detached HEAD does not exactly match one of the existing\n>> refs.\n> \n> Is that an important distinction? The way the user got there was by\n> manually specifying the SHA-1 shash of the commit to git-checkout. So\n> if the user could get there once, the user could get there again a\n> second time. Just because we don't have a name to that precise commit\n> inside the git system doesn't necessary mean the user can't get back\n> there. In fact, the user probably could via \"history | grep 'git\n> checkout'\". \n\nHave you read further? git-bisect could (and probably should) use detached\nHEAD instead of special 'bisect' branch. Doing bisection can be hard work\n(checking if commit is good or bad might take time) and we don't want to\nlose it.\n\nBesides, history has finite length, and you could get to the state not only\nvia \"git checkout\", but also via \"git reset --hard\".\n\nReflog for detached HEAD would help in this.\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33195","messageId":"200702010120.58806.Josef.Weidendorfer@gmx.de","threadId":"6587","inReplyTo":"871wlbascq.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Josef Weidendorfer","fromEmail":"josef.weidendorfer@gmx.de","sentAt":"2007-02-01T00:20:58Z","receivedAt":"2007-02-01T00:20:58Z","isPatch":false,"sender":{"key":"josef.weidendorfer@gmx.de","avatar":null},"body":"On Wednesday 31 January 2007, Carl Worth wrote:\n> > It would be nice if:\n> >\n> > git clone -b ${branch} git://...\n\nNice indeed.\n\nAdditionally, it would be nice for clone to directly\ncheckout tags. Why not an option \"--checkout \"\nto directly checkout after cloning?\n\nThis goes nicely with the \"-b\" option\nto create a new branch. A \"-b \" option alone would\nimply \"--checkout origin/\". And without \"--checkout\"\nor \"-b\" option it defaults to \"-b master\" which gives\nexactly the same behavior as now.\n\nThis way,\n\n git clone --checkout v1.0 git://...\n\nwould checkout tag v1.0, and use a detached head for it.\n\n> In addition, it would be great to have a command that did the same\n> setup within an existing repository.\n\nWhy not use \"git clone\" for this?\nCurrently, the man page says about the directory it will clone into:\n\n \"Cloning into an existing directory is not allowed.\"\n\nBut we could relax this: if the specified directory is the root of\na checkout (ie. with a .git subdir), we would clone a remote repository\ninto the same local repository. However, this should not default\nto \"-b master\", ie. not switch the current branch. Additionally, the\nremote name should not default to \"origin\", but to the \n\"humanish\" part of the source repository. IMHO we should have done\nthe latter since long time ago, as a remote \"origin\" is not really\nuseful once you work with branches from multiple remote repositories.\n\nDoing this,\n\n git clone git://... \n\nwould be the equivalent of\n\n mkdir \n cd \n git init\n git clone -b master git://... .\n\nwhich IMHO would make a lot of sense.\n \n> And I would be most happy if the two commands for these two use cases\n> shared as much syntax as possible, so I could publish one string and\n> users could cut-and-paste it to either command as appropriate.\n\nYou would say:\n\n\"To get version , do a\n\n git clone --checkout git://...\n\nIf you already have a local clone of the repository, append the\ndirectory of your local repository as target to clone this version\ninto\".\n\n\n> One string I would have liked would have been \"git://... ${branch}\"\n\nIMHO \"-b\" option is better as it tells you that it creates a new\nlocal development branch for you.\n\nJosef\n\n> but existing git-clone and git-fetch command syntax is not too\n> amenable for that, (git-clone interprets an argument after the URL as\n> the name of the local directory to create while git-fetch interprets\n> the argument after the URL as a refspec).\n> \n> -Carl\n> \n"},{"id":"33208","messageId":"eprp82$snm$1@sea.gmane.org","threadId":"6587","inReplyTo":"87odognuhl.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-01T04:12:06Z","receivedAt":"2007-02-01T04:12:06Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n[cut]\n\nBy the way, you can get new layout with old git using --use-separate-remote\noption to git clone (which is present I think from around Jun 2006).\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"33214","messageId":"8aa486160702010102q3a49c4cfle44379a5f0b5422d@mail.gmail.com","threadId":"6587","inReplyTo":"200702010120.58806.Josef.Weidendorfer@gmx.de","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Santi Béjar","fromEmail":"sbejar@gmail.com","sentAt":"2007-02-01T09:02:44Z","receivedAt":"2007-02-01T09:02:44Z","isPatch":false,"sender":{"key":"santi@agolina.net","avatar":null},"body":"On 2/1/07, Josef Weidendorfer wrote:\n> On Wednesday 31 January 2007, Carl Worth wrote:\n> > > It would be nice if:\n> > >\n> > > git clone -b ${branch} git://...\n>\n> Nice indeed.\n>\n> Additionally, it would be nice for clone to directly\n> checkout tags. Why not an option \"--checkout \"\n> to directly checkout after cloning?\n\nMaybe, I'm not sure.\n\n> > In addition, it would be great to have a command that did the same\n> > setup within an existing repository.\n>\n> Why not use \"git clone\" for this?\n> Currently, the man page says about the directory it will clone into:\n>\n> \"Cloning into an existing directory is not allowed.\"\n>\n> But we could relax this: if the specified directory is the root of\n> a checkout (ie. with a .git subdir), we would clone a remote repository\n> into the same local repository.\n\nYou can do it with git-remote. I think it is sensible to have a\ncommand to get a new repository and a command to have a new remote.\n\nFor the \"work on the non-HEAD branch\" I think we could have:\n\n# clone a remote repository and start working with branch ${branch}\n$ git clone -b ${branch} ${url}\n\n# add a new branch based on a remote branch,\n# and configure to pull from there.\n$ git branch ${branch} ${remote_branch}\n$ git checkout -b ${branch} ${remote_branch}\n\nas you see it is the current syntax, so I suggest to automatically\nsetup the branch.${branch}.{remote,merge} configs to follow the\n${remote_branch} if this is sensible. So for example\n\n$ git clone ${url_of_git.git}\n$ cd git\n$ git checkout -b maint origin/maint\n$ git-config -l | grep ^branch.maint\nbranch.master.remote=origin\nbranch.master.merge=refs/heads/maint\n\n( or branch.master.merge=refs/remotes/origin/maint )\n\nThis changes the current behaviour, but I think it make sense. If this\nis not possible another way would be to have another option (-r for\nremote, or -f for follow, or -p for pull, or -m for merge, ...) as:\n\n$ git branch ${branch} -r ${remote_branch}\n$ git checkout -b ${branch} -r ${remote_branch}\n\nAnd if you want to add/change the remote/merge config for an existing\nbranch, in addition to doing this with git-config, git-remote could do\nit as it currently shows the tracking branches.\n\nSanti\n"},{"id":"33691","messageId":"87y7nbdeaw.wl%cworth@cworth.org","threadId":"6587","inReplyTo":"87odognuhl.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-02-06T05:51:19Z","receivedAt":"2007-02-06T05:51:19Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 30 Jan 2007 12:13:26 -0800, Carl Worth wrote:\n> I'm finding that the instructions I'm having to write are much more\n> complicated than I would like them to be. And some of this is due to\n> incompatibility between git 1.5 and previous versions.\n\nWhen I first brought up this thread we had lots of good discussion\nabout detached head that led to improved (or eliminated) warning\nmessages, and some good motivation for HEAD reflog.\n\nMeanwhile, there's still a piece of the original problem that was not\naddressed:\n\n> \t\tgit checkout -b build origin/proposed-fix\n>\n> I really like most of what separate-remotes does. But I don't like\n> that branch names no longer resolve the same way they used to. Could\n> we fix git to resolve \"branch\" as \"remotes/*/branch\" if unique? That\n> would allow the old instructions and old habits to continue to work,\n> (making the change to separate-remotes much more compatible).\n\nIs there any feedback on the above? I just ran into this problem again\ntonight, giving out instructions of \"git checkout -b build\nproposed-fix\" and then bracing myself to have the user complain about\nan error of:\n\n\tgit checkout: updating paths is incompatible with switching branches/forcing\n\tDid you intend to checkout 'proposed-fix' which can not be resolved as commit?\n\nTo which I'd have to respond, \"Oh, you're using a newer git. In your\ncase use 'git checkout -b build origin/proposed-fix'\".\n\nSo, could we fix this so that a remote branch name will resolve\nwithout the \"origin/\" prefix if it is not ambiguous?\n\nI can imagine the resolution rules are already fairly complicated, (I\ndon't even know what they all are already). But when there is no\nambiguity, and when the behavior would be backwards compatible to git\nbefore separate-remotes, is there any reason this would be a bad idea?\n\nThanks,\n\n-Carl\n"},{"id":"33694","messageId":"7vveifkczt.fsf@assigned-by-dhcp.cox.net","threadId":"6587","inReplyTo":"87y7nbdeaw.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-06T06:37:42Z","receivedAt":"2007-02-06T06:37:42Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> So, could we fix this so that a remote branch name will resolve\n> without the \"origin/\" prefix if it is not ambiguous?\n\nI am fairly negative on this one, especially I do not think the\nsymptom deserves to be described with the word \"fix\". DWIM is\ngood, but it has bounds, and this particular one feels it is\nslightly on the other side of the boundary. We currently only\nDWIM out of a fixed set of patterns -- if you want to extend it,\nit would now require readdir() to expand.\n\n> I can imagine the resolution rules are already fairly complicated, (I\n> don't even know what they all are already).\n\nIf you add another DWIM rule, then I suspect that you would have\nharder time explaining why they get \"hey, that is ambiguous\"\nerror.\n"},{"id":"33696","messageId":"7vodo7karm.fsf@assigned-by-dhcp.cox.net","threadId":"6587","inReplyTo":"7vveifkczt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-06T07:25:49Z","receivedAt":"2007-02-06T07:25:49Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> If you add another DWIM rule, then I suspect that you would have\n> harder time explaining why they get \"hey, that is ambiguous\"\n> error.\n\nI forgot to quote this part.\n\n> ... to resolve \"branch\" as \"remotes/*/branch\" if unique?\n\nOne of the reasons I do not think it is a good idea is, saying\n\"if unique\" makes it sound as if it is sane, but it forgets that\nwhat confusion it is bringing into the picture when not unique.\n\nIf somebody says \"git show master\", obviously it would be found\nunder refs/heads/, and most likely there would be a tracking\nbranch refs/remotes/origin/master if you are not the project\nlead, and if you work on more than one machines using\nmothership-satellites configuration, you would probably have\nrefs/remotes/note/master and refs/remotes/laptop/master on your\nmothership machine. Now, \"master\" is not unique, but I do not\nthink we would want to complain \"Gaah, master is not unique! If\nyou mean heads/master, say so\".\n\nSo addition to \"if unique\", we need another DWIM rule that says\n\"refs/heads/branch\" trumps even when there are branch elsewhere\nand prevents ambiguity rule from triggering.\n\nAnd that is only one example I can think of in 10 minutes while\nwatching TV sitting next to my wife, without thinking much about\ngit X-<. Who knows what other additional confusion we are\ntalking about? That is what I fear most.\n"},{"id":"33697","messageId":"20070206072820.GC23866@coredump.intra.peff.net","threadId":"6587","inReplyTo":"87y7nbdeaw.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-06T07:28:20Z","receivedAt":"2007-02-06T07:28:20Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 05, 2007 at 09:51:19PM -0800, Carl Worth wrote:\n\n> I can imagine the resolution rules are already fairly complicated, (I\n> don't even know what they all are already). But when there is no\n> ambiguity, and when the behavior would be backwards compatible to git\n> before separate-remotes, is there any reason this would be a bad idea?\n\nI'm not convinced that the complication is a good idea. However, if you\nwould like to play with it, a patch is below (it depends on my 'add\nutility functions for enumerating remotes' patch, which I just posted).\n\n-- >8 --\nsha1_name: match refs in 'refs/remotes/*/%s'\n\nIf no other matches are found for a ref, then look for it in every defined\nremote. This will not complain of ambiguity, since we only do the lookup if\nno other ref matches.\n---\n sha1_name.c | 37 +++++++++++++++++++++++++++++++++++++\n 1 files changed, 37 insertions(+), 0 deletions(-)\n\ndiff --git a/sha1_name.c b/sha1_name.c\nindex d77f770..d9fe107 100644\n--- a/sha1_name.c\n+++ b/sha1_name.c\n@@ -5,6 +5,7 @@\n #include \"blob.h\"\n #include \"tree-walk.h\"\n #include \"refs.h\"\n+#include \"remotes.h\"\n \n static int find_short_object_filename(int len, const char *name, unsigned char *sha1)\n {\n@@ -235,6 +236,30 @@ static int ambiguous_path(const char *path, int len)\n \treturn slash;\n }\n \n+struct match_ref_in_remote_data {\n+\tconst char *ref;\n+\tint ref_len;\n+\tint count;\n+\tunsigned char *sha1;\n+\tchar *resolved;\n+};\n+static int match_ref_in_remote(const char *remote, void *data)\n+{\n+\tstruct match_ref_in_remote_data *md = data;\n+\tunsigned char sha1_from_ref[20];\n+\tconst char *r;\n+\n+\tr = resolve_ref(\n+\t\tmkpath(\"refs/remotes/%s/%.*s\", remote, md->ref_len, md->ref),\n+\t\tmd->count ? sha1_from_ref : md->sha1,\n+\t\t1, NULL);\n+\tif (r) {\n+\t\tif (!md->count++)\n+\t\t\tmd->resolved = xstrdup(r);\n+\t}\n+\treturn 0;\n+}\n+\n static const char *ref_fmt[] = {\n \t\"%.*s\",\n \t\"refs/%.*s\",\n@@ -264,6 +289,18 @@ int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref)\n \t\t\t\tbreak;\n \t\t}\n \t}\n+\n+\tif (!refs_found) {\n+\t\tstruct match_ref_in_remote_data md;\n+\t\tmd.ref = str;\n+\t\tmd.ref_len = len;\n+\t\tmd.count = 0;\n+\t\tmd.sha1 = sha1;\n+\t\tfor_each_remote(match_ref_in_remote, &md);\n+\t\trefs_found = md.count;\n+\t\t*ref = md.resolved;\n+\t}\n+\n \treturn refs_found;\n }\n \n-- \n1.5.0.rc3.554.ga40e-dirty\n"},{"id":"33698","messageId":"20070206073141.GD23866@coredump.intra.peff.net","threadId":"6587","inReplyTo":"7vodo7karm.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-06T07:31:41Z","receivedAt":"2007-02-06T07:31:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 05, 2007 at 11:25:49PM -0800, Junio C Hamano wrote:\n\n> So addition to \"if unique\", we need another DWIM rule that says\n> \"refs/heads/branch\" trumps even when there are branch elsewhere\n> and prevents ambiguity rule from triggering.\n\nFWIW, the patch I just posted allows all existing lookups to trump\nrefs/remotes/*/%s, but will complain of ambiguities between remotes.\nBut please don't take my patch as a vote for this being sane. :) I just\nwanted to give Carl something to play with.\n\n-Peff\n"},{"id":"33700","messageId":"7vy7nbiv90.fsf@assigned-by-dhcp.cox.net","threadId":"6587","inReplyTo":"20070206072820.GC23866@coredump.intra.peff.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-06T07:46:19Z","receivedAt":"2007-02-06T07:46:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> sha1_name: match refs in 'refs/remotes/*/%s'\n>\n> If no other matches are found for a ref, then look for it in every defined\n> remote. This will not complain of ambiguity, since we only do the lookup if\n> no other ref matches.\n\nI think the abstraction is wrong -- why do you even need to\niterate over .git/remotes (and .git/config remote.*) when the\nonly thing this cares about is refs under refs/remotes/*\nhierarchy?\n\nOr am I missing something blatantly obvious?\n"},{"id":"33703","messageId":"20070206081205.GA31948@coredump.intra.peff.net","threadId":"6587","inReplyTo":"7vy7nbiv90.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2007-02-06T08:12:05Z","receivedAt":"2007-02-06T08:12:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Feb 05, 2007 at 11:46:19PM -0800, Junio C Hamano wrote:\n\n> I think the abstraction is wrong -- why do you even need to\n> iterate over .git/remotes (and .git/config remote.*) when the\n> only thing this cares about is refs under refs/remotes/*\n> hierarchy?\n\nWell, you obviously can't look in the directory because of packed refs.\nYou can enumerate all refs with for_each_remote_ref and try to match\nagainst \"refs/remotes/*/$ref\". But how do you handle '/' in a remote\nname or a branch name? If I have a remote \"foo/bar\" with branch \"baz\",\nshould I match it while looking up \"bar/baz\"? What about having the\nremote \"foo\" and the branch \"bar/baz\"? Should a lookup for \"baz\" find\nthat?\n\nIf I'm just given the collapsed \"remote/branch\" text, I don't know which\nparts are remote and which parts are branch, unless I make the\nassumption that remotes have no '/' in them (which I did not think we\nwere making).\n\n-Peff\n"},{"id":"33732","messageId":"Pine.LNX.4.64.0702061027570.19212@xanadu.home","threadId":"6587","inReplyTo":"20070206072820.GC23866@coredump.intra.peff.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2007-02-06T15:33:31Z","receivedAt":"2007-02-06T15:33:31Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Tue, 6 Feb 2007, Jeff King wrote:\n\n> I'm not convinced that the complication is a good idea. However, if you\n> would like to play with it, a patch is below (it depends on my 'add\n> utility functions for enumerating remotes' patch, which I just posted).\n\n\nYour patch forgot to add the equivalent handling to dwim_log().\n\n\nNicolas\n"},{"id":"33749","messageId":"87wt2vce31.wl%cworth@cworth.org","threadId":"6587","inReplyTo":"7vveifkczt.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-02-06T18:53:38Z","receivedAt":"2007-02-06T18:53:38Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Mon, 05 Feb 2007 22:37:42 -0800, Junio C Hamano wrote:\n> Carl Worth writes:\n>\n> > So, could we fix this so that a remote branch name will resolve\n> > without the \"origin/\" prefix if it is not ambiguous?\n>\n> I am fairly negative on this one, especially I do not think the\n> symptom deserves to be described with the word \"fix\". DWIM is\n> good, but it has bounds, and this particular one feels it is\n> slightly on the other side of the boundary.\n\nI can accept that argument.\n\nWith \"fix\" I was referring to the backwards-compatibility problem,\n(that I don't have a way to give branch checkout instructions to users\nthat will work for both 1.5 and pre-1.5 versions of git). As is, if\nI provide instructions that don't match the version the user has, then\nthe user will see a rather confusing message:\n\n\tgit checkout: updating paths is incompatible with switching branches/forcing\n\tDid you intend to checkout 'origin/8801' which can not be resolved as commit?\n\n[And perhaps the message above is evidence for too much DWIM in the\ninterface already---that checkout will accept either a revision\nspecifier or a path name and do fairly distinct operations depending\non which it gets.]\n\nIf my tail-matching-for-remotes idea won't fly, are there any other\nsuggestions for a way to provide instructions for this step that would\nwork across both 1.4 and 1.5 versions of git?\n\n> If you add another DWIM rule, then I suspect that you would have\n> harder time explaining why they get \"hey, that is ambiguous\"\n> error.\n\nWell, ideally git would explain the ambiguity with something like\nthis:\n\n\tThere are multiple \"proposed-fix\" remote-tracking\n\tbranches. Please specify which you would like:\n\n\t\torigin/proposed-fix\n\t\tsomething-else/proposed-fix\n\nAnd I would think that this would not even be surprising since the\nuser would not get into this situation by default, but would actually\nhave to have added an additional something-else remote before being\nable to get this kind of ambiguity.\n\nBut, like I said, I'm glad to accept that the tail-matching idea is a\nbad idea. Feel free to drop that on the floor. I'm more interested in\nthe compatibility issue.\n\n-Carl\n"},{"id":"33750","messageId":"7vwt2vgkuc.fsf@assigned-by-dhcp.cox.net","threadId":"6587","inReplyTo":"87wt2vce31.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-02-06T19:14:03Z","receivedAt":"2007-02-06T19:14:03Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Carl Worth writes:\n\n> On Mon, 05 Feb 2007 22:37:42 -0800, Junio C Hamano wrote:\n>> Carl Worth writes:\n>>\n>> > So, could we fix this so that a remote branch name will resolve\n>> > without the \"origin/\" prefix if it is not ambiguous?\n>>\n>> I am fairly negative on this one, especially I do not think the\n>> symptom deserves to be described with the word \"fix\". DWIM is\n>> good, but it has bounds, and this particular one feels it is\n>> slightly on the other side of the boundary.\n>\n> I can accept that argument.\n>\n> With \"fix\" I was referring to the backwards-compatibility problem,\n> (that I don't have a way to give branch checkout instructions to users\n> that will work for both 1.5 and pre-1.5 versions of git).\n\nIf you tell your users to --use-separate-remote in the \"git\nclone\" instruction, would that solve your backward compatibility\nproblem?\n"},{"id":"33751","messageId":"87sldjcbxt.wl%cworth@cworth.org","threadId":"6587","inReplyTo":"7vwt2vgkuc.fsf@assigned-by-dhcp.cox.net","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2007-02-06T19:39:58Z","receivedAt":"2007-02-06T19:39:58Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 06 Feb 2007 11:14:03 -0800, Junio C Hamano wrote:\n> If you tell your users to --use-separate-remote in the \"git\n> clone\" instruction, would that solve your backward compatibility\n> problem?\n\nAh, yes. That should actually do the trick.\n\nThanks,\n\n-Carl\n"},{"id":"33752","messageId":"eqamic$7es$1@sea.gmane.org","threadId":"6587","inReplyTo":"87sldjcbxt.wl%cworth@cworth.org","subject":"Re: Difficulties in advertising a new branch to git newbies","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2007-02-06T19:58:35Z","receivedAt":"2007-02-06T19:58:35Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Carl Worth wrote:\n\n> On Tue, 06 Feb 2007 11:14:03 -0800, Junio C Hamano wrote:\n>> If you tell your users to --use-separate-remote in the \"git\n>> clone\" instruction, would that solve your backward compatibility\n>> problem?\n> \n> Ah, yes. That should actually do the trick.\n\nActually git has this option removed (at least from docs; perhaps it is\nsimply no-op).\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"}]}