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
