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
