Re: [GIT PULL] arm64: Fixes for -rc4
Hello, I added the git list to Cc:. For the new readers: The context of this thread can be found at https://lwn.net/ml/linux-kernel/20191017234348.wcbbo2njexn7ixpk@willie-the-truck/ On Mon, Oct 21, 2019 at 08:46:58AM +0200, Ingo Molnar wrote: > Anyway, a small Git feature request: it would be super useful if "git > request-pull" output was a bit more dependable and at least warned about > this and didn't include what is, from the viewpoint of the person doing > the merge, a bogus diffstat. (Generating the correct diffstat is probably > beyond request-pull's abilities: it would require changing the working > tree to actually perform the merge - while request-pull is a read-only > operation right now. But detecting the condition and warning about it > should be possible?) I think Will's case is still an easy one compared with what could actually happen. The related history looks as follows: ,-. ,-. ,-.,-.,-. v5.4-rc1 --| |-...-| |-- v5.4-rc2 --| |-..-| |-..-| |-- v5.4-rc3 \ `-' `-' \ `-'/-'`-' \ ,-. ,-. \ ,-/,-. ,-. `--| |-...-| ||*|| |-...-|H| `-' `-'\ `-'`-' /-' \ ,-. ,-. / `--| |-...-| |-' `-' `-' Will asked Linus to merge the Commit marked 'H', the two merge bases are v5.4-rc2 and '*'. (FTR: * = 3e7c93bd04edfb0cae7dad1215544c9350254b8f H = 777d062e5bee0e3c0751cdcbce116a76ee2310ec , they can be found in git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git) The formally correct way to create the diffstat is to merge v5.4-rc2 and '*' (in general: all merge bases) and calculate the diff between this merge and the to-be-merged-commit. Compared to what Will did (i.e. merge Linus' HEAD and this branch and then diff @~ with @) doing it the way I described has the advantage(?) that commits that conflict with this merge request in Linus' tree since the merge bases are not in the way. In this case this can be done automatically: $ git read-tree --index-output=tralala v5.4-rc2 3e7c93bd04edfb0cae7dad1215544c9350254b8f $ GIT_INDEX=tralala git write-tree 6a2acfd1870d9da3c330ea9b648a7e858b5ee39f $ git diff --stat 6a2acfd1870d9da3c330ea9b648a7e858b5ee39f 777d062e5bee0e3c0751cdcbce116a76ee2310ec Documentation/arm64/silicon-errata.rst | 2 ++ arch/arm64/Kconfig | 17 ++ arch/arm64/include/asm/asm-uaccess.h | 7 +++--- arch/arm64/include/asm/cpucaps.h | 4 +++- arch/arm64/include/asm/memory.h| 10 ++-- arch/arm64/include/asm/pgtable.h | 3 --- arch/arm64/include/asm/sysreg.h| 2 +- arch/arm64/kernel/cpu_errata.c | 38 +++ arch/arm64/kernel/cpufeature.c | 15 arch/arm64/kernel/entry.S | 8 --- arch/arm64/kernel/hibernate.c | 9 +++- arch/arm64/kernel/process.c| 18 +++ arch/arm64/kvm/hyp/switch.c| 69 ++-- arch/arm64/mm/fault.c | 6 - include/linux/sched.h | 1 + 15 files changed, 186 insertions(+), 23 deletions(-) Would be great if git-request-pull learned to do that. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: [PATCH v2] range-diff: don't segfault with mode-only changes
On Tue, Oct 08, 2019 at 06:38:43PM +0100, Thomas Gummerer wrote:
> In ef283b3699 ("apply: make parse_git_diff_header public", 2019-07-11)
> the 'parse_git_diff_header' function was made public and useable by
> callers outside of apply.c.
>
> However it was missed that its (then) only caller, 'find_header' did
> some error handling, and completing 'struct patch' appropriately.
>
> range-diff then started using this function, and tried to handle this
> appropriately itself, but fell short in some cases. This in turn
> would lead to range-diff segfaulting when there are mode-only changes
> in a range.
>
> Move the error handling and completing of the struct into the
> 'parse_git_diff_header' function, so other callers can take advantage
> of it. This fixes the segfault in 'git range-diff'.
>
> Reported-by: Uwe Kleine-König
> Signed-off-by: Thomas Gummerer
This patch also makes git work again for the originally problematic
usecase.
Tested-by: Uwe Kleine-König
Thanks for your quick reaction to my bug report,
Uwe Kleine-König
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: Regression in v2.23
Hello Thomas, On Mon, Oct 07, 2019 at 02:48:31PM +0100, Thomas Gummerer wrote: > I can hopefully do some more testing and write automated tests later > today or tomorrow. In the meantime it would be awesome if you could > confirm if this patch fixes the problem you were seeing. I assume you already tested on my constructed example from the report. I just tested on the original and there is works fine, too. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Regression in v2.23
Hello,
With git 2.23.0 I have:
uwe@taurus:~/tmp/rangediff-segfault$ git init
Initialized empty Git repository in
/home/uwe/tmp/rangediff-segfault/.git/
uwe@taurus:~/tmp/rangediff-segfault$ echo root > root
uwe@taurus:~/tmp/rangediff-segfault$ git add root
uwe@taurus:~/tmp/rangediff-segfault$ git commit -m root
[master (root-commit) b0feddb2dee8] root
1 file changed, 1 insertion(+)
create mode 100644 root
uwe@taurus:~/tmp/rangediff-segfault$ echo content > file
uwe@taurus:~/tmp/rangediff-segfault$ chmod +x file
uwe@taurus:~/tmp/rangediff-segfault$ git add file
uwe@taurus:~/tmp/rangediff-segfault$ git commit -m file
[master 45b547c57acd] file
1 file changed, 1 insertion(+)
create mode 100755 file
uwe@taurus:~/tmp/rangediff-segfault$ chmod -x file
uwe@taurus:~/tmp/rangediff-segfault$ git add file
uwe@taurus:~/tmp/rangediff-segfault$ git commit -m 'chmod -x'
[master eaa5d3b98caa] chmod -x
1 file changed, 0 insertions(+), 0 deletions(-)
mode change 100755 => 100644 file
uwe@taurus:~/tmp/rangediff-segfault$ git range-diff @~2..@~ @~2..
Segmentation fault (core dumped)
Bisecting points to b66885a30cb84fc61986bc4eea805a31fdbea79a, current master
(b744c3af07a15aaeb1b82fab689995fd5528f120) segfaults in the same way.
This is somehow similar to
https://public-inbox.org/git/20190923101929.ga18...@kitsune.suse.cz/ but
the patch by Johannes Schindelin sent in
https://public-inbox.org/git/pull.373.git.gitgitgad...@gmail.com/
doesn't help me.
For me the segfault also happens in
strbuf_addstr(&buf, patch.new_name);
with patch.new_name being NULL.
The matching backtrace and patch object looks as follows:
(gdb) bt
#0 __strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:65
#1 0x555cc448949c in strbuf_addstr (s=,
sb=0x7ffcd1d9ef00)
at strbuf.h:292
#2 read_patches (range=range@entry=0x555cc5dc2b70 "@~2..",
list=list@entry=0x7ffcd1d9f280) at range-diff.c:126
#3 0x555cc44898a8 in show_range_diff (range1=0x555cc5dc2b50
"@~2..@~",
range2=0x555cc5dc2b70 "@~2..", creation_factor=60, dual_color=1,
diffopt=diffopt@entry=0x7ffcd1d9f680) at range-diff.c:507
#4 0x555cc4397aa6 in cmd_range_diff (argc=,
argv=, prefix=) at
builtin/range-diff.c:80
#5 0x555cc4328494 in run_builtin (argv=,
argc=, p=) at git.c:445
#6 handle_builtin (argc=, argv=) at
git.c:674
#7 0x555cc4329554 in run_argv (argv=0x7ffcd1d9f9e0,
argcp=0x7ffcd1d9f9ec)
at git.c:741
#8 cmd_main (argc=, argv=) at git.c:872
#9 0x555cc432803a in main (argc=4, argv=0x7ffcd1d9fc78)
at common-main.c:52
(gdb) up 2
#2 read_patches (range=range@entry=0x555cc5dc2b70 "@~2..",
list=list@entry=0x7ffcd1d9f280) at range-diff.c:126
126 range-diff.c: No such file or directory.
(gdb) print patch
$1 = {new_name = 0x0, old_name = 0x0, def_name = 0x555cc5dc98c0 "file",
old_mode = 33261, new_mode = 33188, is_new = 0, is_delete = 0,
rejected = 0,
ws_rule = 0, lines_added = 0, lines_deleted = 0, score = 0,
extension_linenr = 0, is_toplevel_relative = 0, inaccurate_eof = 0,
is_binary = 0, is_copy = 0, is_rename = 0, recount = 0,
conflicted_threeway = 0, direct_to_threeway = 0, crlf_in_old = 0,
fragments = 0x0, result = 0x0, resultsize = 0,
old_oid_prefix = '\000' ,
new_oid_prefix = '\000' , next = 0x0,
threeway_stage = {{
hash = '\000' }, {hash = '\000' }, {
hash = '\000' }}}
I guess you are able to work out the details with this information. If you need
more input, please Cc: me on replies.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: git slow unless piped to cat
Hello, On Tue, Aug 27, 2019 at 02:38:57PM -0700, Bryan Turner wrote: > On Tue, Aug 27, 2019 at 2:32 PM Uwe Kleine-König > wrote: > > > > On Tue, Aug 27, 2019 at 02:59:30PM -0400, Jeff King wrote: > > > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote: > > > > > > to see the loose ones. If there are a lot, try: > > > > > > git pack-refs --prune --all > > > > > > (or just "git gc", which does this). > > > > This is a daily updated mirror that is also incrementally backed up. I > > repack from time to time, but hesitate to do this regularily as each > > time I repack the next backup run is "expensive" and I get many small > > packs. I did this now anyhow. > > Just noting that Jeff didn't suggest a repack; he suggested a > pack-refs. This should have little, if any impact on your backup > processing, because all it's going to do is rewrite the "packed-refs" > file and delete loose refs. It doesn't modify any files under objects/ > at all. Ah, right. That also explains why I still had a few loose objects. I cut-n-pasted the command, so I did as suggested, just thought it was something different. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: git slow unless piped to cat
On Tue, Aug 27, 2019 at 02:59:30PM -0400, Jeff King wrote: > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote: > > > $ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time env > > GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git > > --no-pager show --no-color --no-decorate v5.2 > > ... > > > > real0m1.041s > > user0m0.000s > > sys 0m0.021s > > > > $ git for-each-ref |wc -l > > 10013 > > > > So this is indeed the problem. > > That's not that many refs. Are they mostly unpacked? Loose refs are > awful on a cold cache, since it's one inode per ref (or worse, since it > has walk the directories, too). > > Try: > > find .git/refs -type f | wc -l u...@dude.ptx:/ptx/src/git/linux.git$ find refs -type f | wc -l 2874 (Note this is a bare repository. So I used refs instead of .git/refs.) > to see the loose ones. If there are a lot, try: > > git pack-refs --prune --all > > (or just "git gc", which does this). This is a daily updated mirror that is also incrementally backed up. I repack from time to time, but hesitate to do this regularily as each time I repack the next backup run is "expensive" and I get many small packs. I did this now anyhow. After that I have: $ find objects/[0-9a-f][0-9a-f] -type f | wc -l 166 $ find objects/pack | wc -l 98 > Modern versions of Git should delete any leftover empty directories > after pruning the loose variants, but I think won't go out of their way > to remove ones they didn't delete from. And those are still expensive to > walk on a cold cache. If it's still slow, try: > > find .git/refs/* -type d | xargs rmdir -v There were a few: $ find refs/ -depth -type d -empty -print -delete | wc -l 147 (Oops, after the repacking above this also removed ./refs which I had to restore to make git recognize this as a repository.) With these two things done it is a bit faster: $ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color v5.2 tag v5.2 ... real0m11.022s user0m0.321s sys 0m0.248s Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: git slow unless piped to cat
Hello, On Tue, Aug 27, 2019 at 12:33:09PM +0200, SZEDER Gábor wrote: > On Tue, Aug 27, 2019 at 12:04:27PM +0200, Uwe Kleine-König wrote: > > I'm a bit surprised that the default for --decorate depends on the > > output being a terminal. > > Decorations (and colors as well) are for humans, and humans read the > terminal. I agree for colors only. Changing the actually provided information depending on output being a terminal is IMHO at least surprising. > > Thanks for your help, I will think about what I want to do. Just using > > --no-decorate will work, but isn't nice either. Will test if just > > throwing away all those tags from linux-next will make this already > > better. > > Note that you can disable decorations by setting the 'log.decorate' > configuration variable to false. Being able to configure --decorate-refs= and --decorate-refs-exclude= in the config would be nice ... Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: git slow unless piped to cat
On Tue, Aug 27, 2019 at 11:44:07AM +0200, SZEDER Gábor wrote:
> On Tue, Aug 27, 2019 at 11:12:06AM +0200, Philipp Zabel wrote:
> > On Tue, 2019-08-27 at 10:56 +0200, Uwe Kleine-König wrote:
> > > On Tue, Aug 27, 2019 at 10:41:11AM +0200, SZEDER Gábor wrote:
> > > > On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote:
> > > > > I have a problem here with git being slow in some situations.
> > > > > Using git 2.23.0 (from Debian) the effect is:
> > > > >
> > > > > u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 >
> > > > > /proc/sys/vm/drop_caches"; time git show v5.2
> > > > > tag v5.2
> > > > > ...
> > > > >
> > > > > real 0m12.727s
> > > > > user 0m0.300s
> > > > > sys 0m0.371s
> > > > >
> > > > > But to get the actual data isn't the problem:
> > > > >
> > > > > u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 >
> > > > > /proc/sys/vm/drop_caches"; time git show v5.2 | cat
> > > > > tag v5.2
> > > > > ...
> > > > >
> > > > > real 0m0.764s
> > > > > user 0m0.014s
> > > > > sys 0m0.020s
> > > > >
> > > >
> > > > How does 'git --no-pager show v5.2' perform? If it's as fast as the
> > > > case piping the output to cat, then look into what pager and pager
> > > > options you use.
> > >
> > > u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 >
> > > /proc/sys/vm/drop_caches"; time git --no-pager show v5.2
> > > tag v5.2
> > > ...
> > >
> > > real0m13.225s
> > > user0m0.355s
> > > sys 0m0.336s
> > >
> > > So this doesn't seem to be the problem. Also the local configuration
> > > can be ruled out:
> > >
> > > u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 >
> > > /proc/sys/vm/drop_caches"; time env GIT_CONFIG_NOSYSTEM=1
> > > HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show
> > > --no-color v5.2
> > > tag v5.2
> > > ...
> > >
> > > real0m13.587s
> > > user0m0.335s
> > > sys 0m0.336s
> > >
> > > Thanks
> > > Uwe
> >
> > Have you checked strace output? I see a directory walk through .git/refs
> > and .git/packed-refs if the output is not redirected.
>
> That's a good point, 'git show/log' show decorations (refs pointing to
> any commits shown) when the output is a terminal:
>
> $ git show v5.2
> [...]
> commit 0ecfebd2b52404ae0c54a878c872bb93363ada36 (HEAD -> master, tag: v5.2)
> [...]
> $ git show v5.2 |cat
> [...]
> commit 0ecfebd2b52404ae0c54a878c872bb93363ada36
> [...]
> And indeed, if you have a lot of refs and cold cache, then that might
> account for a couple of seconds difference. So, how does 'git show
> --no-decorate v5.2' perform, and if it performs well, then how many
> refs do you have ('git for-each-ref |wc -l')?
$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time env
GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git
--no-pager show --no-color --no-decorate v5.2
...
real0m1.041s
user0m0.000s
sys 0m0.021s
$ git for-each-ref |wc -l
10013
So this is indeed the problem.
I'm a bit surprised that the default for --decorate depends on the
output being a terminal.
Thanks for your help, I will think about what I want to do. Just using
--no-decorate will work, but isn't nice either. Will test if just
throwing away all those tags from linux-next will make this already
better.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
Re: git slow unless piped to cat
On Tue, Aug 27, 2019 at 10:41:11AM +0200, SZEDER Gábor wrote: > On Tue, Aug 27, 2019 at 10:15:59AM +0200, Uwe Kleine-König wrote: > > I have a problem here with git being slow in some situations. > > Using git 2.23.0 (from Debian) the effect is: > > > > u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 > > > /proc/sys/vm/drop_caches"; time git show v5.2 > > tag v5.2 > > ... > > > > real0m12.727s > > user0m0.300s > > sys 0m0.371s > > > > But to get the actual data isn't the problem: > > > > u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 > > > /proc/sys/vm/drop_caches"; time git show v5.2 | cat > > tag v5.2 > > ... > > > > real0m0.764s > > user0m0.014s > > sys 0m0.020s > > > > How does 'git --no-pager show v5.2' perform? If it's as fast as the > case piping the output to cat, then look into what pager and pager > options you use. u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time git --no-pager show v5.2 tag v5.2 ... real0m13.225s user0m0.355s sys 0m0.336s So this doesn't seem to be the problem. Also the local configuration can be ruled out: u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time env GIT_CONFIG_NOSYSTEM=1 HOME=/nonexistant XDG_CONFIG_HOME=/nonexistant git --no-pager show --no-color v5.2 tag v5.2 ... real0m13.587s user0m0.335s sys 0m0.336s Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
git slow unless piped to cat
Hello, I have a problem here with git being slow in some situations. Using git 2.23.0 (from Debian) the effect is: u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time git show v5.2 tag v5.2 ... real0m12.727s user0m0.300s sys 0m0.371s But to get the actual data isn't the problem: u...@dude.ptx:/ptx/src/git/linux.git$ sudo sh -c "echo 3 > /proc/sys/vm/drop_caches"; time git show v5.2 | cat tag v5.2 ... real0m0.764s user0m0.014s sys 0m0.020s My expectation is that both commands should take approximately the same amount of time. This is 100% reproducible here. The backing filesystem could be quicker (don't know, this is xfs in an logical volume) but this applies to both calls, so this doesn't seem to be the biggest culprit at least. This is not a regression, I see similar problems since >2 years. (Didn't report before because I didn't know such an obvious reproducer.) Using perf I get in the first case: 7.99% git libz.so.1.2.11 [.] inflate 3.02% git libc-2.28.so[.] __memcmp_sse4_1 1.67% git [kernel.kallsyms] [k] __list_del_entry_valid 1.32% git [kernel.kallsyms] [k] unmap_page_range 1.25% git [kernel.kallsyms] [k] filemap_map_pages ... while with cat I get: 3.35% git [kernel.kallsyms] [k] __update_load_avg_cfs_rq 3.22% git [kernel.kallsyms] [k] update_blocked_averages 2.37% git [kernel.kallsyms] [k] __list_del_entry_valid 1.92% git [kernel.kallsyms] [k] hrtimer_interrupt 1.91% git [kernel.kallsyms] [k] __pagevec_lru_add_fn It doesn't seem to be related to stdio buffering or coloring as stdbuf -o0 git show --no-color v5.2 is slow, too. Any idea what could be the problem? Is there some info that I might report additionally to make this better understandable? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ |
[PATCH] howto/using-merge-subtree: mention --allow-unrelated-histories
Without passing --allow-unrelated-histories the command sequence
fails as intended since commit e379fdf34fee ("merge: refuse to create
too cool a merge by default"). To setup a subtree merging unrelated
histories is normal, so add the option to the howto document.
Signed-off-by: Uwe Kleine-König
---
Documentation/howto/using-merge-subtree.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/howto/using-merge-subtree.txt
b/Documentation/howto/using-merge-subtree.txt
index 1ae8d1214ec0..a499a94ac228 100644
--- a/Documentation/howto/using-merge-subtree.txt
+++ b/Documentation/howto/using-merge-subtree.txt
@@ -33,7 +33,7 @@ Here is the command sequence you need:
$ git remote add -f Bproject /path/to/B <1>
-$ git merge -s ours --no-commit Bproject/master <2>
+$ git merge -s ours --no-commit --allow-unrelated-histories Bproject/master <2>
$ git read-tree --prefix=dir-B/ -u Bproject/master <3>
$ git commit -m "Merge B project as our subdirectory" <4>
--
2.19.1
Re: git filter-branch and merging of signed tags
Hello Michael, On Mon, Nov 02, 2015 at 05:21:03PM +0100, Michael J Gruber wrote: > Uwe Kleine-König venit, vidit, dixit 02.11.2015 09:04: > > ~/gsrc/linux$ git version > > git version 2.6.1 > > Does your git include > a5a4b3f (filter-branch: remove multi-line headers in msg filter, > 2015-10-08)? That takes care of the incomplete header tag parsing. No, it does not. Thanks for the hint. > Should be in master by now, I think. > > Keeping the mergetag signature would require some extra logic in > filter-branch. that I'd like to have :-). It seems I have to dig into that myself. (If someone is quicker than me, I promise not to be angry :-) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git filter-branch and merging of signed tags
Hello, Consider I want to rewrite a commit that is a merge of a signed tag. In my case that's 064ca93f7ab927c2752d86fc5727716e340d737c that currently sits in linux-next: ~/gsrc/linux$ git version git version 2.6.1 ~/gsrc/linux$ git checkout 064ca93f7ab927c2752d86fc5727716e340d737c ~/gsrc/linux$ git cat-file commit HEAD tree 7086bbd51d06ebd0e3fcca70380d0a066efce6ef parent e44a01fa0e0aec2f3a21dadb9c030d14831d4258 parent f719a0d6a8541b383c506aaa4b4fa6b4109669f4 author Arnd Bergmann 1444139956 +0200 committer Arnd Bergmann 1444139956 +0200 mergetag object f719a0d6a8541b383c506aaa4b4fa6b4109669f4 type commit tag efm32-for-4.4-rc1 tagger Uwe Kleine-König 1443549594 +0200 efm32 cleanups for 4.4-rc1 These are just two followup cleanups for commits that are in v3.17-rc1 and waited in my private tree for application since that time. -BEGIN PGP SIGNATURE- iQEcBAABCgAGBQJWCtIwAAoJEMH8FHityuwJFPYH/2LJpi0yUhI01s0D9U5rZgjl 8mLP70utAMaqXiGqP/O0ndH+za5TrrUTwDJE5jhAHru1Q6q62Ld2BfOR5+K8zlrP 4UDGBDj3ePJgEtbSsJYJIRT+AKque2GONbeGpJh2arPrNamWChKIz8HoGSgwdRlx TvQuVFEa6C3ujP0ATM8x54f0vR4bYm9WmBS522DwZQY4JpGZC005A3Quw6fmFxPJ vJRo1fE1d2OZ3Cuxb15m8PLtZw6sbMdMwgyirAFGrJsN9u/V6BzsSzH0s8suT7IP WIohnmYtFSUfkQjaGrMl2wIpJSsIzettiXf9GrQDXSGZsQ4k7sW3U+qrcZ7ZUR4= =ngv1 -END PGP SIGNATURE- Merge tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux into next/cleanup Merge "efm32 cleanups for 4.4-rc1" from Uwe Kleine-Koenig: These are just two followup cleanups for commits that are in v3.17-rc1 and waited in my private tree for application since that time. * tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux: ARM: efm32: switch to vendor,device compatible strings ARM: efm32: switch to properly namespaced location property OK, to fix my name in the commit log I do: git filter-branch -f --msg-filter "sed 's/Kleine-Koenig/$(echo Kleine-K+APY-nig | iconv -f utf-7 -t utf-8)/'" HEAD ^HEAD^ ^HEAD^2 This destroys the mergetag, as now I have: ~/gsrc/linux$ git cat-file commit HEAD tree 7086bbd51d06ebd0e3fcca70380d0a066efce6ef parent e44a01fa0e0aec2f3a21dadb9c030d14831d4258 parent f719a0d6a8541b383c506aaa4b4fa6b4109669f4 author Arnd Bergmann 1444139956 +0200 committer Arnd Bergmann 1444139956 +0200 efm32 cleanups for 4.4-rc1 These are just two followup cleanups for commits that are in v3.17-rc1 and waited in my private tree for application since that time. -BEGIN PGP SIGNATURE- iQEcBAABCgAGBQJWCtIwAAoJEMH8FHityuwJFPYH/2LJpi0yUhI01s0D9U5rZgjl 8mLP70utAMaqXiGqP/O0ndH+za5TrrUTwDJE5jhAHru1Q6q62Ld2BfOR5+K8zlrP 4UDGBDj3ePJgEtbSsJYJIRT+AKque2GONbeGpJh2arPrNamWChKIz8HoGSgwdRlx TvQuVFEa6C3ujP0ATM8x54f0vR4bYm9WmBS522DwZQY4JpGZC005A3Quw6fmFxPJ vJRo1fE1d2OZ3Cuxb15m8PLtZw6sbMdMwgyirAFGrJsN9u/V6BzsSzH0s8suT7IP WIohnmYtFSUfkQjaGrMl2wIpJSsIzettiXf9GrQDXSGZsQ4k7sW3U+qrcZ7ZUR4= =ngv1 -END PGP SIGNATURE- Merge tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux into next/cleanup Merge "efm32 cleanups for 4.4-rc1" from Uwe Kleine-König: These are just two followup cleanups for commits that are in v3.17-rc1 and waited in my private tree for application since that time. * tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux: ARM: efm32: switch to vendor,device compatible strings ARM: efm32: switch to properly namespaced location property ~/gsrc/linux$ diff -u <(git cat-file commit HEAD) <(git cat-file commit 064ca93f7ab927c2752d86fc5727716e340d737c) --- /dev/fd/63 2015-11-02 09:02:17.310373539 +0100 +++ /dev/fd/62 2015-11-02 09:02:17.310373539 +0100 @@ -3,7 +3,11 @@ parent f719a0d6a8541b383c506aaa4b4fa6b4109669f4 author Arnd Bergmann 1444139956 +0200 committer Arnd Bergmann 1444139956 +0200 - +mergetag object f719a0d6a8541b383c506aaa4b4fa6b4109669f4 + type commit + tag efm32-for-4.4-rc1 + tagger Uwe Kleine-König 1443549594 +0200 + efm32 cleanups for 4.4-rc1 These are just two followup cleanups for commits that are in v3.17-rc1 and @@ -21,7 +25,7 @@ Merge tag 'efm32-for-4.4-rc1' of git://git.pengutronix.de/git/ukl/linux into next/cleanup -Merge "efm32 cleanups for 4.4-rc1" from Uwe Kleine-König: +Merge "efm32 cl
Re: please strip MIME-Version and Content-T{ype,ransfer-Encoding} in git am --scissors
Hello Junio,
On Thu, Oct 08, 2015 at 01:04:01PM -0700, Junio C Hamano wrote:
> Uwe Kleine-König writes:
>
> >> Does this have anything to do with scissors, though? If you remove
> >> everything before "8< ---" in the body of Tony's message (i.e. keep
> >> the in-body headers starting with "From:" and ending with CTE) and
> >> try again, I would suspect that you will get the same result.
> > No, you're wrong here:
> >
> > u...@dude.ptx:~/gsrc/linux$ head ~/tmp/1444332661.3982_89.ptx\:2\,RS
> > From: Tony Lindgren
> > Date: Tue, 6 Oct 2015 05:36:17 -0700
> > Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > added a debug option for GPMC, but somehow managed to keep it unselectable.
>
> I think you are the one who misread my question. I said "keep the
> in-body headers", didn't I? If you did the "head", then you would
> see something like this:
Ah got it. Yes, you're right. (Subject and Date are actually different
between real and in-body headers, but that's not important. git am picks
up the in-body headers.)
> > u...@dude.ptx:~/gsrc/linux$ head ~/tmp/1444332661.3982_89.ptx\:2\,RS
> > From: Tony Lindgren
> > Date: Tue, 6 Oct 2015 05:36:17 -0700
> > Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
> > ... probably Received: and all other junk from your mailbox ...
> >
> > From: Tony Lindgren
> > Date: Tue, 6 Oct 2015 05:36:17 -0700
> > Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> > added a debug option for GPMC, but somehow managed to keep it unselectable.
>
> >> I also think that the "MIME-Version" thing is what gives this;
> >> mailinfo and am do not really use it, and consider that the in-body
> >> header ends there.
> >
> > I failed to follow you here.
>
> I think if you tried the example with in-body header, you will see
> what I meant.
>
> >
> >> The right approach to tweak mailinfo to cope with this better would
> >> be to keep a bit more state inside mailinfo.c::handle_commit_msg()
> >> so that if we are (1) using in-body headers, (2) have already seen
> >> _some_ valid in-body header like "Subject:" and "From: ", and (3)
> >> have not seen a blank line, discard lines that we do not care about
> >> (e.g. "MIME-VERSION: 1.0").
The right thing should also happen if MIME-Version comes above Subject
in the body but other than that I'm with you here.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: please strip MIME-Version and Content-T{ype,ransfer-Encoding} in git am --scissors
Hello Junio,
On Thu, Oct 08, 2015 at 12:28:46PM -0700, Junio C Hamano wrote:
> Uwe Kleine-König writes:
>
> > Hello,
> >
> > when applying the mail below (without the '> ' prefix) using git am
> > --scissors the result looks like:
> >
> > $ git show
> > commit 26ef0606927cc1979faa4166d7f9f3584b5cdc61
> > Author: Tony Lindgren
> > Date: Tue Oct 6 05:36:17 2015 -0700
> >
> > memory: omap-gpmc: Fix unselectable debug option for GPMC
> >
> > MIME-Version: 1.0
> > Content-Type: text/plain; charset=UTF-8
> > Content-Transfer-Encoding: 8bit
> >
> > Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for
> > debug")
> > added a debug option for GPMC, but somehow managed to keep it
> > unselectable.
> >
> > [...]
> >
> > $ git version
> > git version 2.6.0
> >
> > The obvious improvement is to strip all headers like git am does without
> > --scissors.
>
> Does this have anything to do with scissors, though? If you remove
> everything before "8< ---" in the body of Tony's message (i.e. keep
> the in-body headers starting with "From:" and ending with CTE) and
> try again, I would suspect that you will get the same result.
No, you're wrong here:
u...@dude.ptx:~/gsrc/linux$ head ~/tmp/1444332661.3982_89.ptx\:2\,RS
From: Tony Lindgren
Date: Tue, 6 Oct 2015 05:36:17 -0700
Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
added a debug option for GPMC, but somehow managed to keep it unselectable.
u...@dude.ptx:~/gsrc/linux$ git am ~/tmp/1444332661.3982_89.ptx\:2\,RS
Applying: memory: omap-gpmc: Fix unselectable debug option for GPMC
u...@dude.ptx:~/gsrc/linux$ git cat-file commit HEAD
tree bab01e3e0d0bdd715b86cf7d5c9e8bb9768a30dc
parent c6fa8e6de3dc420cba092bf155b2ed25bcd537f7
author Tony Lindgren 1444134977 -0700
committer Uwe Kleine-König 1444332782 +0200
memory: omap-gpmc: Fix unselectable debug option for GPMC
Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
added a debug option for GPMC, but somehow managed to keep it unselectable.
This probably happened because I had some uncommitted changes and the
GPMC option is selected in the platform specific Kconfig.
Let's also update the description a bit, it does not mention that
enabling the debug option also disables the reset of GPMC controller
during the init as pointed out by Uwe Kleine-König
and Roger Quadros .
Fixes: 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
Reported-by: Uwe Kleine-König
Signed-off-by: Tony Lindgren
> I also think that the "MIME-Version" thing is what gives this;
> mailinfo and am do not really use it, and consider that the in-body
> header ends there.
I failed to follow you here.
> The right approach to tweak mailinfo to cope with this better would
> be to keep a bit more state inside mailinfo.c::handle_commit_msg()
> so that if we are (1) using in-body headers, (2) have already seen
> _some_ valid in-body header like "Subject:" and "From: ", and (3)
> have not seen a blank line, discard lines that we do not care about
> (e.g. "MIME-VERSION: 1.0").
That sound's right.
> > If someone wants a bounce of the original mail, just ask per PM.
>
> I have no idea what you are talking about here...
The result would be that a copy of the original mail would hit your mailbox if
you asked per private mail (PM).
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
please strip MIME-Version and Content-T{ype,ransfer-Encoding} in git am --scissors
Hello,
when applying the mail below (without the '> ' prefix) using git am
--scissors the result looks like:
$ git show
commit 26ef0606927cc1979faa4166d7f9f3584b5cdc61
Author: Tony Lindgren
Date: Tue Oct 6 05:36:17 2015 -0700
memory: omap-gpmc: Fix unselectable debug option for GPMC
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for
debug")
added a debug option for GPMC, but somehow managed to keep it
unselectable.
[...]
$ git version
git version 2.6.0
The obvious improvement is to strip all headers like git am does without
--scissors.
If someone wants a bounce of the original mail, just ask per PM.
Best regards
Uwe
On Wed, Oct 07, 2015 at 03:41:19AM -0700, Tony Lindgren wrote:
> * Uwe Kleine-König [151007 00:57]:
> > On Wed, Oct 07, 2015 at 10:45:50AM +0300, Roger Quadros wrote:
> > >
> > > How about this instead?
> > >
> > > NOTE: Apart from matching the register setup with the bootloader you also
> > > need to
> > > match the GPMC FCLK frequency used by the bootloader else the GPMC timings
> > > won't be identical with the bootloader timings.
> > Yeah, sounds better, thanks.
> >
> > > Also you might need to build this patch on top of
> > > http://article.gmane.org/gmane.linux.kernel/2054796
> > I talked to Tony about this patch yesterday on irc, but I didn't find it
> > in the archives yet when I sent my mail.
>
> Yes sorry here's a repost with your and Roger's changes folded in and
> edited a bit. Probably best to keep them together with this patch.
>
> Does the following look OK to you guys?
>
> Regards,
>
> Tony
>
> 8<
> From: Tony Lindgren
> Date: Tue, 6 Oct 2015 05:36:17 -0700
> Subject: [PATCH] memory: omap-gpmc: Fix unselectable debug option for GPMC
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
> Content-Transfer-Encoding: 8bit
>
> Commit 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> added a debug option for GPMC, but somehow managed to keep it unselectable.
>
> This probably happened because I had some uncommitted changes and the
> GPMC option is selected in the platform specific Kconfig.
>
> Let's also update the description a bit, it does not mention that
> enabling the debug option also disables the reset of GPMC controller
> during the init as pointed out by Uwe Kleine-König
> and Roger Quadros .
>
> Fixes: 63aa945b1013 ("memory: omap-gpmc: Add Kconfig option for debug")
> Reported-by: Uwe Kleine-König
> Signed-off-by: Tony Lindgren
>
> --- a/drivers/memory/Kconfig
> +++ b/drivers/memory/Kconfig
> @@ -58,12 +58,18 @@ config OMAP_GPMC
> memory drives like NOR, NAND, OneNAND, SRAM.
>
> config OMAP_GPMC_DEBUG
> - bool
> + bool "Enable GPMC debug output and skip reset of GPMC during init"
> depends on OMAP_GPMC
> help
> Enables verbose debugging mostly to decode the bootloader provided
> - timings. Enable this during development to configure devices
> - connected to the GPMC bus.
> + timings. To preserve the bootloader provided timings, the reset
> + of GPMC is skipped during init. Enable this during development to
> + configure devices connected to the GPMC bus.
> +
> + NOTE: In addition to matching the register setup with the bootloader
> + you also need to match the GPMC FCLK frequency used by the
> + bootloader or else the GPMC timings won't be identical with the
> + bootloader timings.
>
> config MVEBU_DEVBUS
> bool "Marvell EBU Device Bus Controller"
>
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] log-tree: let format-patch not indent notes
Hello Junio, On Thu, Sep 25, 2014 at 10:24:53AM -0700, Junio C Hamano wrote: > Uwe Kleine-König writes: > > Commit logs as shown by git-log are usually indented by four spaces so > > here it makes sense to do the same for commit notes. > > > > However when using format-patch to create a patch for submission via > > e-mail the commit log isn't indented and also the "Notes:" header isn't > > really useful. So consequently don't indent and skip the header in this > > case. This also removes the empty line between the end-of-commit marker > > and the start of the notes. > > > > Signed-off-by: Uwe Kleine-König > > --- > > This commit changes the output of format-patch (applied on this commit) > > from: > > > > ... > > case. > > > > Signed-off-by: Uwe Kleine-König > > --- > > > > Notes: > > This commit changes the output of format-patch (applied on this > > commit) from: > > > > to > > > > ... > > case. > > > > Signed-off-by: Uwe Kleine-König > > --- > > This commit changes the output of format-patch (applied on this commit) > > from: > > > > which I consider to be more useful. > > I suspect that is fairly subjective, as the current one is in that > form because those who wrote this feature first, reviewed, applied > would have considered it more useful, isn't it? Well, I thought when the feature to dump the notes into a patch was created there was exactly one way these notes were written. This was was designed for git-log and so intended and with "Notes:". For git-format-patch it was good enough. > Because I never send out a format-patch output without looking it > over in an editor, I know I can easily remove it if I find the > "Notes:" out of place in the output, but if the "Notes:" thing > weren't there in the first place I may scratch my head trying to > figure out where to update it if the information there were stale, > so for that reason I'd find it more useful to have Notes: to remind > me where that information comes from. As you must explicitly request notes to be included in patches (--notes) I think it's unusual to not know where the info comes from, doesn't it? I don't know how many people use git-notes to track their comments, but the first thing I do when editing patches is to remove the Notes: header and s/^// on the remaining lines. And most of the time this is the only thing I do and I need to touch every patch only because of that. > But that is just my personal preference and I am willing to be > persuaded either way with a better argument than "to me it looks > nicer". > > As to indenting, because the material after three-dashes is meant to > be fed to "git apply" or "patch", I'd prefer to keep it to avoid > having to worry about a payload that may look like part of a patch. > This preference is a bit stronger than the presence/absence of > "Notes:". Ok, that's a valid concern. If we want to assert that this doesn't look like a patch we need to at least parse the notes and quote it somehow. Hmm. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH RFC] log-tree: let format-patch not indent notes
Commit logs as shown by git-log are usually indented by four spaces so
here it makes sense to do the same for commit notes.
However when using format-patch to create a patch for submission via
e-mail the commit log isn't indented and also the "Notes:" header isn't
really useful. So consequently don't indent and skip the header in this
case. This also removes the empty line between the end-of-commit marker
and the start of the notes.
Signed-off-by: Uwe Kleine-König
---
This commit changes the output of format-patch (applied on this commit) from:
...
case.
Signed-off-by: Uwe Kleine-König
---
Notes:
This commit changes the output of format-patch (applied on this
commit) from:
to
...
case.
Signed-off-by: Uwe Kleine-König
---
This commit changes the output of format-patch (applied on this commit)
from:
which I consider to be more useful.
log-tree.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/log-tree.c b/log-tree.c
index bcee7c596696..c1d73d8fecdf 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -585,7 +585,8 @@ void show_log(struct rev_info *opt)
int raw;
struct strbuf notebuf = STRBUF_INIT;
- raw = (opt->commit_format == CMIT_FMT_USERFORMAT);
+ raw = (opt->commit_format == CMIT_FMT_USERFORMAT) ||
+ (opt->commit_format == CMIT_FMT_EMAIL);
format_display_notes(commit->object.sha1, ¬ebuf,
get_log_output_encoding(), raw);
ctx.notes_message = notebuf.len
--
2.1.1.274.gb3e1830.dirty
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG?: git-filter-branch removes mergetags
Hello, I just noticed that git-filter-branch doesn't preserve mergetag annotations in situations where it could. Here is an example (with linux.git): $ git checkout -b test 6cd2f85413eef8fe7bcd7c25bf55e7b055fa257c $ git cat-file commit HEAD | grep mergetag mergetag object 954263938706bf62d36e81b6b49f313390f2ed35 $ git filter-branch -f --msg-filter 'sed s/foo/bar/' HEAD^! Rewrite 6cd2f85413eef8fe7bcd7c25bf55e7b055fa257c (1/1) Ref 'refs/heads/test' was rewritten $ diff -u <(git cat-file commit refs/original/refs/heads/test) <(git cat-file commit HEAD) --- /dev/fd/63 2014-09-23 21:07:49.987065017 +0200 +++ /dev/fd/62 2014-09-23 21:07:49.991064988 +0200 @@ -3,32 +3,6 @@ parent 954263938706bf62d36e81b6b49f313390f2ed35 author Linus Torvalds 1411488823 -0700 committer Linus Torvalds 1411488823 -0700 -mergetag object 954263938706bf62d36e81b6b49f313390f2ed35 - type commit - tag for-linus - tagger Paolo Bonzini 1411478481 +0200 - - Another fix for 3.17 arrived at just the wrong time, after I had sent - yesterday's pull request. Normally I would have waited for - some other patches to pile up, but since 3.17 might be short - here it is. - -BEGIN PGP SIGNATURE- - Version: GnuPG v2.0.22 (GNU/Linux) - - iQIcBAABAgAGBQJUIXPRAAoJEBvWZb6bTYbyySEP/AkPjfNGYqwBbM8GUJ4tt4gR - C+xbiO+xPr2qCwfi36DQtL0UPwJHWSq7SXaDMvSqMo22FjnFcVaGuQcGAPno/8ZA - tLBe1km9HIPlEIV3vpoe8PPpj9cuZ86+YOCuPIqK5fC7l6Ops0dhCOjf88tmPVQ4 - yhodpJ1Lt/sPBUWb6pNfk0iWD+qSbfUWtwzv89oudEvLcLiAcPSBdbvnxVS3bmGm - qbL8pvCOozK5GJbl0+cYWCoEPBP5ekqGvwvGdEBTx+4qv2S2htzUX30UA2VYy5IR - jMXVrJbvSW9FXQdBgr0Q4ql6evOVjL+5LpwgRUC6tuC6r1rMP+nXyHKS35HC1i8W - FYr62B/LZTm4vyDHsmsiEl43VLAcF7kmXufQT62vJg+ifeA1MAMIJra7ZDx8WbsD - HDqM+CeaZrF3p4okRrktbecQdeFFyg4wOasHRTO7SETkbP7i1cS0Mp8rRbX3CnJq - 0UM8STe+hViXR7uYZEbjlbGKkszDS49fstJIaNm9JPJm+S/V5/MZFelNWgPp/+kF - xpQUxtoSaFnqgBXpRZ7t2Y2zGeZkMWn/P84S23/7K1TfRPCsUpgFbiY26rGW9l4v - r8gz7v+V1gCzWYVRuEzolFrea6A1ik2sspzeDuZOrf+QYwMyyUdEQ/NfCm032wba - CYL0V2M/dJNmZnZRPP9/ - =ZkSE - -END PGP SIGNATURE- Merge tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm I expected the signature to not disappear such that in the example above no change is introduced. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: git request-pull broken for plain branches
Hi Junio, On Wed, Jun 25, 2014 at 01:41:23PM -0700, Junio C Hamano wrote: > Uwe Kleine-König writes: > > On Wed, Jun 25, 2014 at 05:05:51AM -0700, Linus Torvalds wrote: > >> On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König > >> wrote: > >> > > >> > $ git rev-parse HEAD > >> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 > >> > $ git ls-remote origin | grep > >> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 > >> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 > >> > refs/heads/ukl/for-mainline > >> > $ git request-pull origin/master origin HEAD > /dev/null > >> > warn: No match for commit > >> > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 found at origin > >> > warn: Are you sure you pushed 'HEAD' there? > >> > >> Notice how "HEAD" does not match. > >> > >> The error message is perhaps misleading. It's not enough to match the > >> commit. You need to match the branch name too. git used to guess the > >> branch name (from the commit), and it often guessed wrongly. So now > >> they need to match. > >> > >> So you should do > >> > >> git request-pull origin/master origin ukl/for-mainline > >> > >> to let request-pull know that you're requesting a pull for > >> "ukl/for-mainline". > > Or > > git request-pull origin/master origin HEAD:ukl/for-mainline > > I am not Linus, and do not speak for him, but FWIW here are some > comments on the ideas. > > > I liked git guessing the branch name, maybe we can teach it to guess a > > bit better than it did before 2.0? Something like: > > > > - if there is a unique match on the remote side, use it. > > I am on the fence but slightly leaning to the negative side on this > one. The branch/ref the object was took from when "git pull" is run > does matter, because the name is recorded in the merge summary, so > we cannot say "There are refs that happen to point at the object you > wanted to be pulled, so we'll pick one of them let the integrator > pull from that ref we randomly chose" is not something we would > want. "If there is a unique one, that must be the one the user has > meant; there is nothing else possible" feels like a strong argument, > and I was actually contemplating about doing an enhancement on top > of Linus's original myself along that line, back when we queued that > patch exactly for that reason. > > But a counter-argument, in the context of Linus's change in question > being primarily to avoid end-user mistakes resulting in a bogus > request, is that the ref on the remote that happens to match the > object but is different from what the user named may be a totally > unrelated branch before the user actually has pushed the set of > changes the request is going to ask to be pulled. The mistake that > this extra strictness tries to avoid is to compose request-pull > before pushing what to be pulled and then forgetting to push. Sounds sensible. Then the enhancements that come to my mind are: Change git-request-pull to explicitly take a remote ref as end. This makes sure that it is actually there and the right remote name is picked. Don't require to specify a local ref even if there is no local matching ref, just use the remote sha1 to generate the diffstat and summary. Another thing I'd like to have is to make git-request-pull not generate the usual output if there is no match. Optionally introduce a -f to get back the (maybe bogus) output; in this case a local rev would be needed. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG: git request-pull broken for plain branches
Hello Linus, On Wed, Jun 25, 2014 at 05:05:51AM -0700, Linus Torvalds wrote: > On Wed, Jun 25, 2014 at 2:55 AM, Uwe Kleine-König > wrote: > > > > $ git rev-parse HEAD > > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 > > $ git ls-remote origin | grep > > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 > > 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 > > refs/heads/ukl/for-mainline > > $ git request-pull origin/master origin HEAD > /dev/null > > warn: No match for commit 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 > > found at origin > > warn: Are you sure you pushed 'HEAD' there? > > Notice how "HEAD" does not match. > > The error message is perhaps misleading. It's not enough to match the > commit. You need to match the branch name too. git used to guess the > branch name (from the commit), and it often guessed wrongly. So now > they need to match. > > So you should do > > git request-pull origin/master origin ukl/for-mainline > > to let request-pull know that you're requesting a pull for "ukl/for-mainline". > > If you have another name for that branch locally (ie you did something > like "git push origin local:remote"), then you can say > > git request-pull origin/master origin local-name:remote-name > > to specify what the branch to be pulled is called locally vs remotely. > > In other words, what used to be "pick some branch randomly" is now > "you need to _specify_ the branch". ah, got it. Still some of my concerns stay valid and I also have some new ones: - if there is a branch and a tag on the remote side that match what I specified the outcome depends on the order of git-ls-remote. (minor nit.) - if I have to specify the remote name now, why do I have to also specify my local ref? Isn't the respective $sha1 of the remote side enough to do what is needed? - Isn't $found = $sha1; silly because I cannot pull a rev, only a ref? (side note: git pull linus d91d66e88ea95b6dd21958834414009614385153 gives no error message, only returns 1 and does nothing else.) - Is the result of git request-pull $somecommit origin what is intended? For me it does ... are available in the git repository at: $repository for you to fetch changes ... if the remote HEAD matches the local one. I'd prefer to have an explicit branch name there, or at least HEAD. I liked git guessing the branch name, maybe we can teach it to guess a bit better than it did before 2.0? Something like: - if there is a unique match on the remote side, use it. - if there are >= 1 match on the remote side and exactly one matches what I specified as , use it. - if there are >= 1 match on the remote side and exactly one of them is a tag, use the tag - if there are two matches on the remote side, and one is "HEAD", pick the other one. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG: git request-pull broken for plain branches
Hello, I have git from Debian's 2.0.0-2 package: $ git version git version 2.0.0 git request-pull is broken for me: $ git rev-parse HEAD 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 $ git ls-remote origin | grep 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 refs/heads/ukl/for-mainline $ git request-pull origin/master origin HEAD > /dev/null warn: No match for commit 9e065e4a5a58308f1a0da4bb80b830929dfa90b3 found at origin warn: Are you sure you pushed 'HEAD' there? The same happens on 2.0.0.421.g786a89d. The problem is in git-request-pull.sh's find_matching_ref. This code has more than one problem (looking on 2.0.0.421.g786a89d): - find_matching_ref doesn't assign to $found if none of the if conditions in the loop match (this results in my problem); - find_matching_ref happily overwrites $found even if the previous ref was better according to the metric specified above the definition of find_matching_ref; and - the output generated uses $pretty_remote without asserting that it matches $ref. In my case this results in a branch specification of "HEAD" even if I fix find_matching_ref to return refs/heads/ukl/for-mainline. I tried to add this case to t/t5150-request-pull.sh, but didn't understand how after starring at it for half an hour. :-( Bisection points on 024d34cb0813 (request-pull: more strictly match local/remote branches) as first bad commit. Apart from introducing the warning, it also changes the branch spec from "ukl/for-mainline" (which is correct) to the name of the current branch (which is bogus). Also 024d34cb0813 makes 5 out of 7 tests in t/t5150-request-pull.sh fail. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature-request: git notes copy --to
Hello again,
On Thu, Feb 20, 2014 at 10:03:34PM +0100, Uwe Kleine-König wrote:
> I'm playing around with git-notes and want to share some of my notes
> with my co-workers. We have a central repository for our various topic
> branches and want to track upstream inclusion in git-notes. So we have
> to share our notes branch somehow.
>
> The workflow I think makes sense here is (untested):
>
> ### hack hack, add notes bla blub
> ### -> nice topic branch with some notes
>
> git fetch serverrepo refs/notes/commits:refs/notes/servercommits
> git notes merge refs/notes/servercommits
> git rev-list origin/master.. | awk '{print $1 " " $1}' | git notes copy
> --to refs/notes/servercommits --stdin
> git push serverrepo refs/notes/servercommits:refs/notes/commits
>
> Then maybe:
>
> git notes merge refs/notes/servercommits
>
> again.
>
> The idea here is to only include notes in refs/notes/servercommits that
> are relevant for my coworkers and not all intermediate notes that were
> created during development or while working on other branches.
>
> Does this make sense? Do you have better ideas or suggestions how to
> improve the workflow?
>
> The only problem now is that git notes copy doesn't take a --to
> parameter. Maybe there is a volunteer to implement it? Then I'd
> volunteer to test it :-)
I have implemented something now to copy notes to another branch. Here
is it for reference:
--->8---
#! /bin/sh
set -e
. git-sh-setup
# for now the remote notes rev must be a ref below refs/notes
# see id:20140220153045.gi6...@pengutronix.de for the respective plea.
remote_notes="refs/notes/servercommits"
local_notes="$(git notes get-ref)"
remote_notes_ref=$(git rev-parse --verify "$remote_notes^{commit}")
tmpfile=$(mktemp)
trap "rm \"$tmpfile\"" EXIT
git rev-list "$@" | sed 's/^/100644 blob [0-9a-f]{40}\t/' > $tmpfile
GIT_DIR=$(git rev-parse --git-dir)
GIT_INDEX_FILE="$GIT_DIR/index-rnotes" git read-tree "$remote_notes"
git ls-tree "$local_notes" | grep -E -f "$tmpfile" |
GIT_INDEX_FILE="$GIT_DIR/index-rnotes" git update-index --index-info
tree=$(GIT_INDEX_FILE="$GIT_DIR/index-rnotes" git write-tree)
if test "x$tree" = "x$(git rev-parse "$remote_notes_ref^{tree}")"; then
echo "empty commit"
exit 0
fi
commit=$(git commit-tree "$tree" -p "$remote_notes_ref" << EOF
Notes added by 'git notes-copy'
source notes: $(git rev-parse $local_notes)
EOF
)
git update-ref "$remote_notes" $commit $remote_notes_ref
--->8---
It still has some edges, but I think it will do for me. Enhancements
welcome.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
feature-request: git notes copy --to
Hello,
I'm playing around with git-notes and want to share some of my notes
with my co-workers. We have a central repository for our various topic
branches and want to track upstream inclusion in git-notes. So we have
to share our notes branch somehow.
The workflow I think makes sense here is (untested):
### hack hack, add notes bla blub
### -> nice topic branch with some notes
git fetch serverrepo refs/notes/commits:refs/notes/servercommits
git notes merge refs/notes/servercommits
git rev-list origin/master.. | awk '{print $1 " " $1}' | git notes copy
--to refs/notes/servercommits --stdin
git push serverrepo refs/notes/servercommits:refs/notes/commits
Then maybe:
git notes merge refs/notes/servercommits
again.
The idea here is to only include notes in refs/notes/servercommits that
are relevant for my coworkers and not all intermediate notes that were
created during development or while working on other branches.
Does this make sense? Do you have better ideas or suggestions how to
improve the workflow?
The only problem now is that git notes copy doesn't take a --to
parameter. Maybe there is a volunteer to implement it? Then I'd
volunteer to test it :-)
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
$(git notes merge FETCH_HEAD) doesn't work
Hello,
I started playing around with sharing git notes and so was happy to see
that git-notes learned about merging since I last tried.
My first try looked as follows (using git 1:1.9.0-1 from Debian):
$ git fetch $someremote refs/notes/commits
...
$ git notes merge FETCH_HEAD
$ echo $?
0
$ git log --oneline refs/notes/commits..FETCH_HEAD | wc -l
2
Looking at the source I see:
/* argv[0] holds "FETCH_HEAD" here */
strbuf_addstr(&remote_ref, argv[0]);
expand_notes_ref(&remote_ref);
After the call to expand_notes_ref remote_ref contains
"refs/notes/FETCH_HEAD" which isn't what I intended and I'm quite
surprised by. The problem seems to be:
/* Dereference o->remote_ref into remote_sha1 */
if (get_sha1(o->remote_ref, remote_sha1)) {
/*
* Failed to get remote_sha1. If o->remote_ref looks like an
* unborn ref, perform the merge using an empty notes tree.
*/
if (!check_refname_format(o->remote_ref, 0)) {
hashclr(remote_sha1);
remote = NULL;
} else {
die("Failed to resolve remote notes ref '%s'",
o->remote_ref);
}
} ...
The workaround is obvious (i.e. git update-ref refs/notes/somestring
FETCH_HEAD; git notes merge somestring), but still I think this
behaviour is not optimal. I don't know why one might want to treat a
broken remote side as empty but at least a diagnostic message would be
nice. The same happens if I pass an explicit sha1 instead of
"FETCH_HEAD".
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG?] git checkout $commit -- somedir doesn't drop files
Hello, after these commands: $ git init $ mkdir subdir $ echo a > subdir/a $ git add subdir/a $ git commit -m a $ echo more a >> subdir/a $ echo b > subdir/b $ git add subdir/* $ git commit -m b $ git checkout HEAD^ -- subdir I'd expect that subdir/b is removed from the index as this file didn't exist in HEAD^ but git-status only reports: # On branch master # Changes to be committed: # (use "git reset HEAD ..." to unstage) # # modified: subdir/a # Is this intended? (I'm using git 1.8.4.rc3 as shipped by Debian (package version 1:1.8.4~rc3-1).) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] log: use true parents for diff even when rewriting
Hello Thomas, On Tue, Jul 23, 2013 at 09:27:06AM +0200, Thomas Rast wrote: > Junio C Hamano writes: > > Conceptually I can see how this will change the history > > simplification in the vertical direction (skipping the ancestry > > chain and jumping directly to the closest grandparent that touched > > the specified path), but I am not sure how well this interacts with > > history simplification in the horizontal direciton (culling > > irrelevant side branches from the merge). > > But isn't that similarly confusing for the user as Uwe's original > problem? Suddenly we'd be showing a merge commit as an ordinary one, > simply because the merged history did not affect the filtered > pathspecs. Thus we would show everything that has been merged on the > *other* files as a big diff. Would that be useful? It would certainly > be a big difference in how the commit is shown. the merge is only included in the output if on both parent paths the file is touched. So this is a non-issue, isn't it? (Well, only if it has more than 2 parents and not all ancestor paths touch the file, the number of parents shown is changed.) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
git log anomalities
Hello, today I looked at the changes to drivers/net/ethernet/freescale/fec.c in the kernel since v3.8 using git log --stat v3.8.. --full-diff -- drivers/net/ethernet/freescale/fec.c which looks as expected. But when I added --graph the diffstats change. E.g. for 793fc0964be1921f15a44be58b066f22b925d90b it changes from: drivers/net/ethernet/freescale/Makefile |3 +- drivers/net/ethernet/freescale/fec.c | 1966 - drivers/net/ethernet/freescale/fec_main.c | 1966 + drivers/net/ethernet/freescale/fec_ptp.c |3 - 4 files changed, 1968 insertions(+), 1970 deletions(-) to | Documentation/devicetree/bindings/net/dsa/dsa.txt | 91 + | .../bindings/net/marvell-orion-mdio.txt |3 + | Documentation/networking/ip-sysctl.txt| 35 +- | MAINTAINERS |2 +- | arch/arm/net/bpf_jit_32.c |5 +- | arch/arm/plat-orion/common.c | 54 +- | arch/powerpc/net/bpf_jit_comp.c | 12 +- | ... | 404 files changed, 15373 insertions(+), 8563 deletions(-) Is that a bug, or a feature I don't understand? (I'm using Debian's 1:1.8.3.2-1) Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature suggestion: optimize common parts for checkout --conflict=diff3
Hi Jeff, On Thu, Apr 04, 2013 at 04:33:44PM -0400, Jeff King wrote: > [...] > So I do think zdiff3 is useful, and I plan to continue using it. Thanks for your description. I'm using and liking zdiff3, too. So I'd really like seeing it in vanilla git. Thanks Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG gitk] strange scrolling behaviour if history canvas not completely filled
Hello, (running gitk from Debian's gitk 1:1.8.2~rc3-1 package) if only a few commits are shown in gitk such that the history canvas is too big, i.e. there is place for more commits to be shown, the scroll bar on the right hand side correctly is greyed out. Still I can scroll using the mouse moving the oldest shown to the bottom of the canvas (sometimes even half a line further). Not sure this qualifies as bug already. But when having scrolled down selecting commits with the mouse doesn't work as expected anymore: If I click on the topmost commit, not that one is selected but the one that would appear at the mouse tip if the history were not scrolled down. Best regards Uwe PS: I'm not subscribed, so please Cc: me on replies. -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[BUG gitk] notes not reloaded on Update/Reload
Hello, running gitk from Debian (1:1.8.2~rc3-1) I noticed that $ gitk ... & $ git notes edit $some_ref_shown_by_gitk and then pressing F5 or Shift-F5 doesn't update the notes shown. Best regards Uwe PS: Please Cc: on replies as I'm not subscribed -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature suggestion: optimize common parts for checkout --conflict=diff3
Hello Junio, On Wed, Mar 06, 2013 at 01:09:41PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > But it would apply to the content that is outside > > of the hunk marker; we have changed the concept of what is in the base > > and what is in the conflict by shrinking the conflict to its smallest > > size. > > Hmm, unless you mean by "base" something entirely different from > "what was in the common ancestor version", I do not think I can > agree. The point of diff3 mode is to show how it looked line in the > common ancestor and what the conflicting sides want to change that > common version into; letting the user view three versions to help > him decide what to do by only looking at the part inside conflict > markers. > > We show "both sides added, either identically or differently" as > noteworthy events, but the patched code pushes "both sides added > identically" case outside the conflicting hunk, as if what was added I didn't test, but "both sides removed identically" should be moved out, too, shouldn't it? > relative to the common ancestor version (in Uwe's case, is it 1-14 > that is common, or just 10-14?) is not worth looking at when > considering what the right resolution is. If it is not worth > looking at what was in the original for the conflicting part, why > would we be even using diff3 mode in the first place? because even zdiff3 contains more information than merge. And compared to diff3 it's smaller sometimes and so easier to understand. Other than that I agree fully to the things Jeff said so far. Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] xdiff: implement a zealous diff3
"zdiff3" is identical to ordinary diff3, only it allows more aggressive
compaction than diff3. This way the displayed base isn't necessary
technically correct, but still this mode might help resolving merge
conflicts between two near identical additions.
Signed-off-by: Uwe Kleine-König
---
Hello,
this patch implements what I want. Thanks to Jeff for pointing me to the
right code to modify.
Best regards
Uwe
builtin/merge-file.c | 2 ++
contrib/completion/git-completion.bash | 2 +-
xdiff-interface.c | 2 ++
xdiff/xdiff.h | 1 +
xdiff/xmerge.c | 8 +++-
5 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/builtin/merge-file.c b/builtin/merge-file.c
index c0570f2..4ef86aa 100644
--- a/builtin/merge-file.c
+++ b/builtin/merge-file.c
@@ -32,6 +32,8 @@ int cmd_merge_file(int argc, const char **argv, const char
*prefix)
struct option options[] = {
OPT_BOOLEAN('p', "stdout", &to_stdout, N_("send results to
standard output")),
OPT_SET_INT(0, "diff3", &xmp.style, N_("use a diff3 based
merge"), XDL_MERGE_DIFF3),
+ OPT_SET_INT(0, "zdiff3", &xmp.style, N_("use a zealous diff3
based merge"),
+ XDL_MERGE_ZEALOUS_DIFF3),
OPT_SET_INT(0, "ours", &xmp.favor, N_("for conflicts, use our
version"),
XDL_MERGE_FAVOR_OURS),
OPT_SET_INT(0, "theirs", &xmp.favor, N_("for conflicts, use
their version"),
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index b62bec0..a0d887e 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1091,7 +1091,7 @@ _git_checkout ()
case "$cur" in
--conflict=*)
- __gitcomp "diff3 merge" "" "${cur##--conflict=}"
+ __gitcomp "diff3 merge zdiff3" "" "${cur##--conflict=}"
;;
--*)
__gitcomp "
diff --git a/xdiff-interface.c b/xdiff-interface.c
index ecfa05f..a911c25 100644
--- a/xdiff-interface.c
+++ b/xdiff-interface.c
@@ -308,6 +308,8 @@ int git_xmerge_config(const char *var, const char *value,
void *cb)
die("'%s' is not a boolean", var);
if (!strcmp(value, "diff3"))
git_xmerge_style = XDL_MERGE_DIFF3;
+ else if (!strcmp(value, "zdiff3"))
+ git_xmerge_style = XDL_MERGE_ZEALOUS_DIFF3;
else if (!strcmp(value, "merge"))
git_xmerge_style = 0;
else
diff --git a/xdiff/xdiff.h b/xdiff/xdiff.h
index 219a3bb..9730c63 100644
--- a/xdiff/xdiff.h
+++ b/xdiff/xdiff.h
@@ -64,6 +64,7 @@ extern "C" {
/* merge output styles */
#define XDL_MERGE_DIFF3 1
+#define XDL_MERGE_ZEALOUS_DIFF3 2
typedef struct s_mmfile {
char *ptr;
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 9e13b25..4772707 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -177,7 +177,7 @@ static int fill_conflict_hunk(xdfenv_t *xe1, const char
*name1,
size += xdl_recs_copy(xe1, m->i1, m->chg1, 1,
dest ? dest + size : NULL);
- if (style == XDL_MERGE_DIFF3) {
+ if (style == XDL_MERGE_DIFF3 || style == XDL_MERGE_ZEALOUS_DIFF3) {
/* Shared preimage */
if (!dest) {
size += marker_size + 1 + marker3_size;
@@ -420,6 +420,12 @@ static int xdl_do_merge(xdfenv_t *xe1, xdchange_t *xscr1,
int style = xmp->style;
int favor = xmp->favor;
+ /*
+* This is the only change between XDL_MERGE_DIFF3 and
+* XDL_MERGE_ZEALOUS_DIFF3. "zdiff3" isn't 100% technically correct (as
+* the base might be considerably simplified), but still it might help
+* interpreting conflicts between two big and near identical additions.
+*/
if (style == XDL_MERGE_DIFF3) {
/*
* "diff3 -m" output does not make sense for anything
--
1.8.2.rc2
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
feature suggestion: optimize common parts for checkout --conflict=diff3
Hello, Here comes another recipe for a different suggestion: git init echo 1 > file git add file git commit -m 'base' git branch branch seq 1 30 | grep -v 15 > file git commit -m 'add 2-30 without 15' file git checkout branch seq 1 30 | grep -v 16 > file git commit -m 'add 2-30 without 16' file git merge master git diff This yields: diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -12,7 -12,7 +12,11 @@@ 12 13 14 ++<<<<<<< HEAD +15 ++=== + 16 ++>>>>>>> master 17 18 19 as expected; nice and sweet. After git checkout --conflict=diff3 file however the difference isn't that easy to spot any more. I expected diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -12,7 -12,7 +12,12 @@@ 12 13 14 ++<<<<<<< ours +15 ++||| base ++=== + 16 ++>>>>>>> theirs 17 18 19 But instead I get diff --cc file index a07e697,5080129..000 --- a/file +++ b/file @@@ -1,29 -1,29 +1,61 @@@ 1 ++<<<<<<< ours +2 +3 +4 +5 +6 +7 +8 +9 +10 +11 +12 +13 +14 +15 +17 +18 +19 +20 +21 +22 +23 +24 +25 +26 +27 +28 +29 +30 ++||| base ++=== + 2 + 3 + 4 + 5 + 6 + 7 + 8 + 9 + 10 + 11 + 12 + 13 + 14 + 16 + 17 + 18 + 19 + 20 + 21 + 22 + 23 + 24 + 25 + 26 + 27 + 28 + 29 + 30 ++>>>>>>> theirs Of course this is technically correct, just not maximally helpful. Is this a missing optimisation for the diff3 case or did I miss a detail that makes my expectation wrong? Best regards Uwe -- Pengutronix e.K. | Uwe Kleine-König| Industrial Linux Solutions | http://www.pengutronix.de/ | -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: feature suggestion: improve rerere
On Wed, Mar 06, 2013 at 02:24:18PM +0100, Johannes Sixt wrote:
> Am 3/6/2013 11:16, schrieb Uwe Kleine-König:
> > ++<<<<<<< ours
> > +ssize_t xread(int fd, void *buf, size_t count)
> > +{
> > + ssize_t ret, done = 0;
> > +
> > +retry:
> > + ret = read(fd, buf + done, count - done);
> > + if (ret < 0)
> > + return ret;
> > +
> > + done += ret;
> > +
> > + if (ret == 0 /* EOF */ || done == count)
> > + return done;
> > + else
> > + goto retry;
> > +}
> > +
> > ++||| base
> > ++===
> > + #include "common.h"
> > +
> > ++>>>>>>> theirs
> > int main(int argc,char *argv[])
> > {
> > int fd, val, ret, size, wrote, len;
> >
> > This is the same conflict as the first one, just with ours and theirs
> > exchanged. So my suggestion is to make rerere use the resolution
> > recorded for the first conflict here.
> >
> > Sounds sensible?
>
> Of course, and rerere already does it. But only when you use git's default
> conflict markers rather than diff3 style markers that have this extra
> | line.
I only did git checkout --conflict=diff3 after the merge conflict
happend. So I cannot confirm that git already does it.
So here is a reproduction receipe:
git clone git://git.infradead.org/mtd-utils.git
cd mtd-utils
git checkout ca39eb1
wget -O patch1
http://article.gmane.org/gmane.linux.drivers.mtd/45779/raw
wget -O patch2
http://article.gmane.org/gmane.linux.drivers.mtd/45591/raw
for p in patch1 patch2; do perl -p -i -e 'print "From tralala Mon Sep
17 00:00:00 2001\n" if $. == 1' $p; done
git am patch1
git am -3 patch2 # first merge conflict
perl -n -i -e 's/===//; print unless /^[<>]{7} /;'
flash_otp_write.c # resolve
git add flash_otp_write.c
git am --resolved
git rebase -i ca39eb1 # swap order of the two patches
results in
$ git ls-files -u
100644 f360a3e025deaf7acfb7b20c9fad90f498ae4430 1
flash_otp_write.c
100644 d407ebbf400e630dc00ee004ecb44be8af51b25d 2
flash_otp_write.c
100644 31b963e2d6cf0016ca542529886e1ee71a22664e 3
flash_otp_write.c
and resolving yields:
$ git ls-files -s flash_otp_write.c
100644 648e0422d21c0ffa7621f82b86c02a065e488293 0
flash_otp_write.c
Then
git rebase --continue
gives the 2nd rebase conflict:
$ git ls-files -u
100644 d407ebbf400e630dc00ee004ecb44be8af51b25d 1
flash_otp_write.c
100644 648e0422d21c0ffa7621f82b86c02a065e488293 2
flash_otp_write.c
100644 f360a3e025deaf7acfb7b20c9fad90f498ae4430 3
flash_otp_write.c
Now knowing from the previous resolution that with base=f360a3e0
(= origin + patch1) merging
d407ebbf (= origin) and
31b963e2 (= origin + patch1 + patch2)
gives 648e0422 (origin + patch2),
git could know that with base=d407ebbf (origin) merging 648e0422 (origin
+ patch1) and f360a3e0 (origin + patch1) gives 31b963e2 (origin + patch1
+ patch2) again.
And git doesn't prepare 31b963e2 in flash_otp_write.c for me.
@Johannes, do you have some non-standard setting, or can you reproduce?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
feature suggestion: improve rerere
Hello,
I think the following suggestion is sound. And it might even be easy to
implement but I don't know how rerere works, so I might be wrong here.
When applying a patch it's normal to hit a conflict. For me this just
happend:
$ git diff
diff --cc flash_otp_write.c
index f360a3e,648e042..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,8 -15,23 +15,29 @@@
#include
++<<<<<<< ours
+#include "common.h"
+
++||| base
++===
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret < 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
++>>>>>>> theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
easy to resolve to:
$ git diff
diff --cc flash_otp_write.c
index f360a3e,648e042..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,8 -15,23 +15,25 @@@
#include
+#include "common.h"
+
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret < 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
Now if I shuffle patches and put the new patch before the conflicting
patch, I have to resolve first:
$ git diff
diff --cc flash_otp_write.c
index d407ebb,31b963e..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,6 -15,25 +15,31 @@@
#include
++<<<<<<< ours
++||| base
++#include "common.h"
++
++===
+ #include "common.h"
+
+ ssize_t xread(int fd, void *buf, size_t count)
+ {
+ ssize_t ret, done = 0;
+
+ retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret < 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+ }
+
++>>>>>>> theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
which is resolved to just adding the function and dropping the #include.
But then readding the 2nd patch it conflicts again:
$ git diff
diff --cc flash_otp_write.c
index 648e042,f360a3e..000
--- a/flash_otp_write.c
+++ b/flash_otp_write.c
@@@ -15,23 -15,8 +15,29 @@@
#include
++<<<<<<< ours
+ssize_t xread(int fd, void *buf, size_t count)
+{
+ ssize_t ret, done = 0;
+
+retry:
+ ret = read(fd, buf + done, count - done);
+ if (ret < 0)
+ return ret;
+
+ done += ret;
+
+ if (ret == 0 /* EOF */ || done == count)
+ return done;
+ else
+ goto retry;
+}
+
++||| base
++===
+ #include "common.h"
+
++>>>>>>> theirs
int main(int argc,char *argv[])
{
int fd, val, ret, size, wrote, len;
This is the same conflict as the first one, just with ours and theirs
exchanged. So my suggestion is to make rerere use the resolution
recorded for the first conflict here.
Sounds sensible?
Best regards
Uwe
PS: I'm using Debian's git 1.8.2~rc2-1 and hope I didn't miss this
feature already implemented while looking through v1.8.2..junio/next.
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/7] Add support for Freescale's mc34708 to mc13xxx driver
Hello,
[I added git@vger.k.o to Cc: please strip the recipents accordingly if
you reply.]
On Fri, Jul 13, 2012 at 09:02:56AM +1000, Marc Reilly wrote:
> Hi Uwe,
>
> > This series was tested on a Phytec pcm038 (mc13783 on spi) using
> > traditional boot (i.e. not dt) and on a i.MX53 based machine (mc34708 on
> > i2c) using dt boot.
> >
> > Philippe's patches are already in next, they are just included here for
> > those who want to test the patches. The 'mfd/mc13xxx: drop modifying
> > driver's id_table in probe' was already sent out yesterday and is
> > included here because the last patch depends on it.
> >
>
> For all patches (that don't already have it):
> Acked-by: Marc Reilly
Thanks.
> If for some reason you do a V2:
> - In patch 6 moves line "#define MC13XXX_NUMREGS 0x3f" around, is this
> necessary?
It doesn't move it around, that's only how it looks. I removed enum
mc13xxx_id (above MC13XXX_NUMREGS) and added struct mc13xxx_variant
(below MC13XXX_NUMREGS). Git choosed to use the closing brace of enum
mc13xxx_id and struct mc13xxx_variant respectively as context (together
with the following empty line).
(For the new readers, here is how git represented the relevant part:
#include
#include
-enum mc13xxx_id {
- MC13XXX_ID_MC13783,
- MC13XXX_ID_MC13892,
- MC13XXX_ID_INVALID,
+#define MC13XXX_NUMREGS 0x3f
+
+struct mc13xxx;
+
+struct mc13xxx_variant {
+ const char *name;
+ void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
};
-#define MC13XXX_NUMREGS 0x3f
+extern struct mc13xxx_variant
+ mc13xxx_variant_mc13783,
+ mc13xxx_variant_mc13892;
struct mc13xxx {
struct regmap *regmap;
...
)
The following would be an equivalent and (for humans) easier to review
patch:
#include
#include
-enum mc13xxx_id {
- MC13XXX_ID_MC13783,
- MC13XXX_ID_MC13892,
- MC13XXX_ID_INVALID,
-};
-
#define MC13XXX_NUMREGS 0x3f
+struct mc13xxx;
+
+struct mc13xxx_variant {
+ const char *name;
+ void (*print_revision)(struct mc13xxx *mc13xxx, u32 revision);
+};
+
+extern struct mc13xxx_variant
+ mc13xxx_variant_mc13783,
+ mc13xxx_variant_mc13892;
+
struct mc13xxx {
struct regmap *regmap;
...
But as this touches 17 lines compared to only 15 using the way git
choosed to represent patch 6, git used the smaller representation. (I'm
not sure this is the correct reason, but at least it sounds sensible.)
Usually this metric is sane, but here it's not. I don't know if you can
do anything about it? E.g. take the number of +, - and context blocks
into account. Then it would be 5 for the patch above vs. 7 for the
way git did it.
Or weight a context line containing
#define MC13XXX_NUMREGS 0x3f
more than two lines one of which is empty and the other only contains a
}?
> - Patch 4 should come last, ie after "add support for mc34708"
Yeah, but it doesn't break bisectibility, and as the rtc patches go in via a
different tree (in fact akpm already took them) it doesn't matter much.
Best regards and thanks for your feedback
Uwe
--
Pengutronix e.K. | Uwe Kleine-König|
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
