All of lore.kernel.org
 help / color / mirror / Atom feed
From: Avery Pennarun <apenwarr@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: Bryan Larsen <bryan.larsen@gmail.com>, git <git@vger.kernel.org>,
	Junio C Hamano <gitster@pobox.com>
Subject: Re: Avery Pennarun's git-subtree?
Date: Wed, 21 Jul 2010 15:56:54 -0400	[thread overview]
Message-ID: <AANLkTinl1SB1x1bEObLIo-LWjvxM-Yf1PfdUp4DNJda3@mail.gmail.com> (raw)
In-Reply-To: <AANLkTilivtS4TccZXHz2N_n_2RpY6q_5sw7zwdWKdnYE@mail.gmail.com>

On Wed, Jul 21, 2010 at 3:43 PM, Ævar Arnfjörð Bjarmason
<avarab@gmail.com> wrote:
> What sort of workflows do you find bad with git-submodule that are
> better with git-subtree?
>
> The submodule concept is simple, but a lot of the implementation is
> bad IMO. It doesn't integrate well, e.g. you have to remember to do
> git clone --recursive, or git clone and git submodule update --init
> after that, submodules don't remember what branch you wanted, so git
> submodule foreach 'git pull' doesn't DWYM (although I have a hack for
> that) etc.

In my experience, there is exactly one killer problem with submodules
that people are looking to solve with git-subtree:

Branching.

If you have a random developer in your office and they need to make a
patch to one of your subprojects in the course of making their main
project work, with submodules this requires incredibly error-prone
contortions involving branching both projects, making sure you have
push access to both projects, learning how to use git-submodule, etc.
And then merging that branch into someone else's branch is
complicated, particularly if they've also applied their own changes to
the subproject.

With git-subtree, that developer just commits the changes to the
merged project - and that's it.  Then you or someone else, who knows
how git-subtree works, at any point in the future, can submit the
subproject changes upstream, or not, as appropriate.

No amount of bugfixing in git submodule can fix this workflow, because
it's not a result of bugs.  (The bugs, particularly the
disconnected-by-default HEADs on submodule checkouts, do make it a bit
worse :( )  It would require a fundamental redesign to make this work
nicely with submodules.

git-subtree is certainly a fundamental redesign.  Arguably there might
be even better ways to design it, of course.  And submodules are good
for certain other situations that git-subtree isn't, so it's obviously
not a one-for-one replacement.

If we can get some kind of consensus in principle that git-subtree is
a good idea to merge into git core, I can prepare some patches and we
can talk about the details.

Have fun,

Avery

  reply	other threads:[~2010-07-21 19:57 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-21 17:15 Avery Pennarun's git-subtree? Bryan Larsen
2010-07-21 19:43 ` Ævar Arnfjörð Bjarmason
2010-07-21 19:56   ` Avery Pennarun [this message]
2010-07-21 20:36     ` Ævar Arnfjörð Bjarmason
2010-07-21 21:09       ` Avery Pennarun
2010-07-21 21:20         ` Avery Pennarun
2010-07-21 22:46         ` Jens Lehmann
2010-07-22  1:09           ` Avery Pennarun
     [not found]             ` <m31vavn8la.fsf@localhost.localdomain>
2010-07-22 18:23               ` Bryan Larsen
2010-07-24 22:36                 ` Jakub Narebski
2010-07-22 19:41               ` Avery Pennarun
2010-07-22 19:56                 ` Jonathan Nieder
2010-07-22 20:06                   ` Avery Pennarun
2010-07-22 20:17                   ` Ævar Arnfjörð Bjarmason
2010-07-22 21:33                     ` Avery Pennarun
2010-07-23 15:10                       ` Jens Lehmann
2010-07-26 17:34                       ` Eugene Sajine
2010-07-22 20:43                   ` Elijah Newren
2010-07-22 21:32                     ` Avery Pennarun
2010-07-23  8:31                 ` Chris Webb
2010-07-23  8:40                   ` Avery Pennarun
2010-07-23 15:11                     ` Jens Lehmann
2010-07-23 22:33                       ` Avery Pennarun
2010-07-23 15:13                     ` Jens Lehmann
2010-07-23 15:10                 ` Jens Lehmann
2010-07-23 16:05                   ` Bryan Larsen
2010-07-23 17:11                     ` Jens Lehmann
2010-07-23 19:01                       ` Bryan Larsen
2010-07-23 22:32                   ` Avery Pennarun
2010-07-25 19:57                     ` Jens Lehmann
2010-07-27 18:40                       ` Avery Pennarun
2010-07-27 21:14                         ` Jens Lehmann
2010-07-23 15:19                 ` Marc Branchaud
2010-07-23 22:50                   ` Avery Pennarun
2010-07-24  0:58                     ` skillzero
2010-07-24  1:20                       ` Avery Pennarun
2010-07-24 19:40                         ` skillzero
2010-07-25  1:47                           ` Nguyen Thai Ngoc Duy
2010-07-28 22:27                             ` Jakub Narebski
2010-07-26 13:13                           ` Jakub Narebski
2010-07-26 16:37                         ` Marc Branchaud
2010-07-26 16:41                           ` Linus Torvalds
2010-07-26 17:36                             ` Bryan Larsen
2010-07-26 17:48                               ` Linus Torvalds
2010-07-27 18:28                             ` Avery Pennarun
2010-07-27 20:25                               ` Junio C Hamano
2010-07-27 20:57                                 ` Avery Pennarun
2010-07-27 21:14                                   ` Junio C Hamano
2010-07-27 21:32                                   ` Jens Lehmann
2010-07-26  8:56                       ` Jakub Narebski
2010-07-27 18:36                         ` Avery Pennarun
2010-07-28 13:36                           ` Marc Branchaud
2010-07-28 18:32                           ` Jakub Narebski
2010-07-24 20:07                     ` Sverre Rabbelier
2010-07-26  8:51                     ` Jakub Narebski
2010-07-27 19:15                       ` Avery Pennarun
2010-07-26 15:15                     ` Marc Branchaud
2010-07-21 23:46         ` Ævar Arnfjörð Bjarmason

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=AANLkTinl1SB1x1bEObLIo-LWjvxM-Yf1PfdUp4DNJda3@mail.gmail.com \
    --to=apenwarr@gmail.com \
    --cc=avarab@gmail.com \
    --cc=bryan.larsen@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /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.