search for: restructoring

...er branching, I would like to see it clarified for how this improves the workflow. I have dealt with many open source projects and many VCS variants. I don't see a noticable improvement from using Git compared e.g. to SVN for sane usage of branches -- be it short-term feature branches, mid-term restructoring or long-term release branches. The exception may be doing wild cross branch merging and long dependency chains between branches like done in the Linux kernel -- but I don't think that's a sane development model and I certainly don't see that agreeing with the development policy of LLVM....

...d like to see it clarified for how this improves the workflow. I > have dealt with many open source projects and many VCS variants. I > don't see a noticable improvement from using Git compared e.g. to SVN > for sane usage of branches -- be it short-term feature branches, > mid-term restructoring or long-term release branches. Merging support in svn is brain-dead. Having a single commit "Merged branch foo rX:Y" is hardly informative. Having the actual chunk of VC history merged into the target branch is the Right Thing. > The exception > may be doing wild cross branch merg...

...d like to see it clarified > for how this improves the workflow. I have dealt with many open source > projects and many VCS variants. I don't see a noticable improvement from > using Git compared e.g. to SVN for sane usage of branches -- be it > short-term feature branches, mid-term restructoring or long-term release > branches. The exception may be doing wild cross branch merging and long > dependency chains between branches like done in the Linux kernel -- but > I don't think that's a sane development model and I certainly don't see > that agreeing with the develop...

fly language <flylanguage at gmail.com> writes: >> After git, mainline will still be the most important branch for the >> *project*, >> but you will work with quite a few branches on parallel. >> >> > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to > maintain the "mainline". > > The git workflow works really

> After git, mainline will still be the most important branch for the > *project*, > but you will work with quite a few branches on parallel. > > Who's mainline? :) Be prepared to assign a super-merger, like Linus, to maintain the "mainline". The git workflow works really really great, but it does require getting rid of mainline thinking. It doesn't exist.