In D9516#149033, @mharbison72 wrote:Big picture, why do we need to be able to tell namespace parts from command parts?
To make sure the user understand they are stepping in an entire different realm with different rules.
In the standard namespace (no prefix) we garantee (or aims at) the lack of footgun and excellent backward compatibility.
The debug namespace should not be somewhere any normal user ever have to go (at least without a responsible staff member)
The admin namespace will have its own rules and its own "be careful, this is not a "normal" situation to be there.
So we want something more distincting than just a simple - that we could have for "command group" or readability like phab-send, phab-read, etc.So it sounds like more of a convention for these behavior properties than say, commands in the admin group requiring --yes-i-know-this-may-eat-my-data. We'll have to have to figure out how to convey that somehow. I see admin, for example, and think "I'm in charge of making this work for my group, and it sounds like it does what I want, so it's for me and just some extra characters to type". I don't have any suggestions on how to highlight these behaviors ATM.
Active Repositories
- rHG Mercurial
- Fri, Jan 22, 5:10 AM
- Mercurial
- rNRWHG narrowhg
- 369 Commits
- ·
- Restricted Project
- Jan 26 2018, 6:48 PM
- Mercurial
Recent Activity
Today
Yesterday
In D9825#149333, @durin42 wrote:Do you think we should go ahead and apply the local patch then until we can update the vendored copy?
Do you think we should go ahead and apply the local patch then until we can update the vendored copy?
In D9825#149257, @durin42 wrote:Yes, please remove the python-zstandard changes from here, and send them directly to @indygreg upstream for that.
Finds the author command
https://github.com/git/git/blob/7f7ebe054af6d831b999d6c2241b9227c4e4e08d/builtin/fast-import.c#L2689
The basic concern I have here is that I have stepped on git's toes here before and the field is nowhere near as free text as it is supposed to be according to the specification. So any change should at least double check what the git code is actually doing, because it doesn't do the same as the documentation from what I have seen. Case in point is the data handling, where git does distingiush between +0 and -0.
Should we add a test that, if git-fast-import is available, actually tries the import and verifies that things look reasonable?
Yes, please remove the python-zstandard changes from here, and send them directly to @indygreg upstream for that.