On Tue, Mar 8, 2016 at 10:35 AM, <[email protected]> wrote: > I'm following what Luciano recommended, and I am at this point: > I would not recommend merging when merge creates an empty commit. I would > do something like : > > git checkout master <-- done > git pull --rebase <-- done > git checkout quarks-3 <-- done > git rebase master <-- done > git checkout master <-- done > > Now, here you can do two things <-- have not done that yet > git merge quarks-3 > but make sure with git log or git k that you don't have a empty merge > commit like this > > http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%3C075f51d86d934da5b327675955cf4e53%40git.apache.org%3E > Can you explain what you mean by saying it has an empty merge? I don't > see what you mean when I look at that link ? Thanks > > or you could also use > git cherry-pick <commit hash> > > git push > >
Let's take an example of QUARKS-7 fix. The actual fix was this commit, which you actually see the changes inside : http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%[email protected]%3E But, because merge was used, then you get an extra commit, where the title does not mean much (only says merge blah, blah, blah) and it also does not have any good context of the changes inside (e.g. diff) http://mail-archives.apache.org/mod_mbox/incubator-quarks-commits/201603.mbox/%[email protected]%3E If cherry-pick or rebase was used, this extra commit was not going to be present, and when viewed in a graphical git tool, you would see a linear code stream, instead of multiple branches going back and forth from master. Some other projects have these automated, with some advanced stuff such as automatically close of related jiras, etc... https://github.com/lresende/spark/blob/master/dev/merge_spark_pr.py -- Luciano Resende http://people.apache.org/~lresende http://twitter.com/lresende1975 http://lresende.blogspot.com/
