You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "david.w.smiley@gmail.com" <da...@gmail.com> on 2016/01/25 07:07:20 UTC
Merge vs Rebase
[image: lucene-merge-commit-pic.png]
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
Re: Merge vs Rebase
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Mon, Jan 25, 2016 at 2:49 AM, Shai Erera <se...@gmail.com> wrote:
This has been our way with Apache SVN anyway, so why change it?
>
I don't consider this a valid argument ;) Git is a new tool, it opens up
new features. We shouldn't "lock ourselves into the SVN" way just because
"that is what we have always done".
Do you still restrict yourself to what "vi" was able to do while using
Eclipse ;)
Mike McCandless
http://blog.mikemccandless.com
RE: Merge vs Rebase
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
> > The example of the conflict between my commit and Mike’s is just a
> “normal usecase”.
It was meant as a conflict in workflow (two people committing at almost same time). And that happens quite often.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Yonik Seeley <ys...@gmail.com>.
On Mon, Jan 25, 2016 at 2:47 PM, Shai Erera <se...@gmail.com> wrote:
> 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...
+1
For back-porting the majority of issues from trunk to 5x, cherry-pick
should definitely be the default we point to.
"merge" is about merging *all* changes from a branch, so it won't even
work unless one has a separate feature branch for the change being
back-ported.
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Mark Miller <ma...@gmail.com>.
On Mon, Jan 25, 2016 at 3:11 PM Dawid Weiss <da...@gmail.com> wrote:
> > commit 51396b8cf63fd7c77d005d10803ae953acfe659f
> > Merge: 5319ca6 6df206a
> >
> > The 'merged' commit, in this case, seems redundant to me as it doesn't
> add
> > any useful information about them.
>
> It tells you exactly which two parent commits this merge actually
> joins. In terms of patches -- this tells you which two different
> "lines" of patches this commit consolidates. This isn't unimportant
> information.
>
>
Depends on the change, who you are, and what you care about.
It's a discussion that's already been had 100000 times on the internet. We
won't break any new ground here.
Most of the other Apache projects go for linear history and rebase (eg see
the Hadoop projects https://wiki.apache.org/hadoop/HowToCommit). Other
projects don't. It's simply a religious decision.
- Mark
--
- Mark
about.me/markrmiller
Re: Merge vs Rebase
Posted by Shai Erera <se...@gmail.com>.
As a person looking at the history, I don't care what this particular
commit merged. I only care about the two commits before it. They're the
ones with content, they're the ones I'll want to 'git show' ... most likely.
Anyway, we don't have to agree on this, but I do suggest that we come up w/
a standard. Otherwise, we'll see a mess. I personally prefer rebase, but if
the project decided to do merge, I'll adopt that and apply it. I'm not
going to argue much because aside from aesthetics and cleanup of 'git log',
I don't feel knowledgeable enough to argue against one or the other.
Shai
On Mon, Jan 25, 2016 at 10:11 PM Dawid Weiss <da...@gmail.com> wrote:
> > commit 51396b8cf63fd7c77d005d10803ae953acfe659f
> > Merge: 5319ca6 6df206a
> >
> > The 'merged' commit, in this case, seems redundant to me as it doesn't
> add
> > any useful information about them.
>
> It tells you exactly which two parent commits this merge actually
> joins. In terms of patches -- this tells you which two different
> "lines" of patches this commit consolidates. This isn't unimportant
> information.
>
> Think of Solr and Lucene, for example -- the merge commit that glues
> the two projects together looks exactly like the one above: it
> connects two different lines of (thousands) of patches that in the
> result form Lucene-Solr.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Merge vs Rebase
Posted by Dawid Weiss <da...@gmail.com>.
> commit 51396b8cf63fd7c77d005d10803ae953acfe659f
> Merge: 5319ca6 6df206a
>
> The 'merged' commit, in this case, seems redundant to me as it doesn't add
> any useful information about them.
It tells you exactly which two parent commits this merge actually
joins. In terms of patches -- this tells you which two different
"lines" of patches this commit consolidates. This isn't unimportant
information.
Think of Solr and Lucene, for example -- the merge commit that glues
the two projects together looks exactly like the one above: it
connects two different lines of (thousands) of patches that in the
result form Lucene-Solr.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Shai Erera <se...@gmail.com>.
Thanks Dawid. I'll try for sport to not amend commits for a while, see how
that works out for me :). I'll admit that I already ran into needing to
revert a local change cause it didn't work, but I didn't have the "history"
to revert to ...
I don't mind typing 'git push origin HEAD:master'. I prefer commands that
are explicit. Anyway, I usually do Ctrl+R (in bash) and type the command,
which is quickly found in the history. Since it's always the same, I don't
really type it all the time.
Shai
On Mon, Jan 25, 2016 at 11:07 PM Dawid Weiss <da...@gmail.com> wrote:
> > I'll admit Dawid that I obviously still have a lot to learn about working
> > with Git, but what I wrote above reflects my workflow on another project,
> > where we also use Gerrit for doing the code reviews.
>
> I'm not a git expert too, but I've grown to like it for its,
> surprisingly, simplicity. If you grasp the idea of a commit being a
> "patch with a parent" then everything becomes really logical. Looking
> up options and switches to commands in git can be frustrating, but
> this is "implementation layer" not "understanding of what's happening"
> layer.
>
> > I was referring to our current review style -- I'll upload a patch to
> JIRA
> > and get reviews. Yes, for my own history I could commit as many as I want
> > locally, then squash what I want, drop the ones that I don't etc. At the
> > moment I'm used to amending the commit, but I know of a coworker of mine
> who
> > works like you propose -- many commits and squashing in the end.
>
> Your workflow is up to you, Shai. I think amending the same commit
> over and over is in contrast to what you use a version tracking system
> for -- you do *want* those changes layered one on top of another. If
> not for anything else, then for just the possibility that you may want
> to browse through them and see what you've changed when (I do this a
> lot).
>
> > I thought that if I'm in branch 'feature', I cannot do 'git push' since
> > there's no remote tracking branch called 'feature'.
>
> This is where git does not excel. A "git push" for one person may be
> different than for another person -- this depends... on the
> configuration.
>
> The push by default tries to send all the "matching" branches -- the
> ones you have locally that are tracking something on the remote end
> with the same name. They have been fiddling with the defaults though,
> so I'm not sure if this is still the case. Grep for "push.default"
> here:
>
> https://git-scm.com/docs/git-config
>
> > So just so I'm clear, the sequence of commands you're proposing is:
> >
> > git checkout master
> > git merge --squash feature
> # review patch here
> > git push (update origin/master)
> >
> > git checkout branch_5x
> > git cherry-pick master (or the commit hash)
> > git push (update origin/branch_5x)
>
> Yes, that's one of my favorites. It consolidates all the "working"
> state of a feature into one final diff (patch) which you can review
> (see above) before pushing. I have pushes set to "matching" so for me
> it's one final push after I'm done with all the branches.
>
> > Can you make it even shorter? :)
>
> Yes, you can use what Yonik suggested -- just work on the master
> branch directly and rebase before you commit. For tiny things this
> works just fine.
>
> Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Merge vs Rebase
Posted by Dawid Weiss <da...@gmail.com>.
> I'll admit Dawid that I obviously still have a lot to learn about working
> with Git, but what I wrote above reflects my workflow on another project,
> where we also use Gerrit for doing the code reviews.
I'm not a git expert too, but I've grown to like it for its,
surprisingly, simplicity. If you grasp the idea of a commit being a
"patch with a parent" then everything becomes really logical. Looking
up options and switches to commands in git can be frustrating, but
this is "implementation layer" not "understanding of what's happening"
layer.
> I was referring to our current review style -- I'll upload a patch to JIRA
> and get reviews. Yes, for my own history I could commit as many as I want
> locally, then squash what I want, drop the ones that I don't etc. At the
> moment I'm used to amending the commit, but I know of a coworker of mine who
> works like you propose -- many commits and squashing in the end.
Your workflow is up to you, Shai. I think amending the same commit
over and over is in contrast to what you use a version tracking system
for -- you do *want* those changes layered one on top of another. If
not for anything else, then for just the possibility that you may want
to browse through them and see what you've changed when (I do this a
lot).
> I thought that if I'm in branch 'feature', I cannot do 'git push' since
> there's no remote tracking branch called 'feature'.
This is where git does not excel. A "git push" for one person may be
different than for another person -- this depends... on the
configuration.
The push by default tries to send all the "matching" branches -- the
ones you have locally that are tracking something on the remote end
with the same name. They have been fiddling with the defaults though,
so I'm not sure if this is still the case. Grep for "push.default"
here:
https://git-scm.com/docs/git-config
> So just so I'm clear, the sequence of commands you're proposing is:
>
> git checkout master
> git merge --squash feature
# review patch here
> git push (update origin/master)
>
> git checkout branch_5x
> git cherry-pick master (or the commit hash)
> git push (update origin/branch_5x)
Yes, that's one of my favorites. It consolidates all the "working"
state of a feature into one final diff (patch) which you can review
(see above) before pushing. I have pushes set to "matching" so for me
it's one final push after I'm done with all the branches.
> Can you make it even shorter? :)
Yes, you can use what Yonik suggested -- just work on the master
branch directly and rebase before you commit. For tiny things this
works just fine.
Dawid
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Shai Erera <se...@gmail.com>.
I'll admit Dawid that I obviously still have a lot to learn about working
with Git, but what I wrote above reflects my workflow on another project,
where we also use Gerrit for doing the code reviews.
> How do you get reviews? Did you push feature-branch to origin or did you
just create a patch from it?
I was referring to our current review style -- I'll upload a patch to JIRA
and get reviews. Yes, for my own history I could commit as many as I want
locally, then squash what I want, drop the ones that I don't etc. At the
moment I'm used to amending the commit, but I know of a coworker of mine
who works like you propose -- many commits and squashing in the end. He's
worked w/ Git for years and you obviously have too, so I can only conclude
that your way probably has benefits, which I haven't yet discovered.
> You don't have to rebase anything.
You're right, and I've realized it after I sent it. Again, this is just a
workflow I've developed, where my local master is always up-to-date with
origin, and then I rebase / branch off it instead of origin/master. But I
could also totally rebase my local feature-branch over origin/master.
> git push will push all remote tracking branches (or current branch),
> so you could simply do git push. Shorter.
I thought that if I'm in branch 'feature', I cannot do 'git push' since
there's no remote tracking branch called 'feature'. To just use 'git push',
won't I need to first merge 'feature' into local master and then use 'git
push'? Could be I'm wrong, but I'm almost sure I couldn't just 'git push'
from feature, without specifying that I want HEAD (or feature) to be pushed
to origin/master.
> A less verbose way to do it would be to merge --squash your feature
> into master and then cherry pick a single commit from master to
> branch_5x.
So just so I'm clear, the sequence of commands you're proposing is:
git checkout master
git merge --squash feature
git push (update origin/master)
git checkout branch_5x
git cherry-pick master (or the commit hash)
git push (update origin/branch_5x)
I used cherry-pick in my previous commit, only from a separate local
branch. Reason is I always prefer to keep master (and in this case
branch_5x too) clean, but the (much shorter!) sequence above would work too.
Is this what you meant?
Can you make it even shorter? :)
Shai
On Mon, Jan 25, 2016 at 9:47 PM Shai Erera <se...@gmail.com> wrote:
> 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 <ma...@mikemccandless.com>
> Date: Sun Jan 24 16:51:39 2016 -0500
> merged
>
> commit *5319ca6*11a7dabc07d23a63555ff2df39596d00e
> Author: Michael McCandless <ma...@mikemccandless.com>
> 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 <us...@apache.org>
> 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 <
> lucene@mikemccandless.com> 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 <uw...@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: uwe@thetaphi.de
>> >
>> >
>> >
>> > From: Shai Erera [mailto:serera@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 <da...@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.smiley@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
Re: Merge vs Rebase
Posted by Shai Erera <se...@gmail.com>.
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 <ma...@mikemccandless.com>
Date: Sun Jan 24 16:51:39 2016 -0500
merged
commit *5319ca6*11a7dabc07d23a63555ff2df39596d00e
Author: Michael McCandless <ma...@mikemccandless.com>
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 <us...@apache.org>
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 <
lucene@mikemccandless.com> 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 <uw...@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: uwe@thetaphi.de
> >
> >
> >
> > From: Shai Erera [mailto:serera@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 <da...@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.smiley@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Merge vs Rebase
Posted by Michael McCandless <lu...@mikemccandless.com>.
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 <uw...@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: uwe@thetaphi.de
>
>
>
> From: Shai Erera [mailto:serera@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 <da...@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.smiley@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Mark Miller <ma...@gmail.com>.
On Mon, Jan 25, 2016 at 10:15 AM Dawid Weiss <da...@gmail.com> wrote:
> For example I
> disagree with Mark that multiple merges and then final merge are a bad
> thing in general. They are fairly straightforward in the commit graph
> and they very clearly signify that somebody was working on their own
> stuff and periodically synced up with changes on the master (or any
> other branch).
>
It sounds like you are talking about something else. If you are
legitimately working on a large feature, what you would an svn branch for,
merge commits can make sense. That's not the general case at all. Like I
said, it's about determining when the merge commit adds value and when it
just creates complexity with no extra value.
Other than that, you guys are just too obsessed with 'forbidden'.
We talk about getting on the same page and guidelines, and you guys talk
about 'forbidden' and 'bans'. You are just talking past us.
Do some googling. Pretty much every project faces this and either decides
to create an insane amount of merge commits or not. Both choices are taken,
but the path that is almost never taken is, everyone just does whatever the
hell they want without discussing first.
- Mark
--
- Mark
about.me/markrmiller
Re: Merge vs Rebase
Posted by Joel Bernstein <jo...@gmail.com>.
I'm a non git expert and I would prefer to have guidelines to follow.
Understanding the complexities here is not something I have any interest
in. I just want to merge and commit in some agreed apon standard way.
Joel Bernstein
http://joelsolr.blogspot.com/
On Mon, Jan 25, 2016 at 10:37 AM, Shai Erera <se...@gmail.com> wrote:
> Hi Dawid,
>
> Yes, I know what --amend does. I never amend the parent commit, only my
> initial commit. I think we're talking about the same thing, but just to
> clarify, this is what I mean:
>
> git checkout -b feature-branch
> git commit -a -m "message"
> (Get reviews)
> git commit --amend (addressing review comments)
>
> I do not intend to stack additional commits on top of the initial commit,
> and then in the end squash them or whatever. I treat it all as one piece of
> work and commit, and I don't think our history should reflect every comment
> someone makes on an issue. In analogy, today in JIRA we always update a
> full .patch file, and eventually commit it, irrespective of the number of
> iterations that issue has gone through.
>
> Again, I think we're sync, but wanted to clarify what I meant.
>
> About the guidelines, I'd prefer that we use rebase, but that's not what I
> was after with the guide. Today I've made my first commit to Git (in
> Lucene!), and the way I handled trunk and branch_5x is as follows:
>
> git checkout -b feature master (i.e. trunk)
> (work, commit locally, publish ...)
> (time to push, i.e. SVN commit)
> git fetch origin
> git checkout master && git pull --rebase (this is nearly identical to the
> previous 'svn up')
> git checkout feature && git rebase master
> git push origin HEAD:master (this is the equivalent of svn commit)
>
> ('merge' to branch_5x)
> git checkout branch_5x
> git pull --rebase (pulls from origin/branch_5x)
> git checkout -b feature_5x branch_5x
> git cherry-pick feature (this is partly 'svn merge')
> git push origin HEAD:branch_5x
>
> (a) Is this (one of) the correct way to do it?
> (b) Is there a less verbose way to do it, aside from rebasing feature on
> origin/branch_5x?
>
> So, if we can have such sequence of operations written somewhere, even if
> only as a proposed way to handle it, I think it will make it easy on the
> Git newcomers among committers, since they're going to need to do this a
> lot. And certainly if there's a quicker way to do it!
>
> Shai
>
> On Mon, Jan 25, 2016 at 5:15 PM Dawid Weiss <da...@gmail.com> wrote:
>
>> Hi Shai,
>>
>> > I usually do 'git commit --amend',
>>
>> When do you do this? Note that what the above command does is:
>>
>> 1) it takes the last commit on the current local branch,
>> 2) it takes its parent commit,
>> 3) it applies the diff from the last commit to the parent, permits you
>> to modify the message and commits this new stuff on top of the parent,
>> *resetting* the branch's HEAD reference to this new commit.
>>
>> If you already pushed your unamended commit to the remote then it's
>> too late -- you'd end up with diverged local branch. Again, the
>> simplest way to "see" this would be gitk. I'm sorry if I'm explaining
>> something obvious.
>>
>> > is beneficial. But if I upload a patch, get reviews and intend to
>> upload an
>> > updated patch, I will --amend my commit.
>>
>> I don't see any relation with commits and --amend here. As long as
>> you're working on a branch, this really doesn't matter -- you can just
>> commit your changed stuff after a review and push it to a remote
>> feature branch for others to see (or keep it local if you work on it
>> alone). Amending commit is meant merely to fix a typo in a commit
>> message. Yes, you can play with commits in a serious way (skipping
>> commits, merging them together, changing commit contents, etc.), but
>> this is really beyond the scope of a new git user (for those who are
>> interested -- see what an interactive rebase is -- rebase -i).
>>
>> > 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.
>>
>> Even if it seems right I don't think this is realistic, given that
>> people have their own preferences and (strong) opinions. For example I
>> disagree with Mark that multiple merges and then final merge are a bad
>> thing in general. They are fairly straightforward in the commit graph
>> and they very clearly signify that somebody was working on their own
>> stuff and periodically synced up with changes on the master (or any
>> other branch). Finally, when the feature is ready, a merge to the
>> mainline happens. It's no different to what we used in SVN, actually.
>> This is a classic example of flying fish strategy -- it's been with
>> versioning systems for ages. What I think Mark is worried about is
>> merges across multiple branches, which indeed can quickly become
>> mind-boggling. That's why I suggested that, at first, everyone should
>> stick to simple cherry picks and squashed merges -- not that they're
>> "the best" way to work with git, it's just that they're conceptually
>> simpler to understand for those who start their adventure with
>> distributed revision control systems. I personally use a lot of
>> partial merges and I have no problem with them at all.
>>
>> > 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,
>>
>> I didn't have enough time and I'm on vacation with my family this
>> week. But I agree with Robert here -- these guidelines should make the
>> job easier for people who are new to git, but they should *not*
>> restrict the liberty of how one chooses to work in general. We can
>> make some restrictions with respect to "release" branches -- master,
>> branch_5x, but I don't see the reason of forbidding whatever one
>> desires on private branches. Also, see my example below.
>>
>> >> 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)
>>
>> See the attached picture, it highlights four different ways in which a
>> branch can be reintegrated into the mainline, definitely not
>> exhausting all the possibilities. The difference between them is in:
>>
>> 1) how frequently (and when) you resolve conflicts against the branch
>> you eventually target your work at; I'd argue it's simpler with
>> multiple partial merges during your work on a feature than one final
>> rebase (which needs to resolve conflicts for all commits),
>> 2) whether you want others to see intermediate stages of your work or
>> just the final outcome,
>> 3) how difficult it'll be to reapply the patch to some other branch.
>> 4) if you rebase your feature branch all the commits hashes change. In
>> effect, you can't really work on a single feature branch with others
>> -- you'd be overwriting each other's changes by forcing new commits
>> with push to a common repository.
>>
>> I don't think any of them is better than another, they're just
>> different. I do all of these things depending on the circumstances.
>>
>> > 'svn' does the equivalent of a git rebase when pushing a new commit
>> that isn't otherwise some explicit merge.
>>
>> Hmm.. I think in this case the comparison to SVN is apples to oranges
>> because SVN lacks a lot of the extended scenarios of what git rebasing
>> is used for. In my example, see the fourth strategy -- this is
>> canonical "merge a feature atomically, preserving all intermediate
>> commits" case. It has benefits if you wish to see how the feature
>> evolved, but it still very intuitive (and easy to revert).
>>
>> Dawid
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Merge vs Rebase
Posted by Dawid Weiss <da...@gmail.com>.
> git checkout -b feature-branch
> git commit -a -m "message"
> (Get reviews)
> git commit --amend (addressing review comments)
How do you get reviews? Did you push feature-branch to origin or did
you just create a patch from it? If you did push then it doesn't make
sense to amend. If you didn't push then I still don't see any point in
amending -- you'd just apply any reviews you see fit and squash for
the merge with the mainline. Why bother amending commits that never
make it to the mainline? I see only downsides -- you lose the history
of what you fixed in response to those reviews, for example.
> I do not intend to stack additional commits on top of the initial commit,
> and then in the end squash them or whatever. I treat it all as one piece of
> work and commit, and I don't think our history should reflect every comment
> someone makes on an issue.
Why not? I admit I don't understand. A merge squash at the end of your
work is essentially combining all the intermediate commits into a
single patch -- what's the difference to having one commit amended
multiple times?
> In analogy, today in JIRA we always update a full
> .patch file, and eventually commit it, irrespective of the number of
> iterations that issue has gone through.
Issues very often have a history of patches, not just the most recent one.
> Again, I think we're sync, but wanted to clarify what I meant.
I don't think we are, but at the same time I don't think it matters.
It's what I said -- how you work on your own branches is your thing.
> git checkout master && git pull --rebase (this is nearly identical to the
You don't have to rebase anything. This pull will always succeed and
will fast-forward to the current origin/master, unless you work
directly on your local master branch (which you don't, concluding from
your log of commands).
> git push origin HEAD:master (this is the equivalent of svn commit)
git push will push all remote tracking branches (or current branch),
so you could simply do git push. Shorter.
> (a) Is this (one of) the correct way to do it?
Yes.
> (b) Is there a less verbose way to do it, aside from rebasing feature on
> origin/branch_5x?
You're committing multiple commits on top of master (by rebasing).
Like I mentioned before, this is just one way to do it (in my opinion
it's inferior to no-fast-forward merge in that it obcures which
commits formed a single "feature").
A less verbose way to do it would be to merge --squash your feature
into master and then cherry pick a single commit from master to
branch_5x.
D.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Dennis Gove <dp...@gmail.com>.
+1 for stealing the Hadoop guide wrt commit guidelines. I find their
approach straight forward and I am a fan of attempting to keep a linear
history, as we did in svn.
- Dennis
On Mon, Jan 25, 2016 at 7:50 PM, Erick Erickson <er...@gmail.com>
wrote:
> P.S. with attribution re: the hadoop committer guide.
>
> On Mon, Jan 25, 2016 at 4:49 PM, Erick Erickson <er...@gmail.com>
> wrote:
> > OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> > start and we can refine as necessary.
> >
> > I'll put big banners about "PRELIMINARY" in it, and add bits about
> > this being recommended not required.
> >
> > Thoughts?
> >
> > On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> >> Hi,
> >>
> >>> Another chore we do is on adding new files is
> >>> svn propset svn:eol-style native <file-name>
> >>>
> >>> do we have an equivalent for that in git?
> >>
> >> Per-file properties like eol-style or MIME-type don't exist. Git has
> some set of internal file extensions it treats as text files and does the
> newlines automagically. If we want to configure that, we can commit a
> ".gitconfig" file in root directory of repository:
> https://help.github.com/articles/dealing-with-line-endings/
> >>
> >> I would like to add such a .gitconfig file in any case to do some sane
> defaults.
> >>
> >> The ANT checker in "precommit" now also checks your GIT working copy
> and fails like before, although it no longer looks at mime types or
> eol-style.
> >>
> >> Uwe
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Merge vs Rebase
Posted by Erick Erickson <er...@gmail.com>.
P.S. with attribution re: the hadoop committer guide.
On Mon, Jan 25, 2016 at 4:49 PM, Erick Erickson <er...@gmail.com> wrote:
> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> start and we can refine as necessary.
>
> I'll put big banners about "PRELIMINARY" in it, and add bits about
> this being recommended not required.
>
> Thoughts?
>
> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> Hi,
>>
>>> Another chore we do is on adding new files is
>>> svn propset svn:eol-style native <file-name>
>>>
>>> do we have an equivalent for that in git?
>>
>> Per-file properties like eol-style or MIME-type don't exist. Git has some set of internal file extensions it treats as text files and does the newlines automagically. If we want to configure that, we can commit a ".gitconfig" file in root directory of repository: https://help.github.com/articles/dealing-with-line-endings/
>>
>> I would like to add such a .gitconfig file in any case to do some sane defaults.
>>
>> The ANT checker in "precommit" now also checks your GIT working copy and fails like before, although it no longer looks at mime types or eol-style.
>>
>> Uwe
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Mark Miller <ma...@gmail.com>.
On Tue, Jan 26, 2016 at 12:18 PM Erick Erickson <er...@gmail.com>
wrote:
>
> Well, I'm not advocating at all using all their practices,
>
If Hadoop is too janky a project to look at, perhaps we look at
ElasticSearch, which also rebases and squashes commits to manage sanity:
https://github.com/elastic/elasticsearch/blob/master/CONTRIBUTING.md
- Mark
--
- Mark
about.me/markrmiller
Re: Merge vs Rebase
Posted by Erick Erickson <er...@gmail.com>.
Robert:
Well, I'm not advocating at all using all their practices, just the
guide for how we want to use Git as a place to start our own process.
Or, more accurately, how newbie to Git can use it without "surprises".
David's right, I'm really looking at just the commit patches part.
> The thing I want to model most is the form. It's a clear set of steps I can use to get my feet wet and refine if necessary later. _What_ those steps are open to change.
> I'm getting a little numbed by this endless debate about how to use the shiny new Git thing. Unless we (well, Git pros) want to coach every one of us new-to-Git folks individually, a "how to" guide is indicated. So I'm trying to get something concrete we can then change to suit. As usual, of course, people are more than generous with their time/advice, but why make more work for them?
> Git is just a tool. Right now, the learning curve is just obstructing my getting any "real work" done. We can debate how sparse my code contributions have been recently some other time ;)
> There's nothing coercive about this proposal. If people have a favorite way of making Git stand up and do tricks, I'm not about to ask anyone to change it.
> I have no objections to there being multiple processes outlined in whatever doc we create, just as long as there's a consistent set of steps outlined that I can follow for each workflow without parsing endless "if you want this, then do that" branches.
> The very fact that this conversation has lasted so long is all the proof I need that Git has enough different ways of being used that a "how to" guide is a good thing.
Best,
Erick
On Tue, Jan 26, 2016 at 8:54 AM, Mark Miller <ma...@gmail.com> wrote:
> They say the same thing about our horrid build system and so won't learn
> from our other good practices. What a stupid way to think on both sides.
>
> - Mark
>
> On Tue, Jan 26, 2016 at 11:30 AM, Michael McCandless
> <lu...@mikemccandless.com> wrote:
>>
>> On Tue, Jan 26, 2016 at 10:54 AM, david.w.smiley@gmail.com
>> <da...@gmail.com> wrote:
>> > Rob,
>> > I'll trust your assessment of the technical deficiencies of the Hadoop
>> > codebase as I have no experience to say one way or the other.
>>
>> I will trust Rob's assessment too.
>>
>> > But I'm
>> > confused why this is relevant to wether they have a decent process &
>> > docs on
>> > how to use git?
>>
>> Actually I think the relationship is clear?
>>
>> If XYZ entity creates something scary looking to me, then it's
>> appropriate for me to question XYZ's dev practices/processes. I.e. I
>> would not want to look for inspiration on dev practices from such an
>> XYZ project.
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
>
> --
> - Mark
>
> http://about.me/markrmiller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Mark Miller <ma...@gmail.com>.
They say the same thing about our horrid build system and so won't learn
from our other good practices. What a stupid way to think on both sides.
- Mark
On Tue, Jan 26, 2016 at 11:30 AM, Michael McCandless <
lucene@mikemccandless.com> wrote:
> On Tue, Jan 26, 2016 at 10:54 AM, david.w.smiley@gmail.com
> <da...@gmail.com> wrote:
> > Rob,
> > I'll trust your assessment of the technical deficiencies of the Hadoop
> > codebase as I have no experience to say one way or the other.
>
> I will trust Rob's assessment too.
>
> > But I'm
> > confused why this is relevant to wether they have a decent process &
> docs on
> > how to use git?
>
> Actually I think the relationship is clear?
>
> If XYZ entity creates something scary looking to me, then it's
> appropriate for me to question XYZ's dev practices/processes. I.e. I
> would not want to look for inspiration on dev practices from such an
> XYZ project.
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
--
- Mark
http://about.me/markrmiller
Re: Merge vs Rebase
Posted by Michael McCandless <lu...@mikemccandless.com>.
On Tue, Jan 26, 2016 at 10:54 AM, david.w.smiley@gmail.com
<da...@gmail.com> wrote:
> Rob,
> I'll trust your assessment of the technical deficiencies of the Hadoop
> codebase as I have no experience to say one way or the other.
I will trust Rob's assessment too.
> But I'm
> confused why this is relevant to wether they have a decent process & docs on
> how to use git?
Actually I think the relationship is clear?
If XYZ entity creates something scary looking to me, then it's
appropriate for me to question XYZ's dev practices/processes. I.e. I
would not want to look for inspiration on dev practices from such an
XYZ project.
Mike McCandless
http://blog.mikemccandless.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Jan 26, 2016 at 11:22 AM, Yonik Seeley <ys...@gmail.com> wrote:
> On Tue, Jan 26, 2016 at 10:54 AM, david.w.smiley@gmail.com
> <da...@gmail.com> wrote:
>> My only critique of it is that I sense the git branch.autosetuprebase option
>> (what Yonik is using) might be obsoleted by the pull.rebase option;
Ah, OK... I see from the other thread you meant this:
git config --global pull.rebase true
Didn't know about that. Looks good to me!
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Yonik Seeley <ys...@gmail.com>.
On Tue, Jan 26, 2016 at 10:54 AM, david.w.smiley@gmail.com
<da...@gmail.com> wrote:
> My only critique of it is that I sense the git branch.autosetuprebase option
> (what Yonik is using) might be obsoleted by the pull.rebase option;
Maybe I don't understand what you're saying, but
"git config branch.autosetuprebase always"
just changes the default for new branches.
I think we should recommend this for new git users, since someone will
forget to type the rebase part of "git pull --rebase" and accidentally
get merge commits when they didn't mean to (and it's already happened
;-)
-Yonik
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by "david.w.smiley@gmail.com" <da...@gmail.com>.
Rob,
I'll trust your assessment of the technical deficiencies of the Hadoop
codebase as I have no experience to say one way or the other. But I'm
confused why this is relevant to wether they have a decent process & docs
on how to use git?
For reference I think Erick is referring to this:
https://wiki.apache.org/hadoop/HowToCommit
and perhaps just the "Commit individual patches" section.
FWIW I like the documentation there. Relatively succinct and represents
almost exactly how I plan to work with Lucene/Solr going forward, albeit
through IntelliJ and not at the command-line.
My only critique of it is that I sense the git branch.autosetuprebase
option (what Yonik is using) might be obsoleted by the pull.rebase option;
I like the latter (newer option) better; and it makes no sense to use
both. This is a nitpick though; the result is rebasing on pull.
~ David
On Tue, Jan 26, 2016 at 9:06 AM Robert Muir <rc...@gmail.com> wrote:
> I am entirely serious, but we all know the code quality problems with
> hadoop. Many are the same ones Uwe has already fought here and you can
> already find issues/discussions on them:
>
> * any hadoop maven artifact is "jar hell in a box"
> * hadoop classes do crazy shit, like execute operating system
> processes when classes load.
> * at the same time, hadoop is not really portable (e.g. hdfs just
> fails on windows without native libraries).
>
> furthermore, I have seen a push for a lot of apache projects to follow
> a "typical" hadoop-like development style. You can recognize certain
> features of it like trying to enforce code reviews,
> review-then-commit, etc. It recently caused a big thread on the
> incubator lists. personally, I agree with some of the comments there,
> that making it too hard to get commits in discourages code cleanups
> and things like that (which appear to be desperately needed if you
> actually look at the code)
>
> I also think their approach to backwards compatibility and JVM version
> support plays a big role. If they stopped pretending they could run on
> ancient java versions and just adopted java 7, they would actually be
> *more* portable (e.g. work on windows) and not less. Also use of NIO.2
> instead of trying to execute processes like 'ln -s' for handling files
> is way cleaner.
>
> On Tue, Jan 26, 2016 at 8:03 AM, Erik Hatcher <er...@gmail.com>
> wrote:
> > Robert - not sure if you're serious or not but I'd love to see an
> example of the (lack of?) code quality especially in how the dev practices
> there contributed to it. Pointers?
> >
> > Erik
> >
> >> On Jan 26, 2016, at 06:16, Robert Muir <rc...@gmail.com> wrote:
> >>
> >> I don't think we should follow the hadoop dev practices, just look at
> >> the quality of the code they produce...
> >>
> >>> On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson <
> erickerickson@gmail.com> wrote:
> >>> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> >>> start and we can refine as necessary.
> >>>
> >>> I'll put big banners about "PRELIMINARY" in it, and add bits about
> >>> this being recommended not required.
> >>>
> >>> Thoughts?
> >>>
> >>>> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler <uw...@thetaphi.de>
> wrote:
> >>>> Hi,
> >>>>
> >>>>> Another chore we do is on adding new files is
> >>>>> svn propset svn:eol-style native <file-name>
> >>>>>
> >>>>> do we have an equivalent for that in git?
> >>>>
> >>>> Per-file properties like eol-style or MIME-type don't exist. Git has
> some set of internal file extensions it treats as text files and does the
> newlines automagically. If we want to configure that, we can commit a
> ".gitconfig" file in root directory of repository:
> https://help.github.com/articles/dealing-with-line-endings/
> >>>>
> >>>> I would like to add such a .gitconfig file in any case to do some
> sane defaults.
> >>>>
> >>>> The ANT checker in "precommit" now also checks your GIT working copy
> and fails like before, although it no longer looks at mime types or
> eol-style.
> >>>>
> >>>> Uwe
> >>>>
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com
Re: Merge vs Rebase
Posted by Robert Muir <rc...@gmail.com>.
I am entirely serious, but we all know the code quality problems with
hadoop. Many are the same ones Uwe has already fought here and you can
already find issues/discussions on them:
* any hadoop maven artifact is "jar hell in a box"
* hadoop classes do crazy shit, like execute operating system
processes when classes load.
* at the same time, hadoop is not really portable (e.g. hdfs just
fails on windows without native libraries).
furthermore, I have seen a push for a lot of apache projects to follow
a "typical" hadoop-like development style. You can recognize certain
features of it like trying to enforce code reviews,
review-then-commit, etc. It recently caused a big thread on the
incubator lists. personally, I agree with some of the comments there,
that making it too hard to get commits in discourages code cleanups
and things like that (which appear to be desperately needed if you
actually look at the code)
I also think their approach to backwards compatibility and JVM version
support plays a big role. If they stopped pretending they could run on
ancient java versions and just adopted java 7, they would actually be
*more* portable (e.g. work on windows) and not less. Also use of NIO.2
instead of trying to execute processes like 'ln -s' for handling files
is way cleaner.
On Tue, Jan 26, 2016 at 8:03 AM, Erik Hatcher <er...@gmail.com> wrote:
> Robert - not sure if you're serious or not but I'd love to see an example of the (lack of?) code quality especially in how the dev practices there contributed to it. Pointers?
>
> Erik
>
>> On Jan 26, 2016, at 06:16, Robert Muir <rc...@gmail.com> wrote:
>>
>> I don't think we should follow the hadoop dev practices, just look at
>> the quality of the code they produce...
>>
>>> On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson <er...@gmail.com> wrote:
>>> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
>>> start and we can refine as necessary.
>>>
>>> I'll put big banners about "PRELIMINARY" in it, and add bits about
>>> this being recommended not required.
>>>
>>> Thoughts?
>>>
>>>> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> Hi,
>>>>
>>>>> Another chore we do is on adding new files is
>>>>> svn propset svn:eol-style native <file-name>
>>>>>
>>>>> do we have an equivalent for that in git?
>>>>
>>>> Per-file properties like eol-style or MIME-type don't exist. Git has some set of internal file extensions it treats as text files and does the newlines automagically. If we want to configure that, we can commit a ".gitconfig" file in root directory of repository: https://help.github.com/articles/dealing-with-line-endings/
>>>>
>>>> I would like to add such a .gitconfig file in any case to do some sane defaults.
>>>>
>>>> The ANT checker in "precommit" now also checks your GIT working copy and fails like before, although it no longer looks at mime types or eol-style.
>>>>
>>>> Uwe
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Erik Hatcher <er...@gmail.com>.
Robert - not sure if you're serious or not but I'd love to see an example of the (lack of?) code quality especially in how the dev practices there contributed to it. Pointers?
Erik
> On Jan 26, 2016, at 06:16, Robert Muir <rc...@gmail.com> wrote:
>
> I don't think we should follow the hadoop dev practices, just look at
> the quality of the code they produce...
>
>> On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson <er...@gmail.com> wrote:
>> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
>> start and we can refine as necessary.
>>
>> I'll put big banners about "PRELIMINARY" in it, and add bits about
>> this being recommended not required.
>>
>> Thoughts?
>>
>>> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
>>> Hi,
>>>
>>>> Another chore we do is on adding new files is
>>>> svn propset svn:eol-style native <file-name>
>>>>
>>>> do we have an equivalent for that in git?
>>>
>>> Per-file properties like eol-style or MIME-type don't exist. Git has some set of internal file extensions it treats as text files and does the newlines automagically. If we want to configure that, we can commit a ".gitconfig" file in root directory of repository: https://help.github.com/articles/dealing-with-line-endings/
>>>
>>> I would like to add such a .gitconfig file in any case to do some sane defaults.
>>>
>>> The ANT checker in "precommit" now also checks your GIT working copy and fails like before, although it no longer looks at mime types or eol-style.
>>>
>>> Uwe
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Robert Muir <rc...@gmail.com>.
I don't think we should follow the hadoop dev practices, just look at
the quality of the code they produce...
On Mon, Jan 25, 2016 at 7:49 PM, Erick Erickson <er...@gmail.com> wrote:
> OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
> start and we can refine as necessary.
>
> I'll put big banners about "PRELIMINARY" in it, and add bits about
> this being recommended not required.
>
> Thoughts?
>
> On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
>> Hi,
>>
>>> Another chore we do is on adding new files is
>>> svn propset svn:eol-style native <file-name>
>>>
>>> do we have an equivalent for that in git?
>>
>> Per-file properties like eol-style or MIME-type don't exist. Git has some set of internal file extensions it treats as text files and does the newlines automagically. If we want to configure that, we can commit a ".gitconfig" file in root directory of repository: https://help.github.com/articles/dealing-with-line-endings/
>>
>> I would like to add such a .gitconfig file in any case to do some sane defaults.
>>
>> The ANT checker in "precommit" now also checks your GIT working copy and fails like before, although it no longer looks at mime types or eol-style.
>>
>> Uwe
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Erick Erickson <er...@gmail.com>.
OK, I'm _really tempted_ to just steal the Hadoop guide verbatim as a
start and we can refine as necessary.
I'll put big banners about "PRELIMINARY" in it, and add bits about
this being recommended not required.
Thoughts?
On Mon, Jan 25, 2016 at 4:36 PM, Uwe Schindler <uw...@thetaphi.de> wrote:
> Hi,
>
>> Another chore we do is on adding new files is
>> svn propset svn:eol-style native <file-name>
>>
>> do we have an equivalent for that in git?
>
> Per-file properties like eol-style or MIME-type don't exist. Git has some set of internal file extensions it treats as text files and does the newlines automagically. If we want to configure that, we can commit a ".gitconfig" file in root directory of repository: https://help.github.com/articles/dealing-with-line-endings/
>
> I would like to add such a .gitconfig file in any case to do some sane defaults.
>
> The ANT checker in "precommit" now also checks your GIT working copy and fails like before, although it no longer looks at mime types or eol-style.
>
> Uwe
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Merge vs Rebase
Posted by Uwe Schindler <uw...@thetaphi.de>.
Hi,
> Another chore we do is on adding new files is
> svn propset svn:eol-style native <file-name>
>
> do we have an equivalent for that in git?
Per-file properties like eol-style or MIME-type don't exist. Git has some set of internal file extensions it treats as text files and does the newlines automagically. If we want to configure that, we can commit a ".gitconfig" file in root directory of repository: https://help.github.com/articles/dealing-with-line-endings/
I would like to add such a .gitconfig file in any case to do some sane defaults.
The ANT checker in "precommit" now also checks your GIT working copy and fails like before, although it no longer looks at mime types or eol-style.
Uwe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Mark Miller <ma...@gmail.com>.
Yup, it's committers like you and Joel that I'm most worried about simple
guidelines for. Those that are deep into Git on this project are likely to
do whatever they want anyway. I'm not looking to waste my time fighting
them. But for those that don't want to walk those waters, that don't have a
religious bent about having the history of every patch in SVN and hundreds
of one off branches, let's set up a simple work flow for them that helps
keep things sane.
Mark
On Mon, Jan 25, 2016 at 2:42 PM Erick Erickson <er...@gmail.com>
wrote:
> Gotta echo Joel, I just want to get through my first commit here.
> Yonik's outline is along the lines of what I'm looking for. For
> newcomers (including newcomers to Git like me), this discussion is a
> little analogous to someone asking "how do I write to a file in Java"
> and having the discussion dive into the pros and cons of the zillion
> different things you can do with writing data to some disk somewhere;
> options for binary, text, character set, buffered, flushed, fsync'd,
> and on and on. Each and every one of the options discussed has a very
> good use case, but is hard to absorb all at once.
>
> The "How to Contribute" page needs to be updated; I'll be happy to
> volunteer to create/edit a "Git commit process". I can bring the
> newbie's ignorant perspective to bear on it, doing all the dumb things
> that newbies do. Trust me on this, I can misinterpret even the
> simplest of instructions.
>
> And do note that it's perfectly OK IMO to have multiple ways of doing
> things, so this more along the lines of recommendations than
> requirements. I'm not interested in "the one true way". I _am_
> interested in "how do I keep from messing this up completely".
>
> I'm envisioning a few sections here.
> >Your first Git commit
> >> steps for method 1
> >>> backporting to 5x
> >> steps for method 2
> >>> backporting to 5x
>
> > Advanced issues
> >> advanced issue 1
> >> advanced issue 2
>
> Of course we have to reach some consensus on what acceptable "method
> for newbies" are, which is much of what this discussion is about.
>
> Erick
>
> On Mon, Jan 25, 2016 at 10:07 AM, Shai Erera <se...@gmail.com> wrote:
> > I used cherry-pick, as to me it's the most similar thing to the svn merge
> > workflow we had. But as Mark said, there are other ways too, and IMO we
> > should get to an agreed upon way as a project, and not individuals.
> >
> > For instance, IIRC, branch_5x now has 2 commits: the first is the one
> from
> > master, and the second is named 'merge'. Seeing that in 'svn log', IMO,
> > doesn't contribute to a better understanding of the history.
> >
> > Shai
> >
> >
> > On Mon, Jan 25, 2016, 19:56 Mark Miller <ma...@gmail.com> wrote:
> >>
> >> Although, again, before someone gets angry, some groups choose to merge
> in
> >> this case as well instead. There are lots of legit choices. Projects
> tend to
> >> come to consensus on how they operate with these things. There is no
> >> 'correct' choice, just opinions and what the project coalesces around.
> >>
> >>
> >> - Mark
> >>
> >> On Mon, Jan 25, 2016 at 12:45 PM Mark Miller <ma...@gmail.com>
> >> wrote:
> >>>
> >>> >> The next step is merging to branch_5x
> >>> >> How do you recommend I do it?
> >>>
> >>> Generally, people use 'cherry-pick' for this.
> >>>
> >>> - Mark
> >>>
> >>> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul <no...@gmail.com>
> wrote:
> >>>>
> >>>> The most common usecase is
> >>>> Do development on trunk(master)
> >>>>
> >>>> git commit to master
> >>>> git push
> >>>>
> >>>>
> >>>> The next step is merging to branch_5x
> >>>> How do you recommend I do it?
> >>>>
> >>>> Another chore we do is on adding new files is
> >>>> svn propset svn:eol-style native <file-name>
> >>>>
> >>>> do we have an equivalent for that in git?
> >>>>
> >>>>
> >>>> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley <ys...@gmail.com>
> >>>> wrote:
> >>>> >> git push origin HEAD:master (this is the equivalent of svn commit)
> >>>> >> (b) Is there a less verbose way to do it,
> >>>> >
> >>>> > I'm no git expert either, but it seems like the simplest example of
> >>>> > applying and committing a patch could be much simpler by having good
> >>>> > defaults and not using a separate branch.
> >>>> >
> >>>> > 1) update your repo (note my .gitconfig makes this use rebasing)
> >>>> > $ git pull
> >>>> >
> >>>> > 2) apply patch / changes, run tests, etc
> >>>> >
> >>>> > 3) commit locally
> >>>> > $ git add # add the changed files.. use "git add -u" for adding all
> >>>> > modified files
> >>>> > $ git commit -m "my commit message"
> >>>> >
> >>>> > 4) push to remote
> >>>> > $ git push
> >>>> >
> >>>> > -Yonik
> >>>> >
> >>>> > ------------ my .gitconfig ----------
> >>>> > [user]
> >>>> > name = yonik
> >>>> > email = yonik@apache.org
> >>>> >
> >>>> > [color]
> >>>> > diff = auto
> >>>> > status = auto
> >>>> > branch = auto
> >>>> >
> >>>> > [alias]
> >>>> > br = branch
> >>>> > co = checkout
> >>>> > l = log --pretty=oneline
> >>>> > hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph
> >>>> > --date=short
> >>>> >
> >>>> > [branch]
> >>>> > autosetuprebase = always
> >>>> >
> >>>> > [push]
> >>>> > default = tracking
> >>>> >
> >>>> >
> ---------------------------------------------------------------------
> >>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> > For additional commands, e-mail: dev-help@lucene.apache.org
> >>>> >
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> -----------------------------------------------------
> >>>> Noble Paul
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>> --
> >>> - Mark
> >>> about.me/markrmiller
> >>
> >> --
> >> - Mark
> >> about.me/markrmiller
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
- Mark
about.me/markrmiller
Re: Merge vs Rebase
Posted by Erick Erickson <er...@gmail.com>.
Gotta echo Joel, I just want to get through my first commit here.
Yonik's outline is along the lines of what I'm looking for. For
newcomers (including newcomers to Git like me), this discussion is a
little analogous to someone asking "how do I write to a file in Java"
and having the discussion dive into the pros and cons of the zillion
different things you can do with writing data to some disk somewhere;
options for binary, text, character set, buffered, flushed, fsync'd,
and on and on. Each and every one of the options discussed has a very
good use case, but is hard to absorb all at once.
The "How to Contribute" page needs to be updated; I'll be happy to
volunteer to create/edit a "Git commit process". I can bring the
newbie's ignorant perspective to bear on it, doing all the dumb things
that newbies do. Trust me on this, I can misinterpret even the
simplest of instructions.
And do note that it's perfectly OK IMO to have multiple ways of doing
things, so this more along the lines of recommendations than
requirements. I'm not interested in "the one true way". I _am_
interested in "how do I keep from messing this up completely".
I'm envisioning a few sections here.
>Your first Git commit
>> steps for method 1
>>> backporting to 5x
>> steps for method 2
>>> backporting to 5x
> Advanced issues
>> advanced issue 1
>> advanced issue 2
Of course we have to reach some consensus on what acceptable "method
for newbies" are, which is much of what this discussion is about.
Erick
On Mon, Jan 25, 2016 at 10:07 AM, Shai Erera <se...@gmail.com> wrote:
> I used cherry-pick, as to me it's the most similar thing to the svn merge
> workflow we had. But as Mark said, there are other ways too, and IMO we
> should get to an agreed upon way as a project, and not individuals.
>
> For instance, IIRC, branch_5x now has 2 commits: the first is the one from
> master, and the second is named 'merge'. Seeing that in 'svn log', IMO,
> doesn't contribute to a better understanding of the history.
>
> Shai
>
>
> On Mon, Jan 25, 2016, 19:56 Mark Miller <ma...@gmail.com> wrote:
>>
>> Although, again, before someone gets angry, some groups choose to merge in
>> this case as well instead. There are lots of legit choices. Projects tend to
>> come to consensus on how they operate with these things. There is no
>> 'correct' choice, just opinions and what the project coalesces around.
>>
>>
>> - Mark
>>
>> On Mon, Jan 25, 2016 at 12:45 PM Mark Miller <ma...@gmail.com>
>> wrote:
>>>
>>> >> The next step is merging to branch_5x
>>> >> How do you recommend I do it?
>>>
>>> Generally, people use 'cherry-pick' for this.
>>>
>>> - Mark
>>>
>>> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul <no...@gmail.com> wrote:
>>>>
>>>> The most common usecase is
>>>> Do development on trunk(master)
>>>>
>>>> git commit to master
>>>> git push
>>>>
>>>>
>>>> The next step is merging to branch_5x
>>>> How do you recommend I do it?
>>>>
>>>> Another chore we do is on adding new files is
>>>> svn propset svn:eol-style native <file-name>
>>>>
>>>> do we have an equivalent for that in git?
>>>>
>>>>
>>>> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley <ys...@gmail.com>
>>>> wrote:
>>>> >> git push origin HEAD:master (this is the equivalent of svn commit)
>>>> >> (b) Is there a less verbose way to do it,
>>>> >
>>>> > I'm no git expert either, but it seems like the simplest example of
>>>> > applying and committing a patch could be much simpler by having good
>>>> > defaults and not using a separate branch.
>>>> >
>>>> > 1) update your repo (note my .gitconfig makes this use rebasing)
>>>> > $ git pull
>>>> >
>>>> > 2) apply patch / changes, run tests, etc
>>>> >
>>>> > 3) commit locally
>>>> > $ git add # add the changed files.. use "git add -u" for adding all
>>>> > modified files
>>>> > $ git commit -m "my commit message"
>>>> >
>>>> > 4) push to remote
>>>> > $ git push
>>>> >
>>>> > -Yonik
>>>> >
>>>> > ------------ my .gitconfig ----------
>>>> > [user]
>>>> > name = yonik
>>>> > email = yonik@apache.org
>>>> >
>>>> > [color]
>>>> > diff = auto
>>>> > status = auto
>>>> > branch = auto
>>>> >
>>>> > [alias]
>>>> > br = branch
>>>> > co = checkout
>>>> > l = log --pretty=oneline
>>>> > hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph
>>>> > --date=short
>>>> >
>>>> > [branch]
>>>> > autosetuprebase = always
>>>> >
>>>> > [push]
>>>> > default = tracking
>>>> >
>>>> > ---------------------------------------------------------------------
>>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> -----------------------------------------------------
>>>> Noble Paul
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>>
>> --
>> - Mark
>> about.me/markrmiller
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Shai Erera <se...@gmail.com>.
I used cherry-pick, as to me it's the most similar thing to the svn merge
workflow we had. But as Mark said, there are other ways too, and IMO we
should get to an agreed upon way as a project, and not individuals.
For instance, IIRC, branch_5x now has 2 commits: the first is the one from
master, and the second is named 'merge'. Seeing that in 'svn log', IMO,
doesn't contribute to a better understanding of the history.
Shai
On Mon, Jan 25, 2016, 19:56 Mark Miller <ma...@gmail.com> wrote:
> Although, again, before someone gets angry, some groups choose to merge in
> this case as well instead. There are lots of legit choices. Projects tend
> to come to consensus on how they operate with these things. There is no
> 'correct' choice, just opinions and what the project coalesces around.
>
>
> - Mark
>
> On Mon, Jan 25, 2016 at 12:45 PM Mark Miller <ma...@gmail.com>
> wrote:
>
>> >> The next step is merging to branch_5x
>> >> How do you recommend I do it?
>>
>> Generally, people use 'cherry-pick' for this.
>>
>> - Mark
>>
>> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul <no...@gmail.com> wrote:
>>
>>> The most common usecase is
>>> Do development on trunk(master)
>>>
>>> git commit to master
>>> git push
>>>
>>>
>>> The next step is merging to branch_5x
>>> How do you recommend I do it?
>>>
>>> Another chore we do is on adding new files is
>>> svn propset svn:eol-style native <file-name>
>>>
>>> do we have an equivalent for that in git?
>>>
>>>
>>> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley <ys...@gmail.com>
>>> wrote:
>>> >> git push origin HEAD:master (this is the equivalent of svn commit)
>>> >> (b) Is there a less verbose way to do it,
>>> >
>>> > I'm no git expert either, but it seems like the simplest example of
>>> > applying and committing a patch could be much simpler by having good
>>> > defaults and not using a separate branch.
>>> >
>>> > 1) update your repo (note my .gitconfig makes this use rebasing)
>>> > $ git pull
>>> >
>>> > 2) apply patch / changes, run tests, etc
>>> >
>>> > 3) commit locally
>>> > $ git add # add the changed files.. use "git add -u" for adding all
>>> > modified files
>>> > $ git commit -m "my commit message"
>>> >
>>> > 4) push to remote
>>> > $ git push
>>> >
>>> > -Yonik
>>> >
>>> > ------------ my .gitconfig ----------
>>> > [user]
>>> > name = yonik
>>> > email = yonik@apache.org
>>> >
>>> > [color]
>>> > diff = auto
>>> > status = auto
>>> > branch = auto
>>> >
>>> > [alias]
>>> > br = branch
>>> > co = checkout
>>> > l = log --pretty=oneline
>>> > hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph
>>> --date=short
>>> >
>>> > [branch]
>>> > autosetuprebase = always
>>> >
>>> > [push]
>>> > default = tracking
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >
>>>
>>>
>>>
>>> --
>>> -----------------------------------------------------
>>> Noble Paul
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> --
>> - Mark
>> about.me/markrmiller
>>
> --
> - Mark
> about.me/markrmiller
>
Re: Merge vs Rebase
Posted by Mark Miller <ma...@gmail.com>.
Although, again, before someone gets angry, some groups choose to merge in
this case as well instead. There are lots of legit choices. Projects tend
to come to consensus on how they operate with these things. There is no
'correct' choice, just opinions and what the project coalesces around.
- Mark
On Mon, Jan 25, 2016 at 12:45 PM Mark Miller <ma...@gmail.com> wrote:
> >> The next step is merging to branch_5x
> >> How do you recommend I do it?
>
> Generally, people use 'cherry-pick' for this.
>
> - Mark
>
> On Mon, Jan 25, 2016 at 12:39 PM Noble Paul <no...@gmail.com> wrote:
>
>> The most common usecase is
>> Do development on trunk(master)
>>
>> git commit to master
>> git push
>>
>>
>> The next step is merging to branch_5x
>> How do you recommend I do it?
>>
>> Another chore we do is on adding new files is
>> svn propset svn:eol-style native <file-name>
>>
>> do we have an equivalent for that in git?
>>
>>
>> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley <ys...@gmail.com> wrote:
>> >> git push origin HEAD:master (this is the equivalent of svn commit)
>> >> (b) Is there a less verbose way to do it,
>> >
>> > I'm no git expert either, but it seems like the simplest example of
>> > applying and committing a patch could be much simpler by having good
>> > defaults and not using a separate branch.
>> >
>> > 1) update your repo (note my .gitconfig makes this use rebasing)
>> > $ git pull
>> >
>> > 2) apply patch / changes, run tests, etc
>> >
>> > 3) commit locally
>> > $ git add # add the changed files.. use "git add -u" for adding all
>> > modified files
>> > $ git commit -m "my commit message"
>> >
>> > 4) push to remote
>> > $ git push
>> >
>> > -Yonik
>> >
>> > ------------ my .gitconfig ----------
>> > [user]
>> > name = yonik
>> > email = yonik@apache.org
>> >
>> > [color]
>> > diff = auto
>> > status = auto
>> > branch = auto
>> >
>> > [alias]
>> > br = branch
>> > co = checkout
>> > l = log --pretty=oneline
>> > hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph
>> --date=short
>> >
>> > [branch]
>> > autosetuprebase = always
>> >
>> > [push]
>> > default = tracking
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>>
>>
>> --
>> -----------------------------------------------------
>> Noble Paul
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> --
> - Mark
> about.me/markrmiller
>
--
- Mark
about.me/markrmiller
Re: Merge vs Rebase
Posted by Mark Miller <ma...@gmail.com>.
>> The next step is merging to branch_5x
>> How do you recommend I do it?
Generally, people use 'cherry-pick' for this.
- Mark
On Mon, Jan 25, 2016 at 12:39 PM Noble Paul <no...@gmail.com> wrote:
> The most common usecase is
> Do development on trunk(master)
>
> git commit to master
> git push
>
>
> The next step is merging to branch_5x
> How do you recommend I do it?
>
> Another chore we do is on adding new files is
> svn propset svn:eol-style native <file-name>
>
> do we have an equivalent for that in git?
>
>
> On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley <ys...@gmail.com> wrote:
> >> git push origin HEAD:master (this is the equivalent of svn commit)
> >> (b) Is there a less verbose way to do it,
> >
> > I'm no git expert either, but it seems like the simplest example of
> > applying and committing a patch could be much simpler by having good
> > defaults and not using a separate branch.
> >
> > 1) update your repo (note my .gitconfig makes this use rebasing)
> > $ git pull
> >
> > 2) apply patch / changes, run tests, etc
> >
> > 3) commit locally
> > $ git add # add the changed files.. use "git add -u" for adding all
> > modified files
> > $ git commit -m "my commit message"
> >
> > 4) push to remote
> > $ git push
> >
> > -Yonik
> >
> > ------------ my .gitconfig ----------
> > [user]
> > name = yonik
> > email = yonik@apache.org
> >
> > [color]
> > diff = auto
> > status = auto
> > branch = auto
> >
> > [alias]
> > br = branch
> > co = checkout
> > l = log --pretty=oneline
> > hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
> >
> > [branch]
> > autosetuprebase = always
> >
> > [push]
> > default = tracking
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
- Mark
about.me/markrmiller
Re: Merge vs Rebase
Posted by Noble Paul <no...@gmail.com>.
The most common usecase is
Do development on trunk(master)
git commit to master
git push
The next step is merging to branch_5x
How do you recommend I do it?
Another chore we do is on adding new files is
svn propset svn:eol-style native <file-name>
do we have an equivalent for that in git?
On Mon, Jan 25, 2016 at 10:20 PM, Yonik Seeley <ys...@gmail.com> wrote:
>> git push origin HEAD:master (this is the equivalent of svn commit)
>> (b) Is there a less verbose way to do it,
>
> I'm no git expert either, but it seems like the simplest example of
> applying and committing a patch could be much simpler by having good
> defaults and not using a separate branch.
>
> 1) update your repo (note my .gitconfig makes this use rebasing)
> $ git pull
>
> 2) apply patch / changes, run tests, etc
>
> 3) commit locally
> $ git add # add the changed files.. use "git add -u" for adding all
> modified files
> $ git commit -m "my commit message"
>
> 4) push to remote
> $ git push
>
> -Yonik
>
> ------------ my .gitconfig ----------
> [user]
> name = yonik
> email = yonik@apache.org
>
> [color]
> diff = auto
> status = auto
> branch = auto
>
> [alias]
> br = branch
> co = checkout
> l = log --pretty=oneline
> hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
>
> [branch]
> autosetuprebase = always
>
> [push]
> default = tracking
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
--
-----------------------------------------------------
Noble Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Yonik Seeley <ys...@gmail.com>.
> git push origin HEAD:master (this is the equivalent of svn commit)
> (b) Is there a less verbose way to do it,
I'm no git expert either, but it seems like the simplest example of
applying and committing a patch could be much simpler by having good
defaults and not using a separate branch.
1) update your repo (note my .gitconfig makes this use rebasing)
$ git pull
2) apply patch / changes, run tests, etc
3) commit locally
$ git add # add the changed files.. use "git add -u" for adding all
modified files
$ git commit -m "my commit message"
4) push to remote
$ git push
-Yonik
------------ my .gitconfig ----------
[user]
name = yonik
email = yonik@apache.org
[color]
diff = auto
status = auto
branch = auto
[alias]
br = branch
co = checkout
l = log --pretty=oneline
hist = log --pretty=format:\"%h %ad | %s%d [%an]\" --graph --date=short
[branch]
autosetuprebase = always
[push]
default = tracking
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Shai Erera <se...@gmail.com>.
Hi Dawid,
Yes, I know what --amend does. I never amend the parent commit, only my
initial commit. I think we're talking about the same thing, but just to
clarify, this is what I mean:
git checkout -b feature-branch
git commit -a -m "message"
(Get reviews)
git commit --amend (addressing review comments)
I do not intend to stack additional commits on top of the initial commit,
and then in the end squash them or whatever. I treat it all as one piece of
work and commit, and I don't think our history should reflect every comment
someone makes on an issue. In analogy, today in JIRA we always update a
full .patch file, and eventually commit it, irrespective of the number of
iterations that issue has gone through.
Again, I think we're sync, but wanted to clarify what I meant.
About the guidelines, I'd prefer that we use rebase, but that's not what I
was after with the guide. Today I've made my first commit to Git (in
Lucene!), and the way I handled trunk and branch_5x is as follows:
git checkout -b feature master (i.e. trunk)
(work, commit locally, publish ...)
(time to push, i.e. SVN commit)
git fetch origin
git checkout master && git pull --rebase (this is nearly identical to the
previous 'svn up')
git checkout feature && git rebase master
git push origin HEAD:master (this is the equivalent of svn commit)
('merge' to branch_5x)
git checkout branch_5x
git pull --rebase (pulls from origin/branch_5x)
git checkout -b feature_5x branch_5x
git cherry-pick feature (this is partly 'svn merge')
git push origin HEAD:branch_5x
(a) Is this (one of) the correct way to do it?
(b) Is there a less verbose way to do it, aside from rebasing feature on
origin/branch_5x?
So, if we can have such sequence of operations written somewhere, even if
only as a proposed way to handle it, I think it will make it easy on the
Git newcomers among committers, since they're going to need to do this a
lot. And certainly if there's a quicker way to do it!
Shai
On Mon, Jan 25, 2016 at 5:15 PM Dawid Weiss <da...@gmail.com> wrote:
> Hi Shai,
>
> > I usually do 'git commit --amend',
>
> When do you do this? Note that what the above command does is:
>
> 1) it takes the last commit on the current local branch,
> 2) it takes its parent commit,
> 3) it applies the diff from the last commit to the parent, permits you
> to modify the message and commits this new stuff on top of the parent,
> *resetting* the branch's HEAD reference to this new commit.
>
> If you already pushed your unamended commit to the remote then it's
> too late -- you'd end up with diverged local branch. Again, the
> simplest way to "see" this would be gitk. I'm sorry if I'm explaining
> something obvious.
>
> > is beneficial. But if I upload a patch, get reviews and intend to upload
> an
> > updated patch, I will --amend my commit.
>
> I don't see any relation with commits and --amend here. As long as
> you're working on a branch, this really doesn't matter -- you can just
> commit your changed stuff after a review and push it to a remote
> feature branch for others to see (or keep it local if you work on it
> alone). Amending commit is meant merely to fix a typo in a commit
> message. Yes, you can play with commits in a serious way (skipping
> commits, merging them together, changing commit contents, etc.), but
> this is really beyond the scope of a new git user (for those who are
> interested -- see what an interactive rebase is -- rebase -i).
>
> > 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.
>
> Even if it seems right I don't think this is realistic, given that
> people have their own preferences and (strong) opinions. For example I
> disagree with Mark that multiple merges and then final merge are a bad
> thing in general. They are fairly straightforward in the commit graph
> and they very clearly signify that somebody was working on their own
> stuff and periodically synced up with changes on the master (or any
> other branch). Finally, when the feature is ready, a merge to the
> mainline happens. It's no different to what we used in SVN, actually.
> This is a classic example of flying fish strategy -- it's been with
> versioning systems for ages. What I think Mark is worried about is
> merges across multiple branches, which indeed can quickly become
> mind-boggling. That's why I suggested that, at first, everyone should
> stick to simple cherry picks and squashed merges -- not that they're
> "the best" way to work with git, it's just that they're conceptually
> simpler to understand for those who start their adventure with
> distributed revision control systems. I personally use a lot of
> partial merges and I have no problem with them at all.
>
> > 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,
>
> I didn't have enough time and I'm on vacation with my family this
> week. But I agree with Robert here -- these guidelines should make the
> job easier for people who are new to git, but they should *not*
> restrict the liberty of how one chooses to work in general. We can
> make some restrictions with respect to "release" branches -- master,
> branch_5x, but I don't see the reason of forbidding whatever one
> desires on private branches. Also, see my example below.
>
> >> 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)
>
> See the attached picture, it highlights four different ways in which a
> branch can be reintegrated into the mainline, definitely not
> exhausting all the possibilities. The difference between them is in:
>
> 1) how frequently (and when) you resolve conflicts against the branch
> you eventually target your work at; I'd argue it's simpler with
> multiple partial merges during your work on a feature than one final
> rebase (which needs to resolve conflicts for all commits),
> 2) whether you want others to see intermediate stages of your work or
> just the final outcome,
> 3) how difficult it'll be to reapply the patch to some other branch.
> 4) if you rebase your feature branch all the commits hashes change. In
> effect, you can't really work on a single feature branch with others
> -- you'd be overwriting each other's changes by forcing new commits
> with push to a common repository.
>
> I don't think any of them is better than another, they're just
> different. I do all of these things depending on the circumstances.
>
> > 'svn' does the equivalent of a git rebase when pushing a new commit that
> isn't otherwise some explicit merge.
>
> Hmm.. I think in this case the comparison to SVN is apples to oranges
> because SVN lacks a lot of the extended scenarios of what git rebasing
> is used for. In my example, see the fourth strategy -- this is
> canonical "merge a feature atomically, preserving all intermediate
> commits" case. It has benefits if you wish to see how the feature
> evolved, but it still very intuitive (and easy to revert).
>
> Dawid
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
Re: Merge vs Rebase
Posted by Dawid Weiss <da...@gmail.com>.
Hi Shai,
> I usually do 'git commit --amend',
When do you do this? Note that what the above command does is:
1) it takes the last commit on the current local branch,
2) it takes its parent commit,
3) it applies the diff from the last commit to the parent, permits you
to modify the message and commits this new stuff on top of the parent,
*resetting* the branch's HEAD reference to this new commit.
If you already pushed your unamended commit to the remote then it's
too late -- you'd end up with diverged local branch. Again, the
simplest way to "see" this would be gitk. I'm sorry if I'm explaining
something obvious.
> is beneficial. But if I upload a patch, get reviews and intend to upload an
> updated patch, I will --amend my commit.
I don't see any relation with commits and --amend here. As long as
you're working on a branch, this really doesn't matter -- you can just
commit your changed stuff after a review and push it to a remote
feature branch for others to see (or keep it local if you work on it
alone). Amending commit is meant merely to fix a typo in a commit
message. Yes, you can play with commits in a serious way (skipping
commits, merging them together, changing commit contents, etc.), but
this is really beyond the scope of a new git user (for those who are
interested -- see what an interactive rebase is -- rebase -i).
> 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.
Even if it seems right I don't think this is realistic, given that
people have their own preferences and (strong) opinions. For example I
disagree with Mark that multiple merges and then final merge are a bad
thing in general. They are fairly straightforward in the commit graph
and they very clearly signify that somebody was working on their own
stuff and periodically synced up with changes on the master (or any
other branch). Finally, when the feature is ready, a merge to the
mainline happens. It's no different to what we used in SVN, actually.
This is a classic example of flying fish strategy -- it's been with
versioning systems for ages. What I think Mark is worried about is
merges across multiple branches, which indeed can quickly become
mind-boggling. That's why I suggested that, at first, everyone should
stick to simple cherry picks and squashed merges -- not that they're
"the best" way to work with git, it's just that they're conceptually
simpler to understand for those who start their adventure with
distributed revision control systems. I personally use a lot of
partial merges and I have no problem with them at all.
> 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,
I didn't have enough time and I'm on vacation with my family this
week. But I agree with Robert here -- these guidelines should make the
job easier for people who are new to git, but they should *not*
restrict the liberty of how one chooses to work in general. We can
make some restrictions with respect to "release" branches -- master,
branch_5x, but I don't see the reason of forbidding whatever one
desires on private branches. Also, see my example below.
>> 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)
See the attached picture, it highlights four different ways in which a
branch can be reintegrated into the mainline, definitely not
exhausting all the possibilities. The difference between them is in:
1) how frequently (and when) you resolve conflicts against the branch
you eventually target your work at; I'd argue it's simpler with
multiple partial merges during your work on a feature than one final
rebase (which needs to resolve conflicts for all commits),
2) whether you want others to see intermediate stages of your work or
just the final outcome,
3) how difficult it'll be to reapply the patch to some other branch.
4) if you rebase your feature branch all the commits hashes change. In
effect, you can't really work on a single feature branch with others
-- you'd be overwriting each other's changes by forcing new commits
with push to a common repository.
I don't think any of them is better than another, they're just
different. I do all of these things depending on the circumstances.
> 'svn' does the equivalent of a git rebase when pushing a new commit that isn't otherwise some explicit merge.
Hmm.. I think in this case the comparison to SVN is apples to oranges
because SVN lacks a lot of the extended scenarios of what git rebasing
is used for. In my example, see the fourth strategy -- this is
canonical "merge a feature atomically, preserving all intermediate
commits" case. It has benefits if you wish to see how the feature
evolved, but it still very intuitive (and easy to revert).
Dawid
Re: Merge vs Rebase
Posted by "david.w.smiley@gmail.com" <da...@gmail.com>.
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 <ma...@gmail.com> 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 <se...@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 <da...@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 <uw...@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: uwe@thetaphi.de
>>> >
>>> >
>>> >
>>> > From: Shai Erera [mailto:serera@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.smiley@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.smiley@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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> --
> - Mark
> about.me/markrmiller
>
--
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com
Re: Merge vs Rebase
Posted by Mark Miller <ma...@gmail.com>.
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 <se...@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 <da...@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 <uw...@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: uwe@thetaphi.de
>> >
>> >
>> >
>> > From: Shai Erera [mailto:serera@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 <da...@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.smiley@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> --
- Mark
about.me/markrmiller
Re: Merge vs Rebase
Posted by Shai Erera <se...@gmail.com>.
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 <da...@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 <uw...@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: uwe@thetaphi.de
> >
> >
> >
> > From: Shai Erera [mailto:serera@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 <da...@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.smiley@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
Re: Merge vs Rebase
Posted by Dawid Weiss <da...@gmail.com>.
> [...] 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 <uw...@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: uwe@thetaphi.de
>
>
>
> From: Shai Erera [mailto:serera@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 <da...@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.smiley@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
RE: Merge vs Rebase
Posted by Uwe Schindler <uw...@thetaphi.de>.
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/> http://www.thetaphi.de
eMail: uwe@thetaphi.de
From: Shai Erera [mailto:serera@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.smiley@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <http://www.solrenterprisesearchserver.com/>
Re: Merge vs Rebase
Posted by Shai Erera <se...@gmail.com>.
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 <da...@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.smiley@gmail.com wrote:
>
> [image: lucene-merge-commit-pic.png]
>
> 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
>
>
>
Re: Merge vs Rebase
Posted by David Smiley <da...@gmail.com>.
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.smiley@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 <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>