# [PATCH] builtin-branch: highlight current remote branches with an asterisk 16 messages from 2009-02-09 to 2009-02-10. Participants: Jay Soffian, Johannes Schindelin, Mark Burton, Junio C Hamano, Björn Steinbrink, Santi Béjar, Jeff King. Thread: https://gitlist.dev/t/17686 ## Jay Soffian, 2009-02-09 23:32 Subject: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <1234222326-55818-1-git-send-email-jaysoffian@gmail.com> URL: https://gitlist.dev/e/1234222326-55818-1-git-send-email-jaysoffian%40gmail.com ``` Teach git branch -{r,a} how to interpret remote HEADs and highlight the corresponding remote branch with an asterisk, instead of showing literal "/HEAD". Signed-off-by: Jay Soffian --- git branch -r before patch: origin/HEAD origin/html origin/maint origin/man origin/master origin/next origin/pu origin/todo git branch -r after patch: origin/html origin/maint origin/man * origin/master origin/next origin/pu origin/todo The coloring for the current remote branch remains red, not green like the current local branch. I think it's an improvement. :) builtin-branch.c | 41 ++++++++++++++++++++++++++++++----------- 1 files changed, 30 insertions(+), 11 deletions(-) diff --git a/builtin-branch.c b/builtin-branch.c index 56a1971..62558a7 100644 --- a/builtin-branch.c +++ b/builtin-branch.c @@ -15,6 +15,7 @@ #include "branch.h" #include "diff.h" #include "revision.h" +#include "string-list.h" static const char * const builtin_branch_usage[] = { "git branch [options] [-r | -a] [--merged | --no-merged]", @@ -190,9 +191,19 @@ struct ref_list { int index, alloc, maxwidth; struct ref_item *list; struct commit_list *with_commit; + struct string_list *remote_heads; int kinds; }; +static void add_to_remote_heads(struct string_list *remote_heads, const char *head) { + unsigned char sha1[20]; + int flag; + const char *refname = resolve_ref(head, sha1, 0, &flag); + if (refname && (flag & REF_ISSYMREF) && + !prefixcmp(refname, "refs/remotes/")) + string_list_insert(refname + 13, remote_heads); +} + static int append_ref(const char *refname, const unsigned char *sha1, int flags, void *cb_data) { struct ref_list *ref_list = (struct ref_list*)(cb_data); @@ -223,6 +234,13 @@ static int append_ref(const char *refname, const unsigned char *sha1, int flags, if ((kind & ref_list->kinds) == 0) return 0; + /* Handle remote HEAD */ + if (kind == REF_REMOTE_BRANCH && ((len = strlen(refname)) > 5) && + !strcmp(refname + len - 5, "/HEAD")) { + add_to_remote_heads(ref_list->remote_heads, refname - 13); + return 0; + } + if (merge_filter != NO_FILTER) add_pending_object(&ref_list->revs, (struct object *)commit, refname); @@ -294,8 +312,8 @@ static int matches_merge_filter(struct commit *commit) static void print_ref_item(struct ref_item *item, int maxwidth, int verbose, int abbrev, int current) { - char c; - int color; + char c = ' '; + int color = COLOR_BRANCH_PLAIN, current_color = COLOR_BRANCH_CURRENT; struct commit *commit = item->commit; if (!matches_merge_filter(commit)) @@ -306,17 +324,13 @@ static void print_ref_item(struct ref_item *item, int maxwidth, int verbose, color = COLOR_BRANCH_LOCAL; break; case REF_REMOTE_BRANCH: - color = COLOR_BRANCH_REMOTE; - break; - default: - color = COLOR_BRANCH_PLAIN; + color = current_color = COLOR_BRANCH_REMOTE; break; } - c = ' '; if (current) { c = '*'; - color = COLOR_BRANCH_CURRENT; + color = current_color; } if (verbose) { @@ -364,10 +378,12 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str int i; struct ref_list ref_list; struct commit *head_commit = lookup_commit_reference_gently(head_sha1, 1); + struct string_list remote_heads = { NULL, 0, 0, 1}; memset(&ref_list, 0, sizeof(ref_list)); ref_list.kinds = kinds; ref_list.with_commit = with_commit; + ref_list.remote_heads = &remote_heads; if (merge_filter != NO_FILTER) init_revisions(&ref_list.revs, NULL); for_each_ref(append_ref, &ref_list); @@ -399,13 +415,16 @@ static void print_ref_list(int kinds, int detached, int verbose, int abbrev, str } for (i = 0; i < ref_list.index; i++) { - int current = !detached && + int current = (!detached && (ref_list.list[i].kind == REF_LOCAL_BRANCH) && - !strcmp(ref_list.list[i].name, head); + !strcmp(ref_list.list[i].name, head)) || + (ref_list.list[i].kind == REF_REMOTE_BRANCH && + string_list_has_string(&remote_heads, + ref_list.list[i].name)); print_ref_item(&ref_list.list[i], ref_list.maxwidth, verbose, abbrev, current); } - + string_list_clear(&remote_heads, 0); free_ref_list(&ref_list); } -- 1.6.1.2.354.ge44a2 ``` ## Johannes Schindelin, 2009-02-09 23:49 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0902100048410.10279%40pacific.mpi-cbg.de In-Reply-To: <1234222326-55818-1-git-send-email-jaysoffian@gmail.com> ``` Hi, On Mon, 9 Feb 2009, Jay Soffian wrote: > Teach git branch -{r,a} how to interpret remote HEADs and highlight the > corresponding remote branch with an asterisk, instead of showing literal > "/HEAD". Let's hope that nobody's scripts rely on a single star in front of the local HEAD... Ciao, Dscho ``` ## Mark Burton, 2009-02-10 00:03 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210000321.78025483@crow> URL: https://gitlist.dev/e/20090210000321.78025483%40crow In-Reply-To: ``` Hi, Johannes Schindelin wrote: > Let's hope that nobody's scripts rely on a single star in front of the > local HEAD... I don't know if I have any scripts that rely on a single star in front of the local HEAD or not (I'm sure some people must have them), but I do think this new feature would be very confusing, especially when used with -a. At the very least, make the indicator something other than a star, an @ or #, perhaps. Cheers, Mark ``` ## Jay Soffian, 2009-02-10 00:10 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <76718490902091610v1a53494ajb24b6a87bf207a78@mail.gmail.com> URL: https://gitlist.dev/e/76718490902091610v1a53494ajb24b6a87bf207a78%40mail.gmail.com In-Reply-To: ``` On Mon, Feb 9, 2009 at 6:49 PM, Johannes Schindelin wrote: > Hi, > > On Mon, 9 Feb 2009, Jay Soffian wrote: > >> Teach git branch -{r,a} how to interpret remote HEADs and highlight the >> corresponding remote branch with an asterisk, instead of showing literal >> "/HEAD". > > Let's hope that nobody's scripts rely on a single star in front of the > local HEAD... Perhaps you'd be happier with a different marker for the remote head, but in any case, git branch is a porcelain, isn't it? j. ``` ## Jay Soffian, 2009-02-10 00:22 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <76718490902091622y9a6d1bak5dc401858382e2ff@mail.gmail.com> URL: https://gitlist.dev/e/76718490902091622y9a6d1bak5dc401858382e2ff%40mail.gmail.com In-Reply-To: <20090210000321.78025483@crow> ``` (Please don't trim cc:) On Mon, Feb 9, 2009 at 7:03 PM, Mark Burton wrote: > I don't know if I have any scripts that rely on a single star in front of > the local HEAD or not (I'm sure some people must have them), but I do > think this new feature would be very confusing, especially when used > with -a. > > At the very least, make the indicator something other than a star, an @ > or #, perhaps. With color, it shouldn't be confusing at all as only one branch is in green. W/o color, it still seems clear to me as the remote branches have their remote name prefixed to them. Even if you're on a detached head: * (no branch) master next sent/branch-show-remote-HEAD wip/am-usability-improvements wip/push-docs origin/html origin/maint origin/man * origin/master origin/next origin/pu origin/todo A different marker doesn't really seem like an improvement to me: * (no branch) master next sent/branch-show-remote-HEAD wip/am-usability-improvements wip/push-docs origin/html origin/maint origin/man @ origin/master origin/next origin/pu origin/todo But I'm happy to have the community paint the shed I've constructed. j. ``` ## Junio C Hamano, 2009-02-10 00:24 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <7viqnjrveb.fsf@gitster.siamese.dyndns.org> URL: https://gitlist.dev/e/7viqnjrveb.fsf%40gitster.siamese.dyndns.org In-Reply-To: <20090210000321.78025483@crow> ``` Mark Burton writes: > Johannes Schindelin wrote: >> Let's hope that nobody's scripts rely on a single star in front of the >> local HEAD... > > I don't know if I have any scripts that rely on a single star in front of > the local HEAD or not (I'm sure some people must have them), but I do > think this new feature would be very confusing, especially when used > with -a. People use "git branch | sed -ne 's/^\* //p' in their scripts (you can say "against recommendation" but I think it is a sign that the recommendation against use of Porcelain in the scripts is not loud enough). I do not think anybody greps in "git branch -a", though, for that purpose. The current "branch -a" output is a mess. It omits "remotes/" even though it includes the local ones in the output. Perhaps with remotes/, the output may become a bit more readable: $ git branch -a * master next pu * remotes/dscho/master * remotes/origin/master remotes/origin/next remotes/origin/pu * remotes/spearce/master which may still be too loud with asterisks, but at least there is no confusion. Or perhaps like this: $ git branch -a * master next pu remotes/dscho/HEAD -> master remotes/dscho/master remotes/origin/HEAD -> master remotes/origin/master remotes/origin/next remotes/origin/pu remotes/spearce/HEAD -> master remotes/spearce/master with an obvious twist when there is no mixed output: $ git branch -r dscho/HEAD -> master dscho/master origin/HEAD -> master origin/master origin/next origin/pu spearce/HEAD -> master spearce/master ``` ## Björn Steinbrink, 2009-02-10 07:52 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210075214.GC1320@atjola.homenet> URL: https://gitlist.dev/e/20090210075214.GC1320%40atjola.homenet In-Reply-To: <1234222326-55818-1-git-send-email-jaysoffian@gmail.com> ``` On 2009.02.09 18:32:06 -0500, Jay Soffian wrote: > Teach git branch -{r,a} how to interpret remote HEADs and highlight the > corresponding remote branch with an asterisk, instead of showing literal > "/HEAD". Hm, what's the use case for having such a marker? And since only "git clone" sets up origin/HEAD, while "git remote add foo git://..." won't create foo/HEAD, you would get that marker for origin only. Also, the origin/HEAD symref isn't updated, so it doesn't tell you which branch is "active" in the remote repository now, but which one was active when you cloned the repo. So basically, what that marker would tell you is that you can use "origin" as a short-shortname for the remote tracking branch that has the marker. I don't see how that is very useful. If the /HEAD symref would be created for all remotes and would get updated, that would at least make the marker more meaningful, but I still don't really see what I'd use it for. From what I've heard, some people just consider origin/HEAD a clone artifact without much use, and so far, I think I agree. But maybe there's more to it? Björn ``` ## Santi Béjar, 2009-02-10 07:59 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: URL: https://gitlist.dev/e/adf1fd3d0902092359o43427e89j2005e3653766723f%40mail.gmail.com In-Reply-To: <7viqnjrveb.fsf@gitster.siamese.dyndns.org> ``` 2009/2/10 Junio C Hamano : > Mark Burton writes: > >> Johannes Schindelin wrote: >>> Let's hope that nobody's scripts rely on a single star in front of the >>> local HEAD... >> >> I don't know if I have any scripts that rely on a single star in front of >> the local HEAD or not (I'm sure some people must have them), but I do >> think this new feature would be very confusing, especially when used >> with -a. > > People use "git branch | sed -ne 's/^\* //p' in their scripts (you can say > "against recommendation" but I think it is a sign that the recommendation > against use of Porcelain in the scripts is not loud enough). I do not > think anybody greps in "git branch -a", though, for that purpose. > > The current "branch -a" output is a mess. It omits "remotes/" even though > it includes the local ones in the output. Perhaps with remotes/, the > output may become a bit more readable: > > $ git branch -a > * master > next > pu > * remotes/dscho/master > * remotes/origin/master > remotes/origin/next > remotes/origin/pu > * remotes/spearce/master > > which may still be too loud with asterisks, but at least there is no > confusion. Or perhaps like this: > > $ git branch -a > * master > next > pu > remotes/dscho/HEAD -> master > remotes/dscho/master > remotes/origin/HEAD -> master > remotes/origin/master > remotes/origin/next > remotes/origin/pu > remotes/spearce/HEAD -> master > remotes/spearce/master > > with an obvious twist when there is no mixed output: > > $ git branch -r > dscho/HEAD -> master > dscho/master > origin/HEAD -> master > origin/master > origin/next > origin/pu > spearce/HEAD -> master > spearce/master For me it makes sense. Also this type of output for symrefs "-> master" makes even more sense in the verbose output. Santi ``` ## Santi Béjar, 2009-02-10 08:02 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: URL: https://gitlist.dev/e/adf1fd3d0902100002k5d787e2ewe9012b42f943a6a3%40mail.gmail.com In-Reply-To: <20090210075214.GC1320@atjola.homenet> ``` 2009/2/10 Björn Steinbrink : > On 2009.02.09 18:32:06 -0500, Jay Soffian wrote: >> Teach git branch -{r,a} how to interpret remote HEADs and highlight the >> corresponding remote branch with an asterisk, instead of showing literal >> "/HEAD". > > Hm, what's the use case for having such a marker? And since only "git > clone" sets up origin/HEAD, while "git remote add foo git://..." won't > create foo/HEAD, git remote add -f ... would create it. > you would get that marker for origin only. Also, the > origin/HEAD symref isn't updated, so it doesn't tell you which branch > is "active" in the remote repository now, but which one was active when > you cloned the repo. Maybe there should be a way to update it afterwards. Santi ``` ## Björn Steinbrink, 2009-02-10 08:24 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210082439.GD1320@atjola.homenet> URL: https://gitlist.dev/e/20090210082439.GD1320%40atjola.homenet In-Reply-To: ``` On 2009.02.10 09:02:02 +0100, Santi Béjar wrote: > 2009/2/10 Björn Steinbrink : > > On 2009.02.09 18:32:06 -0500, Jay Soffian wrote: > >> Teach git branch -{r,a} how to interpret remote HEADs and highlight the > >> corresponding remote branch with an asterisk, instead of showing literal > >> "/HEAD". > > > > Hm, what's the use case for having such a marker? And since only "git > > clone" sets up origin/HEAD, while "git remote add foo git://..." won't > > create foo/HEAD, > > git remote add -f ... would create it. No, it won't. Only "git remote add -m ..." would. And there, you have to pass a branchname yourself, "-m HEAD" doesn't do the trick. So there you'd have a "the branch I have selected" instead of "the branch the remote HEAD referenced". Making it quite different from what "git clone" does. But actually, that looks like a bug. The docs for -m say that it should just override what /HEAD is set to, not that it should be required to cause the /HEAD creation. I'll try to look into that. > > you would get that marker for origin only. Also, the > > origin/HEAD symref isn't updated, so it doesn't tell you which branch > > is "active" in the remote repository now, but which one was active when > > you cloned the repo. > > Maybe there should be a way to update it afterwards. That may not be the default for remotes added with -m though, as otherwise the -m option to "git remote add" would become quite pointless. Björn ``` ## Mark Burton, 2009-02-10 11:05 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210110546.5ead75a6@crow> URL: https://gitlist.dev/e/20090210110546.5ead75a6%40crow In-Reply-To: <76718490902091622y9a6d1bak5dc401858382e2ff@mail.gmail.com> ``` On Mon, 9 Feb 2009 19:22:50 -0500 Jay Soffian wrote: > (Please don't trim cc:) > > On Mon, Feb 9, 2009 at 7:03 PM, Mark Burton wrote: > > I don't know if I have any scripts that rely on a single star in front of > > the local HEAD or not (I'm sure some people must have them), but I do > > think this new feature would be very confusing, especially when used > > with -a. > > > > At the very least, make the indicator something other than a star, an @ > > or #, perhaps. > > With color, it shouldn't be confusing at all as only one branch is in > green. How about the colour blind git users? > W/o color, it still seems clear to me as the remote branches > have their remote name prefixed to them. Even if you're on a detached > head: > > * (no branch) > master > next > sent/branch-show-remote-HEAD > wip/am-usability-improvements > wip/push-docs > origin/html > origin/maint > origin/man > * origin/master > origin/next > origin/pu > origin/todo > > A different marker doesn't really seem like an improvement to me: > > * (no branch) > master > next > sent/branch-show-remote-HEAD > wip/am-usability-improvements > wip/push-docs > origin/html > origin/maint > origin/man > @ origin/master > origin/next > origin/pu > origin/todo > > But I'm happy to have the community paint the shed I've constructed. > > j. You can paint a rickety old shed any colour you wish but it doesn't make it any stronger. Personally, I think the -> syntax is a much better idea as it is unlikely to be confused with the existing marker and it shows the relationship between the (remote) HEAD and remote current branch. Cheers, Mark ``` ## Jeff King, 2009-02-10 11:19 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210111907.GD12089@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090210111907.GD12089%40coredump.intra.peff.net In-Reply-To: <20090210075214.GC1320@atjola.homenet> ``` [let me answer your email in reverse order, which will hopefully make more sense when reading] On Tue, Feb 10, 2009 at 08:52:14AM +0100, Björn Steinbrink wrote: > still don't really see what I'd use it for. From what I've heard, some > people just consider origin/HEAD a clone artifact without much use, and > so far, I think I agree. But maybe there's more to it? The ref "origin" will resolve to "refs/remotes/origin/HEAD", if it exists. So you can use it as a shorthand for "origin/master" (or whatever branch is most interesting to you on the remote). > If the /HEAD symref would be created for all remotes and would get > updated, that would at least make the marker more meaningful, but I It has been noted in the past that it should _not_ be automatically updated, since it is really about "what is the user's preference for the 'most interesting' branch in this remote". And we don't want to overwrite some preference that they specified. So I think it makes sense to: - if it doesn't exist, set it up based on the remote's HEAD. Clone already does this, but "git remote add -f" should probably do it, too. I'm not sure if every fetch should do it. - give the user some nice interface (probably via "git remote") to move the pointer around (right now, it is "git symbolic-ref refs/remotes/$remote/HEAD refs/remotes/$remote/$branch"). - give the user some nice interface to re-fetch the remote HEAD and update refs/remotes/$remote/HEAD with it. Probably as an option to the "git remote" invocation above. -Peff ``` ## Björn Steinbrink, 2009-02-10 11:50 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210115036.GG1320@atjola.homenet> URL: https://gitlist.dev/e/20090210115036.GG1320%40atjola.homenet In-Reply-To: <20090210111907.GD12089@coredump.intra.peff.net> ``` On 2009.02.10 06:19:07 -0500, Jeff King wrote: > On Tue, Feb 10, 2009 at 08:52:14AM +0100, Björn Steinbrink wrote: > > > still don't really see what I'd use it for. From what I've heard, some > > people just consider origin/HEAD a clone artifact without much use, and > > so far, I think I agree. But maybe there's more to it? > > The ref "origin" will resolve to "refs/remotes/origin/HEAD", if it > exists. So you can use it as a shorthand for "origin/master" (or > whatever branch is most interesting to you on the remote). Yeah, that's what I meant when I said "short-shortname". Maybe it's just me, but I really can't see myself using that. Would be likely that "origin" references something else than what I expect, especially when switching from one repo to another. And doing "git branch -r" to find out if "origin" is the right thing is slower than just typing the full shortname right away. Well, just my 2 cents. > > If the /HEAD symref would be created for all remotes and would get > > updated, that would at least make the marker more meaningful, but I > > It has been noted in the past that it should _not_ be automatically > updated, since it is really about "what is the user's preference for the > 'most interesting' branch in this remote". And we don't want to > overwrite some preference that they specified. Yeah, as I said in the other mail, having it as a default would make add -m quite pointless. > So I think it makes sense to: > > - if it doesn't exist, set it up based on the remote's HEAD. Clone > already does this, but "git remote add -f" should probably do it, > too. I'm not sure if every fetch should do it. FWIW, I would hate fetch for doing that. I dislike the whole /HEAD thing, and wouldn't want fetch to recreate that for me all the time. > - give the user some nice interface (probably via "git remote") to > move the pointer around (right now, it is "git symbolic-ref > refs/remotes/$remote/HEAD refs/remotes/$remote/$branch"). Maybe "git remote set-master"? Though I kinda dislike the "master" part of the name, which I just took from the -m option to "remote add", though. I guess that could increase the confusion about the "master" branch as pre-setup by "git init" being special, and might lead to interesting conclusions about that command affecting the remote repository. > - give the user some nice interface to re-fetch the remote HEAD and > update refs/remotes/$remote/HEAD with it. Probably as an option to > the "git remote" invocation above. Yeah, would make sense. Björn ``` ## Jeff King, 2009-02-10 11:59 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210115943.GA15387@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090210115943.GA15387%40coredump.intra.peff.net In-Reply-To: <20090210115036.GG1320@atjola.homenet> ``` On Tue, Feb 10, 2009 at 12:50:36PM +0100, Björn Steinbrink wrote: > Yeah, that's what I meant when I said "short-shortname". Maybe it's just > me, but I really can't see myself using that. Would be likely that > "origin" references something else than what I expect, especially when > switching from one repo to another. And doing "git branch -r" to find > out if "origin" is the right thing is slower than just typing the full > shortname right away. Well, just my 2 cents. Hmm. I use it all the time. :) I find it especially useful in one project where everybody has a personal repo with one interesting branch, and I am the integration manager. I use "git remote update' to fetch from everybody, and then I can diff and pull against them just by naming their remote. So I think it is just one of those features that some people find useful and others don't. > Yeah, as I said in the other mail, having it as a default would make add > -m quite pointless. Not necessarily. You might be interested in some other branch that isn't their HEAD. So yes, you would hopefully be using it much less because we would be guessing what you wanted to put there instead of making you type it. But it would still be useful as an override. > > - if it doesn't exist, set it up based on the remote's HEAD. Clone > > already does this, but "git remote add -f" should probably do it, > > too. I'm not sure if every fetch should do it. > > FWIW, I would hate fetch for doing that. I dislike the whole > /HEAD thing, and wouldn't want fetch to recreate that for me all > the time. Yeah, I think that is a good reason not to have fetch do it. > > - give the user some nice interface (probably via "git remote") to > > move the pointer around (right now, it is "git symbolic-ref > > refs/remotes/$remote/HEAD refs/remotes/$remote/$branch"). > > Maybe "git remote set-master"? Though I kinda dislike the "master" part > of the name, which I just took from the -m option to "remote add", > though. I guess that could increase the confusion about the "master" > branch as pre-setup by "git init" being special, and might lead to > interesting conclusions about that command affecting the remote > repository. I think somebody suggested "set-default" in another thread, which doesn't quite work either. Perhaps "set-head" is too literal? Maybe "favorite-branch"? :) -Peff ``` ## Björn Steinbrink, 2009-02-10 12:23 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210122341.GH1320@atjola.homenet> URL: https://gitlist.dev/e/20090210122341.GH1320%40atjola.homenet In-Reply-To: <20090210115943.GA15387@coredump.intra.peff.net> ``` On 2009.02.10 06:59:43 -0500, Jeff King wrote: > On Tue, Feb 10, 2009 at 12:50:36PM +0100, Björn Steinbrink wrote: > > Yeah, as I said in the other mail, having it as a default would make add > > -m quite pointless. > > Not necessarily. You might be interested in some other branch that isn't > their HEAD. So yes, you would hopefully be using it much less because we > would be guessing what you wanted to put there instead of making you > type it. But it would still be useful as an override. I guess you read that in the wrong context (or I replied in the wrong context). What I meant is that it would be bad if "git remote update" or "git fetch " or whatever would update /HEAD automatically, as that would kill what you have setup with -m. Using -m as an override for the automatic guessing makes sense, sure. It's even what the docs say how it's supposed to work already (it just doesn't create /HEAD at all atm, unless -m is given). Björn ``` ## Jeff King, 2009-02-10 13:04 Subject: Re: [PATCH] builtin-branch: highlight current remote branches with an asterisk Message-ID: <20090210130416.GB17305@coredump.intra.peff.net> URL: https://gitlist.dev/e/20090210130416.GB17305%40coredump.intra.peff.net In-Reply-To: <20090210122341.GH1320@atjola.homenet> ``` On Tue, Feb 10, 2009 at 01:23:41PM +0100, Björn Steinbrink wrote: > > > Yeah, as I said in the other mail, having it as a default would make add > > > -m quite pointless. > > > > Not necessarily. You might be interested in some other branch that isn't > > their HEAD. So yes, you would hopefully be using it much less because we > > would be guessing what you wanted to put there instead of making you > > type it. But it would still be useful as an override. > > I guess you read that in the wrong context (or I replied in the wrong > context). What I meant is that it would be bad if "git remote update" or > "git fetch " or whatever would update /HEAD > automatically, as that would kill what you have setup with -m. Ah, OK, I totally misunderstood. Yes, I think we are in agreement, then. -Peff ```