It's worth noting that there are 2 things to talk about here... rebasing, and squashing. Often advocated together, but distinct. The first moves history around, the second collapses history, hiding the incremental commits that lead to the final state. It occurs to me that presently we have a set of patches in Jira recording things that were tried, and how it changed as well as the final commit. It seems that if rebase and squash becomes the process, we should account for where the process and things that didn't work are recorded. Links to pull requests in github perhaps? What if the accounts from which those were issued are discontinued or the forks deleted when someone feels a need to clean up (or perhaps github decides to limit public repos)? Will the process still involve a patch in Jira? In which case things are effectively squashed anyway...
On Tue, Jan 19, 2016 at 6:04 PM, Dawid Weiss <[email protected]> wrote: > Folks... remember that if we switch to git pretty much everyone can do > whatever they want until they actually push their stuff to the Apache > git repo. I would bet it will be more convenient for everyone to > actually work on their own (github, local or whatever) forks until > they have a patch they can apply to the main repo. And then they can > provide a patch either with rebase, diff, squash, whatever... > > A "merge --squash" is effectively getting a patch and applying it, > with some added convenience of recording in the log message what's > been squashed. It's not "really" a merge (a merge commit in git has > two parents). I think keeping linear history *is* simpler, at least at > the beginning, but we're only talking about two branches here -- > "master" and "branch_5x" -- these two should have linear history of > commits and this really is for convenience so that people understand > what's going on. > > I will do what you ask for, Hoss, although the cloned git repo records > every single SVN revision in the commit log anyway, so it should be > relatively easy to find which commit (SVN and otherwise) preceded the > move. > > Dawid > > > > On Tue, Jan 19, 2016 at 11:56 PM, Mark Miller <[email protected]> > wrote: > > bq. Merge commits either offer no information or add all the patch > > information to the history tree. It really just muddles things up for > > everyone. > > > > And I'm not talking about the 'feature branch' equivalent merge for > > something large you are working on and want the history for. > > > > I'm talking about the 90% of issues that are simple, small patches. > > > > - Mark > > > > On Tue, Jan 19, 2016 at 5:48 PM Mark Miller <[email protected]> > 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 <[email protected]> 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 <[email protected]> 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 <[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] > >>>> > >>> > >> -- > >> - Mark > >> about.me/markrmiller > > > > -- > > - Mark > > about.me/markrmiller > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- http://www.the111shift.com
