[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] CDT and GitHub (was: RE: Unit testing support for Eclipse CDT)
|
* Marc Khouzam <marc.khouzam@xxxxxxxxxxxx> [2011-08-31 16:13]:
> > Create unit tests for Helgrind
> > https://bugs.eclipse.org/bugs/show_bug.cgi?id=345863
> >
> > The contributor's GitHub commit (referenced in the bug):
> >
> > https://github.com/danielhb/linuxtools/commit/3103bea0dceb75a2
> > 2e65f716d7cfc602a124586e
>
> Just to be sure, when you fetch such a commit, you will actually
> get a set of commits, if the contributor made his/her change
> using multiple commits. That way, we keep the history. Right?
In the case of this particular work, it was a single commit which I
cherry-picked. You can always cherry-pick multiple commits or rebase or
something else.
> > http://git.eclipse.org/c/linuxtools/org.eclipse.linuxtools.git
> > /commit/?id=cdd81a6ee600ef97e14fa191743415ea6457f576
> >
> > As you can see, the committer is set to me and the author
> > remains as the contributor.
>
> What is not clear is how the CQ is handled. In your case,
> you attached an actual patch to the CQ. Normally, we won't
> have such a patch.
Yeah, it was originally submitted as a patch and I verified that the
resulting git commit had the exact same content. One could always
generate a patch (using EGit [1] or `git diff`) for use in the CQ.
> http://wiki.eclipse.org/Development_Resources/Handling_Git_Contributions
> mentions to include "the URL of the ref" of the commit.
> But if the change is actually is a set of commit should we specify
> the first and last commit maybe? So that the IP reviewer knows what
> is the new code?
Sure, that's an option. If I were a contributor, I'd try to squash my
commits into as few as makes sense. Don't forget that git commits all
have pointers to their parents so it's easy to see where things
diverged.
Andrew
[1]
http://wiki.eclipse.org/EGit/User_Guide#Creating_Patches