Re: [RFC] Third round of support for cloning submodules

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

 



Martin Waitz, Mon, May 21, 2007 00:14:55 +0200:
> >  - Do we detach HEAD if the commit named by the superproject
> >    tree is not at the tip of the current branch of subproject?
> >    do we detach always even if the commit is at the tip?
> 
> We must not mess with random upstream branches of the submodule
> just because they happen to reference the same tip.
> That would be too confusing.

Strange. The very same reason I heard when I tried to explain why
branches are good. The people found them confusing, just like you now.
They preach Perforce, too.

> Either use one special branch or detach.

Why not just detach always?

> >  - What would we do when the subproject working tree is not
> >    clean?
> 
> The same as with normal files:
> error out if something is changed which conflicts with the requested
> update.

This is called tree-level merge. Done by -m option (it does more than
that, yes, but this one too). While at it we can do file-level merge
as well, why not?

> When we have a special managed-by-supermodule branch and the submodule
> has another branch currently checked out we can entirely ignore this
> issue.

Detached head isn't special enough?

> >  - How can a user decide which subproject to descend into and
> >    which subproject to ignore, and how does git remember the
> >    earlier decision made by the user without asking the same
> >    again, and how does a user express "now I want to also track
> >    that subproject I've ignored so far" and "now I am not
> >    interested in following that subproject anymore"?
> 
> I'd simply use explicit checkout of a submodule and removal of
> the submodule to be a fine way to express the user's wish.

The directory of the submodule will be back by the next
git-checkout-index (in the current implementation).
Not the .git's, so yes it is a fine way to express user's wish: he
just initialize the subprojects he wants (by whatever way).

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

  Powered by Linux