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 <ser...@gmail.com> 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 <dawid.we...@gmail.com>
> 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 <u...@thetaphi.de> 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: 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>
>> > 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 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: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>> --
- Mark
about.me/markrmiller
