On Wed, 2012-05-02 at 13:14 -0700, Junio C Hamano wrote:
Show 12 quoted lines
> Steven Rostedt <rostedt@goodmis.org> writes:
>
> > On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
> >> Linus Torvalds <torvalds@linux-foundation.org> 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.
Show 9 quoted lines
> > $ 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.
Show 11 quoted lines
> 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
Linus Torvalds
