Thread (3 messages) 3 messages, 2 authors, 2017-09-12

Re: [PATCH v3 1/2 / RFC] builtin/branch: stop supporting the use of --set-upstream option

From: Junio C Hamano <hidden>
Date: 2017-09-12 06:49:24

Possibly related (same subject, not in this thread)

Kaartic Sivaraam [off-list ref] writes:
On Wed, 2017-08-16 at 12:09 -0700, Junio C Hamano wrote:
quoted
You said that "checkout" does not do a necessary check that is done
in "branch", so presumably "branch" already has a code to do so that
is not called by the current "checkout", right?  Then you would add
a new caller in "checkout" to trigger the same check that is already
done in "branch", but the code "branch" uses _might_ be too specific
to the kind of data the current implementation of "branch" uses and
it _may_ not be easy to call it directly from "checkout" (I didn't
check if that is the case).  If so, then the check implemented in
the current "branch" may need to be refactored before it can easily
be called from the new caller you would be adding to "checkout".
Thanks. Now I get it. What about doing that check in
branch.c::create_branch or branch.c::validate_new_branchname? I guess
creating a branch named HEAD isn't that good an idea in any case. Doing
the check there might prevent a similar situation in future, I guess.
Further "branch" and "checkout" do call branch.c::create_branch which
in turn calls branch.c::validate_new_branchname.
The above analysis sounds sensible, so it appears that you already
found a function that is shared in the two codepaths, and have a
good plan to make them consistent?

I was sweeping my mailbox to collect loose ends that haven't been
tied down, and noticed that this topic does not seem to reach a
conclusion.  Do we want to reboot the effort?  Or should we just
throw it in the #leftoverbits bin for now?

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help