Well put Mark. It's definitely not an either-or, it's about judicious use of merge commits.
And, someone correct me if I'm wrong, but I think we decided to switch from svn to git* but otherwise keep things the same.* Wouldn't that preclude these little merge bubbles? This is because 'svn' does the equivalent of a git rebase when pushing a new commit that isn't otherwise some explicit merge. Thus that has been our workflow, and I think we agreed not to change the workflow. I definitely think we should minimize what we're changing step by step (and I think we agreed to that notion); and so the workflow should be the same until a bit of time passes and someone proposes a specific change. We still haven't heard from an *advocate* of these git little merge bubbles, and this one in particular to keep this decision concrete rather than abstract. I suspect there is no advocate. If committers are only "fine" with them (ambivalent), or not-fine, then I think we should not have them. But should we hypothetically decide to have these merge bubbles, I think we should not do them now -- see last paragraph. ~ David On Mon, Jan 25, 2016 at 9:15 AM Mark Miller <[email protected]> wrote: > Yup, these are the nasty little merge commits that if you do every time > make the history ridiculous. > > Though before our 'touchy' committers go nuts again, it's not about merge > vs rebase, it's about proper use of merge commits. You can avoid them with > squash merges as well, rebase is simply one option. It's really about the > decision of when a merge commit adds value and when it doesn't. If you keep > adding them when they add no value, it's just a useless mess. > > Rebase is just one way to keep sane history though. The merge command > *can* do it too if you know what you are doing. > > Mark > On Mon, Jan 25, 2016 at 4:37 AM Shai Erera <[email protected]> wrote: > >> I usually do 'git commit --amend', but I agree Dawid, especially in those >> JIRA issues which are logically sub-divided into multiple sub-tasks, with >> ISSUE-1.patch, ISSUE-2.patch.. that keeping all the commits in the history >> is beneficial. But if I upload a patch, get reviews and intend to upload an >> updated patch, I will --amend my commit. >> >> I also agree w/ Uwe, I think it will really help if we have a >> guidelines/cheatsheet that document how do we expect dev to happen in the >> Git world. What you (Dawid) put on Github is great for Git newcomers, but >> as a community I think that having rough standards and guidelines will >> help, especially the newcomers who may make work one way just because they >> read about it somewhere. The merge/rebase and especially between master and >> branch_5x are a good starting point to alleviate confusion and setting >> expectations / proposing a workflow. >> >> > git merge origin/master # merge any changes from remote master, >> >> I would do a rebase here. Is there a reason you pick merge in the example >> - i.e. do u think it's the preferred way, or was it just an example? >> (asking for educational reasons) >> >> Shai >> >> On Mon, Jan 25, 2016 at 10:48 AM Dawid Weiss <[email protected]> >> wrote: >> >>> > [...] merge C1 and C2, and C2 is a parent of C1, Git doesn't do a >>> merge commit. Someone probably can confirm that. >>> >>> No, there is freedom in how you do it. You can do a fast-forward merge >>> or a regular merge, which will show even a single commit which would >>> otherwise be linear as a diversion from history. >>> >>> There is no way to "script rebase" since rebases can cause conflicts >>> and these need to be resolved. If you wish to avoid these "bubbles" >>> then I'd suggest to: >>> >>> 1) *never* work on any remote-tracking branch directly, branch your >>> feature branch and work on that, merging from remote branch until >>> you're ready to commit. >>> >>> git fetch origin >>> git checkout master -b myfeature >>> while (!done) { >>> ... work on myfeature, committing to myfeature >>> git fetch origin >>> git merge origin/master # merge any changes from remote master, >>> resolving conflicts >>> } >>> >>> # when done, either rebase myfeature on top of origin/master and do a >>> fast-forward commit (preserves history of all intermediate commits) or >>> squash the entire feature into a single commit. >>> >>> git checkout master >>> git pull # this will never conflict or rebase anything since you >>> never had any own changes on master >>> git merge --squash myfeature >>> git commit -m "myfeature" >>> >>> By the way -- having those "bubbles" in history can be perceived as >>> beneficial if you merge features that have multiple commits because >>> then you "see" all the intermediate commits and you can revert the >>> entire feature in one step (as opposed to multiple fast-forward >>> commits). >>> >>> Dawid >>> >>> >>> >>> Dawid >>> >>> >>> On Mon, Jan 25, 2016 at 9: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] >>> >>> -- > - Mark > about.me/markrmiller > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
