Re: [PATCH, RFC] checkout: Attempt to checkout submodules

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

 



On Thu, Mar 19, 2015 at 02:15:19PM -0700, Junio C Hamano wrote:
> Trevor Saunders <tbsaunde@xxxxxxxxxxxx> writes:
> 
> > On one hand it seems kind of user hostile to just toss out any changes
> > in the submodule that are uncommitted, on the other for any other path
> > it would seem weird to have git checkout trigger rebasing or merging.
> 
> I think that is exactly why we do not do anything in this codepath.

yeah, and not only is it weird, but git diff will still report that
there's a difference which I imagine people will find strange.

> I have a feeling that an optional feature that allows "git submodule
> update" to happen automatically from this codepath might be
> acceptable by the submodule folks, and they might even say it does
> not even have to be optional but should be enabled by default.

ok, that seems fairly reasonable.  I do kind of wonder though if it
shouldn't be 'git submodule update --checkout' but that would get us
kind of back to where we started.  I guess since the default is checkout
if you set the pref then you can be assumed to have some amount of idea
what your doing.

> But I do not think it would fly well to unconditionally run
> "checkout -f" here.

agreed

Trev

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