* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Santi Béjar @ 2008-10-22 7:39 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022061730.GA5749@elte.hu>
On Wed, Oct 22, 2008 at 8:17 AM, Ingo Molnar <mingo@elte.hu> wrote:
[...]
> this welcome enhancement made me remember of three usage problems i had
> with Git recently:
>
> 1)
>
> Btw., it would be nice if there was an easier way to get a similar git
> log display in the ASCII space. For example i frequently ask the
> question "which topic branch did commit XYZ originate from?". All i have
> now is a pretty crude script that displays this for a given file:
>
> earth4:~/tip> tip-log --no-merges linus.. kernel/sched.c | grep ^#
> # core/kill-the-BKL: ffda12a: sched: optimize group load balancer
> # core/locking: ffda12a: sched: optimize group load balancer
> ...
>
> (see the script attached below)
>
> but it's very slow with 233 branches, obviously, so i only use it as a
> last resort mechanism.
>
> What i'd _love_ to see is just an ASCII representation of where a commit
> "came from" into the current branch. The first-hop branch it was
> committed to.
>
> it doesnt even have to be correct in the sha1 sense - i.e. it's enough
> for me if the merge commit log is parsed. (and hence it wont be correct
> if a branch ceases to exist or is renamed - but that is OK, i keep the
> branch space static)
>
> any ideas how to achieve that? I'd love to have output like this, if i
> do this from tip/master (the master integration branch):
>
> # mockup
>
> earth4:~/tip> gll --no-merges kernel/sched.c
> ffda12a: [sched/core] sched: optimize group load balancer
> 8cd162c: [sched/clock] sched: only update rq->clock while holding
> 0a16b60: [tracing/sched] tracing, sched: LTTng instrumentation
> a5d8c34: [sched/debug] sched debug: add name to sched_domain sysctl entries
> 34b3ede: [sched/core] sched: remove redundant code in cpu_cgroup_create()
>
> ... and i dont want to embedd the branch name in every single commit.
>
> The semantics seem well-specified to me: walk down the merge tree a
> particular commit came from, and use the branch name that is mentioned
> in a merge commit's comment section 'closest' to this commit.
>
> That information is not 'trustable' in the sha1 sense because merge
> commits can be modified manually and because the momentary name of a
> branch might not be correct anymore - but with a sane topical setup this
> would be a very powerful visualization tool.
>
> It would be a nice tool that makes it easy to check the proper structure
> of topical branches, after the fact. Weird, incorrectly queued up
> commits would stick out _immediately_:
>
> 34b3ede: [x86/xen] sched: remove redundant code in cpu_cgroup_create()
>
If you still have the tip of the branches you want to know, you can
get a similar output with:
$ git log --pretty=oneline builtin-checkout.c | git name-rev --stdin
828e32b82e3e2bb10d6d730d3abe505063b481f6 (remotes/origin/HEAD~17) Fix
mismerge at cdb22c4 in builtin-checkout.c
f285a2d7ed6548666989406de8f0e7233eb84368 (remotes/spearce/master~2)
Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializer
048f2762007d022defceb6850a44bc1bd5ccebf7 (remotes/spearce/master~24)
do not segfault if make_cache_entry failed
(sorry if it is refilled)
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Andreas Ericsson @ 2008-10-22 7:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, SLONIK.AZ, git
In-Reply-To: <81b0412b0810211543p6cb8c4ej49fb7fe70c3e2917@mail.gmail.com>
Alex Riesen wrote:
> 2008/10/22 Junio C Hamano <gitster@pobox.com>:
>> "Alex Riesen" <raa.lkml@gmail.com> writes:
>>> FWIW, I support Leo on that. The "established" behavior is stupid.
>> I am not inclined to respond to such an emotional argument. On the other
>> hand, it is fair to say that the existing behaviour is established,
>> because it is backed by a long history, which you can objectively verify.
>
> I found it illogical (well, stupid) and inconvinient
>
>> *1* It would be a different matter if the patch at the same time removed
>> the fetch/clone DWIMmery. At least such a patch would be internally self
>> consistent.
>
> Good idea.
No. Bad idea. That would not only break people's fetch configurations if
they've done clone on repos without passing .git, but also mean users
would have to remember if a particular server names their bare repos
"project.git".
If you remove *all* DWIMmery from fetch/clone, you'd also break people's
expectations when they're fetching from each other, as they'd have to pass
"git://devpeer/project/.git" instead of just "git://devpeer/project", which
is what *looks* sane.
A good idea would be to always report the name the user used. 'git clone'
already does that, recording the non-DWIMmed URL in the remotes config.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Ingo Molnar @ 2008-10-22 7:56 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0810220039g51d61e92l5ba254b57723d3b6@mail.gmail.com>
* Santi Béjar <santi@agolina.net> wrote:
> > It would be a nice tool that makes it easy to check the proper
> > structure of topical branches, after the fact. Weird, incorrectly
> > queued up commits would stick out _immediately_:
> >
> > 34b3ede: [x86/xen] sched: remove redundant code in cpu_cgroup_create()
> >
>
> If you still have the tip of the branches you want to know, you can
> get a similar output with:
>
> $ git log --pretty=oneline builtin-checkout.c | git name-rev --stdin
> 828e32b82e3e2bb10d6d730d3abe505063b481f6 (remotes/origin/HEAD~17) Fix
> mismerge at cdb22c4 in builtin-checkout.c
> f285a2d7ed6548666989406de8f0e7233eb84368 (remotes/spearce/master~2)
> Replace calls to strbuf_init(&foo, 0) with STRBUF_INIT initializer
> 048f2762007d022defceb6850a44bc1bd5ccebf7 (remotes/spearce/master~24)
> do not segfault if make_cache_entry failed
>
> (sorry if it is refilled)
i didnt know about git name-rev, nice tool!
below is sample output from tip/master. Would there be a way to reformat
it into a compact form, like:
d80f55f6: (master) Merge branch 'tracing/urgent'
17d80fd0: (tracing/urgent) tracing: create tracers menu
The most useful angle would be if git log --format had a way to print
the reverse name. Then i could do a git-log-line script like:
git log --pretty=format:"%h: %20N %s" $@
where %N prints the reverse name.
While at it: it would be nice if git log had a way to crop string
output. For example i'd love to use:
git log --pretty=format:"%h: %60s" $@
which would print out at most 60 characters from the first commit line.
That way i can see it properly on an 80 width terminal and can paste it
into email without linewraps, etc. But --pretty=format does not seem to
know width restrictions.
Ingo
d80f55f6711ab57ac5f4e147f9782a7351847ec1 (master) Merge branch 'tracing/urgent'
17d80fd07d35ae1d231b3378ee4f00ace54f9d31 (tracing/urgent) tracing: create tracers menu
debfcaf93ed500a051489db6646d71f29fe86a68 (tracing/urgent~1) Merge branch 'tracing/ftrace' into tracing/urgent
722fb95f2f57cdd4c6910675a7f342066ff131f7 (master~1) Merge branch 'tracing/core'
d24fdbbb398764fccaec317d6e354a5111493940 (tracing/core) Merge branch 'linus' into tracing/core
3e66b5d4a4c2265832d5e6fc0e36488fb1f06d84 (master~2) Merge branch 'kmemcheck'
22993cab5b465ad75fc17056141cf94ff57b4767 (master~3) Merge branch 'x86/uv'
b0f209898f1a177bd503d49215b8c6628797a81c (x86/uv) x86, uv: use consistent names for region size and conherence id on x86 and ia64
e811da01227ab5cf84aa616f1ce528533b6204f1 (master~4) Merge branch 'irq/urgent'
e85cd2b2ced8e0643a2ca769552b6f6e0cbbb470 (master~5) Merge branch 'core/urgent'
a56d4858686da0c97086c93d3f50d4020405c02b (core/urgent) printk: make variable static
3786fc710c32b61464c322e5cd0c3d1d34ae72d0 (irq/urgent) irq: make variable static
df4a3963c2f91586ff96f8962bccee4d14cb1100 (master~6) Merge branch 'x86/urgent'
8bcad30f2e6d4c20f7e71d2e2ac77acc0f0931e5 (x86/urgent) x86: make variables static
eefa4b484d1678e11c16d17b7e2d9e10bbfc1c3e (remotes/origin/HEAD) Merge branch 'out-of-tree'
50f971ad73ea9550b1d8e34006bd11c7e108b24f (out-of-tree) qa: disable jffs2 for now
c55c135163a1fb1869beefbce887c01fe50d31ed (remotes/origin/HEAD~1) range-hrtimers: merge timers/urgent
490bd253db3da535fb7e8129d8d648290d27206c (remotes/origin/HEAD~2) Merge branch 'timers/urgent'
aed24c813ce374751c0818be922c785ec9f83dea (remotes/origin/HEAD~3) NOHZ: restart tick device from irq_enter()
c4bd822e7b12a9008241d76db45b665f2fef180c (timers/urgent) NOHZ: fix thinko in the timer restart code path
fca45353be469acb7f961fd3b2b244f400098a7d (kmemcheck) kmemcheck: document the shadow member of struct page
50987b4becd23c0716631602c36a1be5ed74576c (kmemcheck~1) kmemcheck: update Kconfig help text
f899dff87c5f03c8fc9145a9472b7e7f7173bbaa (kmemcheck~2) kmemcheck: update documentation
af3f8f7ec6d1a35c9a99a50e4faafdc18249412c (kmemcheck~3) kmemcheck: fix mis-merge in sysctl table
24a528ca7f1473368bf97c67a697227e57170a7f (remotes/origin/HEAD~4) Merge branch 'linus'
439bbef95d7987acb821954db8f8c858c6bf6246 (remotes/origin/HEAD~5) Merge branch 'tracing/urgent'
ed8491f0e2c3378e2a84ddf5bb2d60b2e7c04113 (remotes/origin/HEAD~5^2) ftrace: fix section mismatch warning.
8b1c190e9605035b4efb1f3bc6684cbae9b87dda (remotes/origin/HEAD~6) Merge branch 'irq/urgent'
1bc1b5f7823035666d341b269dede4507b81a0bb (remotes/origin/HEAD~7) Merge branch 'core/urgent'
5f86515158ca86182c1dbecd546f1848121ba135 (core-fixes-for-linus) rcupdate: fix bug of rcu_barrier*()
b6f3b7803a9231eddc36d0a2a6d2d8105ef89344 (auto-sparseirq-next) genirq: NULL struct irq_desc's member 'name' in dynamic_irq_cleanup()
e9f95e637320efe1936b647308ddf4ec5b8e0311 (auto-sparseirq-next~1) genirq: fix off by one and coding style
935ddf564701da409ca960bf2f54db528daa79a3 (remotes/origin/HEAD~8) Merge branch 'irq/urgent'
8ca7f02cdb97f1fe581768593ba2288a2d0fe32f (remotes/origin/HEAD~8^2) genirq: fix off by one and coding style
be5272d9410fcbc57edbc9b2d212332ed9e76dff (remotes/origin/HEAD~9) Merge branch 'out-of-tree'
b6ec630b689e5f4694d8ea1f38798926a960dc2e (out-of-tree~1) net9p: work around build breakage
11f46c9d6d27ab4d359bafa0b9df0cc5e1ba4a1d (remotes/origin/HEAD~10) Merge branch 'x86/doc'
ff2904fb6daeefecb6f8c2c8c63ea41b833c1ded (remotes/origin/HEAD~10^2) Merge branch 'linus' into x86/doc
197ec4d0ce943259c11900aa0ee45cf4252d009a (remotes/origin/HEAD~11) Merge branch 'out-of-tree'
ae4038719e87e6cf2f815aa735909b615abd9121 (out-of-tree~2) mm fix: Re: unable to handle kernel NULL pointer derefence at 00000000
a331daffa5dd61e29bbc50ef258753c325815f69 (remotes/origin/HEAD~12) Merge branch 'x86/urgent'
27945ca30442e84d866735dde5cec3b0ba148d62 (remotes/origin/HEAD~13) Merge branch 'x86/pci-ioapic-boot-irq-quirks'
ee2caf0cee7f09953630209d63434eadd97b3f8f (remotes/origin/HEAD~14) manual merge of x86/doc
e523b1fdc81ba1aed0f9800e12d99a1c0f6fcd86 (remotes/origin/HEAD~15) Merge branch 'x86/cleanups'
1a6e0823a6863b9312faf6aa42f9913d25c65f66 (remotes/origin/HEAD~16) Merge branch 'warnings/simple'
d9067316e80df04a850e2cc6e92f43cb149700cc (remotes/origin/HEAD~17) Merge branch 'warnings/infrastructure'
a3a2394fadfc13818182ab0f8bfdbbfd01e84b57 (remotes/origin/HEAD~18) Merge branch 'warnings/complex'
64cf0f977c72dbe309a089439071c1d2714f6653 (remotes/origin/HEAD~19) Merge branch 'warnings/bug'
5cbb06a3ff222d3ffe6fe57f6f490bee31ae83ee (remotes/origin/HEAD~20) Merge branch 'tracing/urgent'
1c667db03bee74b1b25715a192f9b297761a9e00 (remotes/origin/HEAD~21) Merge branch 'tracing/markers'
1aa708f1c974d338b4bce75eec7f77ef3b748171 (remotes/origin/HEAD~22) Merge branch 'tracing/ftrace'
440c31d907ecdf4f7d7d213656e08f7a67e0c18d (remotes/origin/HEAD~23) Merge branch 'tracing/core'
396cc143ac608aa82cdf2d942a3d00d2ac333db2 (remotes/origin/HEAD~24) Merge branch 'timers/rtc'
22022cb8b6c8fdfe3cdc12f310203a28190f24de (remotes/origin/HEAD~25) manual merge of timers/range-hrtimers
f908633285b8e73cff179a52bc4f73d3d9b565f5 (remotes/origin/HEAD~26) manual merge of stackprotector
00f6c5901c6ac11c63b9057639756d3e4d2dc613 (remotes/origin/HEAD~27) Merge branch 'sched/urgent'
d4d79dc6ad5d9f43038ad7c717866c8fcae0173e (remotes/origin/HEAD~28) Merge branch 'safe-poison-pointers'
1552b31f9c6ee9e5e5cb92dea77e084aa13ff05a (remotes/origin/HEAD~29) Merge branch 'oprofile'
1ef89f7f876568c2d15731ae5ee39d384deabb05 (remotes/origin/HEAD~30) manual merge of kmemcheck-v2
1f92ca40e95515ee1f7685fb7049ecfc8c797ca0 (remotes/origin/HEAD~31) Merge branch 'irq/urgent'
a16fc956cb5021500a8d02547a99488c894f1413 (remotes/origin/HEAD~32) Merge branch 'irq/genirq-v3'
728b75cc6dfa6178bbbf20838eda60032a78fc2c (remotes/origin/HEAD~33) manual merge of irq/genirq
61b15a6bddc8625b6beda35e2d923d2844f59b95 (remotes/origin/HEAD~34) manual merge of cpus4096
62dd3c84287f6b59fe2f1e40c26a0d7e5d63516c (remotes/origin/HEAD~35) Merge branch 'core/urgent'
0868e883d967ac6c54e35a817c23a40a603d7551 (remotes/origin/HEAD~36) Merge branch 'core/percpu'
6eb9b1d2e751f3857229e48144fdc394ffaa6fe7 (remotes/origin/HEAD~37) Merge branch 'core/locking'
f89beb7bc5eba16660141122b34d99fe89fe9c65 (remotes/origin/HEAD~38) Merge branch 'core/futexes'
c483bd39bfcc57c931226955d4e83b71a4e01ce9 (remotes/origin/HEAD~39) Merge branch 'core/debug'
75e7035e679c462c0c9c6a1cb0dc60fbcc58d3d4 (remotes/origin/HEAD~40) Revert "NOHZ: restart tick device from irq_enter()"
39fc6adb39ea36f746b6c4137dc38012878ce02e (remotes/origin/HEAD~41) Merge branch 'out-of-tree'
8422ac179506d38eb3f432809e806dd012581270 (out-of-tree~3) staging: fix p80211wext_event_associated() build failure
d9c32f25101f22574aa861cb7f3fe58ebdf52232 (out-of-tree~4) qa: cx88: disable for now
e63003c9ec406578631c6322346ca0e326d99d46 (out-of-tree~5) qa: always-enable CONFIG_FILE_LOCKING
0be9b16320ac42f968245e55383a5dd9238b9c39 (out-of-tree~6) pci: fix: BUG: unable to handle kernel NULL pointer dereference, IP: pci_create_slot+0x28/0x170
d4d92fcc681f2a9b788fe228df1f9da3ef0cc111 (out-of-tree~7) dvb: disable dm1105
b56b096cb3b258eebc63ce36ba9ee332a1427d79 (out-of-tree~8) mfd: disable another driver
892cff77716a359fc2f6e159d846893d07bf11f4 (out-of-tree~9) drivers/mfd/Kconfig: turn off broken driver
93e60b49d3df9f8bab5079e9e796bce3c604e3ed (out-of-tree~10) security: initialize skb->sk_security by default
3cdfa5c3b0e1d60925497ced0cf908a2f078732c (out-of-tree~11) rtx2x00: disable for now
c8d7def4258375d88f0b6f06cc6f10c3a514a285 (out-of-tree~12) drm: fix leak of uninitialized data to userspace
17bc3f7bf083e754e5c6210eab7af9ce7ed02ebc (out-of-tree~13) Revert "Revert parts of "x86: update mptable""
ac2716510df12c6fa0e6b99ebb4aa68584a1a751 (out-of-tree~14) pnp: Huge number of "io resource overlap" messages
ced6e773aa88b80b0c6b519a84f1e85ff15e3416 (out-of-tree~15) acpi: don't load acpi_cpufreq if acpi=off
f6d62717fa9c6572f257720abac383a7ae5fdb62 (out-of-tree~16) wd.c: work around broken build
1327b0cc9ad75c246f6e4198cf9c1731afda4146 (out-of-tree~17) net, wd.c: fix undefined reference to `NS8390p_init'
75acfc78aa1a3ac46f473e39b8b294309f8a80c9 (out-of-tree~18) misdn: work around build bug
81ba9c8488248a766f7151eba1664e9d93f49701 (out-of-tree~19) hp-plus.c: work around build failure
70027001c8e97565fad148f371505f022eb1e779 (out-of-tree~20) USB: work around crash
985d392693af6bbd6bdabcad65d24edb3b64c4ed (out-of-tree~21) work around build breakage
18eed0ffd132f50660e7c1c16c48ec2af312de00 (out-of-tree~22) i2c: work around boot crash in amd756_s4882_init()
32347630cbf94685c4eaae6d645ba720a8b31d2b (out-of-tree~23) i2c workaround: turn off I2C_NFORCE2_S4985 for now
7120b52e90e1837e09bb4621f105022f940b856a (out-of-tree~24) work around this crash for now:
3966803bcaa7a7b82ac05959c66ce12ea5953111 (out-of-tree~25) ACPI: don't walk tables if ACPI was disabled
3ac23f215a2b1710ae7b4ee5569ddfe303386a4f (out-of-tree~26) ACPI, x86: disable the C2C3_FFH access mode if MWAIT is unsupported
1d8d02e53965633d7465e4d3881365d5f114cfd9 (out-of-tree~27) x86: enable speedstep for Intel Pentium M processor 7x0 [1.6-2.26 GHz] (Sonoma) processors
899b5030558b8dc21a171e2e8129e0a93fb08860 (out-of-tree~28) init: root mount fix
6894676b3486f75d8e0c0c777fa9d8bf883eec70 (out-of-tree~29) net: use numa_node in net_devcice->dev instead of parent
da684332e2dc25966ac39d0c57f21715db0eb80e (out-of-tree~30) tip: add -tip tag
c267f4dff573d67eb9a8645b5045d971a0a3bc7b (warnings/complex) fix warning in fs/ext4/extents.c
8501db35588df4f35d67d8ba207422006a214ae7 (warnings/complex~1) work around warning in fs/xfs/xfs_rtalloc.c
7cf87ad9e9dc30304ec862b45156e93d2c255911 (warnings/complex~2) fix warning in drivers/net/mlx4/mcg.c
6e0ffadd6edcdc2bfc8a526a4f6f7644815fd1ed (warnings/complex~3) fix warning in drivers/net/mlx4/profile.c
faad95db248fffe94b691a9c8f9cd0193584633a (warnings/complex~4) fix warning in arch/x86/kernel/setup.c
4f4e11e8dce3f4d76f7196b2af7f8c28067f902b (warnings/complex~5) fix warning in drivers/isdn/i4l/isdn_ppp.c
4b9fa1a9927b4fec31c68b2d7d20384a01363b47 (warnings/complex~6) fix warning in arch/x86/kernel/early-quirks.c
159583619a768eb78ec81bf9ca96fa0096699083 (warnings/complex~7) fix warning in drivers/base/platform.c
bfbde60a78f6d467e41c557b44ec741d92ba61f0 (warnings/complex~8) fix warning in drivers/pci/pci-driver.c
6ddae344a73fcff60c840dd4e429bf55562b41f3 (warnings/complex~9) #ifdef complications in drivers/acpi/sleep/main.c
4b57d6ee2dc9a1062521298ad2d87b24aa5d12e4 (warnings/complex~10) fix warning in net/ax25/sysctl_net_ax25.c
b5532a323def96dda020cc19d326c2d456b3befc (warnings/complex~11) fix warnings in drivers/acpi/sbs.c
ec9e8767ceacedbac9a1ed60d815e9f37ea98a31 (warnings/complex~12) fix warning in sound/pci/cs46xx/cs46xx_lib.c
76a62692c3328c2870949b07ee10dff764701faf (warnings/complex~13) fix warning in net/sunrpc/xprtrdma/verbs.c
d41b73d05e0f4c99255e18de064adeac79e32af2 (warnings/complex~14) fix warning in net/bluetooth/rfcomm/sock.c
035aca6532256d0b5a31c7dfc989c3af223aae9e (warnings/complex~15) fix warning in drivers/video/matrox/matroxfb_crtc2.c
3e67d911f11fb73d716bffc6d056730ced7b9f11 (warnings/complex~16) fix warning in drivers/char/rtc.c
8f845313ba091a6041e666c611ef9bb751d91723 (warnings/complex~17) fix warning in ipc/ipc_sysctl.c
34483bdb925851a069c8ad32801a52382f3a6d31 (warnings/complex~18) fix warning in drivers/usb/misc/vstusb.c
98fa7e0f5af226c5343b5bcdd4c5435c120acd8e (warnings/complex~19) fix warning in drivers/message/fusion/mptbase.c
956ae9e7f7535aa15a9e5f2dce1c7dc0dada2be2 (warnings/complex~20) fix warning in kernel/profile.c
e698275468fae57af762b81dbc64fac09909e1ec (warnings/complex~21) fix warning in drivers/net/wireless/ray_cs.c
830ecfa8290ba6d332bd809b330977338190abbe (warnings/complex~22) fix warning in sound/pci/hda/patch_sigmatel.c
76b04a364261b872602ce73c659534b1cde1b7ae (warnings/complex~23) fix warning in drivers/scsi/advansys.c
2020ebad843222e5e965d1a76584da5737da1e89 (warnings/complex~24) fix warning in arch/x86/kernel/cpu/intel_cacheinfo.c
aca9c3a12781b0184be4d2bf4f906206394710db (warnings/complex~25) fix warning in drivers/isdn/i4l/isdn_common.c
d489f40fdffc0432a4deffa8c6b538c5d6c76990 (warnings/complex~26) fix warning in drivers/net/wan/syncppp.c
32a1ce224a376395351d534f5a3cdbf09a1bb0a8 (warnings/complex~27) fix warning in net/netfilter/nf_conntrack_proto_sctp.c
055231c21d70848060852892d63bb0ed1db22ac5 (warnings/complex~28) fix warning in net/netfilter/ipvs/ip_vs_ctl.c
2262c8b220ab3b07ae07775b7ccb676ed24ac5f6 (warnings/complex~29) fix warning in drivers/char/rocket.c
6f9fecb3d70400c5f99c1a1d09ffcce84483f611 (warnings/complex~30) fix warning in arch/x86/kernel/scx200_32.c
1fdf3e8b2702553b5c99cd57fd7445de3b976b9c (warnings/complex~31) fix warning in drivers/net/atlx/atl2.c
fa8e55eb6d126214b56c1291b6163bb698be094f (warnings/complex~32) include/linux/init.h: fix warning in drivers/crypto/hifn_795x.c
5a74eb70b93ead02290817d85f0064df833d429f (warnings/complex~33) fix warning in drivers/video/aty/atyfb_base.c, #2
cc499e1b8c2a2e4b6f2bfbfaea1bf14b3d8ca9ee (warnings/complex~34) fix warning in drivers/video/aty/atyfb_base.c
dee28be5adf98095ffba0681b9d50b5193530787 (warnings/complex~35) fix warning in fs/coda/sysctl.c
6bbf3e6297bfac50ab1f26c95dded0163a7f5351 (warnings/complex~36) fix warning in net/netfilter/nf_conntrack_proto_tcp.c
47ac1136e2314d7c65d65b114a17751728f61f93 (warnings/complex~37) fix warning in drivers/media/dvb/dvb-usb/anysee.c
d569696a616ac0ca0b440d84071f83e77b00f452 (warnings/complex~38) fix warning in drivers/net/wireless/iwlwifi/iwl-scan.c
15d50b15843ccea15667f0bff5eb54d389a445f9 (warnings/complex~39) lockdep: include/linux/lockdep.h - fix warning in net/bluetooth/af_bluetooth.c
5a0d58611372742163d2727812f36527321abfe3 (warnings/complex~40) fix warning in drivers/watchdog/w83697ug_wdt.c
0faf3f9d4728e23b877279f3a239d8c9c59cd5dd (warnings/complex~41) fix warning in drivers/net/wireless/libertas_tf/if_usb.c
609d5948fd3f59132f48de6360fc46d0bbecd8a7 (warnings/complex~42) fix warning in drivers/mfd/ucb1400_core.c
8858ab02a18e82675cec3a99984767ef7445084f (warnings/complex~43) fix warning in drivers/scsi/dtc.c
129e100e56a451534307b800ece2cc9ffbfa0fae (warnings/complex~44) fix warning in drivers/isdn/sc/timer.c
a70d2056f7d297e2ae39b89d72e7a3b7734cfa9e (warnings/complex~45) fix warning in drivers/isdn/sc/ioctl.c
4646ee0cad4328de4d4c30f838dc27109b54dcd3 (warnings/complex~46) fix warning in drivers/net/depca.c
ca9a950c830f529766cc422a29c4822271eb5406 (warnings/complex~47) fix warning in drivers/net/3c523.c
2e4f5630f57f155cbd07771c3a305f48b991f90c (warnings/complex~48) fix warning in drivers/scsi/g_NCR5380.c
7f941db396f1fdc0e010916b5a613b5b7d522c14 (warnings/complex~49) fix warning in drivers/isdn/sc/shmem.c
cc2efdd1b01a3caa7ce93d301d9a3e23ea0457ee (warnings/complex~50) fix warning in drivers/mca/mca-legacy.c
24842fb0217e3cf2988de77830ae1adee295a167 (warnings/complex~51) fix warning in drivers/isdn/icn/icn.c
c85193d4a954684f4269c4ed4f6f7b391d63797e (warnings/complex~52) fix warning in drivers/infiniband/hw/amso1100/c2_vq.c
299711a947ae5f818fa5f3e3d2c4fe22466a03ca (warnings/complex~53) fix warning in drivers/input/touchscreen/htcpen.c
dd4c80c5dedf66d1840fc372a9f7418f32d138df (warnings/complex~54) fix warning in drivers/isdn/sc/init.c
ec5aa2f441bacc89b2e0e9e4971c6c9aa460942a (warnings/complex~55) fix warning in drivers/watchdog/i6300esb.c
ee5aa63192e5b545c0f89c84dbfdb5cc4deea113 (warnings/complex~56) fix warning in kernel/power/main.c
e16a7ed48454125ff97a644742398022f72321dd (warnings/complex~57) fix warning in fs/compat_binfmt_elf.c
606c6806381192653211492b07592df9430c7865 (warnings/complex~58) fix warning in drivers/pci/search.c
037abd9c198336c3aa9024de149e6b640877be2f (warnings/complex~59) fix warning in drivers/isdn/hardware/eicon/message.c
f72bccd1611f4dafd875e993cff5017a4a73ec6d (warnings/complex~60) warnings: disable i2o on 64bit
8077af8b47a9ec1c76997a9516f0335638ee51c0 (warnings/complex~61) warnings: fix xfs posix acl
0b3682ba33c59a362901b478bdab965da888b350 (auto-sparseirq-next~2) genirq: fix set_irq_type() when recording trigger type
2515ddc6db8eb49a79f0fe5e67ff09ac7c81eab4 (kmemcheck-v2) binfmt_elf_fdpic: Update for cputime changes.
a50c22eed593f474e75f693381e4d42e81762de8 (kmemcheck-v2~1) mm: remove duplicated #include's
e798ba57e9f423dddbf1bdeb20a62bdd0593890f (kmemcheck-v2~2) Export tiny shmem_file_setup for DRM-GEM
653c03168348ac7aebb969931f87ba281749d7dd (kmemcheck-v2~3) misc: replace remaining __FUNCTION__ with __func__
e8848a170fd432bdda176a2d568919d4bba90467 (kmemcheck-v2~4) fix CONFIG_HIGHMEM compile error in drivers/gpu/drm/i915/i915_gem.c
f6f286f33e843862c559bfea9281318c4cdec6b0 (kmemcheck-v2~5) fix WARN() for PPC
5f41b8cdc6ef33b3432cee36264d628a80398362 (kmemcheck-v2~6) kexec: fix crash_save_vmcoreinfo_init build problem
e3d2f927f788adcdabc42f8a1616f6cc56c53bbe (kmemcheck-v2~7) Merge git://git.kernel.org/pub/scm/linux/kernel/git/kyle/parisc-2.6
a9b6148d25f15ddfe9d7a7f3e526fdb64e7cf7da (auto-core-next-base) USB: Fix unused label warnings in drivers/usb/host/ehci-hcd.c
9b7530cc329eb036cfa589930c270e85031f554c (auto-core-next-base~1) i915: cleanup coding horrors in i915_gem_gtt_pwrite()
1ae87786800b5e0411847974b211797b6ada63c4 (auto-core-next-base~2) Fix sprintf format warnings in drm_proc.c
2bea2e4abf2fe8bc7384103aeaad91089109cfba (auto-core-next-base~3) Merge branch 'bkl-removal' of git://git.lwn.net/linux-2.6
a0bfb673dca8a2b4324fe11e678ec6d6a9ad67e0 (auto-core-next-base~4) Merge branch 'linux-next' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6
92b29b86fe2e183d44eb467e5e74a5f718ef2e43 (auto-core-next-base~5) Merge branch 'tracing-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
b9d7ccf56be1ac77b71a284a1c0e6337f9a7aff0 (auto-core-next-base~6) Merge branch 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
9301975ec251bab1ad7cfcb84a688b26187e4e4a (auto-core-next-base~7) Merge branch 'genirq-v28-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
7110879cf2afbfb7af79675f5ff109e63d631c25 (auto-core-next-base~8) Merge branch 'core-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
99ebcf8285df28f32fd2d1c19a7166e70f00309c (auto-core-next-base~9) Merge branch 'v28-timers-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
72558dde738b06cc01e16b3247a9659ca739e22d (auto-core-next-base~10) Merge git://git.kernel.org/pub/scm/linux/kernel/git/bart/ide-2.6
b91385236c00031c64b42b44db8068ad38a5ea11 (auto-core-next-base~11) Merge branch 'next' of git://git.kernel.org/pub/scm/linux/kernel/git/djbw/async_tx
d67ae206ef05198824c2a306c0c0edf2d2088920 (auto-core-next-base~12) Merge git://git.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog
1d9a8a47d659f053abeca9ece45651b4d94780c8 (auto-core-next-base~13) Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse
f07767fd0f95c385108fa4c456a9cb216a424fec (auto-core-next-base~14) byteorder: remove direct includes of linux/byteorder/swab[b].h
f4432c5caec5fa95ea7eefd00f8e6cee17e2e023 (auto-core-next-base~15) Update email addresses.
6da0b38f4433fb0f24615449d7966471b6e5eae0 (auto-core-next-base~16) fs/Kconfig: move ext2, ext3, ext4, JBD, JBD2 out
54b1d646d442289d8d49e04bc2f10ba122ff6aa4 (warnings/simple) sound/soc/codecs/tlv320aic23.c: remove unused variable
0be735b3ff71e13e24b82420f23a1b3b0a207ffb (warnings/simple~1) net/mac80211/rc80211_minstrel_debugfs.c: fix return type
04271505e03535e1fd085c96085fcee41e7c415f (warnings/simple~2) [vfs] fs.h: fops_get()/fops_put(): use pointer comparison
f81ee5ca545020daf0ddfff3744199b87bbd8c70 (warnings/simple~3) include/linux/fs.h: improve type checking of __mandatory_lock()
5baf34fc63c31ef676e0a764415b10e5cc1c7a4b (warnings/simple~4) net/netlabel/netlabel_addrlist.c: add type checking to audit_log_format()
d58cbf52cb25e215c0e34048bda8ec481bdce4af (warnings/simple~5) fs/afs/dir.c: fix uninitialized variable use
19be5d76a014ce0e743848a42cbb3b579c0ad8d7 (warnings/simple~6) drivers/video/cirrusfb.c: remove unused variables
d138e44e2f8d0f26e04b0386d328d9cc7e33d82e (warnings/simple~7) drivers/net/wireless/b43/phy_g.c: type check debug printouts
f11adf3c65aff25074d5d3a90d72cdfc40d66b50 (warnings/simple~8) drivers/ide/pci/hpt366.c: remove unused variable
ecd05381e26b9a61e49fa485baea1595bd3d1b40 (warnings/simple~9) x86: fix default_spin_lock_flags() prototype
0d468300dc97d6aec084799ffe39253ac366f1e4 (auto-core-next-base~17) Remove empty imacfb.c file
96499871f45b9126157b1a5c512d6e30f1635225 (auto-core-next-base~4^2) PCI: fix pci_ioremap_bar() on s390
db7a6d8d01b21829d28638258cbbc9553210bac1 (auto-core-next-base~18) Update .gitignore files for generated targets
270c66be9b4a6f2be53ef3aec5dc8e7b07782ec9 (auto-core-next-base~4^2~1) PCI: fix AER capability check
0927678f55c9a50c296f7e6dae85e87b8236e155 (auto-core-next-base~4^2~2) PCI: use pci_find_ext_capability everywhere
1543c90c39360df333a21bfbbdfe812ae23b8167 (auto-core-next-base~4^2~3) PCI: remove #ifdef DEBUG around dev_dbg call
bd1d9855be3ab8a5c2b31053d464b7fe63e6963b (auto-core-next-base~4^2~4) PCI hotplug: fix get_##name return value problem
e5665a45fa28d0114f61b5d534a3b2678592219d (auto-core-next-base~4^2~5) PCI: document the pcie_aspm kernel parameter
aa42d7c6138afdc54f74e971456a0fbfec16b77b (auto-core-next-base~4^2~6) PCI: introduce an pci_ioremap(pdev, barnr) function
e9f82cb75096ae30658a72d473bf170bf4d3bb2e (auto-core-next-base~4^2~7) powerpc/PCI: Add legacy PCI access via sysfs
f19aeb1f3638b7bb4ca21eb361f004fac2bfe259 (auto-core-next-base~4^2~8) PCI: Add ability to mmap legacy_io on some platforms
f393d9b130423a7a47c751b26df07ceaa5dc76a9 (auto-core-next-base~4^2~9) PCI: probing debug message uniformization
58c3a727cb73b75a9104d295f096cca12959a5a5 (auto-core-next-base~4^2~10) PCI: support PCIe ARI capability
201de56eb22f1ff3f36804bc70cbff220b50f067 (auto-core-next-base~4^2~11) PCI: centralize the capabilities code in probe.c
280c73d3691fb182fa55b0160737c2c0feb79471 (auto-core-next-base~4^2~12) PCI: centralize the capabilities code in pci-sysfs.c
e354597cce8d219d135d65e585dc4f30323486b9 (auto-core-next-base~4^2~13) PCI: fix 64-vbit prefetchable memory resource BARs
557848c3c03ad1d1e66cb3b5b06698e3a9ebc33c (auto-core-next-base~4^2~14) PCI: replace cfg space size (256/4096) by macros.
022edd86d7c864bc8fadc3c8ac4e6a464472ab05 (auto-core-next-base~4^2~15) PCI: use resource_size() everywhere.
c322b28a04c084a467a862766f74c40c917a721c (auto-core-next-base~4^2~16) PCI: use same arg names in PCI_VDEVICE comment
5d9bc1fa47f0c1561f1d7c0bdff5e24860852b42 (auto-core-next-base~4^2~17) PCI hotplug: rpaphp: make debug var unique
c9bbb4abb658daf6cc6f92fb4751a7796a5aab75 (auto-core-next-base~4^2~18) PCI: use %pF instead of print_fn_descriptor_symbol() in quirks.c
c8761fe80ed052634153438405c9048611ae7ae1 (auto-core-next-base~4^2~19) PCI: fix hotplug get_##name return value problem
11d587429e9cbb40ac20d7ed8126c66da0d7aba5 (auto-core-next-base~4^2~20) PCI: fix sparse warning in pci_remove_behind_bridge
50cbfa511a21cac1909b6b4c955fa39d1da81457 (auto-core-next-base~4^2~21) PCI: fix MSI-HOWTO.txt info about MSI-X MMIO space
ec84f1268fcf16c4a852fdb38b3a541748644918 (auto-core-next-base~4^2~22) PCI: fix -Wakpm warnings in pci_pm_init debug output
cef354db0d7a7207ea78c716753d9216a9c2b7e1 (auto-core-next-base~4^2~23) PCI: connect struct pci_dev to struct pci_slot
93ff68a55aa92180a765d6c51c3303f6200167a6 (auto-core-next-base~4^2~24) PCI: make CPU list affinity visible
5993760f7fc75b77e4701f1e56dc84c0d6cf18d5 (auto-core-next-base~4^2~25) PCI: utilize calculated results when detecting MSI features
7f2feec140f1f1e4f701e013a2bf8284a9ec2a3c (auto-core-next-base~4^2~26) PCI: pciehp: replace printk with dev_printk
83e9ad540b9ee23919961f9500ca254220b78d09 (auto-core-next-base~4^2~27) PCI: pciehp: change name tag of "hpdriver_portdrv" variable
37a84ec668ba251ae02cf2c2c664baf6b247ae1f (auto-core-next-base~4^2~28) x86/PCI: irq and pci_ids patch for Intel Ibex Peak DeviceIDs
f7a10e32a1a7ae240fa3925c5727d224eba3e31d (auto-core-next-base~4^2~29) PCI: pciehp: fix irq initialization
c01156061bdd5976397dfb173f8c70ae351a6cb6 (auto-core-next-base~4^2~30) PCI: Document that most pci options are shared between i386 and x86-64
c9ed77eeba8ec2541a40918210bcc676acacd43a (auto-core-next-base~4^2~31) PCI: tidy PME support messages
2fd39aa7c2f3d696814abb3e8962c759eee484f3 (auto-core-next-base~4^2~32) PCI: ibmphp: list_for_each to list_for_each_entry-checkpatch cleanups
a8d2dbd38481e0c35c6bdd8196dd38a42ae45d02 (auto-core-next-base~4^2~33) PCI: ibmphp: list_for_each to list_for_each_entry
34a2e15e95fce6d6f4d30162f53a0ceb25d5bbaf (auto-core-next-base~4^2~34) PCI: follow lspci device/vendor style
d768cb6929773060171eee8397a63883f60ddc07 (auto-core-next-base~4^2~35) x86/PCI: follow lspci device/vendor style
16dbef4a831782466b10d4ae56837c5ba17d1948 (auto-core-next-base~4^2~36) PCI: change MSI-x vector to 32bit
0235c4fc7fc6f621dc0dd89eba102ad5aa373390 (auto-core-next-base~4^2~37) PCI PM: Introduce function pci_wake_from_d3
3d137310245e4cdc3e8c8ba1bea2e145a87ae8e3 (auto-core-next-base~4^2~38) PCI: allow quirks to be compiled out
b41d6cf38e27a940d998d989526a9748de1bf028 (auto-core-next-base~4^2~39) PCI: Check dynids driver_data value for validity
edbc25caaa492a82e19baa915f1f6b0a0db6554d (auto-core-next-base~4^2~40) PCI: remove dynids.use_driver_data
592b7a88564a2167a144265bf68df0123c0e4e98 (tmp.master.prev~2^2) doc/x86: fix doc subdirs
921974982a7aab561a1c3ff1763af7470874ba8e (auto-core-next-base~19) Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
7d67474e506598fe26e0c262acf02132dc730517 (auto-core-next-base~20) Merge git://git.infradead.org/battery-2.6
252883e512c6d8fbc03b6738f1620fda44c4d472 (auto-core-next-base~21) epca: Add infinite break support
^ permalink raw reply
* Re: [PATCH] git-svn: don't escape tilde ('~') for http(s) URLs
From: Eric Wong @ 2008-10-22 8:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, git, jsogo
In-Reply-To: <7vtzb5wr6v.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Eric Wong <normalperson@yhbt.net> writes:
>
> >> strace revealed that git-svn url-encodes ~ while svn does not do that.
> >>
> >> For svn we have:
> >> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> >> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
> >>
> >> While git-svn shows:
> >> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> >> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
>
> This looks like an XML based request sequence to me (and svn is talking
> WebDAV here, right?); it makes me wonder what exact quoting rules are used
> there. I would expect $path in <S:src-path>$path</S:src-path> to quote
> a letters in it e.g. '<' as "<" --- which is quite different from what
> the s/// substitutions in the patch seem to be doing.
I agree. I haven't checked if the SVN libraries do proper XML escaping
for us (but the problem hasn't shown up yet :). I was already
completely disappointed that git-svn had to do its own escaping when
transmitting data using the SVN libraries (and dependent on the protocol
being used, too!).
> > diff --git a/git-svn.perl b/git-svn.perl
> > index ef6d773..a97049a 100755
> > --- a/git-svn.perl
> > +++ b/git-svn.perl
> > @@ -852,7 +852,7 @@ sub escape_uri_only {
> > - s/([^\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
> > + s/([^~\w.%+-]|%(?![a-fA-F0-9]{2}))/sprintf("%%%02X",ord($1))/eg;
>
> Admittedly I do not know git-svn (nor Perl svn bindings it uses), and I
> suspect that some of the XML-level escaping is done in the libsvn side,
> but it would be nice if somebody can at least verify that the code after
> the patch works with repositories with funny characters in pathnames
> (perhaps list all the printables including "<&>?*!@.+-%^"). Even nicer
> would be a log message that says "the resulting code covers all cases
> because it follows _that_ spec to escape _all_ problematic letters",
> pointing at some in svn (or libsvn-perl) resource.
Help with looking at what SVN does and writing testcases would
definitely be appreciated on this matter. Or perhaps this can be done
at GitTogether :)
> The patch may make a path with '~' work, but it (neither in the patch text
> nor in the commit log message) does not have much to give readers enough
> confidence that the code after the patch is the _final_ one, as opposed to
> being just a band-aid for a single symptom that happened to have been
> discovered this time.
This is definitely a band-aid fix until I or somebody else takes the
time to figure out:
1. exactly which characters need to be escaped
2. for which protocols those characters need to be escaped
3. which part(s) of the URI they need to be escaped for
(repository root vs SVN path)
4. which versions of SVN needs more (or less) escaping rules
(I vote for somebody else, especially for #4 :)
--
Eric Wong
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 8:20 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <1224622557-6669-1-git-send-email-angavrilov@gmail.com>
On Wed, Oct 22, 2008 at 12:55:57AM +0400, Alexander Gavrilov wrote:
> +test_expect_success \
> + 'blame respects i18n.commitencoding' '
> + git blame --incremental file | \
> + grep "^\(author\|summary\) " > actual &&
> + test_cmp actual expected
Even though it is POSIX, using backslashed grouping in 'grep' isn't
portable. It fails at least on Solaris 8, and you have to do:
egrep "^(author|summary) "
instead. Of course, I can't get your test to pass even with that change,
but I think that is just a broken iconv on Solaris.
-Peff
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Stephen Rothwell @ 2008-10-22 8:27 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Junio C Hamano, git
In-Reply-To: <20081022072923.GC27637@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 1292 bytes --]
On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> I've Cc:-ed Junio and the Git list as a general FYI - but it must be
> frustrating to get such a bugreport, because i have no reproducer.
>
> git-rerere sometimes seems to be picking up the wrong resolution. VERY
> rarely.
>
> It seems random and content dependent. Once it happened to
> arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170
> successful resolutions i have in my tree right now. And i do many
> conflict resolutions every day - and it happened only once every 6
> months or so.
>
> (the arch/x86/kernel/traps_32.c one happened regularly, that's why i
> thought it's content sha1 dependent, and not some corruption.)
>
> Next time it happens i'll be on the watchout and will save the complete
> tree.
I think rerere matches preimages on the SHA1 of the conflict (or its
reverse), so sufficiently similar pieces of code will match. I would
expect things like ext2/3/4 to be candidates. Did the traps_32.c one
match one for traps_64.c?
I may be mistaken, but I once followed the code in rerere to try to
figure out how to fix a resolution.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Stephen Rothwell @ 2008-10-22 8:31 UTC (permalink / raw)
To: Ingo Molnar
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Junio C Hamano, git
In-Reply-To: <20081022192725.5f5de711.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 566 bytes --]
On Wed, 22 Oct 2008 19:27:25 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> I think rerere matches preimages on the SHA1 of the conflict (or its
> reverse), so sufficiently similar pieces of code will match. I would
> expect things like ext2/3/4 to be candidates. Did the traps_32.c one
> match one for traps_64.c?
Or, of course similar conflicts in different merges in different branches
of the same tree are really asking for it ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: linux-next: stackprotector tree build failure
From: Ingo Molnar @ 2008-10-22 8:31 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Thomas Gleixner, H. Peter Anvin, linux-next, Junio C Hamano, git
In-Reply-To: <20081022192725.5f5de711.sfr@canb.auug.org.au>
* Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> On Wed, 22 Oct 2008 09:29:23 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > I've Cc:-ed Junio and the Git list as a general FYI - but it must be
> > frustrating to get such a bugreport, because i have no reproducer.
> >
> > git-rerere sometimes seems to be picking up the wrong resolution. VERY
> > rarely.
> >
> > It seems random and content dependent. Once it happened to
> > arch/x86/kernel/traps_32.c and now to kernel/fork.c. Along the ~170
> > successful resolutions i have in my tree right now. And i do many
> > conflict resolutions every day - and it happened only once every 6
> > months or so.
> >
> > (the arch/x86/kernel/traps_32.c one happened regularly, that's why i
> > thought it's content sha1 dependent, and not some corruption.)
> >
> > Next time it happens i'll be on the watchout and will save the complete
> > tree.
>
> I think rerere matches preimages on the SHA1 of the conflict (or its
> reverse), so sufficiently similar pieces of code will match. I would
> expect things like ext2/3/4 to be candidates. Did the traps_32.c one
> match one for traps_64.c?
>
> I may be mistaken, but I once followed the code in rerere to try to
> figure out how to fix a resolution.
the traps_32.c one was that git-rerere put in a traps_64.c end result.
So i ended up with a 32-bit kernel that tried to build a 64-bit piece of
code - fireworks. That condition persisted - i had to fix it up manually
all the time i integrated that portion of the tree. That too was i think
centered around a header file chunk - perhaps the #include section of
traps_32.c and traps_64.c was similar enough in that section?
Ingo
^ permalink raw reply
* [JGIT PATCH 1/3] Fix retrieval of test resources for paths containing spaces
From: Jonas Fonseca @ 2008-10-22 8:32 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
The use of URL.getPath() can be problematic when the repository path
contains spaces since they get encoded as %20, which will lead to a "No
such file" error when resolving to a local file. The fix first tries to
convert the resource URL to a URI (added in Java 1.5), which is then
used to construct the File instance. As a fallback use the old behavior
if a URISyntaxException is thrown.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../tst/org/spearce/jgit/util/JGitTestUtil.java | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java b/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
index bf2471d..eee0c14 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/util/JGitTestUtil.java
@@ -38,6 +38,7 @@
package org.spearce.jgit.util;
import java.io.File;
+import java.net.URISyntaxException;
import java.net.URL;
public abstract class JGitTestUtil {
@@ -57,7 +58,11 @@ public static File getTestResourceFile(final String fileName) {
// loaded previously
return new File("tst", fileName);
}
- return new File(url.getPath());
+ try {
+ return new File(url.toURI());
+ } catch(URISyntaxException e) {
+ return new File(url.getPath());
+ }
}
private static ClassLoader cl() {
--
1.6.0.2.1166.g8d97a.dirty
--
Jonas Fonseca
^ permalink raw reply related
* [JGIT PATCH 2/3] Fix FileTreeIteratorTest on Windows/NTFS
From: Jonas Fonseca @ 2008-10-22 8:33 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
Replace '.' with ',' in the test paths to keep the original intent, but
make the test runnable on systems where files named "a." cannot be
reliably created. The problem seems to be that a file created as "a."
will end up as "a" on disk.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../jgit/treewalk/FileTreeIteratorTest.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
With this all the tests pass on my Windows installation.
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/treewalk/FileTreeIteratorTest.java b/org.spearce.jgit.test/tst/org/spearce/jgit/treewalk/FileTreeIteratorTest.java
index ca31991..967557e 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/treewalk/FileTreeIteratorTest.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/treewalk/FileTreeIteratorTest.java
@@ -47,7 +47,7 @@
import org.spearce.jgit.util.RawParseUtils;
public class FileTreeIteratorTest extends RepositoryTestCase {
- private final String[] paths = { "a.", "a.b", "a/b", "a0b" };
+ private final String[] paths = { "a,", "a,b", "a/b", "a0b" };
private long[] mtime;
--
1.6.0.2.1166.g8d97a.dirty
--
Jonas Fonseca
^ permalink raw reply related
* [JGIT RFC PATCH 3/3] Rate limit warnings spewed by RepositoryTestCase.recursiveDelete
From: Jonas Fonseca @ 2008-10-22 8:34 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
On Windows XP / NTFS / NetBeans 6.1 / Java 5 a lot of warnings are
printed. In most cases the path is in fact deleted and it seems to just
be a timing bug or something Windows or NTFS specific. Also, many of the
warnings are for the same paths and therefore a bit redundant.
Furthermore, when a lot of warnings are printed it gives the feeling of
slowing down the tests. By rate limiting the warnings the problem is
still made visible for developers to notice.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
.../org/spearce/jgit/lib/RepositoryTestCase.java | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
This is mostly an annoyance fix, but might be acceptable.
diff --git a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
index 9d7d133..44e24d7 100644
--- a/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
+++ b/org.spearce.jgit.test/tst/org/spearce/jgit/lib/RepositoryTestCase.java
@@ -51,6 +51,8 @@
public abstract class RepositoryTestCase extends TestCase {
+ private static long deleteFailures;
+
protected final File trashParent = new File("trash");
protected File trash;
@@ -79,7 +81,7 @@ protected static void recursiveDelete(final File dir) {
}
}
dir.delete();
- if (dir.exists()) {
+ if (dir.exists() && deleteFailures++ < 42) {
System.out.println("Warning: Failed to delete " + dir);
}
}
--
1.6.0.2.1166.g8d97a.dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Andreas Ericsson @ 2008-10-22 8:34 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022061730.GA5749@elte.hu>
Ingo Molnar wrote:
> Git recently started printing the branch name when creating commits:
>
> [irq/urgent]: created 3786fc7: "irq: make variable static"
>
> very nice idea IMO!
Thanks! Be sure to read the paintshop discussion that lead to the
change ;-)
> Having it all on one line allows me to double-check
> that i indeed queued up a patch in the intended topic branch. Had it
> read:
>
> [irq/urgent]: created 3786fc7: "printk: make variable static"
>
> i'd have noticed the mistake immediately.
>
> this welcome enhancement made me remember of three usage problems i had
> with Git recently:
>
> 1)
>
> Btw., it would be nice if there was an easier way to get a similar git
> log display in the ASCII space. For example i frequently ask the
> question "which topic branch did commit XYZ originate from?". All i have
> now is a pretty crude script that displays this for a given file:
>
> earth4:~/tip> tip-log --no-merges linus.. kernel/sched.c | grep ^#
> # core/kill-the-BKL: ffda12a: sched: optimize group load balancer
> # core/locking: ffda12a: sched: optimize group load balancer
> ...
>
> (see the script attached below)
>
> but it's very slow with 233 branches, obviously, so i only use it as a
> last resort mechanism.
>
> What i'd _love_ to see is just an ASCII representation of where a commit
> "came from" into the current branch. The first-hop branch it was
> committed to.
>
> it doesnt even have to be correct in the sha1 sense - i.e. it's enough
> for me if the merge commit log is parsed. (and hence it wont be correct
> if a branch ceases to exist or is renamed - but that is OK, i keep the
> branch space static)
>
> any ideas how to achieve that? I'd love to have output like this, if i
> do this from tip/master (the master integration branch):
>
If you have the branch-heads around, do "git branch --contains <sha1>".
If I understand the i386 tree correctly (integration branches are named
without slashes), you could pipe it to "grep /" to see only the
topic-branches that has it.
I imagine you'd want to use it to find out which branches you can (or
can't) merge, and in that case you need to know about all the topics
which have the commit. Assuming you don't go crazy cherry-picking and
criss-cross merging, it should only list a few. The output is not as
fancy as below, but it should be faster than the appended script (by
several orders of magnitude).
> # mockup
>
> earth4:~/tip> gll --no-merges kernel/sched.c
> ffda12a: [sched/core] sched: optimize group load balancer
> 8cd162c: [sched/clock] sched: only update rq->clock while holding
> 0a16b60: [tracing/sched] tracing, sched: LTTng instrumentation
> a5d8c34: [sched/debug] sched debug: add name to sched_domain sysctl entries
> 34b3ede: [sched/core] sched: remove redundant code in cpu_cgroup_create()
>
> ... and i dont want to embedd the branch name in every single commit.
>
> The semantics seem well-specified to me: walk down the merge tree a
> particular commit came from, and use the branch name that is mentioned
> in a merge commit's comment section 'closest' to this commit.
>
> That information is not 'trustable' in the sha1 sense because merge
> commits can be modified manually and because the momentary name of a
> branch might not be correct anymore - but with a sane topical setup this
> would be a very powerful visualization tool.
>
> It would be a nice tool that makes it easy to check the proper structure
> of topical branches, after the fact. Weird, incorrectly queued up
> commits would stick out _immediately_:
>
> 34b3ede: [x86/xen] sched: remove redundant code in cpu_cgroup_create()
>
> 2)
>
> and while at ASCII representation - this made me remember a problem i
> frequently have with octopus merges: it's _very_ difficult currently to
> 'backtrack' along a higher-order octopus in the git log ASCII space.
>
> I dont use the newfangled flashy GUIs all that frequently and i recently
> tried to go back to double-check the history of this order-21 octopus
> merge in the upstream Linux kernel:
>
> commit e496e3d645c93206faf61ff6005995ebd08cc39c
> Merge: b159d7a... 5bbd4c3... 175e438... 516cbf3... af2d237... 9b15684... 5b7e41f... 1befdef... a03352d... 7b22ff5... 2c7e9fd... 91030ca... dd55235... b3e15bd... 20211e4... efd327a... c7ffa6c... e51a1ac... 5df4551... d99e901... e621bd1...
> Author: Ingo Molnar <mingo@elte.hu>
> Date: Mon Oct 6 18:17:07 2008 +0200
>
> Merge branches 'x86/alternatives', 'x86/cleanups', 'x86/commandline', 'x86/crashdump', 'x86/debug', 'x86/defconfig', 'x86/doc', 'x86/exports', 'x86/fpu', 'x86/gart', 'x86/idle', 'x86/mm', 'x86/mtrr', 'x86/nmi-watchdog', 'x86/oprofile', 'x86/paravirt', 'x86/reboot', 'x86/sparse-fixes', 'x86/tsc', 'x86/urgent' and 'x86/vmalloc' into x86-v28-for-linus-phase1
>
> i wanted to know the history of the 'x86/idle' topical commits. But it
> was not easy to line up the sha1's to the branch names. So i had to
> manually edit the commit log, i manually lined up all 21 sha1's to each
> other, just to be able to figure out branch #11 in that lineup.
>
> Is there some more efficient way to do that? Perhaps some git log output
> that matches up the topic names with the sha1's? [for the cases where
> the octopus merge commit log message still has a reasonable format]
>
A mock-up of desired output would be good here. Perhaps something like this?
--%<--%<--
<X>-way octopus merge
x86/alternatives <abbrev sha1>: "<abbreviated x86/alternatives subject>"
x86/cleanups <abbrev sha1>: "<abbreviated x86/cleanups subject>"
Signed-off-by: ...
--%<--%<--
The subject for this says absolutely nothing, but it's not so long that it
can't be viewed comfortably either, and hopefully the author will amend
the subject with something suitable.
> 3)
>
> Similarly, when doing Octopus merges, and if the merge _fails_, it's
> hard to see exactly which branch failed. For example, when preparing for
> the v2.6.28 merge window i did something like this at a certain stage:
>
> git merge x86/alternatives x86/cleanups x86/commandline \
> x86/crashdump x86/debug x86/defconfig x86/doc \
> x86/exports x86/fpu x86/gart x86/xen x86/idle x86/mm \
> x86/mtrr x86/nmi-watchdog x86/oprofile x86/paravirt \
> x86/reboot x86/sparse-fixes x86/tsc x86/urgent \
> x86/vmalloc
>
> I got a conflicted octopus merge somewhere in the middle of it. But it
> only displayed sha1's when doing the merge. When i did a git log of that
> sha1 it was not obvious at first sight which current branch maps to that
> sha1. So i had to binary-search for the branch that caused the conflict
> (!), to figure out that in the above sequence the 'x86/xen' bit is what
> was causing trouble.
>
> It would be very nice if the Octopus merge tool displayed not only the
> sha1's that it is merging, but also the refspec that it is processing.
> And when it fails it would be nice if it displayed a for-dummies
> "Octopus merge failed when trying to merge x86/xen" kind of thing.
>
> So mapping back sha1's to topic branch names does not seem to be very
> easy at the moment. I realize that it is a fundamentally hard thing to
> do, and the information is not reliable because branch names are
> temporary - but in a sane branch setup it would be very nice to have
> tools for that, to keep topics nice and tidy, and to annotate git logs
> with the topical information.
>
Branch-names may be temporary, but we already record them for merge
messages so I don't see why we couldn't also use them when reporting
error messages but in a different format. I had a quick look at the
git-merge-octopus.sh but didn't find the obvious place to hack this
thing in, so I'll have to defer that to someone for whom this is a
more pressing need (hint ;-)), or who knows their way around gits
plumbing better than I do.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Alexander Gavrilov @ 2008-10-22 8:35 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20081022082016.GA18473@sigill.intra.peff.net>
On Wed, Oct 22, 2008 at 12:20 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 22, 2008 at 12:55:57AM +0400, Alexander Gavrilov wrote:
>
>> +test_expect_success \
>> + 'blame respects i18n.commitencoding' '
>> + git blame --incremental file | \
>> + grep "^\(author\|summary\) " > actual &&
>> + test_cmp actual expected
>
> Even though it is POSIX, using backslashed grouping in 'grep' isn't
> portable. It fails at least on Solaris 8, and you have to do:
>
> egrep "^(author|summary) "
>
> instead. Of course, I can't get your test to pass even with that change,
> but I think that is just a broken iconv on Solaris.
Hm, which of the conversions fail? You can try manually converting the
txt files with the iconv command to figure it out.
Alexander
^ permalink raw reply
* git archive
From: kenneth johansson @ 2008-10-22 8:42 UTC (permalink / raw)
To: git
I was going to make a tar of the latest stable linux kernel.
Done it before but now I got a strange problem.
>git archive --format=tar v2.6.27.2
fatal: Not a valid object name
this is the output from some other command on the same bare repository.
>git tag | grep 2.6.27.2
v2.6.27.2
>git cat-file -p v2.6.27.2
object 6bcd6d778419101dd96cbbdf03eeab8d779b1d66
type commit
tag v2.6.27.2
tagger Greg Kroah-Hartman <gregkh@suse.de> Sat Oct 18 10:58:00 2008 -0700
This is the v2.6.27.2 stable release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
iEYEABECAAYFAkj6I6sACgkQMUfUDdst+ylcigCg0/e3kQZwAqLp6wPuPqdWl7nL
X0wAnjuNPJG1OqZfhMiAGccLx0QGvMQz
=INvo
-----END PGP SIGNATURE-----
>git cat-file -p 6bcd6d778419101dd96cbbdf03eeab8d779b1d66
tree a717af81e5a2e8a7ee36f3b80aa077965f570197
parent 6505670551fa3deeb6e5d7cab6983514384c7220
author Greg Kroah-Hartman <gregkh@suse.de> 1224352642 -0700
committer Greg Kroah-Hartman <gregkh@suse.de> 1224352642 -0700
Linux 2.6.27.2
>git archive --format=tar a717af81e5a2e8a7ee36f3b80aa077965f570197
fatal: not a tree object
>git cat-file -t a717af81e5a2e8a7ee36f3b80aa077965f570197
tree
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Jeff King @ 2008-10-22 8:50 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: git, Junio C Hamano
In-Reply-To: <bb6f213e0810220135hd520f78odb83414c248a15e4@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 703 bytes --]
On Wed, Oct 22, 2008 at 12:35:17PM +0400, Alexander Gavrilov wrote:
> > instead. Of course, I can't get your test to pass even with that change,
> > but I think that is just a broken iconv on Solaris.
>
> Hm, which of the conversions fail? You can try manually converting the
> txt files with the iconv command to figure it out.
Test 2 fails for CP1251 and SJIS. Manually converting with iconv seems
to work ok (at least, doing "iconv -f CP1251 -t UTF-8 cp1251.txt"
produces the same output as "cat utf8.txt".
The output from "t8005-blame-i18n.sh -v -i" is attached (as
application/octet-stream to protect it from email munging) if that is
helpful to you. I can't make heads or tails of it.
-Peff
[-- Attachment #2: t8005-output.txt --]
[-- Type: application/octet-stream, Size: 1787 bytes --]
^ permalink raw reply
* Does a `git pull' write to the origin repository in any way?
From: Brett Ryan @ 2008-10-22 9:00 UTC (permalink / raw)
To: git
Greetings, the reason I ask this question is because my pattern of
development is to create local source git repositories on my home
directory, then pull them to the central location. I found myself
getting the error `unable to create temporary sha1 filename
.git/objects/11: File exists' which after investigation found that
there were paths in `.git/objects/' owned by root which is who I use
to do the pull from my home directory using sudo. `git log' shows all
commits as me.
Typical dev cycle.
cd ~/src/appl_bin
# make mods
git commit -a
cd $DEST
sudo git pull ~/src/appl_bin linux_test
Thankyou
-Brett
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Ingo Molnar @ 2008-10-22 9:00 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48FEE5B3.9060202@op5.se>
* Andreas Ericsson <ae@op5.se> wrote:
> I imagine you'd want to use it to find out which branches you can (or
> can't) merge, and in that case you need to know about all the topics
> which have the commit. Assuming you don't go crazy cherry-picking and
> criss-cross merging, it should only list a few. The output is not as
> fancy as below, but it should be faster than the appended script (by
> several orders of magnitude).
i solved that particular problem quite well, based on suggestions in a
thread earlier on the git-list. I'm using git branch --no-merged:
earth4:~/tip> time todo-merge-all
merging the following updated branches:
merging linus ... ... merge done.
real 0m2.865s
user 0m2.580s
sys 0m0.228s
that work step used to be over a minute! There are 233 topic branches at
the moment and 18 integration branches. Kudos for making this go really
fast in 1.6.0.
the thing i'm after is to see the originator branch of changes. "git
name-rev" was suggested by Santi Béjar in this thread and that is
exactly what i need - i'll try to integrate it into some git-log-ish
output tool.
One thing i noticed is that 'git name-rev' can be quite slow for certain
commits:
earth4:~/tip> time git name-rev 948f984
948f984 tags/tip-safe-poison-pointers-2008-05-26_08_52_Mon~1
real 0m2.181s
user 0m2.068s
sys 0m0.092s
Which seems natural since it might have to dive back into history and
cross-reference it to all names. (there's 400 branches and 450 tags in
this tree, so i'm certainly pushing things!)
But if i use that in my git-log-line summary tool it might become
quadratic overhead (or worse) very quickly, with minutes of runtime.
Ingo
^ permalink raw reply
* Re: [PATCH v2] builtin-blame: Reencode commit messages according to git-log rules.
From: Alexander Gavrilov @ 2008-10-22 9:32 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20081022085036.GA1454@sigill.intra.peff.net>
On Wed, Oct 22, 2008 at 12:50 PM, Jeff King <peff@peff.net> wrote:
> On Wed, Oct 22, 2008 at 12:35:17PM +0400, Alexander Gavrilov wrote:
>
>> > instead. Of course, I can't get your test to pass even with that change,
>> > but I think that is just a broken iconv on Solaris.
>>
>> Hm, which of the conversions fail? You can try manually converting the
>> txt files with the iconv command to figure it out.
>
> Test 2 fails for CP1251 and SJIS. Manually converting with iconv seems
> to work ok (at least, doing "iconv -f CP1251 -t UTF-8 cp1251.txt"
> produces the same output as "cat utf8.txt".
>
> The output from "t8005-blame-i18n.sh -v -i" is attached (as
> application/octet-stream to protect it from email munging) if that is
> helpful to you. I can't make heads or tails of it.
>From the output it seems that what fails is "-f cp1251 -t sjis" and
"-f utf-8 -t sjis" (remember that blame --incremental produces its
output in reverse order compared to the order of commits). Unless
blame for some reason actually tries to convert to an entirely
different encoding. If tests 4 and 5 pass, you can try adding
--encoding=shift-jis to test 2 to check it.
Alexander
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Andreas Ericsson @ 2008-10-22 9:54 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022090010.GC4369@elte.hu>
Ingo Molnar wrote:
> * Andreas Ericsson <ae@op5.se> wrote:
>
>> I imagine you'd want to use it to find out which branches you can (or
>> can't) merge, and in that case you need to know about all the topics
>> which have the commit. Assuming you don't go crazy cherry-picking and
>> criss-cross merging, it should only list a few. The output is not as
>> fancy as below, but it should be faster than the appended script (by
>> several orders of magnitude).
>
> i solved that particular problem quite well, based on suggestions in a
> thread earlier on the git-list. I'm using git branch --no-merged:
>
> earth4:~/tip> time todo-merge-all
> merging the following updated branches:
> merging linus ... ... merge done.
>
> real 0m2.865s
> user 0m2.580s
> sys 0m0.228s
>
> that work step used to be over a minute! There are 233 topic branches at
> the moment and 18 integration branches. Kudos for making this go really
> fast in 1.6.0.
>
> the thing i'm after is to see the originator branch of changes. "git
> name-rev" was suggested by Santi Béjar in this thread and that is
> exactly what i need - i'll try to integrate it into some git-log-ish
> output tool.
>
> One thing i noticed is that 'git name-rev' can be quite slow for certain
> commits:
>
> earth4:~/tip> time git name-rev 948f984
> 948f984 tags/tip-safe-poison-pointers-2008-05-26_08_52_Mon~1
>
> real 0m2.181s
> user 0m2.068s
> sys 0m0.092s
>
> Which seems natural since it might have to dive back into history and
> cross-reference it to all names. (there's 400 branches and 450 tags in
> this tree, so i'm certainly pushing things!)
>
> But if i use that in my git-log-line summary tool it might become
> quadratic overhead (or worse) very quickly, with minutes of runtime.
>
What's the timing for "git branch --contains 948f984" ?
"git name-rev" parses a lot more just to be able to print a pretty
short-name (the reversed "git describe") for you to use.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Ingo Molnar @ 2008-10-22 9:58 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <48FEF868.2010802@op5.se>
* Andreas Ericsson <ae@op5.se> wrote:
> Ingo Molnar wrote:
>> * Andreas Ericsson <ae@op5.se> wrote:
>>
>>> I imagine you'd want to use it to find out which branches you can (or
>>> can't) merge, and in that case you need to know about all the topics
>>> which have the commit. Assuming you don't go crazy cherry-picking and
>>> criss-cross merging, it should only list a few. The output is not as
>>> fancy as below, but it should be faster than the appended script (by
>>> several orders of magnitude).
>>
>> i solved that particular problem quite well, based on suggestions in a
>> thread earlier on the git-list. I'm using git branch --no-merged:
>>
>> earth4:~/tip> time todo-merge-all
>> merging the following updated branches:
>> merging linus ... ... merge done.
>>
>> real 0m2.865s
>> user 0m2.580s
>> sys 0m0.228s
>>
>> that work step used to be over a minute! There are 233 topic branches
>> at the moment and 18 integration branches. Kudos for making this go
>> really fast in 1.6.0.
>>
>> the thing i'm after is to see the originator branch of changes. "git
>> name-rev" was suggested by Santi Béjar in this thread and that is
>> exactly what i need - i'll try to integrate it into some git-log-ish
>> output tool.
>>
>> One thing i noticed is that 'git name-rev' can be quite slow for
>> certain commits:
>>
>> earth4:~/tip> time git name-rev 948f984
>> 948f984 tags/tip-safe-poison-pointers-2008-05-26_08_52_Mon~1
>>
>> real 0m2.181s
>> user 0m2.068s
>> sys 0m0.092s
>>
>> Which seems natural since it might have to dive back into history and
>> cross-reference it to all names. (there's 400 branches and 450 tags in
>> this tree, so i'm certainly pushing things!)
>>
>> But if i use that in my git-log-line summary tool it might become
>> quadratic overhead (or worse) very quickly, with minutes of runtime.
>>
>
> What's the timing for "git branch --contains 948f984" ?
>
> "git name-rev" parses a lot more just to be able to print a pretty
> short-name (the reversed "git describe") for you to use.
it takes much longer:
earth4:~/tip> time git branch --contains 948f984
[... 44 branches ...]
real 0m9.596s
user 0m9.151s
sys 0m0.218s
Ingo
^ permalink raw reply
* Re: [irq/urgent]: created 3786fc7: "irq: make variable static"
From: Jakub Narebski @ 2008-10-22 10:50 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20081022061730.GA5749@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> Git recently started printing the branch name when creating commits:
>
> [irq/urgent]: created 3786fc7: "irq: make variable static"
>
> very nice idea IMO! Having it all on one line allows me to double-check
> that i indeed queued up a patch in the intended topic branch. Had it
> read:
>
> [irq/urgent]: created 3786fc7: "printk: make variable static"
>
> i'd have noticed the mistake immediately.
>
> this welcome enhancement made me remember of three usage problems i had
> with Git recently:
[...]
About printing either forward (git-describe, e.g. v1.6.0.2-590-g67f6062)
or backward (git-name-rev, e.g. tags/v1.6.0-rc2~8): you can use
git-name-rev in filter mode (git log ... | git name-rev --stdin), or
"git log --decorate", or '%d' in --pretty format specifier (this is very
new thing).
You might be also interested in --abbrev-commit (when used with
--pretty=oneline format), and --graph option to git-log (or
git-show-branch). The "(--merged | --no-merged | --contains) [<commit>]"
options to git-branch might be also of interest...
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git history and file moves
From: Alex Riesen @ 2008-10-22 11:19 UTC (permalink / raw)
To: Lin Ming; +Cc: git, Moore, Robert
In-Reply-To: <1224640967.14280.0.camel@minggr.sh.intel.com>
2008/10/22 Lin Ming <ming.m.lin@intel.com>:
> I'm looking for a way to move files to a new directory and have the
> full history follow the file automatically. Is this possible?
>
> I know about --follow, but I want the history to just follow the file
> transparently. ...
Of all Git tools, what does not do this "transparently" or "automatically"?
How more transparent do you imagine this?
What do you think should follow what?
I ask, because it is hard to understand what exactly is it you're missing:
merge support (which we have), git log listing the files as copied/renamed
(which is what --follow is for, and the suggestion for you is to make an
alias or something), git blame (ever looked at git gui blame?) or gitk
(which follows renames in default configuration)
> Also, we have a git web interface and we want the full
> history for the moved files to be available.
It is available. Whether it is shown is another question. git-web can
be improved (or just configured?)
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-22 11:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Andreas Ericsson, git
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>
On 10/21/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > 2008/10/21 Junio C Hamano <gitster@pobox.com>:
> >> "Leo Razoumov" <slonik.az@gmail.com> writes:
> >>
> >>> Even though the old behavior is "long established", it introduces
> >>> unnecessary ambiguity. If I have two repos
> >>> ...
> >>
> >> Of course. Now you know why people don't name such a pair of repositories
> >> like that ;-).
> >
> > FWIW, I support Leo on that. The "established" behavior is stupid.
>
>
> I am not inclined to respond to such an emotional argument. On the other
> hand, it is fair to say that the existing behaviour is established,
> because it is backed by a long history, which you can objectively verify.
>
> If you think about it deeper, you will realize that it is not even clear
> if it is "stupid".
>
> More importantly, the behaviour is consistent with the way how "git fetch"
> and "git clone" DWIMs the repository name by suffixing .git when the input
> lacks it. And this DWIMmery comes from the expectations that:
>
> (1) people name their repository project.git; and
>
> (2) people like using and seeing short names (iow, "clone
> git://$somewhere/project" is preferred over "clone
> git://$somewhere/project.git");
>
> If a repository whose real location is git://$somewhere/project.git is
> cloned/fetched as git://$somewhere/project by people, recording the merge
> source using the shorter name used by people to fetch from it is more
> consistent. The patch breaks this consistency [*1*].
>
> What is clear is that you would confuse yourself if you have two
> repositories A and A.git next to each other, and that is primarily because
> it breaks the above expectation.
>
> git core-level rarely imposes such policies, but what Porcelains do is a
> different matter.
>
> Hence the suggestion: don't do it.
>
> [Footnote]
>
> *1* It would be a different matter if the patch at the same time removed
> the fetch/clone DWIMmery. At least such a patch would be internally self
> consistent.
>
I think this discussion went in the direction of "correct" versus
"convent". I, personally, will choose correct over convenient any
time. Different people use git for different projects and their
expectations differ in this regard. In my case
after I do "git clone Foo.git" I get "Foo" repo side-by-side with
"Foo.git" and the ambiguity becomes apparent.
Regarding your footnote *1*. I agree with your suggestions and I can
improve the patch in the following way:
(1) Fetch/clone messages/comments will refer to the source/destination
repos by their complete names without stripping off any parts
(2) Searching for a source repo, clone/fetch will first try an exact
match and if it fails it will remove/add ".git" suffix and
^ permalink raw reply
* Re: [PATCH] git-fetch should not strip off ".git" extension
From: Leo Razoumov @ 2008-10-22 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Andreas Ericsson, git
In-Reply-To: <7vd4htwp6v.fsf@gitster.siamese.dyndns.org>
My apologies!! I hit send button by mistake before message was
complete. Please, see below a completed version.
--Leo--
On 10/21/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Alex Riesen" <raa.lkml@gmail.com> writes:
>
> > 2008/10/21 Junio C Hamano <gitster@pobox.com>:
> >> "Leo Razoumov" <slonik.az@gmail.com> writes:
> >>
> >>> Even though the old behavior is "long established", it introduces
> >>> unnecessary ambiguity. If I have two repos
> >>> ...
> >>
> >> Of course. Now you know why people don't name such a pair of repositories
> >> like that ;-).
> >
> > FWIW, I support Leo on that. The "established" behavior is stupid.
>
>
> I am not inclined to respond to such an emotional argument. On the other
> hand, it is fair to say that the existing behaviour is established,
> because it is backed by a long history, which you can objectively verify.
>
> If you think about it deeper, you will realize that it is not even clear
> if it is "stupid".
>
> More importantly, the behaviour is consistent with the way how "git fetch"
> and "git clone" DWIMs the repository name by suffixing .git when the input
> lacks it. And this DWIMmery comes from the expectations that:
>
> (1) people name their repository project.git; and
>
> (2) people like using and seeing short names (iow, "clone
> git://$somewhere/project" is preferred over "clone
> git://$somewhere/project.git");
>
> If a repository whose real location is git://$somewhere/project.git is
> cloned/fetched as git://$somewhere/project by people, recording the merge
> source using the shorter name used by people to fetch from it is more
> consistent. The patch breaks this consistency [*1*].
>
> What is clear is that you would confuse yourself if you have two
> repositories A and A.git next to each other, and that is primarily because
> it breaks the above expectation.
>
> git core-level rarely imposes such policies, but what Porcelains do is a
> different matter.
>
> Hence the suggestion: don't do it.
>
> [Footnote]
>
> *1* It would be a different matter if the patch at the same time removed
> the fetch/clone DWIMmery. At least such a patch would be internally self
> consistent.
>
I think this discussion went in the direction of "correct" versus
"convent". I, personally, will choose correct over convenient any
time. Different people use git for different projects and their
expectations differ in this regard. In my case
after I do "git clone Foo.git" I get "Foo" repo side-by-side with
"Foo.git" and the ambiguity becomes apparent.
Regarding your footnote *1*. I agree with your suggestions and I can
improve the patch in the following way:
(P1) Fetch/clone messages/records will refer to the source/destination
repos by their complete names without stripping off any parts of the name.
(P2) Searching for a source repo, clone/fetch will first try an exact
match and if it fails it will remove/add ".git" suffix as needed and retry.
Item (P2) will provide the convenience, while item (P1) still
guarantees correctness.
Please, let me know if such approach is more satisfactory.
--Leo--
^ permalink raw reply
* Re: git history and file moves
From: Michael J Gruber @ 2008-10-22 12:38 UTC (permalink / raw)
To: Lin Ming; +Cc: Alex Riesen, git, Moore, Robert
In-Reply-To: <81b0412b0810220419q43f6985fs1c608e3d3cbcf8f3@mail.gmail.com>
Alex Riesen venit, vidit, dixit 10/22/08 13:19:
> 2008/10/22 Lin Ming <ming.m.lin@intel.com>:
>> I'm looking for a way to move files to a new directory and have the
>> full history follow the file automatically. Is this possible?
>>
>> I know about --follow, but I want the history to just follow the file
>> transparently. ...
>
> Of all Git tools, what does not do this "transparently" or "automatically"?
> How more transparent do you imagine this?
> What do you think should follow what?
>
> I ask, because it is hard to understand what exactly is it you're missing:
> merge support (which we have), git log listing the files as copied/renamed
> (which is what --follow is for, and the suggestion for you is to make an
> alias or something), git blame (ever looked at git gui blame?) or gitk
> (which follows renames in default configuration)
>
>> Also, we have a git web interface and we want the full
>> history for the moved files to be available.
>
> It is available. Whether it is shown is another question. git-web can
> be improved (or just configured?)
By default, gitweb uses "-M" for diff. You can specify all options (-C,
-CC, -B) using "@diff_opts" in the config file for gitweb.cgi - if that
is what you are using. Is it?
Anyways, using default configs for git log and gitweb.cgi both of them
show the full history (renames, history before and after) for me here,
using current git (1.6.0.3.514.g2f91b). What is your setup?
Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox