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

Re: [PATCH 3/4] filter-branch: fix --prune-empty on parentless commits

From
Jeff King <peff@peff.net>
Date
Mar 3, 2017, 07:55 UTC
Message-ID
<20170303075535.rxij4knd7d4ayfev@sigill.intra.peff.net>
In-Reply-To
<xmqqshmvbhe5.fsf@gitster.mtv.corp.google.com>
On Thu, Mar 02, 2017 at 11:36:18AM -0800, Junio C Hamano wrote:
Show 22 quoted lines
> "Devin J. Pohly" <djpohly@gmail.com> writes:
> 
> > I think your point is interesting too, though.  If a commit is also
> > TREESAME to its parent(s?) in the _pre-filtered_ branch, it seems
> > reasonable that someone might want to leave it in the filtered branch as
> > an empty commit while pruning empt*ied* commits.  I would imagine that
> > as another option (--prune-newly-empty?).
> 
> I was hoping to hear from others who may care about filter-branch to
> comment on this topic to help me decide, but I haven't heard
> anything, so here is my tentative thinking.
> 
> I am leaning to:
> 
>  * Take your series as-is, which would mean --prune-empty will
>    change the behaviour to unconditionally lose the empty root.
> 
>  * Then, people who care deeply about it can add a new option that
>    prunes commits that become empty while keeping the originally
>    empty ones.
> 
> Thoughts?

Sorry, this was on my to-review list but the sha1 stuff has been much more exciting. :)

The behavior that Devin proposes is what I would have expected to happen. Between "prune-existing-empty" and "prune-became-empty", I've never had a use for the distinction. But as I think this is similar to the way cherry-pick distinguished between "redundant" and "empty", I guess some people have.

I agree that it should be a new, separate option, as it's orthogonal to dealing with the root commit (i.e., somebody is equally likely to want to preserve an already-empty commit from the middle of history).

The change to filter-branch itself looks obviously correct. The only objectionable thing I noticed in the test additions is that the early ones should be marked test_expect_failure until the fix from 3/4 flips them to "success". Otherwise it breaks bisectability.

-Peff
Previous: Jacob KellerNext: Devin J. Pohly
Message 10 of 15 in “t7003: ensure --prune-empty can prune root commit”
  1. 1/4 t7003: ensure --prune-empty can prune root commitDevin J. Pohly, Feb 23, 2017
  2. 2/4 t7003: ensure --prune-empty removes entire branch when applicableDevin J. Pohly, Feb 23, 2017
  3. 3/4 filter-branch: fix --prune-empty on parentless commitsDevin J. Pohly, Feb 23, 2017
  4. Junio C HamanoFeb 23, 2017
  5. Devin J. PohlyFeb 23, 2017
  6. Junio C HamanoMar 2, 2017
  7. Devin J. PohlyMar 2, 2017
  8. Junio C HamanoMar 2, 2017
  9. Jacob KellerMar 2, 2017
  10. Jeff KingMar 3, 2017
  11. Devin J. PohlyMar 3, 2017
  12. Junio C HamanoMar 3, 2017
  13. 4/4 p7000: add test for filter-branch with --prune-emptyDevin J. Pohly, Feb 23, 2017
  14. Jeff KingMar 3, 2017
  15. Devin J. PohlyMar 3, 2017

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.