lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe <tomasflo...@gmail.com>
Subject Re: GIT migration date (SVN freeze)
Date Tue, 19 Jan 2016 22:55:38 GMT
My understanding is that squashed merges also keep the linear history. You
do loose the branch commit history, but if that's not something you are
interested in keeping that should be fine, right? That's the workflow that
Dawid proposed and it's the one I've been using so far with git.

Tomás

On Tue, Jan 19, 2016 at 2:48 PM, Mark Miller <markrmiller@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 <ryan@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 <rcmuir@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.heck@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
>>> > <andyetitmoves@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" <markrmiller@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.weiss@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-unsubscribe@lucene.apache.org
>>> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>>
>>> >>> --
>>> >>> - Mark
>>> >>> about.me/markrmiller
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > http://www.the111shift.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>> --
> - Mark
> about.me/markrmiller
>

Mime
View raw message