Re: In favor of "git commit --no-parent"

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Sep 29, 2011 at 5:28 PM, Michael Witten <mfwitten@xxxxxxxxx> wrote:
> On Thu, Sep 29, 2011 at 21:02, Phil Hord <phil.hord@xxxxxxxxx> wrote:
>> I think a user looking for this functionality -- either a new git user
>> or a user who seldom uses the "create secondary root commit" command
>> -- would first try 'git help init'.  It seems logical to me that I
>> should be able to do this:
>>
>>  cd my-git-repo
>>  git init --root=<newbranch> .
>>
>> This feels natural to me for this operation.
>
> That would be a good place for the "git checkout --no-parent" variant,
> especially given that I think "git checkout --no-parent" should produce
> an empty working tree and index, which we can all note is essentially
> what "git init" gives us.
>
> Your suggestion seems like a corroboration of my stance.

I'm not arguing the functionality; just the command spelling.
Consider your stance corroborated.

I don't like "git checkout" for this because
1. git-checkout is too popular already; oddball functions like this
should live in the shadows.
2. git-checkout is conceptually wrong, imho.  git-checkout means
"fetch me this commit" or "fetch me files from this commit".
Technically it does the same thing that we're talking about here (it
frobs the index, the workdir and HEAD), but conceptually it is very
different.

Conceptually, I think the functionality you're talking about is more
akin to git-init.

Phil
--
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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]