Karl Hasselström <kha@xxxxxxxxxxx> writes: > Currently, there's stg rebase which only does rebasing, and stg pull > which does either rebase or merge depending on a config option. And on > top of that there's config stuff like stgit.pullcmd that is invoked in > some cases but not others. > > What I think I'd like is the following: > > * Just one command, stg pull. stg rebase is removed. And I would have to learn to use other command (I use very frequently the following sequence: git remote update && stg rebase <branch>)? Not nice. I already have to use two commands: "stg refresh && stg edit" to make a change which affects how commit message is written, instead of simplier "stg refresh --edit". > * When pull is invoked, the following happens: > > 1. The branch we pull from may be updated, depending on the > configuration. (e.g. git fetch or git svn fetch) > > 2. Depending on the configuration (overridable by the > --fast-forward, --rebase, and --merge options), one of these > three things happen: Couldn't then "stg rebase" be 'internal alias' to "git pull --rebase"? [...] > * The default action is to fast-forward, which is probably what most > users want -- merge is very likely to do the wrong thing, and > rebase can lose changes. Unless you want to rebase on top of different branch, for example moving stack from 'master' to 'next', or when you work on top of branch which doesn't fast-forward, like 'pu' in git repository. -- Jakub Narebski Poland ShadeHawk on #git -- 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
