. Hacked together
rather quickly, so I'm only proposing it for contrib for now. If others
see the need, we can add docs, tests and move it to git proper.
Signed-off-by: Michael S. Tsirkin
---
contrib/git-cpcover | 80 +
1 file changed, 80 inser
to date)?
Periods at the end of one-sentence messages?
Colloquialisms and tone of voice? "Already up to date." sounds like a
terse error message but "Everything up-to-date" sounds like a chatty
friend.
Maybe none of this is worth the effort, but I thought I'd mention it
just in case.
Michael Kielstra
From: Michael Platings
Signed-off-by: Michael Platings
---
t/t8014-blame-ignore-fuzzy.sh | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t8014-blame-ignore-fuzzy.sh b/t/t8014-blame-ignore-fuzzy.sh
index 6f1a94caef..6e61882b6f 100755
--- a/t/t8014-blame-ignore
From: Michael Platings
Use an intermediate file between between git blame and sed to avoid
git blame's exit code being hidden.
Signed-off-by: Michael Platings
---
t/t8014-blame-ignore-fuzzy.sh | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/t/t8014-
Hi Denton,
Thanks for the review. The patch was supposed to be in response to
https://public-inbox.org/git/20190613151756.ga31...@szeder.dev/ but
apparently I didn't use --in-reply-to correctly. I'll resubmit with
the requested changes.
-Michael
On Sun, 16 Jun 2019 at 20:02, Denton
From: Michael Platings
---
t/t8014-blame-ignore-fuzzy.sh | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/t/t8014-blame-ignore-fuzzy.sh b/t/t8014-blame-ignore-fuzzy.sh
index 1ff59624e9..13f3313710 100755
--- a/t/t8014-blame-ignore-fuzzy.sh
+++ b/t/t8014-blame
Am 2019-05-16 um 11:34 schrieb Ævar Arnfjörð Bjarmason:
From: Michael Osipov
HP aCC does not accept any of the previously tested CC_LD_DYNPATH
formats, but only its own[1] "-Wl,+b" format. Add it to configure.ac.
1. http://nixdoc.net/man-pages/hp-ux/man1/ld_pa.1.html
Sig
Thanks very much for this Derrick. I looked into it and it turns out
that the missing coverage in blame.c for "certainties[i] =
CERTAINTY_NOT_CALCULATED" was due to earlier code overwriting the same
value in most cases, thereby defeating an optimization. I've deleted
that earlier code and now cover
From: Michael Platings
Thanks to Derrick Stolee for highlighting missing coverage.
In the case of "certainties[i] = CERTAINTY_NOT_CALCULATED" this was
defeating an optimization that preserved results of calculations
between line-matching passes. This had caused other code to never
b
Hi Junio,
The SQUASH??? patches look good to me. Please squash away!
Thanks,
-Michael
On Fri, 17 May 2019 at 06:12, Junio C Hamano wrote:
>
> Barret Rhoden writes:
>
> > From: Michael Platings
> >
> > ...
> > Michael removed the bashisms from the tests.
>
&g
Am 2019-05-16 um 10:31 schrieb Ævar Arnfjörð Bjarmason:
On Thu, May 16 2019, Osipov, Michael wrote:
Am 2019-05-15 um 13:48 schrieb Ævar Arnfjörð Bjarmason:
On Tue, May 14 2019, Osipov, Michael wrote:
Hi,
Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
Update sha1dc from the
Am 2019-05-15 um 13:48 schrieb Ævar Arnfjörð Bjarmason:
On Tue, May 14 2019, Osipov, Michael wrote:
Hi,
Am 2019-05-14 um 00:17 schrieb Ævar Arnfjörð Bjarmason:
Update sha1dc from the latest version by the upstream
maintainer[1]. See 07a20f569b ("Makefile: fix unaligned loads in
s
arcstevens/sha1collisiondetection/pull/50
Signed-off-by: Ævar Arnfjörð Bjarmason
---
n Thu, May 09 2019, Osipov, Michael wrote:
Hey there,
Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
On Wed, May 08 2019, Osipov, Michael wrote:
Hi folks,
Hi see Documentation/SubmittingPatches for how
Hey there,
Am 2019-05-09 um 09:32 schrieb Ævar Arnfjörð Bjarmason:
On Wed, May 08 2019, Osipov, Michael wrote:
Hi folks,
Hi see Documentation/SubmittingPatches for how to submit patches inline
instead of as attachments.
Do you want me to resend the configure.ac change as per wiki article
rl=/usr/bin/perl
--with-iconv=$PREFIX \
--with-libpcre=$PREFIX --with-gitconfig=$PREFIX/etc/gitconfig
--with-gitattributes=$PREFIX/etc/gitattributes \
--without-tcltk --disable-pthreads --with-lib=lib/hpux32
gmake INSTALL=$INSTALL_SH install
Note: I am not subscribed to this list.
Regards,
From: Michael Platings
Hi Barret,
This patch is on top of your patch v6 4/6.
Previously I pointed out that my code couldn't handle this case correctly:
Before:
commit-a 11) Position MyClass::location(Offset O) {
commit-b 12)return P + O;
commit-c 13) }
> My main concerns:
> - Can your version reach outside of a diff chunk?
Currently no. It's optimised for reformatting and renaming, both of
which preserve ordering. I could look into allowing disordered matches
where the similarity is high, while still being biased towards ordered
matches. If you
here they know that line numbers haven't
changed they could choose 1-1 matching, while for a reformatting
commit they could use fuzzy matching. I welcome your thoughts.
-Michael
On Sun, 14 Apr 2019 at 11:24, Junio C Hamano wrote:
> > If you only enable blame.markIgnoredLines then the hash for
> > "unblamable" lines appears as e.g. "*3252488f5" - this doesn't seem
> > right to me because the commit *wasn't* ignored,
>
> I think you misunderstood me. I was merely suggestin
> > + the `blame.ignoreRevsFile` config option. An empty file name, `""`,
> > will
> > + clear the list of revs from previously processed files.
>
> Maybe I haven't read this carefully enough but the use-case for this
> doesn't seem to be explained, you need this for the option, but the
>
On Sun, 14 Apr 2019 at 04:45, Junio C Hamano wrote:
> Wouldn't this make it impossible to tell between what's done by such
> a commit that was marked to be ignored, and what's done locally only
> in the working tree, which the users have long accustomed to see
> with the ^0*$ object name? I think
them separate.
Regarding the "old heuristic" I think there may still be a use case
for that but I'll expand on that later.
Thanks,
-Michael
is going to be interested in
this issue and would prefer that I let him know sooner rather than
later.
-Michael
(resending in plain text, sorry for the spam again)
On Sun, 7 Apr 2019 at 23:52, David Kastrup wrote:
>
> mich...@platin.gs writes:
>
> > From: Michael Platings
>
From: Michael Platings
Hi Barret,
This is the updated fuzzy matching algorithm, sorry for the delay. It does
highlight a bug in the calculation for the number of lines ("int nr_parent_lines
= e->num_lines - delta;") - if you apply the patch, build it, then try to
./git blame
now much faster and
more modest in its memory use. I hope to share the patch tomorrow.
Following that, I'll do what I can to assist with reviewing your
patches.
Cheers,
-Michael
the major problem that the file will
need updating every time you rebase a commit to be ignored, and you'll
need to remember to edit it for cherry picks. Let's not have that
option as I think it will add unhelpful complexity.
-Michael
ented blame.ignoreRevsFile, but I think the world
will be a more consistent and happier place if we dictate the location
that the revisions are loaded from, in the same way as .gitignore.
Deciding what that location should be is one of those bikeshed
arguments which is perhaps why Barret dodged it :)
-Michael
s the parent & child file content, plus the
indices in the strings of where new lines start. This information is
already calculated in the course of doing the diff but it looks like a
fair amount of plumbing work will be needed to make the information
available to the chunk callback. That was my reason for initially
plonking the fuzzy matching in a separate pass.
Thanks,
-Michael
t;fuzzy heuristic" so I'd love to get
your take on it.
Many thanks,
-Michael
On Mon, 25 Mar 2019 at 02:39, Junio C Hamano wrote:
>
> mich...@platin.gs writes:
>
> > From: Michael Platings
> >
> > Hi Git devs,
> >
> > Some of you may be famil
From: Michael Platings
---
blame.c| 352 +++--
blame.h| 1 +
builtin/blame.c| 3 +
t/t8020-blame-fuzzy.sh | 264 +
4 files changed, 609 insertions(+), 11 deletions
From: Michael Platings
Hi Git devs,
Some of you may be familiar with the git-hyper-blame tool [1]. It's "useful if
you have a commit that makes sweeping changes that are unlikely to be what you
are looking for in a blame, such as mass reformatting or renaming."
git-hyper-blame i
From: Michael Rappazzo
On a worktree which is not the primary, using the symbolic-ref 'head' was
incorrectly pointing to the main worktree's HEAD. The same was true for
any other case of the word 'Head'.
Signed-off-by: Michael Rappazzo
---
refs.c
On a worktree which is not the primary, using the symbolic-ref 'head' was
incorrectly pointing to the main worktree's HEAD. The same was true for any
other casing of the word 'Head'.
Signed-off-by: Michael Rappazzo rappa...@gmail.com [rappa...@gmail.com]
Michael Rapp
ch for free if the external tool uses `git` to interact
with the repository. I use such options regularly with external tools.
IMO it would be a regression for these tools to refuse to run when
invoked as, say, `git -C path/to/repo foo`.
Michael
On 2018-11-15, Stefan Beller wrote:
> On Thu, Nov 15, 2018 at 1:33 PM Michael Forney wrote:
>> Well, currently the submodule config can be disabled in diff_flags by
>> setting override_submodule_config=1. However, I'm thinking it may be
>> simpler to selectively *enabl
On 2018-11-15, Michael Forney wrote:
> Here is a work-in-progress diff that seems to have the correct
> behavior in all cases I tried.
I was hoping that gmail wouldn't mess with the whitespace, but apparently
it has, sorry about that. Let me try again.
---
builtin/add.c | 1 -
On 2018-11-15, Stefan Beller wrote:
> On Wed, Nov 14, 2018 at 10:05 PM Michael Forney
> wrote:
>> Looking at ff6f1f564c, I don't really see anything that might be
>> related to git-add, git-reset, or git-diff, so I'm guessing that this
>> only worked before b
+bmwill
On 2018-11-14, Michael Forney wrote:
> On 2018-10-25, Stefan Beller wrote:
>> I guess reverting that commit is not a good idea now, as
>> I would expect something to break.
>>
>> Maybe looking through the series 614ea03a71
>> (Merge branch 'bw
On 2018-10-25, Stefan Beller wrote:
> On Thu, Oct 25, 2018 at 11:03 AM Michael Forney
> wrote:
>>
>> On 2018-03-16, Michael Forney wrote:
>> > Hi,
>> >
>> > In the past few months have noticed some confusing behavior with
>> > ignored submod
On 2018-03-16, Michael Forney wrote:
> Hi,
>
> In the past few months have noticed some confusing behavior with
> ignored submodules. I finally got around to bisecting this to commit
> 5556808690ea245708fb80383be5c1afee2fb3eb (add, reset: ensure
> submodules can be added or res
On Thu, 11 Oct 2018 08:01:40 +0900, Junio wrote:
> Michael Witten writes:
>
>> On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
>>
>>> We haven't seen much complaints and breakages reported against the
>>> two big "rewrite in C" topics arou
On Wed, 10 Oct 2018 18:51:17 -, Michael Witten wrote:
> merge -# Same as merge -C abcde r1
That should be:
merge -# Same as `merge r1'
erges.
Thanks for this great feature.
I'm only complaining so much because it's such a useful feature, and I
want it to be even better, because I'll probably use it A LOT; it
should have been available since the start as a natural consequence of
the way git works.
Sincerely,
Micha
Signed-off-by: Michael Witten
---
Documentation/git-rebase.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-rebase.txt b/Documentation/git-rebase.txt
index 1fbc6ebcde..432baabe33 100644
--- a/Documentation/git-rebase.txt
+++ b/Documentation/git-rebase.txt
The sample code calls `get_revision()' followed by `graph_update()',
but the documentation and source code indicate that `get_revision()'
already calls `graph_update()' for you.
Signed-off-by: Michael Witten
---
Documentation/technical/api-history-graph.txt | 1 -
1 file
Signed-off-by: Michael Witten
---
Documentation/technical/api-history-graph.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/technical/api-history-graph.txt
b/Documentation/technical/api-history-graph.txt
index 18142b6d29..729d6a0cf3 100644
--- a
t's way outside of the scope
of the project for now.
[0]: https://github.com/MichaelMure/git-bug/issues/15
2018-08-19 2:45 GMT+02:00 Michael Muré :
> Here was my reasoning for the naming choice:
>
> - I need something meaningful
> - I need something that encompass the idea and fe
e points about merging)
> Hi again,
>
> To avoid the other thread shadowing more important things:
>
> Michael Muré wrote:
>
>> Someone suggested in the Hacker News thread [0] to post it here as well.
>
> Thanks to Ævar for that.
>
> [...]
>> git-bug use as id
MichaelMure/git-bug
[2]: https://github.com/MichaelMure/git-bug/blob/master/doc/model.md
--
Michael Muré
Sent from my iPhone
> On 2 Aug 2018, at 22:50, Ævar Arnfjörð Bjarmason wrote:
>
> Update sha1dc from the latest version by the upstream
> maintainer[1]. See 2db87328ef ("Merge branch 'ab/sha1dc'", 2017-07-10)
> for the last update.
>
> This fixes an issue where AIX was wrongly detected as a
On 31/07/2018 16:25, Ævar Arnfjörð Bjarmason wrote:
...the real trick is using these macros outside of GCC / glibc and on
older GCC versions. See the github link above, you basically end up with
a whitelist of how it looks on different systems / compilers. Sometimes
both are defined, sometimes on
I hope a I have a "leap forward"
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
> Perhaps it's worth taking a step back here and thinking about whether
> this whole thing is unworkable. It was hard enough to get this to work
> on the combination of Linux, *BSD and Solaris, but I suspect we
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
> The reason we're in this hole is because we use this
> sha1collisiondetection library to do SHA-1, and the reason we have
> issues with it specifically (not OpenSSL et al) is because its only
> method of detecting endianness is at compile ti
A small step back...
On 7/30/2018 11:39 AM, Ævar Arnfjörð Bjarmason wrote:
On Sun, Jul 29 2018, Michael wrote:
On 29/07/2018 22:06, brian m. carlson wrote:
On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote:
On 29/07/2018 21:27, brian m. carlson wrote:
Well, that explains it. I
root@x068:[/data/httpd/gcc]gcc -dM -E - < /dev/null | grep AIX | head -1
#define _AIX 1
michael@x071:[/home/michael]/usr/bin/grep -p DEFLT:
/etc/vac.cfg.[567][123] | grep options\
options =
-D_AIX,-D_AIX32,-D_AIX41,-D_AIX43,-D_AIX50,-D_AIX51,-D_AIX52,-D_AIX53,-D_IBMR2,-D_POWER
On 29/07/2018 23:40, Andreas Schwab wrote:
On Jul 29 2018, Ævar Arnfjörð Bjarmason wrote:
Also, to you and anyone else with access to AIX: I'd be happy to figure
these issues out pro-actively if you give me a login to an AIX
machine. I promise not to do anything except compile/debug/test git o
On 29/07/2018 22:06, brian m. carlson wrote:
On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote:
On 29/07/2018 21:27, brian m. carlson wrote:
Well, that explains it. I would recommend submitting a patch to
https://github.com/cr-marcstevens/sha1collisiondetection, and the we can
pull in
On 29/07/2018 21:27, brian m. carlson wrote:
On Sun, Jul 29, 2018 at 08:59:39PM +0200, Michael wrote:
On 29/07/2018 20:10, brian m. carlson wrote:
Are you using SHA1DC on that system, and does compiling with another
SHA-1 implementation help? There was a change to the SHA1DC code big
endian
On 29/07/2018 20:10, brian m. carlson wrote:
On Sun, Jul 29, 2018 at 06:44:26PM +0200, Michael wrote:
root@x066:[/tmp/xxx]git --version
git version 2.13.3
root@x066:[/tmp/xxx]git clone g...@github.com:aixtools/hello-world.git
Cloning into 'hello-world'...
remote: Counting object
ack failed
p.s. - what surprises me re: git-2.13.2 - no messages about 'Cloning
into ...', which version 2.13.1 did give.
I guess a bisect is the next step - between version 2.13.2 and 2.13.3.
Other suggestions welcome!
Michael
27;t spot anything odd, except for
> > the question about reasoning for why we use memcmp directly over using
> > hashcmp. I don't think that's any sort of blocker, it just seemed an
> > odd decision to me.
>
> I also read through the series and only found the 100/2
On Mon, Jul 2, 2018 at 7:27 PM Stefan Beller wrote:
> On Sun, Jul 1, 2018 at 8:57 AM Michael Haggerty wrote:
> [...]
> So this suggests to have MAX_BORING to be
> "hunk size + some small constant offset" ?
That would be my suggestion, yes. There are cases where it will be
0)
> open('b', 'w').write(" \n" * 110)
(`N = 100`, `M = 10`, `K = 1`) or
> open('a', 'w').write("\nMISSING\n\n" * 100)
> open('b', 'w').write("\nMISSING\n\n" * 110)
(`N
The commits in state:filter.map have already been processed, so don't
filter them again. This makes incremental git filter-branch much faster.
Also add tests for --state-branch option.
Signed-off-by: Michael Barabanov
---
git-filter-branch.sh | 1 +
t/t7003-filter-branch.sh
The commits in state:filter.map have already been processed, so don't
filter them again. This makes incremental git filter-branch much faster.
Also add tests for --state-branch option.
Signed-off-by: Michael Barabanov
---
git-filter-branch.sh | 3 +++
t/t7003-filter-branch.sh
ich ref backend is used.
>
> Suggested-by: Michael Haggerty
> Helped-by: Jeff King
> Signed-off-by: Christian Couder
> ---
> This was suggested and discussed in:
>
> https://public-inbox.org/git/20180525085906.ga2...@sigill.intra.peff.net/
>
> t/t9104-git-svn-foll
apshot *snapshot)
> size = xsize_t(st.st_size);
>
> if (!size) {
> + close(fd);
> return 0;
> } else if (mmap_strategy == MMAP_NONE || size <= SMALL_FILE_SIZE) {
> snapshot->buf = xmalloc(size);
> --
> 2.17.1.1185.g55be947832-goog
>
+1.
Thanks,
Michael
>
> To test the case when we are "deep inside the '.git' directory" the
> test scripts used to perform a `cd .git/refs/heads`.
>
> As there are plans to implement other ref storage systems, let's
> use '.git/objects' instead of '.git/refs/heads' as the "deep inside
> the '.git' directory" path.
Seems reasonable to me. +1.
Michael
On Fri, May 25, 2018 at 10:59 AM, Jeff King wrote:
> On Fri, May 25, 2018 at 10:48:04AM +0200, Michael Haggerty wrote:
>
>> > test_expect_success "multi-fetch works off a 'clean' repository" '
>> > - rm -r "$GIT_DIR/svn" "$GIT_DI
> + git update-ref "refs/tags/$NAME" "$commit" &&
> echo $commit
> }
>
> diff --git a/t/t7201-co.sh b/t/t7201-co.sh
> index 76c223c967..ab9da61da3 100755
> --- a/t/t7201-co.sh
> +++ b/t/t7201-co.sh
> @@ -65,7 +65,7 @@ test_expect_success setup '
> test_expect_success "checkout from non-existing branch" '
>
> git checkout -b delete-me master &&
> - rm .git/refs/heads/delete-me &&
> + git update-ref -d --no-deref refs/heads/delete-me &&
> test refs/heads/delete-me = "$(git symbolic-ref HEAD)" &&
> git checkout master &&
> test refs/heads/master = "$(git symbolic-ref HEAD)"
> diff --git a/t/t9104-git-svn-follow-parent.sh
> b/t/t9104-git-svn-follow-parent.sh
> index a735fa3717..9c49b6c1fe 100755
> --- a/t/t9104-git-svn-follow-parent.sh
> +++ b/t/t9104-git-svn-follow-parent.sh
> @@ -215,7 +215,8 @@ test_expect_success "multi-fetch continues to work" "
> "
>
> test_expect_success "multi-fetch works off a 'clean' repository" '
> - rm -r "$GIT_DIR/svn" "$GIT_DIR/refs/remotes" "$GIT_DIR/logs" &&
> + rm -rf "$GIT_DIR/svn" "$GIT_DIR/refs/remotes" &&
> + git reflog expire --all --expire=all &&
> mkdir "$GIT_DIR/svn" &&
> git svn multi-fetch
> '
>
`rm -rf "$GIT_DIR/refs/remotes"` is not kosher. I think it can be written
printf 'option no-deref\ndelete %s\n' $(git for-each-ref
--format='%(refname)' refs/remotes) | git update-ref --stdin
as long as the number of references doesn't exceed command-line limits.
This will also take care of the reflogs. Another alternative would be to
write it as a loop.
Michael
On 05/25/2018 12:08 AM, Jakub Narebski wrote:
> Derrick Stolee writes:
>> On 5/22/2018 1:39 AM, Michael Haggerty wrote:
>>> On 05/21/2018 08:10 PM, Derrick Stolee wrote:
>>>> [...]
>>> This may be beyond the scope of what you are working on, but there are
&g
ntly use. Sometimes the
difference in diff length is dramatic.
To me it feels like the best *deterministic* merge base would be based
on the above criterion, maybe with first-parent reachability, commit
times, and SHA-1s used (in that order) to break ties.
I don't plan to work on the implement
te_index}_${n}.{ref,log}` to make it
clearer to see by inspection what each file contains. That would also
make it unnecessary, in most cases, to insert a `_${n}` to make the
filename unique.
Michael
[1] https://github.com/dturner-tw/git/tree/dturner/pluggable-backends
overs the lines with asterisks. Are the other
scenarios already covered by other tests? If not, how about adding them?
That would give us confidence that the new code works in all circumstances.
Michael
On Fri, May 04, 2018 at 08:07:53AM -0500, Eric Blake wrote:
> [adding a cross-post to the git mailing list]
>
> On 05/04/2018 02:10 AM, Cornelia Huck wrote:
> > On Thu, 3 May 2018 22:51:40 +0300
> > "Michael S. Tsirkin" wrote:
> >
> > > This wa
itory. With
the new --follow-symlinks option both will be resolved to their
target, and its content shown instead.
Signed-off-by: Michael Vogt
---
Documentation/git-show.txt | 7 +++
builtin/log.c | 6 +-
revision.c | 2 ++
revision.h | 1 +
t/
Updated version of the `git show --follow-symlink` patch. This version
includes the feedback from Ævar Arnfjörð Bjarmason and Stefan Beller:
- commit message updated
- test fixes merged from Ævar (thanks!)
- Documentation/git-show.txt clarified
It does not include a test for --follow-symlinks in
On Fri, Apr 13, 2018 at 09:33:00PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Fri, Apr 13 2018, Michael Vogt wrote:
>
> > The update patch is attached as an inline attachement.
>
> Your patch still just shows up as a straight-up attachment in many
> E-Mail clients. Not
Add support for the `--follow-symlinks` options to git-show. This
allows to write:
git show --follow-symlink HEAD:path-a-symlink
to get the content of the symlinked file.
Signed-off-by: Michael Vogt
---
Documentation/git-show.txt | 6 +
builtin/log.c | 7
On Fri, Apr 13, 2018 at 10:28:13AM -0700, Stefan Beller wrote:
> Hi Michael,
Hi Stefan,
> thanks for the patch,
Thanks for the review.
[..]
> The patch seems reasonable, apart from minor nits:
> In the test we'd prefer no whitespace on the right side of the redirection,
> i.
Hi Ævar,
thanks for your quick reply!
On Mon, Apr 09, 2018 at 11:28:45AM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Apr 09 2018, Michael Vogt wrote:
[..]
> > Subject: [PATCH] support: git show --follow-symlinks HEAD:symlink
> >
> > Add support for the `--follow-symlinks
of these things might be easy to generalize to non-main
repositories, but I didn't bother because AFAIK currently only the main
repository store is ever mutated.
You can move a now-obsolete comment above the definition of `struct
files_ref_store` if you haven't in some other patch (search for
"libification").
Hope that helps,
Michael
hat nothing else is called `the_repository`. But
why actually commit the macro, as opposed to compiling once locally to
check for correctness, then maybe add something like `assert(r ==
the_repository)` for the actual commit?
But I don't care either way, since the macro disappears again soon.
Michael
[1].
It would be nice to have this ability. Attached is a draft patch to
allow to write: `git show --follow-symlinks HEAD:path-to-symlink`.
Tests are missing in the patch, I'm happy to add those if there is a
chance for the feature to get in.
Cheers,
Michael
[1] Using `git cat-file --fol
re in the file. But the file format isn't actually
documented to allow comments, and comments make little sense in this
file, so we won't go that far.)
Signed-off-by: Michael Haggerty
---
I *don't* think we actually want to merge this patch. See the cover
letter for my reas
that the existing tools are OK and this
patch would be counterproductive. But I wanted to share it with the
list anyway.
Michael
Michael Haggerty (1):
packed-backend: ignore broken headers
refs/packed-backend.c | 21 +
t/t3210-pack-refs.sh | 33 -
2 files changed, 41 insertions(+), 13 deletions(-)
--
2.14.2
problematic
for this reason will have a very large number of tree entries.
If you want to detect a bad repository layout like this *before* it
becomes a problem, then probably something like "average tree entries
per commit" might be a good leading indicator of a problem.
Michael
m 'update foo.txt'
[master 6ec564c] update foo.txt
1 file changed, 1 insertion(+), 1 deletion(-)
$ git show
commit 6ec564c15ddae099c71f01750b4c434557525653 (HEAD -> master)
Author: Michael Forney
Date: Fri Mar 16 20:18:37 2018 -0700
update foo.txt
diff --git a/foo.txt b/foo.txt
index
implementation in pure Go, was even
slower. So the final version of `git-sizer` calls `git` for accessing
the repository.
Feedback is welcome, including about the weightings [4] that I use to
compute the "level of concern" of the various metrics.
Have fun,
Michael
[1] https://github.com/githu
this won't cause Git itself any problems, but it's likely to be
inconvenient. For example, when you type `git log` and 7 million
characters page by. Or when you use some GUI tool to view your history
and it performs badly because it wasn't built to handle such enormous
commit messages.
Michael
On Wed, Feb 14, 2018 at 12:41 AM, Jeff King wrote:
> This fixes a (probably harmless) parsing problem in
> sq_dequote_step(), in which we parse some bogus input
> incorrectly rather than complaining that it's bogus.
> [...]
LGTM. Thanks for taking care of this.
Michael
ot followed by a line with lesser indentation).
Doing significantly better probably would require some amount of
language-awareness, but that's a bigger job than I was willing to take
on.
Michael
e because of this.
And as Cylance is not a pattern-based AV, it's not something that will go away
by waiting for the next daily update ...
Any ideas about this?
Thanks
Michael
ut I believe that it does not get committed and besides also does not
seem to have a way to `git add -f`.
---
Note: currently on git version 2.14.1, but looking through the
changelogs, did not see any changes since then that would enable this
workflow.
-Michael Scott-Nelson
ional questions or issues with this packaging - please post
on http://forums.rootvg.net/aixtools - I see that a lot sooner than
any email (on gmail).
HTH,
Michael
On Thu, Jan 18, 2018 at 3:47 PM, Ævar Arnfjörð Bjarmason
wrote:
>
> On Thu, Jan 18 2018, raikrishna jotted:
>
>> Hi T
determined start position is the same as
`snapshot->eof`. (This is possible now because the previous commit
made `find_reference_location()` robust against empty snapshots.)
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 12 ++--
1 file changed, 6 insertions(+), 6 deleti
urn 0 without trying to read or mmap the file.
Returning 0 also makes `create_snapshot()` exit early, which avoids
the technically undefined comparison `NULL < NULL`.
Reported-by: Kim Gybels
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 13 ++---
1 file changed, 6 insertio
4 from
this patch series would be worthwhile improvements.
Michael
Kim Gybels (1):
packed_ref_cache: don't use mmap() for small files
Michael Haggerty (5):
struct snapshot: store `start` rather than `header_len`
create_snapshot(): use `xmemdupz()` rather than a strbuf
find_reference_
It's lighter weight.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index b872267f02..08698de6ea 100644
--- a/refs/packed-backend.c
+++ b/refs/packed-back
From: Kim Gybels
Take a hint from commit ea68b0ce9f8 (hash-object: don't use mmap() for
small files, 2010-02-21) and use read() instead of mmap() for small
packed-refs files.
Signed-off-by: Kim Gybels
Signed-off-by: Junio C Hamano
Signed-off-by: Michael Haggerty
---
refs/packed-back
1 - 100 of 4723 matches
Mail list logo
