git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
From: Yaroslav Halchenko <yoh@onerussian.com>
To: git <git@vger.kernel.org>
Subject: Re: [wishlist] submodule.update config
Date: Mon, 10 Dec 2018 17:49:01 -0500
Message-ID: <20181210224901.GL4633@hopa.kiewit.dartmouth.edu> (raw)
In-Reply-To: <CAGZ79kY+F776YfNBrx3wk3ffv4sqqabM5iJxbQDiPE6xoio69w@mail.gmail.com>


On Mon, 10 Dec 2018, Stefan Beller wrote:
> > I wondered, if you think it would be sensible to also add of
> > submodule.update which would be considered before submodule.SUBMODULE.update
> > variable possibly defined per submodule.  That would be more inline with desire
> > to use any of the --merge, --rebase (and hopefully soon --reset-hard)
> > strategies specified as an option for submodule update, where no per-submodule
> > handling  is happening.

> > Thanks in advance for the consideration!

> So you are proposing a variable like submodule.update
> without the .<name>. that would apply to any submodule?

yes

> The precedence in descending order of these
> configs that modify the behavior of "git submodule update"
> would be:

> * the command line flag (--merge/--rebase/--checkout)
> * submodule specific instructions (submodule.<name>.update)
> * generic submodule config (the new submodule.update)
> * default as --checkout

sound great

> I first hesitated in thinking this would be a good addition,
> as there is no plumbing command for submodules,
> to easily modify submodules irrespective of the user
> config. But that is out already with the submodule
> specific update configs.
> So I think it may be a good addition.

Glad to hear that. Not sure though I would know where to stick my
nose to figure out what to change. ;-)

> I wonder if we'd be better off to re-invent the UX instead
> of hiding your intentions in a config setting for a command
> that is already long to type. What about

>   git submodule merge
>   git submodule rebase
>   git submodule checkout
>   git submodule reset (--hard)

> as aliases for
>   git submodule update (...)

Well, not sure... In the long run, if UX is to be tuned up, I wonder if
it would be more worthwhile to look toward making all those git commands
(git merge, git checkout, git rebase, ..., git revert, git cherry-pick)
support --recurse-submodules with a consistent with the non-recursive
operation by default behavior (e.g.  not introducing detached HEADs or
controlling that via a set of additional options where needed).  I feel
that "git-submodule" ideally should not get its interface extended to
complement everything "git" commands can do, although that might need to
be extended to provide necessary plumbing.  As for the UX, it should
provide only the set of additional commands, which could not be present
in the main API (e.g. pure "git submodule" itself to list
submodules, and "submodule foreach", "init", "deinit").

-- 
Yaroslav O. Halchenko
Center for Open Neuroscience     http://centerforopenneuroscience.org
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834                       Fax: +1 (603) 646-1419
WWW:   http://www.linkedin.com/in/yarik        

  reply index

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-08 15:45 Yaroslav Halchenko
2018-12-10 20:40 ` Stefan Beller
2018-12-10 22:49   ` Yaroslav Halchenko [this message]
2018-12-11  0:08     ` [PATCH] " Stefan Beller
2018-12-11  5:10       ` Yaroslav O Halchenko
2018-12-12 19:31         ` Stefan Beller
2018-12-13 16:50           ` Yaroslav Halchenko

Reply instructions:

You may reply publically 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181210224901.GL4633@hopa.kiewit.dartmouth.edu \
    --to=yoh@onerussian.com \
    --cc=git@vger.kernel.org \
    /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

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox