pecific lookup table that prints the algorithm in use.
Signed-off-by: brian m. carlson
---
t/oid-info/hash-info | 3 +++
1 file changed, 3 insertions(+)
diff --git a/t/oid-info/hash-info b/t/oid-info/hash-info
index ccdbfdf974..6b5ded0b34 100644
--- a/t/oid-info/hash-info
+++ b/t/oid-info/ha
The testsuite will eventually learn how to run using an algorithm other
than SHA-1. In preparation for this, teach the test_oid family of
functions how to look up the empty blob and empty tree values so they
can be used.
Signed-off-by: brian m. carlson
---
t/oid-info/hash-info | 6 ++
1
ables, filtered by a whitelist
+ (`git config --show-origin --get`)
+ - A list of all configured git-hooks in `.git/hooks/` (but not their contents)
+ - A list of all loose objects in `.git/objects/`
+ - A list of all packs in `.git/objects/pack`
+ - A list of all object info in `.git/objects
Hi Emily,
On Thu, 15 Aug 2019, Emily Shaffer wrote:
> On Thu, Aug 15, 2019 at 10:07:57PM +0200, Johannes Schindelin wrote:
> >
> > On Thu, 15 Aug 2019, Derrick Stolee wrote:
> >
> > > On 8/14/2019 10:34 PM, Emily Shaffer wrote:
> > > > diff --git a/git-bugreport.sh b/git-bugreport.sh
> > > > new
On Fri, Aug 16, 2019 at 09:41:41AM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > I think comparing this habit to the .gitignore isn't quite fair -
> > .gitignore tells me I forgot to add my new command binary to it, when I
> > run `git status` to see what I need to add to my commit w
Emily Shaffer writes:
> I think comparing this habit to the .gitignore isn't quite fair -
> .gitignore tells me I forgot to add my new command binary to it, when I
> run `git status` to see what I need to add to my commit with new
> command.
That is why I said that we need to actively work on, i
On Thu, Aug 15, 2019 at 04:40:50PM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> > I think a whitelist of config options to print would grow stale
> > immediately, and the options we're missing would be very likely to be
> > configs to turn on new experimental features - which is proba
Emily Shaffer writes:
> I think a whitelist of config options to print would grow stale
> immediately, and the options we're missing would be very likely to be
> configs to turn on new experimental features - which is probably what we
> most want the bugreport for.
The implementation of your "gi
On Thu, Aug 15, 2019 at 03:29:24PM -0700, Junio C Hamano wrote:
> Emily Shaffer writes:
>
> >> > +NOTE
> >> > +
> >> > +Bug reports can be sent to git@vger.kernel.org.
> >>
> >> I am not sure if this belongs here.
> >
> > Sure, I wasn't certain either. Would you rather I remove the "what to
On Thu, Aug 15, 2019 at 07:36:57AM -0700, Junio C Hamano wrote:
> Derrick Stolee writes:
>
> > Config options to consider stripping out:
> >
> > *url*
> > *pass* (anything "password" but also "sendmail.smtppass")
>
> Blacklisting? I wonder if users feel safer if these are limited to
> k
Emily Shaffer writes:
>> > +NOTE
>> > +
>> > +Bug reports can be sent to git@vger.kernel.org.
>>
>> I am not sure if this belongs here.
>
> Sure, I wasn't certain either. Would you rather I remove the "what to do
> with this bugreport" NOTE section entirely?
Not really. You are invoking an
On Thu, Aug 15, 2019 at 10:07:57PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 15 Aug 2019, Derrick Stolee wrote:
>
> > On 8/14/2019 10:34 PM, Emily Shaffer wrote:
> > > diff --git a/git-bugreport.sh b/git-bugreport.sh
> > > new file mode 100755
> > > index 00..2200703a51
> > > --
;s a good point.
In responding to Stolee's review, I mentioned adding additional context
to some command's output so that "those reviewing the report don't need
to be intimately familiar with what the bugreport script runs". But it
might actually be most useful to echo the
for the object
> store. Having a few extra steps such as the following could be nice:
>
> echo "[Loose Objects]"
> for objdir in $(find "$GIT_DIR/objects/??" -type d)
> do
> echo "$objdir: $(ls $objdir | wc -l)"
Hi,
On Thu, 15 Aug 2019, Derrick Stolee wrote:
> On 8/14/2019 10:34 PM, Emily Shaffer wrote:
> > diff --git a/git-bugreport.sh b/git-bugreport.sh
> > new file mode 100755
> > index 00..2200703a51
> > --- /dev/null
> > +++ b/git-bugreport.sh
>
> At first I was alarmed by "What? another she
ut confusing to the person
sitting on the receiving end? Would it help, as a convention, to
always ahve "echo [what am I reporting]" before each of these
commands?
> +# Create bugreport file
> +BUGREPORT_FILE="$basedir/git-bugreport-$(whoami)-$(hostname)-$(date
> -Imin
Derrick Stolee writes:
> Config options to consider stripping out:
>
> *url*
> *pass* (anything "password" but also "sendmail.smtppass")
Blacklisting? I wonder if users feel safer if these are limited to
known-benign ones.
>> +echo "[Configured Hooks]"
>> +find "$GIT_DIR/ho
ernel.org.
> +
> +GIT
> +---
> +Part of the linkgit:git[1] suite
> diff --git a/Makefile b/Makefile
> index f9255344ae..69801a1c45 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -606,6 +606,7 @@ TEST_PROGRAMS_NEED_X =
> unexport CDPATH
>
> SCRIPT_SH +=
ool--helper.sh
SCRIPT_SH += git-filter-branch.sh
SCRIPT_SH += git-merge-octopus.sh
diff --git a/command-list.txt b/command-list.txt
index a9ac72bef4..be5a605047 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -54,6 +54,7 @@ git-archive mainporcelain
git-bisect
Thanks, I will try that as well. Strange it works on command line but not
STDOUT though.
-Original Message-
From: Junio C Hamano
Sent: Friday, August 9, 2019 5:50 PM
To: Cliff Schomburg
Cc: SZEDER Gábor ; git@vger.kernel.org
Subject: Re: "git log" does not display refs
Cliff Schomburg writes:
> Strangely, when I run this command:
>
> Git log origin/master --pretty=oneline --decorate -1
>
> I get the format I want from STDOUT. However, when I try to filter it to
> show only the tag refs:
>
> Git log origin/master --pretty=oneline --decorate --decorate-refs=^ta
standard output again. Only on the command line.
Does --decorate-refs not return to STDOUT?
Thanks,
Cliff
-Original Message-
From: SZEDER Gábor
Sent: Friday, August 9, 2019 3:51 PM
To: Cliff Schomburg
Cc: git@vger.kernel.org
Subject: Re: "git log" does not display refs info when ex
Adding --decorate gave me the desired result.
Thanks for your help!
-Original Message-
From: SZEDER Gábor
Sent: Friday, August 9, 2019 3:51 PM
To: Cliff Schomburg
Cc: git@vger.kernel.org
Subject: Re: "git log" does not display refs info when executed via C# Process
class
On Fri, Aug 09, 2019 at 07:36:19PM +, Cliff Schomburg wrote:
> I have an open Git for Windows issue here:
> https://github.com/git-for-windows/git/issues/2285
>
> "git log" works as expected from the command prompt. But when I execute it
> via C# Process class and read from Standard Output,
Hello,
I have an open Git for Windows issue here:
https://github.com/git-for-windows/git/issues/2285
"git log" works as expected from the command prompt. But when I execute it via
C# Process class and read from Standard Output, the refs are missing.
Is anyone familiar with this issue? Any ide
rage/ceph_**.*.** && git apply 001.patch
I check code and I find that root directory need to be set using "--directory"
I think we need show some info about it.
thinks
simon gao 于2019年7月25日周四 下午6:43写道：
>
> Signed-off-by: simon gao
> ---
> apply.c | 4 +++-
>
Signed-off-by: simon gao
---
apply.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/apply.c b/apply.c
index 4992eca..47b16aa 100644
--- a/apply.c
+++ b/apply.c
@@ -2093,8 +2093,10 @@ static int use_patch(struct apply_state *state, struct
patch *p)
/* Paths outside
Signed-off-by: simon gao
---
apply.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/apply.c b/apply.c
index 4992eca..f66a6ff 100644
--- a/apply.c
+++ b/apply.c
@@ -2094,6 +2094,7 @@ static int use_patch(struct apply_state *state, struct
patch *p)
if (state->prefix && *state->prefix)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
read-cache.c | 49 +++--
1 file changed, 35 insertions(+), 14 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index db5147d088..4accd8bb08 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1694,8 +1694,26 @@
update_server_info() to
>> > > ignore packs which are no longer present (or switch to exec-ing a
>> > > separate update-server-info binary).
>> >
>> > Ah, checking files_exists() and setting a bit seems sufficient.
>>
>> Yes, though we do
On Thu, May 23, 2019 at 05:27:23PM +, Eric Wong wrote:
> ALLOC_GROW makes the whole thing much nicer.
> Thanks for the hint :>
>
> -8<-
> Subject: [PATCH] server-info: do not list unlinked packs
This looks fine to me (though the
e no longer present (or switch to exec-ing a
> > > separate update-server-info binary).
> >
> > Ah, checking files_exists() and setting a bit seems sufficient.
>
> Yes, though we do we even need to store the bit?
I wanted to avoid the over-allocation, and I hit a bounds
g a
> > separate update-server-info binary).
>
> Ah, checking files_exists() and setting a bit seems sufficient.
Yes, though we do we even need to store the bit?
I.e.,
> @@ -199,12 +200,16 @@ static void init_pack_info(const char *infofile, int
> force)
>
Jeff King wrote:
> On Wed, May 15, 2019 at 08:38:39PM +, Eric Wong wrote:
>
> > I've also noticed objects/info/packs contains stale entries
> > after repack/gc runs on current git.
> >
> > Tried adding reprepare_packed_git before update_server_info,
&
On Wed, May 15, 2019 at 08:38:39PM +, Eric Wong wrote:
> I've also noticed objects/info/packs contains stale entries
> after repack/gc runs on current git.
>
> Tried adding reprepare_packed_git before update_server_info,
> but that didn't seem to work; so mayb
I've also noticed objects/info/packs contains stale entries
after repack/gc runs on current git.
Tried adding reprepare_packed_git before update_server_info,
but that didn't seem to work; so maybe something isn't cleared.
Might have time to investigate more this week, might not..
we should've had this feature all along :)
And it's easy for me to build off your WIP to have fetch
update server info iff info/refs already exists:
---8<---
Subject: [PATCH 2/1] server-info: conditionally update on fetch
Since fetch can invalidate existing server info files, use
On Tue, May 14, 2019 at 02:19:36PM +0200, Ævar Arnfjörð Bjarmason wrote:
> Aside from this change, I wonder if making "fetch" optionally "exit 1"
> if no refs were updated would be useful, as in the below WIP. Of course
> it would be better to distinguish errors from "no refs to update".
That see
On Tue, May 14 2019, Eric Wong wrote:
> Jeff King wrote:
>> Yeah, I think there's sort of an open question here of who is calling
>> update-server-info when nothing got updated. I think the only place we
>> call it automatically is via receive-pack, but I'd g
On Tue, May 14 2019, Jeff King wrote:
> On Tue, May 14, 2019 at 12:33:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > I think it would work because any update-server-info, whether from A or
>> > B, will take into account the full current repo state (and we don't
Jeff King wrote:
> Yeah, I think there's sort of an open question here of who is calling
> update-server-info when nothing got updated. I think the only place we
> call it automatically is via receive-pack, but I'd guess Eric runs it as
> part of public-inbox scripts.
On Tue, May 14, 2019 at 12:33:11PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > I think it would work because any update-server-info, whether from A or
> > B, will take into account the full current repo state (and we don't look
> > at that state until we take the loc
On Tue, May 14 2019, Jeff King wrote:
> On Sun, May 12, 2019 at 09:16:31AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
>> > You're probably right (especially because we'd just spent O(n) work
>> > generating the candidate file). But note that I have seen pathologi
On Sun, May 12, 2019 at 09:16:31AM +0200, Ævar Arnfjörð Bjarmason wrote:
> > You're probably right (especially because we'd just spent O(n) work
> > generating the candidate file). But note that I have seen pathological
> > cases where info/refs was gigabytes.
>
&g
Do not change the existing info/refs and objects/info/packs
files if they match the existing content on the filesystem.
This is intended to preserve mtime and make it easier for dumb
HTTP pollers to rely on the If-Modified-Since header.
Combined with stdio and kernel buffering; the kernel should
h-ref or for-each-pack dump, hence opting for not even bothing to
>> stat() to get the size before reading.
>
> You're probably right (especially because we'd just spent O(n) work
> generating the candidate file). But note that I have seen pathological
> cases where info/refs
.
You're probably right (especially because we'd just spent O(n) work
generating the candidate file). But note that I have seen pathological
cases where info/refs was gigabytes.
> > /*
> > * Create the file "path" by writing to a temporary file and renaming
>
> stat() to get the size before reading.
I've been trying to improve dumb HTTP for more cases; actually.
(since it's much cheaper than smart HTTP in server memory/CPU)
> Because really, if we were *trying* to micro-optimize this for time or
> memory use there's much bette
On Sat, May 11 2019, Eric Wong wrote:
> Do not change the existing info/refs and objects/info/packs
> files if they match the existing content on the filesystem.
> This is intended to preserve mtime and make it easier for dumb
> HTTP pollers to rely on the If-Modified-Since header.
Eric Wong wrote:
> Combined with stdio and kernel buffering; the kernel should be
> able to avoid block layer writes and reduce wear.
Along the same lines, I'd like to get repack to stop recreating
identical packs at some point (but that could be months from now...)
1;
>
> Same issue.
>
> > diff --git a/t/t5200-update-server-info.sh b/t/t5200-update-server-info.sh
> > @@ -0,0 +1,41 @@
> > +test_description='Test git stash show configuration.'
>
> Copy/paste error for test description?
Yup, thanks for the review.
On Fri, May 10, 2019 at 9:35 PM Eric Wong wrote:
> Do not change the existing info/refs and objects/info/packs
> files if they match the existing content on the filesystem.
> This is intended to preserve mtime and make it easier for dumb
> HTTP pollers to rely on the If-Modified-
Do not change the existing info/refs and objects/info/packs
files if they match the existing content on the filesystem.
This is intended to preserve mtime and make it easier for dumb
HTTP pollers to rely on the If-Modified-Since header.
Combined with stdio and kernel buffering; the kernel should
From: Nickolai Belakovski
To display worktree path for refs checked out in a linked worktree
Signed-off-by: Nickolai Belakovski
---
Documentation/git-branch.txt | 6 --
builtin/branch.c | 4
t/t3203-branch-output.sh | 19 +++
3 files changed, 27 inser
From: Nickolai Belakovski
The output of git branch is modified to mark branches checked out in a
linked worktree with a "+" and color them in cyan (in contrast to the
current branch, which will still be denoted with a "*" and colored in green)
This is meant to communicate to the user that the br
Am 05.04.2019 um 20:11 schrieb Jeff King:
> On Fri, Apr 05, 2019 at 12:41:27PM +0200, René Scharfe wrote:
>> Parsing "P" and "pack-" together crosses logical token boundaries,
>> but that I don't mind it here.
>
> Yeah, I was tempted to write:
>
> if (skip_prefix(data, "P ", &data) &&
> ski
tp: simplify parsing of remote objects/info/packs
This drops the incorrect claim in the commit message noticed by René.
-Peff
On Fri, Apr 05, 2019 at 02:13:13PM -0400, Jeff King wrote:
> Subject: server-info: simplify cleanup in parse_pack_def()
> We have two exits from the function: either we jump to the out_stale
> label or not. But in both exits we repeat our cleanup, and the only
> difference is our
This old code uses fgets with a fixed-size buffer. Let's use a strbuf
instead, so we don't have to wonder if "1000" is big enough, or what
happens if we see a long line.
This also lets us drop our custom code to trim the newline.
Probably nobody actually cares about the 1000-char limit (after all
When writing objects/info/packs, we use the basename of each pack
(i.e., just the "pack-1234abcd.pack" part). We compute that manually by
adding "objdirlen + 6" to the name.
This _should_ work consistently, as we do not include non-local packs,
meaning everything shoul
nt old_num;
int new_num;
- int nr_alloc;
} **info;
static int num_pack;
static const char *objdir;
@@ -213,6 +212,7 @@ static void init_pack_info(const char *infofile, int force)
for (i = 0, p = get_all_packs(the_repository); p; p = p->next) {
if (!
char *url;
+ const char *data;
struct strbuf buf = STRBUF_INIT;
- unsigned char hash[GIT_MAX_RAWSZ];
- const unsigned hexsz = the_hash_algo->hexsz;
+ struct object_id oid;
end_url_with_slash(&buf, base_url);
strbuf_addstr(&buf, "ob
We have two exits from the function: either we jump to the out_stale
label or not. But in both exits we repeat our cleanup, and the only
difference is our return value. Let's just use a variable for the return
value to avoid repeating ourselves.
Signed-off-by: Jeff King
---
server-info.c | 7 +++
When we're writing out a new objects/info/packs file, we read back the
old one to try to keep the ordering the same. When we see a line
starting with "P", we expect "P pack-1234..." and blindly jump to "line
+ 2" to parse the pack name. If we saw a line with _ju
On Fri, Apr 05, 2019 at 12:41:27PM +0200, René Scharfe wrote:
> Am 05.04.2019 um 01:27 schrieb Jeff King:
> > We can use skip_prefix() and parse_oid_hex() to continuously increment
> > our pointer, rather than dealing with magic numbers. This also fixes a
> > few small shortcomings:
> >
> > - if
o roughly important fixes first, and minor cleanups last). The
> individual chunks are mostly independent, but the server-info cleanups
> rely on the shared pack_basename() helper added as part of the midx fix.
Here's a v2 which addresses the feedback on the last round (thank you
both).
> {
> struct http_get_options options = {0};
> - int ret = 0, i = 0;
> - char *url, *data;
> + int ret = 0;
> + char *url;
> + const char *data;
> struct strbuf buf = STRBUF_INIT;
> - unsigned char hash[GIT_MAX_RAWSZ];
> -
rse rabbit-hole order (which
> is also roughly important fixes first, and minor cleanups last). The
> individual chunks are mostly independent, but the server-info cleanups
> rely on the shared pack_basename() helper added as part of the midx fix.
A kind of cover letter to make readers c
When writing objects/info/packs, we use the basename of each pack
(i.e., just the "pack-1234abcd.pack" part). We compute that manually by
adding "objdirlen + 6" to the name.
This _should_ work consistently, as we do not include non-local packs,
meaning everything shoul
nt old_num;
int new_num;
- int nr_alloc;
} **info;
static int num_pack;
static const char *objdir;
@@ -213,6 +212,7 @@ static void init_pack_info(const char *infofile, int force)
for (i = 0, p = get_all_packs(the_repository); p; p = p->next) {
if (!
This old code uses fgets with a fixed-size buffer. Let's use a strbuf
instead, so we don't have to wonder if "1000" is big enough, or what
happens if we see a long line.
This also lets us drop our custom code to trim the newline.
Probably nobody actually cares about the 1000-char limit (after all
When we're writing out a new objects/info/packs file, we read back the
old one to try to keep the ordering the same. When we see a line
starting with "P", we expect "P pack-1234..." and blindly jump to "line
+ 2" to parse the pack name. If we saw a line with _ju
We have two exits from the function: either we jump to the out_stale
label or not. But in both exits we repeat our cleanup, and the only
difference is our return value. Let's just use a variable for the return
value to avoid repeating ourselves.
Signed-off-by: Jeff King
---
server-info.c | 7 +++
struct object_id oid;
end_url_with_slash(&buf, base_url);
strbuf_addstr(&buf, "objects/info/packs");
@@ -2163,24 +2163,17 @@ int http_get_info_packs(const char *base_url, struct
packed_git **packs_head)
goto cleanup;
data = buf.buf;
at anybody actually cares in practice).
However, I did see a memory bug in its parser, which is fixed by patch
6. And a bunch of other cleanups, which are patches 7-11. Fortunately
that buggy parser is not used to look at info/packs files we pull over
dumb-http; it has its own parser. So I looked at th
This patch series introduces two experimental features to git-p4,
which unrelated to each other.
1. The first patch adds support for so-called "alien" branches.
The feature lets git-p4 create empty commits
to make the history or tags more accurate.
It is particularly useful when spli
On Fri, Mar 15, 2019 at 06:38:07PM -0700, nbelakov...@gmail.com wrote:
> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
> index ceb74e0826..e5dc23e225 100755
> --- a/t/t3203-branch-output.sh
> +++ b/t/t3203-branch-output.sh
> @@ -328,4 +328,23 @@ test_expect_success '--color overr
Nickolai Belakovski writes:
> On Thu, Feb 21, 2019 at 4:59 AM Jeff King wrote:
>>
>> On Tue, Feb 19, 2019 at 05:31:23PM +0900, nbelakov...@gmail.com wrote:
>>
>> > From: Nickolai Belakovski
>> >
>> > To display worktree path for refs checked out in a linked worktree
>>
>> This would be a good p
From: Nickolai Belakovski
The output of git branch is modified to mark branches checked out in a
linked worktree with a "+" and color them in cyan (in contrast to the
current branch, which will still be denoted with a "*" and colored in green)
This is meant to communicate to the user that the br
From: Nickolai Belakovski
To display worktree path for refs checked out in a linked worktree
Signed-off-by: Nickolai Belakovski
---
Documentation/git-branch.txt | 6 --
builtin/branch.c | 4
t/t3203-branch-output.sh | 19 +++
3 files changed, 27 inser
On Thu, Feb 21, 2019 at 4:59 AM Jeff King wrote:
>
> On Tue, Feb 19, 2019 at 05:31:23PM +0900, nbelakov...@gmail.com wrote:
>
> > From: Nickolai Belakovski
> >
> > To display worktree path for refs checked out in a linked worktree
>
> This would be a good place to describe why this is useful. :)
On Thu, Feb 21, 2019 at 4:44 AM Jeff King wrote:
>
> On Tue, Feb 19, 2019 at 05:31:22PM +0900, nbelakov...@gmail.com wrote:
>
> > From: Nickolai Belakovski
> >
> > The output of git branch is modified to mark branches checkout out in a
>
> s/checkout out/checked out/ ?
>
Yes, thanks
>
> > - s
On Tue, Feb 19, 2019 at 05:31:23PM +0900, nbelakov...@gmail.com wrote:
> From: Nickolai Belakovski
>
> To display worktree path for refs checked out in a linked worktree
This would be a good place to describe why this is useful. :)
I do not have an opinion myself. Patch 2 makes a lot of sense
On Tue, Feb 19, 2019 at 05:31:22PM +0900, nbelakov...@gmail.com wrote:
> From: Nickolai Belakovski
>
> The output of git branch is modified to mark branches checkout out in a
s/checkout out/checked out/ ?
> linked worktree with a "+" and color them in cyan (in contrast to the
> current branch,
From: Nickolai Belakovski
To display worktree path for refs checked out in a linked worktree
Signed-off-by: Nickolai Belakovski
---
Documentation/git-branch.txt | 6 --
builtin/branch.c | 4
t/t3203-branch-output.sh | 21 -
3 files changed, 28 ins
From: Nickolai Belakovski
The output of git branch is modified to mark branches checkout out in a
linked worktree with a "+" and color them in cyan (in contrast to the
current branch, which will still be denoted with a "*" and colored in green)
This is meant to communicate to the user that the b
On Mon, Feb 4, 2019 at 9:41 PM brian m. carlson
wrote:
>
> On Mon, Feb 04, 2019 at 09:18:14PM -0500, Larry Martell wrote:
> > On Mon, Feb 4, 2019 at 9:15 PM brian m. carlson
> > wrote:
> > > If you want to generate a file, you can certainly do that in the
> > > post-commit hook or using a Makefil
On Mon, Feb 04, 2019 at 09:18:14PM -0500, Larry Martell wrote:
> On Mon, Feb 4, 2019 at 9:15 PM brian m. carlson
> wrote:
> > If you want to generate a file, you can certainly do that in the
> > post-commit hook or using a Makefile target. You just can't check it
> > into the repo. Lots of project
the
> > install that has certain info (commit id, date of commit, commit
> > message, etc.). and we'd like that to be generated automatically.
>
> If you want to generate a file, you can certainly do that in the
> post-commit hook or using a Makefile target. You just can'
On Mon, Feb 04, 2019 at 09:00:42PM -0500, Larry Martell wrote:
> Thanks for the reply. Any suggestions on how to achieve what I want to do?
>
> The use case is that we want to have a file that is part of the
> install that has certain info (commit id, date of commit, commit
> mess
On Mon, Feb 4, 2019 at 8:55 PM brian m. carlson
wrote:
>
> On Mon, Feb 04, 2019 at 08:36:10PM -0500, Larry Martell wrote:
> > Is there any way using a git hook to get info on the commit (id,
> > message), put that in a file, and include that file in the commit?
> >
&g
On Mon, Feb 04, 2019 at 08:36:10PM -0500, Larry Martell wrote:
> Is there any way using a git hook to get info on the commit (id,
> message), put that in a file, and include that file in the commit?
>
> If I try that in a pre-commit hook I do not get the info on the
> current com
Is there any way using a git hook to get info on the commit (id,
message), put that in a file, and include that file in the commit?
If I try that in a pre-commit hook I do not get the info on the
current commit. I tried it in pre-receive but it does not seem to get
executed at all.
If I do it in
>
> $ git commit -vvv -S -am "Update GnuPG recipe"
> error: gpg failed to sign the data
> fatal: failed to write commit object
>
> How can I obtain more information from git commit?
try
$ GIT_TRACE=1 git commit ...
That should give you more info and the exact gnupg command to execute
should be there too
--
Duy
I'm trying to determine why a new installation of GnuPG is having
trouble. The new install is in /usr/local. The other install is from
the distro and is OK.
Here's the new installation error message:
$ git commit -vvv -S -am "Update GnuPG recipe"
error: gpg failed to sign the data
fat
butes
> > +++ b/.gitattributes
> > @@ -13,3 +13,4 @@
> > /Documentation/gitk.txt conflict-marker-size=32
> > /Documentation/user-manual.txt conflict-marker-size=32
> > /t/t-*.sh conflict-marker-size=32
> > +/t/oid-info/* eol=lf
>
> Yeah, this seems like a sensib
Derrick Stolee writes:
>> FWIW, I personally do not think "is sensitive to CRLF" is too bad,
>> as my attempt to clarify it does not make it much better, e.g.
>>
>> The logic to read from these files in shell uses built-in
>> "read" command, which leaves CR at the end of these text
>>
On Wed, Dec 12, 2018 at 10:14:53AM -0800, Derrick Stolee via GitGitGadget wrote:
> From: Derrick Stolee
>
> The new test_oid machinery in the test library requires reading
> some information from t/oid-info/hash-info and t/oid-info/oid.
> The shell logic that reads from these fil
On 12/12/2018 9:38 PM, Junio C Hamano wrote:
"Derrick Stolee via GitGitGadget" writes:
From: Derrick Stolee
The new test_oid machinery in the test library requires reading
some information from t/oid-info/hash-info and t/oid-info/oid.
The shell logic that reads from these files is
> > wrote:
> > > > From: Derrick Stolee
> > > >
> > > > The new test_oid machinery in the test library requires reading
> > > > some information from t/oid-info/hash-info and t/oid-info/oid.
> > > > The shell logic that reads from the
1 - 100 of 672 matches
Mail list logo
