| avivey | |
| Nov 8 2016, 7:06 PM |
| F4251778: pasted_file | |
| Mar 22 2017, 5:11 PM |
About half the time, I get the "dependency" relation wrong (Which revision depends on which (ie Does a Parent depends on its children (Like in tax forms) or the other way around (Like in unix processes?)) when it's described as "parent/child", and I use this rather a lot, and also need to explain to users, which is even more confusing.
Why did we move away from "depends on"?
What specific, totally unambiguous labels would you prefer these actions to have?
Edit Parent Revisions
Edit Child Revisions
Our use of "parent" and "child" are consistent with Git's use of "parent" and "child", if that helps: for example, git help log discusses the ideas of "parent commits" and "child commits" in many places, and "parent revisions" and "child revisions" have the same relationship order as commits do in Git.
However, dependency order differs between revisions and tasks (revisions depend on their parents; tasks depend on their children).
I was used to the "dependency" ones we had, but I agree they're not really unconfusing enough.
The only phrasing I can think of that is unambiguous is also long and not very natural:
Being consistent with git should help me remember this, at least :)
I think there was no web UI for this until T4788, which added both options. Prior to that, the only way to mark dependencies was by writing "Depends On" in text (which still works). So we didn't previously have anything else, unless I'm misremembering.
I think these (which are the shortest "Depends On" flavored texts I can come up with) are more confusing than parent/child. We had some version of this in Maniphest briefly long ago and I think it was consistently confusing:
Edit Dependents
Edit Dependencies
So that's why we ended up with "Parent" and "Child".
In Maniphest, we also had these variants (I think?):
Edit Blocking Tasks
WMF, at least, found this unclear and changed it to:
Edit "Blocked By" Tasks
We could maybe try "Edit Ancestor Revisions" and "Edit Descendant Revisions", but I'm not sure if that's more clear. That also implies that you can edit multiple levels, which you can't.
Also, part of the reason that we have two (and that I want to retain two) is to force you to make a choice, since I think it was previously common for users to kind of ignore the text and assume it meant whichever direction they were hoping to find a button for.
Or, of course, we could do:
Edit Revisions This Revision Depends On, Such That They Must Be Committed First
Edit Revisions Which Depend On This Revision, And Which May Be Committed Only After This Revision Is Committed
The distinction between "Earlier Revisions" and "Earlier Versions of This Revision" (e.g., earlier diffs) seems potentially confusing to me. That is, I could imagine a new user thinking "Earlier Revisions" meant "earlier versions of this change", not "prior changes which this change depends on".
(If we were better about figuring this out automatically -- which we may be soon -- would it be a problem at all?)
In my case (T9287), the dependencies are cross-repository, which I don't think we can reasonably automatically figure out.
I'm happy to change this if anyone comes up with good alternate wording, but I think this might be about the best we can do.
Per above, a mnemonic for this is that parent/child revisions in Differential are the same as parent/child commits in Git.
We'll do a better job of automatically creating these relationships in the future, although that won't help in all cases.
(You can also edit these strings locally with little risk of conflicts if you have a great fondness for one of the 30-word-long versions.)
I know it's closed, but here are few proposals (not sure if better in any way):
or (probably bad):
@epriestley If you just add copy in the selection dialog, it will help a lot IMO:
For instance: "Edit Parent Revisions (will result in a parent commit of the child revision)" (I know terrible wording but you get the idea).