I don't think anyone here says "no merges at all", but rather I feel the direction is "rebase whenever possible, merge when you must or it makes sense". I realize that the last part is fuzzy and open, and maybe that's why Dawid (I think?) suggested that we don't change much yet, but rather let this new Git roll in, let everyone feel it and experience it, and then perhaps a month-two from now we can discuss how we want to have commits done in the project.
About history, when I look at 'git log' in branch_5x, it looks like that: --------------------- commit 51396b8cf63fd7c77d005d10803ae953acfe659f Merge: *5319ca6* *6df206a *Author: Michael McCandless <[email protected]> Date: Sun Jan 24 16:51:39 2016 -0500 merged commit *5319ca6*11a7dabc07d23a63555ff2df39596d00e Author: Michael McCandless <[email protected]> Date: Sun Jan 24 16:48:51 2016 -0500 revert this est change until we can fix geo API border cases (LUCENE-6956) commit *6df206a*51dee447e9f4625d864ffd80778bdf8ff Author: Uwe Schindler <[email protected]> Date: Sun Jan 24 22:05:38 2016 +0100 LUCENE-6938: Add WC checks back, now based on JGit ---------------------- The 'merged' commit, in this case, seems redundant to me as it doesn't add any useful information about them. I believe this case isn't an example one for a merge. Just my thoughts... Shai On Mon, Jan 25, 2016 at 9:30 PM Michael McCandless < [email protected]> wrote: > I am very much a git newbie, but: > > > The example of the conflict between my commit and Mike’s is just a > “normal usecase”. > > It did not happen in this case, but what if there were tricky > conflicts to resolve? And I went and did that and then committed the > resulting merge? I would want this information ("Mike did a hairy > conflict ridden merge using Emacs while drinking too much beer") to be > preserved because it is in fact meaningful, e.g. to retroactively > understand how bugs were introduced, as one example. > > If I understand it right, a git pull --rebase would also introduce > conflicts, which I would have (secretly) resolved and then committed > as if I had gone and spontaneously developed that patch suddenly? > > I think it's odd to insist on "beauty" for our source control history > when in fact the reality is quite messy. This is like people who > insist on decorating the inside of their home as if they live in a > museum when in reality they have four crazy kids running around. > > Mike McCandless > > http://blog.mikemccandless.com > > On Mon, Jan 25, 2016 at 3:34 AM, Uwe Schindler <[email protected]> wrote: > > 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 > > > > eMail: [email protected] > > > > > > > > From: Shai Erera [mailto:[email protected]] > > Sent: Monday, January 25, 2016 8:50 AM > > To: [email protected] > > 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 <[email protected]> > > 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, [email protected] 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
