Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

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,

RE: GIT migration date (SVN freeze)

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 lo

Re: GIT migration date (SVN freeze)

> 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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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:

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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,

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

> 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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

: 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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

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

GIT migration date (SVN freeze)

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

Re: GIT migration date (SVN freeze)

> 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

Re: GIT migration date (SVN freeze)

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!