On Sun, 30 Jan 2011, Jonathan Nieder wrote:
> Hi Dmitry,
>
> Dmitry S. Kravtsov wrote:
>
> > I want to dedicate my coursework at University to implementation of
> > some useful git feature. So I'm interesting in some kind of list of
> > development status of these features
> [...]
> > Or I'll be glad to know what features are now 'free' and what are
> > currently in active development.
>
> Interesting question. The short answer is that they are all "free".
> Generally people seem to be happy to learn of an alternative approach
> to what they have been working on.
>
> [For the following pointers, the easiest way to follow up is probably
> to search the mailing list archives.]
>
> > better support for big files (large media)
>
> For a conservative approach, you might want to get in touch with Sam
> Hocevar, Nicolas Pitre, and Miklos Vajna. The idea is to stream big
> files directly to pack and not waste time trying to compress them.
There is also, supposedly stalled, git-bigfiles project.
>
> For an alternative approach, Joey Hess's git-annex might be
> interesting.
Note that this feature would not be easy to implement; you would need
both quite good knowledge of git internals, and some realistic use case
that you can test performance of your improvements with.
> > resumable clone/fetch (and other remote operations)
>
> Jakub Narebski seems to be interested in this and Nicolas Pitre has
> given some good advice about it. You can get something usable today
> by putting up a git bundle for download over HTTP or rsync, so it is
> possible that this just involves some UI (porcelain) and documentation
> work to become standard practice.
I wouldn't say that: it is Nicolas Pitre (IIRC) who was doing the work;
I was only interested party posting comments, but no code.
Again, this feature is not very easy to implement, and would require
knowledge of git internals including "smart" git transport ("Pro Git"
book can help there).
> > GitTorrent Protocol, or git-mirror
>
> Sam Vilain and Jonas Fonseca did some good work on this, but it's
> stalled.
There was some recent discussion on this on git mailing llist, but
without any code.
One would need to know similar areas as for "resumable clone" feature.
Plus some knowledge on P2P transport in GitTorrent case.
> > lazy clone / on-demand fetching of object
>
> There's a patch. As is, it is not likely to be useful outside
> specialized circumstances imho.
>
> http://thread.gmane.org/gmane.comp.version-control.git/73117
One would need to know about how git checks for consistency, e.g. via
git-fsck for that.
> > subtree clone
>
> Nguyán ThÃi Ngác Duy and Elijah Newren have done some design and
> prototyping work.
Git mailing list archives should contain proof of concept / RFC patches
for this feature. Quite interesting.
> > support for tracking empty directories
>
> Tricky to get the UI right. I am interested in and would be glad to
> help with this one.
Also one needs to remember that this would require adding extension
to git index, because currently it tracks only files, and not
directories. Explicitly tracking directories in the index could be
useful for other purposes...
The major difficulty of this is IMHO not the UI, but tracking all those
tricky corner cases (like directory/file conflict, etc.).
[...]
> > side-by-side diffs and/or color-words diff in gitweb
> > admin and/or write features in gitweb
> > graphical history view in gitweb
>
> There may or may not have been design work on some of these for Pavan
> Kumar Sunkara's last summer of code project. John 'Warthog9' Hawley,
> Jakub Narebski, and Petr Baudis might have advice.
Pavan was to work on admin and/or write features in gitweb, while he
didn't even finish splitting gitweb (perhaps he tried to be too
ambitious in trying to split whole of gitweb at once, instead of
splitting-off well definied pieces?).
There are existing Perl modules on CPAN and/or Perl web apps that use
side-by-side diffs and/or color-words diff, so there is code to take an
example, to use in gitweb, or to borrow.
The graphical history view would be more difficult, but not very
difficult, I think. You would have to decide how to draw a graph:
should gitweb generate image on the fly, use some smart combination
of CSS and pre-made images (perhaps with transparency), use Unicode
graph characters, or use ASCII-art graph. You would also have to decide
whether to use or base on some existing algorithm to generate graph,
borrowing from tig, git-browser, gitk or git-forest (the last is in
Perl, like gitweb), or whether to make use of "git log --graph" output.
> > GUI for rebase in git-gui
> > GUI for creating repository in git-gui
> > graphical diff/merge tool integrated with git-gui
> > syntax highlighting in git-gui
>
> Pat Thoyts is probably the one to talk to.
Note that for graphical diff/merge tool you should be able to borrow
from xxdiff graphical diff/merge tool, which is also written in Tcl/Tk.
> > filename encoding (in repository vs in filesystem)
>
> This is important for the Windows port and likely to be a nuisance
> on Unix. I think there has been some work on it on the msysgit list?
That would need a good design (note also different forms of Unicode),
and overcoming inertia.
> > localization of command-line messages (i18n)
>
> Ãvar ArnfjÃrà Bjarmason did some work which is in pu. It needs
> some polishing. I am also interested.
I don't know how much is left to do (beside actually translating
messages). But this series could use a little help.
> > union checkouts (some files from one branch, some from other)
>
> Not sure I understand the use case?
I don't know if it would be really useful, but the concept is similar to
union mounts. In union mount (unionfs, aufs,...) you can e.g. mount
CD-ROM read-only, and over it overlay on some read-write filesystem.
The idea is to have some files (some directories) in working area come
from one branch, some from other branch, persistently in some way. Not
sure if it would be actually useful.
> > advisory locking / "this file is being edited"
>
> Probably better to implement out of band (using hooks?). I don't
> know of any work or documentation in that direction.
Yes, t would probably be best as external project, only with git
integration.
> > built-in gitjour/bananajour support
>
> A good start might be to submit one or both of these to contrib?
If I remember correctly there are some third-party extensions to be
found, and perhaps even some patches in git mailing list.
Best choose something you are both interested in, and proficient with.
HTH
--
Jakub Narebski
Poland
--
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