Francesco Pretto cez...@gmail.com 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. I
Francesco Pretto cez...@gmail.com 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
2014/1/7 Junio C Hamano gits...@pobox.com:
Francesco Pretto cez...@gmail.com 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
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 gits...@pobox.com:
Francesco Pretto cez...@gmail.com 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
-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.
*
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 currently
On Sun, Jan 05, 2014 at 10:46:11PM +0100, Francesco Pretto wrote:
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
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
On Mon, Jan 06, 2014 at 12:22:23AM +0100, Francesco Pretto wrote:
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
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
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.name.branch):
$ git
(Hmmpth, forgot signoff...)
To whom it may interest, added some CC.
2014/1/5 Francesco Pretto cez...@gmail.com:
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
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
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
2014/1/5 Heiko Voigt hvo...@hvoigt.net:
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
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.
14 matches
Mail list logo
