Re: [git subtree] documentation and new --squash mode
- From
Avery Pennarun <apenwarr@gmail.com>
- Date
- May 31, 2009, 16:42 UTC
- Message-ID
- <32541b130905310942x3ca98b0ibbed8598f4ba6e56@mail.gmail.com>
- In-Reply-To
- <slrnh24bff.n9t.sitaramc@sitaramc.homelinux.net>
On Sun, May 31, 2009 at 3:12 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
Show 9 quoted lines
> 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.
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.)
Also, git-subtree might have bugs yet. Watch out for that :)
Show 6 quoted lines
> [1] I do understand filter-branch quite well, and I know that > even without advance planning it is possible to separate a > subdirectory into its own repo using filter-branch. I don't > fancy teaching *them* filter-branch, so that makes me > personally central to their projects, which is not scalable > at all.
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.
Have fun,
Avery