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

Re: [PATCH] Add git-filter-branch

From
Johannes Sixt <j.sixt@eudaptics.com>
Date
Jun 5, 2007, 07:01 UTC
Message-ID
<46650A58.4934C07C@eudaptics.com>
In-Reply-To
<Pine.LNX.4.64.0706041850350.4046@racer.site>
Johannes Schindelin wrote:
Show 13 quoted lines
> On Mon, 4 Jun 2007, Johannes Sixt wrote:
> > But this makes only sense if you have a linear history. Consider this
> > history, where you want to rewrite the commits that are only on branch
> > 'next':
> >
> > --A--B--C--D--E--F--G--H       <- master
> >    \  \  \  \  \  \  \  \
> >     X--o--o--o--o--o--o--o--o  <- next
> >
> > How would you go about with the current calling convention?
> 
> Are you actually sure that this scenario makes sense? When is the last
> time you wanted to filter a branch?

Oh, this makes a lot of sense. For example after I've imported a CVS repository I had installed grafts for a number of merges that were made in CVS (but we all know that CVS doesn't record them, so I did that manually this way). That would be the merge commits in 'next' of the example above. Now a simple

   git filter-branch -k master new-next

could "implant" the grafts into the commits. In this scenario I don't need to rewrite 'master' because I know in advance that nothing would actually be rewritten.

(Since 'master' was about 8000 commits I really didn't want to wait until the no-ops would be completed, so I did it by actually fixing cg-admin-rewritehist to not complain about the unmapped parents.)

> In any case, for such a degenerated test case I would rather try to limit
> filtering in the filter expression. Remember: you don't have to change
> _every_ commit.
I don't think that this is a degenerate case. See the example above.

Please observe that the only reasonable way to limit the commits to rewrite is by giving some --not arguments to the rev-list. The filter scriptlets themselves have no easy way to tell whether a commit should be rewritten or not. They just rewrite - with the final result perhaps ending up identical to the original; but no labor was saved.

-- Hannes
Previous: Johannes SchindelinNext: Johannes Schindelin
Message 18 of 27 in “Add git-filter-branch”
  1. Add git-filter-branchJohannes Schindelin, Jun 3, 2007
  2. Jakub NarebskiJun 3, 2007
  3. Johannes SchindelinJun 3, 2007
  4. Jakub NarebskiJun 3, 2007
  5. Steven GrimmJun 3, 2007
  6. Johannes SchindelinJun 3, 2007
  7. Jonas FonsecaJun 5, 2007
  8. David KastrupJun 5, 2007
  9. Junio C HamanoJun 5, 2007
  10. Jonas FonsecaJun 5, 2007
  11. Johannes SchindelinJun 5, 2007
  12. filter-branch: use $(($i+1)) instead of $((i+1))Johannes Schindelin, Jun 6, 2007
  13. Johannes SixtJun 4, 2007
  14. Johannes SixtJun 4, 2007
  15. Johannes SchindelinJun 4, 2007
  16. Johannes SixtJun 4, 2007
  17. Johannes SchindelinJun 4, 2007
  18. Johannes SixtJun 5, 2007
  19. Johannes SchindelinJun 5, 2007
  20. Johannes SixtJun 6, 2007
  21. Junio C HamanoJun 6, 2007
  22. Johannes SchindelinJun 6, 2007
  23. Johannes SixtJun 6, 2007
  24. Johannes SchindelinJun 6, 2007
  25. filter-branch: also don't fail in map() if a commit cannot be mappedJohannes Sixt, Jun 6, 2007
  26. Johannes SchindelinJun 6, 2007
  27. filter-branch: also don't fail in map() if a commit cannot be mappedJohannes Sixt, Jun 6, 2007

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.