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 11:19:07PM +0100, Heiko Voigt wrote:
> On Tue, Jan 14, 2014 at 01:42:09PM -0800, W. Trevor King wrote:
> > The “gitlinked commits must be in the subproject's master” rule
> > protects you from blowing stuff away here. You could use rebase- or
> > merge-style integration as
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 branch in a submodule. How about we finish
> discussing the exact solution
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
On Tue, Jan 14, 2014 at 11:24:45AM +0100, Heiko Voigt wrote:
> On Thu, Jan 09, 2014 at 02:18:40PM -0800, W. Trevor King wrote:
> > Users who are worried about loosing local updates should not be
> > using a checkout-style updates. If they are using a
> > checkout-style update, and they ask for an
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
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 King:
> >>> However, the local-branch setting needs to be both
> >>> per-submod
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 King:
>>> However, the local-branch setting needs to be both
>>> per-submodule and per-superproject-branch, so .git/config doesn't work
>>> very we
On Thu, Jan 09, 2014 at 08:23:07PM +0100, Jens Lehmann wrote:
> Am 09.01.2014 18:32, schrieb W. Trevor King:
> > However, the local-branch setting needs to be both
> > per-submodule and per-superproject-branch, so .git/config doesn't work
> > very well. I think it's better to use something like m
Am 09.01.2014 18:32, schrieb W. Trevor King:
> On Thu, Jan 09, 2014 at 09:31:13AM +0100, Jens Lehmann wrote:
>> Am 09.01.2014 02:09, schrieb Francesco Pretto:
>>> 2014/1/9 W. Trevor King :
However, submodule..local-branch has nothing to do with remote
repositories or tracking branche
On Thu, Jan 09, 2014 at 09:31:13AM +0100, Jens Lehmann wrote:
> Am 09.01.2014 02:09, schrieb Francesco Pretto:
> > 2014/1/9 W. Trevor King :
> >>
> >> However, submodule..local-branch has nothing to do with remote
> >> repositories or tracking branches.
> >
> > My bad: this means the feature is st
Am 09.01.2014 02:09, schrieb Francesco Pretto:
> 2014/1/9 W. Trevor King :
>>
>> However, submodule..local-branch has nothing to do with remote
>> repositories or tracking branches.
>
> My bad: this means the feature is still not entirely clear to me.
>
>>
>> [branch "my-feature"]
>> re
On Thu, Jan 09, 2014 at 02:09:37AM +0100, Francesco Pretto wrote:
> 2014/1/9 W. Trevor King :
> > [branch "my-feature"]
> > remote = origin
> > merge = refs/heads/my-feature
> > [submodule "submod"]
> > local-branch = "my-feature"
> >
> > and I don't think Git'
2014/1/9 W. Trevor King :
>
> However, submodule..local-branch has nothing to do with remote
> repositories or tracking branches.
My bad: this means the feature is still not entirely clear to me.
>
> [branch "my-feature"]
> remote = origin
> merge = refs/heads/my-feature
>
On Thu, Jan 09, 2014 at 12:54:54AM +0100, Francesco Pretto wrote:
> 2) Having 'git checkout', 'git checkout --recurse-submodules' and
> finally 'git submodule checkout' is too much for me.
Agreed. Since 'git checkout' already exists and 'git checkout
--recurse-submodules' is close [1,2], I think
On Thu, Jan 09, 2014 at 12:07:56AM +0100, Francesco Pretto wrote:
> After long thoughts, I think your idea about a local branch with a
> differently named remote branch looks interesting but I would be
> extremely cautious to add a ' submodule..local-branch' now. Do
> we have a similar mechanism on
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 W. Trevor King :
>
> I'd be happy to hear ideas about superproject-branch-specific local
> overrides to a hypothetical submodule..local-branch, in the
> event that a developer doesn't like a default set in .gitmodules. If
> I could think of a way to do that, we could avoid this heuristic
On Tue, Jan 07, 2014 at 09:09:19PM +0100, Francesco Pretto wrote:
> 2014/1/7 W. Trevor King :
> >> Trevor, maybe it was not clear. But I wanted to say:
> >>
> >> " I fully support *Trevor's* patch..." :)
> >
> > Which I appreciate ;). I still though I should point out that my
> > patch *confuses*
2014/1/7 Francesco Pretto :
> 2014/1/7 Junio C Hamano :
>> It is not immediately obvious to me why anybody who specifies the
>> submodule.*.branch variable to say "I want _that_ branch" not to
>> want to be on that branch but in a detached state, so from that
>> perspective, submodule.*.attach feel
On Tue, Jan 07, 2014 at 11:21:28AM -0800, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
> >> Having writing all the above and then looking at the patch again, it
> >> is not immediately obvious to me where you use "rebase" when
2014/1/7 W. Trevor King :
>> Junio, for what it concerns me I fully support this patch as, IMO, it
>> makes cleaner the role of the property "submodule..branch".
>
> No.
Trevor, maybe it was not clear. But I wanted to say:
" I fully support *Trevor's* patch..." :)
--
To unsubscribe from this list
On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
> 2014/1/7 Junio C Hamano :
> > It is not immediately obvious to me why anybody who specifies the
> > submodule.*.branch variable to say "I want _that_ branch" not to
> > want to be on that branch but in a detached state, so from tha
"W. Trevor King" writes:
> On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
>> submodule: respect requested branch on all clones
>>
>> The previous code only checked out the requested branch in cmd_add
>> but not in cmd_update; this left the user on a detached HEAD aft
2014/1/7 Junio C Hamano :
>> Unless you decide to go with the proposed approach of Trevor, where
>> "submodule..branch" set means attached (if it's not changed:
>> this thread is quite hard to follow...). To this end, Junio could sync
>> with more "long-timers" (Heiko?) submodule users/devs to unde
On Tue, Jan 07, 2014 at 10:15:25AM -0800, Junio C Hamano wrote:
> submodule: respect requested branch on all clones
>
> The previous code only checked out the requested branch in cmd_add
> but not in cmd_update; this left the user on a detached HEAD after
> an update initially clon
Francesco Pretto writes:
> 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 "--r
"W. Trevor King" writes:
> From: "W. Trevor King"
>
> The previous code only checked out the requested branch in cmd_add.
> This commit moves the branch-checkout logic into module_clone, where
> it can be shared by cmd_add and cmd_update. I also update the initial
> checkout command to use 'reb
2014/1/6 Junio C Hamano :
>
> As long as origin/master contains the commit specified by the
> superproject, that would work, but it may be a good thing to use a
> mode of submodule.*.update that does not have to drop the user into
> a detached state in the first place. I somehow thought that was
>
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
"W. Trevor King" writes:
>> And wouldn't it make it unnecessary to have a new "re-attach" option
>> if such a mode that never have to detach is used?
>
> I think so, but we currently don't have a "never detached" route for
> folks that are cloning submodules via update (instead of via
> 'submodul
On Mon, Jan 06, 2014 at 08:56:22AM -0800, Junio C Hamano wrote:
> Heiko Voigt writes:
> > Yes, why would you do a git pull in a submodule? Don't you want to do
> > something like
> >
> > git checkout -t -b dev/my-topic origin/master
> >
> > to start your development?
>
> As long as origin/mas
On Mon, Jan 06, 2014 at 04:47:39PM +0100, Heiko Voigt wrote:
> 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:
> > > > Thinking through this more, p
Heiko Voigt writes:
> 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
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 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 that I don't think it deserves the ambiguity of
> gitlink-to-reference. In
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:
> > The reason why one would set a branch option here is to share the
> > superproject branch with colleagues. He can make sure they can
> > always fetch and checkout the s
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
On Sun, Jan 05, 2014 at 01:47:52PM -0800, W. Trevor King wrote:
> On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
> > 2014/1/5 W. Trevor King:
> > Also it covers:
> > - an "autoremote" behavior when the user wants an attached HEAD:
> > with your patch "--remote" is still needed to
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
> 2014/1/5 W. Trevor King:
> > Adding a check to only checkout submodule..branch if
> > submodule..update was 'rebase', 'merge', or 'none' would be
> > easy, but I don't think that makes much sense. I can't see any
> > reason for fo
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 initial-clone
> update, regardless of submodule..update, which doesn't match
>
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 both. Ideally, the behavior should be the
> > same, but in the initial-clo
On Sun, Jan 05, 2014 at 08:17:00AM -0800, W. Trevor King wrote:
> From: "W. Trevor King"
>
> The previous code only checked out the requested branch in cmd_add.
> This commit moves the branch-checkout logic into module_clone, where
> it can be shared by cmd_add and cmd_update. I also update the
56 matches
Mail list logo
