codestriker-user

[Codestriker-user] git support

[Jeffrey M. <je...@gm...>]

David: I believe one of my coworkers emailed you several months back
about git support.  Last week he came and asked me to look at adding
it, and I took a stab at it.  I believe that diff retrieval, diff
parsing, and retrieval for parallel view work.  This is the first Perl
I've written, and I'd still consider it more of a rough draft, so I'm
sure there's plenty of room for improvement.  I've attached a patch
(relative to v1.9.9) for what I've done so far, hoping for some
feedback!

In particular, I'm wondering about git diff's support for copy and
rename detection.  It'd be nice for a copy or rename to show up as
such in the filename list, and not unnecessarily show a diff
containing the entire contents of the file.  This information is
printed in the header of the patch, so it's very easy for the parser
to detect (don't know about other differs; have never used CVS/SVN). I
don't see any support for this anywhere else in the diff parsers, and
it doesn't look like the code's quite set up to handle it. Thoughts?

Thanks,
Jeffrey

Re: [Codestriker-user] git support

[MARK K. <mar...@mo...>]

Not to take away from Codestriker at all, but Gerrit is a tool for Git that
is already out there so there is no need to reinvent the wheel.  It it kinda
like codestriker for Git but it does more than that.  It stands in front of
the actual Git repository.  You submit your commits directly to Gerrit and
only after review and approval do they get merged into the respository.  See
http://code.google.com/p/gerrit/


-- 
Mark Keisler
Principal Software Engineer
Motorola Open Source Technologies




On Tue, Sep 22, 2009 at 3:14 PM, Jeffrey Middleton <je...@gm...>wrote:

> David: I believe one of my coworkers emailed you several months back
> about git support.  Last week he came and asked me to look at adding
> it, and I took a stab at it.  I believe that diff retrieval, diff
> parsing, and retrieval for parallel view work.  This is the first Perl
> I've written, and I'd still consider it more of a rough draft, so I'm
> sure there's plenty of room for improvement.  I've attached a patch
> (relative to v1.9.9) for what I've done so far, hoping for some
> feedback!
>
> In particular, I'm wondering about git diff's support for copy and
> rename detection.  It'd be nice for a copy or rename to show up as
> such in the filename list, and not unnecessarily show a diff
> containing the entire contents of the file.  This information is
> printed in the header of the patch, so it's very easy for the parser
> to detect (don't know about other differs; have never used CVS/SVN). I
> don't see any support for this anywhere else in the diff parsers, and
> it doesn't look like the code's quite set up to handle it. Thoughts?
>
> Thanks,
> Jeffrey
>
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry&reg; Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9&#45;12, 2009. Register now&#33;
> http://p.sf.net/sfu/devconf
> _______________________________________________
> Codestriker-user mailing list
> Cod...@li...
> https://lists.sourceforge.net/lists/listinfo/codestriker-user
>
>

Re: [Codestriker-user] git support

[David S. <dav...@gm...>]

Hi Jeffrey,

At a quick glance, that looks great.  Thanks for passing it on.

> In particular, I'm wondering about git diff's support for copy and
> rename detection.  It'd be nice for a copy or rename to show up as
> such in the filename list, and not unnecessarily show a diff
> containing the entire contents of the file.  This information is

We have this issue with Subversion diffs at the moment too..
Codestriker pretty much just reproduces the diff it was given.  You'd
have to perhaps update the filename "field" to contain this
information (copied from ...).  This is how Subversion diffs actually
represent it.

Do you have some example git diffs?  Perhaps you can add those into
t/FileParser/git.t?

Also - just so I can update the documentation, can you email me some
example repository strings for the git repository?

Cheers,
David

Re: [Codestriker-user] git support

[Jeffrey M. <je...@gm...>]

On Tue, Sep 22, 2009 at 7:40 PM, MARK KEISLER <mar...@mo...> wrote:
> Not to take away from Codestriker at all, but Gerrit is a tool for Git that
> is already out there so there is no need to reinvent the wheel.  It it kinda
> like codestriker for Git but it does more than that.  It stands in front of
> the actual Git repository.  You submit your commits directly to Gerrit and
> only after review and approval do they get merged into the respository.  See
> http://code.google.com/p/gerrit/
>
>
> --
> Mark Keisler
> Principal Software Engineer
> Motorola Open Source Technologies

Thanks for the tip.  I didn't actually have anything to do with the
choice of Codestriker; I'm just the guy who got asked to add git
support.  I think the decisions probably pretty solid at this point.
but I'll certainly suggest it and have a look.  We're still
prototyping, so I suspect it'll be a while before [usefully] reviewing
every commit is at all feasible.

Jeffrey

Re: [Codestriker-user] git support

[David S. <dav...@gm...>]

> Thanks for the tip.  I didn't actually have anything to do with the
> choice of Codestriker; I'm just the guy who got asked to add git
> support.  I think the decisions probably pretty solid at this point.
> but I'll certainly suggest it and have a look.  We're still
> prototyping, so I suspect it'll be a while before [usefully] reviewing
> every commit is at all feasible.

Something to consider too is possibly writing a post-commit script to
automatically create topics.  We do that at my work (we use
subversion) and its quite handy.

We have adopted a code review practice where we do post-commit
reviews, and having a script to automatically create the topic saves a
lot of time.  We used to do pre-commits, but found this could become a
bit of a bottleneck - especially as the team grew in size.

Presumably this could be done with git too.

Cheers,
David