Jonathan Nieder wrote:
> Thanks for a pointer. Some ideas still at the "throw them against the
> wall and see if they stick" stage: please feel free to add to the page
> if you think you can find subsets with the right scope.
Some stuff off the top of my head, please apply a similar filter:
* Word-based merge helper
The existing merge algorithms are all tailored to line-based formats
such as code. Writing, e.g., LaTeX or even asciidoc requires
sticking to a strict word-wrapped format. Worse even, re-wrapping
leads to headaches if people work on the same areas a lot, much like
the effects of code reindents.
Something similar was already proposed in 2010, IIRC by Dscho:
https://git.wiki.kernel.org/index.php/SoC2010Ideas#Merge_helper_for_LaTeX_files
One possible angle of attack given --word-diff=porcelain would be:
1. Fix --word-diff to properly represent both sides of the diff at
least optionally. (It was observed in a list post some months
ago that it doesn't even represent *one* side faithfully.)
2. Use --word-diff=porcelain as input to some to-be-written merge
algorithm.
* Clean up add -p
git-add--interactive.perl became a bit of a mess. Partly due to my
own efforts with {checkout,stash,...} it has bolted-on interfaces to
other commands. There are some UI issues that simply fall out of
its design, e.g., you cannot go back from one file to another,
Ctrl-C stops applying to the current file but does not discard
earlier files, etc. And that's not saying anything about 'add -i'
which I don't really know.
This would probably not be a very fun project, but it could add a
little edge of usability to the tool and it's probably one of the
few pure-Perl ideas we can offer.
> 4. filter-branch killer: using fast-import's new features to implement
> common filter-branch operations (--subdirectory-filter,
> --prune-empty, obliterating certain files) faster.
I would phrase this as follows:
* fast-import-filter
Implement a utility that can execute certain transformations to
fast-import streams, such as:
- delete or rename entire files/directories
- split out subtrees
- ...
Ideally, this should be a thin command line interface around a set
of primitives (such as a Perl package) that allow a competent
scripter to go beyond the CLI. (There have been threads on this.)
Later on, make an interface that automatically does
git fast-export | fast-import-filter | git fast-import
with suitable options. Nice because it should be largely orthogonal
to everything except the fast-import stream format.
In addition, Jeff wrote:
> Yeah, I like that. Or maybe somebody can pick up git-sequencer, which in
> theory could be used to filter-branch, too (or maybe sequencer can go on
> top of fast-import? :) ).
I'd be interested to hear how that goes, because I think the tools are
fundamentally different. The rebase and thus sequencer family is
delta-based, and the fast-import and filter-branch families are
tree-based. Feel free to prove me wrong of course.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html