Re: [irq/urgent]: created 3786fc7: "irq: make variable static"

> this welcome enhancement made me remember of three usage problems i had
> with Git recently:
>
> 1)
>
> Btw., it would be nice if there was an easier way to get a similar git
> log display in the ASCII space. For example i frequently ask the
> question "which topic branch did commit XYZ originate from?". All i have
> now is a pretty crude script that displays this for a given file:
>
> earth4:~/tip> tip-log --no-merges linus.. kernel/sched.c | grep ^#
> # core/kill-the-BKL: ffda12a: sched: optimize group load balancer
> # core/locking: ffda12a: sched: optimize group load balancer
> ...
>
> (see the script attached below)
>
> but it's very slow with 233 branches, obviously, so i only use it as a
> last resort mechanism.
>
> What i'd _love_ to see is just an ASCII representation of where a commit
> "came from" into the current branch. The first-hop branch it was
> committed to.
>
> it doesnt even have to be correct in the sha1 sense - i.e. it's enough
> for me if the merge commit log is parsed. (and hence it wont be correct
> if a branch ceases to exist or is renamed - but that is OK, i keep the
> branch space static)
>
> any ideas how to achieve that? I'd love to have output like this, if i
> do this from tip/master (the master integration branch):
>
>  # mockup
>
>  earth4:~/tip> gll --no-merges kernel/sched.c
>  ffda12a: [sched/core]      sched: optimize group load balancer
>  8cd162c: [sched/clock]     sched: only update rq->clock while holding
>  0a16b60: [tracing/sched]   tracing, sched: LTTng instrumentation
>  a5d8c34: [sched/debug]     sched debug: add name to sched_domain sysctl entries
>  34b3ede: [sched/core]      sched: remove redundant code in cpu_cgroup_create()
>
> ... and i dont want to embedd the branch name in every single commit.
>
> The semantics seem well-specified to me: walk down the merge tree a
> particular commit came from, and use the branch name that is mentioned
> in a merge commit's comment section 'closest' to this commit.
>
> That information is not 'trustable' in the sha1 sense because merge
> commits can be modified manually and because the momentary name of a
> branch might not be correct anymore - but with a sane topical setup this
> would be a very powerful visualization tool.
>
> It would be a nice tool that makes it easy to check the proper structure
> of topical branches, after the fact. Weird, incorrectly queued up
> commits would stick out _immediately_:
>
>  34b3ede: [x86/xen]      sched: remove redundant code in cpu_cgroup_create()
>