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

Re: [PATCH] rebase --fix: interactive fixup mode

From
Junio C Hamano <gitster@pobox.com>
Date
Jan 8, 2012, 22:58 UTC
Message-ID
<7vfwfpg5st.fsf@alter.siamese.dyndns.org>
In-Reply-To
<20120108213134.GA18671@ecki.lan>
Clemens Buchacher <drizzd@aon.at> writes:
Show 15 quoted lines
> Interactive rebase is frequently used not to rebase history, but to
> manipulate recent commits. This is typically done using the following
> command:
>
>  git rebase -i HEAD~N
>
> Where N has to be large enough such that the the range HEAD~N..HEAD
> contains the desired commits. At the same time, it should be small
> enough such that the range HEAD~N..HEAD does not include published
> commits or a merge commit. Otherwise, the user may accidentally change
> published history. Rebasing a merge commit can also have the generally
> undesirable effect of linearizing the merge history.
>
> In order to determine a suitable range automatically, it is a reasonable
> heuristic to rebase onto the most recent merge commit.

I understand the problem you are trying to solve, but I am not sure if this is a good idea from the UI point of view for two reasons.

 - "We want to limit the extent of the operation to commits since the last
   merge" is by itself a reasonable thing to ask, and I do not think it
   should be limited to "rebase". If we had an extended SHA-1 syntax to
   express it, for example, you may want to say "I want to see what I did
   since the last merge" and run "git log $last_merge_before_HEAD..".
   Perhaps HEAD~{merge} or something?
 - If your "rebase --fix" is to "fix" things, what is "rebase -i" about?
   Isn't it also about fixing? I imagine that ordinary people expect a
   "fix" option that takes a parameter would take a commit to be fixed,
   and drive the rebase machinery to quickly fix it; in other words,
	$ git rebase --fix=':/^reword the greeting message'
   may internally run "rebase -i $(git rev-parse ':/^rewor...')^", with
   the insn sheet already prepared to "edit" the first commit in it, and
   may even return the control back to the user without showing the insn
   sheet in the editor.
Hmm?
   
Previous: Jonathan NiederNext: Clemens Buchacher
Message 8 of 13 in “rebase --fix: interactive fixup mode”
  1. rebase --fix: interactive fixup modeClemens Buchacher, Jan 8, 2012
  2. Jakub NarebskiJan 8, 2012
  3. Clemens BuchacherJan 8, 2012
  4. Jonathan NiederJan 8, 2012
  5. Clemens BuchacherJan 8, 2012
  6. Nguyen Thai Ngoc DuyJan 9, 2012
  7. Jonathan NiederJan 9, 2012
  8. Junio C HamanoJan 8, 2012
  9. Clemens BuchacherJan 9, 2012
  10. Michael HaggertyJan 9, 2012
  11. Neal KreitzingerJan 10, 2012
  12. Thomas RastJan 9, 2012
  13. Clemens BuchacherJan 9, 2012

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.