On Apr 30, 2008, at 2:31 PM, Avery Pennarun wrote:
On 4/30/08, Tim Harper <timcharper@xxxxxxxxx> wrote:
The problem, of course, is that you can easily have valuable, but
not-tracked, files in there. Deleting the submodule is therefore no
option.
Submodules are not deleted. They are moved out of the working copy
into a
folder in .git. Therefore, upon changing back to the branch with the
submodule, they are restored, without nay a hair on their head lost.
<drool>
Yes! I'm a little sad that I didn't think of that, because it sounds
like *exactly* what I want.
Glad to hear I'm not the only one who feels that way :)
What about the following case:
- submodule matches the super module checkin
?
- make changes to submodule but to *not* commit them
Changes will never be lost, because the submodule is either stashed
away, working copy and all, or a "checkout" command is issued to
change the HEAD pointer. The latter is like changing branches with
uncommitted code - the changes will either be carried, and possibly
conflict.
- switch supermodule branches, which should checkout a different
submodule
Submodule is automatically changed for you, so changing branches makes
sure you always have the "whole project". Recursion isn't handled at
the time being, so it only works for 1 level deep.
- submodule checkout causes a conflict with uncommitted files
Oooh - this could be a problem currently, especially if you're not on
a branch. If you have to resolve conflicts the way to resolve them is
to commit, and you can't switch to a branch to commit unless you
resolve your issues. In which case, you'll probably want to resolve,
commit, then create a new branch with your current HEAD, then merge it
into a branch. I'll visit that as issues arise. This is bleeding
edge experimentation here :)
What will/should happen here? It seems like either the supermodule's
submodule pointer won't be set properly (ie. git-submodule-update will
fail, but the supermodule won't be marked as conflicted, thus
git-commit in the supermodule will commit the wrong submodule
revision) or else submodule files might have to be lost or something.
This is a good point: I don't believe that submodules have anyway to
mark the submodule revision as "conflicted". In order for this
concept to be handled in its full glory, that will most certainly need
to be handled.
Also, someone earlier asked for a link to your work. I'd like to see
it too, as I don't know what a "textmate git bundle" is. I gather
textmate is a MacOS X program, but I don't know what that has to do
with git-submodule :)
TextMate is an editor for MacOSX.
Here's a link to the bundle. It's written in ruby.:
http://github.com/timcharper/git-tmbundle/
What does it have to do with submodules? It's essentially a "GUI" for
git. It provides automation for a lot of common tasks also. My team
has a need for submodules, but unfortunately in their current state I
couldn't recommend it to them, so I "smoothed over" the rough edges by
automating a lot of the awkwardness. So far, it's been working well
for us.
Thanks,
Avery
Thank you!
Tim
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
