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

On Wed, 2012-05-02 at 13:14 -0700, Junio C Hamano wrote:

Steven Rostedt [off-list ref] writes:

quoted

On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:

quoted

Linus Torvalds [off-list ref] writes:

quoted

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.

quoted

$ 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