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

["Nathan W. Panike" <nathan.panike@xxxxxxxxx>]

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