But this is your personal opinion. Feel free to do what you like, but don't try to dictate how other folks use their computers. This religious nature of git users is extremely frustrating.
There is really nothing wrong with using merge, personally that is what I will be using. it is easy to understand. 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 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
