to be
> > a pre-existing bug.
>
> I noticed that, too, but at this point I am only fixing regressions. We
> can try to fix this long-standing bug in the v2.20 cycle.
Right.
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyv
oking at this, I observe that the fact that the `rebase
finished' message also does not honour GIT_REFLOG_ACTION appears to be
a pre-existing bug.
(In general one often can't rely on GIT_REFLOG_ACTION still being set
because the rebase might have been interrupted and restarted, which I
th
ovide a minimal test case but this should suffice
to see the bug I hope...
Regards
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
there
seems to be disagreement about whether a subcommand may *append* to
GIT_REFLOG_ACTION; which, ISTM, is a practice which ought to be
encouraged rather than discouraged.)
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
Jonathan Nieder writes ("Re: want option to git-rebase"):
> Ian Jackson wrote[1]:
> > git-rebase leaves entries like this in the reflog:
> >
> > c15f4d5391 HEAD@{33}: rebase: checkout
> > c15f4d5391ff07a718431aca68a73e672fe8870e
...
> GIT_REFLOG_ACTI
Hi. Thanks to both of you for your helpful comments.
Jonathan Nieder writes ("Re: git signed push server-side"):
> Ian Jackson wrote[1]:
> > 2. git-receive-pack calls gpg (Debian #852684)
> >
> > It would be better if it called gpgv.
...
> think respecting gpg.p
as
seen here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=852695
If I send patches like the above, would they be welcomed (subject to
detailed review, of course) ?
Thanks,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk,
es occur in publicly-visible filenames only in notes
tree objects, which are manipulated by git internally and do not
necessarily need to appear in the filesystem.
The filenames in .git/objects/ can be in whatever encoding we like, so
are not an obstacle.
Ian.
--
Ian JacksonThese opi
Jonathan Nieder writes ("RFC: Another proposed hash function transition plan"):
> This past week we came up with this idea for what a transition to a new
> hash function for Git would look like. I'd be interested in your
> thoughts (especially if you can make them as comments on the document,
> wh
brian m. carlson writes ("Re: Transition plan for git to move to a new hash
function"):
> Instead, I was referring to areas like the notes code. It has extensive
> use of the last byte as a type of lookup table key. It's very dependent
> on having exactly one hash, since it will always want to u
Ian.
[1] I'm going to keep assuming that the bikeshed will be blue, because
I think BLAKE2b has is a better choice. It has probably had more
serious people looking at it than SHA-3, at least, and it has good
performance. The web page has an impressive adoption list - probably
wider than SHA-3.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
brian m. carlson writes ("Re: Transition plan for git to move to a new hash
function"):
> On Mon, Feb 27, 2017 at 01:00:01PM +, Ian Jackson wrote:
> > Objects of one hash may refer to objects named by a different hash
> > function to their own. Preference rules a
Markus Trippelsdorf writes ("Re: Why BLAKE2?"):
> On 2017.02.27 at 13:00 +, Ian Jackson wrote:
> > For brevity I will write `SHA' for hashing with SHA-1, using current
> > unqualified object names, and `BLAKE' for hasing with BLAKE2b, using
> > H ob
ge to make new SHA commits
Default configuration change
SHA disabled in new trees, except during initial
`clone', `mirror' and similar
Effects:
Existing SHA history is retained, and copied to new clients and
servers. But established clients and servers reject
Ian Jackson writes ("Re: SHA1 collisions found"):
> The idea of using the length is a neat trick, but it cannot support
> the dcurrent object name abbreviation approach unworkable.
Sorry, it's late here and my grammar seems to have disintegrated !
Ian.
Junio C Hamano writes ("Re: SHA1 collisions found"):
> Ian Jackson writes:
> > * Therefore the transition needs to be done by giving every object
> >two names (old and new hash function). Objects may refer to each
> >other by either name, but must pick one
Joey Hess writes ("SHA1 collisions found"):
> https://shattered.io/static/shattered.pdf
> https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
>
> IIRC someone has been working on parameterizing git's SHA1 assumptions
> so a repository could eventually use a more secure hash. How far has
> that got
like the one that `git cat-file --batch` has.
I think it should be unbuffered by default, so I will make that
change, along with the fixes from your other mails, and resubmit.
Regards,
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.
Michael Haggerty writes ("Re: [PATCH 1/5] check-ref-format: Refactor out
check_one_ref_format"):
> On 11/04/2016 08:13 PM, Ian Jackson wrote:
> > +static int check_one_ref_format(const char *refname)
...
> This function needs to `return 0` if it gets to the end.
Indeed
Michael Haggerty writes ("Re: [PATCH 2/5] check-ref-format: Refactor to make
--branch code more common"):
> On 11/04/2016 08:13 PM, Ian Jackson wrote:
> > static int normalize = 0;
> > +static int check_branch = 0;
> > static int flags = 0;
> >
> >
Junio C Hamano writes ("Re: [PATCH 5/6] config docs: Provide for config to
specify tags not to abbreviate"):
> Ian Jackson writes:
> > This is not correct, because as I have explained, this should be a
> > per-tree configuration:
>
> I do not have fundamental opp
has a
config file reading system which handles per-tree configs.
If we can't get agreement from the git-core developers on a config to
be used, and documented, for any tool which has similar behaviour, I
think the right answer is `git config gitk.', which would
be documented in git
Jeff King writes ("Re: [PATCH 5/6] config docs: Provide for config to specify
tags not to abbreviate"):
> Yeah, I think git's config system was always designed to carry options
> for porcelains outside of git-core itself. So your new option fits into
> that.
Good, thanks.
> I think the two thing
bbreviation
system in gitk. But they do not address the fundamental point that
some tags are much more interesting than others. It is this latter
point that I am trying to deal with.
Ian.
--
Ian JacksonThese opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk
Jacob Keller writes ("Re: [PATCH 5/6] config docs: Provide for config to
specify tags not to abbreviate"):
> On Mon, Nov 7, 2016 at 4:52 PM, Ian Jackson
> wrote:
> > +log.noAbbrevTags::
> > + Each value is a glob pattern, specifying tag nammes which
> >
Ian Jackson writes ("[PATCH 0/6] Provide for config to specify tags not to
abbreviate"):
> Please find in the following mails patches which provide a way to make
> gitk display certain tags in full, even if they would normally be
> abbreviated.
>
> There are four
gs should be
displayed in full. dgit will be able to set an appropriate config
setting in the trees it deals with.
Ian Jackson (4):
gitk: Internal: drawtags: Abolish "singletag" variable
gitk: Internal: drawtags: Idempotently reset "ntags"
gitk: drawtags: Introduce conce
done any needed abbreviation.
No functional change.
Signed-off-by: Ian Jackson
---
gitk | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 42fa41a..31aecda 100755
--- a/gitk
+++ b/gitk
@@ -6575,9 +6575,10 @@ proc drawtags {id x xt y1} {
} else {
es, in the `singletag'
case, are not themselves valid tag names. So they can be detected
directly.
(Also, `singletag' was not quite right anyway: really it meant that
the tag name(s) had been abbreviated.)
No functional change.
Signed-off-by: Ian Jackson
---
gitk | 3 +--
1 file
it is probably very interesting because it refers to a version
actually uploaded to Debian by the Debian package maintainer.
We would therefore like a way to specify that such tags should be
displayed in full. dgit will be able to set an appropriate config
setting in the trees it deals with.
Sig
been done.
No functional change right now because no tags are considered
`unabbrev'.
Signed-off-by: Ian Jackson
---
gitk | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 31aecda..d76f1e3 100755
--- a/gitk
+++ b/gitk
@@ -6546,6 +6546,10 @
e trees it deals with.
Signed-off-by: Ian Jackson
---
Documentation/config.txt | 8
1 file changed, 8 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index a0ab66a..6aade4f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2002,
Signed-off-by: Ian Jackson
---
Documentation/git-check-ref-format.txt | 10 --
builtin/check-ref-format.c | 34 +++---
2 files changed, 39 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check
Signed-off-by: Ian Jackson
---
Documentation/git-check-ref-format.txt | 8 ++--
builtin/check-ref-format.c | 10 --
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-check-ref-format.txt
b/Documentation/git-check-ref-format.txt
index
I wanted to be able to syntax check lots of proposed refs quickly
(please don't ask why - it's complicated!)
So I added a --stdin option to git-check-ref-format. Also it has
--report-errors now too so you can get some kind of useful error
message if it complains.
It's still not really a good bat
We are going to want to permit other options with --branch.
So, replace the special case with just an entry for --branch in the
parser for ordinary options, and check for option compatibility at the
end.
No overall functional change.
Signed-off-by: Ian Jackson
---
builtin/check-ref-format.c
We are going to want to reuse this. No functional change right now.
It currently has a hidden memory leak if --normalize is used.
Signed-off-by: Ian Jackson
---
builtin/check-ref-format.c | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/builtin
collapse_slashes always returns a value from xmallocz.
Right now this leak is not very interesting, since we only call
check_one_ref_format once.
Signed-off-by: Ian Jackson
---
builtin/check-ref-format.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/builtin/check-ref
38 matches
Mail list logo
