On Fri, Dec 01, 2006 at 11:19:41PM +0100, Yann Dirson wrote: > > > 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 Indeed most of the current attributes of a stack (except maybe for the description, which can hardly be seen as a config option) are quite volatile, and thus unsuited for repo-config. OTOH, as you said parent information would find easily its place there. > > 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 would also think that what really belongs to that config item would be the declaration of which remote our parent branch should use to be updated (ie. no need to duplicate the info in all the stgit stacks forked off the same parent). However it looks like this config option is not currently used unless the branch to be git-fetched is the curent one, which is quite annoying - we would need to get that setting ourselves to pass it to git-fetch. What's not clear to me is how to deal with cogito branches (maybe check for the existence of .git/branches/<name> and then "git fetch <name>" ?), and with local branches (how are we supposed to derive that a branch is not a remote one ? Should GIT add a branch.<name>.remote or "." for locally-created branches ?). We would also still need a config item to tell which parent branch we should use, in order to know which branch.<name>.remote to extract, and which branch to fast-forward our base onto. 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