Random Git Issues/Wishlist

[Petr Baudis <pasky@suse.cz>]

  Hi,

  this is a random list of issues that come up in my mind when I was
thinking about things we could discuss at the Git BOF at OLS in case
enought Git developers gathered - which of course didn't happen but
perhaps it might be useful to mention them as well. Feel free to follow
up with *your* stuff (and comments or patches, of course).

  (i) libgit - right now it has just evolved from bundling random Git
internal calls and has no defined API whatsoever; luckily, nothing
external hopefully uses it yet. If we wait much longer, people will
probably start to and we might start getting into a trouble there.
Another thing is what to do with the builtins, shall we bundle most of
the code in libgit? If not, many libgit users will probably end up just
reimplementing large chunks of their functionality. I've actually
thought about also interfacing libbuiltin.so when doing Git.pm but I
didn't yet for the sake of simplicity.

  (ii) Documentation - it's currently very bad. Incomplete, out of sync,
missing tons of parameters and other things, and so on. We should be
more responsible when adding features to always document them right
away.

  (iii) Lazy clone, shallow clone, whatever you call it. This has
several possible degrees of implementation:

	(a) Just being able to get the latest revision (this really
	    shouldn't be that hard to do)
	(b) Arbitrarily cut off the revisions at some point; this means
	    that you will get _some_ repository but with incomplete
	    history and we should handle that sensibly, like...
	(c) ...having kind of "remote alternates", which means that if
	    we hit an object we don't have we will look it remotely as
	    well; this means moving the remote access functions much
	    more inside the really core Git; we want to be smart and
	    e.g. bundle tree requests with all the msisingblob requests
	    and so on; we don't want to fetch *everything* when the
	    user just does git log, though
	(d) As an extension of (a), having some side of server-client
	    stuff which would also know how to do rev-lists and such
	    remotely; I'm not sure if the demand here is big enough
	    to justify that

  (iv) Packing - I really feel bad about requiring users to manually
repack periodically, and also that's hurting the dumb server users
unless you take special provisions and so on

  (v) Subprojects support; in a sort of long-term limbo because I guess
everyone is too lazy to finally implement something and the users aren't
loud enough ;-) (or they just moved on to another VCS)

  (vi) Renames - should we follow them in logs? Will we? When? How
exactly in the interesting cases?

  (vii) Private tags. refs/private or refs/tags/.hidden? Will we even?
When?

  (viii) Patches versioning in StGit - many people I've told about StGit
complained that it doesn't version patches (and possibly moved to mq?).
We should have some scheme for doing meta-history (especially
interesting when/if we aim to make altering history easy).

  (ix) What about the user survey? It sorta stalled, as far as I can
see.

  (x) Metainformation over the Git protocol - kernel.org wants this
badly because rsyncing the repositories leads to *endless* problems;
there are some more complicated rsync schemes possible but hpa would be
happiest with making it possible to just use git to sync the
repositories out; this might be in part dependent on (iv) since the
repository maintainers basically lose control over the packing

  (xi) Annotate or blame? Most people seem to be in favour of blome,
but having both is confusing; by now one of them should've already won.

  (xii) Special merging - I now maintian the SuSE glibc package in git
and I'd like to use something more sensible than diff3 merger for
merging the changelogs from various branches; it's trivially solvable
conflicts all the time

  (xiii) General user interface issues, like confusing error messages,
incomplete usage help, needlessly complicated (see our git init
discussion in the other thread) or inconsistent usage (git rebase,
anyone?) in general and other stuff aside of (ii).

  That's probably all you'll hear from me for now, I guess. It's your
turn now.

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam