On Tue, Feb 20, 2007 at 01:00:59AM +0100, Yann Dirson wrote: > On Mon, Feb 19, 2007 at 06:28:40PM -0500, Pavel Roskin wrote: > > > I think the fail-safe solution would be to leave the old behaviour > > > (i.e. git-pull and pull-does-rebase=no) and people that need to pull > > > from branches like that described above would use the fetch+rebase > > > approach. Ideally, we'll have this configurable per-branch (and could > > > leave the global one as well if the most specific is not available, > > > but should default to git-pull). > > > > By the way, it would be great to reduce all complexity to "one bit" per > > branch. If stgit.internal-pull (the name is subject to improvement) is > > on, "stgit pull" calls git-fetch and does rebase. Otherwise, it calls > > git-pull. No need to configure two variables per branch. > > Being able to specify the command to use makes it possible to hook to > other SCM's (eg. using git-cvsimport, git-svn or similar). Thinking twice, we could make things even better :) Let's acknowledge that we have several ways of pulling, by getting rid of the awkward 'stgit.pull-does-rebase'. Instead we could use a new "pull-policy" setting, with possible values "pull" and "fetch-rebase" to match the 2 currently-available behaviours. Then according to the pull-policy, "stg pull" would use "pullcmd" or a new "fetchcmd" setting, thus removing the requirement to mess with pullcmd in the common case. All of "pull-policy", "pullcmd", and "fetchcmd" would have a per-branch and a global setting (stgit.<foo> and branch.*.stgit.<foo>). We could also introduce a 3rd "rebase" policy, to support local parent branches better. 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