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 vers
,
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/
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 ex
, 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
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.
---
Documentati
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 solut
> 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
It would help especially when the commit message was written badly.
Or it might be possible to customize just like "git log --format"?
Thanks
> 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-
nd `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
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
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,
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
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
flog 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 bel
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 i
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
p
17 matches
Mail list logo
