On 10/03/12 22:43, Marcin Cieslak wrote:
I am a seasoned developer. I only do it in my spare time and only when I am particularly annoyed about something not working in MediaWiki (mostly as a feedback from plwiki community or recently checkusers).
You can see my pitiful track record here:
https://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/saper
Most of those things are urgent one-liners that got to be pushed to deployment very quickly and I never had any problem with getting it through the process. But I'm a small guy. So please do not treat my remarks below as something that would make life of people pushing hundreds of lines per week to MediaWiki more difficult.
I only don't like (as it happends with git to me recently) to learn the tool once again from scratch just because I haven't used it for the last 4 weeks or so.
I am using mercurial, git and starting to learn fossil. There is one change which is partially related to tools, partally to the distributed nature of git.
The fundamental change is something else to me: you lose feeling of linearity. I like hg because it still tries to give me a cosy nice local version numbers (great to switch from SVN, you can even have your old SVN commit numbers to stay after migration). But when I look at the gerrit interface (not gerrit's fault) I have no idea what was done before, what was done after, what's the history.
Yes, git is so poewerful, that gets fragile in itself. I end up with several clones and no idea about where they differ. Isn't there a way to compare them?
What happend to me on a very first day trying gerrit:
I got an email to merge a change (since somebody pushed something conflicing in between), so I duly issued some magic git commands and I got it pushed. However, when I came back to gerrit I ended up with an "empty" commit:
https://gerrit.wikimedia.org/r/#change,2916
I thought I did merge though! What happened? Looks an empty commit got filed...
I tried poking around in gerrit to find out what happened I had no clue, only running "git log" locally revealed that may change was indeed merged by somebody else in the background.
I had a feeling I have 4 or more revisions flying around ("commits") and I could not relate them to each other. Only "git log" locally helped me to get out of the trouble.
Looking at this screen:
Interesting. I didn't know about it. Of course, being #dashboard,103 instead of #dashboard,saper makes impossible to change it to find the changes by a given user. It isn't even possible to script it downloading them all in a loop to retrieve the relationship between user and id, as gerrit is unusable without javascript.
Those two commits are related, but it's totally non-obvious that something follows up on something else. I have clicked on them and yes, I can find that 87f491132487313144e531354578ea2fbd3b42b4 is common to both of them. Oh, cool!
In comparison to this, the current Special:Code follow up revision system is easy, readable and very useful.
Oh, and by the way those I3577f029 and Ifb002160 are some identifiers totally unrelated to commits (I need to learn more about Change-Id vs. a commit... I promise I will - already got burned by missing pre-commit hook in the repo). And there is only date, not a timestamp to get some sense of linearity again.
I am really afraid I will be lost when my dashboard will have many more patches and merges.
It doesn't seem to list all the changes, only the recent ones. So it wouldn't be a replacement for http://www.mediawiki.org/wiki/Special:Code/MediaWiki/author/saper I guess it has to be done with git log --author=saper from now on.
Looking at this or any more complex git development tree makes my cry for linear revision numbers. At least I can find out what was before, what is after - sure it comes at a cost of potentially more difficult merging and branching, but let's be serious, how many "edit conflicts" do we have in the tree?
Only a few currently. But a non-linear merging based on review time will increase them. Still, revision numbers arbitrarily assigned by date of submission would be almost as good as our current system. But I don't think that's supported by gerrit.
- Introducing a new dedicated code-review tool (Gerrit)
That one is a habit change. It is a bit disturbing for the first week, just like any new web interface. We will eventually get used to it. I am sure people will easily adapt to the GUI and we will be there to assist.
As described previously in this thread I would describe myself as a simple git fetch/push/commit guy. No rebase, no cherry-pick yet. Maybe the world is still two-dimensional to me.
To solve problems with the above (simple fetch / push model except for WAY TOO FANCY things like HEAD:refs/for/<some-branch> I am told to refer to this:
https://www.mediawiki.org/wiki/Gerrit/resolve_conflict
six commands, including "git-review" I still don't have running. I am afraid to ask what's the non-git-review version of the commands in the guide :)
I agree, there are too many magic commands in that page.
Looking at this again:
https://gerrit.wikimedia.org/r/#change,2916
I have 28f176ca9ca3767bfa9f0ec219f5fa0c299c5761 and 87f491132487313144e531354578ea2fbd3b42b4 here (those are commits, fine) and Ifb002160485030496c7d3f2abc4991484b533648
Additionally there is this c64fd4488d2ea24e120acb15db413377494dd3b3 ("Patch Set 1") referring me to (gitweb) which is calls it "commit". Ah, and there is 1101a1b3fe7f4d1c29321157fc1ef9b9f3fb6ff0 as well.
Ouch and there is this "refs/changes/16/2916/1" <-- the good think I can actually click on it in gitweb!
? That's not a link.
All this makes "MFT r111795, r111881, r111920, r112573, r112995, r113169" looks pale in comparison. And I can actually click a link in [[Special:Code]], and go back and forth on followups, neat!
I proposed several times to bump git change numbers, so new ones don't "conflict" with svn ones. Ie. the number alone would allow you to point to gerrit or CodeReview, keeping a bit of consistency between models. Even the urls kind of match https://gerrit.wikimedia.org/r/123 for r123
Who cares about that? That r stands there for being a review system. I was told that zero effort was going to be made for that (they were unsure about the consequences of bumping the auto_increment, although there's little I can do about that) and to just talk about "change 1234" not "r1234".
It's obvious that c3000 comes after r115000, isn't it? ;)
The only real confusion to me in the current system is the role of "1.19" and "1.19wmf1" tags. It took me a while to figure out they are something like github's pull request OR bumping revsion's priority for review with "1.19wmf1" meaning "urgent!"
Well, their meaning is 'this should be merged to 1.19/1.9wmf1 branch', but of course that means there's a greater urgency to review them.
- Introducing a gated-trunk model
I have a small confusion here:
- Is this true that under current process all unreverted stuff
from SVN will eventually make it to the live site whenever new "wmf" branch will be created? I think lots of new stuff gets in here this way, not necessarily be explicit merge into whatever wmf branch du jour is. Yes, it creates a nice thrill in the community whenever we do this.
Yes. New wmf branches get branched from trunk, so they get everthing in trunk at that point (there have been some little exceptions, with some unstable changes reverted in the branch, but not in trunk).
git shouldn't change that. You can branch from master as well.
- My understanding until now was that WMF is going to run master
in production. Why create another WMF branch then? So we will have a one step to push things to (review branch->master) and then (master->WMF) to deploy? This would be actually a double-gated deployment branch. Ouch.
Good point, if we are going to have that quick reviewing, wmf branches should either get all master commits, or have frequent merges from master.
I really think that tighter integration with bugtracker (so bug attachments end up in vcs review queue and commit comments can be seen as quasi-bugs) would be much more beneficial to users. I will try to see how it would have worked with systems like fossil for example and report back.
Indeed, that'd be an important feature.
And, having seen fossil, bzr and other systems, I just don't subscribe to idea that DVCS *must* have the user interface from hell. And I am not going to use git often enough to have all commands in my head (or even neatly scripted as some people suggest). I love the change the DVCS's bring but not at the cost of needing to say "git push origin HEAD:refs/for/master" or something like that. (I had to go back to docs to write this command again).
//Saper