Hi Pavel, This is quite related to the subject of the "Handling of branches in stgit" thread I launched recently (Nov 30th). On Sat, Dec 09, 2006 at 04:23:25AM -0500, Pavel Roskin wrote: > It's very important for me to have default remote support in StGIT. I'm > trying to track different Linux branches, and I don't want to remember > what branch I'm on when I run "stg pull". Right, that's the main problem with the current implementation. > One approach is to leave the default remote selection completely to git. > The downside is that StGIT prints the remote it's pulling from. Now > StGIT will have to print common words that it's pulling something. Or > maybe it shouldn't print anything? It could just print a generic message and let GIT print out the details. > Also, git-pull doesn't allow to specify the refspec without the remote. > This limitation seems artificial to me, but we have to pass this > limitation to the StGIT users. In which situtation do you need to pass a refspec ? I thought all necessary refspecs should already be part of a remote's definition. > The positive side if that StGIT is completely unaware of the word > "origin", and any changes in git handling of the default remote will > propagate to StGIT immediately. Indeed. > The other approach is to calculate the default remote in StGIT. This > would allow StGIT to tell the user where it's pulling from. Doing so would probably require to teach StGIT about every new way of fetching a branch (we already have 3 ways, as outlined in my initial mail). OTOH, it may be the only way to present the user with a uniform way of working, independently of the way we update the parent branch. Indeed, we may just want to distinguish whether the parent branch is a remote one or not. Then if it's a remote one, git-fetch already has enough info to do its work updating the parent branch (whether using .git/remotes or .git/branches). If it's not a remote branch, there's just nothing to do at this step. Then, we just have to "pop -a" and move the stack base, without relying on "pull". That would also transparently give support for branching off a non-forwarding branch (like git's "next" and "pu", or like any stgit managed branch). Would anyone miss the "git-pull" call ? Best regards, -- Yann. - 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