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 <[email protected]> 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 > <[email protected]> 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" <[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 > > > > > -- > http://www.the111shift.com --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
