Re: [git subtree] documentation and new --squash mode

From: Sitaram Chamarty <sitaramc@gmail.com>
Date: Jun 1, 2009, 01:09 UTC
Message-ID: <2e24e5b90905311809h751eff3en7f5a87f1e5a6ab03@mail.gmail.com>
In-Reply-To: <32541b130905310942x3ca98b0ibbed8598f4ba6e56@mail.gmail.com>

On Sun, May 31, 2009 at 10:12 PM, Avery Pennarun <apenwarr@gmail.com> wrote:

Show 15 quoted lines

>
> On Sun, May 31, 2009 at 3:12 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> > As I understand the documentation (and past emails, snippets
> > of IRC traffic, etc) git subtree will help me do precisely
> > what I want -- a simple way to deal with this all-too-common
> > SVN-ism.  If not "simple", at least
> >
> >  - simpler than submodules, and
> >
> >  - no need for advance planning [1] about what parts will
> >    be subprojects.
>
> Well, I don't know that I'd go so far as to advise against advance
> planning :)  But git subtree does make it easy for you to change your
> mind later, that much is true.

Agreed, and that's good enough for me.

Show 7 quoted lines

> You might still have some troubles if you rename subdirectories a lot;
> perhaps I don't understand it correctly, but the so-called file
> move/rename detection in git doesn't seem to be implemented
> everywhere. If you extract the history of a subdirectory that was
> previously renamed, you'll get only the history since it was renamed.
> (Which might be fine with you.  You can certainly still merge it back
> in afterwards.)

Did not know this; thanks -- will keep an eye out.

> Also, git-subtree might have bugs yet.  Watch out for that :)

:)

> git-subtree is certainly easier to use than filter-branch, IMHO.  Plus
> it helps you merge things back in afterwards, which filter-branch
> doesn't particularly.

All in all it does look like it will fulfill my purposes. I will probably use it myself a bit before telling people to use it of course.

Thanks,

Sitaram