D15459 is a partial fix here. Here's an "after":

In T5000#142199, @xclaesse wrote:

I am really attached to git workflow as well, so I wrote my own tool to integrate git and phabricator together:
https://phabricator.freedesktop.org/diffusion/GITPHAB/

With simple commands like "git phab attach" you can submit a git branch to review, creating one differential per commit. It is still "just" a wrapper tool on top of "arc diff", though.

I hope it can help others.

D15458 is not a retroactive fix, but new comments made after that change should no longer be separable.

That key seems like it's probably not great for the OR changeType part of the query. If you still have the table handy and playing with it doesn't take an unreasonably huge amount of time, is this better?

getEnableCoverage() returns three values:

to clarify

KEY `commitID` (`commitID`,`isDirect`,`changeType`)

Chad, I just updated, thats very nice! Thank you for doing that!

The strict answer to this is "click the Edit button to go to the full edit UI". We can't make all possible reassign operations accomplishable by dragging, so this has to be the safety net for the cases where we can't guess who your likely assignees are. But I suspect we can do pretty well most of the time with some set of those rules, and make the cost of guessing wrong low.

The create date is now added to the "Authored By" field. I'll maybe give it a better treatment after we land Differential.

I'm going to figure out what the state of large PUTs

The ordering of blogs on the right /phame is (I think after looking at it) creation date. I'm not sure that is the more useful than just lexographical(?) and feels bit implementation detail-y.

@chad wrote:
There are 3 choices.

1. Put in the subheader like on Ponder, Paste.
2. Put the date in the sidebar with Author somehow.
3. Make the first transaction in Timeline never hide.

Awesome, thanks! Updated to latest and confirmed.

Currently I don't believe we have any client-side form validation, at least none that I can think of.

This sounds consistent and expected to me. Either we have JavaScript validation of fields, and therefore notify you of errors immediately so they can be resolved before submission or we don't.

Knowing created date helps to understand how stale a task is which is good to know in some cases

• Certain tasks with a given status/tag need addressed in a timely manner (like customer complaints)
• Tasks which have made it to a version but are ancient are likely no longer relevant/important
• Possibly other case that aren't coming to mind

We have means/views/communications for determining & handling these situations already so it's purely convenience, not trying to base decisions around a single date field.

We cross posted... My initial feature request was not due to this change. It has always been difficult to come by the create date in Phabricator for us. With this change and prior to. With this change, however, it may open an opportunity to put create date on the right column.

Oh! And I'm not saying that this change caused this issue. It has existed for quite some time, we just now are getting around to posting here for discussion.

Sorry, I'm still not understanding what specific change you're concerned about. Isn't the information in the same place -- with the same behavior -- as it was before?

Here are two screen shots

I miss the create date being easily visible.

I miss the create date being easily visible. I opened a feature request for this, but was directed here for commenting. The question posted there was "What do I do differently knowing the create date?"

We've talked internally about several other solutions, but we haven't settled on anything specific yet. It's helpful to know in general how often and what people get from this information. I can find it if I need it, but I only look for it maybe 1-2 times a month here, and only ever for curiosity. I don't tend to treat tasks differently because of the date.

Actually, just going to close this out in favor of the discussion on https://secure.phabricator.com/phame/post/view/770/development_notes_2016_week_10/. Please add your thoughts there.

What do you do differently knowing the date a task was opened? That is, what problem does it expressly solve?

I wonder if the create date of the task should be on the right column along with items such as Subscribers, Authored By, etc...

How can i use DiffusionBrowseController.php to brow my files with non-latin character names correctly?

Marking wontfix in the sense that I'll take on this work rather than upstream.

I added you to Community so you should have access now.

Ah yes I forgot to mention that I have set up a Herald rule that kicks off the build plan.

To clarify, you're expecting the error message to disappear immediately, before you submit the form?

You can sort of do this like this:

This may make sense to at least lightly entangle with T4752, which overlaps in some ways.

To do an integrity check, it looks like we have to compute the Git hash ourselves.

As a general preface, this stuff makes me a little uneasy about LFS in its current state:

初稿

Resolved, I should edit my /etc/sudoers and add: path to ´Defaults env_keep´ and /usr/local/git/bin/ to secure_path

IMPORTANT: This is not a demo or test install. Please don't make a mess. You can launch a demo install on Phacility if you want to poke around and try things out.

i'm sure that is in the path.

Thanks for the report! Resolved at HEAD.

D15454 changes the wording to:

We should probably change the text on "placed up for grabs" to "unassigned from X". I don't think we use that term anywhere else nowadays, either.

nothing added to commit but untracked files present (use "git add" to track)
root@phabricator:/home/phabricator/phabricator# git log -1
commit 929b4ccb5cd29ea932a081ab5d69bf5e06a3ffd3
Author: Chad Little <chad@chadsdomain.com>
Date: Fri Feb 19 14:45:05 2016 -0800

See Prototype, we don't provide bug or feature request for prototypes unfortunately.

Yeah, cut-off would also be acceptable (although I like wrapping slightly better). It might motivate users to pick shorter names but there's not even a lot of space for reasonable names when combined with milestones/subprojects like:

Tags over 320px are likely cut off in all mobile devices anywhere you use them, as well. There aren't too many options if you use really really long names. GitHub cuts it off in like, 20 characters.

We might not use tags over there, not clear yet.