git ssb


cel / ssb-issues

Use first line of issue text as its title.

Closed noffle wants to merge commits into master from cel / %V53yIAO6ZNGv1Lx9tCP… / issue-names
noffle · 11/9/2016, 7:54:37 AM

Use first line of issue text as its title.

What do you think? I'd really like to be able to see the full issue title in git-ssb-web and on the cli, but the truncation being built directly into the issue ssb message makes this impossible.

A better solution might be to have a title form field in git-ssb-web/cli instead, but I'm pretty happy with this -- first line = name matches the same nomenclature as git commits and PRs.

cel deleted the issue-names branch · 11/9/2016, 11:51:21 AM
%9gLLPNuSFYyYcleA8rrsFs0B0Wir2I9Un0FQLSwuxZs=.sha256 cel · 11/9/2016, 11:57:05 AM

Merged into v0.3.0.

There was a separate title field before but I deprecated it because it simplifies some things. Formalizing the first-line = title thing seems like a good idea.

%tTJuUCSA4bZzGxtf+XdMYcdx0TfBiETG44o6xu/swuQ=.sha256 noffle · 11/9/2016, 12:26:07 PM

How do you feel about a title form field on git-ssb-web for issue creation? It'd be one field in the backend, but it might be a nice UX.

%KrxQs9BZNFKTTJTqiPcu1+LxgyR8/9d02STeAEqv7JQ=.sha256 cel · 11/9/2016, 4:49:30 PM

I think using the first line of text for a title makes sense in the context of a git commit, where you pass a text body as an argument or via a text file. But in a web UI, we can afford to have a separate title field from text body field.

In %b9wdyGH..., my thinking was "well, in ssb we get by without titles on posts, so maybe we don't need titles on issues/PRs". But, with issues & PRs we often want to list them and easily be able to tell what is what, so I can see it being useful to add back the title field.

This can be done by reverting a282c43eb17a12a9a7d49e9c95560668ec1f08b7 in git-ssb-web, at least partially. Just adding back the title field can be done by reverting the parts of that diff that mention <input or Then ssb-issues should be updated to undeprecate the title property. It also then might be good to update patchbay to add a title field for issue/PR creation, and set the title property, and same with the git-ssb pull-request command - although this isn't completely necessary because git-ssb-web, git-ssb and patchbay all will render an issue or PR's title based on the title property if it is present and fall back to the text property.

If you also want to add back renaming (editing an PR/issue's title), then you could revert more of that diff, to add back the title edit form and handle case 'issue-title'. patchbay should also then be updated to handle renames when rendering issues/PRs.

The only other consideration I can think of is that I was thinking of simplifying the issue edits schema so that the only edit possible is to close an issue, since this allows for a query optimization, to get links with rel issues without values to compute issue state (using just the dest property of each link). However, in doing some quick tests I don't find a significant difference in time to do sbot links --rel issues with or without --values, so this might not matter.

So if you want to add back issue title fields to some degree, I think that would be fine.

%OCqVJR9RsEc5m4Kmh1opfrCegzUWJeQ6iZrshN3gHqg=.sha256 Matt McKegg · 11/9/2016, 5:49:17 PM

In patchwork-next, I made it so that only the first line is used as a title and markdown is stripped out (for everything, not just git issues). Works fairly well.

Built with git-ssb-web