On Tue, Jan 07, 2014 at 11:51:28PM +0100, Heiko Voigt wrote:
> On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
> > Here's an attempted summary of our desires, and my ideal route
> > forward:
> >
> > * Preferred local submodule branches for each superproject branch.
> > * Not curr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, Jan 06, 2014 at 08:10:04PM -0800, W. Trevor King wrote:
> Here's an attempted summary of our desires, and my ideal route
> forward:
>
> * Preferred local submodule branches for each superproject branch.
> * Not currently supported by Git.
>
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" to
>> updates his submodules, overrid
On Mon, Jan 06, 2014 at 08:21:24PM +0100, David Engster wrote:
> +---+
> | master | <--
> +---++---+| Merges to/from master
> | CEDET | | done only by CEDET developers
> +---+ |
> +---
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 sometimes can't be spurious, as in the use case
>> I w
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 sometimes can't be spurious, as in the use case
> I wrote above: access control on the
Francesco Pretto writes:
>>> > - In which situations does the developer or maintainer switch between
>>> >your attached/detached mode?
>>>
>>> The developer/maintainer does so optionally and voluntarily and it
>>> effects only its private working tree.
>>
>> This does not answer my question.
On Mon, Jan 06, 2014 at 06:47:58PM +0100, Francesco Pretto wrote:
> I'm really sorry, I thought this was already clear from the first
> patch iteration. I will go more in depth:
For me anyway, this extra detail is very helpful. Thanks :).
> Maintainer of "project1" also prepares a branch
> "proj
Francesco Pretto writes:
> 2014/1/6 Heiko Voigt :
>> Could you describe something like this for your workflow? A complete
>> change lifecycle when a developer works, as you call it, "actively" in a
>> submodule?
>>
>
> I'm really sorry, I thought this was already clear from the first
> patch iterat
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 developers commit to be
>> check
On Mon, Jan 06, 2014 at 03:18:05PM +0100, Heiko Voigt wrote:
> If you simply want to always checkout the development tip of some
> project you could do something like this:
>
> git submodule foreach 'git fetch && git checkout origin/master'
Or (respecting submodule..branch):
$ git submod
On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote:
> 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
On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
> 2014/1/5 Heiko Voigt :
> > The following questions directly pop into my mind:
> >
> > - What means the maintainer does not track the submodules sha1? Does
> >that mean the superproject always refers to submodule commits using
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
On Sun, Jan 05, 2014 at 03:50:49AM +0100, Francesco Pretto wrote:
> 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 track the upstream submodule revision sha1;
> - a d
(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 track the upstream
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 track the upstream submodule revision sha1;
- a developer checkout the repository branch decided by the maintainer.
Subsequen
18 matches
Mail list logo
