2014/1/14 Heiko Voigt :
> On Tue, Jan 14, 2014 at 02:22:31PM -0800, W. Trevor King wrote:
>> On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
>> > 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 dire
On Tue, Jan 14, 2014 at 02:22:31PM -0800, W. Trevor King wrote:
> On Tue, Jan 14, 2014 at 10:46:08PM +0100, Heiko Voigt wrote:
> > 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 br
On Tue, Jan 14, 2014 at 01:42:09PM -0800, W. Trevor King wrote:
> On Tue, Jan 14, 2014 at 09:58:30PM +0100, Heiko Voigt wrote:
> > A typical workflow where a feature in a project needs some extension or
> > change in a submodule goes like this:
> >
> > 1. The developer does his changes locally imp
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
On Tue, Jan 14, 2014 at 09:58:30PM +0100, Heiko Voigt wrote:
> A typical workflow where a feature in a project needs some extension or
> change in a submodule goes like this:
>
> 1. The developer does his changes locally implementing everything
>needed. To commit he creates a local branch in t
On Tue, Jan 14, 2014 at 08:57:09AM -0800, W. Trevor King wrote:
> > > On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> > > > Am 09.01.2014 20:55, schrieb W. Trevor King:
> > > > > Maybe you meant "for checkout I can easily overwrite the local
> > > > > changes with the upstream branc
Hi,
On Thu, Jan 09, 2014 at 02:18:40PM -0800, W. Trevor King wrote:
> On Thu, Jan 09, 2014 at 10:40:52PM +0100, Jens Lehmann wrote:
> > Am 09.01.2014 20:55, schrieb W. Trevor King:
> > > On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote:
> > >> Am 09.01.2014 18:32, schrieb W. Trevor Kin
2014/1/8 W. Trevor King :
> I also prefer 'checkout' to 'head', because 'checkout'
> already exists in non-submodule Git for switching between local
> branches.
>
Reasons I would loosely support 'git submodule checkout'
--
2014/1/8 W. Trevor King :
> To elaborate the idea I sketched out here [2], say
> you want:
>
> Superproject branch Submodule branch Upstream branch
> === ===
> master mastermaster
> super-featuremaster
2014/1/8 W. Trevor King :
> Note that I've moved away from “submodule..branch
> set means attached” towards “we should set per-superproject-branch
> submodule..local-branch explicitly” [1].
>
Honestly, I'm having an hard time to follow this thread. Also, you
didn't update the patch. If you were en
On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
> # Attach the submodule HEAD to .
> # Also set ".git/config" 'submodule..branch' to
> $ git submodule head -b --attach
I prefer submodule..local-branch for the submodule's local
branch name. I also prefer 'checkout' to 'head',
2014/1/7 Heiko Voigt :
> One thing is missing though (and I think thats where Francesco came
> from): What if the developer already has a detached HEAD in the
> submodule?
>
> How does he attach to a branch? For this we need something similar to
> Francescos attach/detach or Trevors submodule check
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi,
here my current thoughts in a kind of summary email.
On Tue, Jan 07, 2014 at 11:45:03AM -0800, W. Trevor King wrote:
> On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
> > 2014/1/7 Junio C Hamano :
> > > It is not immediately obv
2014/1/7 Francesco Pretto :
> To not break the existing behavior what it's really needed here, IMO,
> is a "submodule..attached" property that says two things:
> - at the first clone on "git submodule update" stay attached to
> "submodule..branch";
> - implies "--remote", as it's the only thing tha
2014/1/6 Heiko Voigt :
>
> I agree. If we were to support this more easily we could add a
> configuration option so you can omit the --remote (i.e.:
> submodule..remote=true, as I also suggested in the other email).
>
> That way the developer checking out a branch in flight does not even
> need to
On Sun, Jan 05, 2014 at 05:12:56PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 04:33:14PM -0800, W. Trevor King wrote:
> > The only people who would need *automatic* rebase recovery would be
> > superproject devs update-cloning the subproject. That's a small
> > enough cross-section tha
On Sun, Jan 05, 2014 at 03:39:43PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
> > On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
> > > If submodule..branch is set, it *always* creates a new local
> > > branch of that name pointing to
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
> 2014/1/5 W. Trevor King :
> > On Sun, Jan 05, 2014 at 04:53:12AM +0100, Francesco Pretto wrote:
> >> Also it could break some users that rely on the current behavior.
> >
> > The current code always has a detached HEAD after an ini
On Sun, Jan 05, 2014 at 11:57:33PM +0100, Heiko Voigt wrote:
> On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
> > If submodule..branch is set, it *always* creates a new local
> > branch of that name pointing to the exact sha1. If
> > submodule..branch is not set, we still create a
On Sun, Jan 05, 2014 at 01:24:58PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 08:48:50PM +0100, Heiko Voigt wrote:
> > On Sun, Jan 05, 2014 at 08:17:00AM -0800, W. Trevor King wrote:
> > > It's not clear if this refers to the initial-clone update, future
> > > post-clone updates, or bot
20 matches
Mail list logo
