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 > >
