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 King:
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
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 branch, which is what
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 the
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 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
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 of
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 well,
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 branch
2014/1/14 Heiko Voigt hvo...@hvoigt.net:
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
Am 09.01.2014 02:09, schrieb Francesco Pretto:
2014/1/9 W. Trevor King wk...@tremily.us:
However, submodule.name.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]
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 wk...@tremily.us:
However, submodule.name.local-branch has nothing to do with remote
repositories or tracking branches.
My bad: this means the feature
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 wk...@tremily.us:
However, submodule.name.local-branch has nothing to do with remote
repositories or tracking
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 my
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 well. I
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-submodule and
2014/1/8 W. Trevor King wk...@tremily.us:
To elaborate the idea I sketched out here [2], say
you want:
Superproject branch Submodule branch Upstream branch
=== ===
master mastermaster
super-feature
2014/1/8 W. Trevor King wk...@tremily.us:
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'
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.name.local-branch' now. Do
we have a similar mechanism
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
2014/1/9 W. Trevor King wk...@tremily.us:
However, submodule.name.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 =
On Thu, Jan 09, 2014 at 02:09:37AM +0100, Francesco Pretto wrote:
2014/1/9 W. Trevor King wk...@tremily.us:
[branch my-feature]
remote = origin
merge = refs/heads/my-feature
[submodule submod]
local-branch = my-feature
and I don't think Git's
Francesco Pretto cez...@gmail.com writes:
2014/1/7 Francesco Pretto cez...@gmail.com:
To not break the existing behavior what it's really needed here, IMO,
is a submodule.name.attached property that says two things:
- at the first clone on git submodule update stay attached to
W. Trevor King wk...@tremily.us writes:
From: W. Trevor King wk...@tremily.us
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
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 cloned,
2014/1/7 Junio C Hamano gits...@pobox.com:
Unless you decide to go with the proposed approach of Trevor, where
submodule.name.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
W. Trevor King wk...@tremily.us 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
On Tue, Jan 07, 2014 at 08:19:49PM +0100, Francesco Pretto wrote:
2014/1/7 Junio C Hamano gits...@pobox.com:
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
2014/1/7 W. Trevor King wk...@tremily.us:
Junio, for what it concerns me I fully support this patch as, IMO, it
makes cleaner the role of the property submodule.name.branch.
No.
Trevor, maybe it was not clear. But I wanted to say:
I fully support *Trevor's* patch... :)
--
To unsubscribe
On Tue, Jan 07, 2014 at 11:21:28AM -0800, Junio C Hamano wrote:
W. Trevor King wk...@tremily.us 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
2014/1/7 Francesco Pretto cez...@gmail.com:
2014/1/7 Junio C Hamano gits...@pobox.com:
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,
On Tue, Jan 07, 2014 at 09:09:19PM +0100, Francesco Pretto wrote:
2014/1/7 W. Trevor King wk...@tremily.us:
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 W. Trevor King wk...@tremily.us:
I'd be happy to hear ideas about superproject-branch-specific local
overrides to a hypothetical submodule.name.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
2014/1/7 Heiko Voigt hvo...@hvoigt.net:
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
On Wed, Jan 08, 2014 at 01:17:49AM +0100, Francesco Pretto wrote:
# Attach the submodule HEAD to branch.
# Also set .git/config 'submodule.module.branch' to branch
$ git submodule head -b branch --attach module
I prefer submodule.name.local-branch for the submodule's local
branch name. I also
2014/1/8 W. Trevor King wk...@tremily.us:
Note that I've moved away from “submodule.name.branch
set means attached” towards “we should set per-superproject-branch
submodule.name.local-branch explicitly” [1].
Honestly, I'm having an hard time to follow this thread. Also, you
didn't update the
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
2014/1/5 W. Trevor King wk...@tremily.us:
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
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.name.branch is set, it *always* creates a new local
branch of that name pointing to the
Heiko Voigt hvo...@hvoigt.net writes:
On Sun, Jan 05, 2014 at 10:27:19PM +0100, Francesco Pretto wrote:
2014/1/5 W. Trevor King wk...@tremily.us:
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
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, perhaps
On Mon, Jan 06, 2014 at 08:56:22AM -0800, Junio C Hamano wrote:
Heiko Voigt hvo...@hvoigt.net 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
W. Trevor King wk...@tremily.us 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
2014/1/6 Heiko Voigt hvo...@hvoigt.net:
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.name.remote=true, as I also suggested in the other email).
That way the developer checking out a branch in flight does not
2014/1/7 Francesco Pretto cez...@gmail.com:
To not break the existing behavior what it's really needed here, IMO,
is a submodule.name.attached property that says two things:
- at the first clone on git submodule update stay attached to
submodule.name.branch;
- implies --remote, as it's the
2014/1/6 Junio C Hamano gits...@pobox.com:
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
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-clone
2014/1/5 W. Trevor King wk...@tremily.us:
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.name.update, which
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.name.branch if
submodule.name.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
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 both.
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.name.branch is set, it *always* creates a new local
branch of that name pointing to the exact sha1. If
submodule.name.branch is not set, we still create
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
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
52 matches
Mail list logo
