On 4/1/08, Sam Vilain <sam@xxxxxxxxxx> wrote: > > The ideal situation would be to have > > git just manage the version control without having to babysit it, of > > course. > > I can understand the motivation to write such disparaging remarks; > however it may be more productive to come up with good ideas about how > it can be made to work better for you, without getting in the way of > other users. patches are even better! I didn't mean anything disparaging. I have nothing against babysitters :) I'll be happy to work on patches once we have some sort of consensus on what would be desirable. I think we're slowly getting there. > >> If I understand you correctly, you want to be forced to create a > >> branch and push to that? I don't think that works well with many > >> developers pushing to a shared repository (my situation), > > > > Hmm, this is curious. If you're *not* using submodules, then I don't > > think you can push successfully without being on a branch, can you? > > Sure, you could; > > git push origin HEAD:branchname Okay, yes. But that's just arbitrarily avoiding a local branch and creating a remote one instead. I can't imagine a situation where you'd really want the local branch to be anonymous while the remote one is not. When doing a normal "git clone" without submodules, git automatically creates you a local branch with the same name as the remote's .git/HEAD - which is rather arbitrary, but even an arbitrary local name is better than no name, and when checking out a brand new submodule, there are *no* local branches, so a name conflict is impossible. > > If you 'git checkout -b branchname' inside a submodule, then 'git > > push' will do the right thing, so I'm not sure what you'd want to be > > more automagical than that. > > Well, where did you get the branch name from? That's the part that > requires user intervention. You could make an educated guess, such as > with git name-rev, but it would not necessarily be the right guess - so > user confirmation of the choice would be desirable. Here's a paraphrase of what I suggested earlier. I don't think it got a response: Instead of storing only the commitid of each submodule in the parent tree, store the current branch name as well. Use this as a hint to 'submodule update' so that when it checks out commitid, it names the local branch with the same name as it used to have. (This is rather user-friendly since if I check in, push, and clone, my new submodule checkout will have the same branchname as it used to have.) Note that the newly checked-out submodule branch will probably have the same name as as remote branch. However, the remote branch may refer to a different commitid (for example, if someone has pushed to that branch after the parent repo was last updated). This is exactly right; it means that if I cd into the submodule and "git push", it'll fail because I'm not up to date (I can always switch to a new branch if I want), and if I "git pull", it'll pull from the place where it should. This way, cloning a project with submodules will work much like cloning the parent project; pushing and pulling the parent and the submodules will do as you expect. The bad news is that this would require a change to the tree format for submodules (to contain the branch name). Is that a problem? Can it be done in a backwards-compatible way? Also, I think this is the only time I've seen a branch name in the commit/tree structure, which normally refers only to sha-1 hashes. Is that a problem? Is there a better way? Thanks, Avery -- 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
