Chris Lattner <clatt...@apple.com> writes:
>> On Jun 2, 2016, at 11:42 AM, via lldb-dev <lldb-dev@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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
