I'll offer my +1 on the proposed schedule (assuming the 5x releases are
completed).

I'm in favor of rebase commits on the master branch (and release branches)
to keep the history in a straight line. I propose that our patch checklist
be modified to include a note about performing both rebasing and squashing
- ie, each JIRA ticket is a single commit on the main branches. What people
do in their own clones/forks of the repo is up to them but I feel strongly
that we should do everything we can to keep the main repository branches
merge-commit free.

- Dennis

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
>

Reply via email to