Hackontest ideas?

  Hi,

  participating in this might be fun, even if there is not much time
left to sign up:

	http://www.hackontest.org/index.php?action=Root-projectDetail(120)

(What feature in Git or a Git-related tool would you implement, given 24 hours staight and unlimited pizza supply?)

  P.S.: Disclaimer - yes, if someone suggests something cool enough to
do with Git, I might apply. ;-)

On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> wrote:

Restartable git-clone? :-)

It was a GSoC idea this year, but in the end nobody started working on it.

(I was about to work on it, but finally my 'builtin-merge' application was accepted.)

Miklos Vajna <vmiklos@frugalware.org> wrote:

Yea, we eventually decided it was probably too small for a GSoC project. Given how quickly you put together your git-merge project, I'm actually happy we got you working on git-merge and not restartable clone, as I think you may have finished restartable clone in 24 hours and then said "now what mr. mentor?" ;-)

Pasky, et.al.:

How about smart fetch/push over HTTP? E.g. a CGI (or extension to gitweb) that does native pack transport over HTTP rather than dumb object traversal with GET and WebDAV LOCK/PUT. Note that the push side doesn't need to support tell-me-more extension, making it a fairly trivial GET, POST (or PUT) sequence.

On Mon, Jul 28, 2008 at 10:31:10PM -0700, Shawn O. Pearce wrote:

Ah, thanks for reminding me about this, nice!

Thanks all for their suggestions so far, I have added all of them plus an extra. Now, if you want them implemented, some of you need to join as implementers and the features need to get a lot of votes quickly! ;-))

(Frankly, I don't think there is really any chance to make it, but I think having such a list of mid-size self-contained tasks might be useful for other occasions, so I will haul it over to the wiki after the deadline.)

				Petr "Pasky" Baudis

On Mon, Jul 28, 2008 at 5:01 PM, Petr Baudis <pasky@ucw.cz> wrote:

It might be cool if git-daemon supported avahi/zeroconf/bonjour/rendezvous as a server and maybe git-status(? or maybe a new command) had a flag that could make it an avahi client and list repositories on the local network being advertised over avahi.

It looks like bzr has an avahi plugin. Not sure whether it would be a useful feature for people. What do other folks think?

As a project, it seems fairly self-contained and well defined, and might be doable for a small team in 24 hours.

-Tarmigan

Petr Baudis <pasky@ucw.cz> writes:

"Use 'assume unchanged' bit to implement narrow checkout".

On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:

I think Nguyen Thai Ngoc Duy is already working on this? (Though I think he does not use the assume unchanged bit; but this will be likely done before the end of September.)

(This is a bit annoying, by the way - the deadline is way too early...)

				Petr "Pasky" Baudis

On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:

You are welcome to do ;) I got to narrow checkout from subtree checkout where 'assume unchanged' bit was unapplicable so my approach is a bit different, but probably 'assume unchanged' bit is the right way to go.

On Tue, Jul 29, 2008 at 08:55:32AM +0700, Nguyen Thai Ngoc Duy wrote:

But I rather liked the elegancy of just narrowing this down to a particular subtree. Is there really a good reason to generalize this further?

				Petr "Pasky" Baudis

On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:

I think because it's doable and people do need to narrow to more than one subtree sometimes. Also it would solve ".git* in parent directories" problem that is really hard if you strictly do "narrow down to a particular subtree".

Petr Baudis <pasky@ucw.cz> writes:

"git-merge-blame" (http://git.or.cz/gitwiki/SoC2007Ideas#head-cfde15f16950c2579a89cc109762e911546e6fe3).

Petr Baudis <pasky@ucw.cz> writes:

A few ideas (some might be repeated)
 * resumable clone
 * git-push implemented as CGI
 * support for ftp, ftps, sftp fetch
 * support for gits (git over SSL/TLS) fetch
 * relative blame, i.e. if you have blame data for some revision
   (for example in "git gui blame") you want to have data for some
   revision which is either direct ancestor or direct descendant
   of the revision you have blame data for, aka "git blame --relative"
 * "tree" blame, i.e. something like VievVC or GitHub shows:
   for exach entry in a tree commit which brought it to current version
 * graph log for gitweb, either generating images on the fly, or using
   a few pre-defined images ('|', '-', '\', '/', etc.) and CSS.
 * "MediaWiki history"-like or "MoinMoin info"-like view for gitweb
 * improvements to "git log --follow" so it works also for nonlinear
   history (for example "git log --follow gitweb/gitweb.perl" following
   to the very first version of gitweb, then as gitweb.cgi)
 * graphical history viewer for Git mode in Emacs.
 * context sensitive searching in gitweb, for example searching
   commits on given branch, or grepping files in given directory
 * handling of svn:externals using submodules
 * custom merge strategy for ChangeLog, for .po files

Blame merge strategy would take probably much more that 24h solely in the initial design phase...

Hi,

On Tue, 29 Jul 2008, Jakub Narebski wrote:

I doubt that this is easy. Otherwise, Eric would have done it a long time ago.

The main concern I have is to get the semantics right: AFAICT svn:externals has _no notion_ of "what is current". It just _always_ fetches the HEAD. Even if you check out an ancient revision in the "superproject".

Ciao, Dscho

Johannes Schindelin wrote:

Yeah, I guess is too large a project for Hackontest.
 

If I understand correctly with version 1.5 svn:externals can be specified using "peg revisions", so they could refer to some specific revision of 'external', like git submodules.

Hi,

On Tue, 29 Jul 2008, Jakub Narebski wrote:

... which only means that if they had done that from the beginning, it the git-svn enhancement would be easy.

But as they did not have it from the beginning, anybody tackling git-svn and svn:externals will have to come up with sensible semantics for the hard case.

Ciao, Dscho

On 7/29/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

One option would be to simply attach the submodule to the "latest commit of the svn:external at the time the supermodule svn commit was made". Basically, enforce git-submodule's precise revision feature retroactively onto svn:externals.

I think this would be perfectly fine in my own projects, for example: it's what I wanted in the first place, but svn didn't have this feature, so I faked it by branching/tagging the external repo whenever I wanted to link to a particular revision.

Have fun,

Avery

On Tue, Jul 29, 2008 at 01:56:37PM +0200, Johannes Schindelin wrote:

Usually, yes. But you could specify a specific revision with -r <rev>.

Or, for branches/tags, as they're paths, a correct url would suffice.

With the new 1.5, it is also possible to specify pegged revisions. Much better, because otherwise subversion would require that the path existed in the server in HEAD.

Hi,

On Tue, 29 Jul 2008, Luciano Rocha wrote:

I do not see how that helps defining the semantics for git-svn at all.

As I already commented, the possibility (and for most svn repositories, the likelihood) that nothing is pegged makes this less helpful, either.

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

I started working on externals support a long time ago, but got hung up on corner-cases (with .gitmodules and .gitignore being in the tree) and backward-compatibility issues with commiting back to SVN.

The more I think about it, the more I think the worse-is-better approach I used for "git svn show-ignore" is the way to go (using the unversioned .git/info/exclude). That would mean ignoring submodules as implemented by git and just shotgunning another git-svn-created subdirectory into where the external would've been...

Based on my limited understanding, peg revisions are only needed in SVN because of the cost of traversing history to DTRT. git-svn should be able to just use the -r<rev> syntax that has always been supported without needing peg revisions. On the other hand, implicit rename/copy detection in git may not pick up drastic changes...

Hi,

On Sun, 3 Aug 2008, Eric Wong wrote:

I was talking about the svn -> git direction.

And Git does not peg revisions because of the cost of traversing history to DTRT.

Git pegs revisions of submodules, because it is the right thing to do. Subversion just got it wrong to begin with. After all, we are going through a lot to make defined revisions, and we do not want to throw that out by allowing an unversioned submodule.

So, importing a svn:external with git-svn has to undo that error somehow (which might be helped by the linearity of subversion, but might be tricky because of possible clock skews between the two subversion repositories).

Ciao, Dscho

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Likewise.

I was saying SVN uses peg revisions because of the cost. Also, there may be a misunderstanding as to what peg revisions are (in SVN) and how they relate to git.

Here's an example svn:external definition with a peg revision:

  -r 1234 http://foo/bar.c@5233

"@5233" is the peg revision, and (as I understand it, just a hint) and "-r 1234" is the actual revision we want from SVN (and what git-svn should fetch). Confusing? Yes.

Yes, most repositories I've seen don't even use "-r 1234" (which has always been supported by SVN). This is the problem git will have to deal with.

Yes. This is why I'm leaning towards /not/ using git submodules for this because svn:externals are rarely defined with -r <revno>.