Linus,
This includes two fixes, one of which seems to have fell under your
radar before:
http://groups.google.com/group/linux.kernel/browse_thread/thread/b0a0880f3e0f415a/188f12ab40b7a6c9?show_docid=188f12ab40b7a6c9
But that's fine, as I pulled in Russ's patch after merging your tree,
and it did not do a fast forward of your tree. I didn't notices that
it did that, and it seemed a bit strange to do a commit for a fast
forward.
Is git set up to not fast forward by default? (I need to give it another try)
Anyway, changed my tree to be a fast forward (you haven't pulled it
yet, so no harm done with a rebase), and I added another fix.
New signed tag.
Please pull the latest ktest-for-v3.4-rc5 tree, which can be found at:
git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-ktest.git
ktest-for-v3.4-rc5
Head SHA1: b66786c7ff4441f0b9ac3b05f8e62cad75df65ff
Russ Dill (1):
ktest.pl: Fix combined usage of BISECT_REVERSE and BISECT_SKIP
Steven Rostedt (1):
ktest: Fix reboot on success stopping all reboots
----
tools/testing/ktest/ktest.pl | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
On Tue, May 1, 2012 at 5:44 PM, Steven Rostedt <[email protected]> wrote:
>
> Is git set up to not fast forward by default? (I need to give it another try)
Git will fast-forward by default if you do a pull and there is no
development of your own in your tree.
There are two exceptions:
- you explicitly say that you don't want to fast-forward (--no-ff or
"[merge] ff=false" in the git config file)
- if you pull a signed tag with a modern version of git.
That second case may be what you hit.
If you do a
git pull linus v3.4-rc5
in order to just update to the state of my latest tag, then git will
assume you want to do a new commit (and thus a non-fast-forward) just
so that git can record the tag signature in the commit.
The sad part is that I don't think you can even override the second
case. IOW, I think even "git pull --ff linus v3.4-rc5" will still do a
non-fast-forward merge.
That's inconvenient, and an unintended consequence of the behavior I
wanted as a top-level maintainer. But I really do think it's wrong for
normal developers who might validly just want to update to some
particular tagged release.
Junio? Any ideas?
Linus
Hi Linus,
On Tue, 1 May 2012 19:58:46 -0700 Linus Torvalds <[email protected]> wrote:
>
> The sad part is that I don't think you can even override the second
> case. IOW, I think even "git pull --ff linus v3.4-rc5" will still do a
> non-fast-forward merge.
git merge v3.4-rc5^{commit}
works, but that doesn't work for "git pull" :-( I tend to "fetch and
merge" rather than pull ...
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Linus Torvalds <[email protected]> writes:
> If you do a
>
> git pull linus v3.4-rc5
>
> in order to just update to the state of my latest tag, then git will
> assume you want to do a new commit (and thus a non-fast-forward) just
> so that git can record the tag signature in the commit.
>
> The sad part is that I don't think you can even override the second
> case.
> ...
> That's inconvenient, and an unintended consequence of the behavior I
> wanted as a top-level maintainer. But I really do think it's wrong for
> normal developers who might validly just want to update to some
> particular tagged release.
>
> Junio? Any ideas?
"Ideas" meaning "recipe to do with deployed binaries"?
When a normal developer wants to _reset to_ a particular tagged release,
in order to _start_ new work, she wouldn't be doing even the above "git
pull linus v3.4-rc5". That will contaminate the result with whatever
random stuff she happened to have on the current branch. A more natural
sequence would be "git fetch --tags linus" followed by either
git checkout v3.4-rc5 ;# to detach
or
git checkout -b mywork v3.4-rc5 ;# to start
So the case to "reset to" is not very interesting.
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.
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 ;-)
On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
> Linus Torvalds <[email protected]> writes:
>
> When a normal developer wants to _reset to_ a particular tagged release,
> in order to _start_ new work, she wouldn't be doing even the above "git
> pull linus v3.4-rc5". That will contaminate the result with whatever
> random stuff she happened to have on the current branch. A more natural
> sequence would be "git fetch --tags linus" followed by either
>
> git checkout v3.4-rc5 ;# to detach
The problem is, I like to know what has been pulled into mainline. I
have patches in quilt (for ktest only, not for my other work) and will
start adding them on a "clean" release. By doing a git pull (or fetch
and merge), I like to see the fast forward to know if everything that's
in my current branch has been pulled. If it hasn't, then something may
have been missed.
>
> or
>
> git checkout -b mywork v3.4-rc5 ;# to start
But then I would end up with several branches that would require
deleting. One way I could see myself in handling this case would be to
delete the current branch and start again (thinking that everything was
already pulled). But by doing that, if something wasn't pulled in, then
I would have lost those changes without ever knowing.
>
> So the case to "reset to" is not very interesting.
>
> 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.
>
> 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.
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
-- Steve
Steven Rostedt <[email protected]> writes:
> On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
>> Linus Torvalds <[email protected]> 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]
>> So the case to "reset to" is not very interesting.
>> 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.
>> 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 <[email protected]> writes:
>
> > On Tue, 2012-05-01 at 20:49 -0700, Junio C Hamano wrote:
> >> Linus Torvalds <[email protected]> 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
Steven Rostedt <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote:
> Steven Rostedt <[email protected]> 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...
There's also a patch that adds sorting support to "git branch":
http://thread.gmane.org/gmane.comp.version-control.git/188705
--
Duy