Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes

[Steven Rostedt]

On Wed, 2012-05-02 at 13:14 -0700, Junio C Hamano wrote:
> Steven Rostedt <rostedt@xxxxxxxxxxx> writes:
> 
> > On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
> >> Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:
> >> 
> >
> >> When a normal developer wants to _reset to_ a particular tagged release,...
> >
> > The problem is,...
> > But then I would end up with ...
> 
> [comments on the part I declared "uninteresting" snipped]

Just have to snip it, you don't need to declare it uninteresting.


> > $ git-branch-status v3.0.4 v3.0.5              
> > Branch v3.0.4 can be fast forward to v3.0.5 in 240 commits
> >
> > $ git-branch-status v3.0.4 v3.1  
> > Branch v3.0.4 and v3.1
> > differ by 257 and 9380 commit(s) respectively
> 
> I personally do not think "257 and 9380" vs "15 and 400" totally
> uninteresting, in the sense that the absolute numbers do not matter much,

I disagree here. Maybe it's because of the example I used. Here's a more
appropriate one:

I usually work against the tip.git tree for my kernel work (not ktest),
and I have several branches for different things I work on. I
periodically rebase against the latest tip branch to make sure
everything works (these development branches are only local to my own
machines, not public). Sometimes I forget what I pushed forward and
where I left off. I'll make a branch off of another branch's commit and
push that, and continue developing. But I rebase the new stuff and test
it before pushing it again. So I have something like this:

$ git-branch-status tip/perf/core
Branch HEAD and tip/perf/core
differ by 15 and 644 commit(s) respectively

Here it shows that this branch has 15 patches that are pending. I'll
usually rebase against tip/perf/core, run a bunch of tests, and then
push it out when ready.

I'll continue to work on this branch and add more patches. But because
other people may add things to tip/perf/core that affect me, I need to
rebase once in a while. But I also check to see if the previous push was
in, and I use my script git-branch-status on a daily basis. Lets me know
what patches I need to look at. Maybe it's not that important, but I
find it useful in my everyday workflow.

> and the only question that matter is "Is everything in this one included
> in the other?" and I just say "git lgf master..topic" (where I have in my
> $HOME/.gitconfig "[alias] lgf = log --oneline --boundary --first-parent"
> defined) to see the list of commits on a topic, with the indication of
> where the topic forked from.  Obviously it takes the "never merge mainline
> into topics" discipline for it to be useful.
> 
> I also use "git show-branch $A $B $C..." for something like this but that
> is only useful when these branches are known to have only a handful of
> commits on their own, and its output is not very suited if they have
> hundreds of commits.


If I'm the only one that finds this feature useful, then I'm happy with
just using my script. It works well and I have it on all my boxes. I
just wanted to show others in case I'm not the only one that finds this
information useful.

I just thought it would be easy to implement as git already does this
check. I liked what I saw from git that I based my output of this script
on it. In fact, I just saw it today:

$ git checkout trace/rfc/tracing/fentry
Switched to branch 'trace/rfc/tracing/fentry'
Your branch and 'ftrace/rfc/tracing/fentry' have diverged,
and have 65913 and 4 different commit(s) each, respectively.


I'll throw in one more feature request, that you can take or leave (I
have another script for it ;-), something that does a listing of
branches in order of date. I have over a hundred branches in my repo,
and I forget which branch was the last one I was working on. So I
created a script called git-ls (attached).

Here's what the output looks like:

$ git-ls | tail
681d1c4    2012-04-19    trace/tip/perf/urgent                         tracing: Fix stacktrace of latency tracers (irqsoff and friends)
59cfede    2012-04-19    trace/rfc/iolatency                           tracing: Add iolatency tracer
61463fa    2012-04-24    trace/tip/perf/core                           ftrace/x86: Remove the complex ftrace NMI handling code
e201738    2012-04-26    trace/tip/perf/core-2                         ftrace/x86: Remove the complex ftrace NMI handling code
053cef1    2012-04-27    trace/rfc/tracing/fentry                      ftrace/x86: Add support for -mfentry to x86_64
4a6d70c    2012-04-27    trace/tip/perf/core-3                         ftrace/x86: Remove the complex ftrace NMI handling code
a76c3eb    2012-04-30    trace/rfc/kprobes/ftrace                      ftrace/x86: Add support for x86_32 to pass pt_regs to function tracer
6e1b77e    2012-05-02    trace/rfc/kprobes/ftrace-v2                   kprobes: Update header for ftrace optimization
a4cc5f1    2012-05-02    trace/tip/perf/next-2                         ftrace/x86: Add separate function to save regs
9bd8569    2012-05-02    trace/tip/perf/next                           trace: Make removal of ring buffer pages atomic

It lists the branches in order of date of last commit.

Again, just showing some things that I find useful. If no one else finds
these interesting, then just ignore it. I have my scripts :-)

-- Steve

Attachment: git-ls
Description: Perl program