GSoC status report

How it goes with Google Summer of Code git projects:
builtinification, libification and GitTorrent?

I can see that builtinification (and perhaps libification) goes quite 
well; what about GitTorrent project? Does anybody know how Mono SoC 
project: "Managed C# git implementation" goes?

-- 
Jakub Narebski
Poland

Jakub Narebski [off-list ref] wrote:

How it goes with Google Summer of Code git projects:
builtinification,

Carlos is making good progress, he's had a few versions of git-tag
posted, and incorporated feedback into it.  Hopefully we'll see that
finialize and merge into Junio's tree in the not-too-distant future.

libification

Luiz and I have have been working mostly off-list on this, as we
wanted to get something solid that the list can actually look at
and comment on, rather than just speculate.  Luiz has something he's
just about ready to share with us, and may post about it next week.
I don't want to steal his thunder, so I'm staying quiet on the
topic for now.  ;-)

and GitTorrent?

Unfortuantely this isn't a project under GSoC anymore.  The student
involved had some issues with being able to get his paperwork
completed for Google and was not able to participate this summer.
I have not heard much more than that.
 

I can see that builtinification (and perhaps libification) goes quite 
well; what about GitTorrent project? Does anybody know how Mono SoC 
project: "Managed C# git implementation" goes?

I haven't heard anything on it, or looked into it since the start.
I did reach out to both the student and Miguel, and got responses
back from them at that time, but have not heard anything since.
A Google search turned up the Mono GSoC status update mailing list,
which has weekly posts from a bunch of other Mono related projects,
but none about the C# Git implementation.  I'm suspecting maybe it
is dead.

-- 
Shawn.

Hi,

On Fri, 20 Jul 2007, Jakub Narebski wrote:

How it goes with Google Summer of Code git projects:
builtinification, libification and GitTorrent?

For my part, I am very pleased with the progress Carlos is making with 
builtinification.  He is quite familiar with the source code by now, and 
with the style We Do Things Here(tm).  Even though _he_ thinks the 
progress is slow, I do not.  The first phase was to get acquainted with 
the code, and with the techniques to convert shell code into C.

And since Kristian joined into the builtinification process, and since 
Carlos and Kristian are working together quite nicely, I am even more 
happy.

FWIW this is the list of scripts that I would like to see converted by the 
end of the year (feel free to object), ordered by their size:

verify-tag, reset, repack, tag, checkout, rebase, bisect, 
rebase--interactive, am, commit.

It looks like 'tag' and 'commit' are pretty near to completion, with 'tag' 
already being in the 'next' branch, and verify-tag will probably follow 
soon.

The list left out two clusters: 'fetch' related scripts (pull, ls-remote, 
parse-remote, fetch, clone) and 'merge' related scripts (merge-ours, 
merge-resolve, merge-stupid, merge-octopus, merge)¹.

Julian and Daniel are working on the fetch front, and the progress is 
awesome.  I especially like the abstraction we have now, so that new 
transports are much easier to implement.  I am even tempted to have a go 
at 'pushing' to bundles.

Seems like I got the 4 people I wished for the builtin project, in a way 
;-)

IMHO 'stash', 'submodule' and 'filter-branch'² are not yet ready to be 
made builtin.

As for the merge stuff, I consider it too soon, too, especially since 
"git-merge" is a critical part of core Git _and_ quite long (even if the 
same arguments would apply to 'commit', too, but Kristian is already at 
work ;-)

Ciao,
Dscho

Footnote 1: I left out merge-one-file, since I have an (untested) builtin 
in my tree.  So there is not really much work to do there, I only have to 
find some time to research how to test this script properly.

Footnote 2: Sven is working on rewrite-commits, which is somewhat more 
limited than filter-branch ATM, though faster.  As Junio suggested, we can 
always consider using rewrite-commits as a fast backend to filter-branch, 
once both rewrite-commits and filter-branch stabilised.

Johannes Schindelin wrote:

FWIW this is the list of scripts that I would like to see converted by the 
end of the year (feel free to object), ordered by their size:

verify-tag, reset, repack, tag, checkout, rebase, bisect, 
rebase--interactive, am, commit.

I thought that verify-tag would be put into git-tag, with git-verify-tag
being alias to "git tag --verify" or something like that.

What about git-revert and git-cherry-pick (it is one script)? Or are you
simply concentrating on the tools you need most in common workflow?


Thanks for the reply
-- 
Jakub Narebski
Poland

Hi,

On Sat, 21 Jul 2007, Jakub Narebski wrote:

Johannes Schindelin wrote:

quoted

FWIW this is the list of scripts that I would like to see converted by the 
end of the year (feel free to object), ordered by their size:

verify-tag, reset, repack, tag, checkout, rebase, bisect, 
rebase--interactive, am, commit.

I thought that verify-tag would be put into git-tag, with git-verify-tag
being alias to "git tag --verify" or something like that.

What about git-revert and git-cherry-pick (it is one script)? Or are you
simply concentrating on the tools you need most in common workflow?

They are builtins since v1.5.1~170^2~2.

Hth,
Dscho