Emily Shaffer <emilyshaffer@xxxxxxxxxx> writes: > On Tue, Feb 18, 2020 at 03:56:22PM -0800, Emily Shaffer wrote: >> On Tue, Feb 18, 2020 at 03:46:28PM -0800, Emily Shaffer wrote: >> > On Sat, Feb 15, 2020 at 10:24:40AM -0800, Junio C Hamano wrote: >> > > I am actually OK if we limit the use of this tool to "use with a >> > > repository that is not corrupt", as coping with these kinds of >> > > breakages that in the main Git executable we deem "needs manual >> > > intervention" inside a single process is too painful (it would have >> > > been easier to cope with these too if we stuck with a script that >> > > invokes many discrete commands and acts on their errors, but that is >> > > optimizing for rare case and not recommended). But we should tell >> > > users about the limitation and encourage them to ask for help in non >> > > automatable means. >> > >> > I think you're saying, "Mention this drawback in the manpage for >> > git-bugreport." Sounds like a good idea to me, so I'll add it for v8. >> >> I'm pretty unsure about how you wanted this to sound; rather than >> sending a v8 only to revise it a lot, I'll send the paragraph for >> wordsmithing beforehand. Is this what you meant? >> >> This tool is invoked via the typical Git setup process, which means that in some >> cases, it might not be able to launch - for example, if a relevant config file >> is unreadable. In this kind of scenario, it may be helpful to manually gather >> the kind of information listed above when manually asking for help. > > Since I saw lots of replies from Junio elsewhere in this thread, I'll > take the silence here as assent. v8 on its way momentarily. Heh, it's just I have too little time to allocate on this single topic X-<. Don't take silence as anything else.
