That's just you ignoring what I've written. - Mark On Wed, Jan 20, 2016 at 12:21 PM Robert Muir <rcm...@gmail.com> wrote:
> But this is your personal opinion. > > Feel free to do what you like, but don't try to dictate how other > folks use their computers. > This religious nature of git users is extremely frustrating. > > There is really nothing wrong with using merge, personally that is > what I will be using. it is easy to understand. > > On Tue, Jan 19, 2016 at 5:48 PM, Mark Miller <markrmil...@gmail.com> > wrote: > > bq. Especially having a rule that everyone *must* rebase doesn't seem > right. > > > > We don't really have many rules, just agreed upon guidelines. There is no > > "rule" that you have to commit LUCENE-XXX: message, but we do it because > it > > would be a mess if everyone used their own format. That doesn't mean when > > someone commits "this little test fix" someone says, wtf, you broke the > > 'rule'. Don't get too caught up in the language, you have to take it in > the > > spirit of how the project operates. > > > > Merge commits either offer no information or add all the patch > information > > to the history tree. It really just muddles things up for everyone. > > > > No one seems to have any actual arguments for merge? > > > > bq. Rebasing just makes development more complicated > > > > Do you have any statements to back that up? I find rebasing extremely > > simple. > > > > Git is simple when used simply. It's a nightmare when used fully. > > > > - Mark > > > > On Tue, Jan 19, 2016 at 5:25 PM Ryan Ernst <r...@iernst.net> wrote: > >> > >> 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 > >>> > >> > > -- > > - Mark > > about.me/markrmiller > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- - Mark about.me/markrmiller
