Hi,
I am fine with both. The example of the conflict between my commit and Mike’s is just a “normal usecase”. To me it looks correct how it is shown in history. At least it shows reality: 2 people were about to commit the same. This happened with SVN many times, too, but you are right it was solved by SVN through additional update (a rebase) and then try commit again. I am fine with both variants. But if we decide to only do one variant, I’d prefer to have some “howto chart” what you need to do to setup your working copy correctly (all commands for configuring @apache.org username, pull settings,…) that are local to the repository. Maybe add a shell/windows.cmd script to devtools! I don’t want to change those settings globaly, so please don’t use the magic –global setting in the example.If we have a script, we can do that per WC: - Fetch repo from git-wip-us - Run script About merge: When we get pull requests from 3rd parties, we should definitely not rebase!!!! With merging that in (in the same way how Githiub is doing it), we preserve attribution to the original commiter. We should really keep that! That is to me the only good reason to use Git! I am fine with rebasing our own stuff and make it a slight as possible, but for stuff from 3rd party people, we should really preserve what they did! So I will always use the command in the github pull request mail and apply that to my working copy and push. Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen <http://www.thetaphi.de/> http://www.thetaphi.de eMail: u...@thetaphi.de From: Shai Erera [mailto:ser...@gmail.com] Sent: Monday, January 25, 2016 8:50 AM To: dev@lucene.apache.org Subject: Re: Merge vs Rebase I agree David. I'm sure there are valid use cases for merging commits, but I always prefer rebasing. This has been our way with Apache SVN anyway, so why change it? I fell like merging only adds unnecessary lines to 'git log', where you see "Merge commits (1, 7)" but this doesn't add much information to whoever looks at it. What does it matter if this merge commit is from previous master and feature-commit? Why do we need one additional commit per change? I'm not a Git expert, but I know (think...) that if you merge C1 and C2, and C2 is a parent of C1, Git doesn't do a merge commit. Someone probably can confirm that. FWIW, I plan to continue working the 'SVN' way by doing the following: git checkout master git pull --rebase (update to latest commit/rev) git checkout -b feature git commit -a -m "feature message" git commit --amend (applying review feedback) git fetch origin master:master (a'la 'svn up' we used to do) git rebase master (now my feature commit is right on top of master's latest commit / rev) git push origin HEAD:master This will preserve the history linear and flat, which is what we currently have w/ SVN. As for merging this commit now to branch_5x. I'll admit I don't have experience working with Git w/ multiple active (feature) branches, so I'm not sure if rebasing branch_5x on my commit is what we want (cause it will drag with it all of trunk's history, as far as I understand). I might try to cheerrypick that commit only and apply to branch_5x, which is, again - AFAIU - what we used to do in SVN. However, as I said, I'm not a Git expert, so if anyone thinks I should adopt a different workflow, especially for the branch_5x changes, I'd be happy to learn. Shai On Mon, Jan 25, 2016 at 8:13 AM David Smiley <david.w.smi...@gmail.com <mailto:david.w.smi...@gmail.com> > wrote: I suspect my picture didn’t make it so I’m trying again: Or if that didn’t work, I put it on dropbox: https://www.dropbox.com/s/p3q9ycxytxfqssz/lucene-merge-commit-pic.png?dl=0 ~ David On Jan 25, 2016, at 1:07 AM, david.w.smi...@gmail.com <mailto:david.w.smi...@gmail.com> wrote: Just to put a little picture to this, I noticed the following: (see attached pic) I suspect it was the bi-product of using a merge based pull (I think the default?) instead of a rebase one, and as a result we have this little loop in the log. No doubt there is a place for merge commits (e.g. merging one feature branch and another); but is there an advocate willing to tell us the virtues that in this instance (not all instances but this one), it's a good thing? i.e. is there some insight this loop shows that that I should value more than a direct simple lineage? FWIW I prefer to rebase my commits to prevent these little merge bubbles. It happens automatically with this setting: git config --global pull.rebase true Alternatively it could be done without the --global flag. I would most appreciate it if other committers used this same setting, and I think we'd all mutually appreciate it as well with cleaner git histories. ~ David -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
