Re: Summer of Code project ideas due this Friday

[Thomas Rast <trast@student.ethz.ch>]

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