Moving to Git?

# Ashod Nakashian (7 years ago)

WebKittens,

In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again).

The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition.

I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly.

[1] bugs.webkit.org/show_bug.cgi?id=79509#c6

[2] trac.webkit.org/wiki/Moving%20to%20Git [3] trac.webkit.org/wiki/Moving%20to%20Git?action=history

Thanks for lending an ear,

Contact us to advertise here
# Sergio Villar Senin (7 years ago)

En 08/03/12 13:35, Ashod Nakashian escribiu:

WebKittens,

In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again).

Please correct me if I'm wrong but IIRC the main blocker was that any user with an standard OS X setup should be able to start hacking on WebKit without having to install any additional dependency. SVN is shipped with OS X and git is not.

Anyway I'd be really pleased if that move happens.

BR

# Jarred Nicholls (7 years ago)

On Thu, Mar 8, 2012 at 7:46 AM, Sergio Villar Senin <svillar at igalia.com>wrote:

En 08/03/12 13:35, Ashod Nakashian escribiu:

WebKittens,

In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again).

Please correct me if I'm wrong but IIRC the main blocker was that any user with an standard OS X setup should be able to start hacking on WebKit without having to install any additional dependency. SVN is shipped with OS X and git is not.

A version of git ships with Xcode, and without Xcode I don't think anyone attempting to hack on WebKit will get very far :3

# Ashod Nakashian (7 years ago)

From: Sergio Villar Senin <svillar at igalia.com> To: webkit-dev at lists.webkit.org Sent: Thursday, March 8, 2012 4:46 PM Subject: Re: [webkit-dev] Moving to Git?

En 08/03/12 13:35, Ashod Nakashian escribiu:

WebKittens,

In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again).

Please correct me if I'm wrong but IIRC the main blocker was that any user with an standard OS X setup should be able to start hacking on WebKit without having to install any additional dependency. SVN is shipped with OS X and git is not.

Ahh, the days when one didn't have to download anything to start hacking away... But seriously, why should I care about OS X when Windows comes packed with git?</sarcasm>

Anyway I'd be really pleased if that move happens.

Same here. And my hope is that there are many more of us.

# Konrad Piascik (7 years ago)

I personally use either git or git-svn and would welcome the move.

# Ryosuke Niwa (7 years ago)

On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian <ashodnakashian at yahoo.com>wrote: >

In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again).

The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition.

I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly.

Re-evaluating the situation is good, but I'm still opposed.

# Alexis Menard (7 years ago)

On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian <ashodnakashian at yahoo.com> wrote: >

In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again).

The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition.

I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly.

Re-evaluating the situation is good, but I'm still opposed.

I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste).

Then for everything else I use git and its power locally.

# Ryosuke Niwa (7 years ago)

On Thu, Mar 8, 2012 at 9:10 AM, Alexis Menard

<alexis.menard at openbossa.org>wrote: >

I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste).

And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial.

Then for everything else I use git and its power locally. >

Right. Git clients are pretty nice.

# Geoffrey Garen (7 years ago)

Rather than asking for a switch to git by fiat, why not improve git and our git-related infrastructure to the point where people choose to switch naturally?

The fact that many valuable contributors choose not to use git is sufficient proof that switching by fiat would be a bad idea.

Geoff

# Carlos Garcia Campos (7 years ago)

El jue, 08-03-2012 a las 14:10 -0300, Alexis Menard escribió:

On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian <ashodnakashian at yahoo.com> wrote: >

In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again).

The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition.

I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly.

Re-evaluating the situation is good, but I'm still opposed.

I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste).

I agree about merging commits, but I think it's possible to enforce all merges to be fast-forward and without merging commits. In general browsing git history is easier and cleaner than svn, and more important it's much faster (my taste :-P)

Then for everything else I use git and its power locally.

I would be more than happy with the switch :-)

# Philippe Normand (7 years ago)

On Thu, 2012-03-08 at 14:10 -0300, Alexis Menard wrote:

On Thu, Mar 8, 2012 at 2:03 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Thu, Mar 8, 2012 at 4:35 AM, Ashod Nakashian <ashodnakashian at yahoo.com> wrote: >

In the light of discovering that some SVN scripts have fallen behind in terms of maintenance[1] and WebKit's strong Git support and infrastructure, against my better judgement, I'd like to distract you from being productive by bringing up this topic (again).

The wiki page of the same name[2] was created 3 years ago and hardly updated since[3]. I know we're all busy with more important things, but IMHO I think we can at least update the wiki and perhaps vote on when/how we should do the eventual transition.

I understand that while this type of work isn't necessarily very productive, maintaining two repositories and sets of scripts (with their docs and issues) has a very real cost as well. I'm proposing we reevaluate the situation and act accordingly.

Re-evaluating the situation is good, but I'm still opposed.

I don't use svn but the only benefit I see of WebKit using svn is the linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste).

We just need to keep the history linear. With good practices it's possible :)

Philippe

# Konrad Piascik (7 years ago)

It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing. Konrad Sent from my BlackBerry on the Rogers Wireless Network

# Alexis Menard (7 years ago)

On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik <kpiascik at rim.com> wrote:

It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing.

But can you enforce in the server? To avoid people to push it by mistake?

# Dana Jansens (7 years ago)

On Thu, Mar 8, 2012 at 12:35 PM, Alexis Menard

<alexis.menard at openbossa.org>wrote:

On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik <kpiascik at rim.com> wrote:

It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing.

But can you enforce in the server? To avoid people to push it by mistake?

progit.org/book/ch7-4.html

Konrad

# Carlos Garcia Campos (7 years ago)

El jue, 08-03-2012 a las 14:35 -0300, Alexis Menard escribió:

On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik <kpiascik at rim.com> wrote:

It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing.

But can you enforce in the server? To avoid people to push it by mistake?

Yes, I think it's possible with a hook in the server.

# Adam Treat (7 years ago)

Indeed it is.

# Tor Arne Vestbø (7 years ago)

On 08.03.12 18:22, Geoffrey Garen wrote:

Rather than asking for a switch to git by fiat, why not improve git and our git-related infrastructure to the point where people choose to switch naturally?

The fact that many valuable contributors choose not to use git is sufficient proof that switching by fiat would be a bad idea.

That's a good point. I'm curious though, what are the main sicking points?

tor arne

# Ashod Nakashian (7 years ago)

From: Ryosuke Niwa <rniwa at webkit.org> To: Alexis Menard <alexis.menard at openbossa.org> Cc: Ashod Nakashian <ashodnakashian at yahoo.com>; WebKit Development <webkit-dev at lists.webkit.org> Sent: Thursday, March 8, 2012 9:19 PM Subject: Re: [webkit-dev] Moving to Git?

On Thu, Mar 8, 2012 at 9:10 AM, Alexis Menard <alexis.menard at openbossa.org> wrote: I don't use svn but the only benefit I see of WebKit using svn is the

linear history, clean, easy to read and to explore. Git repos tend to have merging commits a lot and it leads to make bisecting/history browsing harder (my taste).

And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial.

I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN.

# Ashod Nakashian (7 years ago)

From: Geoffrey Garen <ggaren at apple.com> To: Ashod Nakashian <ashodnakashian at yahoo.com> Cc: WebKit Development <webkit-dev at lists.webkit.org> Sent: Thursday, March 8, 2012 9:22 PM Subject: Re: [webkit-dev] Moving to Git?

Rather than asking for a switch to git by fiat, why not improve git and our git-related infrastructure to the point where people choose to switch naturally?

Switch by fiat? Not by a long shot. The call is to reevaluate the suggestion. Indeed, we must improve the infrastructure as long as there are users, regardless of any plans of moving VCs.

The fact that many valuable contributors choose not to use git is sufficient proof that switching by fiat would be a bad idea.

This is part of the goal - to see how many still use SVN, what's holding them back from the move and how we can help them and the community to make the transition to what is deemed by most (my estimate) to be superior.

On that count, what feature do you find in svn that is missing from git, or put differently, why is git not as good as svn for you?

# simon.hausmann at nokia.com (7 years ago)

Alexis, imagine not pushing directly but going through an intermediate system like in Qt - where history is nicely linear now :)

Simon

# Ryosuke Niwa (7 years ago)

On Thu, Mar 8, 2012 at 11:24 AM, Ashod Nakashian

<ashodnakashian at yahoo.com>wrote: >

And that's a show stopper for me. For build bot maintenance, regression fixes, etc... being able to easily tell the number of commits between two revisions (in my head as opposed to using a tool) or the ordering of commits is crucial.

I think this is an interesting point. It seems there are two solutions. We can enforce fast-forward as many have pointed out and we can maintain an SVN mirror. Although I don't like the idea of maintaining an SVN repo, and it's almost universally agreed that git offers superior tools to SVN.

I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on.

# Adam Treat (7 years ago)

There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts.

# Joe Mason (7 years ago)

It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it.

What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches?

What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier?

# Ryosuke Niwa (7 years ago)

On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat <atreat at rim.com> wrote:

There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts.

On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason <jmason at rim.com> wrote:

It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it.

What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches?

What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier?

The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run "svn up".

# Antonio Gomes (7 years ago)

(For those valuable contributors who are against Git and have manifested somehow here, please do not take it personally)

IMO, none of the arguments used here so far seem like a real problem for a switch. Of course, SVN people would have to adapt their workflow and it could take days (no more than that, trust me), but it is for a greater goal at the end.

In my opinion, SVN concepts are completely obsolete these days. It is hard to me to even hear someone arguing in favor of SVN against GIT, but I respect anyone's opinion. I just do not feel them strong enough given the whole context.

# Dirk Pranke (7 years ago)

On Thu, Mar 8, 2012 at 9:22 AM, Geoffrey Garen <ggaren at apple.com> wrote:

Rather than asking for a switch to git by fiat, why not improve git and our git-related infrastructure to the point where people choose to switch naturally?

The fact that many valuable contributors choose not to use git is sufficient proof that switching by fiat would be a bad idea.

People have been improving our git infrastructure constantly; I think the point is the converse ... it's getting harder to support SVN, and supporting two systems does impose a cost (at least to the people like me that do hack on the infrastructure :).

That said, I have to agree that it's nice to be able to see a monotonically increasing number in the change history. Even if you have a single linear branch in the git master, you don't have that. Maybe there is a practice for getting an equivalent using labels or tags in git repos that I don't know about?

# Geoffrey Garen (7 years ago)

IMO, none of the arguments used here so far seem like a real problem for a switch. Of course, SVN people would have to adapt their workflow and it could take days (no more than that, trust me), but it is for a greater goal at the end.

This is an example of what I mean by "fiat":

Step 1: Force a change upon people Step 2: … Step 3: A greater good is achieved

Geoff

# Antonio Gomes (7 years ago)

I might have missed your point. Who is trying to force you to change something?

I would love to understand the "other side" for sure...

# Jochen Eisinger (7 years ago)

On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat <atreat at rim.com> wrote:

There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts.

On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason <jmason at rim.com> wrote:

It seems to me that there's no need to use multiple local branches in git

if you find it confusing - it's an additional feature, but I don't see anything that requires it.

What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches?

What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier?

The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run "svn up".

I wonder, do you really run svn up that much? I'd expect that this breaks your checkout every now and then if some dependencies change. I usually run update-webkit, which should hide the rebasing actions from you

# Hugo Parente Lima (7 years ago)

On Thursday 08 March 2012 17:12:47 Ryosuke Niwa wrote:

On Thu, Mar 8, 2012 at 12:04 PM, Adam Treat <atreat at rim.com> wrote:

There is nothing about git that forces you to have multiple branches locally. Good practice, yes, but nothing forcing it. As for the difficulty of resolving conflicts between patches you've made locally and changes made on the shared repository since you started making your local patches... nothing about git makes this any harder. Unless you have a lock based source control system you'll have to resolve conflicts.

On Thu, Mar 8, 2012 at 12:05 PM, Joe Mason <jmason at rim.com> wrote:

It seems to me that there's no need to use multiple local branches in git if you find it confusing - it's an additional feature, but I don't see anything that requires it.

What workflow do you have that requires you to have multiple branches locally in git, and how do you solve it in svn without using branches?

What precisely do you find difficult about merging remote changes, and how is the svn equivalent easier?

The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run "svn up".

"git pull" does the same (if no conflicts were found, but the same pain will happen on svn in case of conflicts)

or "git fetch origin; git rebase origin/master"

I remember the days were I switched from svn to git, blaming git for force me to type additional commands, today I'm just regrets for the blames and can't think in another VCS than git :-).

# Joe Mason (7 years ago)

Well, not quite. The equivalent to "svn up" is "git pull --rebase origin/master" (which should be the default, as git merge is the bit that horribly confuses people - but I digress). I'm not sure if it will fill in the origin/master part automatically.

What Ryosuke seems to be complaining about is that if you have changes to your working copy, "svn up" will automatically merge them, which could lead to conflicts you have to untangle, while "git pull --rebase" will give an error telling you you must commit or stash them first. So the real equivalent to "svn up" is "git stash && git pull --rebase origin/master && git stash pop". And "git stash pop" will start pretty much the same merging process as svn's if there are conflicts.

This is only slightly more complicated, and has the benefit that if something goes wrong, your changes remain explicitly in the git stash, where you can get at them with commands like "git stash show" or "git stash branch", whereas unless svn has features I don't know about, if "svn up" does unexpected things the only record of your changes is a series of conflict markers you'll need to resolve.

And you can always make a "git-up" script that does "git stash && git pull --rebase origin/master && git stash pop", so the command you type won't even be any longer than "svn up", but will give you more safety.

# Ryosuke Niwa (7 years ago)

On Thu, Mar 8, 2012 at 12:44 PM, Jochen Eisinger <jochen at chromium.org> wrote: >

On Thu, Mar 8, 2012 at 9:12 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: >

The simplicity. In git, I have to worry about things like committing local changes before rebasing to master, or stashing, etc... In svn, all I have to do is to run "svn up".

I wonder, do you really run svn up that much? I'd expect that this breaks your checkout every now and then if some dependencies change. I usually run update-webkit, which should hide the rebasing actions from you

I do that at least 5-6 times a day if not more.

On Thu, Mar 8, 2012 at 12:58 PM, John Yani <vanuan at gmail.com> wrote:

I don't think so. I like the simplicity of svn. While git client works great, I always get frustrated by the complexity of having multiple branches locally and the amount of work required to merge the remote changes on the branch I'm working on.

What do you mean?

fetch from origin master and merge into the current branch

git pull origin master

Huh? That's not equivalent to svn up at all.

On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason <jmason at rim.com> wrote: >

What Ryosuke seems to be complaining about is that if you have changes to your working copy, "svn up" will automatically merge them, which could lead to conflicts you have to untangle, while "git pull --rebase" will give an error telling you you must commit or stash them first. So the real equivalent to "svn up" is "git stash && git pull --rebase origin/master && git stash pop". And "git stash pop" will start pretty much the same merging process as svn's if there are conflicts.

Right. But I can't bother to type that much myself. Maybe my complain will go away if someone had implemented webkit-patch up that does this automatically.

This is only slightly more complicated

I'd say astoundingly more complicated because of

and has the benefit that if something goes wrong, your changes remain

explicitly in the git stash, where you can get at them with commands like "git stash show" or "git stash branch"

whereas unless svn has features I don't know about, if "svn up" does unexpected things the only record of your changes is a series of conflict markers you'll need to resolve.

But I can just run svn diff to create a backup if I really wanted to save the original change. But I've never had a trouble merging things so it's hard for me to tell if that's really useful or not.

And you can always make a "git-up" script that does "git stash && git pull

--rebase origin/master && git stash pop", so the command you type won't even be any longer than "svn up", but will give you more safety.

That'll certainly be an improvement. I still dislike git hashes though. If someone implements such a script in webkit-patch and we can automatically assign svn-revision like numbers to all commits, I can be convinced to use git.

# Joe Mason (7 years ago)

I agree that git's hashes are less friendly than the monotonically increasing commit numbers from svn or p4. I've occasionally been given a pair of git hashes and had no idea which one came first, or even if they were in the same branch.

"git log --oneline <hash>" is a pretty simple way to list all the commits coming before the given <hash>, so you can see the order of them. Other than that, maybe a post-commit hook that automatically puts a

Aside: here's a neat command to map git hash's to svn-style ascending numbers: git log --oneline <hash>|cat -b

$ git log --oneline e865bb0|cat -b|head 1 e865bb0 [Qt WK2] Remove duplicate code related to dialog handling in QQuickWebView bugs.webkit.org/show_bug.cgi?id=80557 2 a6b3dd6 Fix flaky test by decreasing granularity of cues (cues cover longer time intervals). The flakiness seems to appear because the video is paused synchronously, while missed events events are dispatched asynchronously. 3 9e20583 [Qt] Rebaseline after r110072. 4 4e072d9 [Qt] Windows build fix.ommit 5 7c7ab53 [chromium] Unreviewed gardening. 6 7c004bc Web Inspector: The function had to return a hash but it returned just address. bugs.webkit.org/show_bug.cgi?id=80591 7 d4c2667 Unreviewed single line fix. The function had to return a hash but it returned just address. 8 7b5de0b [chromium] Unreviewed gardening. 9 5540031 <shadow> should be rendered correctly. bugs.webkit.org/show_bug.cgi?id=78596 10 9040697 Speech JavaScript API: SpeechRecognitionAlternative, Result and ResultList bugs.webkit.org/show_bug.cgi?id=80424

...except of course that this is descending numbers (1 is the most recent) and they're not persistent, so telling somebody "commit 8" only works if they're starting from the same point. Which makes them not incredibly useful.

# Maciej Stachowiak (7 years ago)

It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn.

It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated:

1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?)

And then there is the status quo:

3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so.

One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off.

If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider:

A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems.

Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those?

# Dirk Pranke (7 years ago)

On Thu, Mar 8, 2012 at 2:10 PM, Maciej Stachowiak <mjs at apple.com> wrote: >

It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn.

It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated:

1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?)

There appear to be scripts on the interweb that would allow access to a git repo over svn. I would be against doing this here (if we're going to allow svn access at all, we might as well stay with what we have).

I believe that a git repo would allow slightly easier cloning and branching, and would make the overall system more reliable (because we wouldn't have to worry about the git/svn bridge breaking or getting corrupted).

I don't think either of these reasons is particularly compelling, although I have no real insight into the uptime / ops costs of keeping the two repos in sync vs. only a git repo.

I think the major benefit in moving git-only would be to simplify the tooling and the documentation for the project (we wouldn't have to document how to access everything two or three different ways). I am uncertain but skeptical that the tooling benefit outweighs the cost of the conversion.

# Alexis Menard (7 years ago)

On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak <mjs at apple.com> wrote: >

It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn.

It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated:

1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?)

And then there is the status quo:

3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so.

One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off.

If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider:

A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems.

Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those?

To the global infrastructure :

  • Local history for git. svn log access to the server every time you call that command. Will improve the load of the server.
  • Performance of checkouts/pull as data are send compressed from the server.

To git user :

  • Using git push rather than having to use git-svn (which you need to keep in sync).
  • Simplified workflow, we don't need to mess with git-svn.
  • Companies who fork (we all do) can simplify their workflow a bit regarding branches.

To svn user :

  • Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn).
  • Local history/blaming/...
  • Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff).
  • The staging area, upload what you want/need and keep some work local
  • Smaller checkouts

The real downside is for the svn users to learn a bit git workflow.

I'm forgetting stuff for sure.

# David Barr (7 years ago)

On Fri, Mar 9, 2012 at 8:25 AM, Ryosuke Niwa <rniwa at webkit.org> wrote: >

On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason <jmason at rim.com> wrote: >

What Ryosuke seems to be complaining about is that if you have changes to your working copy, "svn up" will automatically merge them, which could lead to conflicts you have to untangle, while "git pull --rebase" will give an error telling you you must commit or stash them first. So the real equivalent to "svn up" is "git stash && git pull --rebase origin/master && git stash pop". And "git stash pop" will start pretty much the same merging process as svn's if there are conflicts.

Right. But I can't bother to type that much myself. Maybe my complain will go away if someone had implemented webkit-patch up that does this automatically.

And you can always make a "git-up" script that does "git stash && git pull --rebase origin/master && git stash pop", so the command you type won't even be any longer than "svn up", but will give you more safety.

That'll certainly be an improvement. I still dislike git hashes though. If someone implements such a script in webkit-patch and we can automatically assign svn-revision like numbers to all commits, I can be convinced to use git.

I fully support scripts specific to the WebKit workflow that wrap the VCS specifics.

In my former role, I spoke to developers to identify their most common sequences of actions when synchronising their code and what information they needed when a step failed. I then wrote a common script that would execute as much of the process as it could and provide information and instruction on failure. This was a boon to productivity as in the common case, synchronisation was sub-second, and in the uncommon case they no longer had to dig up the relevant information before resolving conflicts.

I think we ought to streamline the git workflow before we start trying to proselytise Subversion users. :)

The monotonic labels that Ryosuke desires are known in git language as "generation numbers". If we maintain a canonical linear history going forward, they would also be unique as with Subversion. This could be a good reason to resurrect the relevant thread on the git mailing list.

-- David Barr.

# Alexis Menard (7 years ago)

On Thu, Mar 8, 2012 at 7:30 PM, Alexis Menard

<alexis.menard at openbossa.org> wrote:

On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak <mjs at apple.com> wrote: >

It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn.

It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated:

1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?)

And then there is the status quo:

3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so.

One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off.

If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider:

A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems.

Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those?

To the global infrastructure :

  • Local history for git. svn log access to the server every time you call that command. Will improve the load of the server.
  • Performance of checkouts/pull as data are send compressed from the server.

To git user :

  • Using git push rather than having to use git-svn (which you need to keep in sync).
  • Simplified workflow, we don't need to mess with git-svn.
  • Companies who fork (we all do) can simplify their workflow a bit regarding branches.

To svn user :

  • Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn).
  • Local history/blaming/...
  • Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff).
  • The staging area, upload what you want/need and keep some work local
  • Smaller checkouts
  • Bot maintainers : Power outage or network interruption in the middle of a svn checkout/up lock the repo sometimes and you need to manually svn cleanup the checkout (maybe someone have a tool or script to avoid that???). I had much more svn locked repos than git dead checkout because of interruptions.
# Patrick Gansterer (7 years ago)

Am 08.03.2012 um 23:30 schrieb Alexis Menard:

On Thu, Mar 8, 2012 at 7:10 PM, Maciej Stachowiak <mjs at apple.com> wrote:

It seems like there are a couple of different issues here that affect how we do version control. Currently we have an SVN primary repository, some contributors use SVN, and others use git via git-svn.

It seems like there are two possible changes we can make, and it is not really clear to me which is being advocated:

1) Offer only a git repository; everyone uses git. 2) Use a git central repository; but some form of svn access is provided (is this even possible?)

And then there is the status quo:

3) Continue doing what we're doing; central repository is svn, but anyone is free to use git and we try to make it convenient to do so.

One interesting asymmetry here is that, while many git users proseltyze git and advocate total removal of svn support from our tools and infrastructure, no one seems to advocate completely removing git support. So I left that option off. There are also other distributed version control systems out there such as Mercurial or Bazaar, but no one seems much in favor of using them for WebKit, so those options are also left off.

If we are to assess these options in a deeper way than just everyone saying what they personally like, we need to identify the pros and cons of options (1) and (2) relative to (3). That's assuming (2) is even possible. It seems like there are at least a few factors to consider:

A) Future quality of life for current git users. B) Future quality of life for current svn users. C) Benefits of the master repository being either git or svn, regardless of what clients are supported. (For example, many folks seem to think human-understandable revision identifiers is a benefit of the master being SVN). D) Cost to the project of maintaining support for two different version control systems.

Git advocates on this thread have mostly focused on convincing svn users how much they'd like using git instead. It seems at least some svn users do not believe their quality of life would improve by switching to git, including some who have actually tried git. No one has really identified what benefits there would be to git users if a change is made. Could someone describe those?

To the global infrastructure :

  • Local history for git. svn log access to the server every time you call that command. Will improve the load of the server.
  • Performance of checkouts/pull as data are send compressed from the server.

*) Easier way to setup local mirrors (for buildbots). See discussion at lists.webkit.org/pipermail/webkit-dev/2012-March/019699.html

# Dirk Pranke (7 years ago)

On Thu, Mar 8, 2012 at 2:37 PM, David Barr <davidbarr at google.com> wrote:

The monotonic labels that Ryosuke desires are known in git language as "generation numbers". If we maintain a canonical linear history going forward, they would also be unique as with Subversion. This could be a good reason to resurrect the relevant thread on the git mailing list.

slightly-offtopic, but I had not heard of "generation numbers" before. Based on a cursory web-learning pass (*), it sounds like they're not quite the same thing as SVN revisions, since SVN revision numers are unique to a repo, and two revisions on two different branches may have the same generation number. Since we do actually keep branches in the master repo, this wouldn't quite be the same (although it might possibly be acceptable). Please correct me if I'm wrong ...

-- Dirk

(*) stackoverflow.com/questions/6702821/git

# Lucas Forschler (7 years ago)

Could someone enlighten me on what this page would look like after a conversion to git?

build.webkit.org/builders/Windows%20Debug%20%28Build%29?numbuilds=100

Lucas

# Aaron Boodman (7 years ago)

I think it would look the same, except for instead of monotonically increasing decimal numbers in the "revision" column, you'd see random hexadecimal ones (typically 6-8 digits long).

# Tor Arne Vestbø (7 years ago)

On 09.03.12 01:36, Aaron Boodman wrote:

I think it would look the same, except for instead of monotonically increasing decimal numbers in the "revision" column, you'd see random hexadecimal ones (typically 6-8 digits long).

It would be possible to use 'git describe' [1] to give something like this:

r-110272-g19c9e9c7

If we tag the initial commit in the repository as 'r'. The number refers to the number of commits after the tag 'r'.

We could optionally tag WebKit versions, and get something like:

v525.19-12345-g19c9e9c7

Meaning 12345 commits after v525.19 was tagged. Doing the latter does not prevent the former, as you can use --match r to force the initial tag.

tor arne

[1] linux.die.net/man/1/git

# Tor Arne Vestbø (7 years ago)

On 08.03.12 22:25, Ryosuke Niwa wrote:

That'll certainly be an improvement. I still dislike git hashes though. If someone implements such a script in webkit-patch and we can automatically assign svn-revision like numbers to all commits, I can be convinced to use git.

Dunno about webkit-patch, but would make sense to roll into update-webkit.

Regarding revision numbers, 'git describe' could help us give a common way to describe revisions with monotonically increasing revision numbers.

tor arne

# Konstantin Tokarev (7 years ago)

08.03.2012, 21:35, "Alexis Menard" <alexis.menard at openbossa.org>:

On Thu, Mar 8, 2012 at 2:32 PM, Konrad Piascik <kpiascik at rim.com> wrote:

It is possible to keep linear history with git. This just requires you to fast forward and rebase before pushing.

But can you enforce in the server? To avoid people to push it by mistake?

You can use Gerrit [1] to enforce linear history.

[1] code.google.com/p/gerrit

# Adam Treat (7 years ago)

With svn up you are just as likely to see a conflict.

# Konstantin Tokarev (7 years ago)

09.03.2012, 18:24, "Adam Treat" <atreat at rim.com>:

With svn up you are just as likely to see a conflict.

And in case of doubtful conflicts you won't be able to revert you tree to it's previous state so easily as with git.

# Ashod Nakashian (7 years ago)

From: David Barr <davidbarr at google.com> To: Ryosuke Niwa <rniwa at webkit.org> Cc: "webkit-dev at lists.webkit.org" <webkit-dev at lists.webkit.org> Sent: Friday, March 9, 2012 2:37 AM Subject: Re: [webkit-dev] Moving to Git?

I think we ought to streamline the git workflow before we start trying to proselytise Subversion users. :)

Can you be more specific? What do you find wanting in the git workflow besides the few cases raised by svn users (such as "svn up" that can be supported in update-webkit)?

I think if we address the main issues raised by the svn users, the current consensus (if representative) seems to point towards an overwhelming support (and demand?) for git over svn. On that point it's reasonable to say that we're heading towards option #1 or #2 of Maciej. As such, I'm humbly proposing the following (hopefully without getting ahead of myself):

A) Address as many of the issues raised by the svn users and streamline their use-cases in the current scripts on top of git that we can (this would leave generation numbers out of scope as it's a git issue, although we can push that on git's mail-list). Address any current issues that (advanced/seasoned) git users find wanting/missing to have a solid system that capitalizes on the powers of git as much as possible.

B) Plan a phase-out schedule for svn repo, servers and scripts and mainlining git (this needs input from ops and those who can assess the overhead involved - something I'm ignorant of). Offer the option of having svn mirror (however realistic that is, I can't tell) keeping in mind the overhead of maintaining the svn scripts.

If we don't do anything we'll be supporting both systems, scripts, docs etc. with little advantage but having the choice of both systems (status-quo). If we start moving towards git I think we'll end up with the reverse situation than what we have now (git mainline, svn mirror) and, assuming the majority use git and there are more benefits to git over svn, then WebKit will benefit more that way than the case is now. However, having said that, something tells me the remaining svn users will probably switch to git sooner rather than later.

(Disclaimer: I enjoy svn as much as the next guy, but I think git offers enough power to justify the overhead of learning/adapting/migrating to it. In addition, as many pointed out, no one has to use all the power features and the svn-equivalent day-to-day ones can be automated transparently by current (and new) scripts.)

# Ryosuke Niwa (7 years ago)

On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian <ashodnakashian at yahoo.com>wrote: >

Can you be more specific? What do you find wanting in the git workflow besides the few cases raised by svn users (such as "svn up" that can be supported in update-webkit)?

I'm also annoyed by now git diff works since I almost always want "git diff master" as I said in another thread. There are a number of other things I don't like about git. Also, I think I'd prefer mercurial over git for its saner behavior and terminologies if we're switching to a different VCS but I'm not about to start a thread for that.

Quite frankly, moving to git will make my workflow worse regardless of improvements... It's like forcing me to use Linux instead of Windows/Mac. I'll do it if the overwhelming majority of the community thinks that's a good thing but I won't be happy about it.

I think if we address the main issues raised by the svn users, the current

consensus (if representative) seems to point towards an overwhelming support (and demand?) for git over svn. On that point it's reasonable to say that we're heading towards option #1 or #2 of Maciej. As such, I'm humbly proposing the following (hopefully without getting ahead of myself):

Frankly, I don't quite understand the benefit of this transition. Do we really need to move to git? If the only problem of keeping svn was about svn-apply being broken, I'm more than happy to fix that script.

A) Address as many of the issues raised by the svn users and streamline

their use-cases in the current scripts on top of git that we can (this would leave generation numbers out of scope as it's a git issue, although we can push that on git's mail-list). Address any current issues that (advanced/seasoned) git users find wanting/missing to have a solid system that capitalizes on the powers of git as much as possible.

I'd argue that generation numbers is a requirement for this transition. Monotonically increasing number is one major benefit of using svn server. Also, ideally, this generation number will be consisnte with the existing svn revision numbers so that if N is the last revision committed to the svn repository then the first commit in the git repository should have the generation number of N+1.

# Konrad Piascik (7 years ago)

There are solutions in git for all of your raised issues. If you want to have git diff work against master then you just need to setup an alias to do that for you. gitready.com/intermediate/2009/02/06/helpful-command-aliases.html

This way you can create aliases for all the commands and syntax you want.

Alexis mentioned that it is possible to have a linear history that Qt uses. It should also be possible to setup a git hook on the server side to modify the commit message and include the revision number.

# Kalle Vahlman (7 years ago)

2012/3/9 Ryosuke Niwa <rniwa at webkit.org>:

On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian <ashodnakashian at yahoo.com> wrote:

I think if we address the main issues raised by the svn users, the current consensus (if representative) seems to point towards an overwhelming support (and demand?) for git over svn. On that point it's reasonable to say that we're heading towards option #1 or #2 of Maciej. As such, I'm humbly proposing the following (hopefully without getting ahead of myself):

Frankly, I don't quite understand the benefit of this transition. Do we really need to move to git? If the only problem of keeping svn was about svn-apply being broken, I'm more than happy to fix that script.

I think you missed the part where the impact on servers was discussed. If every time someone does "svn log" the server needs to not receive or deal out commits, it will show in response times. I'm sure people using svn do not check the log often, for obvious reasons, but it is still a factor to consider.

# Gustavo Noronha Silva (7 years ago)

On Fri, 2012-03-09 at 08:33 -0800, Ryosuke Niwa wrote:

Frankly, I don't quite understand the benefit of this transition. Do we really need to move to git? If the only problem of keeping svn was about svn-apply being broken, I'm more than happy to fix that script.

For me the biggest benefit would be to do away with ChangeLog files, if we come to that by moving to git. I'm otherwise happy with using the git mirror and git svn for all my needs.

# Gustavo Noronha Silva (7 years ago)

On Thu, 2012-03-08 at 19:39 -0300, Alexis Menard wrote:

To svn user :

  • Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn).
  • Local history/blaming/...
  • Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff).
  • The staging area, upload what you want/need and keep some work local
  • Smaller checkouts
  • Bot maintainers : Power outage or network interruption in the middle of a svn checkout/up lock the repo sometimes and you need to manually svn cleanup the checkout (maybe someone have a tool or script to avoid that???). I had much more svn locked repos than git dead checkout because of interruptions.

/me puts his bot maintainer hat on

That does suck indeed. Been a while since I had to manually intervene, but even when it is fixed automatically, the new checkout takes ages (because the automatic fix is to rm -rf the whole source tree).

That said, we don't need to change the main repository to have bots use git - we can use a git mirror for most bot needs without changing the main repository.

# Mark Rowe (7 years ago)

On 2012-03-09, at 10:23, Gustavo Noronha Silva <gns at gnome.org> wrote:

On Thu, 2012-03-08 at 19:39 -0300, Alexis Menard wrote:

To svn user :

  • Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn).
  • Local history/blaming/...
  • Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff).
  • The staging area, upload what you want/need and keep some work local
  • Smaller checkouts
  • Bot maintainers : Power outage or network interruption in the middle of a svn checkout/up lock the repo sometimes and you need to manually svn cleanup the checkout (maybe someone have a tool or script to avoid that???). I had much more svn locked repos than git dead checkout because of interruptions.

/me puts his bot maintainer hat on

That does suck indeed. Been a while since I had to manually intervene, but even when it is fixed automatically, the new checkout takes ages (because the automatic fix is to rm -rf the whole source tree).

The solution for this would be to teach buildbot run 'svn cleanup' when necessary rather than just assuming the worst and nuking the working copy. This will become trivial to do in future versions of Buildbot as they're moving the logic for how version control operations to the server rather than the slaves, meaning it becomes much easier to update and customize.

# Mark Rowe (7 years ago)

On 2012-03-08, at 14:30, Alexis Menard <alexis.menard at openbossa.org> wrote:

To the global infrastructure :

  • Performance of checkouts/pull as data are send compressed from the server.

Do you have any concrete data on this?

To git user :

  • Using git push rather than having to use git-svn (which you need to keep in sync).

I'm not sure that running 'git push' is that big a benefit to a git user over running 'git svn dcommit'.

  • Simplified workflow, we don't need to mess with git-svn.

Can you clarify in what ways you see this as simplifying workflow? I currently use git-svn myself and it's not obvious to me what you mean by this.

# Mark Rowe (7 years ago)

On 2012-03-09, at 09:15, Kalle Vahlman <kalle.vahlman at gmail.com> wrote:

2012/3/9 Ryosuke Niwa <rniwa at webkit.org>:

On Fri, Mar 9, 2012 at 7:14 AM, Ashod Nakashian <ashodnakashian at yahoo.com> wrote:

I think if we address the main issues raised by the svn users, the current consensus (if representative) seems to point towards an overwhelming support (and demand?) for git over svn. On that point it's reasonable to say that we're heading towards option #1 or #2 of Maciej. As such, I'm humbly proposing the following (hopefully without getting ahead of myself):

Frankly, I don't quite understand the benefit of this transition. Do we really need to move to git? If the only problem of keeping svn was about svn-apply being broken, I'm more than happy to fix that script.

I think you missed the part where the impact on servers was discussed. If every time someone does "svn log" the server needs to not receive or deal out commits, it will show in response times. I'm sure people using svn do not check the log often, for obvious reasons, but it is still a factor to consider.

Making operations like 'log' not hit the server would obviously be nice, but the vast majority of the load on the Subversion server is from update or checkout operations. Do you have a pointer to any concrete data about the relative load on a server for Git vs Subversion in terms of these operations?

Thanks,

# Mark Rowe (7 years ago)

On 2012-03-09, at 07:14, Ashod Nakashian <ashodnakashian at yahoo.com> wrote:


From: David Barr <davidbarr at google.com> To: Ryosuke Niwa <rniwa at webkit.org> Cc: "webkit-dev at lists.webkit.org" <webkit-dev at lists.webkit.org> Sent: Friday, March 9, 2012 2:37 AM Subject: Re: [webkit-dev] Moving to Git?

I think we ought to streamline the git workflow before we start trying to proselytise Subversion users. :)

Can you be more specific? What do you find wanting in the git workflow besides the few cases raised by svn users (such as "svn up" that can be supported in update-webkit)?

I think if we address the main issues raised by the svn users, the current consensus (if representative) seems to point towards an overwhelming support (and demand?) for git over svn.

What you'll find is that the vast majority of SVN users are simply not participating in this email thread. You'll also find that many people that use git-svn are happy enough with the status quo since it gives those who chose to use it most of the benefits of a pure Git setup without forcing it on others.

In my opinion a substantial benefit needs to be demonstrated in order to convince the existing SVN users, many of which are substantial long-term contributors to the project, that it's worth it to them to relearn how to contribute to WebKit. And I do feel that SVN users need to want to switch to Git in order for it to be worth pursuing such a switch. As a heavy Git user myself I've not seen any arguments in this thread that would be convincing to someone not already familiar with Git.

# Maciej Stachowiak (7 years ago)

Here's my thoughts based on this and other comments

On Mar 8, 2012, at 2:30 PM, Alexis Menard wrote:

To the global infrastructure :

  • Local history for git. svn log access to the server every time you call that command. Will improve the load of the server.
  • Performance of checkouts/pull as data are send compressed from the server.

Sounds like there is some potential benefit here, though we might want to explore beefing up the servers before changing the tools.

To git user :

  • Using git push rather than having to use git-svn (which you need to keep in sync).
  • Simplified workflow, we don't need to mess with git-svn.
  • Companies who fork (we all do) can simplify their workflow a bit regarding branches.

It sounds like avoiding use of git-svn is the big benefit to git users and perhaps the reason this topic periodically comes up. Can anyone spell out in more detail the benefits of using straight git instead of git-svn?

To svn user :

  • Conflict resolving much easier and performant than svn (we have drivers for changelogs and the default one are much better than svn).
  • Local history/blaming/...
  • Proper diff coloration (though I'm sure you guys have some magic scripts using colordiff).
  • The staging area, upload what you want/need and keep some work local
  • Smaller checkouts

So far many SVN users haven't found these benefits to exceed the switching cost, though perhaps more will be inspired to give git a try by this thread.

# Adam Treat (7 years ago)

Would be good to know who the remaining svn users are. And who is using git/git-svn now. I'd love to see the breakdown. Data is good.

# Gustavo Noronha Silva (7 years ago)

On Fri, 2012-03-09 at 13:43 -0800, Maciej Stachowiak wrote:

  • Simplified workflow, we don't need to mess with git-svn.
  • Companies who fork (we all do) can simplify their workflow a bit regarding branches.

It sounds like avoiding use of git-svn is the big benefit to git users and perhaps the reason this topic periodically comes up. Can anyone spell out in more detail the benefits of using straight git instead of git-svn?

I am a git user, I use git-svn for all my commits and I tend to use git for every project I create myself outside of WebKit. I see lots of benefits to using git over svn. However, for a project like WebKit I think there's really no reason to use git other than people feeling good about removing git-svn from their systems.

I tend to think there is little or no benefit to switching to git while keeping all of the project workflow in place. The fact that we would want to keep a simple history with no merges in it pretty much defeat any benefit that could be had. I think using git only makes sense if we adopt git workflows, which would mean people would post git branches for review instead of patches, and those branches would then get merged.

The one point I think makes a lot of sense to investigate is tools. People who are maintaining the awesome tools we use today have been doing a great job of making them work for both git and svn users, but it's probably a big burden for them. So, if people declare that some tools will only work with git work directories, I'd be fine with it, would anyone oppose? We can keep using svn as the central server, but people wanting to use those tools would have to use git-svn.

Tbh, I am much more interested in doing away with ChangeLogs than in feeling good about using git push instead of git svn dcommit. If we could find a way around ChangeLogs while keeping svn, then I would be an even happier panda than I am today =).

# noam.rosenthal at nokia.com (7 years ago)

On Mar 9, 2012, at 1:43 PM, ext Maciej Stachowiak wrote:

It sounds like avoiding use of git-svn is the big benefit to git users and perhaps the reason this topic periodically comes up. Can anyone spell out in more detail the benefits of using straight git instead of git-svn?

My main pain point with the current workflow, which can potentially be repaired by using a real git workflow, is the manual changelog editing, rather than using commit messages. With a git workflow we can review commit messages as part of the regular review process, which I understand we can't do with SVN (though I don't know SVN that well).

Wouldn't a world without manual changelog editing be slightly nicer?

# Geoffrey Garen (7 years ago)

I'm starting to see a mathematical relationship between (a) Volume of contribution to the WebKit OpenSource Project (b) Volume of advocacy for removing svn support from the WebKit OpenSource Project

The relationship seems to be of the inverse variety.

In your case, Ashod:

Source> find . -name ChangeLog* | xargs grep "Nakashian" | wc -l 2

Geoff

# Emil A Eklund (7 years ago)

On Fri, Mar 9, 2012 at 14:46, Adam Treat <atreat at rim.com> wrote:

Would be good to know who the remaining svn users are. And who is using git/git-svn now. I'd love to see the breakdown. Data is good.

I'm another svn user and while I'd prefer to keep using svn I'm not opposed to migrating to git if that is what the majority wants. Maintaining both certainly seems undesirable in the long run.

-- Emil

# Pablo Flouret (7 years ago)

On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva <gns at gnome.org>

wrote:

I tend to think there is little or no benefit to switching to git while keeping all of the project workflow in place. The fact that we would want to keep a simple history with no merges in it pretty much defeat any benefit that could be had. I think using git only makes sense if we adopt git workflows, which would mean people would post git branches for review instead of patches, and those branches would then get merged.

I agree. I've lived through a large-scale git migration (from CVS, though, so it
had literally zero opposition from people, the big issue was
infrastructure constraints), and one of the greatest benefits was the
breadth of workflows git allows to choose from, so if people are mostly
happy with the current workflow, then "if it ain't broke, don't fix it"
probably applies.

Otherwise, the question might be how much easier would it be to experiment
with new workflows if we got rid of subversion altogether. Or if people
want to think about new workflows at all, for that matter.

Tbh, I am much more interested in doing away with ChangeLogs than in feeling good about using git push instead of git svn dcommit. If we could find a way around ChangeLogs while keeping svn, then I would be an even happier panda than I am today =).

+1

# Ashod Nakashian (7 years ago)

----- Original Message -----

From: Geoffrey Garen <ggaren at apple.com> To: Ashod Nakashian <ashodnakashian at yahoo.com> Cc: David Barr <davidbarr at google.com>; Ryosuke Niwa <rniwa at webkit.org>; WebKit Development <webkit-dev at lists.webkit.org> Sent: Saturday, March 10, 2012 2:58 AM Subject: Re: [webkit-dev] Moving to Git?

I'm starting to see a mathematical relationship between (a) Volume of contribution to the WebKit OpenSource Project (b) Volume of advocacy for removing svn support from the WebKit OpenSource Project

The relationship seems to be of the inverse variety.

In your case, Ashod:

Source> find . -name ChangeLog* | xargs grep "Nakashian" | wc -l 2

I'm sorry if I don't see why this is a good argument. Is there a prerequisite for resurrecting a healthy discussion on a topic that is obviously of interest to many active contributes that I'm not aware of?

After all, what prompted me to raise this issue is because some svn scripts are outdated and before fixing them I thought may be there wasn't much use for them in the first place (otherwise, someone with a bigger contribution volume would certainly have noticed and fixed them sooner than me).

# Ryosuke Niwa (7 years ago)

First, a follow up on my old post since my message was cut off in the middle: On Thu, Mar 8, 2012 at 1:25 PM, Ryosuke Niwa <rniwa at webkit.org> wrote: >

On Thu, Mar 8, 2012 at 1:19 PM, Joe Mason <jmason at rim.com> wrote:

This is only slightly more complicated

I'd say astoundingly more complicated because of

the fact that you're unapplying changes, updating the checkout, and reapplying changes. This seemingly innocent sequence of operations have an annoying side-effects of touching all files you've modified locally and haven't committed.

So for example if you have any changes to Node.h and run this set of operations, then git will touch Node.h twice by stashing and applying. This would mean that I would be rebuilding the world even if all changes I get from masters were in webkitpy or LayoutTests.

Are there an easy way to work around this issue as well? (other than committing changes, of course)

On Fri, Mar 9, 2012 at 3:54 PM, Ashod Nakashian <ashodnakashian at yahoo.com>wrote: >

After all, what prompted me to raise this issue is because some svn scripts are outdated and before fixing them I thought may be there wasn't much use for them in the first place (otherwise, someone with a bigger contribution volume would certainly have noticed and fixed them sooner than me).

I suspect the only reason the particular bug hadn't been fixed is that we have very few contributors who develop on Windows.

# David Levin (7 years ago)

On Fri, Mar 9, 2012 at 4:01 PM, Ryosuke Niwa <rniwa at webkit.org> wrote:

git will touch Node.h twice by stashing and applying. This would mean that I would be rebuilding the world even if all changes I get from masters were in webkitpy or LayoutTests.

Are there an easy way to work around this issue as well? (other than committing changes, of course)

afaik not really, here's two that I've used:

  1. git-new-workdir (multiple git working dirs so I don't switch branches as often)
  2. ccache (cache the results of the compile)
# Ryosuke Niwa (7 years ago)

On Mar 9, 2012 3:16 PM, "Pablo Flouret" <pablof at motorola.com> wrote: >

On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva <gns at gnome.org>

wrote:

Tbh, I am much more interested in doing away with ChangeLogs than in feeling good about using git push instead of git svn dcommit. If we could find a way around ChangeLogs while keeping svn, then I would be an even happier panda than I am today =).

+1

We can do this without moving to git. Here's how it might work:

  1. When writing a patch, add a new temporary file e.g. ChangeLogEntry that stores new change log entry in each directory where ChangeLogs are located.
  2. ChangeLogEntry files are added to git/svn checkouts
  3. Upload the patch (including ChangeLogEntry) for a review. Bugzilla shows ChangeLogEntry filesas new files (can be tweeked,of course)
  4. Once you get r+, you land the patch. The commit message editor will automatically find ChangeLogEntry files and aggregate the result as the commit message.
  5. You commit. The commit hook ensures no ChangeLogEntry files are actually committed into the svn repository.
# Pablo Flouret (7 years ago)

On Fri, 09 Mar 2012 17:55:59 -0800, Ryosuke Niwa <rniwa at webkit.org> wrote:

On Mar 9, 2012 3:16 PM, "Pablo Flouret" <pablof at motorola.com> wrote: >

On Fri, 09 Mar 2012 14:47:17 -0800, Gustavo Noronha Silva

<gns at gnome.org> wrote:

Tbh, I am much more interested in doing away with ChangeLogs than in feeling good about using git push instead of git svn dcommit. If we could find a way around ChangeLogs while keeping svn, then I would be
an even happier panda than I am today =).

+1

We can do this without moving to git. Here's how it might work:

  1. When writing a patch, add a new temporary file e.g. ChangeLogEntry
    that stores new change log entry in each directory where ChangeLogs are
    located.
  2. ChangeLogEntry files are added to git/svn checkouts
  3. Upload the patch (including ChangeLogEntry) for a review. Bugzilla
    shows ChangeLogEntry filesas new files (can be tweeked,of course)
  4. Once you get r+, you land the patch. The commit message editor will automatically find ChangeLogEntry files and aggregate the result as the commit message.
  5. You commit. The commit hook ensures no ChangeLogEntry files are
    actually committed into the svn repository.

That doesn't sound like much of an improvement.

I'd prefer to see something closer to what 'git format-patch' spits out. Basically you give it a commit range and it spits out one diff per commit,
including the commit message.

This gives a couple of interesting options, like having a single patch
which can contain multiple commits. Or you can do some mangling like
webkit-patch does today to take a commit-range diff and pretend that it's
a single commit. I imagine it shouldn't be too hard to replicate the format for someone
using just svn. A tool's UI for editing the commit message for svn users (or for the
squash case) could somewhat mirror what the git rebase ui does for
squashing. So you'd have a patch that includes commit messages ready for
reviewers' perusal (which i presume is the biggest reason changelogs still
exist?)

In my most frequent workflow i make a patch, submit it, make a local
commit in git for myself (in a branch) and then move on to other things
(in a different branch perhaps). Then when review comments come in, i
address them, make a local commit with those changes, and upload a patch
by giving a range to webkit-patch. ChangeLog files are a pain in the ass
in this case. Also, reviewers don't get to see what changed between the
two patches i uploaded, which a patch coming from format-patch would show.
A final, squashed patch could be required for landing. Or both types could
be submitted through webkit-patch and available in bugzilla. Or something
else.

Anyway, just brainstorming a bit, haven't thought this through that much.

# Kalle Vahlman (7 years ago)

2012/3/9 Mark Rowe <mrowe at apple.com>: >

On 2012-03-09, at 09:15, Kalle Vahlman <kalle.vahlman at gmail.com> wrote:

2012/3/9 Ryosuke Niwa <rniwa at webkit.org>:

Frankly, I don't quite understand the benefit of this transition. Do we really need to move to git? If the only problem of keeping svn was about svn-apply being broken, I'm more than happy to fix that script.

I think you missed the part where the impact on servers was discussed. If every time someone does "svn log" the server needs to not receive or deal out commits, it will show in response times. I'm sure people using svn do not check the log often, for obvious reasons, but it is still a factor to consider.

Making operations like 'log' not hit the server would obviously be nice, but the vast majority of the load on the Subversion server is from update or checkout operations. Do you have a pointer to any concrete data about the relative load on a server for Git vs Subversion in terms of these operations?

I'm afraid not, just bits and pieces about performance and bandwidth usage that mostly amount just to a gut feeling.

Googling also turned up zero studies from server POV. As said there is some evidence that repository size is reduced and that network bandwidth usage can be better with git, but considering how different workflows can emerge at least the bandwidth usage can not be mapped 1:1 to actual deployment.

Another consideration here is that git-svn can be rather abusive for the server if used wrong, so if svn is no longer the central VCS that use case will also vanish, further changing the usage patterns.

The only way to truly know would be to have graphs from a server that hosted similar class project using svn then switched to git (or vice versa!) and even then it would be dependent on the workflows used...

# Gavin Barraclough (7 years ago)

On Mar 9, 2012, at 12:30 PM, Mark Rowe wrote:

What you'll find is that the vast majority of SVN users are simply not participating in this email thread. You'll also find that many people that use git-svn are happy enough with the status quo since it gives those who chose to use it most of the benefits of a pure Git setup without forcing it on others.

In my opinion a substantial benefit needs to be demonstrated in order to convince the existing SVN users, many of which are substantial long-term contributors to the project, that it's worth it to them to relearn how to contribute to WebKit. And I do feel that SVN users need to want to switch to Git in order for it to be worth pursuing such a switch. As a heavy Git user myself I've not seen any arguments in this thread that would be convincing to someone not already familiar with Git.

I think Mark makes a couple of very good points here.

As an svn user, I'm under no illusion about the fact that git is clearly a more powerful tool, and that it's important that we support git access for contributors who need it. However I find that personally I work much more efficiently in svn – my needs are modest and I find git overly complex for my very simple requirements. I would be happy to give greater consideration to moving to git if it would significantly benefit either me or the project as a whole for me to do so.

Reading through this thread, it's not obvious to me that accommodating both svn and git users is a huge burden on the project. I hope this is the case, because I have to say, the status quo seems pretty good (which isn't to say there aren't ways we could improve our processes – there are a few good suggestions in this thread). It seems beneficial to the project to accommodate the needs of a wide range of contributors as well as we reasonable can, and it seems that we are in a fortunate position with regard to version control where we are already doing so very well. I would hope this would only change if there were good reason to do so.

# Joe Mason (7 years ago)

Well, the more git-idiomatic usage is to "git commit" your work in progress often, in particular before updating. This wouldn't touch Node.h at all, it just upates the index (in the .git hidden subdir). Then the rebase also wouldn't touch Node.h, unless there were changes to it upstream.

I just recommended the stash/update/pop sequence because it more closely matched the SVN workflow which you like, and I'm trying to figure out how hard it would be to support this workflow with git. I hadn't thought about the issue of extra file touches, though - good catch.

Here's a better alternative:

git commit -a -c "temp commit" && git pull --rebase origin/master (fix any conflicts and finish the rebase with git rebase --continue if necessary) git reset HEAD^

Instead of using the stash, that puts all your working copy changes into a commit, fetches, and then gets rid of the commit (leaving the changes still in the working copy). There might be some weirdness if there are new files/subdirs instead of just changes to existing files - I'd need to check how that gets handled and possibly tweak some commandline parameters.

# Maciej Stachowiak (7 years ago)

I think one factor that makes many people stick with SVN is that emulating the SVN-style workflow in Git is pretty complicated. Let's consider a typical SVN user's process:

1) Develop one patch at a time. 2) During development, often update his sources to match the repository. 3) When done, create a patch and get it reviewed. 4) When the patch is reviewed, commit it.

The interaction with the version-control system for each of these steps is an obvious single step with SVN. With git, for at least some of these, you will end up needing multiple non-obvious (to an SVN user anyway) commands. All of your examples below for step 2 are complicated and have surprising side effects.

The usual responses to this concern are either "you can write a script to wrap that" or "you should just change your workflow to get the full power of git". But neither of these answers is very persuasive to a person happy with the above workflow. When we had to do the CVS to SVN transition, there was no hesitation because everyone could still use the exact same workflow, but now it was also possible to do more stuff.

I do think that with the right project-wide scripts we could abstract away from the VCS a little and make the transition less painful. I do most of my patch creation and committing with webkit-patch(*) these days, because it actually saves steps over the raw tools. However, update-webkit, which handles the remaining SVN-like workflow step, doesn't follow any of the approaches, instead it does this:

sub runGitUpdate() {

# Doing a git fetch first allows setups with svn-remote.svn.fetch = trunk:refs/remotes/origin/master
# to perform the rebase much much faster.
system("git", "fetch") == 0 or die;
if (isGitSVN()) {
    system("git", "svn", "rebase") == 0 or die;
} else {
    # This will die if branch.$BRANCHNAME.merge isn't set, which is
    # almost certainly what we want.
    system("git", "pull") == 0 or die;
}

}

Perhaps improving runGitUpdate() would be one way to make it easier for more people to try Git.

Regards, Maciej

(*) I'm not sure offhand if webkit-patch land will take care of all three of the steps of adding, committing and pushing/dcommiting which the SVN-like workflow treats as a single step.

# Kalle Vahlman (7 years ago)

2012/3/11 Maciej Stachowiak <mjs at apple.com>: >

The interaction with the version-control system for each of these steps is an obvious single step with SVN. With git, for at least some of these, you will end up needing multiple non-obvious (to an SVN user anyway) commands.

I understand the context of this argument and it is of course valid but it gets REALLY boring to hear this every time someone tries to make a point :)

I've used svn long time ago and git ever since. For me it's no longer obvious that my local changes are not "safe" from merging if I do an update. It is also not obvious that I could not simply commit my patch (locally) and continue on to the next one when the changes are touching the same files etc.

The 'obvious' argument should IMO be avoided at all times, because it inherently carries the notion that the svn way is somehow the de facto way of doing things in everybody's minds. It is not. It is always subjective what workflow makes sense.

# Maciej Stachowiak (7 years ago)

On Mar 10, 2012, at 9:55 PM, Kalle Vahlman wrote:

2012/3/11 Maciej Stachowiak <mjs at apple.com>:

The interaction with the version-control system for each of these steps is an obvious single step with SVN. With git, for at least some of these, you will end up needing multiple non-obvious (to an SVN user anyway) commands.

I understand the context of this argument and it is of course valid but it gets REALLY boring to hear this every time someone tries to make a point :)

I've used svn long time ago and git ever since. For me it's no longer obvious that my local changes are not "safe" from merging if I do an update. It is also not obvious that I could not simply commit my patch (locally) and continue on to the next one when the changes are touching the same files etc.

The 'obvious' argument should IMO be avoided at all times, because it inherently carries the notion that the svn way is somehow the de facto way of doing things in everybody's minds. It is not. It is always subjective what workflow makes sense.

I think we largely agree here. Some people find the SVN workflow subjectively makes sense to them. Others find that the Git workflow subjectively makes sense to them. They are different enough that not everyone finds it natural to switch. Conveniently, we support both.

# Ryosuke Niwa (7 years ago)

On Fri, Mar 9, 2012 at 6:35 PM, Pablo Flouret <pablof at motorola.com> wrote: >

I'd prefer to see something closer to what 'git format-patch' spits out. Basically you give it a commit range and it spits out one diff per commit, including the commit message.

That seems to imply we're completely changing the semantics and the format of change logs. I'd rather not get into such a discussion on this thread, and I think that's a much more controversial change.

So you'd have a patch that includes commit messages ready for reviewers'

perusal (which i presume is the biggest reason changelogs still exist?)

Please go through the webkit-dev archive before in the past 3 years :)

In my most frequent workflow i make a patch, submit it, make a local commit

in git for myself (in a branch) and then move on to other things (in a different branch perhaps). Then when review comments come in, i address them, make a local commit with those changes, and upload a patch by giving a range to webkit-patch. ChangeLog files are a pain in the ass in this case. Also, reviewers don't get to see what changed between the two patches i uploaded, which a patch coming from format-patch would show.

Being able to see changes between two patches will be a very valuable tool. I always open two review pages side-by-side to see what has changed in new patch. However, such a review tool can be implemented on Bugzilla without moving to git.

In fact, the diff's between two local git commits is of little use for me as a reviewer because what I want to see is the diff between the latest patch and the last patch I looked at.

# Ashod Nakashian (7 years ago)

From: Ryosuke Niwa <rniwa at webkit.org> To: Pablo Flouret <pablof at motorola.com> Cc: webkit-dev at lists.webkit.org Sent: Sunday, March 11, 2012 12:01 PM Subject: Re: [webkit-dev] Moving to Git?

On Fri, Mar 9, 2012 at 6:35 PM, Pablo Flouret <pablof at motorola.com> wrote: I'd prefer to see something closer to what 'git format-patch' spits out.

Basically you give it a commit range and it spits out one diff per commit, including the commit message.

That seems to imply we're completely changing the semantics and the format of change logs. I'd rather not get into such a discussion on this thread, and I think that's a much more controversial change.

So you'd have a patch that includes commit messages ready for reviewers' perusal (which i presume is the biggest reason changelogs still exist?) >

Please go through the webkit-dev archive before in the past 3 years :)

In my most frequent workflow i make a patch, submit it, make a local commit in git for myself (in a branch) and then move on to other things (in a different branch perhaps). Then when review comments come in, i address them, make a local commit with those changes, and upload a patch by giving a range to webkit-patch. ChangeLog files are a pain in the ass in this case. Also, reviewers don't get to see what changed between the two patches i uploaded, which a patch coming from format-patch would show.

Being able to see changes between two patches will be a very valuable tool. I always open two review pages side-by-side to see what has changed in new patch. However, such a review tool can be implemented on Bugzilla without moving to git.

In fact, the diff's between two local git commits is of little use for me as a reviewer because what I want to see is the diff between the latest patch and the last patch I looked at.

There certainly are review tools that do exactly that. ReviewBoard[1] is one such that I'm thoroughly familiar with. It has a solid API that can be used in a very similar way to how we're uploading patches on bugzilla, automated mail notifications etc. and can be integrated with bugzilla/build-servers with reasonable effort. In addition, it shows all patches uploaded with diff between any two, which is what a reviewer is mostly interested in: to see what changed between patches and if her issues were addressed properly or not.

I totally agree that these are completely independent of the VCS and can (should?) be utilized where appropriate independent of the topic at hand.

[1] www.reviewboard.org

# Bug Tracker (3 days ago)

I was curious about the status of the proposal for migrating from SVN to Git (trac.webkit.org/wiki/Moving%20to%20Git).

The relevant page on the Trac wiki hasn't been updated for over 5 years and since then Git has become much more popular (the de facto standard for new projects, more or less), while:

  • SVN support is diminishing (e.g. in Xcode).

  • Git support on Windows is much better than 5 years ago.

  • It's difficult to find free robust SVN clients / UIs, unlike the plethora of options available for Git.

  • Most young and relatively new developers (with less than 10 years of experience, like myself) are much more comfortable with Git and maybe have not even used SVN before, so moving to Git could encourage more users and contributors.

Is there any progress in this direction?

Thank you, in advance!

# Ryosuke Niwa (3 days ago)

On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker < bug.tracking.account at protonmail.com> wrote:

I was curious about the status of the proposal for migrating from SVN to Git (trac.webkit.org/wiki/Moving%20to%20Git).

The relevant page on the Trac wiki hasn't been updated for over 5 years and since then Git has become much more popular (the de facto standard for new projects, more or less), while:

  1. SVN support is diminishing (e.g. in Xcode).
  2. Git support on Windows is much better than 5 years ago.
  3. It's difficult to find free robust SVN clients / UIs, unlike the plethora of options available for Git.
  4. Most young and relatively new developers (with less than 10 years of experience, like myself) are much more comfortable with Git and maybe have not even used SVN before, so moving to Git could encourage more users and contributors.

Is there any progress in this direction?

No progress has been made as far as I can tell. Every other year or so, this topic comes up on webkit-dev, and the outcome is always the same.

We need a monotonically increasing revision number to track down perf regressions, etc... yet nobody has put the time & effort to create a solution with Git. I stay firmly opposed to making the Subversion-to-Git transition until such a solution is devised and implemented in various tools we use.

And no, we can't use git-bisect because performance tests take anywhere from 30min to an hour, and we may need ~8 runs to detect a statistically significant difference of 1% or less, meaning that even deciding whether a given perf regression exists between revision X and Y might take ~8 hours.

I'm increasingly frustrated that people keep bringing this topic up without ever resolving the issues that have been raised in the past. Keep bringing up the same topic without presenting a solution to the problems that have been raised in the past 8 years or so of the discussion is simply unproductive.

  • R. Niwa
# Philippe Normand (3 days ago)

On Wed, 2019-02-20 at 09:40 -0800, Ryosuke Niwa wrote:

On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker < bug.tracking.account at protonmail.com> wrote:

I was curious about the status of the proposal for migrating from SVN to Git (trac.webkit.org/wiki/Moving%20to%20Git).

The relevant page on the Trac wiki hasn't been updated for over 5 years and since then Git has become much more popular (the de facto standard for new projects, more or less), while: SVN support is diminishing (e.g. in Xcode). Git support on Windows is much better than 5 years ago. It's difficult to find free robust SVN clients / UIs, unlike the plethora of options available for Git. Most young and relatively new developers (with less than 10 years of experience, like myself) are much more comfortable with Git and maybe have not even used SVN before, so moving to Git could encourage more users and contributors.

Is there any progress in this direction?

No progress has been made as far as I can tell. Every other year or so, this topic comes up on webkit-dev, and the outcome is always the same.

We need a monotonically increasing revision number to track down perf regressions, etc... yet nobody has put the time & effort to create a solution with Git.

Quoting the wiki page linked above:

Some previously svn projects have worked around this. For example, Haiku uses automatic linear tags on each push. cgit.haiku-os.org/haiku/log

Philippe

# Ryosuke Niwa (3 days ago)

On Wed, Feb 20, 2019 at 10:02 AM Philippe Normand <philn at igalia.com> wrote:

On Wed, 2019-02-20 at 09:40 -0800, Ryosuke Niwa wrote: >

On Wed, Feb 20, 2019 at 8:28 AM Bug Tracker < bug.tracking.account at protonmail.com> wrote:

I was curious about the status of the proposal for migrating from SVN to Git (trac.webkit.org/wiki/Moving%20to%20Git).

The relevant page on the Trac wiki hasn't been updated for over 5 years and since then Git has become much more popular (the de facto standard for new projects, more or less), while: SVN support is diminishing (e.g. in Xcode). Git support on Windows is much better than 5 years ago. It's difficult to find free robust SVN clients / UIs, unlike the plethora of options available for Git. Most young and relatively new developers (with less than 10 years of experience, like myself) are much more comfortable with Git and maybe have not even used SVN before, so moving to Git could encourage more users and contributors.

Is there any progress in this direction?

No progress has been made as far as I can tell. Every other year or so, this topic comes up on webkit-dev, and the outcome is always the same.

We need a monotonically increasing revision number to track down perf regressions, etc... yet nobody has put the time & effort to create a solution with Git.

Quoting the wiki page linked above:

Some previously svn projects have worked around this. For example, Haiku uses automatic linear tags on each push. cgit.haiku-os.org/haiku/log

Right, I'm totally aware of that solution because it has come up in the past. Chromium implemented a similar solution (presumably Cr-Commit-Position is that thing?).

What we need is a concrete plan to add the support for such a mechanism in WebKit and update all the tools we have: buildbot, webkitpy, etc...

As far as I can tell, nobody has yet to propose such a plan for WebKit. THAT is the biggest blocker as far as I can tell.

  • R. Niwa
# Simon Fraser (3 days ago)

Are you a WebKit developer? I can't tell from your email.

Simon

# Bug Tracker (3 days ago)

Sorry, for the anonymous email. I opted for it because the list archives are public and concluded that it's not that useful to reveal my identity for the purposes of this question.

In short, however, I am a graduate student interested in using WebKit for an academic project and thought that I should ask first about the progress on Git migration, since it would be far easier for me to work with WebKit then.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

# Konstantin Tokarev (3 days ago)

20.02.2019, 22:27, "Bug Tracker" <bug.tracking.account at protonmail.com>:

Sorry, for the anonymous email. I opted for it because the list archives are public and concluded that it's not that useful to reveal my identity for the purposes of this question.

In short, however, I am a graduate student interested in using WebKit for an academic project and thought that I should ask first about the progress on Git migration, since it would be far easier for me to work with WebKit then.

You can use public Git mirror:

WebKit/webkit

# Bug Tracker (3 days ago)

I considered this option, but my work will involve touching multiple parts of the codebase and thus I would like to be able to keep up / merge locally with the upstream every now and then (e.g. on each relatively stable release, such as Apple's Safari Technology Preview).

However, all branches, tags etc. are available only on SVN.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

# Michael Catanzaro (3 days ago)

FWIW, it's not hard to enforce fast-forward merges with a git hook; that way, we can guarantee that the history has no merge commits and is fully linear. GitLab has built-in support to enforce this for merge requests (though not for direct commits). I agree that linear history is a must for a project the size of WebKit. rNNNNNN tags would be nice, but hardly essential as long as the history is linear.

On Wed, Feb 20, 2019 at 1:38 PM, Bug Tracker

<bug.tracking.account at protonmail.com> wrote:

I considered this option, but my work will involve touching multiple parts of the codebase and thus I would like to be able to keep up / merge locally with the upstream every now and then (e.g. on each relatively stable release, such as Apple's Safari Technology Preview).

However, all branches, tags etc. are available only on SVN.

Migrating to git would be wonderful, but a huge amount of infrastructure effort. Since it's unlikely that anyone is going to invest the large amount of effort required to transition WebKit to git anytime soon, I'd recommend learning how to work with git-svn. It's a bit of effort but not too hard, and way better than using Subversion directly.

Michael

# Maciej Stachowiak (3 days ago)

On Feb 20, 2019, at 12:14 PM, Michael Catanzaro <mcatanzaro at igalia.com> wrote:

FWIW, it's not hard to enforce fast-forward merges with a git hook; that way, we can guarantee that the history has no merge commits and is fully linear. GitLab has built-in support to enforce this for merge requests (though not for direct commits). I agree that linear history is a must for a project the size of WebKit. rNNNNNN tags would be nice, but hardly essential as long as the history is linear.

I think our concern is not just linearity. The reason Ryosuke suggests monotonically increasing revisions is because we often need to answer questions like the following:

  • This performance graph shows a regression between revision A and revision B, I wonder how many revisions are between those?
  • I need to manually bisect a regression between revisions X and Y. I wonder what the approximate midpoint is?

Monotonically increasing sequential numbers make it super easy to answer questions like that. Ideally, such revision numbers would also be accepted by all tools we have to work with. Many git revision number solutions I have seen involve running an extra tool or consulting an additional website to be able to make determinations like this, and that would be a significant task on performance regression defense in particular.

We’d love to hear about solutions that can provide something like this, ideally ones that are GitHub compatible.

# Adrian Perez de Castro (3 days ago)

On Wed, 20 Feb 2019 22:30:22 +0300, Konstantin Tokarev <annulen at yandex.ru> wrote:

20.02.2019, 22:27, "Bug Tracker" <bug.tracking.account at protonmail.com>:

Sorry, for the anonymous email. I opted for it because the list archives are public and concluded that it's not that useful to reveal my identity for the purposes of this question.

In short, however, I am a graduate student interested in using WebKit for an academic project and thought that I should ask first about the progress on Git migration, since it would be far easier for me to work with WebKit then.

You can use public Git mirror:

WebKit/webkit

You can even do upstream WebKit development using exclusively Git, even without needing to use the GitHub mirror, see:

trac.webkit.org/wiki/UsingGitWithWebKit#Checkout

Even for things which would normally require Subversion, “git svn” can be used 99.9% of the time. For the usual “pull latest code from master, make a branch, prepare a patch, upload patch to Bugzilla for landing” Subversion is not needed at all. Just make sure you have 20 to 30 GiB of space for the Git checkout and building WebKit.

For other more specialized workflows, like checking out release branches and version tags you will need some “git svn” usage; but IMO that is still nicer than having to use Subversion.

I hope this helps!

-Adrián

# Bug Tracker (3 days ago)

Thank you all very much for your help! I really appreciate it. :-)

P.S.: I decided to start learning git-svn.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

# Simon Fraser (2 days ago)

On Feb 21, 2019, at 12:18 AM, Bug Tracker <bug.tracking.account at protonmail.com> wrote:

Thank you all very much for your help! I really appreciate it. :-)

P.S.: I decided to start learning git-svn.

trac.webkit.org/wiki/UsingGitWithWebKit, trac.webkit.org/wiki/UsingGitWithWebKit has the information you need.

Simon

Want more features?

Request early access to our private beta of readable email premium.