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