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]
