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 <[email protected]> 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 <[email protected]> > Date: Sun Jan 24 16:51:39 2016 -0500 > merged > > commit *5319ca6*11a7dabc07d23a63555ff2df39596d00e > Author: Michael McCandless <[email protected]> > 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 <[email protected]> > 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 < > [email protected]> 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 <[email protected]> wrote: >> > Hi, >> > >> > >> > >> > I am fine with both. The example of the conflict between my commit and >> > Mike’s is just a “normal usecase”. To me it looks correct how it is >> shown in >> > history. At least it shows reality: 2 people were about to commit the >> same. >> > This happened with SVN many times, too, but you are right it was solved >> by >> > SVN through additional update (a rebase) and then try commit again. I am >> > fine with both variants. But if we decide to only do one variant, I’d >> prefer >> > to have some “howto chart” what you need to do to setup your working >> copy >> > correctly (all commands for configuring @apache.org username, pull >> > settings,…) that are local to the repository. Maybe add a >> shell/windows.cmd >> > script to devtools! I don’t want to change those settings globaly, so >> please >> > don’t use the magic –global setting in the example.If we have a script, >> we >> > can do that per WC: >> > >> > - Fetch repo from git-wip-us >> > >> > - Run script >> > >> > >> > >> > About merge: When we get pull requests from 3rd parties, we should >> > definitely not rebase!!!! With merging that in (in the same way how >> Githiub >> > is doing it), we preserve attribution to the original commiter. We >> should >> > really keep that! That is to me the only good reason to use Git! >> > >> > >> > >> > I am fine with rebasing our own stuff and make it a slight as possible, >> but >> > for stuff from 3rd party people, we should really preserve what they >> did! So >> > I will always use the command in the github pull request mail and apply >> that >> > to my working copy and push. >> > >> > >> > >> > Uwe >> > >> > >> > >> > ----- >> > >> > Uwe Schindler >> > >> > H.-H.-Meier-Allee 63, D-28213 Bremen >> > >> > http://www.thetaphi.de >> > >> > eMail: [email protected] >> > >> > >> > >> > From: Shai Erera [mailto:[email protected]] >> > Sent: Monday, January 25, 2016 8:50 AM >> > To: [email protected] >> > Subject: Re: Merge vs Rebase >> > >> > >> > >> > I agree David. I'm sure there are valid use cases for merging commits, >> but I >> > always prefer rebasing. This has been our way with Apache SVN anyway, >> so why >> > change it? I fell like merging only adds unnecessary lines to 'git log', >> > where you see "Merge commits (1, 7)" but this doesn't add much >> information >> > to whoever looks at it. >> > >> > What does it matter if this merge commit is from previous master and >> > feature-commit? Why do we need one additional commit per change? >> > >> > I'm not a Git expert, but I know (think...) that if you merge C1 and >> C2, and >> > C2 is a parent of C1, Git doesn't do a merge commit. Someone probably >> can >> > confirm that. >> > >> > FWIW, I plan to continue working the 'SVN' way by doing the following: >> > >> > git checkout master >> > >> > git pull --rebase (update to latest commit/rev) >> > >> > git checkout -b feature >> > >> > git commit -a -m "feature message" >> > >> > git commit --amend (applying review feedback) >> > >> > git fetch origin master:master (a'la 'svn up' we used to do) >> > git rebase master (now my feature commit is right on top of master's >> latest >> > commit / rev) >> > >> > git push origin HEAD:master >> > >> > This will preserve the history linear and flat, which is what we >> currently >> > have w/ SVN. >> > >> > >> > >> > As for merging this commit now to branch_5x. I'll admit I don't have >> > experience working with Git w/ multiple active (feature) branches, so >> I'm >> > not sure if rebasing branch_5x on my commit is what we want (cause it >> will >> > drag with it all of trunk's history, as far as I understand). I might >> try to >> > cheerrypick that commit only and apply to branch_5x, which is, again - >> AFAIU >> > - what we used to do in SVN. >> > >> > However, as I said, I'm not a Git expert, so if anyone thinks I should >> adopt >> > a different workflow, especially for the branch_5x changes, I'd be >> happy to >> > learn. >> > >> > Shai >> > >> > >> > >> > On Mon, Jan 25, 2016 at 8:13 AM David Smiley <[email protected]> >> > wrote: >> > >> > I suspect my picture didn’t make it so I’m trying again: >> > >> > >> > >> > Or if that didn’t work, I put it on dropbox: >> > >> > >> https://www.dropbox.com/s/p3q9ycxytxfqssz/lucene-merge-commit-pic.png?dl=0 >> > >> > >> > >> > ~ David >> > >> > >> > >> > On Jan 25, 2016, at 1:07 AM, [email protected] wrote: >> > >> > >> > >> > >> > >> > Just to put a little picture to this, I noticed the following: (see >> > attached pic) >> > >> > I suspect it was the bi-product of using a merge based pull (I think the >> > default?) instead of a rebase one, and as a result we have this little >> loop >> > in the log. No doubt there is a place for merge commits (e.g. merging >> one >> > feature branch and another); but is there an advocate willing to tell >> us the >> > virtues that in this instance (not all instances but this one), it's a >> good >> > thing? i.e. is there some insight this loop shows that that I should >> value >> > more than a direct simple lineage? >> > >> > >> > >> > FWIW I prefer to rebase my commits to prevent these little merge >> bubbles. >> > It happens automatically with this setting: >> > >> > git config --global pull.rebase true >> > >> > Alternatively it could be done without the --global flag. I would most >> > appreciate it if other committers used this same setting, and I think >> we'd >> > all mutually appreciate it as well with cleaner git histories. >> > >> > >> > ~ David >> > >> > -- >> > >> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker >> > >> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> > http://www.solrenterprisesearchserver.com >> > >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
