Can't seem to find a maintainer for init/* files

[Paulo Miguel Almeida]

On Fri, Oct 18, 2019 at 07:25:12PM -0400, Valdis Klētnieks wrote:
> On Sat, 19 Oct 2019 10:33:00 +1300, Paulo Almeida said:
> 
> > 1 - This specific code block has been around for quite some time and many
> > additions using the correct printk(KERN_* were made after it was written.
> > Does that mean that this code block is an exception and should be left
> > as-is for some technical reason? Or, people have somehow forgotten about it
> > and I finally found something to do? :)
> 
> There's a meta-consideration or two here to think about.
> 
> First, many maintainers are not thrilled with trivial patches to code,
> especially checkpatch cleanups.  That's because those patches fall into two
> major categories:
> 
> The patch is against code that's debugged and rock solid stable.  Most of
> do_mounts.c is close to a decade old, and it's only being changed when it's
> needed to add an actual feature (such as mounting by partition label in 2018
> or mounting a CIFS filesystem this year).  And we *have* had what looked like
> "trivial checkpatch cleanup" patches that were buggy and broke stuff.
> 
> The other category is "patches against code that's being worked on".  If it's
> something that somebody else is working on, it can cause merge conflicts, which
> make maintainers grumpy.  So the maintainer only wants to see those cleanups if
> they're by the person who's working on the code, at the front of the patch
> series, so that (presumably) they don't have merge commits and they've gotten
> some compile and run testing.
> 

That makes perfect sense. 

> The other big consideration is git.  Yes, git knows where and when every single
> line of code came from.  That doesn't mean it's always easy to get it to cough
> up information.

I must confess that prior to this "challenge" of yours, I hadn't realised how tricky
git can become to get it to do certain things.  

> 
> For example:   'git blame init/do_mounts.c'.  That tells you where each line came from.
> Now... imagine a commit that did a spaces-to-tabs cleanup on lines 249 to 257.
> git blame' now lists the cleanup commit, not the 6 commits that added the original code.
> 
> Exercise for the reader:  Determine the easiest way to get 'git blame' to show you
> the original 6 commits rather than the cleanup.

Considering that I'm technically a reader :) I'm gonna start with my solution and
if anyone else wants to add to it (or replace it altogether) feel free to do so.

What I got so far is:

L_START=249
L_FINISH=257
FILE=init/do_mounts.c; 

for commit in $(git log --format='%h' --no-patch -L$L_START,$L_FINISH:$FILE | cat | tail -n +2)
do 	
    echo "Showing commit: $commit of file: $FILE"
    git blame -n -L$L_START,$L_FINISH $commit -- $FILE
done

PS.: (For future readers)  That may take a while.

I feel like this isn't right per se as the "git log -L" doesn't support "--follow" 
argument that would impact our ability to make it cough up the info we wanted in case the
file had been renamed. However, on the other hand, it would (to my understanding) make
its best effort to keep track of those lines in the log history. (Correct me if I'm wrong)

In a second approach:
I tried making "git log" to list all the commits this particular file was involved in
(so I could use --follow) but I ended up with loads of commits that change other sections 
of the file (not the lines we were looking for) and because of that I didn't feel like I 
was meeting the "'git blame' to show you the original 6 commits rather than the 
cleanup" rule.

@Valdis I hope I'm not going off-topic but could you shed some light on this?

Last but not least, I appriciate the meta-consideration points you brought up.

Best Regards,

Paulo Almeida