rostedt at goodmis
May 2, 2012, 5:07 PM
Post #7 of 10
On Wed, 2012-05-02 at 13:14 -0700, Junio C Hamano wrote:
Re: [PATCH 0/2] [GIT PULL] ktest: A couple of fixes
[In reply to]
> Steven Rostedt <rostedt [at] goodmis> writes:
> > On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
> >> Linus Torvalds <torvalds [at] linux-foundation> 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
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
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 :-)