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. ;-)

-- 
				Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name.  -- Ken Thompson and Dennis M. Ritchie

On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis [off-list ref] wrote:

  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. ;-)

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.)

On Mon, Jul 28, 2008 at 5:01 PM, Petr Baudis [off-list ref] wrote:

 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. ;-)

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

Miklos Vajna [off-list ref] wrote:

On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis [off-list ref] wrote:

quoted

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

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.)

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.

-- 
Shawn.

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

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.

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

Petr Baudis [off-list ref] writes:

  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?)

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...

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Hi,

On Tue, 29 Jul 2008, Jakub Narebski wrote:

 * handling of svn:externals using submodules

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:

Hi,

On Tue, 29 Jul 2008, Jakub Narebski wrote:

quoted

 * handling of svn:externals using submodules

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

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

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".

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.

-- 
Jakub Narebski
Poland

Hi,

On Tue, 29 Jul 2008, Jakub Narebski wrote:

Johannes Schindelin wrote:

quoted

On Tue, 29 Jul 2008, Jakub Narebski wrote:

quoted

 * handling of svn:externals using submodules

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".

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.

... 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 Tue, Jul 29, 2008 at 01:56:37PM +0200, Johannes Schindelin wrote:

Hi,

On Tue, 29 Jul 2008, Jakub Narebski wrote:

quoted

 * handling of svn:externals using submodules

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".

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.

-- 
Luciano Rocha [off-list ref]
Eurotux Informática, S.A. <http://www.eurotux.com/>

Hi,

On Tue, 29 Jul 2008, Luciano Rocha wrote:

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

quoted

On Tue, 29 Jul 2008, Jakub Narebski wrote:

quoted

 * handling of svn:externals using submodules

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".

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

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

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.

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

Ciao,
Dscho

On 7/29/08, Johannes Schindelin [off-list ref] wrote:

 On Tue, 29 Jul 2008, Jakub Narebski wrote:
 > 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.

... 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.

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

Johannes Schindelin [off-list ref] wrote:

Hi,

On Tue, 29 Jul 2008, Jakub Narebski wrote:

quoted

 * handling of svn:externals using submodules

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

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...

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".

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...

-- 
Eric Wong

Hi,

On Sun, 3 Aug 2008, Eric Wong wrote:

Johannes Schindelin [off-list ref] wrote:

quoted

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".

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.

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 [off-list ref] wrote:

Hi,

On Sun, 3 Aug 2008, Eric Wong wrote:

quoted

Johannes Schindelin [off-list ref] wrote:

quoted

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".

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.

I was talking about the svn -> git direction.

Likewise.

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

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.

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.

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.

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).

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

-- 
Eric Wong