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

> On Jun 2, 2016, at 11:42 AM, via lldb-dev <lldb-dev at
lists.llvm.org> wrote:
> 
> Yeah, I get that and I actually don't mind keeping a linear history.
> But we definitely should branch for release.  Given release branches,
> there are a number of questions and tradeoffs about how to backport
> changes from master/latest development to a release.  Some of those
> options break linear history.  This is the kind of workflow stuff we
> should clarify if possible.
+1 for branching for official llvm.org releases, and each branch should have its
own linear history (from its branch point).

I don’t think we want people’s random projects and development branches on
llvm.org.  They can clone to repo off to their own fork on github and do what
they want there.

-Chris

On Fri, Jun 3, 2016, 10:06 PM Chris Lattner via lldb-dev <
lldb-dev at lists.llvm.org> wrote:
>
> > On Jun 2, 2016, at 11:42 AM, via lldb-dev <lldb-dev at
lists.llvm.org>
> wrote:
> >
> > Yeah, I get that and I actually don't mind keeping a linear
history.
> > But we definitely should branch for release.  Given release branches,
> > there are a number of questions and tradeoffs about how to backport
> > changes from master/latest development to a release.  Some of those
> > options break linear history.  This is the kind of workflow stuff we
> > should clarify if possible.
>
> +1 for branching for official llvm.org releases, and each branch should
> have its own linear history (from its branch point).
>
> I don’t think we want people’s random projects and development branches on
> llvm.org.  They can clone to repo off to their own fork on github and do
> what they want there.
>
>
This and Chris's last post summarize my thoughts on the subject here.

I'm largely agnostic on a move to git or not, however, as far as hosting
services I would prefer github to the others just due to the convenience
with other projects hosted there as well.

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160604/642b7746/attachment.html>

Chris Lattner <clattner at apple.com> writes:
>> On Jun 2, 2016, at 11:42 AM, via lldb-dev <lldb-dev at
lists.llvm.org> wrote:
>> 
>> Yeah, I get that and I actually don't mind keeping a linear
history.
>> But we definitely should branch for release.  Given release branches,
>> there are a number of questions and tradeoffs about how to backport
>> changes from master/latest development to a release.  Some of those
>> options break linear history.  This is the kind of workflow stuff we
>> should clarify if possible.
>
> +1 for branching for official llvm.org releases, and each branch
> should have its own linear history (from its branch point).
My only hesitation with this is that this requires use of cherry-pick,
which is not idea.  The way most git repositories work is to put
everything that should go into a release branch in the release branch
*first* and then merge the release branch to master, ensuring that
everything going out in a release will make it into the next release.
This is how the gitflow workflow works, for example.

The advantage to this is one can use built-in git tool to ask questions
like, "is this commit in the release branch?"  With cherry-pick you
get
logically duplicate commits and making such queries is more cumbersome.

                         -David

On Mon, Jun 06, 2016 at 10:32:45AM -0500, via llvm-dev
wrote:
> My only hesitation with this is that this requires use of cherry-pick,
> which is not idea.  The way most git repositories work is to put
> everything that should go into a release branch in the release branch
> *first* and then merge the release branch to master, ensuring that
> everything going out in a release will make it into the next release.
> This is how the gitflow workflow works, for example.
The model of "commit to oldest first" is IMO one of the most stupid
concepts I have ever seen in git "workflows". It is contrary to the
way
software development works and essentially just a bad workaround for
broken cherry picks. I've seen more than one project starting to use
this model due to advocacy after deciding to use git, stumble around
with it for a release or two and then going back to a normal release
management approach. Even the argument you have presented here does not
make sense to me. Just because a change has been committed to a release
branch, doesn't mean it won't get replaced later.

Joerg