Re: [HTCondor-devel] If you push to the HTCondor repo, please read this... (rebase vs merge)

[Douglas Thain <dthain@xxxxxx>]

FWIW, our experience building cctools at Notre Dame:

Our autobuild system only builds the final commit in a merge, as
Nathan suggests.
And, we encourage "git pull --rebase" instead of "git pull"




On Wed, Sep 17, 2014 at 7:57 AM, Nathan W. Panike
<nathan.panike@xxxxxxxxx> wrote:
> Hello,
>
> I agree with Todd that the micro-merges are annoying, but need to
> offer a correction on Batlab. My recollection is that Batlab keeps an
> internal state of where it built the last commit.  When Batlab sees a
> new commit, it runs git rev-list --ancestry-path to generate the list
> of new commits to process.  This option forces rev-list to find the
> most direct path from old to new.  So, in the case of batlab, only the
> merge commit is actually built.  Thus, using rebase might actually
> increase the load on batlab, if one has a lot of little commits that
> one is merging: the whole string of little commits will be placed on
> the ancestry path and--IIRC-- the last five commits will be built
> one-by-one.  So, if one wants to minimize the load in Batlab and to
> get rid of small merges, one will want to squash the commits, then
> rebase, then push to the central repo.
>
> Indeed, looking at
> http://submit-3.batlab.org/results/continuous.php?branch=master from
> yesterday (2014-09-16), one sees that 9146cb0 was built, but b313943
> was not built, so the batlab description above still holds.
>
> I think Alan's suggestion that one would be "concealing it behind a
> rebase" is a non-starter.  The history is only obscured by such merge
> commits, not clarified.  I believe the final HEAD commit will be the
> same tree regardless of whether one is rebasing or merging.
>
> I am agreeing that Todd is giving good advice, but for the wrong reason.
>
> On Tue, Sep 16, 2014 at 6:35 PM, Alan De Smet <adesmet@xxxxxxxxxxx> wrote:
>> If there are no changes on one of the branches, it should fast-forward, so no merge commit will be generated.
>>
>> If there are changes on both branches, it's possible that the joining of those two sets of changes will produce a non-functioning result.  It is a merge and concealing it behind a rebase seems like a mistake.  I believe we want a build/test cycle on those.
>>
>> --
>> Alan De Smet                 Center for High Throughput Computing
>> adesmet@xxxxxxxxxxx                       http://chtc.cs.wisc.edu
>> _______________________________________________
>> HTCondor-devel mailing list
>> HTCondor-devel@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel
>
>
>
> --
> Nathan Panike
>
> _______________________________________________
> HTCondor-devel mailing list
> HTCondor-devel@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/htcondor-devel