Git 2.19 Segmentation fault 11 on macOS
I just updated to 2.19 via Homebrew, git range-diff seems cool, but I
only got a Segmentation fault: 11
$ git version; git range-diff origin/master HEAD@{2} HEAD
git version 2.19.0
Segmentation fault: 11
Both origin/master and my local branch each got two new commits of their own,
please correct me if this is not the expected way to use git range-diff.
FYI, I've created a sample repo here:
https://github.com/ryenus/range-diff-segfault/
Re: Git 2.19 Segmentation fault 11 on macOS
On Tue, 11 Sep 2018 at 23:49, Thomas Gummerer wrote:
>
> Hi,
>
> thanks for your bug report!
>
> On 09/11, ryenus wrote:
> > I just updated to 2.19 via Homebrew, git range-diff seems cool, but I
> > only got a Segmentation fault: 11
> >
> > $ git version; git range-diff origin/master HEAD@{2} HEAD
>
> Unfortunately the HEAD@{2} syntax needs your reflog, which is not
> available when just cloning the repository (the reflog is only local
> and not pushed to the remote repository). Would it be possible to
> create a short script to create the repository where you're
> experiencing the behaviour, or replacing 'origin/master', 'HEAD@{2}'
> and 'HEAD' with the actual commit ids?
so `HEAD~2` should be used instead of `HEAD@{2}`, right?
I just tried the following and got same error:
$ git range-diff master patch~2 patch
Segmentation fault: 11
>
> I tried with various values, but unfortunately failed to reproduce
> this so far (although admittedly I tried it on linux, not Mac OS).
>
> > git version 2.19.0
> > Segmentation fault: 11
> >
> > Both origin/master and my local branch each got two new commits of their
> > own,
> > please correct me if this is not the expected way to use git range-diff.
> >
> > FYI, I've created a sample repo here:
> > https://github.com/ryenus/range-diff-segfault/
[PATCH] fix revisions doc about quoting for ':/' notation
To make sure the `` in `:/` is seen as one search string,
one should quote/escape `` properly.
Especially, the example given in the manual `:/fix nasty bug` does not
work because of missing quotes. The examples are now corrected, and a
note about quoting/escaping is added as well.
---
Documentation/revisions.txt | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt
index 61277469c..fdfdde0ad 100644
--- a/Documentation/revisions.txt
+++ b/Documentation/revisions.txt
@@ -169,14 +169,14 @@ existing tag object.
and dereference the tag recursively until a non-tag object is
found.
-'{caret}{/}', e.g. 'HEAD^{/fix nasty bug}'::
+'{caret}{/}', e.g. 'HEAD^{/"fix nasty bug"}'::
A suffix '{caret}' to a revision parameter, followed by a brace
pair that contains a text led by a slash,
is the same as the ':/fix nasty bug' syntax below except that
it returns the youngest matching commit which is reachable from
the '' before '{caret}'.
-':/', e.g. ':/fix nasty bug'::
+':/', e.g. ':/"fix nasty bug"'::
A colon, followed by a slash, followed by a text, names
a commit whose commit message matches the specified regular expression.
This name returns the youngest matching commit which is
@@ -185,7 +185,8 @@ existing tag object.
e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what
is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a
literal '!' character, followed by 'foo'. Any other sequence beginning with
- ':/!' is reserved for now.
+ ':/!' is reserved for now. And make sure to quote/escape for the text to be
+ seen as one search string.
':', e.g. 'HEAD:README', ':README', 'master:./README'::
A suffix ':' followed by a path names the blob or tree
--
2.14.1
[PATCH v2] update revisions doc for quoting in ':/' notation
To make sure the `` in `:/` is seen as one search string, one should quote/escape `` properly. Especially, the example given in the manual `:/fix nasty bug` does not work because of missing quotes when used in shell. A note about quoting/escaping is added along with a working example, however, the original example is left-as-is to be consistent with other examples. Signed-off-by: ryenus --- Documentation/revisions.txt | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index 61277469c..d2862d55d 100644 --- a/Documentation/revisions.txt +++ b/Documentation/revisions.txt @@ -185,7 +185,9 @@ existing tag object. e.g. ':/^foo'. The special sequence ':/!' is reserved for modifiers to what is matched. ':/!-foo' performs a negative match, while ':/!!foo' matches a literal '!' character, followed by 'foo'. Any other sequence beginning with - ':/!' is reserved for now. + ':/!' is reserved for now. And make sure to quote/escape for the text to be + interpreted as the expected search string/pattern, e.g., for a commit whose + message matches a literal \'`$`', use `git show :/\\\$` or `git show ':/\$'`. ':', e.g. 'HEAD:README', ':README', 'master:./README':: A suffix ':' followed by a path names the blob or tree -- 2.14.1
Re: [PATCH] fix revisions doc about quoting for ':/' notation
On 17 August 2017 at 05:57, Junio C Hamano wrote:
> Andreas Heiduk writes:
>
>> Am 16.08.2017 um 05:21 schrieb ryenus:
>>> To make sure the `` in `:/` is seen as one search string,
>>> one should quote/escape `` properly.
>>>
>>> Especially, the example given in the manual `:/fix nasty bug` does not
>>> work because of missing quotes. The examples are now corrected, and a
>>> note about quoting/escaping is added as well.
>>
>> Right now the documentation describes the syntax as git sees the
>> parameters. This is agnostic of the shell or other UI with their
>> different quoting rules. For example users of fish must quote
>> `rev@{2}`. A GUI might require no quoting at all. In that case `:/"fix
>> nasty bugs"` would be given to git verbatim and hence not find the revision.
>
> These are all good points that I didn't consider when responding.
>
Makes sense for me, too. I've just sent a v2 patch, which leaves the original
example as-is, meanwhile added a example inside the explanation.
Thanks!
[PATCH] make rebase respect core.hooksPath if set
when looking for pre-rebase and post-rewrite hooks, git-rebase
only looks for hooks dir using `git rev-parse --git-path hooks`,
which didn't consider the path overridden by core.hooksPath.
Signed-off-by: ryenus
---
git-rebase--interactive.sh | 14 +-
git-rebase--merge.sh | 4 +++-
git-rebase.sh | 7 +--
3 files changed, 17 insertions(+), 8 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index e2da524..e8af70d 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -724,11 +724,15 @@ Commit or stash your changes, and then run
git notes copy --for-rewrite=rebase < "$rewritten_list" ||
true # we don't care if this copying failed
} &&
- hook="$(git rev-parse --git-path hooks/post-rewrite)"
- if test -x "$hook" && test -s "$rewritten_list"; then
- "$hook" rebase < "$rewritten_list"
- true # we don't care if this hook failed
- fi &&
+ {
+ hooks_path=$(git config --get core.hooksPath)
+ hooks_path="${hooks_path:-$(git rev-parse --git-path hooks)}"
+ hook="${hooks_path}/post-rewrite"
+ if test -x "$hook" && test -s "$rewritten_list"; then
+ "$hook" rebase < "$rewritten_list"
+ true # we don't care if this hook failed
+ fi
+ } &&
warn "$(eval_gettext "Successfully rebased and updated \$head_name.")"
return 1 # not failure; just to break the do_rest loop
diff --git a/git-rebase--merge.sh b/git-rebase--merge.sh
index 06a4723..df5073e 100644
--- a/git-rebase--merge.sh
+++ b/git-rebase--merge.sh
@@ -96,7 +96,9 @@ finish_rb_merge () {
if test -s "$state_dir"/rewritten
then
git notes copy --for-rewrite=rebase <"$state_dir"/rewritten
- hook="$(git rev-parse --git-path hooks/post-rewrite)"
+ hooks_path=$(git config --get core.hooksPath)
+ hooks_path="${hooks_path:-$(git rev-parse --git-path hooks)}"
+ hook="${hooks_path}/post-rewrite"
test -x "$hook" && "$hook" rebase <"$state_dir"/rewritten
fi
say All done.
diff --git a/git-rebase.sh b/git-rebase.sh
index 04f6e44..c9ba747 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -203,10 +203,13 @@ run_specific_rebase () {
}
run_pre_rebase_hook () {
+ hooks_path=$(git config --get core.hooksPath)
+ hooks_path="${hooks_path:-$(git rev-parse --git-path hooks)}"
+ hook="${hooks_path}/pre-rebase"
if test -z "$ok_to_skip_pre_rebase" &&
- test -x "$(git rev-parse --git-path hooks/pre-rebase)"
+ test -x "$hook"
then
- "$(git rev-parse --git-path hooks/pre-rebase)" ${1+"$@"} ||
+ "$hook" ${1+"$@"} ||
die "$(gettext "The pre-rebase hook refused to rebase.")"
fi
}
--
2.9.3
--
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] make rebase respect core.hooksPath if set
Patch attached. It seems gmail ruined the white spaces. Not sure how to stop gmail from doing that. Sorry for me, and for Gmail. 0001-make-rebase-respect-core.hooksPath-if-set.patch Description: Binary data
Re: [PATCH] make rebase respect core.hooksPath if set
On 15 August 2016 at 20:24, Johannes Schindelin wrote: > Would it not be more appropriate to teach --git-path hooks to respect the > core.hooksPath variable? This would be in line with --git-path objects > respecting the GIT_OBJECT_DIRECTORY environment variable. Indeed, I've thought about that, too, due to the bad smell of duplication, but not sure if that's the right position among all the abstraction layers. Also it's more convenient to come up with a shell based fix on local installation. Thanks -- 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
Notation for current branch?
I wonder if there's an easy to use notation to refer to the current branch? which is expected be friendly to scripting. For HEAD, there's @, which is short and concise. But for the current branch, it seems one has to either use a not so friendly plumbing command, or grep/parse the output of `git branch`, since the latter doesn't even has any option to only print the plain name of the current branch, or maybe an option can be added to `git branch`? Thoughts? -- 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: Notation for current branch?
On 30 August 2016 at 03:49, Junio C Hamano wrote: > Jacob Keller writes: > >>> What's wrong with simply using 'HEAD' for scripting? >> >> When you want to display the current branch to the user, e.g. when >> scripting a shell prompt or similar use > > Wait. Even if a hypothetical version of Git understood @@ as "the > current branch", how would you use that notation, instead of HEAD, > to decide what to "display the current branch to the user"? > > You obviously will not be doing > > echo @@ > > You would be doing something around "git symbolic-ref" at the very > least, and wouldn't you be feeding HEAD to that symbolic-ref anyway > while doing so? > For now the best use case I can think of is with git-reflog, e.g., the meaning of `git reflog HEAD` and `git reflog feature-branch` are quite different, even if I'm currently on the feature-branch, especially when I want to track the rebase histories (if any). If there's a notation for the current branch then I don't have to find the name of the current branch, then copy/paste it. However, in this case, maybe git-reflog can have a `-b` option to show the reflog of the current branch (if on any)? - ryenus
Re: Notation for current branch?
> Jacob Keller writes:
> "git symbolic-ref" seems like the right thing if you need to obtain
> the current branch name, and there's no reason to not just use HEAD
> there.
Really? Any reason why `git rev-parse --abbrev-ref '@{-1}'` works,
but not `git symbolic-ref '@{-1}'`, or even `git symbolic-ref @`?
BTW, possible to make the curly brances optional in `@{n}`, `@{-n}`,
and the alike? coz they require quoting/escaping, and more typing :(
[git rebase -i] show time and author besides commit hash and message?
It would help especially when the commit message was written badly. Or it might be possible to customize just like "git log --format"? Thanks
Re: [git rebase -i] show time and author besides commit hash and message?
> It is possible to change the format globally via config option > rebase.instructionFormat: > > $ git config rebase.instructionFormat "%an (%ad): %s" > > The format is the same as for 'git log'. This one outputs author > name, date, and the first line of commit message. Thanks for the prompt response! I tried immediately, it works just as you have pointed out. Just it seems coloring is not supported? probably because we're inside an editor? > This option is supported since Git 2.6. I missed it, what about including a note about this option as part of the comment in git rebase -i? since that's the place where people would most likely think about it? > Or are you interested in a command-line option that can change > the format on per-invocation basis? I think there isn't one. > It can be interesting to add it, but I don't think it has much > utility... Not much, for git log I'd rather setup an alias "git la", than having to remember various fields, colors, padding options to have a nice output.
enhance git-add to avoid password being staged or committed?
This can be an optional feature, once enabled, git-add would check the hunk(s) to stage for sensitive information, such as passwords, secret tokens, then ask the user for confirmation. The implementation for secret detection could be regexp pattern(s), and/or (trusted?) commands Alternative solutions might be hooks during commit, push or recieve, but it should be the best to do this in the first place during git-add. The context of this is the following HN discussion about passwords on GitHub: https://news.ycombinator.com/item?id=13650818
[feature request] find git commit log before rebase
Assuming I have branches master (m), and a side branch (b), with a history tree like below: m0 --- m1 -- m2 -- m3 -- m4 --- master (m) \ / \ b1 -- b2 b3 -- b4 -- branch (b) (HEAD) | (tag:POINT_BEFORE_REBASE) The history of branch b is can be described as: 1. branch b is forked at point of m1 2. branch b is merged to master into m3, 3. branch b then is rebased (fast-forward) from b2 to m4 4. then branch b started its new life as b3 b4 after rebase With the following command: I can find b3 and b4 since last fork-point git log --oneline $(git merge-base --fork-point master)..b But how to find out commits b1 b2, given the fact that b2 is the point before rebase? I understand it can be achieved via: git log --oneline m2..b2 That's because I know b2 is the point before rebase, and m2 is another child of the subsequent merge commit m3 I wonder how to do this with an simple (enough) command without me looking through the history and find b2 and m2 manually? Thanks! -- 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] find git commit log before rebase
Indeed, specifying the branch name does the trick and this works with `git reflog` and/or `git log --walk-reflogs` Thank you very much! On 27 May 2016 at 01:58, Sebastian Staudt wrote: > Hi. > > I think what you want is `git reflog` (http://git-scm.com/man/reflog). > > git reflog b > > Will tell you the commits b pointed to in the past. > > Best regards, > Sebastian > ryenus schrieb am Do., 26. Mai 2016 um 19:03: >> >> Assuming I have branches master (m), and a side branch (b), with a >> history tree like below: >> >> m0 --- m1 -- m2 -- m3 -- m4 --- master (m) >> \ / \ >> b1 -- b2 b3 -- b4 -- branch (b) (HEAD) >> | >> (tag:POINT_BEFORE_REBASE) >> >> The history of branch b is can be described as: >> >> 1. branch b is forked at point of m1 >> 2. branch b is merged to master into m3, >> 3. branch b then is rebased (fast-forward) from b2 to m4 >> 4. then branch b started its new life as b3 b4 after rebase >> >> With the following command: I can find b3 and b4 since last fork-point >> >> git log --oneline $(git merge-base --fork-point master)..b >> >> But how to find out commits b1 b2, given the fact that b2 is the point >> before rebase? >> >> I understand it can be achieved via: >> >> git log --oneline m2..b2 >> >> That's because I know b2 is the point before rebase, >> and m2 is another child of the subsequent merge commit m3 >> >> I wonder how to do this with an simple (enough) command without me >> looking through the history and find b2 and m2 manually? >> >> Thanks! >> -- >> 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 -- 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 merge/rebase ref -P ref
The inverted meaning of {ours,theirs} for rebase could be very
confusing to some, especially to new uses, for me every time I
merge/rebase I need to think about it to make sure I've made it right.
What about making it more intuitive?
We can and a new option (like '-P') for people to specify the
preferred branch/ref by it's name.
E.g. assume I have two branches, namely 'dev' and 'exp', and I prefer
the changeset on the 'dev' branch when I merge or rebase, so that I
can do it with
# using merge
git checkout dev
git merge exp -P dev
OR
# using rebase
git checkout exp
git rebase dev -P dev
--
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
