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

Re: odd behavior with git-rebase

From
Neil Horman <nhorman@tuxdriver.com>
Date
Mar 24, 2012, 16:55 UTC
Message-ID
<20120324165536.GA17932@neilslaptop.think-freely.org>
In-Reply-To
<7vvclvrrad.fsf@alter.siamese.dyndns.org>
On Fri, Mar 23, 2012 at 01:33:30PM -0700, Junio C Hamano wrote:
Show 8 quoted lines
> Neil Horman <nhorman@tuxdriver.com> writes:
> 
> > I know that git cherry-pick allows for picking of empty commits, and it appears
> > the rebase script uses cherry-picking significantly, so I'm not sure why this
> > isn't working, or if its explicitly prevented from working for some reason.
> 
> The primary purpose of "rebase" is (or at least was when it was conceived)
> to clean up the existing history, and a part of the cleaning up is not to

I can understand that, although IMHO it seems equally usefull as a tool for simply doing what its name implies, moving a history to a new starting point, e.g. to plainly rebase it. Thats the use that I have for it anyway.

Show 6 quoted lines
> replay a patch that ends up being empty.  Even though we try to omit an
> already applied patch by using "git cherry" internally when choosing which
> commits to replay, a commit that by itself is *not* empty could end up
> being empty when a similar change has already been made to the updated
> base, and we do want to omit them.
>

Is there a way to differentiate a commit that is made empty as the result of a previous patch in the rebase, and a commit that is simply empty?

> A commit that is empty (i.e. --allow-empty) by itself was a much later
> invention than the basic rebase logic, and the rebase may want to be
> updated to special case it, but as the default behaviour it is doing the
> right thing by not letting an empty commit into the cleaned up history.

I agree, I think perhaps adding an --allow-empty option to the rebase logic, so that empty commits (or perhaps just initially empty, as opposed to commits made empty) would be very beneficial. 

Thanks all, I'll start trying to pick through the rebase logic this week.

Best Neil

> 
> 
>
Previous: Junio C HamanoNext: Junio C Hamano
Message 6 of 17 in “odd behavior with git-rebase”
  1. Neil HormanMar 23, 2012
  2. Jeff KingMar 23, 2012
  3. Phil HordMar 26, 2012
  4. Jeff KingMar 26, 2012
  5. Junio C HamanoMar 23, 2012
  6. Neil HormanMar 24, 2012
  7. Junio C HamanoMar 26, 2012
  8. Neil HormanMar 26, 2012
  9. Neal KreitzingerMar 26, 2012
  10. Phil HordMar 26, 2012
  11. Phil HordMar 26, 2012
  12. Neil HormanMar 26, 2012
  13. Jay SoffianMar 27, 2012
  14. Neal KreitzingerMar 26, 2012
  15. Neil HormanMar 26, 2012
  16. Phil HordMar 28, 2012
  17. Junio C HamanoMar 28, 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.