; 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 @fyvzl.net or @evade.org
ing 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
think is why my t
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.
ement 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 res
ps://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 Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @
licly-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 Jackson <ijack...@chiark.greenend.org.uk
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,
>
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
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 Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed y
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 object names
nitial
`clone', `mirror' and similar
Effects:
Existing SHA history is retained, and copied to new clients and
servers. But established clients and servers reject any newly
introduced SHA.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emai
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 <ijack...@chiark.greenend.org.uk> writes:
> > * Therefore the transition needs to be done by giving every object
> >two names (old and new hash function). Objects may refer to each
> >
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
e 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 Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvz
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.
Ind
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 <ijack...@chiark.greenend.org.uk> writes:
> > This is not correct, because as I have explained, this should be a
> > per-tree configuration:
ading 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 gitk.
Thanks,
Ian.
--
Ian Jackson &
re long tag names, or many tags, it shows them all as a
single small indication saying just `<tag...|' or whatever with the
literal `tag...', not with the tag value.
Maybe a better name would be
gui.alwaysShowTags
?
I'm happy to be just told what the name ought to be, if the gitk and
git mainta
tem 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 Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fy
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
> <ijack...@chiark.greenend.org.uk> wrote:
> > +log.noAbbrevTags::
> > + Each value is a glob pa
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 fo
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 concept of unabb
abbreviation.
No functional change.
Signed-off-by: Ian Jackson <ijack...@chiark.greenend.org.uk>
---
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
, 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 <ijack...@chiark.greenend.org.uk>
---
gi
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.
Signed-off-by: Ian
.
No functional change right now because no tags are considered
`unabbrev'.
Signed-off-by: Ian Jackson <ijack...@chiark.greenend.org.uk>
---
gitk | 15 ++-
1 file changed, 14 insertions(+), 1 deletion(-)
diff --git a/gitk b/gitk
index 31aecda..d76f1e3 100755
--- a/gitk
+++ b/gitk
@@ -
it deals with.
Signed-off-by: Ian Jackson <ijack...@chiark.greenend.org.uk>
---
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/Documen
Signed-off-by: Ian Jackson <ijack...@chiark.greenend.org.uk>
---
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-che
Signed-off-by: Ian Jackson <ijack...@chiark.greenend.org.uk>
---
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/Documen
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
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 <ijack...@chiark.greenend.org
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 <ijack...@chiark.greenend.org.uk>
---
builtin/check-ref-format.c | 26 ++
1 file changed, 14 insertions(
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 <ijack...@chiark.greenend.org.uk>
---
builtin/check-ref-format.c | 4 +++-
1 file changed, 3 insertions(+), 1 de
38 matches
Mail list logo
