As we moved away from phabricator (to gitlab) for code reviews, this is no more relevant.

KDE already hosts our own instance, so in that regard we are already protected from the shutdown of Phacility.

Hi David,
I did not plan to get you involved in this discussion because I guessed you wouldn't have done it on-purpose, that's why I have opened a bug on Phabrikator. My point of view is that tools are meant to make life easier (like what GIT does), not bring extra layers of complexity, problems and extra work (hence the tone in the report less diplomatic that what I usually try to do, I think it was the straw that broke the camel's back).

I did use arc patch Dxxx to get the commit, but I didn't notice the ownership was wrong. This happens if you manually upload the patch to website instead of using arc utility. Yes, it's a stupid feature of phabricator, and I forgot about it unfortunately. Sorry.

Hello,
Yes, I confirm the first contribution was actually right. But I have just looked at it and saw that @drosca *had* to ask me a contributor name, which it seems he forgot in 2nd contrib.
Why can't Phab use the info from the GIT patch ? It already has everything (Subject, Summary, Author, ...).
What is the need to make project owner's life harder? Isn't Phab supposed to help?

In fact in the first diff you linked you are set correctly as the author in the commit but not the second one.

That's probably because @drosca committed those for you and didn't set you as the author.

In T5437#207118, @ognarb wrote:

@ahmadsamir In PHP always use === and !== instead of == and !=

@ahmadsamir In PHP always use === and !== instead of == and !=

Thanks for fixing it.

"$@" contains all arguments including "diff", so the function didn't work for me. My fixed version:

Yeah, better arc land than breaking something (until the next time it gets on my nerves and I try to hack the arcanist source code, I know next to nothing about PHP... :)).

arc land verifies that the patch has actually been approved (this saved me from landing the wrong commits a few times), it also deletes the local feature branch. But well, it can also push to the wrong branch :-)

Revisiting an old issue :)

Sorry for the delay in responding to this - it had fallen into a crack and was missed :(

In T5242#156513, @filipesaraiva wrote:

I had this same problem recently - land a commit from a different user but the authorsihp was changed. I reverted the commit. :(

I had this same problem recently - land a commit from a different user but the authorsihp was changed. I reverted the commit. :(

For the sake of the next person getting here through the frustrated-online-search tunnel (like I just did a few hours ago, after the untracked files conundrum hit me about 50 times), here's a simple bash function that I came up with to use --allow-untracked with arc diff (there are probably more elegant ways to do this, but this WFM, so):

The jokes always make me smile, but new contributor friendliness comes first. +1.

Personally I am very much in favour, even to tech-savy people who had to deal with systems like the Atlassian Stack (Jira, BitBucket etc.), Redmine and GitLab, Phab can sometimes be very confusing and it's not entirely sure if a button will do what you expect it to.
I also assume that for people who don't feel terribly comfortable with English yet, it might make it even harder.

Due to the flood of notifications and the enormous amount of excess mail that subscribing projects instead of mailing lists generates, it's been decided to just subscribe mailing lists.
Projects will still be added to reviews so people can filter within Phabricator.

Sorry, I haven't had time to look into this i'm afraid.

@Ben: you added this patch ?

As an FYI, it looks like there will be movement shortly around rendering in general across the whole of Phabricator for Markdown/Remarkup syntax.
Please see https://secure.phabricator.com/T13105

In T7711#124543, @habacker wrote:

If you could confirm updating the remaining commit messages works,

I will this on the next review update

I verified that this is working with an update for D10310

Arcanist is responsible for submitting the changes meaning the control is entirely client side and the server has no input.
Best we could do is patch Arcanist and provide a patched version for people to use with the changes we need made, or alternatively use the other Arcanist client written by a third party which i've seen mentioned elsewhere.

In T7711#124542, @bcooksley wrote:

Okay. Given that upstream has in the past rejected other default behaviour change requests

Phabricator does not have site wide property settings to allow sites having different default behavior ?

Okay. Given that upstream has in the past rejected other default behaviour change requests - and the current behaviour appears to very much be deliberate, i'm not sure if we should ask them about this.

Did that with https://phabricator.kde.org/D9831 and review title has been updated. Updating remaining commit messages not tested yet.

Thanks for this pointer - I'm going to try this.

If you could upload it here that would be great.

In T5242#122935, @habacker wrote:

I added author metadata to a local:commits property to $diff at the end of DifferentialCreateRawDiffConduitAPIMethod::execute() and saw that author meta data in querydiffs api method.

@bcooksley: I have a quick and dirty patch for this - where should I post it to ?

Ralf, have you got a patch which can be discussed with the Phabricator developers, or is this something I need to be looking into?

In T5242#122821, @bcooksley wrote:

all that needs modifying is the handling of raw diffs to add that metadata if it's available.

agreed. I added author metadata to a local:commits property to $diff at the end of DifferentialCreateRawDiffConduitAPIMethod::execute() and saw that author meta data in querydiffs api method.

The codepath used by Arcanist won't need modifying, as that already does the right thing (author metadata gets set and is used). This setup probably originates with other VCSes which aren't distributed, with "local:commits" being added later to accomodate Git.

In T5242#122672, @bcooksley wrote:

It's hard to confirm (without checking the Arcanist or Phabricator codebases) but it's quite likely that Phabricator is using the top level "authorName" and "authorEmail" keys here.

In T5242#122672, @bcooksley wrote:

It's hard to confirm (without checking the Arcanist or Phabricator codebases) but it's quite likely that Phabricator is using the top level "authorName" and "authorEmail" keys here.

It's hard to confirm (without checking the Arcanist or Phabricator codebases) but it's quite likely that Phabricator is using the top level "authorName" and "authorEmail" keys here.

@bcooksley: To be more able to know where to patch - It will help to take a look at the internal data first - I found the following small code review examples (web:D9545, arc:D9429)

@rkflx Yes, Identity and Phabricator are completely separate pieces of software. A checkbox such as that would be semi-difficult as Phabricator can't easily access Identity to check your preferences in that regard. It only really has access to that information when you login.

In T5242#79702, @bcooksley wrote:

The two parts of the solution I discussed with Milian is being tracked by upstream at https://secure.phabricator.com/T12256

To get an idea how to fix topic (2) in the mentioned task I digged a bit into the code on a local phabricator installation and got the following results:

1. phabricator fetches the user from the request at https://github.com/phacility/phabricator/blob/master/src/applications/differential/conduit/DifferentialCreateRawDiffConduitAPIMethod.php#L27
2. The raw diff is available in $raw_diff at https://github.com/phacility/phabricator/blob/master/src/applications/differential/conduit/DifferentialCreateRawDiffConduitAPIMethod.php#L28.

In those links, I don't see any mention of changes to identity (which is different from Phab, right!?) as I am proposing, but I'll stop here. We'll need to wait for @bcooksley to comment, maybe he knows more about the current upstream status of the issue.

@rkflx your proposal was already discussed and dismissed (see the comments from https://phabricator.kde.org/T5242#79416 to https://phabricator.kde.org/T5242#79559 ). Please note that I agree with your proposal and I still disagree with the rebuttal.

Of course I did read the entire ticket before posting. Care to elaborate what point I am missing? Note I am talking about identity (i.e. something we can fix now), while the proper fix would be in Phabricator (i.e. something which might be very far away).

In T5242#122455, @rkflx wrote:

I agree in light of our newly selected focus goals, i.e. T7116: Streamlined onboarding of new contributors, that this is kind of important to solve.

Hi all, I regularly stumble over this issue again and again. In fact, I would like to give especially first-time contributors the correct authorship (git commit --author="..."). But I cannot, since the email address is hidden. This is *really* cumbersome, and in fact kind of breaks my workflow. In the end, I mostly claim the work by others for myself, just to get work done. This is not how it should be ideally :-)

Can you please file a Sysadmin ticket and we'll sort you out?

Run into this as I also need to update my email address. It's been two years since the issue was logged...

I've now fixed the translation overrides we're using - upstream changed some of the text so it no longer matched.

FWIW, this is still an issue: https://bugs.kde.org/show_bug.cgi?id=359909#c10

I think that the Diff Detail section is then confusing: even if it does not contain metadata about the repository, if I forcibly set the repository then it should be shown.
Or anyway, the repository should be shown anyway.
Updated example: https://phabricator.kde.org/D5037

I think there are two different items at play here:

• Revisions (Reviews), which have multiple Diffs and Comments attached to them. You can edit the repository set for this by editing the revision.
• Diffs, which comprise a given change to the source code. These also have a repository, which is set when the diff is created.

But you can edit the review later, and you can set the repository. If you can edit and set the repository anytime, the repository should appear in the proper place. If bot, it's a pahbricator bug.

Yeah. When you upload a diff you are given an option to set the repository which I think is what needs to be done here. I suspect that is the step that is being missed and unfortunately you can't go back and amend this once it's been uploaded.

I did not updated the diff itself; I edited the review and added the value in the repository field (see the history of https://phabricator.kde.org/D5538 ). Right now that review shows the repository in the proper field, but it was submitted so something else may have happened that set the field properly.I would try to look for reviews without repo.

When updating a Diff i've noticed you get an option to set a Repository - have you been setting that? (This is separate to the metadata of the review itself)

I've entered false translations for these now as pointed out by @aklapper which resolves the core of this task.

• Phabricator admins can easily overwrite existing strings via adding definitions to /config/edit/translation.override
• FYI, Wikimedia wrote a custom extension to change the login page a bit.

Btw there are also other hardcoded strings that would need some love. For example in https://phabricator.kde.org/differential/diff/create/ there should be git diff -U999 rather than plain git diff (many new contributors don't use the -U switch and the code review loses context).

From a quickly check of the code, it seems that the string is hardcoded, but on the other side it is marked for translation. Apart from filing an upstream bug, maybe a quick solution could be a "custom" (fake) translation?

In T5079#92501, @elvisangelaccio wrote:

In T5079#92497, @elvisangelaccio wrote:

I'm seeing more and more reviews with "foo (branched from bar)" as branch value (e.g. D5706), which is good. But I'm not able to get the same when I create a revision through arcanist (I just get the name of the local feature branch, e.g. see D5658).
What am I doing wrong? I have arcanist and libphutil fully updated (tracking their stable branch).

Oh, maybe it's because git checkout -b does not set the upstream for the new branch. Next time I'll try to use git checkout -t -b, let's see if that helps...

In T5079#92497, @elvisangelaccio wrote:

I'm seeing more and more reviews with "foo (branched from bar)" as branch value (e.g. D5706), which is good. But I'm not able to get the same when I create a revision through arcanist (I just get the name of the local feature branch, e.g. see D5658).
What am I doing wrong? I have arcanist and libphutil fully updated (tracking their stable branch).

I'm seeing more and more reviews with "foo (branched from bar)" as branch value (e.g. D5706), which is good. But I'm not able to get the same when I create a revision through arcanist (I just get the name of the local feature branch, e.g. see D5658).
What am I doing wrong? I have arcanist and libphutil fully updated (tracking their stable branch).

Well, to me that's making things needlessly complicated, for typical FOSS usage at least. Even more so because the arc command to modify revisions is called diff ...

Thanks for your report. Upstream has now resolved this and we've updated to a version that contains the fix now.

Subscribers and Reviewers belong to the Revision, not the Diff. They're reviewing the current status of a Revision, which is represented by a Diff, along with various items like a Summary, Test Plan, etc.

But why would the other fields remain set? If you change the repo you could also argue that the subscribers and reviewers might have to change.

I'll ask upstream but this looks like fairly expected behaviour to me. It's each diff that belongs to a repository not the revision itself.

If it helps at all, for fd.o & Collabora, we avoid using arcanist at all, and use git-phab. That ignores untracked files by default. ;) You could also ship this patch for Arcanist to at least allow you to configure --allow-untracked as the default.

Moving to the Phabricator board for tracking. I'll consider discussing this with upstream.
Note that Commits can actually have their own Project tags which are independent of Repositories.

*Nod*. If it's just a case of having a button to click, i'll ask upstream about that. best place to put it would be under "Create Task" I think.

OK, but that's still not very user-friendly as

I'll ask upstream if they're amenable to making the Branch manually editable (one can change the repository after all).

Any create task url can do this - simply add ?template=<Task to template off> and Phabricator will do the rest for you.