Folks... remember that if we switch to git pretty much everyone can do whatever they want until they actually push their stuff to the Apache git repo. I would bet it will be more convenient for everyone to actually work on their own (github, local or whatever) forks until they have a patch they can apply to the main repo. And then they can provide a patch either with rebase, diff, squash, whatever...
A "merge --squash" is effectively getting a patch and applying it, with some added convenience of recording in the log message what's been squashed. It's not "really" a merge (a merge commit in git has two parents). I think keeping linear history *is* simpler, at least at the beginning, but we're only talking about two branches here -- "master" and "branch_5x" -- these two should have linear history of commits and this really is for convenience so that people understand what's going on. I will do what you ask for, Hoss, although the cloned git repo records every single SVN revision in the commit log anyway, so it should be relatively easy to find which commit (SVN and otherwise) preceded the move. Dawid On Tue, Jan 19, 2016 at 11:56 PM, Mark Miller <markrmil...@gmail.com> wrote: > bq. Merge commits either offer no information or add all the patch > information to the history tree. It really just muddles things up for > everyone. > > And I'm not talking about the 'feature branch' equivalent merge for > something large you are working on and want the history for. > > I'm talking about the 90% of issues that are simple, small patches. > > - Mark > > On Tue, Jan 19, 2016 at 5:48 PM Mark Miller <markrmil...@gmail.com> wrote: >> >> bq. Especially having a rule that everyone *must* rebase doesn't seem >> right. >> >> We don't really have many rules, just agreed upon guidelines. There is no >> "rule" that you have to commit LUCENE-XXX: message, but we do it because it >> would be a mess if everyone used their own format. That doesn't mean when >> someone commits "this little test fix" someone says, wtf, you broke the >> 'rule'. Don't get too caught up in the language, you have to take it in the >> spirit of how the project operates. >> >> Merge commits either offer no information or add all the patch information >> to the history tree. It really just muddles things up for everyone. >> >> No one seems to have any actual arguments for merge? >> >> bq. Rebasing just makes development more complicated >> >> Do you have any statements to back that up? I find rebasing extremely >> simple. >> >> Git is simple when used simply. It's a nightmare when used fully. >> >> - Mark >> >> On Tue, Jan 19, 2016 at 5:25 PM Ryan Ernst <r...@iernst.net> wrote: >>> >>> I agree merges are better to use than rebasing. Rebasing just makes >>> development more complicated, and if you want to squash, you can always do >>> so with merge --squash (as Dawid pointed out on this thread). Especially >>> having a rule that everyone *must* rebase doesn't seem right. >>> >>> On Tue, Jan 19, 2016 at 2:09 PM, Robert Muir <rcm...@gmail.com> wrote: >>>> >>>> yeah, rebasing is garbage. That is what merge is for. >>>> >>>> If apache adds a merge button like github, even better. >>>> >>>> On Tue, Jan 19, 2016 at 4:11 PM, Gus Heck <gus.h...@gmail.com> wrote: >>>> > I'm not very fond of rebasing every commit. I don't like the >>>> > destruction of >>>> > merge history, but I'm not a committer here.... >>>> > >>>> > The following link may help any folks not familiar with git and >>>> > rebasing >>>> > from getting themselves (and possibly the project) into a snafu: >>>> > >>>> > >>>> > https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing >>>> > >>>> > On Tue, Jan 19, 2016 at 2:55 PM, Ramkumar R. Aiyengar >>>> > <andyetitmo...@gmail.com> wrote: >>>> >> >>>> >> +1. There might be ways to enforce it on the remote side.. >>>> >> >>>> >> >>>> >> >>>> >> http://stackoverflow.com/questions/2039773/have-remote-git-repository-refuse-merge-commits-on-push >>>> >> >>>> >> But I am not a git expert enough to tell you exactly what the >>>> >> solution >>>> >> there is trying to do.. >>>> >> >>>> >> On 19 Jan 2016 19:00, "Mark Miller" <markrmil...@gmail.com> wrote: >>>> >>> >>>> >>> I think for everyone's sanity we want to mostly ban merge commits >>>> >>> and >>>> >>> insist people use rebase and a linear history. I think we want to >>>> >>> keep the >>>> >>> history nice and clean just like it is now. >>>> >>> >>>> >>> You can change the pull command so that it does rebase rather than >>>> >>> merge >>>> >>> via git config --global pull.rebase true >>>> >>> >>>> >>> Even if everyone does not agree with that, we need some discussion >>>> >>> and >>>> >>> guidelines. Everyone going crazy in Git with merge commits makes an >>>> >>> ungodly >>>> >>> mess. >>>> >>> >>>> >>> - Mark >>>> >>> >>>> >>> On Tue, Jan 19, 2016 at 1:49 PM Dawid Weiss <dawid.we...@gmail.com> >>>> >>> wrote: >>>> >>>> >>>> >>>> > So I'm clear, this also means that from Saturday morning (call it >>>> >>>> > 6:00 >>>> >>>> > UTC) >>>> >>>> > until you give the OK (assuming the original schedule) I >>>> >>>> > shouldn't >>>> >>>> > count >>>> >>>> > on having access to any of the source code, right? >>>> >>>> >>>> >>>> You will have access to the source code -- the SVN remains >>>> >>>> functional, >>>> >>>> but it'll be an empty folder on the branches I mentioned. >>>> >>>> >>>> >>>> > And when you do give the OK, I should plan on rebasing whatever >>>> >>>> > I'm >>>> >>>> > working on to the new Git repo. There, did I use at least one Git >>>> >>>> > term >>>> >>>> > correctly? >>>> >>>> >>>> >>>> Well, the workflow is up to you. One possible way to work is like >>>> >>>> this >>>> >>>> (I assume command line, because that's what I use). >>>> >>>> >>>> >>>> 1) git clone <Apache repo/lucene_solr.git> >>>> >>>> cd lucene_solr >>>> >>>> >>>> >>>> 2) git checkout master -b mybranch >>>> >>>> >>>> >>>> 3) while (not done) { >>>> >>>> // work on mybranch's files. >>>> >>>> git add -A . # add any changes (and removals) to >>>> >>>> the >>>> >>>> commit, recursively. >>>> >>>> git diff --cached # see what would be committed. >>>> >>>> git commit -m "interim commit" >>>> >>>> } >>>> >>>> >>>> >>>> 4) When done, fetch any new commits from Apache. Merge them with >>>> >>>> your >>>> >>>> feature branch. If there are conflicts, git will guide you. Note >>>> >>>> there >>>> >>>> are no rebases here, you just merge stuff with master much like you >>>> >>>> did with SVN. >>>> >>>> >>>> >>>> git fetch origin >>>> >>>> git merge origin/master >>>> >>>> >>>> >>>> 5) Create a patch against master. >>>> >>>> >>>> >>>> git diff origin/master > myfeature.patch >>>> >>>> >>>> >>>> Done. Place the patch in Jira. >>>> >>>> >>>> >>>> If you wish to commit your changes to master, I'd "squash" all your >>>> >>>> interim changes into one single commit (easier on the eyes and >>>> >>>> simpler >>>> >>>> to revert). >>>> >>>> >>>> >>>> git checkout master >>>> >>>> git pull >>>> >>>> git merge --squash mybranch --nocommit >>>> >>>> # review what would be changed again, etc. >>>> >>>> git stat >>>> >>>> git diff --cached >>>> >>>> # finally, commit >>>> >>>> git commit -m "My changes." >>>> >>>> # and push the commit from your local repository and current branch >>>> >>>> to >>>> >>>> remote (Apache) repository. >>>> >>>> git push origin HEAD >>>> >>>> >>>> >>>> I guarantee you these steps are conceptually very simple. I'd run >>>> >>>> gitk >>>> >>>> --all after every single one (having read the document I pointed to >>>> >>>> previously) -- you'd see how the graph of patches and merges >>>> >>>> unfolds. >>>> >>>> >>>> >>>> Dawid >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>>> >>>> >>> -- >>>> >>> - Mark >>>> >>> about.me/markrmiller >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > http://www.the111shift.com >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>> >>> >> -- >> - Mark >> about.me/markrmiller > > -- > - Mark > about.me/markrmiller --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
