Re: Making submodules easier to work with (auto-update on checkout or merge, stash & restore submodules)

From: Tim Harper <timcharper@gmail.com>
Date: Apr 30, 2008, 20:19 UTC
Message-ID: <BC221793-3FB5-4249-8E8D-819C1B413592@gmail.com>
In-Reply-To: <alpine.DEB.1.00.0804301121240.17469@eeepc-johanness>

I had a feeling my proposal would be met with a mix of opposition and acceptance, depending on which "git camp" you are currently in.

On Apr 30, 2008, at 4:31 AM, Johannes Schindelin wrote:

Show 15 quoted lines

> Hi,
>
> On Tue, 29 Apr 2008, Tim Harper wrote:
>
>> 1) The submodule stays in the working copy when changing to a branch
>>   that does not have a submodule.  This can break a build and cause
>>   problems.  To work around, I have to delete the folder completely
>>   (git-clean).  Then, when I switch back to the branch again, I  
>> have to
>>   re-download the submodule.
>
> 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.

Show 8 quoted lines

>> 2) I have to type "git checkout branch && git submodule init && git
>>   submodule update" to be sure that I really have the whole  
>> contents of
>>   the branch.  That's 3 commands, and a lot of typing.
>
> There is no way around "checkout branch", and I think that is a good
> thing.
>

Naturally

Show 5 quoted lines

> But once you did "submodule init", you will never need to run it  
> again,
> since it edits your .git/config, which does not change when switching
> branches.
>

If working in a collaborative environment, when someone adds a new submodule, it's extra burden to have to know "oh, there's a new submodule now, so I have to run "git submodule init". I find it's more than sufficient just to run it everytime, and costs me nothing. Why aren't "gut submodule update" and "git submodule init" the same command? Perhaps a compromise could be met with "git submodule update -i".

Show 8 quoted lines

> And as for "submodule update", I like the fact that the submodule is  
> not
> updated automatically.  For example, when I actively develop a  
> submodule,
> but have to rebase the superproject, I would _hate_ it if the  
> submodule
> wass updated.
>

Then we could make my proposed idea a configuration variable :) For my use case, I passionately dislike the fact that a submodule is not updated automatically. There's never a time when I don't want to update the submodule. The submodule is a very important piece of our project and the super-project depends on it being at the right version.

I suspect a large majority of git users who would use submodules, and a handful of those already using it, have a similar use case. Though, I have no evidence to support this, other than my own observations.

Show 14 quoted lines

> The whole idea about submodules is that they are repositories of  
> their own
> right, and therefore the superproject should not mess with them,  
> _unless_
> explicitely asked to, with "submodule update".
>
>> 3) If I don't run "git submodule update", and carelessly run "git  
>> commit
>>   -a"  or "git add .", I risk propagating a submodule version from
>>   another branch or undoing an important change.
>
> git commit -a is something that might make sense for newbies, but you
> really should learn to use git add -p and commit without -a.
>

Or... use my textmate bundle for git, which makes committing very easy. :) The newbies are pointed to use "git add ." - just try typing "git add"

Show 33 quoted lines

>> SUGGESTED ALGORITHM (AS HAS BEEN IMPLEMENTED IN THE GIT TEXTMATE  
>> BUNDLE)
>> When pulling / merging / changing branches:
>> 1) cache all submodules to ~/.git/submodules_cache
>> a) move from the working directory to a folder that is a MD5 hex- 
>> hash of
>> both the submodule path and the submodule url
>> 2) execute the pull / merge / branch change
>> 3) restore all defined submodules to ~/.git/submodules_cache (only  
>> the
>> submodules that are still defined after the merge / change / pull)
>> 4) execute git submodule init && git submodule update
>>
>>
>> PITFALLS:
>> pitfall)
>> If you commit a change on a submodule that's not on a branch, auto- 
>> updating
>> submodules will make it difficult to revive that change.
>>
>> workaround)
>> Don't allow the user to commit unless they are on a branch.
>>
>> ... couldn't think of anymore.  Anyone?
>
> I do not like that.  I think that the user should be responsible to  
> take
> care of the up-to-dateness of the submodule.  As far as the  
> superproject
> is concerned, it just keeps track of the committed submodule state,  
> but
> does not enforce it.
>

Does git serve me or do I serve git? The whole point of software is to make our lives easier and more productive. If submodules are apart of our project, why would not want git to handle making sure your submodules are at the right version?

I could see an issue if you changed the submodule version, and forgot to commit the version change in your super project, and then switched branches, and lost your version change. Perhaps the correct behavior in this case would be to only automatically update the submodule version if it didn't differ from the superproject version in the "from" branch.

Show 13 quoted lines

> FWIW I restarted on my --ignore-submodules patch, which can be seen  
> here:
>
> http://repo.or.cz/w/git/dscho.git?a=shortlog;h=refs/heads/my-next
>
> It lacks tests, therefore it has not been submitted for review yet.
>
> The basic idea is that not only "checkout" ignores the _contents_ of  
> the
> submodules, but optionally "diff", and using that option "stash" and
> "rebase".
>
> IOW you can "stash a

Leaving me hanging?  lol.

Thanks, Tim