git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/3] pull: introduce --[no-]autostash and pull.autostash

From
Ramkumar Ramachandra <artagnon@gmail.com>
Date
Apr 15, 2013, 16:45 UTC
Message-ID
<CALkWK0nrVZo3MSgqpPmX2+T3JJ8uP=hzH3PMv+qd4ZaqNVwEsw@mail.gmail.com>
In-Reply-To
<vpqwqs3lqlf.fsf@grenoble-inp.fr>
Matthieu Moy wrote:
> No, you don't. Just try if you're not convinced:

Oh, I trusted the documentation on this one and never tried with a dirty worktree myself. Please fix the documentation, if you know how exactly to correct it.

Show 6 quoted lines
> No, I'm not proposing to do anything for merge. There's no reason to try
> being uniform in conflict resolution for pull-merge and pull-rebase as
> it is already different now. We already have "git rebase --continue", we
> don't have "git merge --continue". So what? The fact that merge doesn't
> have the equivalent doesn't mean we should not do something for "rebase
> --continue".
Well, you can't blame me for the misunderstanding then.
In a previous email, you wrote:
> Shouldn't this belong to "git merge" instead (i.e. implement "git merge
> --autosquash" and call it from "git pull")? Users doing "git fetch &&
> git merge" by hand should be able to use --autosquash, I think.

Junio's criticism of pull.autostash hurting pull-merge people is cogent; my current plan is to ditch pull.autostash altogether, and implement rebase.autostash for the reduced case of a non-interactive rebase.

Previous: Junio C HamanoNext: John Keeping
Message 25 of 44 in “Introduce pull.autostash”
  1. 0/3 Introduce pull.autostashRamkumar Ramachandra, Apr 13, 2013
  2. 1/3 pull: prefer invoking "git <command>" over "git-<command>"Ramkumar Ramachandra, Apr 13, 2013
  3. Philip OakleyApr 14, 2013
  4. 2/3 t5521 (pull-options): use test_commit() where appropriateRamkumar Ramachandra, Apr 13, 2013
  5. 3/3 pull: introduce --[no-]autostash and pull.autostashRamkumar Ramachandra, Apr 13, 2013
  6. Junio C HamanoApr 15, 2013
  7. Ramkumar RamachandraApr 15, 2013
  8. Junio C HamanoApr 15, 2013
  9. Ramkumar RamachandraApr 15, 2013
  10. Matthieu MoyApr 15, 2013
  11. Junio C HamanoApr 15, 2013
  12. Matthieu MoyApr 15, 2013
  13. Ramkumar RamachandraApr 15, 2013
  14. Matthieu MoyApr 15, 2013
  15. Ramkumar RamachandraApr 15, 2013
  16. Matthieu MoyApr 15, 2013
  17. Ramkumar RamachandraApr 15, 2013
  18. Jonathan NiederApr 16, 2013
  19. Ramkumar RamachandraApr 15, 2013
  20. Matthieu MoyApr 15, 2013
  21. Ramkumar RamachandraApr 15, 2013
  22. Ramkumar RamachandraApr 15, 2013
  23. Matthieu MoyApr 15, 2013
  24. Junio C HamanoApr 15, 2013
  25. Ramkumar RamachandraApr 15, 2013
  26. John KeepingApr 15, 2013
  27. Ramkumar RamachandraApr 15, 2013
  28. Jonathan NiederApr 16, 2013
  29. Ramkumar RamachandraApr 16, 2013
  30. Jonathan NiederApr 16, 2013
  31. Junio C HamanoApr 15, 2013
  32. Ramkumar RamachandraApr 15, 2013
  33. Junio C HamanoApr 15, 2013
  34. Ramkumar RamachandraApr 15, 2013
  35. John KeepingApr 15, 2013
  36. Matthieu MoyApr 15, 2013
  37. Ramkumar RamachandraApr 16, 2013
  38. Matthieu MoyApr 16, 2013
  39. Ramkumar RamachandraApr 16, 2013
  40. Matthieu MoyApr 16, 2013
  41. Matthieu MoyApr 16, 2013
  42. Junio C HamanoApr 16, 2013
  43. Phil HordApr 16, 2013
  44. Ramkumar RamachandraApr 16, 2013

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.