On Fri, Dec 01, 2006 at 12:42:19PM +0000, Catalin Marinas wrote: > On 30/11/06, Yann Dirson <ydirson@xxxxxxxxxx> wrote: > >I have started to work on recording parent information for stgit > >branches, so we don't need to give the same info on every "git pull". > > Isn't this what the branch.<name>.remote configuration option is for? > I think we should leave GIT handle this and StGIT only invoke "git > pull" without any arguments. This is one part of the problem (and I admit I have missed this config option), the other one being having stgit pull the correct branch, unstead of (implicitely) having git-pull using the 1st one in the remotes file. > >I'm facing a problem, in that we have several kind of stgit branches: > > > >* those created against a cogito branch (eg. by "cg clone" and "stg > > init"). They work pretty much intuitively (and it happens I mostly > > used this flavour before those tests). All we need is the name of > > the local branch, and "stg pull <branch>" relies on "git fetch" to > > find the repository information in .git/branches/<branch>. > > But I think .git/branches got deprecated or it is a cogito-only feature. .git/branches still seems to be the only type of branch created by cogito. And in fact, when remotes started to appear, I wondered how the cogito branch management (a quite intuitive and classical one) would be made to work well with remotes-defining-several-branches, as well as branches-potentially-defined-in-several-remotes (possible repo inconsistency AFAICT, or maybe to specify different protocols to a single repo ?) - and indeed I still don't have an answer, I guess cogito would have to possibly change its user interface if it were to be able to use multi-branch remotes. In the meantime, we should support them in cogito. And indeed, I found stgit to work perfectly with those. > > In this case, it is easy to request pulling from any branch, but > > usually only one of them is what you want, and the results of using > > another one (or forgetting to specify the one you want) can be > > annoying [ISSUE 1]. Hence this work of mine: being able to store > > this info in .git/patches/<stack>/parent (my initial implementation) > > was sufficient in theory. > > I would leave this to GIT and its configuration files. Do you see any > problems with this approach? I'd rather consider it a stgit issue: git itself does no have to know which of the various heads descending from our stack base is to be "prefered" by our stack. Where to store it is anothe issue (see below). > I plan to merge the stgit config with the git one (and have a [stgit] > section) so that it is more maintainable. Sure, let's take advantage of git-repo-config ! My latest 1/3 patch could then be seen as a 1st step towards an abstraction of stgit object configuration, which could ease the transition from file storage to config items :) 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