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:
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:
I thought I did merge though! What happened? Looks an empty commit
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
Those two commits are related, but it's totally
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
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.
2) Introducing a new dedicated code-review tool
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:
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:
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
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
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:
1) 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.
2) My understanding until now was that WMF is going to
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
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
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
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).