Hackontest ideas?

Hackontest ideas?

[Petr Baudis]

  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

Re: Hackontest ideas?

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 682 bytes --]

On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> 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.)

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Hackontest ideas?

[Shawn O. Pearce]

Miklos Vajna <vmiklos@frugalware.org> wrote:
> On Tue, Jul 29, 2008 at 02:01:03AM +0200, Petr Baudis <pasky@ucw.cz> wrote:
> > 
> > (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.

Re: Hackontest ideas?

[Petr Baudis]

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

Re: Hackontest ideas?

[Tarmigan]

On Mon, Jul 28, 2008 at 5:01 PM, Petr Baudis <pasky@ucw.cz> 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

Re: Hackontest ideas?

[Junio C Hamano]

Petr Baudis <pasky@ucw.cz> writes:

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

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

Re: Hackontest ideas?

[Petr Baudis]

On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:
> Petr Baudis <pasky@ucw.cz> writes:
> 
> > (What feature in Git or a Git-related tool would you implement, given 24
> > hours staight and unlimited pizza supply?)
> 
> "Use 'assume unchanged' bit to implement narrow checkout".

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

Re: Hackontest ideas?

[Nguyen Thai Ngoc Duy]

On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:
> On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:
>  > Petr Baudis <pasky@ucw.cz> writes:
>  >
>  > > (What feature in Git or a Git-related tool would you implement, given 24
>  > > hours staight and unlimited pizza supply?)
>  >
>  > "Use 'assume unchanged' bit to implement narrow checkout".
>
>
> 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.)

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.

-- 
Duy

Re: Hackontest ideas?

[Petr Baudis]

On Tue, Jul 29, 2008 at 08:55:32AM +0700, Nguyen Thai Ngoc Duy wrote:
> On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:
> > On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:
> >  > Petr Baudis <pasky@ucw.cz> writes:
> >  >
> >  > > (What feature in Git or a Git-related tool would you implement, given 24
> >  > > hours staight and unlimited pizza supply?)
> >  >
> >  > "Use 'assume unchanged' bit to implement narrow checkout".
> >
> >
> > 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.)
> 
> 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.

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

Re: Hackontest ideas?

[Nguyen Thai Ngoc Duy]

On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:
> On Tue, Jul 29, 2008 at 08:55:32AM +0700, Nguyen Thai Ngoc Duy wrote:
>  > On 7/29/08, Petr Baudis <pasky@suse.cz> wrote:
>  > > On Mon, Jul 28, 2008 at 05:55:45PM -0700, Junio C Hamano wrote:
>  > >  > Petr Baudis <pasky@ucw.cz> writes:
>  > >  >
>  > >  > > (What feature in Git or a Git-related tool would you implement, given 24
>  > >  > > hours staight and unlimited pizza supply?)
>  > >  >
>  > >  > "Use 'assume unchanged' bit to implement narrow checkout".
>  > >
>  > >
>  > > 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.)
>  >
>  > 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.
>
>
> 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?

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

-- 
Duy

Re: Hackontest ideas?

[Junio C Hamano]

Petr Baudis <pasky@ucw.cz> writes:

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

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

Re: Hackontest ideas?

[Jakub Narebski]

Petr Baudis <pasky@ucw.cz> 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

git-svn and svn:externals, was Re: Hackontest ideas?

[Johannes Schindelin]

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

Re: git-svn and svn:externals, was Re: Hackontest ideas?

[Jakub Narebski]

Johannes Schindelin wrote:
> 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.

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

Re: git-svn and svn:externals, was Re: Hackontest ideas?

[Johannes Schindelin]

Hi,

On Tue, 29 Jul 2008, Jakub Narebski wrote:

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

Re: git-svn and svn:externals, was Re: Hackontest ideas?

[Avery Pennarun]

On 7/29/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> 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

Re: git-svn and svn:externals, was Re: Hackontest ideas?

[Luciano Rocha]

[-- Attachment #1: Type: text/plain, Size: 925 bytes --]

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

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 <luciano@eurotux.com>
Eurotux Informática, S.A. <http://www.eurotux.com/>

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: git-svn and svn:externals, was Re: Hackontest ideas?

[Johannes Schindelin]

Hi,

On Tue, 29 Jul 2008, Luciano Rocha wrote:

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

Re: git-svn and svn:externals, was Re: Hackontest ideas?

[Eric Wong]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.

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

Re: git-svn and svn:externals, was Re: Hackontest ideas?

[Johannes Schindelin]

Hi,

On Sun, 3 Aug 2008, Eric Wong wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > 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

Re: git-svn and svn:externals, was Re: Hackontest ideas?

[Eric Wong]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
> 
> On Sun, 3 Aug 2008, Eric Wong wrote:
> 
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >
> > > 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