From: Jonathan Nieder <jrnieder@gmail.com>
To: "Dmitry S. Kravtsov" <idkravitz@gmail.com>
Cc: git@vger.kernel.org, Jakub Narebski <jnareb@gmail.com>
Subject: Re: Features from GitSurvey 2010
Date: Sat, 29 Jan 2011 17:13:10 -0600 [thread overview]
Message-ID: <20110129231310.GA11088@burratino> (raw)
In-Reply-To: <AANLkTi=gf9_618iojpYJgN_msAe-FBq-Jao=sj76VQak@mail.gmail.com>
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.
For an alternative approach, Joey Hess's git-annex might be
interesting.
> 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.
> GitTorrent Protocol, or git-mirror
Sam Vilain and Jonas Fonseca did some good work on this, but it's
stalled.
> 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
> subtree clone
Nguyễn Thái Ngọc Duy and Elijah Newren have done some design and
prototyping work.
> support for tracking empty directories
Tricky to get the UI right. I am interested in and would be glad to
help with this one.
> environment variables in config
> better undo/abort/continue, and for more commands
These might involve nice "bite-sized" projects. Christian Couder
and Johannes Schindelin have discussed cherry-pick --abort/--continue
and they might be interested in patches on that subject. Stephen
Beyer's sequencer might be interesting for inspiration:
git://repo.or.cz/git/sbeyer.git
> '-n' like option for each command, which describes what would happen
> warn before/when rewriting published history
> git push --create
> "commands issued" (or "command equivalents") in git-gui / gitk
Go for it. "git init --remote" might be a good companion to "git push
--create".
> 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.
> 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.
> 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?
> 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.
> wholesame directory rename detection
Yann Dirson wrote a patch. It needs some polishing (I'd be glad to
help --- it would be exciting to see this move forward).
> union checkouts (some files from one branch, some from other)
Not sure I understand the use case?
> 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.
> built-in gitjour/bananajour support
A good start might be to submit one or both of these to contrib?
> better support for submodules
Jens Lehmann has done some great work on this and presumably would
be happy for help.
https://github.com/jlehmann/git-submod-enhancements/wiki
Hope that helps,
Jonathan
next prev parent reply other threads:[~2011-01-29 23:13 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-29 10:01 Features from GitSurvey 2010 Dmitry S. Kravtsov
2011-01-29 23:13 ` Jonathan Nieder [this message]
2011-02-01 13:51 ` Jakub Narebski
2011-02-01 15:52 ` Nguyen Thai Ngoc Duy
2011-02-01 16:33 ` Shawn Pearce
2011-02-01 16:27 ` Shawn Pearce
2011-02-01 17:05 ` Nguyen Thai Ngoc Duy
2011-02-01 21:27 ` Junio C Hamano
2011-02-01 21:44 ` Nicolas Pitre
2011-02-01 17:11 ` Nguyen Thai Ngoc Duy
2011-02-01 17:34 ` Shawn Pearce
2011-02-01 21:51 ` Nicolas Pitre
2011-02-02 0:26 ` Shawn Pearce
2011-02-02 2:11 ` Nicolas Pitre
2011-02-02 2:23 ` david
2011-02-03 14:38 ` Geert Bosch
2011-02-03 17:39 ` Narrow clone (Re: features from GitSurvey 2010) Jonathan Nieder
2011-02-03 21:23 ` Geert Bosch
2011-02-03 21:33 ` Jonathan Nieder
2011-02-03 21:38 ` Jonathan Nieder
2011-02-03 21:33 ` Features from GitSurvey 2010 Nicolas Pitre
2011-02-01 17:28 ` Tracking empty directories Jonathan Nieder
2011-02-01 17:54 ` Nguyen Thai Ngoc Duy
2011-02-01 18:15 ` Ilari Liusvaara
2011-02-01 18:31 ` Jakub Narebski
2011-02-01 19:09 ` Ilari Liusvaara
2011-02-01 18:35 ` Jonathan Nieder
2011-02-01 19:03 ` Jakub Narebski
2011-02-02 3:54 ` Nguyen Thai Ngoc Duy
2011-02-02 12:31 ` Kevin P. Fleming
2011-02-01 21:36 ` Features from GitSurvey 2010 Nicolas Pitre
2011-02-01 22:50 ` big files in git was: " david
2011-02-03 6:25 ` Nicolas Pitre
2011-02-01 17:44 ` Matthieu Moy
2011-02-01 18:42 ` Jonathan Nieder
2011-02-01 20:23 ` Matthieu Moy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110129231310.GA11088@burratino \
--to=jrnieder@gmail.com \
--cc=git@vger.kernel.org \
--cc=idkravitz@gmail.com \
--cc=jnareb@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).