> [...] 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
