Jakub NarebskiHow 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
Shawn O. PearceRe: GSoC status report
Jakub Narebski <jnareb@gmail.com> 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.
Johannes SchindelinRe: GSoC status report
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.
Jakub NarebskiRe: GSoC status report
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
Johannes SchindelinRe: GSoC status report
Hi,
On Sat, 21 Jul 2007, Jakub Narebski wrote:
> 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?
They are builtins since v1.5.1~170^2~2.
Hth, Dscho