Steven Rostedt [off-list ref] writes:
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]
quoted
So the case to "reset to" is not very interesting.
quoted
But when a normal developer wants to _sync to_ a particular tagged
release, in order to _continue_ working on her topic, she would need to
have a merge (unless she does not have _anything_ herself), and at that
point, merging v3.4-rc5 vs v3.4-rc5^0 would not make that much of a
difference. If she absolutely detests the "mergetag" header, she could do
a "git fetch --tags linus" followed by
git merge v3.4-rc5^0
which admittedly is two more letters than she used to type.
This would fit into my workflow. Thus I could use this.
OK.
quoted
If you mean by "Ideas" for additional features, obviously the last step
could be enhanced to use a more intuitive command line that requires the
user to type even more, i.e.
git merge --ff v3.4-rc5
Once that is done, "git pull --ff linus v3.4-rc5" would fall out as a
logical consequence.
But obviously these two would need new code ;-)
The -ff would make sense as it seems to be the logical thing a user
would want. If they specify the fast-forward flag, then the user would
expect the merge to be a fast forward if possible.
OK. Sounds like a good janitor project we could try to find a volunteer
on ;-).
BTW, is there a git compare type option. That is, I like to compare two
separate branches with the result that one currently gets with git when
a branch is following another branch. When you check out that branch, it
gives you an update on how those two branches are related (is one a fast
forward of the other, are they off by different commits?). It would be
nice if git could do this with any two branches. I wrote a script to do
this for me (attached) but it would be nice if git had it natively.
$ 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,
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.
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
Steven Rostedt [off-list ref] writes:
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 :-)
Well, there is "git branch -v -v":
$ git branch -v -v
[...]
gsoc2012-wiki 0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '"Published" and "secret" commits' project
html 8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c
i18n-po.pl aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations
maint bf50515 Git 1.7.10.1
[...]
t/doc-config-extraction 451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages
test b77178e gitweb: Separate features with no project specific override
todo 10c7888 Meta/dodoc: assign default values
user-manual 4c22f3d Comments to user-manual (WIP)
I guess that git-for-each-ref could be extended with behind / ahead
information, perhaps as modifiers to existing %(upstream) field...
P.S. I would associate "git ls" with listing worktree files.
--
Jakub Narebski
On Wed, 2012-05-02 at 17:33 -0700, Jakub Narebski wrote:
Steven Rostedt [off-list ref] writes:
Well, there is "git branch -v -v":
$ git branch -v -v
[...]
gsoc2012-wiki 0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '"Published" and "secret" commits' project
html 8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c
i18n-po.pl aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations
maint bf50515 Git 1.7.10.1
[...]
t/doc-config-extraction 451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages
test b77178e gitweb: Separate features with no project specific override
todo 10c7888 Meta/dodoc: assign default values
user-manual 4c22f3d Comments to user-manual (WIP)
I guess that git-for-each-ref could be extended with behind / ahead
information, perhaps as modifiers to existing %(upstream) field...
Would that list them in order then? Also, having the date printed is
useful, as I sometimes remember the approximate date a I worked on
something.
P.S. I would associate "git ls" with listing worktree files.
Yeah, I agree. I just wanted a script that had a short and easy name ;-)
git branch-sort
would probably be a better name.
On Thu, May 3, 2012 at 7:33 AM, Jakub Narebski [off-list ref] wrote:
Steven Rostedt [off-list ref] writes:
quoted
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 :-)
Well, there is "git branch -v -v":
$ git branch -v -v
[...]
gsoc2012-wiki 0e71ecb [gsoc2012/wiki/master: ahead 11, behind 4] '"Published" and "secret" commits' project
html 8b94cd8 Autogenerated HTML docs for v1.7.7.1-488-ge8e1c
i18n-po.pl aa8ce2e [git-i18n/ab/i18n-po: ahead 1] po/pl.po: Eliminate fuzzy translations
maint bf50515 Git 1.7.10.1
[...]
t/doc-config-extraction 451c2ef [git/trast/t/doc-config-extraction-v2: ahead 2257, behind 3] Documentation: complete config list from other manpages
test b77178e gitweb: Separate features with no project specific override
todo 10c7888 Meta/dodoc: assign default values
user-manual 4c22f3d Comments to user-manual (WIP)
I guess that git-for-each-ref could be extended with behind / ahead
information, perhaps as modifiers to existing %(upstream) field...
There's also a patch that adds sorting support to "git branch":
http://thread.gmane.org/gmane.comp.version-control.git/188705
--
Duy