4 ms·

For a less painful [1] solution, see git-subrepo. [2] [1] https://github.com/ingydotnet/git-subrepo/blob/master/Intro.pod#git-submodules https://github.com/ing

For a less painful [1] solution, see git-subrepo. [2] [1] https://github.com/ingydotnet/git-subrepo/blob/master/Intro.pod#git-submodules https://github.com/ingydotnet/git-subrepo/blob/master/Intro.... [2] https://github.com/ingydotnet/git-subrepo https://github.com/ingydotnet/git-subrepo

perlgeek 12y ago
I use git-subrepo too, but it has its own sets of warts. It generates pretty verbose (and ugly) commit messages made of json. It doesn't let you do anything (like a pull or clone) when you working directory is dirty. But on the whole, it is often less painful than submodules. I haven't tried subtree yet, will do that next :-)
- chocolateboy 12y ago
  > It generates pretty verbose (and ugly) commit messages made of json. This was fixed recently. [1] > I haven't tried subtree yet, will do that next :-) The git-subrepo intro has a pretty good overview of the issues with git-subtree. [2] [1] https://github.com/ingydotnet/git-subrepo/issues/40 https://github.com/ingydotnet/git-subrepo/issues/40 [2] https://github.com/ingydotnet/git-subrepo/blob/master/Intro.pod#git-subtrees https://github.com/ingydotnet/git-subrepo/blob/master/Intro....
  - perlgeek 12y ago
    OK, the commit messages are less ugly now, but they still give the wrong kind of information. Four lines of the commit message are about git-subrepo, which I don't care about. I'm not a git-subrepo developer, and don't care what version of the tool was used to generate the commit. What I do care a lot about is why a commit was made, and those auto-generated commit messages don't tell me that at all. They can't, because the tools don't read minds. That's why git usually prompts me for a commit message. I like that. It's one of the reasons I'm using version control. It would be nice if git-subrepo played along.
    - chocolateboy 12y ago
      The metadata in the commit message isn't used in any way, so you can always: git commit --amend I personally find it a useful default, though, i.e. there's not usually much more I want to say than "added a subrepo: [metadata...]", and, for something like this, I'd rather err on the side of too much information than too little.

perlgeek 12y ago

I use git-subrepo too, but it has its own sets of warts. It generates pretty verbose (and ugly) commit messages made of json. It doesn't let you do anything (like a pull or clone) when you working directory is dirty. But on the whole, it is often less painful than submodules. I haven't tried subtree yet, will do that next :-)

chocolateboy 12y ago
> It generates pretty verbose (and ugly) commit messages made of json. This was fixed recently. [1] > I haven't tried subtree yet, will do that next :-) The git-subrepo intro has a pretty good overview of the issues with git-subtree. [2] [1] https://github.com/ingydotnet/git-subrepo/issues/40 https://github.com/ingydotnet/git-subrepo/issues/40 [2] https://github.com/ingydotnet/git-subrepo/blob/master/Intro.pod#git-subtrees https://github.com/ingydotnet/git-subrepo/blob/master/Intro....
- perlgeek 12y ago
  OK, the commit messages are less ugly now, but they still give the wrong kind of information. Four lines of the commit message are about git-subrepo, which I don't care about. I'm not a git-subrepo developer, and don't care what version of the tool was used to generate the commit. What I do care a lot about is why a commit was made, and those auto-generated commit messages don't tell me that at all. They can't, because the tools don't read minds. That's why git usually prompts me for a commit message. I like that. It's one of the reasons I'm using version control. It would be nice if git-subrepo played along.
  - chocolateboy 12y ago
    The metadata in the commit message isn't used in any way, so you can always: git commit --amend I personally find it a useful default, though, i.e. there's not usually much more I want to say than "added a subrepo: [metadata...]", and, for something like this, I'd rather err on the side of too much information than too little.