GIT migration date (SVN freeze)

classic Classic list List threaded Threaded
74 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

GIT migration date (SVN freeze)

Dawid Weiss-2
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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!
Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Dawid Weiss-2
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Dawid Weiss-2
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Mark Miller-3
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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

--
Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Chris Hostetter-3
In reply to this post by Dawid Weiss-2

: 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 NNNN'"


(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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Ramkumar R. Aiyengar
In reply to this post by Mark Miller-3

+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" <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

--
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

--



--
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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" <[hidden email]> 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 <[hidden email]> 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: [hidden email]
For additional commands, e-mail: [hidden email]

--



--

Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Robert Muir
In reply to this post by Gus Heck
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 <[hidden email]> 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
> <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>
>
>
>
> --
> http://www.the111shift.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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
> <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>
>
>
>
> --
> http://www.the111shift.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Mark Miller-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>
>
>
>
> --
> http://www.the111shift.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
Reply | Threaded
Open this post in threaded view
|

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>
>
>
>
> --
> http://www.the111shift.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--

Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Mark Miller-3
In reply to this post by Mark Miller-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
> <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>> 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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>> --
>>> - Mark
>>> about.me/markrmiller
>
>
>
>
> --
> http://www.the111shift.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


--
--
Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Mark Miller-3
In reply to this post by Tomás Fernández Löbbe
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 <[hidden email]> 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

--
Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Dawid Weiss-2
In reply to this post by Mark Miller-3
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> > <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>>> >>> 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: [hidden email]
>>>> >>>> For additional commands, e-mail: [hidden email]
>>>> >>>>
>>>> >>> --
>>>> >>> - Mark
>>>> >>> about.me/markrmiller
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > http://www.the111shift.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>> --
>> - Mark
>> about.me/markrmiller
>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Chris Hostetter-3

: 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Dawid Weiss-2
> ..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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: GIT migration date (SVN freeze)

Gus Heck
In reply to this post by Dawid Weiss-2
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
>>>> > <[hidden email]> 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" <[hidden email]> 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 <[hidden email]>
>>>> >>> 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: [hidden email]
>>>> >>>> For additional commands, e-mail: [hidden email]
>>>> >>>>
>>>> >>> --
>>>> >>> - Mark
>>>> >>> about.me/markrmiller
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > http://www.the111shift.com
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>> --
>> - Mark
>> about.me/markrmiller
>
> --
> - Mark
> about.me/markrmiller

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




--
1234