On Fri, Feb 28, 2014 at 08:16:13PM +0900, Brian Gesiak wrote:
> > I just don't want to regress somebody else's workflow due
> > to my lack of imagination.
>
> This makes a lot of sense to me, although as-is the function emits a
> warning and returns immediately (although with a successful status
> code), so I'm also stumped as to what kind of workflow this would be
> included in.
I'm cc-ing Matthieu, who wrote 85e2233, which introduces the check. Its
commit message says:
branch: warn and refuse to set a branch as a tracking branch of
itself.
Previous patch allows commands like "git branch --set-upstream foo
foo", which doesn't make much sense. Warn the user and don't change
the configuration in this case. Don't die to let the caller finish its
job in such case.
For those just joining us, we are focused on the final statement, and
deciding whether we should die() in this case. But I am not clear what
job it would want to be finishing (creating the branch, I guess, but you
cannot be doing anything useful, since by definition the branch already
exists and you are not changing its tip). There wasn't any relevant
discussion on the list[1]. Matthieu, can you remember anything else that
led to that decision?
> In any case, if the jury's out on this one, I suppose the two patches
> I submitted are good to merge? Part of me thinks the bump from warning
> to error belongs in its own patch anyway.
Yeah, it should definitely be a separate patch on top.
-Peff
[1] Threads are:
http://thread.gmane.org/gmane.comp.version-control.git/137297/focus=137299
and
http://thread.gmane.org/gmane.comp.version-control.git/137401/focus=137403
but the discussion focused on the first part of the series.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html