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

Re: [PATCH] New git-seek command with documentation and test.

From
Junio C Hamano <junkio@cox.net>
Date
Feb 24, 2006, 11:38 UTC
Message-ID
<7vvev5aswm.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<43FED93D.1000601@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> I've said it before, and I'll say it again. This tool provides less
> flexibility and much less power than "git checkout -b branch
> <commit-ish>" (although it would be nice to have '-o' for 'overwrite
> existing branch' as an argument to git checkout)

True, but assembly provides more flexibility than higher level languages and you need to strike a balance between power and usability.

The real question is if the structure the tool enforces to your workflow is simply being a straight-jacket or helping an average user to avoid common mistakes.

One occasion I've felt the need for "seek" like feature was when starting to bisect. You usually notice breakage, so you can start with "git bisect bad HEAD", but then what next? You usually are not absolutely sure which one _was_ working the last time.

If I had a seek, then I could go back to some randomly chosen version to try it out, going back until I find a good one.

Maybe "git bisect try $committish" would be a good addition. We could live without it (we can just say "git reset --hard $committish"), but it can be a bit more than just that. If given committish is known to be good or bad, we could remind the user what she said the last time, and offer a chance to take it back. That is, (1) if the given $committish is an ancestor of existing good one, list those good ones and ask "do you mean you are not sure if they are good anymore, and retry the bisection?" If yes, delete those good-* refs; (2) if the given $committish is a descendant of a bad one, show it and ask "do you mean you are not sure if they are good anymore, and retry the bisection?" If yes, remove the existing bad ref. In any case, "reset --hard" to it after user responds.

Other than that, I haven't felt a need for seek-like feature; instead, I make liberal use of throw-away branches.

Previous: Andreas EricssonNext: Carl Worth
Message 26 of 57 in “several quick questions”
  1. Nicolas Vilz 'niv'Feb 14, 2006
  2. Andreas EricssonFeb 14, 2006
  3. Nicolas Vilz 'niv'Feb 14, 2006
  4. Linus TorvaldsFeb 14, 2006
  5. Kenneth JohanssonFeb 14, 2006
  6. Andreas EricssonFeb 14, 2006
  7. Kenneth JohanssonFeb 14, 2006
  8. Linus TorvaldsFeb 14, 2006
  9. Carl WorthFeb 14, 2006
  10. Linus TorvaldsFeb 14, 2006
  11. Carl WorthFeb 14, 2006
  12. Petr BaudisFeb 14, 2006
  13. Johannes SchindelinFeb 14, 2006
  14. Junio C HamanoFeb 14, 2006
  15. Johannes SchindelinFeb 14, 2006
  16. Petr BaudisFeb 14, 2006
  17. Linus TorvaldsFeb 14, 2006
  18. Petr BaudisFeb 14, 2006
  19. Carl WorthFeb 14, 2006
  20. Junio C HamanoFeb 14, 2006
  21. New git-seek command with documentation and test.Carl Worth, Feb 23, 2006
  22. J. Bruce FieldsFeb 24, 2006
  23. git-seek: Eliminate spurious warning. Fix errant reference to git-bisect in docs.Carl Worth, Feb 24, 2006
  24. Junio C HamanoFeb 24, 2006
  25. Andreas EricssonFeb 24, 2006
  26. Junio C HamanoFeb 24, 2006
  27. Carl WorthFeb 24, 2006
  28. Johannes SchindelinFeb 24, 2006
  29. J. Bruce FieldsFeb 24, 2006
  30. Josef WeidendorferFeb 14, 2006
  31. Junio C HamanoFeb 14, 2006
  32. Josef WeidendorferFeb 14, 2006
  33. Junio C HamanoFeb 14, 2006
  34. More useful/hinting error messages in git-checkoutJosef Weidendorfer, Feb 15, 2006
  35. Andreas EricssonFeb 14, 2006
  36. Johannes SchindelinFeb 14, 2006
  37. Andreas EricssonFeb 15, 2006
  38. Junio C HamanoFeb 15, 2006
  39. Junio C HamanoFeb 15, 2006
  40. Andreas EricssonFeb 15, 2006
  41. Junio C HamanoFeb 15, 2006
  42. Petr BaudisFeb 14, 2006
  43. Carl WorthFeb 14, 2006
  44. Linus TorvaldsFeb 14, 2006
  45. Andreas EricssonFeb 14, 2006
  46. Johannes SchindelinFeb 14, 2006
  47. Carl WorthFeb 14, 2006
  48. Keith PackardFeb 14, 2006
  49. Linus TorvaldsFeb 14, 2006
  50. Keith PackardFeb 14, 2006
  51. Martin LanghoffFeb 15, 2006
  52. Keith PackardFeb 15, 2006
  53. Carl WorthFeb 15, 2006
  54. Junio C HamanoFeb 14, 2006
  55. Petr BaudisFeb 14, 2006
  56. Cogito turbo-introductionPetr Baudis, Feb 15, 2006
  57. Petr BaudisFeb 15, 2006

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.