All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Lehmann <Jens.Lehmann@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Lauri Alanko <la@iki.fi>, git@vger.kernel.org
Subject: Re: A design for subrepositories
Date: Sun, 14 Oct 2012 21:32:05 +0200	[thread overview]
Message-ID: <507B1335.10105@web.de> (raw)
In-Reply-To: <7v4nlxylpm.fsf@alter.siamese.dyndns.org>

Am 14.10.2012 20:04, schrieb Junio C Hamano:
> Jens Lehmann <Jens.Lehmann@web.de> writes:
> 
>> Again, the user experience is currently suboptimal.
> 
> You mentioned multiple things in your responses that you are
> planning to address, but I am wondering if the first step before
> doing anything else is to have a list of known-to-be-suboptimal
> things and publish it somewhere other people can find it.  Then
> Lauri or others may able to help code the design of the approach to
> address them for items you already have designs for, and they may
> even be able to help designing the approach for the ones you don't.

I'm keeping such a list in the "Issues still to be tackled in this
repo" section of the Wiki page of my github repo:
   https://github.com/jlehmann/git-submod-enhancements/wiki

Currently that's just a collection of things to do and bugs to fix,
but if people are interested I'm willing to add descriptions of the
solutions I have in mind for those topics.

> More importantly, they do not have to waste time coming up with
> incompatible tools.  Adding "works in this scenario that is
> different from those other slightly different tools" to the mix of
> third-party tool set would fragment and confuse the user base
> ("which one of 47 different tools, all of which are incomplete,
> should I use?") and dilute developer attention.  They all at some
> point want to interact with the core side, and without an overall
> consistent design and coordination, some of their demand on the core
> side would end up being imcompatible.
> 
> The "just let .gitmodules record which branch is of interest,
> without checking out a specific commit bound to the superproject
> tree and using as a base for diff" (aka floating submodule) could be
> one of the items on the list, for example; to support it, we should
> not have to throw the entire "git submodule" with the bathwater.

Yup, that's also on that list under "always tip" mode.

  reply	other threads:[~2012-10-14 19:32 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-13 13:33 A design for subrepositories Lauri Alanko
2012-10-13 17:30 ` Junio C Hamano
2012-10-13 21:23   ` Lauri Alanko
2012-10-14  4:36     ` Junio C Hamano
2012-10-14 10:19       ` Lauri Alanko
2012-10-14 13:28         ` Jens Lehmann
2012-10-14 15:27           ` Lauri Alanko
2012-10-14 16:10             ` Jens Lehmann
2012-10-14 16:15             ` Jens Lehmann
2012-10-14 16:25             ` Jens Lehmann
2012-10-14 18:04               ` Junio C Hamano
2012-10-14 19:32                 ` Jens Lehmann [this message]
2012-10-19  0:31                 ` A design for distributed submodules Lauri Alanko
2012-10-19 20:09                   ` Jens Lehmann
2012-10-14 22:59               ` A design for subrepositories Lauri Alanko
2012-10-15 17:10                 ` Jens Lehmann
2012-10-13 21:20 ` perryh

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=507B1335.10105@web.de \
    --to=jens.lehmann@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=la@iki.fi \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.