I usually do 'git commit --amend', but I agree Dawid, especially in those
JIRA issues which are logically sub-divided into multiple sub-tasks, with
ISSUE-1.patch, ISSUE-2.patch.. that keeping all the commits in the history
is beneficial. But if I upload a patch, get reviews and intend to upload an
updated patch, I will --amend my commit.
I also agree w/ Uwe, I think it will really help if we have a
guidelines/cheatsheet that document how do we expect dev to happen in the
Git world. What you (Dawid) put on Github is great for Git newcomers, but
as a community I think that having rough standards and guidelines will
help, especially the newcomers who may make work one way just because they
read about it somewhere. The merge/rebase and especially between master and
branch_5x are a good starting point to alleviate confusion and setting
expectations / proposing a workflow.
> git merge origin/master # merge any changes from remote master,
I would do a rebase here. Is there a reason you pick merge in the example -
i.e. do u think it's the preferred way, or was it just an example? (asking
for educational reasons)
Shai
On Mon, Jan 25, 2016 at 10:48 AM Dawid Weiss <dawid.we...@gmail.com> wrote:
> > [...] merge C1 and C2, and C2 is a parent of C1, Git doesn't do a merge
> commit. Someone probably can confirm that.
>
> No, there is freedom in how you do it. You can do a fast-forward merge
> or a regular merge, which will show even a single commit which would
> otherwise be linear as a diversion from history.
>
> There is no way to "script rebase" since rebases can cause conflicts
> and these need to be resolved. If you wish to avoid these "bubbles"
> then I'd suggest to:
>
> 1) *never* work on any remote-tracking branch directly, branch your
> feature branch and work on that, merging from remote branch until
> you're ready to commit.
>
> git fetch origin
> git checkout master -b myfeature
> while (!done) {
> ... work on myfeature, committing to myfeature
> git fetch origin
> git merge origin/master # merge any changes from remote master,
> resolving conflicts
> }
>
> # when done, either rebase myfeature on top of origin/master and do a
> fast-forward commit (preserves history of all intermediate commits) or
> squash the entire feature into a single commit.
>
> git checkout master
> git pull # this will never conflict or rebase anything since you
> never had any own changes on master
> git merge --squash myfeature
> git commit -m "myfeature"
>
> By the way -- having those "bubbles" in history can be perceived as
> beneficial if you merge features that have multiple commits because
> then you "see" all the intermediate commits and you can revert the
> entire feature in one step (as opposed to multiple fast-forward
> commits).
>
> Dawid
>
>
>
> Dawid
>
>
> On Mon, Jan 25, 2016 at 9:34 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> > Hi,
> >
> >
> >
> > I am fine with both. The example of the conflict between my commit and
> > Mike’s is just a “normal usecase”. To me it looks correct how it is
> shown in
> > history. At least it shows reality: 2 people were about to commit the
> same.
> > This happened with SVN many times, too, but you are right it was solved
> by
> > SVN through additional update (a rebase) and then try commit again. I am
> > fine with both variants. But if we decide to only do one variant, I’d
> prefer
> > to have some “howto chart” what you need to do to setup your working copy
> > correctly (all commands for configuring @apache.org username, pull
> > settings,…) that are local to the repository. Maybe add a
> shell/windows.cmd
> > script to devtools! I don’t want to change those settings globaly, so
> please
> > don’t use the magic –global setting in the example.If we have a script,
> we
> > can do that per WC:
> >
> > - Fetch repo from git-wip-us
> >
> > - Run script
> >
> >
> >
> > About merge: When we get pull requests from 3rd parties, we should
> > definitely not rebase!!!! With merging that in (in the same way how
> Githiub
> > is doing it), we preserve attribution to the original commiter. We should
> > really keep that! That is to me the only good reason to use Git!
> >
> >
> >
> > I am fine with rebasing our own stuff and make it a slight as possible,
> but
> > for stuff from 3rd party people, we should really preserve what they
> did! So
> > I will always use the command in the github pull request mail and apply
> that
> > to my working copy and push.
> >
> >
> >
> > Uwe
> >
> >
> >
> > -----
> >
> > Uwe Schindler
> >
> > H.-H.-Meier-Allee 63, D-28213 Bremen
> >
> > http://www.thetaphi.de
> >
> > eMail: u...@thetaphi.de
> >
> >
> >
> > From: Shai Erera [mailto:ser...@gmail.com]
> > Sent: Monday, January 25, 2016 8:50 AM
> > To: dev@lucene.apache.org
> > Subject: Re: Merge vs Rebase
> >
> >
> >
> > I agree David. I'm sure there are valid use cases for merging commits,
> but I
> > always prefer rebasing. This has been our way with Apache SVN anyway, so
> why
> > change it? I fell like merging only adds unnecessary lines to 'git log',
> > where you see "Merge commits (1, 7)" but this doesn't add much
> information
> > to whoever looks at it.
> >
> > What does it matter if this merge commit is from previous master and
> > feature-commit? Why do we need one additional commit per change?
> >
> > I'm not a Git expert, but I know (think...) that if you merge C1 and C2,
> and
> > C2 is a parent of C1, Git doesn't do a merge commit. Someone probably can
> > confirm that.
> >
> > FWIW, I plan to continue working the 'SVN' way by doing the following:
> >
> > git checkout master
> >
> > git pull --rebase (update to latest commit/rev)
> >
> > git checkout -b feature
> >
> > git commit -a -m "feature message"
> >
> > git commit --amend (applying review feedback)
> >
> > git fetch origin master:master (a'la 'svn up' we used to do)
> > git rebase master (now my feature commit is right on top of master's
> latest
> > commit / rev)
> >
> > git push origin HEAD:master
> >
> > This will preserve the history linear and flat, which is what we
> currently
> > have w/ SVN.
> >
> >
> >
> > As for merging this commit now to branch_5x. I'll admit I don't have
> > experience working with Git w/ multiple active (feature) branches, so I'm
> > not sure if rebasing branch_5x on my commit is what we want (cause it
> will
> > drag with it all of trunk's history, as far as I understand). I might
> try to
> > cheerrypick that commit only and apply to branch_5x, which is, again -
> AFAIU
> > - what we used to do in SVN.
> >
> > However, as I said, I'm not a Git expert, so if anyone thinks I should
> adopt
> > a different workflow, especially for the branch_5x changes, I'd be happy
> to
> > learn.
> >
> > Shai
> >
> >
> >
> > On Mon, Jan 25, 2016 at 8:13 AM David Smiley <david.w.smi...@gmail.com>
> > wrote:
> >
> > I suspect my picture didn’t make it so I’m trying again:
> >
> >
> >
> > Or if that didn’t work, I put it on dropbox:
> >
> >
> https://www.dropbox.com/s/p3q9ycxytxfqssz/lucene-merge-commit-pic.png?dl=0
> >
> >
> >
> > ~ David
> >
> >
> >
> > On Jan 25, 2016, at 1:07 AM, david.w.smi...@gmail.com wrote:
> >
> >
> >
> >
> >
> > Just to put a little picture to this, I noticed the following: (see
> > attached pic)
> >
> > I suspect it was the bi-product of using a merge based pull (I think the
> > default?) instead of a rebase one, and as a result we have this little
> loop
> > in the log. No doubt there is a place for merge commits (e.g. merging
> one
> > feature branch and another); but is there an advocate willing to tell us
> the
> > virtues that in this instance (not all instances but this one), it's a
> good
> > thing? i.e. is there some insight this loop shows that that I should
> value
> > more than a direct simple lineage?
> >
> >
> >
> > FWIW I prefer to rebase my commits to prevent these little merge bubbles.
> > It happens automatically with this setting:
> >
> > git config --global pull.rebase true
> >
> > Alternatively it could be done without the --global flag. I would most
> > appreciate it if other committers used this same setting, and I think
> we'd
> > all mutually appreciate it as well with cleaner git histories.
> >
> >
> > ~ David
> >
> > --
> >
> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
