Junio C Hamano wrote: > 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"). Excellent I was hoping to start a discussion like this. My initial thought was designing a custom script that git-pull will execute like a hook; we should, however, be able to get away with designing enough configuration orthogonal configuration variables. For anything more complex, just do it by hand! > 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. Will do. Expect a draft soon. -- 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