Re: Re: Re: [RFC v2] submodule: Respect requested branch on all clones

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

 



Hi,

On Tue, Jan 14, 2014 at 11:24:45AM +0100, Heiko Voigt wrote:
> I will write another post about how I think we should/can proceed.

and here is my suggestion how we should proceed.

I think there have been many interesting ideas in this thread but IMO
some of them tried to achieve a little bit to much and were not clear
enough. I am a fan of: Keep it as simple as possible, but *no simpler*.
I think some ideas where going in the "make it to simple" direction.

Take my idea for feature branch support from here[1]. After thinking more
thoroughly it still too many corner cases. E.g. it is way to easy to
accidentally merge the feature branch configuration into the stable branch. But
we want to support the user properly so we need to catch stuff like that.

Submodules are separate projects. There is a boundary between
superproject and submodule and IMO its there for a good reason. E.g.
take the typical "shared code" use-case. If A and B are using C
then both want to make sure a change from A does not break B's
expectations and vice versa. Thats were you usually write unit tests in
C for: Ensure that the expectations are met. The more users of the code
the higher the quality and thus the boundary for bad code should be.

I would like to step back a bit and get back to the original problem at hand:
Francescos original use case of an attached head for direct commits on a stable
branch in a submodule. How about we finish discussing the exact solution of
that first. AFAIK that is already solved with the following:

 * Trevor's first patch[2] to create a branch on initial clone of a submodule
 * A possibly a configuration variable for --remote so it can be
   set as the default update method
 * Combined with submodule.<name>.update=merge/rebase

That should be all (and IIRC Francesco agreed) needed for that use-case.

Lets not implement more than currently is needed. We can revisit the ideas once
some other real use-case manifests. Also we (Jens and I) would first like to
proceed with the recursive checkout / fetch (for which the plan is clear) as
the next complicated step.

Once that is done and people gain some experience with it we can still extend
further.

What do you think?

Cheers Heiko

[1] http://article.gmane.org/gmane.comp.version-control.git/240178/
[2] http://article.gmane.org/gmane.comp.version-control.git/239921
--
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]