Re: [RFC] Rebasing merges: a jorney to the ultimate solution (Road Clear)
Hi Jake, Jacob Kellerwrites: > On Fri, Feb 16, 2018 at 5:08 AM, Sergey Organov wrote: >> Hi, >> >> By accepting the challenges raised in recent discussion of advanced >> support for history rebasing and editing in Git, I hopefully figured out >> a clean and elegant method of rebasing merges that I think is "The Right >> Way (TM)" to perform this so far troublesome operation. ["(TM)" here has >> second meaning: a "Trivial Merge (TM)", see below.] >> >> Let me begin by outlining the method in git terms, and special thanks >> here must go to "Johannes Sixt" for his original bright >> idea to use "cherry-pick -m1" to rebase merge commits. >> >> End of preface -- here we go. >> > > I hope to take a more detailed look at this, also possibly with some > attempts at re-creating the process by hand to see it in practice. Thank you for your interest and for the review, and yes, some testing is what the idea desperately needs. Unfortunately I don't have much time for it right now, nor am I fluent enough in git internals to actually make even a raw prototype really soon, sorry. Anybody who is interested is very welcome to volunteer! [...] > > This might be a bit tricky for a user to understand what the process > is, especially if they don't understand how it's creating special U1' > and U2' commits. However, it *is* the cleanest method I've either seen > or thought of for presenting the conflict to the user. > [...] >> - it appears shiny to the point that it will likely be able to handle >> even darkest evil merges nicely, no special treatment required. >> > > Yep, and I like that it has a pretty reasonable way of presenting > conflicts for resolution. It may be a bit tricky to explain the use of > the intermittent commits U1' and U2' though. Yeah, I see how all this sends somewhat unique challenges to the implementation to get user interaction in case of conflicts right, even though all the basic concepts are old buddies and should be familiar to the user. That said, the recursive merge strategy comes to mind, where creating virtual merge base may itself cause conflicts, so something similar enough is likely to already exist. -- Sergey
Re: [PATCH] sq_dequote: fix extra consumption of source string
On Wed, Feb 14, 2018 at 12:41 AM, Jeff Kingwrote: > This fixes a (probably harmless) parsing problem in > sq_dequote_step(), in which we parse some bogus input > incorrectly rather than complaining that it's bogus. > [...] LGTM. Thanks for taking care of this. Michael
Re: [PATCH v3 22/23] cat-file: tests for new atoms added
On 18/02/18 22:55, Ramsay Jones wrote: > > > On 16/02/18 14:55, Adam Dinwoodie wrote: >> On 12 February 2018 at 08:08, Olga Telezhnaya wrote: >>> Add some tests for new formatting atoms from ref-filter. >>> Some of new atoms are supported automatically, >>> some of them are expanded into empty string >>> (because they are useless for some types of objects), >>> some of them could be supported later in other patches. >> >> This commit appears to be introducing failures in t1006 on Cygwin. >> Specifically, tests 15, 36, 58 and 89, all titled "Check %(refname) >> gives empty output", are failing on the pu branch at 21937aad4, and >> git bisect identifies this commit, 3c1571744 ("cat-file: tests for new >> atoms added", 2018-02-12), as the culprit. > > Hi Adam, Olga, > > Sparse has been complaining about this 'ot/cat-batch-format' branch for > a while, so I had already noted (apart from a symbol which should be > marked as static) something that looked somewhat off - namely, the on > stack initialisation of a 'struct ref_array_item' (builtin/cat-file.c, > line 246, in function batch_object_write()). > > In particular, the 'struct ref_array_item' ends with a [FLEX_ARRAY] field > for the refname, so it clearly isn't meant to be declared on the stack. > The 'ref-filter' code uses a 'constructor' function called 'new_ref_array_\ > item() which, among others, takes a 'refname' parameter with which to > initialise the refname FLEX_ARRAY field. > > So, on Linux, if you build with SANITIZE=address and then run that test: BTW, I forgot to mention that, if you run that test without -i, then more than tests #15,36,58 and 89 will fail. In addition, tests #19-20, #40-41, #62-63 and #93-94 failed - I did not investigate these failures at all. ATB, Ramsay Jones
Re: [PATCH v3 22/23] cat-file: tests for new atoms added
On 16/02/18 14:55, Adam Dinwoodie wrote: > On 12 February 2018 at 08:08, Olga Telezhnaya wrote: >> Add some tests for new formatting atoms from ref-filter. >> Some of new atoms are supported automatically, >> some of them are expanded into empty string >> (because they are useless for some types of objects), >> some of them could be supported later in other patches. > > This commit appears to be introducing failures in t1006 on Cygwin. > Specifically, tests 15, 36, 58 and 89, all titled "Check %(refname) > gives empty output", are failing on the pu branch at 21937aad4, and > git bisect identifies this commit, 3c1571744 ("cat-file: tests for new > atoms added", 2018-02-12), as the culprit. Hi Adam, Olga, Sparse has been complaining about this 'ot/cat-batch-format' branch for a while, so I had already noted (apart from a symbol which should be marked as static) something that looked somewhat off - namely, the on stack initialisation of a 'struct ref_array_item' (builtin/cat-file.c, line 246, in function batch_object_write()). In particular, the 'struct ref_array_item' ends with a [FLEX_ARRAY] field for the refname, so it clearly isn't meant to be declared on the stack. The 'ref-filter' code uses a 'constructor' function called 'new_ref_array_\ item() which, among others, takes a 'refname' parameter with which to initialise the refname FLEX_ARRAY field. So, on Linux, if you build with SANITIZE=address and then run that test: $ ./t1006-cat-file.sh -i -v Initialized empty Git repository in /home/ramsay/git/t/trash directory.t1006-cat-file/.git/ expecting success: echo_without_newline "$hello_content" > hello && git update-index --add hello ok 1 - setup ... = ==12556==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7fff132f04a8 at pc 0x7f1c1b3ca20b bp 0x7fff132f00f0 sp 0x7fff132ef898 READ of size 4 at 0x7fff132f04a8 thread T0 #0 0x7f1c1b3ca20a in __interceptor_strlen (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x7020a) #1 0x6798cc in strbuf_addstr /home/ramsay/git/strbuf.h:273 #2 0x6798cc in quote_formatting /home/ramsay/git/ref-filter.c:496 #3 0x68325d in format_ref_array_item /home/ramsay/git/ref-filter.c:2238 #4 0x68358a in show_ref_array_item /home/ramsay/git/ref-filter.c:2262 #5 0x429866 in batch_object_write builtin/cat-file.c:252 #6 0x42b095 in batch_one_object builtin/cat-file.c:306 #7 0x42b095 in batch_objects builtin/cat-file.c:407 #8 0x42b095 in cmd_cat_file builtin/cat-file.c:528 #9 0x40d3cb in run_builtin /home/ramsay/git/git.c:346 #10 0x40d3cb in handle_builtin /home/ramsay/git/git.c:556 #11 0x40f8ae in run_argv /home/ramsay/git/git.c:608 #12 0x40f8ae in cmd_main /home/ramsay/git/git.c:685 #13 0x40b667 in main /home/ramsay/git/common-main.c:43 #14 0x7f1c1ab7982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #15 0x40ce38 in _start (/home/ramsay/git/git+0x40ce38) Address 0x7fff132f04a8 is located in stack of thread T0 at offset 328 in frame #0 0x4296ff in batch_object_write builtin/cat-file.c:245 This frame has 4 object(s): [32, 36) 'type' [96, 104) 'contents' [160, 168) 'size' [224, 328) 'item' <== Memory access at offset 328 overflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism or swapcontext (longjmp and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow ??:0 __interceptor_strlen Shadow bytes around the buggy address: 0x100062656040: 00 00 f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 0x100062656050: 00 00 00 00 f1 f1 f1 f1 00 00 00 f4 f3 f3 f3 f3 0x100062656060: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x100062656070: 04 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 0x100062656080: 00 f4 f4 f4 f2 f2 f2 f2 00 00 00 00 00 00 00 00 =>0x100062656090: 00 00 00 00 00[f4]f4 f4 f3 f3 f3 f3 00 00 00 00 0x1000626560a0: 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 0x1000626560b0: 04 f4 f4 f4 f2 f2 f2 f2 04 f4 f4 f4 f2 f2 f2 f2 0x1000626560c0: 04 f4 f4 f4 f2 f2 f2 f2 00 f4 f4 f4 f2 f2 f2 f2 0x1000626560d0: 00 f4 f4 f4 f2 f2 f2 f2 00 00 f4 f4 f2 f2 f2 f2 0x1000626560e0: 00 00 00 f4 f2 f2 f2 f2 00 00 00 f4 f2 f2 f2 f2 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array
Draft of Git Rev News edition 36
Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-36.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and sending a pull request, or by commenting on this GitHub issue: https://github.com/git/git.github.io/issues/274 You can also reply to this email. In general all kinds of contribution, for example proofreading, suggestions for articles or links, help on the issues in GitHub, and so on, are very much appreciated. I tried to cc everyone who appears in this edition, but maybe I missed some people, sorry about that. Jakub, Markus, Gabriel and me plan to publish this edition on Wednesday February 21st. Thanks, Christian.
GSoC 2018: Git has been accepted as a mentor organization!
Hi, Just a quick message to let everyone know that Git has been accepted as a mentor organization for the Google Summer of Code 2018. If anyone wants to mentor or co-mentor, that is still possible. Just let us know so that we can invite you to register on the GSoC web site. Dscho, I just sent you an invite as a mentor, as I think you said you are ok to mentor. Best, Christian.