search for: gitflow

...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...

> 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 >

...ories 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 >&...

>On 3 June 2016 at 10:03, George Rimar via llvm-dev ><llvm-dev at lists.llvm.org> wrote: >> +1. I am also bit concerned here. Never used git, but it is fine, I am ready to learn, >> but now when I am using TortoiseSVN the only command line I am using is for creating the >> final patch (though I think that is also available in GUI). >> And what I heard in this