Re: [ITCH] pull.default
Junio C Hamano wrote: 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). Okay, so this is what I currently have: - pull.condition = clean-worktree | ff-update | no-local-changes | always | never - pull.action = merge | rebase* | reset - pull.resetType = soft | hard | merge | keep - pull.autostash = true | false (ff-update is satisfied when FETCH_HEAD is directly ahead of refs/remotes/branch, while no-local-changes is satisfied when FETCH_HEAD is directly ahead of refs/heads/branch) Personally, I would love the defaults pull.condition = ff-update, pull.action = rebase, pull.autostash = true. However, there are branches that I have where this isn't applicable. Any clues on how to design branch-specific options for all these (there's branch.name.pullAction is a bit yuck)? Did I manage to cover everything? Now that pull.autostash is done, I will start writing pull.condition after feedback. * pull.rebase is pending deprecation -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] pull.default
Ramkumar Ramachandra artag...@gmail.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ITCH] pull.default
Junio C Hamano wrote: Ramkumar Ramachandra artag...@gmail.com 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 majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
