On 2012-10-23 12:44, W. Trevor King wrote:
On Tue, Oct 23, 2012 at 12:16:22PM -0700, Nahor wrote:
On 2012-10-22 09:34, W. Trevor King wrote:
For instance, the module may later be updated to a commit in branch B
instead of branch A. Unless you remember to also update .gitmodule, you
have then inconsistent information.
But you're explicitly *using* the configured setting in
git config --file $toplevel/.gitmodules submodule.$name.branch
That should be a reminder that the configuration is important, and
you'll remember to change it.
From my experience with my colleagues at work, that's not going to
happen. People are very good at forgetting to do something ;)
Plus, the text from git-pull should
clearly display the branch you are pulling, which gives you a second
change to notice if something is going wrong.
That's assuming that the user knows the branch that should be pulled and
that he's paying attention to the output and not just quick-scanning for
errors/warnings.
Again, from my experience, that's not going to be the case.
Plus, there isn't always a human being behind a git-pull, e.g. build bots.
I think a better place to store that kind of information is using
git-notes. That way, if the branch is renamed or deleted, you can easily
update the old notes to use the new name instead.
Interesting. What would you attach the note too?
To the commits in the super-repo where a module branch is selected, i.e.:
- where a module was added
- where the module changed branch
- where a super-branch was merged and there was a conflict on the
module's branch name
--
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