> Hi Alex, > On Thu, Sep 8, 2022 at 1:28 AM Alejandro Colomar <alx.manpages@xxxxxxxxx> wrote: > > Hi Jakub > > On 9/7/22 22:53, Jakub Wilk wrote: > > > * Petr Vorel <pvorel@xxxxxxx>, 2022-09-06 11:41: > > >> Although I agree that number of man* is quite high and single man > > >> directory looks nicer, from practical reasons I'd prefer to revert > > >> this commit. > > > I don't like the new layout either. > > Thank you both for sharing your opinion. I'll revert it, then. Let me > > a few weeks before doing that, since I'm in the middle of some other big > > changes (about lint-c), so to not have to stash and fix conflicts at > > that scale. If in the meantime someone finds the new layout nice, > > please speak up :) > I think one other aspect to consider is that it makes history > searching harder. If you type 'git log <file>', by default you only > get the history to the last move. You need 'git log --follow' to see > the whole history. Then if you want to do a 'git blame' on an old > version of the file, pre-move, I think you need to find the old path > and use that. If the maintainer's opinion of where a file should be > changes often, that makes it more fun :). Yes, I have experience from other projects that moving around does not help. But here simple revert is working well: $ git revert 70ac1c4785fc1e158ab2349a962dba2526bf4fbc git is smart: new changes in unshare.2 (8f4ed6463) and fanotify_mark.2 (c06943bee) didn't cause a conflict. But still, if you decide on revert, I'd do it early (don't put new commits before it) $ git log man2/_exit.2 # shows previous history Kind regards, Petr > Just my 2 cents, > Stefan. > > Cheers, > > Alex
