pull-all and push-all do squash if option is set#1
Open
sleicht wants to merge 2 commits intohelmo:subtree-updatesfrom
sleicht:subtree-squash-all
Open
pull-all and push-all do squash if option is set#1sleicht wants to merge 2 commits intohelmo:subtree-updatesfrom sleicht:subtree-squash-all
sleicht wants to merge 2 commits intohelmo:subtree-updatesfrom
sleicht:subtree-squash-all
Conversation
These include: * a .gittrees file with meta data * new sub commands (push-all, pull-all, from-submodule, prune, diff, list) * Documentation updates Contributers from the git log on https://github.com/helmo/git-subtree bibendi <bibendi@bk.ru> Carl Fürstenberg <carl@blockmastersecurity.com> Francesco Delfino <delfinof@gmail.com> helmo <rink@initfour.nl> Herman van Rink <rink@initfour.nl> James Roper <jroper@vz.net> John Yani <vanuan@gmail.com> Jonathan 'Wolf' Rentzsch <jwr.git@redshed.net> mhart <michael@adslot.com> mhoffman <matt.hoffman@quantumretail.com> Nate Jones <nate@endot.org> Paul Cartwright <paul.cartwright@ziilabs.com> Peter Jaros <pjaros@pivotallabs.com> rentzsch <jwr.git@redshed.net> sun <sun@unleashedmind.com> Thomas Van Doren <thomas@cozi.com> Vanya at notebook <vanuan@gmail.com>
Owner
|
It's been awhile since I've played with this... but isn't squash irrelevant for push? |
Author
|
You are probably right. But as --squash is also an option in the 'default' subtree push command I added it to the push-all: From the git subtree usage info: But I'm not dependent on this. So if you don't want it I could remove it from push-all. |
NexZhu
pushed a commit
to daotl/git-subtree
that referenced
this pull request
Jul 7, 2022
[DOC] Mention `git --exec-path` in README.
NexZhu
pushed a commit
to daotl/git-subtree
that referenced
this pull request
Oct 13, 2022
Since commit fcc07e9 (is_promisor_object(): free tree buffer after parsing, 2021-04-13), we'll always free the buffers attached to a "struct tree" after searching them for promisor links. But there's an important case where we don't want to do so: if somebody else is already using the tree! This can happen during a "rev-list --missing=allow-promisor" traversal in a partial clone that is missing one or more trees or blobs. The backtrace for the free looks like this: helmo#1 free_tree_buffer tree.c:147 helmo#2 add_promisor_object packfile.c:2250 helmo#3 for_each_object_in_pack packfile.c:2190 #4 for_each_packed_object packfile.c:2215 #5 is_promisor_object packfile.c:2272 git#6 finish_object__ma builtin/rev-list.c:245 #7 finish_object builtin/rev-list.c:261 git#8 show_object builtin/rev-list.c:274 git#9 process_blob list-objects.c:63 git#10 process_tree_contents list-objects.c:145 git#11 process_tree list-objects.c:201 git#12 traverse_trees_and_blobs list-objects.c:344 [...] We're in the middle of walking through the entries of a tree object via process_tree_contents(). We see a blob (or it could even be another tree entry) that we don't have, so we call is_promisor_object() to check it. That function loops over all of the objects in the promisor packfile, including the tree we're currently walking. When we're done with it there, we free the tree buffer. But as we return to the walk in process_tree_contents(), it's still holding on to a pointer to that buffer, via its tree_desc iterator, and it accesses the freed memory. Even a trivial use of "--missing=allow-promisor" triggers this problem, as the included test demonstrates (it's just a vanilla --blob:none clone). We can detect this case by only freeing the tree buffer if it was allocated on our behalf. This is a little tricky since that happens inside parse_object(), and it doesn't tell us whether the object was already parsed, or whether it allocated the buffer itself. But by checking for an already-parsed tree beforehand, we can distinguish the two cases. That feels a little hacky, and does incur an extra lookup in the object-hash table. But that cost is fairly minimal compared to actually loading objects (and since we're iterating the whole pack here, we're likely to be loading most objects, rather than reusing cached results). It may also be a good direction for this function in general, as there are other possible optimizations that rely on doing some analysis before parsing: - we could detect blobs and avoid reading their contents; they can't link to other objects, but parse_object() doesn't know that we don't care about checking their hashes. - we could avoid allocating object structs entirely for most objects (since we really only need them in the oidset), which would save some memory. - promisor commits could use the commit-graph rather than loading the object from disk This commit doesn't do any of those optimizations, but I think it argues that this direction is reasonable, rather than relying on parse_object() and trying to teach it to give us more information about whether it parsed. The included test fails reliably under SANITIZE=address just when running "rev-list --missing=allow-promisor". Checking the output isn't strictly necessary to detect the bug, but it seems like a reasonable addition given the general lack of coverage for "allow-promisor" in the test suite. Reported-by: Andrew Olsen <andrew.olsen@koordinates.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
NexZhu
pushed a commit
to daotl/git-subtree
that referenced
this pull request
Oct 13, 2022
Fix a memory leak occuring in case of pathspec copy in preload_index.
Direct leak of 8 byte(s) in 8 object(s) allocated from:
#0 0x7f0a353ead47 in __interceptor_malloc (/usr/lib/gcc/x86_64-pc-linux-gnu/11.3.0/libasan.so.6+0xb5d47)
helmo#1 0x55750995e840 in do_xmalloc /home/anthony/src/c/git/wrapper.c:51
helmo#2 0x55750995e840 in xmalloc /home/anthony/src/c/git/wrapper.c:72
helmo#3 0x55750970f824 in copy_pathspec /home/anthony/src/c/git/pathspec.c:684
#4 0x557509717278 in preload_index /home/anthony/src/c/git/preload-index.c:135
#5 0x55750975f21e in refresh_index /home/anthony/src/c/git/read-cache.c:1633
git#6 0x55750915b926 in cmd_status builtin/commit.c:1547
#7 0x5575090e1680 in run_builtin /home/anthony/src/c/git/git.c:466
git#8 0x5575090e1680 in handle_builtin /home/anthony/src/c/git/git.c:720
git#9 0x5575090e284a in run_argv /home/anthony/src/c/git/git.c:787
git#10 0x5575090e284a in cmd_main /home/anthony/src/c/git/git.c:920
git#11 0x5575090dbf82 in main /home/anthony/src/c/git/common-main.c:56
git#12 0x7f0a348230ab (/lib64/libc.so.6+0x290ab)
Signed-off-by: Anthony Delannoy <anthony.2lannoy@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
NexZhu
pushed a commit
to daotl/git-subtree
that referenced
this pull request
Oct 13, 2022
Signed-off-by: Emir SARI <emir_sari@icloud.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
I needed the ability to set the squash option on the pull-all so only changed remote repositories to generate (squashed) commits.