Re: [PATCH v3] git checkout -b: unparent the new branch with -o

[Erick Mattos <erick.mattos@gmail.com>]

Hi,

Junio, you are the leader.  And I really don't want to bother you with
my opinions.

I am just trying to make you satisfied so gitsters, I mean git users,
will have this feature as soon as possible.

2010/3/16 Junio C Hamano <gitster@pobox.com>:
>> After the 'checkout -o -b' the new branch is not saved until committed.
>> Before committing you should 'git rm -rf' anything which is not going to
>> take part in the new branch and change the work tree and index the way
>> you want it to be since they remain untouched as before checkout
>> command.
>
> This paragraph makes the patch incoherent.  It talks as if "no common
> paths" is the majority case, and everybody inconveniently has to perform
> an extra step that shouldn't be needed if the implementation were done
> right.  If "no common paths" is indeed the assumed primary target, why
> doesn't the implementation empty both index and files in the working tree
> so that users don't have to do so themselves?

I was NOT trying to scare with my message.  That paragraph was meant
to let people who would need to do something ("no common paths") know
what they will need to do.  I think it is good enough because "mostly
common paths" people will be happy too by knowing that everything is
unchanged as they want it to be.  So I haven't thought about scaring
at all.  I thought it was good indeed!  :-)

> My _only_ complaint was that your version that _only_ emptied the index
> without touching the working tree made things difficult for everybody,
> both "no common paths" people and "mostly common paths" people.

Just to clarify my point-of-view about the design:

I do prefer my first design mainly because it mimics the state of an
initial commit.  I think that is subjectively better.

You have been asking me to make one of the two possible work flow uses
you pictured as favored so things will be already set to them.  No
further commands to them.

I did it!  As a matter of fact the "mostly common paths" people were
favored as you have noticed your inclination to it before.

As I told you, I just want to make you happy so people that needs the
feature I am working on could have it as fast as possible.

And if one of the possible work flows have to be favored then I do
agree with you about "mostly common paths" as the best choice.

But the point is that the other group will need to do further commands
anyway so I would keep my previous design because of the resemblance
to an initial commit: work tree full and nothing added to the index.

But I mean it!  I really want to satisfy you.  So this was the last
time I talk about my preference.

Therefore let's find out what you want me to do so we can finish this
production cycle.  I don't want to bother you anymore.

> You need to at least qualify the above paragraph with something like "if
> you want to create an unrelated branch whose contents do not resemble the
> original branch at all, then you should ...".
>
> Better yet, try to advertise what you are giving your users in a positive
> way, instead of in a way that only scares users, perhaps like this:
>
>    After 'checkout --orphan', your HEAD will point at an unborn branch,
>    and the next commit will start a new history without any prior commit.
>    To help create such a new history that has contents mostly the same as
>    that of the original branch, the command does not touch the index nor
>    the working tree, and "checkout --orphan" immediately followed by
>    "commit -a" would record a tree very similar to what you had in the
>    original branch.  This is useful when you want to ... [insert a
>    summary of "going open source" example from my previous message if you
>    want here].
>
>    If on the other hand you want to start a new branch whose contents do
>    not resemble the original branch at all, you may want to start from an
>    empty index and the working tree, with "git rm -rf ." immediately
>    after running this command.
>
> The same comment applies to the documentation part.

I was trying to be concise on my message.  I realize you want it more explained.

What about that:

After the 'checkout -o -b' you are in an new unborn branch ready to be
committed.  The next commit will start a new history without any
ancestry.  If this new branch was made to start from scratch, not
resembling the previous one, then you should use 'git rm -rf' to get
an empty work tree and index.  Otherwise with a 'git commit -a' you
will have a tree exactly as in the previous branch.  So just set
things as you want it to be and commit the new unparented branch.

> By the way, I wouldn't mind if you believe "no common paths" is the
> majority case; if that is the case, then the code and behaviour would be
> different, and the presentation would say something like this:

I agree with you in choosing "mostly common paths" as the target since
you have decided to target one.

Before I send another patch version could you please tell me your
position about my new explaining text up there.  I will wait for your
reply before sending a new patch version.

Best regards