4 ms·

* _The DAG-based systems don't represent changesets that cross repositories. They don't have a type of object for representing a snapshot across repositories. _

by pieter 16y ago

* _The DAG-based systems don't represent changesets that cross repositories. They don't have a type of object for representing a snapshot across repositories. _ * _Creating a tag across repositories would involve visiting every repository to add a tag to it._ These two, at least, are technically accounted for by git submodules, though they are a bit of a pain to use.

pilif 16y ago
I don't know. Personally, I love submodules. Once you "get it", it's really straight forward. It really shines, if you use them for third party libraries that you are keeping patches for. In the old days, updating said libraries was nearly impossible once you began patching them. With submodules, you can use git's really cool merging capabilities to help you. Even better: The workflow when updating a library patched by you to a newer upstream version stays the same as if you'd just do a traditional merge in your own codebase. So there's no need to learn even more commands or new workflows - it just works. I'm a huge, huge fan of how git submodules work.
- binaryfinery 16y ago
  Until you have merge conflict. If someone could explain to me which file contains the conflict markers so I can fix them I'd be really happy. Its not the .gitmodules file.
  - pilif 16y ago
    if it's a merge conflict happening while updating the submodule, then the conflict is inside the working copy of that submodule. Go there and resolve it using the usual tools, commit and commit the updated submodule revision in the parent repository
    - binaryfinery 16y ago
      Except that doesnt work, because that just changes the hash of the submodule (as stored by the supermodule) again. The problem is that the supermodule just stores the hash of the submodule. The only way I found of fixing it was to: 1. Create a new repo. 2. Get the branched submodule. 3. Check that in as head: Note, now HEAD will NOT compile - I've committed broken code. 4. Go back to the original repo. 5. Get HEAD: this pulls the hash I need. 6. Do the merge. The submodule doesn merge, because it has the right hash. Surely there must be some way to just modify the hash. But I don't know where to change it. I found it in several locations, but I don't know how it works, and hacking my VCS isnt my idea of good sense.
  - timtadh 16y ago
    the command you are looking for is git diff. git status will show you which files changed, git diff will show you where the conflicts are in the files during the merge.
    - saurik 16y ago
      I am pretty certain in this situation that git diff claims that the submodule directory itself has somehow been modified from the previous commit hash to the new one. Please recognize that the case here is a merge conflict between two people advancing the commit the submodule points to to different revisions of the subproject, not merge conflicts inside of the subproject (which really should not be happening).

by pieter 16y ago

pilif 16y ago

I don't know. Personally, I love submodules. Once you "get it", it's really straight forward. It really shines, if you use them for third party libraries that you are keeping patches for. In the old days, updating said libraries was nearly impossible once you began patching them. With submodules, you can use git's really cool merging capabilities to help you. Even better: The workflow when updating a library patched by you to a newer upstream version stays the same as if you'd just do a traditional merge in your own codebase. So there's no need to learn even more commands or new workflows - it just works. I'm a huge, huge fan of how git submodules work.

binaryfinery 16y ago
Until you have merge conflict. If someone could explain to me which file contains the conflict markers so I can fix them I'd be really happy. Its not the .gitmodules file.
- pilif 16y ago
  if it's a merge conflict happening while updating the submodule, then the conflict is inside the working copy of that submodule. Go there and resolve it using the usual tools, commit and commit the updated submodule revision in the parent repository
  - binaryfinery 16y ago
    Except that doesnt work, because that just changes the hash of the submodule (as stored by the supermodule) again. The problem is that the supermodule just stores the hash of the submodule. The only way I found of fixing it was to: 1. Create a new repo. 2. Get the branched submodule. 3. Check that in as head: Note, now HEAD will NOT compile - I've committed broken code. 4. Go back to the original repo. 5. Get HEAD: this pulls the hash I need. 6. Do the merge. The submodule doesn merge, because it has the right hash. Surely there must be some way to just modify the hash. But I don't know where to change it. I found it in several locations, but I don't know how it works, and hacking my VCS isnt my idea of good sense.
- timtadh 16y ago
  the command you are looking for is git diff. git status will show you which files changed, git diff will show you where the conflicts are in the files during the merge.
  - saurik 16y ago
    I am pretty certain in this situation that git diff claims that the submodule directory itself has somehow been modified from the previous commit hash to the new one. Please recognize that the case here is a merge conflict between two people advancing the commit the submodule points to to different revisions of the subproject, not merge conflicts inside of the subproject (which really should not be happening).