stic pull is likely to succeed, suggesting it is
easier to explain to Git newbies than a FETCH_HEAD merge.
Signed-off-by: W. Trevor King
---
Documentation/git-merge.txt | 8
Documentation/merge-options.txt | 10 ++
builtin/pull.c
On Thu, Oct 12, 2017 at 10:17:51AM +0900, Junio C Hamano wrote:
> "W. Trevor King" writes:
>
> > Following 09c2cb87 (pull: pass --allow-unrelated-histories to "git
> > merge", 2016-03-18) with the tests also drawing on 14d01b4f (merge:
> > add a --sig
On Thu, Oct 12, 2017 at 02:42:30PM +0900, Junio C Hamano wrote:
> "W. Trevor King" writes:
> > On Thu, Oct 12, 2017 at 10:17:51AM +0900, Junio C Hamano wrote:
> >> "W. Trevor King" writes:
> >>
> >> > Following 09c2cb87 (pull: pass --
t as somewhat alphabetized and
having an "add to the commit message" function like --log.
Helped-by: Junio C Hamano
Signed-off-by: W. Trevor King
---
Changes since v1 [1]:
* Dropped "Following" paragraph. Junio took issue with the phrasing
[2], and the implementation in v2
Pull has supported these since ea230d8 (pull: add the --gpg-sign
option, 2014-02-10). Insert in long-option alphabetical order
following 7c85d274 (Documentation/merge-options.txt: order options in
alphabetical groups, 2009-10-22).
Signed-off-by: W. Trevor King
---
This patch is based on maint
On Thu, Oct 12, 2017 at 01:46:39AM -0700, W. Trevor King wrote:
> The order of options in merge-options.txt isn't clear to me, but
> I've put --signoff between --log and --stat as somewhat alphabetized
> and having an "add to the commit message" function like --log.
The long-option bit
didn't make it into the commit message, but it's under the fold in
[1]. I've put --signoff between --log and --stat to preserve the
alphabetical order.
[1]: https://public-inbox.org/git/87iqe7zspn@jondo.cante.net/
Helped-by: Junio C Hamano
Signed-of
On Thu, Mar 27, 2014 at 03:21:49PM +0100, Johan Herland wrote:
> I just found a failure to checkout a project with submodules where
> there is no explicit submodule branch configuration, and the
> submodules happen to not have a "master" branch:
The docs say [1]:
A remote branch name for tracki
On Thu, Mar 27, 2014 at 08:52:08AM -0700, W. Trevor King wrote:
> Working around that to default to the upstream submodule's HEAD is
> possible (you can just use --branch HEAD)
Actually, this is probably not a good idea. The initial submodule
addition works:
$ git submodule add -
On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote:
> Am 27.03.2014 18:16, schrieb Junio C Hamano:
> > Johan Herland writes:
> >
> >> I just found a failure to checkout a project with submodules where
> >> there is no explicit submodule branch configuration, and the
> >> submodules happ
I'm breaking this off into a sub-thread, so it doesn't distract from
the main issue.
On Thu, Mar 27, 2014 at 12:39:03PM -0700, Junio C Hamano wrote:
> There is this bit for "update" in git-submodule.txt:
>
> For updates that clone missing submodules, checkout-mode updates
> will create submod
submodule..branch.
Reported-by: Junio C Hamano
Signed-off-by: W. Trevor King
---
This patch is against master, because 23d25e48 hasn't landed in maint
yet. If you want, I can split this into two patches, one against
maint fixing the b9289227 typo and another against master fixing th
On Fri, Mar 28, 2014 at 12:15:00AM +0100, Jens Lehmann wrote:
> Am 27.03.2014 22:06, schrieb W. Trevor King:
> > The transition from submodule..* to submodule..* happened
> > in 73b0898d (Teach "git submodule add" the --name option, 2012-09-30),
> > which lan
On Thu, Mar 27, 2014 at 11:55:21PM +0100, Jens Lehmann wrote:
> Me thinks that when a superproject doesn't have 'branch' configured
> and does set 'update' to something other than 'checkout' for a
> submodule it should better make sure 'master' is a valid branch in
> there. Everything else sounds l
On Fri, Mar 28, 2014 at 12:21:23AM +0100, Johan Herland wrote:
> On Thu, Mar 27, 2014 at 9:27 PM, Heiko Voigt wrote:
> > On Thu, Mar 27, 2014 at 12:39:03PM -0700, Junio C Hamano wrote:
> >> There is this bit for "update" in git-submodule.txt:
> >>
> >> For updates that clone missing submodules, c
nd get along just fine without
submodule..branch. Remote updates do need a remote branch, but
HEAD works as well here as it did for the initial clone.
Reported-by: Johan Herland
Signed-off-by: W. Trevor King
---
This still needs tests, but it gets through the following fine:
rm -rf superproject s
On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote:
> On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wrote:
> > submodule..branch::
> > A remote branch name for tracking updates in the upstream submodule.
> > - If the option is not specified, i
On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote:
> On Thu, Mar 27, 2014 at 11:43:47PM -0400, Eric Sunshine wrote:
> > On Thu, Mar 27, 2014 at 11:36 PM, W. Trevor King wrote:
> > > submodule..branch::
> > > A remote branch name for track
On Fri, Mar 28, 2014 at 05:55:18PM +0100, Jens Lehmann wrote:
> I just noticed that the two patches Junio added to pu have a
> reworded commit message I'm perfectly happy with.
The revised wording works for me too.
Cheers,
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.g
On Fri, Mar 28, 2014 at 05:57:50PM +0100, Jens Lehmann wrote:
> Am 28.03.2014 04:58, schrieb W. Trevor King:
> > On Thu, Mar 27, 2014 at 08:52:55PM -0700, W. Trevor King wrote:
> >> No the remote branch is in the upstream subproject. I suppose I meant
> >> “the submodu
On Mon, Mar 31, 2014 at 09:35:07PM +0200, Jens Lehmann wrote:
> Am 28.03.2014 04:36, schrieb W. Trevor King:
> > The main drawback to this approach is that we're changing a default,
> > but I agree with John's:
> >
> > On Fri, Mar 28, 2014 at 12:21:23AM +010
On Wed, Apr 16, 2014 at 02:54:48AM +0200, Johan Herland wrote:
> This is a work-in-progress to flesh out (and promote discussion about)
> the expected behaviors for all possible scenarios in which
> 'git submodule update' might be run.
This is lovely :).
> +# - current state of submodule:
> +#
allowed) [1], but I
imagine there are folks who would resist ;). Maybe a deprecation
period to help ease the transition? This is all assuming that I get
more folks to buy into the tight-syncing ;).
The end-goal of my tightly-bound approach is to remove 'submodule
update' altogethe
On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote:
> *) When a submodule is replaced with a tracked file of the same name
>the submodule work tree including any local modifications (and
>even the whole history if it uses a .git directory instead of a
>gitfile!) is simply remo
On Fri, Apr 11, 2014 at 03:22:58PM -0700, Junio C Hamano wrote:
> * jl/submodule-recursive-checkout (2013-12-26) 5 commits
> - Teach checkout to recursively checkout submodules
> - submodule: teach unpack_trees() to update submodules
> - submodule: teach unpack_trees() to repopulate submodules
>
On Thu, Apr 17, 2014 at 11:08:06PM +0200, Jens Lehmann wrote:
> Am 17.04.2014 18:41, schrieb W. Trevor King:
> > On Tue, Mar 25, 2014 at 06:05:05PM +0100, Jens Lehmann wrote:
> >> *) When a submodule is replaced with a tracked file of the same name
> >>the submod
githooks(5) suggests:
Information about why the push is rejected may be sent to the user
by writing to standard error.
So follow that advice in the sample.
Signed-off-by: W. Trevor King
---
templates/hooks--pre-push.sample | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
And explain how it interacts with the scissors setting.
Signed-off-by: W. Trevor King
---
The three-dash limit comes from f0658cf2 (restrict the patch
filtering, 2007-03-12), but I couldn't find any associated
documentation. Since the effect is so similar to the scissors line, I
thought
On Tue, Sep 30, 2014 at 01:23:18PM -0700, Junio C Hamano wrote:
> Here are the topics that have been cooking.
It looks like my boring git-mailinfo doc patch [1] fell through the
cracks here ;). Or maybe it's just cooking a bit longer before
getting queued?
Cheers,
Trevor
[1]: Gmane: http://arti
On Tue, Sep 30, 2014 at 02:12:58PM -0700, Junio C Hamano wrote:
> If we are extending the documentation on "---", …
Ah, I see that the --- are actually mentioned already in the
DISCUSSION section of git-am(1) since 2499857b (git-am documentation:
describe what is taken from where, 2007-03-24). I
x27;t
expect compatibility issues.
[1]: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/id.html
Signed-off-by: W. Trevor King
---
The patch is based on the current maint branch.
Previous LOGNAME discussion:
* Michael Gruber on 2011-05-06 suggesting a discussing a whoami
fallback [1] (but
On Sun, Oct 19, 2014 at 03:49:36PM -0700, Junio C Hamano wrote:
> I'll queue this as-is, but it makes me wonder if we want to do this
> without if/then/fi, e.g.
>
> : ${LOGNAME:=${USER:-$(id -u -n)}
I'm fine with that too.
> Spelling everything out with if/then/fi is obviously at the other
On Thu, Oct 30, 2014 at 06:39:56PM +0300, Dmitry Oksenchuk wrote:
> We're in the middle of conversion of a large CVS repository (20
> years, 70K commits, 1K branches, 10K tags) to Git and considering
> two separate Git repositories: "historical" with CVS history and
> "working" created without hist
On Mon, Apr 21, 2014 at 05:38:34PM -0700, Luis R. Rodriguez wrote:
> [0] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.5| grep
> ^commit | wc -l
> 24878
> [1] mcgrof@ergon ~/linux (git::master)$ git log c5905afb..v3.4| grep
> ^commit | wc -l
> 13106
> [2] mcgrof@ergon ~/linux (git::maste
On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
> On 14-05-01 05:46 AM, brian m. carlson wrote:
> > git checkout maintenance-branch
> > # Update our maintenance branch to the latest from the main repo.
> > git pull --ff-only
> > git pull --no-ff developer-remote topic-branch
On Thu, May 01, 2014 at 02:16:50PM -0500, Felipe Contreras wrote:
> The only problem would be when it's not desirable, however, that's a
> problem of the user's ignorance, and the failure of the project's
> policity to communicate clearly to him that he should be running
> `git merge --no-ff`. Ther
On Thu, May 01, 2014 at 02:04:33PM -0400, Marc Branchaud wrote:
> On 14-05-01 01:56 PM, W. Trevor King wrote:
> > On Thu, May 01, 2014 at 11:20:44AM -0400, Marc Branchaud wrote:
> >> On 14-05-01 05:46 AM, brian m. carlson wrote:
> >>> git checkout maintenan
On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
> My interest in all of the proposed git-pull-training-wheel patches is
> that they give users a way to set a finger-breaking configuration that
> makes pull a no-op (or slows it down, like 'rm -i …'). Then folks
On Thu, May 01, 2014 at 06:34:06PM -0500, Felipe Contreras wrote:
> Nobody ever complained about somebody doing a fast-forward by mistake.
Unless they fast-forward merged a feature branch into master, but the
project prefers explicitly-merged feature branches with a cover-letter
explaination in th
On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Thu, May 01, 2014 at 12:48:46PM -0700, W. Trevor King wrote:
> > > My interest in all of the proposed git-pull-training-wheel patches is
> > > that they give users a w
On Thu, May 01, 2014 at 07:37:04PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Thu, May 01, 2014 at 06:25:16PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > Fast-forward $current_branch by $count commits to $repository
> >
On Thu, May 01, 2014 at 07:00:02PM -0500, Felipe Contreras wrote:
> Also 'branch..rebase' to 'branch..pullmode'.
Perhaps this has already been hashed out in a previous version of this
series, but we may want to use pull.update and branch..update to
match the existing submodule..update. Both setti
On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > My proposed --prompt behavior is for folks who think “I often run
> > this command without thinking it through all the way. I'm also
> > not used to reading Git's output an
On Thu, May 01, 2014 at 07:00:06PM -0500, Felipe Contreras wrote:
> It is very typical for Git newcomers to inadvertently create merges and
> worst; inadvertently pushing them. This is one of the reasons many
> experienced users prefer to avoid 'git pull', and recommend newcomers to
> avoid it as w
On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > My proposed --prompt behavior is for folks who think “I often ru
On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote [1]:
> > On Fri, May 02, 2014 at 01:55:36PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > On Thu, May 01, 2014 at 08:14:29PM -0500, Felipe Contreras wrote:
On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
> > > It would matter almost exactly zero.
> >
> > Some folks have explicit merge policies, and decidin
On Fri, May 02, 2014 at 04:18:57PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > On Fri, May 02, 2014 at 03:34:34PM -0500, Felipe Contreras wrote:
> > > W. Trevor King wrote:
> > > > On Fri, May 02, 2014 at 02:13:25PM -0500, Felipe Contreras wrote:
&g
On Fri, May 02, 2014 at 05:20:11PM -0500, Felipe Contreras wrote:
> W. Trevor King wrote:
> > > > The 'git pull' (with 'none' mode) explainer just helps retrain folks
> > > > that are already using the current 'git pull' incorrec
the topic at
> hand.
I'm trying to motivate a way to slow/disable 'git pull', which I see
as orthogonal to your push to change the default configuration. I
thought describing my workflow in more detail would help clarify why…
> W. Trevor King wrote:
> > On Fri, May 02, 20
On Fri, May 09, 2014 at 02:44:02AM -0500, William Giokas wrote:
> Maybe a time to use something like::
>
> from mercurial import foo \
> bar \
> baz \
> ...
>
> Would make that import into quite a few lines, but would help
pushremote.
Signed-off-by: W. Trevor King
---
Documentation/revisions.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 5a286d0..0796118 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.tx
On Thu, Jun 05, 2014 at 09:03:25AM -0500, Robert Dailey wrote:
> When I work on a feature, I normally create a feature branch. If I
> happen to make changes to the submodule that only work with the
> changes introduced in my feature branch, that seems to complicate
> things. For the purposes of the
On Thu, Jun 05, 2014 at 10:57:17AM -0500, Robert Dailey wrote:
> I was planning on creating a submodule for our third party libs and
> store them extracted in there.
3rd party libraries sound loosely-coupled to me ;). In one of my more
mature projects I did a similar thing, and just used relative
On Thu, Jun 05, 2014 at 08:07:50AM +0200, Heiko Voigt wrote:
> +The caller can look up information about submodules by using the
> +`submodule_from_path()` or `submodule_from_name()` functions.
That's for an already-known submodule. Do we need a way to list
submodules (e.g. for 'submodule foreach
On Thu, Jun 05, 2014 at 11:18:28AM -0700, Junio C Hamano wrote:
> Jens Lehmann writes:
> > We had two settings in mind,...
> > So what if clone would just do an "git submodule init" for now when
> > "submodule.autoinit" is set but "submodule.autoupdate" isn't [?]
> > ... and a single "submodule.au
On Thu, Jun 05, 2014 at 01:31:39PM -0500, Robert Dailey wrote:
> On Thu, Jun 5, 2014 at 11:23 AM, W. Trevor King wrote:
> > 3rd party libraries sound loosely-coupled to me ;). In one of my more
> > mature projects I did a similar thing, and just used relative URLs [1]
> >
On Thu, Jun 05, 2014 at 12:00:33PM -0700, W. Trevor King wrote:
> On Thu, Jun 05, 2014 at 01:31:39PM -0500, Robert Dailey wrote:
> > Instead of just creating my branch and starting to make commits, I
> > now have to setup my submodule branch first. Also pull requests
> > won&
On Mon, Jun 09, 2014 at 03:17:07PM +0200, Jens Lehmann wrote:
> And by the way: wouldn't it make more sense to tell the user /what/
> we do automatically? So maybe 'submodule.autoupdate' is a better
> name for the new switch?
Or autocheckout? No need to preserve submodule-specific jargon when
we
On Thu, Jun 12, 2014 at 06:05:10PM +0200, Charles Brossollet wrote:
> The two problems I'm pointing are:
>
> 1. After checkout of a branch that tracks /user/main repo, call git
>init submodule motors. Git registers it in .git/config with URL
>/user/sub, while it should be /central/sub acco
On Wed, Dec 11, 2013 at 11:26:17PM +0100, Jens Lehmann wrote:
> Am 10.12.2013 00:40, schrieb Junio C Hamano:
> > Heiko Voigt writes:
> >> This notion has changed in a way that only the url (by that the
> >> name) should be copied on init. The default for everything else
> >> should come from .gitm
On Thu, Dec 12, 2013 at 07:57:51PM +0100, Jens Lehmann wrote:
> Am 12.12.2013 02:16, schrieb Junio C Hamano:
> > I think the solution we want is to copy only minimum to the config
> > (and that "minimum" may turn out to be "nothing"), and to default
> > keys that are only absolutely safe to .gitmod
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 'rebase' to pre
From: "W. Trevor King"
Before this commit, all the settings fell under the initial "Each
submodule section also contains the following required keys:". The
example shows sections with just 'update' and 'url' entries, but we
should still make the requir
On Sat, Jan 04, 2014 at 11:09:15PM +0100, Heiko Voigt wrote:
> On Fri, Jan 03, 2014 at 10:06:11AM -0800, W. Trevor King wrote:
> > @@ -306,7 +307,14 @@ module_clone()
> > echo "gitdir: $rel/$a" >"$sm_path/.git"
> >
>
On Sat, Jan 04, 2014 at 11:17:54PM +0100, Heiko Voigt wrote:
> On Fri, Jan 03, 2014 at 10:31:22AM -0800, W. Trevor King wrote:
> > Before this commit, all the settings fell under the initial "Each
> > submodule section also contains the following required keys:". The
&
On Sun, Jan 05, 2014 at 01:39:22AM +0100, Heiko Voigt wrote:
> On Sat, Jan 04, 2014 at 02:54:01PM -0800, W. Trevor King wrote:
> > On Sat, Jan 04, 2014 at 11:09:15PM +0100, Heiko Voigt wrote:
> > > On Fri, Jan 03, 2014 at 10:06:11AM -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 initial
checkout command to use 'rebase' to pre
On Sun, Jan 05, 2014 at 03:50:48AM +0100, Francesco Pretto wrote:
> + case "$update_module" in
> + '')
> + ;; # Unset update mode
> + checkout | rebase | merge | none)
> + ;; # Known
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
> >
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 thin
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
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
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 f
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
>
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 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:
> > > &
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 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
ugh.
It's used to shift the local branch reference from from the
(arbitrary) cloned remote branch tip to the explicit submodule $sha1.
Otherwise the default method for that operation is a HEAD-detaching
'checkout'. I tried to explain it here [3].
> "W. Trevor King" w
On Mon, Jan 06, 2014 at 08:21:24PM +0100, David Engster wrote:
> +---+
> | master | <--
> +---++---+| Merges to/from master
> | CEDET | | done only by CEDET developers
> +---+ |
> +---
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
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 immediatel
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 st
On Tue, Jan 07, 2014 at 10:51:34PM +0100, Francesco Pretto wrote:
> 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 develop
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
On Tue, Jan 07, 2014 at 02:36:25PM -0800, W. Trevor King wrote:
> There are three branches that submodule folks usually care about:
>
> 1. The linked $sha1 in the superproject (set explicitly for every
>superproject commit, and thus for every superproject branch).
> 2. The
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',
On Wed, Jan 08, 2014 at 03:12:44AM +0100, Francesco Pretto wrote:
> 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].
>
&
On Tue, Jan 07, 2014 at 07:47:08PM -0800, W. Trevor King wrote:
> #git checkout --recurse-submodules master
> ( # 'git checkout --recurse-submodules' doesn't exist yet [2,3].
> # Even with that patch, 'git checkout' won't respect
> # su
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
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 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"]
> >
From: "W. Trevor King"
In another branch of the submodule thread Francesco kicked off, I
mentioned that we could store the preferred local submodule branch on
a per-superbranch level if we used the
.git/modules//config for local overrides [1]. Here's
a patch series that greatl
From: "W. Trevor King"
This patch teaches 'git submodule add' to look for a preferred
local-branch, and to checkout that branch after the initial clone.
The local branch will always point at the commit checked out by the
internal 'git clone' operation. For examp
From: "W. Trevor King"
There are three branches that submodule folks usually care about:
1. The linked $sha1 in the superproject (set explicitly for every
superproject commit, and thus for every superproject branch).
2. The remote-tracking submodule..branch that tracks a
From: "W. Trevor King"
This borrows a good deal of the cmd_foreach logic to iterate through
submodules (potentially recursively), checking out the preferred local
branch for each submodule (as appropriate for the current superproject
branch). Ideally, this logic would be bundle
From: "W. Trevor King"
There's no sense in setting up a local branch if we're just going to
go back to a detached HEAD with every checkout-mode update. This
commit replaces the checkout with a reset, updating whatever the
locally checked out branch (or detached HEAD) happens
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.
> &
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'
1 - 100 of 340 matches
Mail list logo
