GSoC 2010

GSoC 2010

[Sverre Rabbelier]

Heya,

Dscho created a GSoC 2010 idea's page [0] a few weeks ago, but it's a
bit sad at the moment (only two idea's). Part of the reason Git was
listed as 'example application' before was our awesome idea list, we
should live up to that again this year :). If you feel like mentoring
a summer of code student, or if you have a great idea, please add it
to the list so that our would-be students have some variety in
choosing their projects. I just added "A remote helper for svn" [1]
myself, since I would love to see native svn support in git. Would
either Daniel or Eric (or someone else of course) be interested in
being a co- or backup-mentor for this project?

Also, unless Shawn volunteers again, we need a Summer of Code admin
for this year. Dscho, Peff, as you two have both jumped in for Junio
before, do either of you have the time and inclination to do so if
Shawn cannot? And of course, Shawn, do you have time to admin again
this year? If not, (and no-one else steps up) I'm willing to admin
myself, but I'll also be backup-admin and mentor for Melange, so if at
all possible it would be awesome if someone else jumps in.

Anyway, Summer of Code 2010 is a go [2], now is the time to get ready
and prepare for an awesome summer :).

[0] http://git.wiki.kernel.org/index.php/SoC2010Ideas
[1] http://git.wiki.kernel.org/index.php/SoC2010Ideas#A_remote_helper_for_svn
[2] http://socghop.appspot.com/

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Petr Baudis]

  Hi!

On Wed, Feb 10, 2010 at 09:23:55PM +0100, Sverre Rabbelier wrote:
> Dscho created a GSoC 2010 idea's page [0] a few weeks ago, but it's a
> bit sad at the moment (only two idea's). Part of the reason Git was
> listed as 'example application' before was our awesome idea list, we
> should live up to that again this year :). If you feel like mentoring
> a summer of code student, or if you have a great idea, please add it
> to the list so that our would-be students have some variety in
> choosing their projects.

  Thanks for reminding me. :-) I have added giddy to the SoC project
list, maybe someone will pick it up...

-- 
				Petr "Pasky" Baudis
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James

Re: GSoC 2010

[Christian Couder]

Hi

Petr Baudis wrote:
>   Hi!
>
> On Wed, Feb 10, 2010 at 09:23:55PM +0100, Sverre Rabbelier wrote:
> > Dscho created a GSoC 2010 idea's page [0] a few weeks ago, but it's a
> > bit sad at the moment (only two idea's). Part of the reason Git was
> > listed as 'example application' before was our awesome idea list, we
> > should live up to that again this year :). If you feel like mentoring
> > a summer of code student, or if you have a great idea, please add it
> > to the list so that our would-be students have some variety in
> > choosing their projects.
>
>   Thanks for reminding me. :-) I have added giddy to the SoC project
> list, maybe someone will pick it up...

I added a "git sequencer again" proposal.

Regards,
Christian. 

Re: GSoC 2010

[Eric Wong]

Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
> 
> Dscho created a GSoC 2010 idea's page [0] a few weeks ago, but it's a
> bit sad at the moment (only two idea's). Part of the reason Git was
> listed as 'example application' before was our awesome idea list, we
> should live up to that again this year :). If you feel like mentoring
> a summer of code student, or if you have a great idea, please add it
> to the list so that our would-be students have some variety in
> choosing their projects. I just added "A remote helper for svn" [1]
> myself, since I would love to see native svn support in git. Would
> either Daniel or Eric (or someone else of course) be interested in
> being a co- or backup-mentor for this project?

Hi Sverre,

I can't commit to anything, but they're welcome to email me/the list for
guidance.  I've left some notes further down in this email as well...

  It's been a long time since I've had time (or need, since most projects
  I care about have moved to git) to hack on git-svn.

  The git-vcs-* stuff is interesting and a good reason to refactor/redo
  parts of git-svn to work with it.  It's been overdue for a
  refactoring/cleanup for _years_ now.


I can't say SVN (nor the Perl support libraries) are pleasant to work
with.  Things to keep in mind:

* avoid memory leaks by using explicit pools

* avoid memory errors (which are much harder to track down
  wrapped around layers of SWIG/XS/SVN library abstractions).
  We sometimes copy SVN native data types into normal Perl ones
  ASAP to avoid errors/leaks

* inconsistent between different repo types:
  - escaping may be rules are stricter/laxer for some paths
  - error codes aren't consistent

* inability to safely maintain multiple connections to a repo
  in one process

I'm sure I'm missing some things here that my mind just blocked
out entirely...

All of them should be well-documented in the git-svn commit history
and/or comments.

-- 
Eric Wong

Re: GSoC 2010

[Johannes Schindelin]

Hi,

On Fri, 12 Feb 2010, Eric Wong wrote:

> Sverre Rabbelier <srabbelier@gmail.com> wrote:
> > Heya,
> > 
> > Dscho created a GSoC 2010 idea's page [0] a few weeks ago, but it's a
> > bit sad at the moment (only two idea's). Part of the reason Git was
> > listed as 'example application' before was our awesome idea list, we
> > should live up to that again this year :). If you feel like mentoring
> > a summer of code student, or if you have a great idea, please add it
> > to the list so that our would-be students have some variety in
> > choosing their projects. I just added "A remote helper for svn" [1]
> > myself, since I would love to see native svn support in git. Would
> > either Daniel or Eric (or someone else of course) be interested in
> > being a co- or backup-mentor for this project?
> 
> Hi Sverre,
> 
> I can't commit to anything, but they're welcome to email me/the list for
> guidance.  I've left some notes further down in this email as well...
> 
>   It's been a long time since I've had time (or need, since most projects
>   I care about have moved to git) to hack on git-svn.
> 
>   The git-vcs-* stuff is interesting and a good reason to refactor/redo
>   parts of git-svn to work with it.  It's been overdue for a
>   refactoring/cleanup for _years_ now.
> 
> 
> I can't say SVN (nor the Perl support libraries) are pleasant to work
> with.  Things to keep in mind:
> 
> * avoid memory leaks by using explicit pools
> 
> * avoid memory errors (which are much harder to track down
>   wrapped around layers of SWIG/XS/SVN library abstractions).
>   We sometimes copy SVN native data types into normal Perl ones
>   ASAP to avoid errors/leaks
> 
> * inconsistent between different repo types:
>   - escaping may be rules are stricter/laxer for some paths
>   - error codes aren't consistent
> 
> * inability to safely maintain multiple connections to a repo
>   in one process
> 
> I'm sure I'm missing some things here that my mind just blocked
> out entirely...
> 
> All of them should be well-documented in the git-svn commit history
> and/or comments.

Would it not make sense to implement git-remote-svn as a C program? That 
should help matters especially on Windows, where git-svn is very slow due 
to its using MSys (which is a stripped-down Cygwin, as you know, jumping 
through hoops to bring some POSIX-iness to Windows).

Ciao,
Dscho

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Fri, Feb 12, 2010 at 10:02, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Would it not make sense to implement git-remote-svn as a C program? That
> should help matters especially on Windows, where git-svn is very slow due
> to its using MSys (which is a stripped-down Cygwin, as you know, jumping
> through hoops to bring some POSIX-iness to Windows).

It would very much be sense to do so, perhaps we should update the
wiki to say that implementing it in C is strongly preferred?

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Fri, Feb 12, 2010 at 09:06, Eric Wong <normalperson@yhbt.net> wrote:
> I can't commit to anything, but they're welcome to email me/the list for
> guidance.

Can't ask for more :).

>  The git-vcs-* stuff is interesting and a good reason to refactor/redo
>  parts of git-svn to work with it.  It's been overdue for a
>  refactoring/cleanup for _years_ now.

Do you think that the code can be sane again if we use git-svn as a
base? Wouldn't it be better to start from scratch and use git-svn only
as a reference as to how to interact with svn?

> I can't say SVN (nor the Perl support libraries) are pleasant to work
> with.  Things to keep in mind:

Perhaps then it would indeed be better to just work with the C
bindings, if they are equally painful.

> I'm sure I'm missing some things here that my mind just blocked
> out entirely...

Do you have any idea how we are wrt licensing issues? II[U|R]C the svn
bindings are APLv2 licensed which would be problematic if we try to
use it in git?

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Mike Hommey]

On Fri, Feb 12, 2010 at 10:03:43AM +0100, Sverre Rabbelier wrote:
> Heya,
> 
> On Fri, Feb 12, 2010 at 10:02, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Would it not make sense to implement git-remote-svn as a C program? That
> > should help matters especially on Windows, where git-svn is very slow due
> > to its using MSys (which is a stripped-down Cygwin, as you know, jumping
> > through hoops to bring some POSIX-iness to Windows).
> 
> It would very much be sense to do so, perhaps we should update the
> wiki to say that implementing it in C is strongly preferred?

It is already mentioned on the wiki that this would probably be a
problem, license-wise. (the svn library is Apache license, which is
incompatible with GPLv2)

Mike

Re: GSoC 2010

[Johannes Schindelin]

Hi,

On Fri, 12 Feb 2010, Sverre Rabbelier wrote:

> On Fri, Feb 12, 2010 at 10:02, Johannes Schindelin 
> <Johannes.Schindelin@gmx.de> wrote:
> > Would it not make sense to implement git-remote-svn as a C program? 
> > That should help matters especially on Windows, where git-svn is very 
> > slow due to its using MSys (which is a stripped-down Cygwin, as you 
> > know, jumping through hoops to bring some POSIX-iness to Windows).
> 
> It would very much be sense to do so, perhaps we should update the wiki 
> to say that implementing it in C is strongly preferred?

Okay, done.

Ciao,
Dscho

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Fri, Feb 12, 2010 at 10:35, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Fri, 12 Feb 2010, Mike Hommey wrote:
>> It is already mentioned on the wiki that this would probably be a
>> problem, license-wise. (the svn library is Apache license, which is
>> incompatible with GPLv2)

Yeah, guess who put that there ;).

> So git-remote-svn would have to be under an Apache-compatible license, so
> what? It is not as if git-remote-svn was a derivative work of Git, just
> because it abides by a very simple command-line interface that happens to
> be defined in Git, but would work anywhere else, too.

Excellent point, I think we could safely argue that if we only expose
'import' and 'export' (so adhere to the fast-import/fast-export format
that is already widely used), that it is indeed not a derative work.
Also, becaus of how we set up the remote helpers (as drop in
binaries), we shouldn't have to worry too much about distributing?

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Tay Ray Chuan]

Hi,

On Fri, Feb 12, 2010 at 5:35 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 12 Feb 2010, Mike Hommey wrote:
>
>> On Fri, Feb 12, 2010 at 10:03:43AM +0100, Sverre Rabbelier wrote:
>>
>> > On Fri, Feb 12, 2010 at 10:02, Johannes Schindelin
>> > <Johannes.Schindelin@gmx.de> wrote:
>> > > Would it not make sense to implement git-remote-svn as a C program?
>> > > That should help matters especially on Windows, where git-svn is
>> > > very slow due to its using MSys (which is a stripped-down Cygwin, as
>> > > you know, jumping through hoops to bring some POSIX-iness to
>> > > Windows).
>> >
>> > It would very much be sense to do so, perhaps we should update the
>> > wiki to say that implementing it in C is strongly preferred?
>>
>> It is already mentioned on the wiki that this would probably be a
>> problem, license-wise. (the svn library is Apache license, which is
>> incompatible with GPLv2)
>
> So git-remote-svn would have to be under an Apache-compatible license, so
> what? It is not as if git-remote-svn was a derivative work of Git, just
> because it abides by a very simple command-line interface that happens to
> be defined in Git, but would work anywhere else, too.

hmm, what about distribution? Will we be able to distribute this
remote helper with the rest of Git's GPL-ed code?

As a side note, if I'm remember correctly, there used to be a
implementation of SHA-1 hashing algorithm from Mozilla  - was that
under MPL? If so, how did we deal with that? (Wikipedia says MPL is
incompatible with GPL, too.)

-- 
Cheers,
Ray Chuan

Re: GSoC 2010

[Johannes Schindelin]

Hi,

On Fri, 12 Feb 2010, Mike Hommey wrote:

> On Fri, Feb 12, 2010 at 10:03:43AM +0100, Sverre Rabbelier wrote:
> 
> > On Fri, Feb 12, 2010 at 10:02, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > > Would it not make sense to implement git-remote-svn as a C program? 
> > > That should help matters especially on Windows, where git-svn is 
> > > very slow due to its using MSys (which is a stripped-down Cygwin, as 
> > > you know, jumping through hoops to bring some POSIX-iness to 
> > > Windows).
> > 
> > It would very much be sense to do so, perhaps we should update the 
> > wiki to say that implementing it in C is strongly preferred?
> 
> It is already mentioned on the wiki that this would probably be a 
> problem, license-wise. (the svn library is Apache license, which is 
> incompatible with GPLv2)

So git-remote-svn would have to be under an Apache-compatible license, so 
what? It is not as if git-remote-svn was a derivative work of Git, just 
because it abides by a very simple command-line interface that happens to 
be defined in Git, but would work anywhere else, too.

Ciao,
Dscho

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Fri, Feb 12, 2010 at 10:34, Tay Ray Chuan <rctay89@gmail.com> wrote:
> hmm, what about distribution? Will we be able to distribute this
> remote helper with the rest of Git's GPL-ed code?

As I just said [0], it won't matter. It can be safely distributed as a
separate package, as long as a binary 'git-remote-svn' is installed
git will be able to use it.

[0] http://article.gmane.org/gmane.comp.version-control.git/139671

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Mike Hommey]

On Fri, Feb 12, 2010 at 10:32:44AM +0100, Sverre Rabbelier wrote:
> Heya,
> 
> On Fri, Feb 12, 2010 at 10:35, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 12 Feb 2010, Mike Hommey wrote:
> >> It is already mentioned on the wiki that this would probably be a
> >> problem, license-wise. (the svn library is Apache license, which is
> >> incompatible with GPLv2)
> 
> Yeah, guess who put that there ;).
> 
> > So git-remote-svn would have to be under an Apache-compatible license, so
> > what? It is not as if git-remote-svn was a derivative work of Git, just
> > because it abides by a very simple command-line interface that happens to
> > be defined in Git, but would work anywhere else, too.
> 
> Excellent point, I think we could safely argue that if we only expose
> 'import' and 'export' (so adhere to the fast-import/fast-export format
> that is already widely used), that it is indeed not a derative work.

It is not so clear when you begin to use facilities such as strbuf, etc.
Maybe dual-licensing these parts would be enough, though, but that still
means doing some homework (getting approval from all contributors)

Mike

strbuf & other stuff dual-licensing, was Re: GSoC 2010

[Johannes Schindelin]

Hi,

[culling the Cc: list to the most-likely interested parties, Cc:ing 
Andreas and Pierre]

On Fri, 12 Feb 2010, Mike Hommey wrote:

> On Fri, Feb 12, 2010 at 10:32:44AM +0100, Sverre Rabbelier wrote:
> 
> > On Fri, Feb 12, 2010 at 10:35, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > > On Fri, 12 Feb 2010, Mike Hommey wrote:
> > >> It is already mentioned on the wiki that this would probably be a
> > >> problem, license-wise. (the svn library is Apache license, which is
> > >> incompatible with GPLv2)
> > 
> > Yeah, guess who put that there ;).
> > 
> > > So git-remote-svn would have to be under an Apache-compatible license, so
> > > what? It is not as if git-remote-svn was a derivative work of Git, just
> > > because it abides by a very simple command-line interface that happens to
> > > be defined in Git, but would work anywhere else, too.
> > 
> > Excellent point, I think we could safely argue that if we only expose
> > 'import' and 'export' (so adhere to the fast-import/fast-export format
> > that is already widely used), that it is indeed not a derative work.
> 
> It is not so clear when you begin to use facilities such as strbuf, etc.
> Maybe dual-licensing these parts would be enough, though, but that still
> means doing some homework (getting approval from all contributors)

AFAIR Andreas already did most of the chasing down for libgit2.

Ciao,
Dscho

web-based client for Git, was Re: GSoC 2010

[Johannes Schindelin]

Hi Pavan,

[culling the Cc: list to the most likely interested parties]

On Fri, 12 Feb 2010, Pavan Kumar Sunkara wrote:

>   I am Pavan Kumar, a computer science student from Indian Institute of 
> Technology, Madras. I would like to propose a new project for git GSoC 
> 2010. I am new to git development community but i would like to start 
> contributing to it by participating as GSoC student to develop a GUI 
> client for git usage. Basically it will be a web client that can be 
> accessed from other computers.

This is great stuff. As you know, the ideas page is really only about 
giving the students ideas what type of projects we'd like to see. But it 
is always better to have a project with your heart and soul behind it.

Provided that we get accepted, you will have time to put up an application 
for this project between March 29 and April 9, according to the timeline:

http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline

But I think you wanted to hear some feedback to your idea. So here goes my 
feedback:

- It is a very interesting idea. I already know a few users who would be 
  happy to use it.

- It is good that you mention the preferred programming language... While 
  I got used to Python, I am by far not good enough to mentor :-)

- There is little chance that this project will become a core part of Git, 
  as it is too far outside of the original focus of it, namely allowing 
  developers to version-control their source code they have in a local 
  directory.

That latter point does not say that your project is not worth it, though! 
As I said, I think it would be very useful to have.

Ciao,
Dscho

Re: web-based client for Git, was Re: GSoC 2010

[Pau Garcia i Quiles]

Hello,

Let me suggest Wt ( http://webtoolkit.eu ) for the web development.

It's C++ and GPLv2, therefore he may be able to directly use libgit2
or copy&paste source code from git. In fact, one of the examples Wt
includes in the source tarball is a git viewer:
http://www.webtoolkit.eu/wt/examples/gitmodel/gitview.wt
http://www.webtoolkit.eu/wt#/src/gitmodel

In addition to that, if someone is interested in contributing to
libQtGit ( http://gitorious.org/libqtgit ) as his/her GSoC, I'd be
more than happy to accept contributors. API is done for the most used
commands but is lacking implementation (read: append to a QStringList
the parameters I added to the comments for the Q_ENUMS, then invoke
QProcess and parse output). Some important commands which have not
been translated to the libQtGit API are 'dif', 'log' and 'submodules'.
Some more information on libQtGit here: http://www.elpauer.org/?p=419

On Fri, Feb 12, 2010 at 11:56 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Hi Pavan,
>
> [culling the Cc: list to the most likely interested parties]
>
> On Fri, 12 Feb 2010, Pavan Kumar Sunkara wrote:
>
>>   I am Pavan Kumar, a computer science student from Indian Institute of
>> Technology, Madras. I would like to propose a new project for git GSoC
>> 2010. I am new to git development community but i would like to start
>> contributing to it by participating as GSoC student to develop a GUI
>> client for git usage. Basically it will be a web client that can be
>> accessed from other computers.
>
> This is great stuff. As you know, the ideas page is really only about
> giving the students ideas what type of projects we'd like to see. But it
> is always better to have a project with your heart and soul behind it.
>
> Provided that we get accepted, you will have time to put up an application
> for this project between March 29 and April 9, according to the timeline:
>
> http://socghop.appspot.com/document/show/gsoc_program/google/gsoc2010/faqs#timeline
>
> But I think you wanted to hear some feedback to your idea. So here goes my
> feedback:
>
> - It is a very interesting idea. I already know a few users who would be
>  happy to use it.
>
> - It is good that you mention the preferred programming language... While
>  I got used to Python, I am by far not good enough to mentor :-)
>
> - There is little chance that this project will become a core part of Git,
>  as it is too far outside of the original focus of it, namely allowing
>  developers to version-control their source code they have in a local
>  directory.
>
> That latter point does not say that your project is not worth it, though!
> As I said, I think it would be very useful to have.
>
> Ciao,
> Dscho
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>



-- 
Pau Garcia i Quiles
http://www.elpauer.org
(Due to my workload, I may need 10 days to answer)

Re: web-based client for Git, was Re: GSoC 2010

[Johannes Schindelin]

Hi,

On Fri, 12 Feb 2010, Pau Garcia i Quiles wrote:

> Let me suggest Wt ( http://webtoolkit.eu ) for the web development.

He said he wants to use Python.

> In addition to that, if someone is interested in contributing to
> libQtGit ( http://gitorious.org/libqtgit ) as his/her GSoC, I'd be
> more than happy to accept contributors.

Given that I read about libQtGit for the first time on this list (I might 
have missed an announcement, though), I find it a bit odd to read 
the implicit announcement in the context of the GSoC for _Git_.

But hey, it's a free world, and you can even put it onto the ideas page on 
the wiki. And maybe a link to your project on the interfaces page, which 
you failed to do yet.

Ciao,
Dscho

Re: web-based client for Git, was Re: GSoC 2010

[Petr Baudis]

  Hi!

On Fri, Feb 12, 2010 at 11:56:29AM +0100, Johannes Schindelin wrote:
> On Fri, 12 Feb 2010, Pavan Kumar Sunkara wrote:
> 
> >   I am Pavan Kumar, a computer science student from Indian Institute of 
> > Technology, Madras. I would like to propose a new project for git GSoC 
> > 2010. I am new to git development community but i would like to start 
> > contributing to it by participating as GSoC student to develop a GUI 
> > client for git usage. Basically it will be a web client that can be 
> > accessed from other computers.
..snip..
> - It is a very interesting idea. I already know a few users who would be 
>   happy to use it.

  Could you please elaborate about your idea? It sounds to me as "just
yet another gitweb/cgit/gitorious/...". What advantages would it have
over those and why can't you implement the features you are missing
within one of the existing web interfaces? Or am I missing something
obvious?

  Thanks,

-- 
				Petr "Pasky" Baudis
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James

Re: web-based client for Git, was Re: GSoC 2010

[Pavan Kumar Sunkara]

I would be happy to elaborate this.

First of all, this is not another gitweb or gitorious.
This is a client to use git. I mean, you could use this to work on git
repositories. (even editing files)

This program can be used in 2 ways. One, Use it locally and Two,
hosted in a website for many users

It's structure will be like this:
* When you start this program by typing gittor in terminal, A new
window will be opened with your preferred browser
* It will take you directly to you repositories overview whose file
paths have been previously provided by you.
* Now after selecting a repository, you can explore among the commits,
diffs, blames, trees (similiar to git web)
* But also you will have other options like
  # Edit file: Opens a browser based syntax highlighted file editor.
  # See status: See the status of current working repository(git status)
  # See diff: See diffs
  # Create and/or Change branches
  # Add/Remove files.
  # Show functionalities
  # Commit with log messages
  # Push/Pull remote repositories
  # Garbage collection
  # And all other major functionalities while using git on a working repository

So, as u see, it is a combination of gitweb and GUI client to use git.
This opens in a internet browser, because it's easy to write GUI for it.(HTML)

Also it can be used by companies by hosting it in a website and ask
their members to login and work on it by website URL.

But mostly this will be used locally.

-pavan

Re: web-based client for Git, was Re: GSoC 2010

[Petr Baudis]

  Hi!

On Fri, Feb 12, 2010 at 05:25:02PM +0530, Pavan Kumar Sunkara wrote:
> sorry but my mails aren't reaching the mailing list. So it would be
> helpful if you forward this mail to the mailing list

  I'm quoting it in full here. :-)

> I would be happy to elaborate this.

  Thanks a lot!

> First of all, this is not another gitweb or gitorious.
> This is a client to use git. I mean, you could use this to work on git
> repositories. (even editing files)

  Aha, I see. Are you aware of "gist" [http://gist.github.com/]? It is
in a sense the first attempt to do this, albeit quite rudimentary in
some ways. And it's also closed-source, I'm not personally aware of an
open-source alternative, so this would certainly be useful! Actually,
I can say I would certainly like to add this functionality to repo.or.cz
for creating commits on the mob branches over the web directly.

> This program can be used in 2 ways. One, hosted in a website for many users
> and Two use it locally
> 
> It's structure will be like this:
> * When you start this program by typing gittor in terminal, A new window
> will be opened with your preferred browser
> * It will take you directly to you repositories overview whose file paths
> have been previously provided by you.
> * Now after selecting a repository, you can explore among the commits,
> diffs, blames, trees (similiar to git web)
> * But also you will have other options like
>   # Edit file: Opens a browser based syntax highlighted file editor.
>   # See status: See the status of current working repository(git status)
>   # See diff: See diffs
>   # Create and/or Change branches
>   # Add/Remove files.
>   # Show functionalities
>   # Commit with log messages
>   # Push/Pull remote repositories
>   # Garbage collection
>   # And all other major functionalities while using git on a working
> repository
> 
> So, as u see, it is a combination of gitweb and GUI client to use git.
> This opens in a internet browser, because it's easy to write GUI for
> it.(HTML)

  However, I'm a bit unsure if you aren't loading too much on yourself,
seeing how much effort it took the other projects to implement *just the
read-only parts* properly. So I still wonder why it wouldn't be better
to focus purely on the editing and commit creation, while relying on
an existing web interface to provide the history browsing, diffs, etc.

  This could be done in several ways - simply taking a client and adding
your code to provide the extra functionality there, OR creating a
standalone project that would be cross-linked with a given web
interface. The latter option is interesting since your extension could
work easily with the web interfaces of choice (and e.g. modifying gitweb
to provide the appropriate links is trivial, to a degree even possible
purely from config file).

  P.S.: I could volunteer to mentor such a project, if no more active
Git hacker shows interest. Perhaps Jakub Narebski might be interested?

-- 
				Petr "Pasky" Baudis
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James

Re: web-based client for Git, was Re: GSoC 2010

[Pavan Kumar Sunkara]

>  However, I'm a bit unsure if you aren't loading too much on yourself,
> seeing how much effort it took the other projects to implement *just the
> read-only parts* properly. So I still wonder why it wouldn't be better
> to focus purely on the editing and commit creation, while relying on
> an existing web interface to provide the history browsing, diffs, etc.

Yeah, My GSoC project will consist of this. Remaining all
functionalities will be coded after i finish GSoC.

>  This could be done in several ways - simply taking a client and adding
> your code to provide the extra functionality there, OR creating a
> standalone project that would be cross-linked with a given web
> interface. The latter option is interesting since your extension could
> work easily with the web interfaces of choice (and e.g. modifying gitweb
> to provide the appropriate links is trivial, to a degree even possible
> purely from config file).

I am intended to link it with gitweb.

>  P.S.: I could volunteer to mentor such a project, if no more active
> Git hacker shows interest. Perhaps Jakub Narebski might be interested?

Wow. That's great, If u could get a confirmation that somebody is
willing to mentor this, then i can start the project even before the
start of GSoC itself.

-pavan

Re: web-based client for Git, was Re: GSoC 2010

[Petr Baudis]

On Fri, Feb 12, 2010 at 05:54:29PM +0530, Pavan Kumar Sunkara wrote:
> >  However, I'm a bit unsure if you aren't loading too much on yourself,
> > seeing how much effort it took the other projects to implement *just the
> > read-only parts* properly. So I still wonder why it wouldn't be better
> > to focus purely on the editing and commit creation, while relying on
> > an existing web interface to provide the history browsing, diffs, etc.
> 
> Yeah, My GSoC project will consist of this. Remaining all
> functionalities will be coded after i finish GSoC.
> 
> >  This could be done in several ways - simply taking a client and adding
> > your code to provide the extra functionality there, OR creating a
> > standalone project that would be cross-linked with a given web
> > interface. The latter option is interesting since your extension could
> > work easily with the web interfaces of choice (and e.g. modifying gitweb
> > to provide the appropriate links is trivial, to a degree even possible
> > purely from config file).
> 
> I am intended to link it with gitweb.

That sounds great!

> >  P.S.: I could volunteer to mentor such a project, if no more active
> > Git hacker shows interest. Perhaps Jakub Narebski might be interested?
> 
> Wow. That's great, If u could get a confirmation that somebody is
> willing to mentor this, then i can start the project even before the
> start of GSoC itself.

Please note that Google provides a funding to a limited number of
projects and the willingness to mentor a project does not mean yet that
we will choose your project in particular for the GSoC program. I can
still provide you with guidance outside of the GSoC frame and your
contributions will still be certainly welcome, but we can decide which
projects to choose for GSoC only when we receive all the applications.

-- 
				Petr "Pasky" Baudis
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James

Re: web-based client for Git, was Re: GSoC 2010

[Mike Hommey]

On Fri, Feb 12, 2010 at 01:18:44PM +0100, Petr Baudis wrote:
>   Hi!
> 
> On Fri, Feb 12, 2010 at 05:25:02PM +0530, Pavan Kumar Sunkara wrote:
> > sorry but my mails aren't reaching the mailing list. So it would be
> > helpful if you forward this mail to the mailing list
> 
>   I'm quoting it in full here. :-)
> 
> > I would be happy to elaborate this.
> 
>   Thanks a lot!
> 
> > First of all, this is not another gitweb or gitorious.
> > This is a client to use git. I mean, you could use this to work on git
> > repositories. (even editing files)
> 
>   Aha, I see. Are you aware of "gist" [http://gist.github.com/]? It is
> in a sense the first attempt to do this, albeit quite rudimentary in
> some ways. And it's also closed-source, I'm not personally aware of an
> open-source alternative, so this would certainly be useful! Actually,
> I can say I would certainly like to add this functionality to repo.or.cz
> for creating commits on the mob branches over the web directly.

Surely, something could be plugged into https://bespin.mozilla.com/,
which already does a great job at editing.

Mike

Re: web-based client for Git, was Re: GSoC 2010

[Petr Baudis]

On Fri, Feb 12, 2010 at 01:44:36PM +0100, Mike Hommey wrote:
> On Fri, Feb 12, 2010 at 01:18:44PM +0100, Petr Baudis wrote:
> >   Hi!
> > 
> > On Fri, Feb 12, 2010 at 05:25:02PM +0530, Pavan Kumar Sunkara wrote:
> > > sorry but my mails aren't reaching the mailing list. So it would be
> > > helpful if you forward this mail to the mailing list
> > 
> >   I'm quoting it in full here. :-)
> > 
> > > I would be happy to elaborate this.
> > 
> >   Thanks a lot!
> > 
> > > First of all, this is not another gitweb or gitorious.
> > > This is a client to use git. I mean, you could use this to work on git
> > > repositories. (even editing files)
> > 
> >   Aha, I see. Are you aware of "gist" [http://gist.github.com/]? It is
> > in a sense the first attempt to do this, albeit quite rudimentary in
> > some ways. And it's also closed-source, I'm not personally aware of an
> > open-source alternative, so this would certainly be useful! Actually,
> > I can say I would certainly like to add this functionality to repo.or.cz
> > for creating commits on the mob branches over the web directly.
> 
> Surely, something could be plugged into https://bespin.mozilla.com/,
> which already does a great job at editing.

That sounds like a nice replacement for the textarea, thanks for the
tip! On the other hand, I think this is currently the least important
part of the project and for the basic implementation, even a simple
textarea should suffice, any prettier editor hopefully could be slammed
in anytime trivially.

-- 
				Petr "Pasky" Baudis
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James

Re: web-based client for Git, was Re: GSoC 2010

[Pavan Kumar Sunkara]

I saw the wishlist of gitweb in wiki.
I would like to implement the syntax highlighting for viewing blobs.

Is there anyone working on it now?
Or shall i move forward.

-pavan

Re: web-based client for Git, was Re: GSoC 2010

[Mike Hommey]

On Fri, Feb 12, 2010 at 01:51:46PM +0100, Petr Baudis wrote:
> On Fri, Feb 12, 2010 at 01:44:36PM +0100, Mike Hommey wrote:
> > On Fri, Feb 12, 2010 at 01:18:44PM +0100, Petr Baudis wrote:
> > >   Hi!
> > > 
> > > On Fri, Feb 12, 2010 at 05:25:02PM +0530, Pavan Kumar Sunkara wrote:
> > > > sorry but my mails aren't reaching the mailing list. So it would be
> > > > helpful if you forward this mail to the mailing list
> > > 
> > >   I'm quoting it in full here. :-)
> > > 
> > > > I would be happy to elaborate this.
> > > 
> > >   Thanks a lot!
> > > 
> > > > First of all, this is not another gitweb or gitorious.
> > > > This is a client to use git. I mean, you could use this to work on git
> > > > repositories. (even editing files)
> > > 
> > >   Aha, I see. Are you aware of "gist" [http://gist.github.com/]? It is
> > > in a sense the first attempt to do this, albeit quite rudimentary in
> > > some ways. And it's also closed-source, I'm not personally aware of an
> > > open-source alternative, so this would certainly be useful! Actually,
> > > I can say I would certainly like to add this functionality to repo.or.cz
> > > for creating commits on the mob branches over the web directly.
> > 
> > Surely, something could be plugged into https://bespin.mozilla.com/,
> > which already does a great job at editing.
> 
> That sounds like a nice replacement for the textarea, thanks for the
> tip! On the other hand, I think this is currently the least important
> part of the project and for the basic implementation, even a simple
> textarea should suffice, any prettier editor hopefully could be slammed
> in anytime trivially.

There is VCS integration with bespin, already, but maybe not what people
would like a git web interface to be
https://wiki.mozilla.org/Labs/Bespin/UserGuide#Version_Control

Mike

Re: web-based client for Git, was Re: GSoC 2010

[Petr Baudis]

  Hi!

On Fri, Feb 12, 2010 at 02:07:23PM +0100, Johannes Schindelin wrote:
> On Fri, 12 Feb 2010, Pavan Kumar Sunkara wrote:
> 
> > I saw the wishlist of gitweb in wiki.
> > I would like to implement the syntax highlighting for viewing blobs.
> > 
> > Is there anyone working on it now?
> 
> http://repo.or.cz/w/git/dscho.git/commitdiff/bc1ed6aafd9ee4937559535c66c8bddf1864bec6

  Have you tried to submit this "upstream"? Why did it get dropped? This
sounds like such a useful _and_ trivial thing that if we can't even get
*this* integrated, surely gitweb is doomed for good...

-- 
				Petr "Pasky" Baudis
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James

Re: web-based client for Git, was Re: GSoC 2010

[Johannes Schindelin]

Hi,

On Fri, 12 Feb 2010, Pavan Kumar Sunkara wrote:

> I saw the wishlist of gitweb in wiki.
> I would like to implement the syntax highlighting for viewing blobs.
> 
> Is there anyone working on it now?

http://repo.or.cz/w/git/dscho.git/commitdiff/bc1ed6aafd9ee4937559535c66c8bddf1864bec6

Ciao,
Dscho

Re: web-based client for Git, was Re: GSoC 2010

[Pavan Kumar Sunkara]

No worries, I will start work o this from next week. :)

On Fri, Feb 12, 2010 at 6:35 PM, Petr Baudis <pasky@suse.cz> wrote:
>  Hi!
>
> On Fri, Feb 12, 2010 at 02:07:23PM +0100, Johannes Schindelin wrote:
>> On Fri, 12 Feb 2010, Pavan Kumar Sunkara wrote:
>>
>> > I saw the wishlist of gitweb in wiki.
>> > I would like to implement the syntax highlighting for viewing blobs.
>> >
>> > Is there anyone working on it now?
>>
>> http://repo.or.cz/w/git/dscho.git/commitdiff/bc1ed6aafd9ee4937559535c66c8bddf1864bec6
>
>  Have you tried to submit this "upstream"? Why did it get dropped? This
> sounds like such a useful _and_ trivial thing that if we can't even get
> *this* integrated, surely gitweb is doomed for good...
>
> --
>                                Petr "Pasky" Baudis
> A great many people think they are thinking when they are merely
> rearranging their prejudices. -- William James
>

Re: web-based client for Git, was Re: GSoC 2010

[Johannes Schindelin]

Hi,

On Fri, 12 Feb 2010, Petr Baudis wrote:

> On Fri, Feb 12, 2010 at 02:07:23PM +0100, Johannes Schindelin wrote:
> > On Fri, 12 Feb 2010, Pavan Kumar Sunkara wrote:
> > 
> > > I saw the wishlist of gitweb in wiki.
> > > I would like to implement the syntax highlighting for viewing blobs.
> > > 
> > > Is there anyone working on it now?
> > 
> > http://repo.or.cz/w/git/dscho.git/commitdiff/bc1ed6aafd9ee4937559535c66c8bddf1864bec6
> 
>   Have you tried to submit this "upstream"?

No.

Ciao,
Dscho

Re: web-based client for Git, was Re: GSoC 2010

[Jakub Narebski]

On Fri, 12 Feb 2010, Petr Baudis wrote:
> On Fri, Feb 12, 2010 at 02:07:23PM +0100, Johannes Schindelin wrote:
>> On Fri, 12 Feb 2010, Pavan Kumar Sunkara wrote:
>> 
>>> I saw the wishlist of gitweb in wiki.

Wishlists on the wiki have, unfortunately, trouble with sometimes being
not up to date.

>>> I would like to implement the syntax highlighting for viewing blobs.
>>> 
>>> Is there anyone working on it now?
>> 
>> http://repo.or.cz/w/git/dscho.git/commitdiff/bc1ed6aafd9ee4937559535c66c8bddf1864bec6
> 
>   Have you tried to submit this "upstream"? Why did it get dropped? This
> sounds like such a useful _and_ trivial thing that if we can't even get
> *this* integrated, surely gitweb is doomed for good...

I don't remember seeing this send to git mailing list.

Note that the patch should use quote_command(...) instead of simple
join(' ', ...) for its arguments, like it is done in git_snapshot().

-- 
Jakub Narebski
Poland

Re: web-based client for Git, was Re: GSoC 2010

[Scott Chacon]

Hey,

On Fri, Feb 12, 2010 at 4:18 AM, Petr Baudis <pasky@suse.cz> wrote:
>  P.S.: I could volunteer to mentor such a project, if no more active
> Git hacker shows interest. Perhaps Jakub Narebski might be interested?
>

I would also be happy to help with this project - it sounds very
interesting and Python/web-dev stuff is something I can actually help
with.

Scott

Re: GSoC 2010

[Daniel Barkalow]

On Fri, 12 Feb 2010, Sverre Rabbelier wrote:

> Heya,
> 
> On Fri, Feb 12, 2010 at 10:35, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 12 Feb 2010, Mike Hommey wrote:
> >> It is already mentioned on the wiki that this would probably be a
> >> problem, license-wise. (the svn library is Apache license, which is
> >> incompatible with GPLv2)
> 
> Yeah, guess who put that there ;).
> 
> > So git-remote-svn would have to be under an Apache-compatible license, so
> > what? It is not as if git-remote-svn was a derivative work of Git, just
> > because it abides by a very simple command-line interface that happens to
> > be defined in Git, but would work anywhere else, too.
> 
> Excellent point, I think we could safely argue that if we only expose
> 'import' and 'export' (so adhere to the fast-import/fast-export format
> that is already widely used), that it is indeed not a derative work.
> Also, becaus of how we set up the remote helpers (as drop in
> binaries), we shouldn't have to worry too much about distributing?

It was intentional on my part that the mode where the helper only talks to 
the remote system and to its parent be not a derived work of the parent, 
under the usual analysis that something is not covered by copyright if it 
has to be a particular way for functional or interoperability reasons.

This does not strictly mean that helpers won't be derived works of git, 
simply because they may use git code internally (strbuf, for example), and 
because it's currently much easier to do incremental imports by looking up 
the current state from the git object database than to be completely 
agnostic.

Also note that the current helper protocol is definitely insufficient to 
replace git-svn ('export' isn't actually specified, although I think 
everyone who guesses how it works guesses the same thing), and the 
transport code needs to be extended to handle the "dcommit" situation 
(when you push a commit, the state that you see on the remote changes 
based on the semantics of what you sent, but it does not change to have 
the same hash as what you pushed).

Distribution of binaries shouldn't be a problem (the GPL specifically 
states that just coming in the same package doesn't matter for licensing, 
and this is generally what copyright laws say anyway); the main issue is 
that packages would have to specify which things have which license, since 
it won't just be obvious.

	-Daniel
*This .sig left intentionally blank*

Re: GSoC 2010

[Daniel Barkalow]

On Wed, 10 Feb 2010, Sverre Rabbelier wrote:

> I just added "A remote helper for svn" [1] myself, since I would love to 
> see native svn support in git. Would either Daniel or Eric (or someone 
> else of course) be interested in being a co- or backup-mentor for this 
> project?

I'd be willing to be a backup mentor for the project. Even if I'm not 
officially doing any project management and paperwork for it, I'd like to 
be officially supposed to be asked questions about it; I've noticed that 
GSoC students are often shy about asking non-mentor developers to review 
their designs, and I'd like to review this before it's all written and 
under the end-of-summer crunch.

	-Daniel
*This .sig left intentionally blank*

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Fri, Feb 12, 2010 at 17:10, Daniel Barkalow <barkalow@iabervon.org> wrote:
> Also note that the current helper protocol is definitely insufficient to
> replace git-svn ('export' isn't actually specified, although I think
> everyone who guesses how it works guesses the same thing),

I've finally started implementing this yesterday.

> and the
> transport code needs to be extended to handle the "dcommit" situation
> (when you push a commit, the state that you see on the remote changes
> based on the semantics of what you sent, but it does not change to have
> the same hash as what you pushed).

So basically what you want to do is after you push, automagically do a
'git reset --hard @{u}'? That could be handled by a specific response
from the helper to the 'export'/'push' command, perhaps it could list
which refs need to be updated?

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Fri, Feb 12, 2010 at 17:19, Daniel Barkalow <barkalow@iabervon.org> wrote:
> I've noticed that
> GSoC students are often shy about asking non-mentor developers to review
> their designs, and I'd like to review this before it's all written and
> under the end-of-summer crunch.

Since I'm (planning on) mentoring this student, I don't think you'll
have to worry about that too much. My experience with my own gsoc was
that the more exposure your work gets on the list the better, so the
student should send weekly 'state of the code' (including the code as
a patch) mails.

-- 
Cheers,

Sverre Rabbelier

Re: web-based client for Git, was Re: GSoC 2010

[Petr Baudis]

On Fri, Feb 12, 2010 at 07:14:58AM -0800, Scott Chacon wrote:
> Hey,
> 
> On Fri, Feb 12, 2010 at 4:18 AM, Petr Baudis <pasky@suse.cz> wrote:
> >  P.S.: I could volunteer to mentor such a project, if no more active
> > Git hacker shows interest. Perhaps Jakub Narebski might be interested?
> >
> 
> I would also be happy to help with this project - it sounds very
> interesting and Python/web-dev stuff is something I can actually help
> with.

Ok, I don't actually know too much about web-dev in Python (actually
fairly little ;-), so you would certainly be better choice!

-- 
				Petr "Pasky" Baudis
A great many people think they are thinking when they are merely
rearranging their prejudices. -- William James

Re: web-based client for Git, was Re: GSoC 2010

[Jan Koprowski]

2010/2/12 Petr Baudis <pasky@suse.cz>:
> On Fri, Feb 12, 2010 at 07:14:58AM -0800, Scott Chacon wrote:
>> Hey,
>>
>> On Fri, Feb 12, 2010 at 4:18 AM, Petr Baudis <pasky@suse.cz> wrote:
>> >  P.S.: I could volunteer to mentor such a project, if no more active
>> > Git hacker shows interest. Perhaps Jakub Narebski might be interested?
>> >
>>
>> I would also be happy to help with this project - it sounds very
>> interesting and Python/web-dev stuff is something I can actually help
>> with.
>
> Ok, I don't actually know too much about web-dev in Python (actually
> fairly little ;-), so you would certainly be better choice!
>
> --
>                                Petr "Pasky" Baudis
> A great many people think they are thinking when they are merely
> rearranging their prejudices. -- William James
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

In my opinion library Werkzeug (http://werkzeug.pocoo.org/) may be a
good point of start searching simple and extremely lightweight base of
application.
This is good option when Django is too heavy.

-- 
><> Jan Koprowski [696775174] GSM

Re: web-based client for Git, was Re: GSoC 2010

[Pavan Kumar Sunkara]

Thanks Jan.
Werkzeug is very promising to be a base for this application.

-pavan

Re: web-based client for Git, was Re: GSoC 2010

[david]

On Fri, 12 Feb 2010, Petr Baudis wrote:

> On Fri, Feb 12, 2010 at 01:44:36PM +0100, Mike Hommey wrote:
>> On Fri, Feb 12, 2010 at 01:18:44PM +0100, Petr Baudis wrote:
>>>   Hi!
>>>
>>> On Fri, Feb 12, 2010 at 05:25:02PM +0530, Pavan Kumar Sunkara wrote:
>>>> sorry but my mails aren't reaching the mailing list. So it would be
>>>> helpful if you forward this mail to the mailing list
>>>
>>>   I'm quoting it in full here. :-)
>>>
>>>> I would be happy to elaborate this.
>>>
>>>   Thanks a lot!
>>>
>>>> First of all, this is not another gitweb or gitorious.
>>>> This is a client to use git. I mean, you could use this to work on git
>>>> repositories. (even editing files)
>>>
>>>   Aha, I see. Are you aware of "gist" [http://gist.github.com/]? It is
>>> in a sense the first attempt to do this, albeit quite rudimentary in
>>> some ways. And it's also closed-source, I'm not personally aware of an
>>> open-source alternative, so this would certainly be useful! Actually,
>>> I can say I would certainly like to add this functionality to repo.or.cz
>>> for creating commits on the mob branches over the web directly.
>>
>> Surely, something could be plugged into https://bespin.mozilla.com/,
>> which already does a great job at editing.
>
> That sounds like a nice replacement for the textarea, thanks for the
> tip! On the other hand, I think this is currently the least important
> part of the project and for the basic implementation, even a simple
> textarea should suffice, any prettier editor hopefully could be slammed
> in anytime trivially.

you may want to look at this firefox add-on, it lets you select any editor 
to edit textareas

https://addons.mozilla.org/en-US/firefox/addon/4125

David Lang

Re: GSoC 2010

[Daniel Barkalow]

On Fri, 12 Feb 2010, Sverre Rabbelier wrote:

> Heya,
> 
> On Fri, Feb 12, 2010 at 17:10, Daniel Barkalow <barkalow@iabervon.org> wrote:
> > Also note that the current helper protocol is definitely insufficient to
> > replace git-svn ('export' isn't actually specified, although I think
> > everyone who guesses how it works guesses the same thing),
> 
> I've finally started implementing this yesterday.

Great.

> > and the
> > transport code needs to be extended to handle the "dcommit" situation
> > (when you push a commit, the state that you see on the remote changes
> > based on the semantics of what you sent, but it does not change to have
> > the same hash as what you pushed).
> 
> So basically what you want to do is after you push, automagically do a
> 'git reset --hard @{u}'? That could be handled by a specific response
> from the helper to the 'export'/'push' command, perhaps it could list
> which refs need to be updated?

I think that 'export' will always have this effect, because the 
export/reimport roundtrip is practically never going to be exact with a 
remote system that isn't actually git (and the state that you see the 
remote as having after a successful push should match what you see if you 
were to clone again). People have wanted to have the remote server getting 
a push able to make changes like this as well, and so far we've resisted 
doing it, because it starts causing problems.

I'm not sure what it should do, and I'm not terribly happy about any of 
the obvious choices, but it does have to do something to be able to 
replace "git svn dcommit".

	-Daniel
*This .sig left intentionally blank*

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Fri, Feb 12, 2010 at 20:16, Daniel Barkalow <barkalow@iabervon.org> wrote:
> I think that 'export' will always have this effect, because the
> export/reimport roundtrip is practically never going to be exact with a
> remote system that isn't actually git (and the state that you see the
> remote as having after a successful push should match what you see if you
> were to clone again).

Not so, currently round-trips to Mercurial using hg-git result in
identical commits.

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Scott Chacon]

Hey,

On Fri, Feb 12, 2010 at 11:30 AM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Fri, Feb 12, 2010 at 20:16, Daniel Barkalow <barkalow@iabervon.org> wrote:
>> I think that 'export' will always have this effect, because the
>> export/reimport roundtrip is practically never going to be exact with a
>> remote system that isn't actually git (and the state that you see the
>> remote as having after a successful push should match what you see if you
>> were to clone again).
>
> Not so, currently round-trips to Mercurial using hg-git result in
> identical commits.

In most cases, this is true, but unfortunately not every VCS is as
denormalized data-wise as Git is. Hg records rename info and a
manifest of changed files in the changeset explicitly, whereas Git
figures them out from the linked trees.  This means that if some
plugin does not write the file listing or rename info properly, it's
difficult to recreate perfectly.  It also doesn't help that the method
that writes that changed-file list from contents in memory operates
subtly differently than the one that writes it from files in the
working directory.  This caused days of headaches for me trying to
keep bidirectional losslessness.

Possibly not terribly helpful information, but interesting to me nonetheless.

Scott

Re: GSoC 2010

[Jeff King]

On Wed, Feb 10, 2010 at 09:23:55PM +0100, Sverre Rabbelier wrote:

> Also, unless Shawn volunteers again, we need a Summer of Code admin
> for this year. Dscho, Peff, as you two have both jumped in for Junio
> before, do either of you have the time and inclination to do so if
> Shawn cannot? And of course, Shawn, do you have time to admin again
> this year? If not, (and no-one else steps up) I'm willing to admin
> myself, but I'll also be backup-admin and mentor for Melange, so if at
> all possible it would be awesome if someone else jumps in.

Shawn, Dscho, and I talked about it off-list. I de-nominated myself
because my wife is having a baby the week that student proposals will be
reviewed, so I will probably disappear then. I think the plan was for
Shawn to be the admin again.

-Peff

Re: GSoC 2010

[Johannes Schindelin]

Hi,

On Sun, 14 Feb 2010, Jeff King wrote:

> On Wed, Feb 10, 2010 at 09:23:55PM +0100, Sverre Rabbelier wrote:
> 
> > Also, unless Shawn volunteers again, we need a Summer of Code admin 
> > for this year. Dscho, Peff, as you two have both jumped in for Junio 
> > before, do either of you have the time and inclination to do so if 
> > Shawn cannot? And of course, Shawn, do you have time to admin again 
> > this year? If not, (and no-one else steps up) I'm willing to admin 
> > myself, but I'll also be backup-admin and mentor for Melange, so if at 
> > all possible it would be awesome if someone else jumps in.
> 
> Shawn, Dscho, and I talked about it off-list. I de-nominated myself 
> because my wife is having a baby the week that student proposals will be 
> reviewed, so I will probably disappear then. I think the plan was for 
> Shawn to be the admin again.

No, my plan was to off-load work from Shawn, who is obviously overworked.

And I only nominated you because you write _so_ long mails that I expected 
you to have spare time and Git motivation to do the job. (In fact, your 
mails are so long, and so many, that I simply cannot read them all.)

Shawn, being the guy he is, was not able to say "no". But I'd rather do 
the admin job myself than seeing him getting even more overworked. Because 
I would hate to see Shawn burn out: his work, in my opinion, has been the 
most valuable for Git in general _by far_ during the last years.

So if Shawn is as overworked as I expect, and you chicken out due too 
becoming father, I will take the job.

Ciao,
Dscho

Re: GSoC 2010

[Jeff King]

On Sun, Feb 14, 2010 at 07:15:56PM +0100, Johannes Schindelin wrote:

> > Shawn, Dscho, and I talked about it off-list. I de-nominated myself 
> > because my wife is having a baby the week that student proposals will be 
> > reviewed, so I will probably disappear then. I think the plan was for 
> > Shawn to be the admin again.
> 
> No, my plan was to off-load work from Shawn, who is obviously overworked.

Let me clarify what I said. I hope everyone who is interested will sign
up to be a potential mentor, and will help by reading and ranking
student proposals. And I include both you and me in that everyone.

But somebody needs to be the officially designated admin and the last
word on decisions, and I thought that was going to be Shawn. If you (or
anyone else) wants to do it, I would be fine with that. But I do not
feel comfortable taking on the responsibility myself.

> So if Shawn is as overworked as I expect, and you chicken out due too 
> becoming father, I will take the job.

I am not becoming a father. I am already a father, and trust me, a
newborn baby is time-consuming.

-Peff

Re: GSoC 2010

[Shawn O. Pearce]

Jeff King <peff@peff.net> wrote:
> On Sun, Feb 14, 2010 at 07:15:56PM +0100, Johannes Schindelin wrote:
> 
> > > Shawn, Dscho, and I talked about it off-list. I de-nominated myself 
> > > because my wife is having a baby the week that student proposals will be 
> > > reviewed, so I will probably disappear then. I think the plan was for 
> > > Shawn to be the admin again.
> > 
> > No, my plan was to off-load work from Shawn, who is obviously overworked.
> 
> Let me clarify what I said. I hope everyone who is interested will sign
> up to be a potential mentor, and will help by reading and ranking
> student proposals. And I include both you and me in that everyone.
> 
> But somebody needs to be the officially designated admin and the last
> word on decisions, and I thought that was going to be Shawn. If you (or
> anyone else) wants to do it, I would be fine with that. But I do not
> feel comfortable taking on the responsibility myself.

Yup.  In the private discussion off-list about this, I basically
agreed to be admin because Peff won't have the time, and it sounded
like Dscho wouldn't either.  So I volunteered out of default.

I think GSoC is a great program, and would love to see Git
participate again this year, and would hate for us to miss out
simply because we couldn't find someone to be the project admin.

Fortunately $DAY_JOB feels GSoC is important, and thus might cut
me a bit of slack during the peak program periods...

-- 
Shawn.

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Mon, Feb 15, 2010 at 17:53, Shawn O. Pearce <spearce@spearce.org> wrote:
> Fortunately $DAY_JOB feels GSoC is important, and thus might cut
> me a bit of slack during the peak program periods...

Ok, Dscho, do you want to be admin and have Shawn be backup, or the
other way around? It'd be nice if we could make a concrete decision
;).

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Mon, Feb 15, 2010 at 23:33, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> My preference is backup, but if Shawn does not want to/is not able to be
> principal admin, I will take over.

All right, Shawn, are you ok with being admin then, with Dscho as
backup? I'll update the wiki with whatever you decide.

-- 
Cheers,

Sverre Rabbelier

Re: GSoC 2010

[Johannes Schindelin]

Hi,

On Mon, 15 Feb 2010, Sverre Rabbelier wrote:

> On Mon, Feb 15, 2010 at 17:53, Shawn O. Pearce <spearce@spearce.org> 
> wrote:
> > Fortunately $DAY_JOB feels GSoC is important, and thus might cut me a 
> > bit of slack during the peak program periods...
> 
> Ok, Dscho, do you want to be admin and have Shawn be backup, or the 
> other way around? It'd be nice if we could make a concrete decision ;).

My preference is backup, but if Shawn does not want to/is not able to be 
principal admin, I will take over.

Ciao,
Dscho

Re: GSoC 2010

[Shawn O. Pearce]

Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Mon, Feb 15, 2010 at 23:33, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > My preference is backup, but if Shawn does not want to/is not able to be
> > principal admin, I will take over.
> 
> All right, Shawn, are you ok with being admin then, with Dscho as
> backup? I'll update the wiki with whatever you decide.

Yea, lets do that.

-- 
Shawn.

Re: GSoC 2010

[Sverre Rabbelier]

Heya,

On Mon, Feb 15, 2010 at 23:36, Shawn O. Pearce <spearce@spearce.org> wrote:
> Yea, lets do that.

Seems we don't record this fact anywhere on the wiki; ah well,
methinks the mailing list will serve just fine as our archive, it has
done so for a while for now :).

-- 
Cheers,

Sverre Rabbelier