Re: [PATCH] git filter-branch: Process commits in --date-order
- From
Junio C Hamano <gitster@pobox.com>
- Date
- Mar 3, 2009, 00:51 UTC
- Message-ID
- <7vbpsjl97d.fsf@gitster.siamese.dyndns.org>
- In-Reply-To
- <alpine.DEB.1.00.0903030126530.10279@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Show 15 quoted lines
> On Tue, 3 Mar 2009, Peter Rosin wrote: > >> When converting an svn repository to git, I am filtering the commits >> using --msg-filter. During this conversion I want to use the >> .git-rewrite/map data to fill in references to other commits. In the >> svn repo, there is a commit message e.g. "Cherry-pick r207", and I >> want to append "r207 = <commit>" to the git commit message, as r207 >> no longer means very much. This works fine when the git commit >> corresponding to r207 has been filtered before the current commit, and >> is present in the map. When filtering in --topo-order, this is not >> always the case, making it impossible to look up the git commit. > > I'd rather have this as an option. God knows what breaks with time-skewed > repositories if you use date-order instead of topo-order, and I'd rather > not break that not quite uncommon case.
I am wondering if it even makes sense to allow users to disable topological ordering.
Doesn't filter-branch have the same "child commits build on top of parent commits" dependency as fast-export has? And didn't you guys fix fast-export recently?