+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" <[email protected]> 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 <[email protected]> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> -- > - Mark > about.me/markrmiller >
