Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1575157 > unrolled thread

Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out of <linux/sched.h>

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out  of <linux/sched.h> Linus Torvalds <torvalds@linux-foundation.org> - 2017-02-06 22:30 +0100
    Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out  of <linux/sched.h> Ingo Molnar <mingo@kernel.org> - 2017-02-06 23:00 +0100
      Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out  of <linux/sched.h> Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-07 09:10 +0100
        Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out  of <linux/sched.h> Ingo Molnar <mingo@kernel.org> - 2017-02-07 09:20 +0100
          Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out  of <linux/sched.h> Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-07 09:30 +0100
            Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out  of <linux/sched.h> Ingo Molnar <mingo@kernel.org> - 2017-02-07 10:50 +0100
              Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out  of <linux/sched.h> Geert Uytterhoeven <geert@linux-m68k.org> - 2017-02-07 11:00 +0100

#1575157 — Re: [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out of <linux/sched.h>

So this was another of those "lots of noise, hiding the actual changes".

And in the midst of all that noise was this fixup:

On Mon, Feb 6, 2017 at 5:29 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> diff --git a/arch/tile/mm/fault.c b/arch/tile/mm/fault.c
> index 1e0509a4c8bd..f58fa06a2214 100644
> --- a/arch/tile/mm/fault.c
> +++ b/arch/tile/mm/fault.c
> @@ -17,11 +17,8 @@
>  #include <linux/signal.h>
>  #include <linux/sched.h>
>  #include <linux/sched/debug.h>
> -<<<<<<< HEAD
> -=======
>  #include <linux/sched/task.h>
>  #include <linux/sched/task_stack.h>
> ->>>>>>> 9ecfbdbd2d46... fork.h fixes
>  #include <linux/kernel.h>
>  #include <linux/errno.h>
>  #include <linux/string.h>

which obviously means that I didn't even notice this other conflict
marker earlier in the series.

Anyway, I'm finding the end result pleasing, but the steps having
small issues like this really makes me want the final series to be
cleaned-up.

             Linus

[toc] | [next] | [standalone]

#1575186

* Linus Torvalds <torvalds@linux-foundation.org> wrote:

> So this was another of those "lots of noise, hiding the actual changes".
> 
> And in the midst of all that noise was this fixup:
> 
> On Mon, Feb 6, 2017 at 5:29 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > diff --git a/arch/tile/mm/fault.c b/arch/tile/mm/fault.c
> > index 1e0509a4c8bd..f58fa06a2214 100644
> > --- a/arch/tile/mm/fault.c
> > +++ b/arch/tile/mm/fault.c
> > @@ -17,11 +17,8 @@
> >  #include <linux/signal.h>
> >  #include <linux/sched.h>
> >  #include <linux/sched/debug.h>
> > -<<<<<<< HEAD
> > -=======
> >  #include <linux/sched/task.h>
> >  #include <linux/sched/task_stack.h>
> > ->>>>>>> 9ecfbdbd2d46... fork.h fixes
> >  #include <linux/kernel.h>
> >  #include <linux/errno.h>
> >  #include <linux/string.h>
> 
> which obviously means that I didn't even notice this other conflict
> marker earlier in the series.
>
> Anyway, I'm finding the end result pleasing, but the steps having
> small issues like this really makes me want the final series to be
> cleaned-up.

Yeah, absolutely. :-/

Wondering why Git allowed me to be so stupid with those leftover merge markers. 
Git usually doesn't even allow me to commit them so I have these tuned out as a 
possibility. This was just a regular git rebase -i flow, to back-merge fixes and 
reorder/squash patches - nothing fancy that I remember - only the occasional 
--onto option. I'm using Git 2.7.4.

Note that the title has a problem too:

  [PATCH 57/89] sched/headers: Split <linux/sched/task_stack> out of <linux/sched.h>

That should say <linux/sched/task_stack.h>.

I'll do the further splitting up, will address all the other review feedback and 
will go over it with a fine comb before reposting.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1575440

Hi Ingo,

On Mon, Feb 6, 2017 at 10:54 PM, Ingo Molnar <mingo@kernel.org> wrote:
> Wondering why Git allowed me to be so stupid with those leftover merge markers.
> Git usually doesn't even allow me to commit them so I have these tuned out as a
> possibility. This was just a regular git rebase -i flow, to back-merge fixes and
> reorder/squash patches - nothing fancy that I remember - only the occasional
> --onto option. I'm using Git 2.7.4.

Git complains about the merge conflicts, and refuses to commit the result
as long as you haven't resolved them, but it will happily commit everything
you add using "git add -u", incl. merge markers.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1575458

* Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Ingo,
> 
> On Mon, Feb 6, 2017 at 10:54 PM, Ingo Molnar <mingo@kernel.org> wrote:
> > Wondering why Git allowed me to be so stupid with those leftover merge markers.
> > Git usually doesn't even allow me to commit them so I have these tuned out as a
> > possibility. This was just a regular git rebase -i flow, to back-merge fixes and
> > reorder/squash patches - nothing fancy that I remember - only the occasional
> > --onto option. I'm using Git 2.7.4.
> 
> Git complains about the merge conflicts, and refuses to commit the result
> as long as you haven't resolved them, but it will happily commit everything
> you add using "git add -u", incl. merge markers.

Hm, it should really force that via 'git add -f' or such. The merge markers are 
_very_ infrequent as naturally occuring source code lines even on a per line basis 
- and especially the combination of them should be exceedingly unique.

I frequently use:

	git add $(git ls-files -m)

... to stage edits without comitting them, probably that workflow is what caused 
this bug.

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1575470

Hi Ingo,

On Tue, Feb 7, 2017 at 9:13 AM, Ingo Molnar <mingo@kernel.org> wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Mon, Feb 6, 2017 at 10:54 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> > Wondering why Git allowed me to be so stupid with those leftover merge markers.
>> > Git usually doesn't even allow me to commit them so I have these tuned out as a
>> > possibility. This was just a regular git rebase -i flow, to back-merge fixes and
>> > reorder/squash patches - nothing fancy that I remember - only the occasional
>> > --onto option. I'm using Git 2.7.4.
>>
>> Git complains about the merge conflicts, and refuses to commit the result
>> as long as you haven't resolved them, but it will happily commit everything
>> you add using "git add -u", incl. merge markers.
>
> Hm, it should really force that via 'git add -f' or such. The merge markers are
> _very_ infrequent as naturally occuring source code lines even on a per line basis
> - and especially the combination of them should be exceedingly unique.

They were very infrequent, until we switched to RST for documentation,
causing false positives when searching for "^[<=>].*" in vim...

> I frequently use:
>
>         git add $(git ls-files -m)

That's identical to "git add -u", right?

> ... to stage edits without comitting them, probably that workflow is what caused
> this bug.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [next] | [standalone]

#1575532

* Geert Uytterhoeven <geert@linux-m68k.org> wrote:

> Hi Ingo,
> 
> On Tue, Feb 7, 2017 at 9:13 AM, Ingo Molnar <mingo@kernel.org> wrote:
> > * Geert Uytterhoeven <geert@linux-m68k.org> wrote:
> >> On Mon, Feb 6, 2017 at 10:54 PM, Ingo Molnar <mingo@kernel.org> wrote:
> >> > Wondering why Git allowed me to be so stupid with those leftover merge markers.
> >> > Git usually doesn't even allow me to commit them so I have these tuned out as a
> >> > possibility. This was just a regular git rebase -i flow, to back-merge fixes and
> >> > reorder/squash patches - nothing fancy that I remember - only the occasional
> >> > --onto option. I'm using Git 2.7.4.
> >>
> >> Git complains about the merge conflicts, and refuses to commit the result
> >> as long as you haven't resolved them, but it will happily commit everything
> >> you add using "git add -u", incl. merge markers.
> >
> > Hm, it should really force that via 'git add -f' or such. The merge markers are
> > _very_ infrequent as naturally occuring source code lines even on a per line basis
> > - and especially the combination of them should be exceedingly unique.
> 
> They were very infrequent, until we switched to RST for documentation,
> causing false positives when searching for "^[<=>].*" in vim...

But the exact merge conflict pattern is generated by Git, and it's far more 
specific than the "^[<=>].*" pattern, right?

So it should be possible to disambiguate?

> > I frequently use:
> >
> >         git add $(git ls-files -m)
> 
> That's identical to "git add -u", right?

Indeed, I'm bad at remembering one letter shortcuts: why is what is '-m' in 
git-ls-files called '-u' in git-add? ;-)

BTW., would 'git add -u' have prevented my mistake?

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]

#1575534

Hi Ingo,

On Tue, Feb 7, 2017 at 10:45 AM, Ingo Molnar <mingo@kernel.org> wrote:
> * Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> On Tue, Feb 7, 2017 at 9:13 AM, Ingo Molnar <mingo@kernel.org> wrote:
>> > * Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>> >> On Mon, Feb 6, 2017 at 10:54 PM, Ingo Molnar <mingo@kernel.org> wrote:
>> >> > Wondering why Git allowed me to be so stupid with those leftover merge markers.
>> >> > Git usually doesn't even allow me to commit them so I have these tuned out as a
>> >> > possibility. This was just a regular git rebase -i flow, to back-merge fixes and
>> >> > reorder/squash patches - nothing fancy that I remember - only the occasional
>> >> > --onto option. I'm using Git 2.7.4.
>> >>
>> >> Git complains about the merge conflicts, and refuses to commit the result
>> >> as long as you haven't resolved them, but it will happily commit everything
>> >> you add using "git add -u", incl. merge markers.
>> >
>> > Hm, it should really force that via 'git add -f' or such. The merge markers are
>> > _very_ infrequent as naturally occuring source code lines even on a per line basis
>> > - and especially the combination of them should be exceedingly unique.
>>
>> They were very infrequent, until we switched to RST for documentation,
>> causing false positives when searching for "^[<=>].*" in vim...
>
> But the exact merge conflict pattern is generated by Git, and it's far more
> specific than the "^[<=>].*" pattern, right?

Sure, but my fingers have memorized the above pattern ;-)

> So it should be possible to disambiguate?

Except for the cases where there are exactly 7 consecutive equals signs
at the beginning of a line in the RST sources.

>> > I frequently use:
>> >
>> >         git add $(git ls-files -m)
>>
>> That's identical to "git add -u", right?
>
> Indeed, I'm bad at remembering one letter shortcuts: why is what is '-m' in
> git-ls-files called '-u' in git-add? ;-)
>
> BTW., would 'git add -u' have prevented my mistake?

No, AFAIK.

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web