From: Junio C Hamano <gitster@pobox.com>
To: Fabian Franz <git@fabian-franz.de>
Cc: git@vger.kernel.org, j.sixt@viscovery.net, hjemli@gmail.com
Subject: Re: [PATCH v4] submodule: add +<branch> syntax for track to allow automatic pulling.
Date: Sat, 10 Jan 2009 17:34:31 -0800 [thread overview]
Message-ID: <7vy6xityl4.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: 1231553410-7541-4-git-send-email-git@fabian-franz.de
Fabian Franz <git@fabian-franz.de> writes:
> When the track parameter is set to +<branch>, on update command a
> new branch is created tracking the remote branch (if it does not
> yet exist). Then the branch is checked out and git-pull is run.
Usually a "+" in front of a refspec means "allow forcing non-ff update",
but here it means completely different thing. The syntax is confusing.
But that aside, I do not know if the semantics of this patch makes sense
to begin with.
Should this really be a persistent property of a submodule? With your
patch, this is always triggered for modules you did "--track +branch" when
you added them, but (1) not for others you did not say "+" when you added,
and (2) you cannot disable the auto-pull for the ones you did even if you
wanted to. It feels it might be better to make it a property of one
particular invocation of "update" action, and more generally, the entire
series feels like a very specific hack that is meant to cover/impose your
particular workflow (and not others').
Don't get me wrong. I do not see any problem in supporing it well, if
that particular workflow is a good workflow and a generally applicable
one.
But I do not think it is documented well enough. "--track creates one
configuration in the .git/config file" and "update always checks out the
tip of the named branch if such configuration is set" may be fine
descriptions of what each piece does. The readers will be left puzzled
without an explanation of the bigger picture to understand why it is
(sometimes) a good idea to make these pieces do what they do.
next prev parent reply other threads:[~2009-01-11 1:36 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-10 2:10 [PATCH v4] submodule: allow tracking of the newest revision of a branch in a submodule Fabian Franz
2009-01-10 2:10 ` [PATCH v4] submodule: add --no-fetch parameter to update command Fabian Franz
2009-01-10 2:10 ` [PATCH v4] submodule: add --use-gitmodules " Fabian Franz
2009-01-10 2:10 ` [PATCH v4] submodule: add +<branch> syntax for track to allow automatic pulling Fabian Franz
2009-01-10 2:10 ` [PATCH v4] submodule: add --recursive parameter to update command Fabian Franz
2009-01-11 1:34 ` Junio C Hamano [this message]
2009-01-10 14:23 ` [PATCH v4] submodule: allow tracking of the newest revision of a branch in a submodule Johannes Schindelin
2009-01-11 1:31 ` [PATCH v4] submodule: add --no-fetch parameter to update command Nanako Shiraishi
2009-01-11 1:32 ` Nanako Shiraishi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vy6xityl4.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=git@fabian-franz.de \
--cc=git@vger.kernel.org \
--cc=hjemli@gmail.com \
--cc=j.sixt@viscovery.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).