On 16/01/07, Yann Dirson <ydirson@xxxxxxxxxx> wrote:
My example is quite similar to the one given by Guilhem: I had a git branch coming from git-cvsimport, and my stgit stack forked atop that branch. At some point git-cvsimport fucked something, and I regenerated a new mirror branch using it in a fresh repo. Then I wanted to rebase my stack on that new branch.
As Jakub said, I would also call this command 'rebase' instead of 'pull --to', even if we duplicate a bit of code. It would make the implementation even simpler as you won't break other people's workflows using git-pull or cg-pull. The main feature of the 'pull' command is to fetch the latest changes from a remote repository and merge (fast-forward) them into current base.
> But you want to replace the call to 'git pull' with 'git fetch'. I > think this is fine with my workflow but some people might actually > rely on calling 'git pull' (or cg-pull). Right, it may be possible (and I'd be interested in seeing such a workflow). Maybe we could keep support for git-pull as an alternative.
As I said, I use this myself on an exported branch.
This could be done, eg. by letting the user use "pullcmd=git-pull" and introduce a new option like "fastforward=<bool>" triggering the fast-forward needed after git-fetch, with the default being "true", and the current behaviour being obtained by changing it to "false".
But isn't this too complicated when all you need is a 'rebase'-like command?
That would not add too much complexity, while setting the default to what I believe to match the most common workflows, and allow anyone relying on the current behaviour to get it back.
The problem is that I may use different workflows in the same repository (but on different branches). Any new config options would have to be per branch. -- Catalin - 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