2014/1/16 W. Trevor King :
> Avoiding useless clones is probably more important than avoiding
> duplicate "Invalid update mode" messages.
No, it's not duplicate code. I'll explain, please follow me:
> @@ -803,17 +803,10 @@ cmd_update()
> update_module=$update
>
I've matured this opinion about "local-branch" some days ago, but I
couldn't join the discussion because I was extremely busy. Hope it's
is still current (and correct).
2014/1/9 W. Trevor King
>
> @@ -339,7 +339,19 @@ module_clone()
> echo "gitdir: $rel/$a" >"$sm_path/.git"
>
> re
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
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
>
ead" is unspecific enough to admit it can also touch
'.git/config' and '.gitmodules'.
Said this, it seems Heiko[1] proposed a similar syntax and the only
difference was about names, not behavior of the command to be added
(if we eventually take this path, ofc).
> On Wed
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
er use case for
git submodules. I would be disappointed if the complexity is reduced in a
way and augmented in another.
> On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
>> # Attach the submodule HEAD to .
>> # Also set ".git/config" 'submodule..branch'
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
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
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
>
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
2014/1/7 Junio C Hamano :
> Francesco Pretto writes:
>> The developer does it voluntarily, at his responsibility, because he
>> may decide to partecipate more actively to the development of the
>> submodule and still want to use a simple "git submodule update&quo
2014/1/7 Junio C Hamano :
> Francesco Pretto writes:
>
>> My bottom line:
>> - For what I understand, detached HEAD it's a way to say "hey, you
>> have to stay on this commit. Also don't even think you can push to the
>> upstream branch". This so
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
2014/1/7 Junio C Hamano :
> It is not about preference but what we want to convey to the
> readers. When you start the sentence with "Oh, it already works
> correctly", the readers need to see this sentence finished: "It
> already works, it is handled correctly, but we change the code
> neverthele
2014/1/7 Junio C Hamano :
> Sorry, but -ECANNOTPARSE.
>
A bird told me what -ECANNOTPARSE means. Tell me if this comment sounds better:
According to "Documentation/gitmodules.txt", 'checkout' is a valid
'submodule..update' mode. Also "git-submodule.sh" already refers
to it and handles it correctl
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 Junio C Hamano :
> Francesco Pretto writes:
>
>> According to "Documentation/gitmodules.txt", 'checkout' is a valid
>> 'submodule..update' command.
>
> As you can see in the surrounding text, we call the value of
> submodu
2014/1/7 Junio C Hamano :
> The thing is, it takes a non trivial amount of time to run through a
> single day's integration cycle, and any reroll that comes later in a
> day once the cycle started may be too late for that day. Otherwise
> I have to discard the the result of earlier merges and test
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";
2014/1/6 Junio C Hamano :
>
> - git-submodule.sh: support 'checkout' as a valid update mode
>
> Need to pick up a rerolled one.
>
I resent it, can you see it?
Thank you,
Francesco
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel
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
s during 'update' command,
issuing an error if the value found is unknown.
Signed-off-by: Francesco Pretto
---
git-submodule.sh | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/git-submodule.sh b/git-submodule.sh
index 2677f2e..4a30087 100755
--- a/git-subm
Ok, applying the suggested modifications and resending shortly.
Thank you,
Francesco
2014/1/6 Junio C Hamano :
> Junio C Hamano writes:
>
>> "W. Trevor King" writes:
>>
>>> On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
>>>
Dear Heiko, my replies below. I also take a couple excerpts from other
emails, as I prefer to not flame on different threads :) .
2014/1/6 Heiko Voigt :
> On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
>> It means he doesn't need to control other developer
2014/1/5 Heiko Voigt :
> Could you please extend the description of your use-case so we can
> understand your goal better?
>
Maybe I found better words to explain you my goal: the current git
submodule use-case threats the submodule as a project independent
dependency. My use case threats the subm
2014/1/5 Heiko Voigt :
>
> Could you please extend the description of your use-case so we can
> understand your goal better?
>
Just in case you missed the first patch iteration[1].
> The following questions directly pop into my mind:
>
> - What means the maintainer does not track the submodules
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, w
(Hmmpth, forgot signoff...)
To whom it may interest, added some CC.
2014/1/5 Francesco Pretto :
> At the current state, the following use-case is not supported very
> well in git:
> - a maintainer adds a submodule, checking out a specific branch of
> the repository. He doesn't t
Thanks for adding your contribute. My comments below:
2014/1/3 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
>
eckout $subforce -q"
+ suffix=$sha1
+ die_msg="$(eval_gettext "Unable to
checkout '\$sha1' in submodule path '\$displaypath'")"
+ say_m
According to "Documentation/gitmodules.txt", 'checkout' is a valid
'submodule..update' command. Also "git-submodule.sh" refers to
it and processes it correctly. Reflect commit 'ac1fbb' to support this
syntax and also validates property values during 'update' command,
issuing a warning if the value
2014/1/3 Francesco Pretto :
> Concluding, my point is that at the current state submodules in git
> seem to be flawed because of the inconsistent HEAD state between "add"
> and "update" users. With my patch applied the attached HEAD behavior
> would be fully support
2014/1/3 Francesco Pretto :
> Concluding, my point is that at the current state submodules in git
> seem to be flawed because of the inconsistent HEAD state between "add"
> and "update" users. With my patch applied the attached HEAD behavior
> would be fully support
2014/1/2 Junio C Hamano :
> Francesco Pretto writes:
>
>> by default "git submodule" performs its add or update operations on a
>> detached
>> HEAD. This works well when using an existing full-fledged/indipendent
>> project as
>> the submodule,
; = "HEAD"
then
head_detached="true"
fi
Is this correct?
2013/12/31 Phil Hord
>
> On Sun, Dec 29, 2013 at 8:49 PM, Francesco Pretto wrote:
> [...]
> >
> > When updating, using the '--attach' switch or operating in a repository with
> >
not one of the supported
values 'checkout', 'merge', 'rebase' and 'none'. Please note that 'checkout'
update command was documented in upstream "Documentation/gitmodules.txt" [2] as
a valid 'submodule..update' value and code in upst
37 matches
Mail list logo
