On Fri, Aug 7, 2015 at 12:14 AM, Konstantin Boudnik <[email protected]> wrote:
> On Wed, Aug 05, 2015 at 03:22PM, Artem Shutak wrote: > > Inline. > > > > On Wed, Aug 5, 2015 at 3:31 AM, Dmitriy Setrakyan <[email protected] > > > > wrote: > > > > > Huge +1 on pull requests. Would be great if we could make TC work with > > > that. > > > > > > On Tue, Aug 4, 2015 at 5:30 PM, Alexey Kuznetsov < > [email protected]> > > > wrote: > > > > > > > Artem, two comments: > > > > > > > > 1) Did you investigate possible workflow with "pull request" instead > of > > > > "patches"? > > > > > > > Yes, I'm investigating this approach. > > > > > > > > 2) In your instruction I see "merge" from master, but as I remember > there > > > > was a discussion of using "rebase". > > > > > > > I don't like rebase. Actually, at example from wiki it's not important, > > what will be used "rebase" or "merge", but with "merge" a contributor > will > > have more simple conflict resolving. The git-format-patch.sh script will > > create patch file with only one commit, which contains all changes at > > development branch (the branch local), so it will not save a history of > > commits. > > We have discussed exactly this point in length: why would you need to > preserve > a potentially nonsensical commits like > "Oh damn - I forgot to remove the comment in this file" > > Also, I don't see how merge is easier from the conflict resolution POW. > What > did you mean by that? > I could be wrong, but in my understanding, with 'merge' you have 3 source version of file: state of file at first branch, at second branch and a 'base' (a state of file for both branches before changes), with 'rebase' you don't have the 'base' . In some cases this information can be really helpful. Artem > > Cos > > > > > > What do you think? > > > > > > > > -- > > > > Alexey Kuznetsov > > > > GridGain Systems > > > > www.gridgain.com > > > > > > > >
