Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Conflicting file name is inconvenient to parse #172

Closed
rualark opened this issue Dec 1, 2019 · 1 comment
Closed

Conflicting file name is inconvenient to parse #172

rualark opened this issue Dec 1, 2019 · 1 comment

Comments

@rualark
Copy link

rualark commented Dec 1, 2019

For example, if file name is "some (other).is txt" the string looks like:
(α) some (other).is txt (<non-existent> -> File (d06a9ece2c6a5652a05f29db7f125749de2d4efa))

It is difficult to understand where file name ends when parsing this line automatically.

Solution: use character that is never used in status on the right side so that it can be found by parsing the line from the end (like rfind() in python):
(α) some (other).is txt : <non-existent> -> File (d06a9ece2c6a5652a05f29db7f125749de2d4efa)

By the way, in MutagenMon I actually parse it by finding matching parenthesis to the last parenthesis in this string

@xenoscopic
Copy link
Member

I can definitely see why this would be a pain to parse. These formats aren't really stable either. They don't really change at the moment, but there's no guaranteed stability, and given the need to improve various UI commands I'm pretty sure they'll change in the near future.

I think your approach of working backward makes the most sense. There are a limited number of formats that these conflicts can take, e.g. File(<SHA1>), Directory, etc. You could probably build regular expressions for these, but I can't guarantee they won't break. In fact, the conflict format has changed even between the time this issue was opened and now (in 26fc5f4).

The real answer to this is either stabilizing the daemon API (#38) or creating a "porcelain" (in the Git sense of the word) mode for commands (#57). So in that sense, I'll mark this as a duplicate of those issues for now, but it's definitely an important case study and motivating factor for those issues, since it's almost impossible to get this information via parsing.

I'm sorry there's not a better solution than painful parsing or waiting. I don't really have a precise ETA on #38 or #57, but realistically they're still probably months away. In the mean time, I can try to avoid breaking the conflict formatting, though I can't make any promises.

But as it stands, it should be possible to engineer regular expressions for the formatting using the formatEntryKind and printConflicts functions.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants