llvm dev - Jun 2016 - [cfe-dev] [lldb-dev] GitHub anyone?

> On Jun 2, 2016, at 11:03 AM, dag at cray.com wrote:
> 
> Tim Northover via cfe-dev <cfe-dev at lists.llvm.org> writes:
> 
>> On 31 May 2016 at 13:45, Mehdi Amini via lldb-dev
>> <lldb-dev at lists.llvm.org> wrote:
>>> Apparently I wasn't very clear: llvm and clang (and the others
>>> projects) would be simple decoupled, individual git
>>> repositories. You would be able to check them out however you want
>>> and commit to them individually.
>>> There would be an extra "integration repository" on top
that would
>>> only provide the service that tells "r12345 is llvm:36c941c
>>> clang:eaf492b compiler-rt:6d77ea5". This repository should be
>>> managed transparently by some server-side integration.
>> 
>> This actually sounds like a really good idea even if a full move to
>> git gets blocked for some reason. It seems like it could be a fairly
>> common requirement: I don't suppose you know of an existing script
>> that could do it? If not, I may take a stab.
> 
> How do you get monotonically increasing number with a history graph?
I think what we're trying to get is a "pushed" revision number,
i.e. tracking the state of the upstream repositories at a given time.

> There are multiple ways to linearize the history.
> 
> You can simply disallow merges I guess but that seems not much better
> than just sticking with SVN.  GitHub's pull request model kind of
breaks
> down if you can't do merges.
Github has an automatic "squashed" mode for pull requests now, I
haven't tested in practice but it may help.

-- 
Mehdi

> > How do you get monotonically increasing number with a history graph?
> 
> I think what we're trying to get is a "pushed" revision
number, i.e.
> tracking the state of the upstream repositories at a given time.
I think I've mentioned this before but internally we are (mostly) using
"rev-list --count --first-parent branch-name" which gives us a 
monotonically increasing number per-branch.  The --first-parent means 
each merge counts as one, which is enough for build-number uniqueness.
Unique sequential build numbers meet our internal needs.  If this number
gets incorporated into the version numbering self-reported by Clang/LLVM,
then it's not hard to map back onto git commits.
--paulr

> On Jun 2, 2016, at 11:22 AM, Robinson, Paul <paul.robinson at
sony.com> wrote:
> 
>>> How do you get monotonically increasing number with a history
graph?
>> 
>> I think what we're trying to get is a "pushed" revision
number, i.e.
>> tracking the state of the upstream repositories at a given time.
> 
> I think I've mentioned this before but internally we are (mostly) using
> "rev-list --count --first-parent branch-name" which gives us a 
> monotonically increasing number per-branch.  The --first-parent means 
> each merge counts as one, which is enough for build-number uniqueness.
> Unique sequential build numbers meet our internal needs.  If this number
> gets incorporated into the version numbering self-reported by Clang/LLVM,
> then it's not hard to map back onto git commits.
I think I've answered to this before but it does not help to solve the
cross-repository problem, we need a "meta integration repository".

-- 
Mehdi

Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes:
>> How do you get monotonically increasing number with a history graph?
>
> I think what we're trying to get is a "pushed" revision
number,
> i.e. tracking the state of the upstream repositories at a given time.
Ah, that is something else entirely.  We use Stash/BitBucket here and it
numbers pull requests monotonically.  That numbering reflects when the
PR is created, NOT when it is merged, though.
>> You can simply disallow merges I guess but that seems not much better
>> than just sticking with SVN.  GitHub's pull request model kind of
breaks
>> down if you can't do merges.
>
> Github has an automatic "squashed" mode for pull requests now, I
> haven't tested in practice but it may help.
IMHO squashed commits are a bad idea from a bisect perspective.  One of
the great benefits of git is the easy of creating small,
logically-independent commits that can be bisected.  Squashing
eliminates that advantage.

An automatic rebase of the branch and fast-forward merge would be a fine
way to maintain linear history.  I have no idea how/if GitHub supports
that though.

                           -David

On 6/2/2016 1:48 PM, via llvm-dev wrote:
> Mehdi Amini via llvm-dev <llvm-dev at lists.llvm.org> writes:
>
>> Github has an automatic "squashed" mode for pull requests
now, I
>> haven't tested in practice but it may help.
> IMHO squashed commits are a bad idea from a bisect perspective.  One of
> the great benefits of git is the easy of creating small,
> logically-independent commits that can be bisected.  Squashing
> eliminates that advantage.
>
> An automatic rebase of the branch and fast-forward merge would be a fine
> way to maintain linear history.  I have no idea how/if GitHub supports
> that though.
>
>                             -David
Squashing or not depends a lot on personal workflow and the automation 
that is in place.  On a different project I maintained, there was 
automation that would retrigger tests when a personal branch on github 
was updated.  This encouraged committers to submit lots of tiny patches 
that didn't necessarily make sense in isolation.  You'd get intermediate
commit messages like "fixed a semi" or "asdfafshg".  The
overall branch
and pull request would make sense.  There was also value to the 
individual in that they could commit frequently, try out crazy stuff, 
and rewind if necessary.  The end result though was that you would have 
a branch that would either ugly up the history a lot, or require a squash.

Some people prefer to trigger those kinds of automation tasks with a git 
commit --amend.  While this keeps branch history clean, you lose 
intermediate states, making it more difficult to rewind when your 
in-progress work goes bad.  It also makes life harder for anyone that 
forks your branch, as now you are rewriting history.

So my opinion on this is that you either need to deal with the evils of 
--amend, or you need to have a squash somewhere in the process, or you 
need to get everything right the first time.  My preference is for a 
squash in the middle.

Note that this entire line of reasoning is assuming that we are talking 
about small topic / bug fixing branches.  If you have a "big" branch, 
then that "big" branch needs to have a clean history as well.  I think
that a regular, un-squashed merge is the best way to handle "big"
branches.


-- 

Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux
Foundation Collaborative Project

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160602/f5d13f82/attachment.html>