git-prompt has various describe styles, among them "describe" (by
annotated tags) and "default" (by exact match with any tag).
Add a mode "tag" that describes by any tag, annotated or not.
Signed-off-by: Michael J Gruber
---
contrib/completion/git-prompt
Junio C Hamano venit, vidit, dixit 15.03.2017 20:25:
> Michael J Gruber writes:
>
>> git-prompt has various describe styles, among them "describe" (by
>> annotated tags) and "default" (by exact match with any tag).
>>
>> Add a mode "tag&quo
> hops, without taking the "taggerdate" into account. As we are
> taking over the "taggerdate" field to store the committer date for
> tips with commits:
>
> (1) keep the original logic when comparing names based on two refs
> both of which are from refs/tags/;
>
> (2) favoring a name bas
Junio C Hamano venit, vidit, dixit 15.03.2017 20:21:
> Michael J Gruber writes:
>
>> `git describe --contains` calls into `git name-rev` which does not have
>> any searching to do and thus does not display any debug information.
>>
>> Say so in the documentat
Signed-off-by: Michael J Gruber
---
Just a minor thing. I'm wondering about lower/upper case
at the beginning of the line, though. Do we have a rule for de.po?
po/de.po | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/po/de.po b/po/de.po
index e9c86f5488..f8215945e7 1
Signed-off-by: Michael J Gruber
---
Junio: this is just a l10n-followup to the previous code patch ;)
po/de.po | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/po/de.po b/po/de.po
index e9c86f5488..913db393dc 100644
--- a/po/de.po
+++ b/po/de.po
@@ -7530,7
git describe --debug localizes all debug messages but not the terms
head, lightweight, annotated that it outputs for the candidates.
Localize them, too.
Also, increase the width of that field to create room for the translated
terms.
Signed-off-by: Michael J Gruber
---
Ralf: this is just the
Junio C Hamano venit, vidit, dixit 21.03.2017 16:48:
> Duy Nguyen writes:
>
>> On Tue, Mar 21, 2017 at 1:50 AM, Jonathan Nieder wrote:
>>> Junio C Hamano wrote:
Stefan Beller writes:
>>>
> While it may be true that you can have bare worktrees; I would question
> why anyone wants to
Map both old addresses to the new, hopefully more permanent one.
Signed-off-by: Michael J Gruber
Signed-off-by: Michael J Gruber
---
.mailmap | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/.mailmap b/.mailmap
index e06526a493..ab85e0d16d 100644
--- a/.mailmap
+++ b
Stefan Beller venit, vidit, dixit 22.03.2017 19:59:
> On Wed, Mar 22, 2017 at 11:56 AM, Junio C Hamano wrote:
>>> So we'd want to be able to say:
>>> "get a tarball including all submodules except the superproject"
>>> (This would produce the "optional language pack tarball")
>>
>> You do not
Joan Aguilar venit, vidit, dixit 24.03.2017 11:27:
> Hello there
>
> this is the first bug report of my life and I am not a native English
> speaker so, first of all, I would like to apologize for my English
> skills and the report itself (if it is not precise enough).
>
> I have already read thi
git describe --debug localizes all debug messages but not the terms
head, lightweight, annotated that it outputs for the candidates.
Localize them, too.
Signed-off-by: Michael J Gruber
---
builtin/describe.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a
Signed-off-by: Michael J Gruber
---
po/de.po | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/po/de.po b/po/de.po
index e9c86f5488..913db393dc 100644
--- a/po/de.po
+++ b/po/de.po
@@ -7530,7 +7530,19 @@ msgstr "git describe [] [...]"
msgid &qu
v2 computes the width for the localized output dynamically.
In fact, it might overcalculated a bit depending on the encoding,
but this does not do any harm.
Michael J Gruber (2):
describe: localize debug output fully
l10n: de: translate describe debug terms
builtin/describe.c | 15
ut-off for name-rev kicks in way more often than the candidate
number cut-off of describe, so we do not clutter the output with the
cut-off.
Signed-off-by: Michael J Gruber
---
builtin/describe.c | 2 ++
builtin/name-rev.c | 64 +++---
2 files c
the same (i.e. a name that is based on an
older tag is better, and if two tags of the same age can reach the
commit, the one with fewer number of hops to reach the commit is
better).
Signed-off-by: Junio C Hamano
Signed-off-by: Michael J Gruber
---
builtin/name-rev.c | 16 +---
1
, but still mostly Junio's
Michael J Gruber (1):
name-rev: provide debug output
This replaces the patch which documented that --debug does not work with
--contains :)
builtin/describe.c | 2 +
builtin/name-rev.c | 117 +
t/t4202-l
ng with the logic that this patch happens to
implement. This is done primarily to illustrate the value of
using a separate helper function is_better_name() instead of
open-coding the selection logic in name_rev() function.
Signed-off-by: Michael J Gruber
---
builtin/name-rev.c | 53 +++
Junio C Hamano venit, vidit, dixit 29.03.2017 19:43:
> Junio C Hamano writes:
>
>> The first two applies cleanly to the same base as jc/name-rev that
>> the first two of these patches are meant to replace, but the third
>> one doesn't apply on top. Are you depending on something newer?
>
> Ah,
Jeff King venit, vidit, dixit 21.01.2017 15:20:
> On Wed, Jan 11, 2017 at 10:08:46AM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> Yes, I would think die_errno() is a no-brainer for translation, since
>>> the strerror() will be translated.
>>>
apply.c:die(_("
the same (i.e. a name that is based on an
older tag is better, and if two tags of the same age can reach the
commit, the one with fewer number of hops to reach the commit is
better).
Signed-off-by: Junio C Hamano
Signed-off-by: Michael J Gruber
---
builtin/name-rev.c | 16 +---
1
ng with the logic that this patch happens to
implement. This is done primarily to illustrate the value of
using a separate helper function is_better_name() instead of
open-coding the selection logic in name_rev() function.
Signed-off-by: Michael J Gruber
---
builtin/name-rev.c | 53 +++
describing with tags and use committer date to
tiebreak
Michael J Gruber (2):
name-rev: provide debug output
describe: pass --debug down to name-rev
Documentation/git-name-rev.txt | 5 ++
builtin/describe.c | 2 +
builtin/name-rev.c | 117
cribe" header).
The date cut-off for name-rev kicks in way more often than the candidate
number cut-off of describe, so we do not clutter the output with the
cut-off.
Signed-off-by: Michael J Gruber
---
Documentation/git-name-rev.txt | 5
builtin/name-rev.c
Now that name-rev knows --debug, pass that flag down to name-rev when we
call it for doing describe --contains.
Signed-off-by: Michael J Gruber
---
builtin/describe.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/builtin/describe.c b/builtin/describe.c
index a5cd8c513f..30196793f0
information is shown next to the branch
information. Just like `--branch`, this comes with a config option.
The wording for the in-progress information is taken over from
git-prompt.sh.
Signed-off-by: Michael J Gruber
---
When used with --porcelain, this gives an easy way to amend the
powerline
Am 31. März 2017 18:52:16 MESZ schrieb Junio C Hamano :
>Michael J Gruber writes:
>
>> Currently, `git describe --contains --debug` does not create any
>debug
>> output because it does not pass the flag down to `git name-rev`,
>which
>> does not know that flag.
&g
Junio C Hamano venit, vidit, dixit 31.03.2017 20:33:
> Junio C Hamano writes:
>
>> Michael J Gruber writes:
>>
>>>> The only case that this change may make a difference I can think of
>>>> is when you have a tag object pointed at from outside refs/tags
Duy Nguyen venit, vidit, dixit 25.03.2017 13:07:
> On Fri, Mar 24, 2017 at 12:55 AM, Junio C Hamano wrote:
>> Michael J Gruber writes:
>>
>>> Are we at a point where we can still rename the new feature at least? If
>>> yes, and keeping everything else
SZEDER Gábor venit, vidit, dixit 06.04.2017 16:33:
>> @@ -1779,6 +1780,31 @@ static void wt_shortstatus_print_tracking(struct
>> wt_status *s)
>> }
>>
>> color_fprintf(s->fp, header_color, "]");
>> +
>> + inprogress:
>> +if (!s->show_inprogress)
>> +goto conclude;
>> +
Junio C Hamano venit, vidit, dixit 31.03.2017 20:14:
> Michael J Gruber writes:
>
>> Ordinary (long) status shows information about bisect, revert, am,
>> rebase, cherry-pick in progress, and so does git-prompt.sh. status
>> --short currently shows none of this informa
Jeff King venit, vidit, dixit 11.07.2017 10:24:
> On Tue, Jul 11, 2017 at 10:20:43AM +0200, Torsten Bögershausen wrote:
>
>>> No problem. I actually think it would be interesting if Git could
>>> somehow detect and warn about this situation. But the obvious way to do
>>> that would be to re-run th
to an object but not vice versa,
so the object cannot possible know %(refname), for example. Thus, this is
wrong independent of refs being objects (one day, maybe) or not.
Change the wording to make this clearer (and distinguish it from formats
for the log family).
Signed-off-by: Michael J Gruber
to be
classical english.
Try and straighten that explanation out a bit.
Signed-off-by: Michael J Gruber
---
Documentation/git-for-each-ref.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-for-each-ref.txt
b/Documentation/git-for-each-ref.txt
index
hIpPy venit, vidit, dixit 19.08.2017 00:35:
> While merging if I do certain actions then the merge commit is made
> with the merge message but as a normal (non-merge) commit.
>
> Repro steps:
> - Set GIT_MERGE_AUTOEDIT=yes (set other than "no") in .bashrc
> - Make a merge commit with no conflicts.
the non-squash case) so that it does
not get lost.
Reported-by: hIpPy
Signed-off-by: Michael J Gruber
---
builtin/merge.c | 14 +++---
1 file changed, 11 insertions(+), 3 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index cc57052993..5379b08824 100644
--- a/builtin/merge.c
they're
not the kind of people that I'd like to make angry - at least not
without a good reason.
Michael J Gruber (3):
Documentation/git-merge: explain --continue
merge: split write_merge_state in two
merge: save merge state earlier
Documentation/git-merge.txt | 5 -
bu
the non-squash case) so that it does
not get lost.
Reported-by: hIpPy
Signed-off-by: Michael J Gruber
---
builtin/merge.c | 3 +++
t/t7600-merge.sh | 15 +++
2 files changed, 18 insertions(+)
diff --git a/builtin/merge.c b/builtin/merge.c
index 86f0adde3b..5379b08824 100644
--- a
write_merge_state() writes out the merge heads, mode, and msg. But we
may want to write out heads, mode without the msg. So, split out heads
(+mode) into a separate function write_merge_heads() that is called by
write_merge_state().
No funtional change so far.
Signed-off-by: Michael J Gruber
Currently, 'git merge --continue' is mentioned but not explained.
Explain it.
Signed-off-by: Michael J Gruber
---
Documentation/git-merge.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index
Martin Ågren venit, vidit, dixit 21.08.2017 18:43:
> On 21 August 2017 at 14:53, Michael J Gruber wrote:
>> Currently, 'git merge --continue' is mentioned but not explained.
>>
>> Explain it.
>>
>> Signed-off-by: Michael J Gruber
>> ---
>
Junio C Hamano venit, vidit, dixit 22.08.2017 02:38:
> Michael J Gruber writes:
>
>> static void prepare_to_commit(struct commit_list *remoteheads)
>> {
>> struct strbuf msg = STRBUF_INIT;
>> @@ -767,6 +768,8 @@ static void prepare_to_commit(struc
Currently, 'git merge --continue' is mentioned but not explained.
Explain it.
Signed-off-by: Michael J Gruber
---
Documentation/git-merge.txt | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index
crafted after the in t7502. The test
requires EXECKEEPSPID (thus does not run under MINGW).
Save the merge state earlier (in the non-squash case) so that it does
not get lost. This makes the test pass.
Reported-by: hIpPy
Signed-off-by: Michael J Gruber
---
builtin/merge.c | 2 ++
t/t7600
tree, which also
avoids setting automerge_was_ok (just as in the proper ret==1 case), so
that finish_automerge() is not called.
To ensure that no code change breaks that assumption, safe-guard
prepare_to_commit() by a BUG() statement.
Suggested-by: junio
Signed-off-by: Michael J Gruber
---
builtin
Compared to the 3-item v2:
1/4 == 1/3
2/4 is new as per Junio's suggestion: clarify the call-chain leading up
to prepare_to_commit()
3/4 == 2/3 with amended subject
4/4 is 3/3 rebased, squash-if removed
Michael J Gruber (4):
Documentation/git-merge: explain --continue
merge: clarify
are
interrupted: we write heads-mode-msg now when we used to write
heads-msg-mode.
Signed-off-by: Michael J Gruber
---
builtin/merge.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index dafec80fa9..db3335b3bf 100644
--- a
Nguyễn Thái Ngọc Duy venit, vidit, dixit 23.08.2017 14:36:
> "git gc" when used in multiple worktrees ignore some per-worktree
> references: object references in the index, HEAD and reflog. This
> series fixes it by making the revision walker include these from all
> worktrees by default (and the s
Stefan Beller venit, vidit, dixit 28.08.2017 20:24:
> On Sat, Aug 26, 2017 at 7:47 AM, Kévin Le Gouguec
> wrote:
>> Hi,
>>
>> I've asked this question on the git-users Google Groups list[1], and
>> while the answers there were interesting, I still cannot figure
>> whether my problem comes from an
the remaining constant to the one appropriate for the current
type
Signed-off-by: Michael J Gruber
---
builtin/name-rev.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/name-rev.c b/builtin/name-rev.c
index c41ea7c2a6..598da6c8bc 100644
--- a/builtin/name-rev.c
+++
shawn wilson venit, vidit, dixit 02.09.2017 23:11:
> tl;dr - how do I get git to use gpg2 to sign things?
>
> I'm using gpg2 (so no agent options are configured but an agent is
> running) which is configured w/ a Nitrokey (Pro if it matters):
>
> % git commit -m "Initial."
>
>
Junio C Hamano venit, vidit, dixit 06.09.2017 05:35:
> Michael J Gruber writes:
>
>> Earlier, dddbad728c ("timestamp_t: a new data type for timestamps",
>> 2017-04-26) changed several types to timestamp_t.
>>
>> 5589e87fd8 ("name-rev: change a &
Jeff King venit, vidit, dixit 06.09.2017 15:35:
> On Wed, Sep 06, 2017 at 01:59:31PM +0200, Michael J Gruber wrote:
>
>> BTW, there's more fallout from those name-rev changes: In connection
>> with that other thread about surprising describe results for emacs.git I
>&
t6120 breaks the repo state intentionally in the last tests.
Clean up the breakage afterwards (and before adding more tests).
Signed-off-by: Michael J Gruber
---
t/t6120-describe.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 7c5728ebd5
other subtests the same.
Signed-off-by: Michael J Gruber
---
t/t6120-describe.sh | 31 +++
1 file changed, 31 insertions(+)
diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh
index 1997ccde56..dd6dd9df9b 100755
--- a/t/t6120-describe.sh
+++ b/t/t6120-describe.sh
The lazy prerequisite ULIMIT_STACK_SIZE is used only in t7004 so far.
Move it to test-lib.sh so that it can be used in other tests (which it will
be in a follow-up commit).
Signed-off-by: Michael J Gruber
---
t/t7004-tag.sh | 6 --
t/test-lib.sh | 6 ++
2 files changed, 6 insertions
name-rev is used in a few tests, but tested only in t6120 along with
describe so far.
Add tests for name-rev with --all and --stdin.
Signed-off-by: Michael J Gruber
---
t/t6120-describe.sh | 25 +
1 file changed, 25 insertions(+)
diff --git a/t/t6120-describe.sh b/t
name-rev segfaults for me in emacs.git with the typical 8102 stack size.
The reason is the recursive walk that name-rev uses.
This series adds a test to mark this as known failure, after some
clean-ups.
Michael J Gruber (4):
t7004: move limited stack prereq to test-lib
t6120: test name-rev
Jeff King venit, vidit, dixit 07.09.2017 16:54:
> On Thu, Sep 07, 2017 at 04:02:19PM +0200, Michael J Gruber wrote:
>
>> name-rev segfaults for me in emacs.git with the typical 8102 stack size.
>> The reason is the recursive walk that name-rev uses.
>>
>> This seri
Junio C Hamano venit, vidit, dixit 08.09.2017 03:26:
> Olaf Klischat writes:
>
>> `git diff --help' says:
>>
>> git diff [--options] [--] [...]
>>This form is to view the changes you have in your
>>working tree relative to the named .
>
> That help text is poorly phrased
Ramsay Jones venit, vidit, dixit 09.09.2017 15:13:
> Hi Adam,
>
> I ran the test-suite on the 'pu' branch last night (simply because
> that was what I had built at the time!), which resulted in a PASS,
> but t6120 was showing a 'TODO passed' for #52.
>
> This is a test introduced by Michael's 'mg
Johannes Schindelin venit, vidit, dixit 12.09.2017 15:39:
> Hi Ramsay,
>
> On Sat, 9 Sep 2017, Ramsay Jones wrote:
>
>> I ran the test-suite on the 'pu' branch last night (simply because that
>> was what I had built at the time!), which resulted in a PASS, but t6120
>> was showing a 'TODO passed'
Kaartic Sivaraam venit, vidit, dixit 13.09.2017 15:05:
> It's not good to use the phrase 'do not touch' to convey the information
> that the cut-line should not be modified or removed as it could possibly
> be mis-interpreted by a person who doesn't know that the word 'touch' has
> the meaning of '
Ekelhart Jakob venit, vidit, dixit 13.09.2017 17:07:
> Dear Git,
>
> git merge-base --fork-point "master" not working if master is already newer
> then my current branch.
> Very oddly it seems to work whenever you had the expected commit checked out
> previously - what made it very tricky to det
Jonathan Nieder venit, vidit, dixit 13.09.2017 21:20:
> Ramsay Jones wrote:
>
>> On cygwin (and MinGW), the 'ulimit' built-in bash command does not have
>> the desired effect of limiting the resources of new processes, at least
>> for the stack and file descriptors. However, it always returns succ
og (think pruning, non-ff fetching, fast forwarding etc.),
so filtering by the current contents of the reflog is potentially
harmful, and it does not seem to fulfill any purpose in the original
design.
Remove the filtering and add a test for an out-of-reflog merge base.
Reported-by: Ekelhar
merge-base output, not just its return code.
Signed-off-by: Michael J Gruber
---
t/t6010-merge-base.sh | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/t/t6010-merge-base.sh b/t/t6010-merge-base.sh
index 31db7b5f91..17fffd7998 100755
--- a/t/t6010-merge-base.sh
+++ b/t/t
of refname is found in any case, independent of the state of the
reflog.
Signed-off-by: Michael J Gruber
---
builtin/merge-base.c | 2 +-
t/t6010-merge-base.sh | 8
2 files changed, 9 insertions(+), 1 deletion(-)
diff --git a/builtin/merge-base.c b/builtin/merge-base.c
index
merge-base --fork-point does not quite work as advertised when the
reflog is empty or partial. This series brings it in line with the
documentation and, hopefully, with the original intent.
Michael J Gruber (3):
t6010: test actual test output
merge-base: return fork-point outside reflog
-off-by: Michael J Gruber
---
t/test-lib.sh | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5fbd8d4a90..b8a0b05102 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -994,6 +994,10 @@ case $uname_s in
pwd
msay Jones
Reported-by: Adam Dinwoodie
Reported-by: Johannes Schindelin
Signed-off-by: Michael J Gruber
---
This is independent of my series, but should best go before so that no
ulimit based test is run on CYGWIN and MINGW.
It follows the basic assumption that a tool like ulimit is either
p
Kaartic Sivaraam venit, vidit, dixit 15.09.2017 06:50:
> It's not good to use the phrase 'do not touch' to convey the information
> that the cut-line should not be modified or removed as it could possibly
> be mis-interpreted by a person who doesn't know that the word 'touch' has
> the meaning of '
Jeff King venit, vidit, dixit 14.09.2017 16:34:
> On Thu, Sep 14, 2017 at 03:15:18PM +0200, Michael J Gruber wrote:
>
>> 4f21454b55 ("merge-base: handle --fork-point without reflog",
>> 2016-10-12) introduced a fix for merge-base --fork-point without reflog
>> a
Junio C Hamano venit, vidit, dixit 15.09.2017 04:48:
> Michael J Gruber writes:
>
>> In fact, per documentation "--fork-point" looks at the reflog in
>> addition to doing the usual walk from the tip. The original design
>> description in d96855ff51 (&quo
Johannes Schindelin venit, vidit, dixit 15.09.2017 00:21:
> Hi Michael,
>
> On Thu, 14 Sep 2017, Michael J Gruber wrote:
>
>> test-lib determines whether a file-system supports FIFOs and needs to do
>> special casing for CYGWIN and MINGW. This separates those system
&
Junio C Hamano venit, vidit, dixit 21.09.2017 08:27:
> Junio C Hamano writes:
>
>> ... I agree that there is a value in what your patch 2/3
>> wants to do when the current one that is more strict would say
>> "there is no known fork-point"---we would gain a way to say "... but
>> this is the bes
Junio C Hamano venit, vidit, dixit 22.09.2017 03:49:
> Michael J Gruber writes:
>
>> Also, I'm undecided about about your reflog argument above - if we leave
>> "--fork-point" to be the current behaviour including Jeff's fix then the
>> documentation
From: Michael J Gruber
git-merge does not honor the pre-commit hook when doing automatic merge
commits, and for compatibility reasons this is going to stay.
Introduce a pre-merge hook which is called for an automatic merge commit
just like pre-commit is called for a non-automatic merge commit
o the same in the same way.
Signed-off-by: Michael J Gruber
---
builtin/merge.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index de254d466b..7ba094ee87 100644
--- a/builtin/merge.c
+++ b/builtin/merge.c
@@ -73,7 +73,7 @@
. I've been rebasing and using
this series for years now, 2/4 is the new-comer which fixed the breakage
from f8b863598c that I encountered because of the no-verify
implementation.
Michael J Gruber (4):
git-merge: Honor pre-merge hook
merge: do no-verify like commit
merge: --no-verify
From: Michael J Gruber
Analogous to commit, introduce a '--no-verify' option which bypasses the
pre-merge hook. The shorthand '-n' is taken by the (non-existing)
'--no-stat' already.
Signed-off-by: Michael J Gruber
---
Documentation/git-merge.txt | 2
From: Michael J Gruber
Add tests which make sure that the pre-merge-hook is called when
present, allows/disallows merge commits depending on its return value
and is suppressed by "--no-verify".
Signed-off-by: Michael J Gruber
---
t/t7503-pre-commit-ho
Junio C Hamano venit, vidit, dixit 24.09.2017 01:48:
> Michael J Gruber writes:
>
>> From: Michael J Gruber
>>
>> Analogous to commit, introduce a '--no-verify' option which bypasses the
>> pre-merge hook. The shorthand '-n' is taken by the (
Ekelhart Jakob venit, vidit, dixit 08.11.2017 09:52:
> Thank you for all the effort to fix this issue. Unfortunately, we are still
> suffering from this and our workaround just stopped being sufficient.
>
> We were wondering if there is any way to tell when this fix will be released?
>
> BR Jako
Signed-off-by: Michael J Gruber
---
Just a few things I spotted while trying to keep myself informed :)
Documentation/RelNotes/1.9.txt | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/Documentation/RelNotes/1.9.txt b/Documentation
nathdwek schrieb am 17.10.2014 um 19:30:
> Hello,
>
> It seems to me that the colors used to indicate the repo's state in the
> prompt are hardcoded although the top comment says otherwise.
>
> From contrib/completion/git-contrib.sh:
>
> [83]# If you would like a colored hint about the current d
Linus Torvalds schrieb am 21.10.2014 um 01:17:
> On Mon, Oct 20, 2014 at 3:28 PM, brian m. carlson
> wrote:
>>
>> It doesn't appear that the stability of git archive --format=tar is
>> documented anywhere. Given that, it doesn't seem reasonable to expect
>> that any tar implementation produces bi
Joseph Nahmias schrieb am 20.10.2014 um 23:24:
> Hello,
>
> It would be great if the documentation showed that the git-difftool(1)
> command accepted the --cached option. You can probably steal appropriate
> verbiage from the git-diff(1) manpage.
>
> $ git --version
> git version 2.1.1
>
> Than
Junio C Hamano schrieb am 21.10.2014 um 20:14:
> Michael J Gruber writes:
>
>> Unfortunately, the git archive doc clearly says that the umask is
>> applied to all archive entries.
>
> Is an extended pax header "an archive entry"? I doubt it, and the
> abov
push --signed promises to take user.signingkey as the signing key but
fails to read the config.
Make it do so.
Signed-off-by: Michael J Gruber
---
Interestingly, when I wrote the test I had the impression that user.email
is not heeded either - or do we have GIT_COMMITTER_EMAIL in the
push --signed promises to take user.signingkey as the signing key but
fails to read the config.
Make it do so.
Signed-off-by: Michael J Gruber
---
Okay, I guess this is nicer. We do have the committer info in the env. Sorry.
builtin/push.c | 13 -
t/lib-gpg/trustdb.gpg
This is a first shot at documenting the various signatures that we use
in a technical document. If something like this is deemed useful
I should probably recreate the sample signatures using our testlib
keys and users in a v2.
Michael J Gruber (2):
Documentation/technical: signature formats
Signed-off-by: Michael J Gruber
---
Documentation/technical/signature-format.txt | 35
1 file changed, 35 insertions(+)
diff --git a/Documentation/technical/signature-format.txt
b/Documentation/technical/signature-format.txt
index 80f0a47..49c2c82 100644
--- a
Various formats for storing signatures have accumulated by now.
Document them to keep track (and maybe avoid yet another one).
Signed-off-by: Michael J Gruber
---
Documentation/Makefile | 1 +
Documentation/technical/signature-format.txt | 126
Junio C Hamano schrieb am 23.10.2014 um 00:05:
> Michael J Gruber writes:
>
>> push --signed promises to take user.signingkey as the signing key but
>> fails to read the config.
>>
>> Make it do so.
>>
>> Signed-off-by: Michael J Gruber
>> --
Junio C Hamano schrieb am 23.10.2014 um 01:47:
> Junio C Hamano writes:
>
>> Michael J Gruber writes:
>>
>>> push --signed promises to take user.signingkey as the signing key but
>>> fails to read the config.
>>>
>>> Make it do so.
>&g
t/lib-gpg.sh copies the test environment's gpg home to the trash
directory and makes sure the directoty is writable.
Make sure the copied files are writable, too.
Signed-off-by: Michael J Gruber
---
t/lib-gpg.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/t/lib-gpg.sh b/t/lib-g
Junio C Hamano schrieb am 22.10.2014 um 21:02:
> Michael J Gruber writes:
>
>> Various formats for storing signatures have accumulated by now.
>> Document them to keep track (and maybe avoid yet another one).
>
> I haven't looked at the description closely, but it
David Aguilar schrieb am 27.10.2014 um 02:10:
> On Sun, Oct 26, 2014 at 05:41:49PM -0700, David Aguilar wrote:
>> On Sun, Oct 26, 2014 at 09:09:20AM +0100, Johannes Sixt wrote:
>>> An attempt to quit difftool by hitting Ctrl-D (EOF) at its prompt does
>>> not quit it, but is treated as if 'yes' was
Jakub Narębski schrieb am 25.10.2014 um 10:30:
> W dniu 2014-10-22 21:02, Junio C Hamano pisze:
>
>> A mergetag is not fundamentally a "signature" in the above sense,
>> though. It is just a dump of the object content in a regular object
>> header field (hence indented by one SP), and its content
201 - 300 of 825 matches
Mail list logo
