Re: GIT migration date (SVN freeze)

[Mark Miller]

That's just you ignoring what I've written.

- Mark
On Wed, Jan 20, 2016 at 12:21 PM Robert Muir  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 
> 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  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  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  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
> >>> >  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"  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  >
> >>> >>> 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 
> >>>  cd lucene_solr
> >>> 
> >>>  2) git checkout master -b mybranch
> >>> 
> >>>  3) while (not done) {
> >>>    // work on mybranch's files.
> >>>    git add -A . 

Re: GIT migration date (SVN freeze)

[Mark Miller]

If you don't have a lot of Git experience, do keep in mind there are lots
of GUI clients that are useful. Even if you choose not to use one
regularly, they are great for initially getting a view / handle on things.

My favorite is SmartGit - it's java and cross platform and made by some
awesome Germans. I almost never drop to command line with it, and other
than 'stage', my typical single branch workflow is the same as SVN
practically.

AFAIK, you can also use the GitHub clients without GitHub.

There is also TortoiseGit (I don't hear great things).

RabbitVCS (not my favorite)

And many, many more.

- Mark

On Wed, Jan 20, 2016 at 7:38 AM Dawid Weiss  wrote:

> > In the current SVN workflow we record the history
> > about that and we see all related commits of this merge
>
> Sigh. My opinion on SVN merges are quite the opposite -- at the
> low-level (which I had to go to, unfortunately) they are nothing *but*
> recorded merge history -- they're path-copy and aggregated diff
> commands that originate from nowhere... The "mergeinfo" property you
> refer to is not really a solution here, it's a workaround for an
> architectural flaw.
>
> > So what’s the right way to merge 3 commits from trunk (now master) to
> > branch_5x? Cherry-Pick and the commit and push?
>
> A git merge has two parent branches. So you merge changes on another
> branch inclusively (all of them). For example, in the git history of
> Solr and Lucene, a "merge" commit between the two projects effectively
> means "take all patches from solr + take all patches from Lucene and
> apply them". You can amend the merge commit and revert or modify
> certain bits, but it can be confusing (and I agree with Mark here).
>
> My personal preference is to work with individual commits, so yes, the
> workflow would be something like this:
>
> git checkout master
> # changeset1
> git add -A . && git commit -m "changeset1"
> # changeset2
> git add -A . && git commit -m "changeset2"
> # changeset3
> git add -A . && git commit -m "changeset3"
>
> git checkout branch_5x
> git log master # note hashes of commits you wish to apply on the branch
> git cherry-pick hash-changeset1 hash-changeset2 hash-changeset3
>
> The result would be three commits on master and three (identical)
> commits on branch_5x. If a changeset cannot be applied cleanly, git
> will let you know -- you can then either abort a cherry pick or modify
> the changeset and apply it on the branch.
>
> Note that if you're working on something you would squash the interim
> commits into one and then it's just one cherry pick to any of the
> maintenance branches you wish to apply it to.
>
> > just know how to use TortoiseGit and I see many buttons and checkboxes
> there
> > that I don’t know.
>
> Calm down and give it some time, although I have no clue what
> TortoiseGit looks like... The advantage of working with command line
> is that it's the same everywhere (windows, linux, mac).
>
> >  I want to see that those merges came from trunk/master in history.
>
> If you cherry pick a commit you won't see it as a merge. It is an
> "apply this commit's diff and log to another branch" command, it has
> nothing to do with merging.
>
> > For large feature
> > branches where more than one comitter are working on, we should of course
> > keep history and not only the final merge.
>
> You will grow to dislike this type of workflow with git if you then
> intend to apply the same feature to another branch... Yes there are
> workflows that make heavy use of branches, but they do require some
> understanding of what can be merged and where. I think it's not the
> right moment to introduce these.
>
> Think of a patch in Jira -- if it's self contained, you can just take
> it and apply it elsewhere. A merge commit of 40 commits that forked
> from the mainline is like taking those 40 patches that have occurred
> since the branch was forked and applying them successively back to the
> mainline. But if you have another branch, forked at a different
> "parent" commit then a merge of the feature branch is not just 40
> patches -- their entire diverging history of parent commits needs to
> be considered. The closest thing to svn's "merge reintegrate" would be
> to copy and rebase those 40 commits from the feature branch and then
> apply it again, but this is where you're getting into more advanced
> workflows. I'd stick with simple cases, at least at the beginning.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
- Mark
about.me/markrmiller

Re: GIT migration date (SVN freeze)

[Robert Muir]

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  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  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  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  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
>>> >  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"  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 
>>> >>> 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 
>>>  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
>>>  

Re: GIT migration date (SVN freeze)

[Ramkumar R. Aiyengar]

More to Mark's point, the focus of this effort is to move the repo and not
the development model. Sure, we can debate a lot more on whether rebase or
merge is preferred, bit given that the amount of git experience varies
across committers, it would help to start off as close to SVN as possible,
and linear history fits the bill..
On 20 Jan 2016 06:30, "Mark Miller"  wrote:

> On Tue, Jan 19, 2016 at 11:51 PM Noble Paul  wrote:
>
>>
>> > Yes, patches in JIRA will still be the primary force, with our secondary
>> > GitHub integration hooks. Agreed, 3rd party submissions will get
>> effectively
>> > squashed anyway.
>>
>> In the Git world users are happy give a pull request instead of a
>> patch. Why do you think patches in Jira will be the primary force?
>>
>>
> Because we are not changing anything about the current process right now.
> Just moving from SVN to Git.
>
> First class support is still patches in JIRA. We have a second class
> integration with Github as well. As before, contributors are free to use
> either. Nothing changes in that regard.
>
> - Mark
> --
> - Mark
> about.me/markrmiller
>

RE: GIT migration date (SVN freeze)

[Uwe Schindler]

Hi,

 

I am more interested about the workflow for merging (really *merge*) the stuff 
from trunk to 5.x! In the current SVN workflow we record the history about that 
and we see all related commits of this merge (in advanced SVN view), so just 
applying the same patch to trunk and 5.x (how it looks) is not what we should 
do. And here, not even svn’s history is linear.

 

So what’s the right way to merge 3 commits from trunk (now master) to 
branch_5x? Cherry-Pick and the commit and push? I have no idea, really! I just 
know how to use TortoiseGit and I see many buttons and checkboxes there that I 
don’t know. :) I want to see that those merges came from trunk/master in 
history.

 

I agree that merging back feature branches should look like a single commit (in 
simple cases) and you don’t want to see all work-in-progress-commits like typo 
fixes, small refactorings, adding javadocs,… For large feature branches where 
more than one comitter are working on, we should of course keep history and not 
only the final merge.

 

Uwe

 

-

Uwe Schindler

H.-H.-Meier-Allee 63, D-28213 Bremen

 <http://www.thetaphi.de/> http://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Ramkumar R. Aiyengar [mailto:andyetitmo...@gmail.com] 
Sent: Wednesday, January 20, 2016 9:26 AM
To: dev@lucene.apache.org
Subject: Re: GIT migration date (SVN freeze)

 

More to Mark's point, the focus of this effort is to move the repo and not the 
development model. Sure, we can debate a lot more on whether rebase or merge is 
preferred, bit given that the amount of git experience varies across 
committers, it would help to start off as close to SVN as possible, and linear 
history fits the bill..

On 20 Jan 2016 06:30, "Mark Miller" <markrmil...@gmail.com 
<mailto:markrmil...@gmail.com> > wrote:

On Tue, Jan 19, 2016 at 11:51 PM Noble Paul <noble.p...@gmail.com 
<mailto:noble.p...@gmail.com> > wrote:


> Yes, patches in JIRA will still be the primary force, with our secondary
> GitHub integration hooks. Agreed, 3rd party submissions will get effectively
> squashed anyway.

In the Git world users are happy give a pull request instead of a
patch. Why do you think patches in Jira will be the primary force?

 

Because we are not changing anything about the current process right now. Just 
moving from SVN to Git.

 

First class support is still patches in JIRA. We have a second class 
integration with Github as well. As before, contributors are free to use 
either. Nothing changes in that regard.

 

- Mark 

-- 

- Mark 

about.me/markrmiller <http://about.me/markrmiller> 

Re: GIT migration date (SVN freeze)

[Dawid Weiss]

> In the current SVN workflow we record the history
> about that and we see all related commits of this merge

Sigh. My opinion on SVN merges are quite the opposite -- at the
low-level (which I had to go to, unfortunately) they are nothing *but*
recorded merge history -- they're path-copy and aggregated diff
commands that originate from nowhere... The "mergeinfo" property you
refer to is not really a solution here, it's a workaround for an
architectural flaw.

> So what’s the right way to merge 3 commits from trunk (now master) to
> branch_5x? Cherry-Pick and the commit and push?

A git merge has two parent branches. So you merge changes on another
branch inclusively (all of them). For example, in the git history of
Solr and Lucene, a "merge" commit between the two projects effectively
means "take all patches from solr + take all patches from Lucene and
apply them". You can amend the merge commit and revert or modify
certain bits, but it can be confusing (and I agree with Mark here).

My personal preference is to work with individual commits, so yes, the
workflow would be something like this:

git checkout master
# changeset1
git add -A . && git commit -m "changeset1"
# changeset2
git add -A . && git commit -m "changeset2"
# changeset3
git add -A . && git commit -m "changeset3"

git checkout branch_5x
git log master # note hashes of commits you wish to apply on the branch
git cherry-pick hash-changeset1 hash-changeset2 hash-changeset3

The result would be three commits on master and three (identical)
commits on branch_5x. If a changeset cannot be applied cleanly, git
will let you know -- you can then either abort a cherry pick or modify
the changeset and apply it on the branch.

Note that if you're working on something you would squash the interim
commits into one and then it's just one cherry pick to any of the
maintenance branches you wish to apply it to.

> just know how to use TortoiseGit and I see many buttons and checkboxes there
> that I don’t know.

Calm down and give it some time, although I have no clue what
TortoiseGit looks like... The advantage of working with command line
is that it's the same everywhere (windows, linux, mac).

>  I want to see that those merges came from trunk/master in history.

If you cherry pick a commit you won't see it as a merge. It is an
"apply this commit's diff and log to another branch" command, it has
nothing to do with merging.

> For large feature
> branches where more than one comitter are working on, we should of course
> keep history and not only the final merge.

You will grow to dislike this type of workflow with git if you then
intend to apply the same feature to another branch... Yes there are
workflows that make heavy use of branches, but they do require some
understanding of what can be merged and where. I think it's not the
right moment to introduce these.

Think of a patch in Jira -- if it's self contained, you can just take
it and apply it elsewhere. A merge commit of 40 commits that forked
from the mainline is like taking those 40 patches that have occurred
since the branch was forked and applying them successively back to the
mainline. But if you have another branch, forked at a different
"parent" commit then a merge of the feature branch is not just 40
patches -- their entire diverging history of parent commits needs to
be considered. The closest thing to svn's "merge reintegrate" would be
to copy and rebase those 40 commits from the feature branch and then
apply it again, but this is where you're getting into more advanced
workflows. I'd stick with simple cases, at least at the beginning.

Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: GIT migration date (SVN freeze)

[Dawid Weiss]

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  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  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  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  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  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
 >  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"  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 
 >>> wrote:
 
  > So I'm clear, this also means that 

Re: GIT migration date (SVN freeze)

[Gus Heck]

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"  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 
>> 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 
>>> 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

Re: GIT migration date (SVN freeze)

[Mark Miller]

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  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  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  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  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
>>> >  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"  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 
>>> >>> 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 
>>>  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 

Re: GIT migration date (SVN freeze)

[Robert Muir]

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  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
>  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"  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 
>>> 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 
 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

Re: GIT migration date (SVN freeze)

[Mark Miller]

Yes, anything that results in the same result is obviously the same :)

I was not arguing against David's steps. I was emphasizing the history
situation.

Linear history = good.

Don't read too far into specific Git commands or Git command bans. I'm not
looking for any of that.

I wanted to push the discussion to proper history management. For me that
is easiest with normally doing a rebase, so most small commits want that
end result behavior. If you want to squash or git fu commits anyway you
want for the same result, no one will even know ;)

- Mark

On Tue, Jan 19, 2016 at 5:55 PM Tomás Fernández Löbbe 
wrote:

> 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
>
> --
- Mark
about.me/markrmiller

Re: GIT migration date (SVN freeze)

[Dennis Gove]

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  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"  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 
>>> 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 
 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
>

Re: GIT migration date (SVN freeze)

[Mark Miller]

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  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  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  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
>> >  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"  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 
>> >>> 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 
>>  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
>> 

Re: GIT migration date (SVN freeze)

[Ryan Ernst]

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  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  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
> >  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"  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 
> >>> 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 
>  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
>
>

Re: GIT migration date (SVN freeze)

[Tomás Fernández Löbbe]

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  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  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  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  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
>>> >  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"  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 
>>> >>> 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 
>>>  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
>>> 

Re: GIT migration date (SVN freeze)

[Mark Miller]

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  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 
> 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

Re: GIT migration date (SVN freeze)

[Dawid Weiss]

> 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 
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

Re: GIT migration date (SVN freeze)

[Erick Erickson]

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?

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?

This is not a problem, just making sure I understand what I'll have access
to when. Besides, I have a couple of retaining walls to build and can easily
spend all weekend without needing to touch my keyboard ;).

Erick

On Tue, Jan 19, 2016 at 5:53 AM, Dawid Weiss  wrote:
>> This works for me as long as we don't have to respin any of the two ongoing
>> releases (5.3.2 and 5.4.1) so that the releases will be done by the time
>> that we start the migration.
>
> Good point. I think it makes sense to wait for these as they'd be then
> properly tagged in git, etc. If it happens before the weekend, good,
> otherwise we'll postpone.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: GIT migration date (SVN freeze)

[Ramkumar R. Aiyengar]

+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"  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  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 
>> 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
>

Re: GIT migration date (SVN freeze)

[Chris Hostetter]

: You will have access to the source code -- the SVN remains functional,
: but it'll be an empty folder on the branches I mentioned.

1 suggestion Dawid...

Just before you run the massive "svn rm" command(s) needed for the wiping 
commit(s), please run "svnversion" on each branch and make a note of the 
r#, then refer to that in your last svn commit message(s), 

trunk example...

svn commit -m "LUCENE-6937: purging all files from the trunk branch of SVN 
as part of our git migration.  The new canonical GIT repo for this code 
base is now https://git.ap...  If you wish to see the contents of this 
branch just prior to this migration you can use 'svn update -r '"


(yes there are other ways for folks to figure this info out, but we might 
as well make it trivial for folks looking at the svn log)



-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: GIT migration date (SVN freeze)

[Chris Hostetter]

: 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.

Sure -- my suggestion was not based on any worries about the "post svn" 
world ... my suggestion was purely based on concerns for:

a) people who forget/don't-know that the migration is happening and do an 
"svn update" this weekend and then want to be able to get back to the 
last useful r# they can develop/test against while they wait for the git 
repo to be available

a) people who might only casually follow lucene/solr dev who do an "svn 
update" a few weeks/months from now and then wonder where the fuck all the 
files went; and/or may not really care enough about long term development 
to bother cloning the git repo -- but still want to get their local svn 
copy back to the state it was before the migration.

..at least having that info in the last svn log message for the directory 
will be a little help (although adding a README_MOVED_TO_GIT.txt file with 
the same info after the 'purge all files comment' would probably also be a 
good idea so people don't even have to check the svn log.)


-Hoss
http://www.lucidworks.com/

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: GIT migration date (SVN freeze)

[Gus Heck]

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  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 
> 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 
> 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  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  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  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
>  >  wrote:
>  >>
>  >> +1. There might be ways to enforce it on the 

Re: GIT migration date (SVN freeze)

[Mark Miller]

On Tue, Jan 19, 2016 at 6:28 PM Gus Heck  wrote:

>  Will the process still involve a patch in Jira? In which case things are
> effectively squashed anyway...
>
>
Yes, patches in JIRA will still be the primary force, with our secondary
GitHub integration hooks. Agreed, 3rd party submissions will get
effectively squashed anyway.

This linear history topic was mainly meant for the few committers we have
that have not really used Git. Committers will work within a repo, and even
if they put up a patch, likely commit from that same work.

Basically, we are agreeing to keep a merge commit out of places where it
only adds confusion. Whether that is done via rebase or squash or some
other git fu, we probably can't really mandate, nor do we need to.

I trust that people that use Git are not going to go in and do tons of
crazy stuff. We want the people that don't use Git to keep things sane as
well.

- Mark
-- 
- Mark
about.me/markrmiller

Re: GIT migration date (SVN freeze)

[Dawid Weiss]

> ..at least having that info in the last svn log message for the directory
> will be a little help (although adding a README_MOVED_TO_GIT.txt file with
> the same info after the 'purge all files comment' would probably also be a
> good idea so people don't even have to check the svn log.)

That's exactly what I was going to do -- much in the spirit of this:

https://svn.apache.org/repos/asf/lucene/java/trunk/trunk_development_moved.txt

It makes a lot of sense and I do share your opinion it's helpful, I
just didn't think to put this in the commit log, but redundancy here
doesn't hurt.

Also, I wouldn't be advocating for git so much if I wasn't *really*
convinced it's a change for the better. I know it will be a pain for
some people, especially at the beginning, but it's just such a more
versatile tool to work with... For those who remember -- think of
switching between CVS and SVN and you'll know what I mean. A whole
different experience.

Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: GIT migration date (SVN freeze)

[Noble Paul]

On Wed, Jan 20, 2016 at 5:47 AM, Mark Miller  wrote:
>
>
> On Tue, Jan 19, 2016 at 6:28 PM Gus Heck  wrote:
>>
>>  Will the process still involve a patch in Jira? In which case things are
>> effectively squashed anyway...
>>
>
> Yes, patches in JIRA will still be the primary force, with our secondary
> GitHub integration hooks. Agreed, 3rd party submissions will get effectively
> squashed anyway.

In the Git world users are happy give a pull request instead of a
patch. Why do you think patches in Jira will be the primary force?
>
> This linear history topic was mainly meant for the few committers we have
> that have not really used Git. Committers will work within a repo, and even
> if they put up a patch, likely commit from that same work.
>
> Basically, we are agreeing to keep a merge commit out of places where it
> only adds confusion. Whether that is done via rebase or squash or some other
> git fu, we probably can't really mandate, nor do we need to.
>
> I trust that people that use Git are not going to go in and do tons of crazy
> stuff. We want the people that don't use Git to keep things sane as well.
>
> - Mark
> --
> - Mark
> about.me/markrmiller



-- 
-
Noble Paul

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: GIT migration date (SVN freeze)

[Mark Miller]

On Tue, Jan 19, 2016 at 11:51 PM Noble Paul  wrote:

>
> > Yes, patches in JIRA will still be the primary force, with our secondary
> > GitHub integration hooks. Agreed, 3rd party submissions will get
> effectively
> > squashed anyway.
>
> In the Git world users are happy give a pull request instead of a
> patch. Why do you think patches in Jira will be the primary force?
>
>
Because we are not changing anything about the current process right now.
Just moving from SVN to Git.

First class support is still patches in JIRA. We have a second class
integration with Github as well. As before, contributors are free to use
either. Nothing changes in that regard.

- Mark
-- 
- Mark
about.me/markrmiller

GIT migration date (SVN freeze)

[Dawid Weiss]

Hello everyone,

This is just to let you know that we've worked with Infra (thanks to
all those involved on INFRA-11056) and it seems we're ready to go. Two
important things:

1) I would like to proceed with the migration on Saturday (European
morning). This will include creating a "wiping" commit on branch_5x
and trunk that will remove all the current content and point people at
the git repository. I don't want to touch anything else. This step
should be preceded by disabling all the existing Jenkins jobs (they
will start to fail after that, for obvious reasons) -- I'd need some
help with that.

2) After (1), I'll convert the SVN history to git again (including the
wiping commit) and revert it on git side. I'll push this to github and
let infra know to wipe the existing git clone and import this repo
instead.

3) If everything is successful, we should be restoring Jenkinses, etc.
GitHub should catch up in a day or two (after they sync up with Apache
mirror).

I assume lazy consensus, if you wish to speak up, please do.

Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: GIT migration date (SVN freeze)

[Dawid Weiss]

> This works for me as long as we don't have to respin any of the two ongoing
> releases (5.3.2 and 5.4.1) so that the releases will be done by the time
> that we start the migration.

Good point. I think it makes sense to wait for these as they'd be then
properly tagged in git, etc. If it happens before the weekend, good,
otherwise we'll postpone.

Dawid

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: GIT migration date (SVN freeze)

[Adrien Grand]

Hi Dawid,

This works for me as long as we don't have to respin any of the two ongoing
releases (5.3.2 and 5.4.1) so that the releases will be done by the time
that we start the migration.

Thanks for working on this!