Ramkumar Ramachandra <artagnon@xxxxxxxxx> writes: > I usually use `git fetch`, inspect state, and then merge/ rebase > accordingly. Unfortunately, this is very sub-optimal as I can > automate this 80% of the time. I want to be able to decide what to do > on a repository-specific basis, and hence propose a pull.default which > can be set to the following: > 1. fetch. Just fetch. (I will set this as my default in ~/.gitconfig) > 2. fast-forward. Fetch. If the FETCH_HEAD is directly ahead of HEAD, > `stash`, merge, and stash apply. Otherwise, do nothing. > 3. rebase. Fetch. stash, rebase, stash apply. `git pull n` will do > rebase --onto master HEAD~n instead of rebase. > 4. reset. Fetch, stash, reset --hard FETCH_HEAD, stash apply. > > Ofcourse, it should print a message saying what it did at the end. > > What do you think? Many other possibilities are missing. "fetch and merge", for example. You seem to be generalizing the "--rebase" and "--ff-only" options of "git pull" with 2 and 3, which may (or may not) make sense. I think you can shrink and enhance the above repertoire at the same time by separating "do I want to have stash and stash pop around" bit into an orthogonal axis. The other orthogonal axes are "Under what condition do I integrate the work from the upstream?" (e.g. "only when I do not have anything, aka, ff-only") and "How would I integrate the work from the upstream?" (e.g. "rebase my work" and "discard anything I did aka reset --hard"). By the way, I do not think you should start your design from a configuration (this is a general principle, not limited to this case). Think about what the smallest number of independent options you need to add to express various workflows, and then turn them into configuration variables that can set the default, all of which have to be overridable from the command line. -- 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