{"thread":{"id":"33219","subject":"[ITCH] pull.default","startedAt":"2013-03-18T18:39:37Z","lastAt":"2013-04-13T21:54:56Z","messageCount":4,"participants":["Ramkumar Ramachandra","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"211590","messageId":"CALkWK0nT9hE_kRt3DLXfP45OwCSLurMOzuTqepxhkWjagbFDUQ@mail.gmail.com","threadId":"33219","inReplyTo":null,"subject":"[ITCH] pull.default","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-18T18:39:37Z","receivedAt":"2013-03-18T18:39:37Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Hi,\n\nI usually use `git fetch`, inspect state, and then merge/ rebase\naccordingly.  Unfortunately, this is very sub-optimal as I can\nautomate this 80% of the time.  I want to be able to decide what to do\non a repository-specific basis, and hence propose a pull.default which\ncan be set to the following:\n1. fetch.  Just fetch.  (I will set this as my default in ~/.gitconfig)\n2. fast-forward.  Fetch.  If the FETCH_HEAD is directly ahead of HEAD,\n`stash`, merge, and stash apply.  Otherwise, do nothing.\n3. rebase.  Fetch.  stash, rebase, stash apply. `git pull n` will do\nrebase --onto master HEAD~n instead of rebase.\n4. reset.  Fetch, stash, reset --hard FETCH_HEAD, stash apply.\n\nOfcourse, it should print a message saying what it did at the end.\n\nWhat do you think?\n\nRam\n"},{"id":"211592","messageId":"7vy5dkmt7k.fsf@alter.siamese.dyndns.org","threadId":"33219","inReplyTo":"CALkWK0nT9hE_kRt3DLXfP45OwCSLurMOzuTqepxhkWjagbFDUQ@mail.gmail.com","subject":"Re: [ITCH] pull.default","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-18T18:57:35Z","receivedAt":"2013-03-18T18:57:35Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Ramkumar Ramachandra <artagnon@gmail.com> writes:\n\n> I usually use `git fetch`, inspect state, and then merge/ rebase\n> accordingly.  Unfortunately, this is very sub-optimal as I can\n> automate this 80% of the time.  I want to be able to decide what to do\n> on a repository-specific basis, and hence propose a pull.default which\n> can be set to the following:\n> 1. fetch.  Just fetch.  (I will set this as my default in ~/.gitconfig)\n> 2. fast-forward.  Fetch.  If the FETCH_HEAD is directly ahead of HEAD,\n> `stash`, merge, and stash apply.  Otherwise, do nothing.\n> 3. rebase.  Fetch.  stash, rebase, stash apply. `git pull n` will do\n> rebase --onto master HEAD~n instead of rebase.\n> 4. reset.  Fetch, stash, reset --hard FETCH_HEAD, stash apply.\n>\n> Ofcourse, it should print a message saying what it did at the end.\n>\n> What do you think?\n\nMany other possibilities are missing.  \"fetch and merge\", for\nexample.\n\nYou seem to be generalizing the \"--rebase\" and \"--ff-only\" options\nof \"git pull\" with 2 and 3, which may (or may not) make sense.\n\nI think you can shrink and enhance the above repertoire at the same\ntime by separating \"do I want to have stash and stash pop around\"\nbit into an orthogonal axis.  The other orthogonal axes are \"Under\nwhat condition do I integrate the work from the upstream?\" (e.g.\n\"only when I do not have anything, aka, ff-only\") and \"How would I\nintegrate the work from the upstream?\" (e.g. \"rebase my work\" and\n\"discard anything I did aka reset --hard\").\n\nBy the way, I do not think you should start your design from a\nconfiguration (this is a general principle, not limited to this\ncase).  Think about what the smallest number of independent options\nyou need to add to express various workflows, and then turn them\ninto configuration variables that can set the default, all of which\nhave to be overridable from the command line.\n"},{"id":"211593","messageId":"CALkWK0kftNGt-xhLH8f+tVUNUF_qBDkTVcAEoiQKp_NRdPOftg@mail.gmail.com","threadId":"33219","inReplyTo":"7vy5dkmt7k.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] pull.default","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-03-18T19:21:24Z","receivedAt":"2013-03-18T19:21:24Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> Ramkumar Ramachandra <artagnon@gmail.com> writes:\n>\n>> I usually use `git fetch`, inspect state, and then merge/ rebase\n>> accordingly.  Unfortunately, this is very sub-optimal as I can\n>> automate this 80% of the time.  I want to be able to decide what to do\n>> on a repository-specific basis, and hence propose a pull.default which\n>> can be set to the following:\n>> 1. fetch.  Just fetch.  (I will set this as my default in ~/.gitconfig)\n>> 2. fast-forward.  Fetch.  If the FETCH_HEAD is directly ahead of HEAD,\n>> `stash`, merge, and stash apply.  Otherwise, do nothing.\n>> 3. rebase.  Fetch.  stash, rebase, stash apply. `git pull n` will do\n>> rebase --onto master HEAD~n instead of rebase.\n>> 4. reset.  Fetch, stash, reset --hard FETCH_HEAD, stash apply.\n>>\n>> Ofcourse, it should print a message saying what it did at the end.\n>>\n>> What do you think?\n>\n> Many other possibilities are missing.  \"fetch and merge\", for\n> example.\n>\n> You seem to be generalizing the \"--rebase\" and \"--ff-only\" options\n> of \"git pull\" with 2 and 3, which may (or may not) make sense.\n>\n> I think you can shrink and enhance the above repertoire at the same\n> time by separating \"do I want to have stash and stash pop around\"\n> bit into an orthogonal axis.  The other orthogonal axes are \"Under\n> what condition do I integrate the work from the upstream?\" (e.g.\n> \"only when I do not have anything, aka, ff-only\") and \"How would I\n> integrate the work from the upstream?\" (e.g. \"rebase my work\" and\n> \"discard anything I did aka reset --hard\").\n\nExcellent I was hoping to start a discussion like this.  My initial\nthought was designing a custom script that git-pull will execute like\na hook; we should, however, be able to get away with designing enough\nconfiguration orthogonal configuration variables.  For anything more\ncomplex, just do it by hand!\n\n> By the way, I do not think you should start your design from a\n> configuration (this is a general principle, not limited to this\n> case).  Think about what the smallest number of independent options\n> you need to add to express various workflows, and then turn them\n> into configuration variables that can set the default, all of which\n> have to be overridable from the command line.\n\nWill do.  Expect a draft soon.\n"},{"id":"214146","messageId":"CALkWK0kbsYgOy6KjcgZe8+cKucqzWPQ3wyp3SqaYy372pW0eFw@mail.gmail.com","threadId":"33219","inReplyTo":"7vy5dkmt7k.fsf@alter.siamese.dyndns.org","subject":"Re: [ITCH] pull.default","fromName":"Ramkumar Ramachandra","fromEmail":"artagnon@gmail.com","sentAt":"2013-04-13T21:54:56Z","receivedAt":"2013-04-13T21:54:56Z","isPatch":false,"sender":{"key":"r@artagnon.com","avatar":"https://avatars.githubusercontent.com/u/37226?v=4"},"body":"Junio C Hamano wrote:\n> I think you can shrink and enhance the above repertoire at the same\n> time by separating \"do I want to have stash and stash pop around\"\n> bit into an orthogonal axis.  The other orthogonal axes are \"Under\n> what condition do I integrate the work from the upstream?\" (e.g.\n> \"only when I do not have anything, aka, ff-only\") and \"How would I\n> integrate the work from the upstream?\" (e.g. \"rebase my work\" and\n> \"discard anything I did aka reset --hard\").\n\nOkay, so this is what I currently have:\n\n- pull.condition = clean-worktree | ff-update | no-local-changes |\nalways | never\n- pull.action = merge | rebase* | reset\n- pull.resetType = soft | hard | merge | keep\n- pull.autostash = true | false\n\n(ff-update is satisfied when FETCH_HEAD is directly ahead of\nrefs/remotes/<branch>, while no-local-changes is satisfied when\nFETCH_HEAD is directly ahead of refs/heads/<branch>)\n\nPersonally, I would love the defaults pull.condition = ff-update,\npull.action = rebase, pull.autostash = true.  However, there are\nbranches that I have where this isn't applicable.  Any clues on how to\ndesign branch-specific options for all these (there's\nbranch.<name>.pullAction is a bit yuck)?\n\nDid I manage to cover everything?  Now that pull.autostash is done, I\nwill start writing pull.condition after feedback.\n\n* pull.rebase is pending deprecation\n"}]}