ol 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 *enable*
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 -
diff
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 because the
+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/subm
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 o
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 around &q
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'
seful 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,
Michael Witten
---
Unfortunately, both the legacy version and the rewrite of
`--
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 changed, 1 deletion
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
e 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 features of a bug
> tracker b
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 identifier
-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
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
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
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
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
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 objects: 3, done
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
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/200 constants
&g
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
00`, `K = 1`) or
> open('a', 'w').write("\nMISSING\n\n" * 100)
> open('b', 'w').write("\nMISSING\n\n" * 110)
(`N = 300`, `M = 30`, `K = 3`). On the other hand, it's not
entirely trivial to find periodicity in a group of lines (i.e., to find
`K`), and I d
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 | 15
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 | 15
ef 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-follow-pa
t *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
eep inside
> the '.git' directory" path.
Seems reasonable to me. +1.
Michael
On Fri, May 25, 2018 at 10:59 AM, Jeff King <p...@peff.net> 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" "$G
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 <sto...@gmail.com> 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
e. 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 implementation of this i
update_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
[2]
https://github.com/
t| wrong value | reject
I think your test only covers 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" <m...@redhat.com> wrote:
> >
&
. With
the new --follow-symlinks option both will be resolved to their
target, and its content shown instead.
Signed-off-by: Michael Vogt <m...@ubuntu.com>
---
Documentation/git-show.txt | 7 +++
builtin/log.c | 6 +-
revision.c | 2 ++
revi
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 <m...@ubuntu.com>
---
Documentation/git-show.txt | 6 +
builtin
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.e. ec
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
bject store).
Some 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
othing 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
ce 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 --follow-symlinks --batch <
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 <mhag...@alum.mit.edu>
---
I *don't* think we actually want to merge this patch. See the cover
letter for my reasoning
atch 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
epository that is 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
o.txt
1 file changed, 1 insertion(+), 1 deletion(-)
$ git show
commit 6ec564c15ddae099c71f01750b4c434557525653 (HEAD -> master)
Author: Michael Forney <mfor...@mforney.org>
Date: Fri Mar 16 20:18:37 2018 -0700
update foo.txt
diff --git a/foo.txt b/foo.txt
index d00491f..0cfbf08 100644
---
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/github/git-sizer
[2]
hanged.
AFAIK 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 <p...@peff.net> 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
receded
but not 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
n my machine 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
Name`,
but 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
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
<ava...@gmail.com> wrote:
>
> On Thu, Jan 18 2018, raikrishna jotted:
the 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 <mhag...@alum.mit.edu>
---
refs/packed-backend.c | 12 ++--
1 file c
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 <kgyb...@infogroep.be>
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/packed
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_location()
It's lighter weight.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
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
ts...@pobox.com>
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/packed-backend.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index e829cf206d..8b4b45da67 100644
--- a/refs/packed-backend.c
+++
ed
NULL when `mustexist` was false, contrary to its docstring.
Change the check and fix the docstring.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/packed-backend.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/refs/packed-backend.
Store a pointer to the start of the actual references within the
`packed-refs` contents rather than storing the length of the header.
This is more convenient for most users of this field.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/packed-backend.
On 01/22/2018 08:31 PM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> writes:
>
>> `snapshot->buf` can still be NULL if the `packed-refs` file didn't exist
>> (see the earlier code path in `load_contents()`). So either that code
>> pa
ec` option. Then instead of
git clone --mirror --single-branch -b BRANCHNAME
with it's non-obvious semantics, you could prohibit that use and instead
support
git clone --bare
--refspec='+refs/heads/BRANCHNAME:refs/heads/BRANCHNAME'
which seems clearer in its intent, if perhaps not sup
tter error messages for
>> corrupt databases, 2007-01-11)
>>
>> Signed-off-by: Kim Gybels <kgyb...@infogroep.be>
>> ---
>>
>> Change since v2: removed separate case for zero length as suggested by Peff,
>> ensuring that snapshot->buf is always a v
ava...@gmail.com> wrote:
>
> On Mon, Jan 15 2018, Michael Giuffrida jotted:
>
>> `git remote prune ` should "delete all stale remote-tracking
>> branches under ". I was surprised to discover, after some
>> troubleshooting, that it also deletes *all* l
`git remote prune ` should "delete all stale remote-tracking
branches under ". I was surprised to discover, after some
troubleshooting, that it also deletes *all* local tags that don't
exist on the remote, if the following refspec is included in the
remote's fetch config:
puting `NULL - NULL` and `NULL + 0`, which are
probably safe in real life but are technically undefined in C.
Sidestep both issues by exiting early if `snapshot->buf` is NULL.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/packed-backend.c | 2 +-
1 file changed, 1
s more
straightforward to document that the function should only be called if
`snapshot->buf` is non-NULL.
Adjust `packed_read_raw_ref()` to return early if `snapshot->buf` is
NULL rather than calling `find_reference_location()`.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/packed-backend.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/refs/packed-backend.c b/refs/packed-backend.c
index 01a13cb817..f20f05b4df 100644
--- a/refs/packed-backend.c
+++ b/refs/packed-bac
, they are totally legitimate
and shouldn't cause Git to fail.) With or without the additions
mentioned below,
Reviewed-by: Michael Haggerty <mhag...@alum.mit.edu>
While reviewing your patch, I realized that some areas of the existing
code use constructs that are undefined according to the C st
"maint". But I
> figured it was worth sharing here in case somebody else runs across it,
> and in case we ever do a v2.14.4 release.
I forgot to respond to this. +1
Reviewed-by: Michael Haggerty <mhag...@alum.mit.edu>
Michael
> -- >8 --
> In clear_packed_ref_cache(), we a
. Zunächst möchte ich mich Ihnen vorstellen.
Ich bin Mrs. Ruth Michael aus Kuwait. Ich war mit dir verheiratet, Peter
Michael. Wer hat 15 Jahre lang mit der kuwaitischen Botschaft in Côte d'Ivoire
gearbeitet, bevor er 2010 starb?
Wir waren 13 Jahre ohne Kind verheiratet. Er starb nach einer kurzen
Ævar Arnfjörð Bjarmason venit, vidit, dixit 12.12.2017 23:26:
>
> On Tue, Dec 12 2017, Randall S. Becker jotted:
>
>> -Original Message-
>> On December 10, 2017 4:14 PM, Ævar Arnfjörð Bjarmason wrote:
>> Subject: [PATCH v3] Makefile: replace perl/Makefile.PL with simple make rules
>>
>>>
On Sun, Nov 26, 2017 at 5:16 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Michael Sloan <mgsl...@gmail.com> writes:
>
>> So what's the problem with this choice of environment variables?
>> Well, the problem is that if PWD is changed during the execution of
>
otfiles-git-bare-repo/
- for versioning your configuration files directly.
Apologies if this has already been discussed, I could not find a good
way to search the mailinglist archives.
Thanks!
-Michael
ggested as "fix") would meet these expectations. I would reuse
the documentation of the current mode as a description of the new mode
and add documentation for the existing mode ;)
Michael
go.
There's some glob-matching code (somewhere? I don't know if it's allowed
everywhere) that allows "**" to mean "zero or one path components. If
"refs/tags" were massaged to be "refs/tags/**", then it would match not only
refs/tags
refs/tags/foo
but also
refs/tags/foo/bar
, which is probably another thing that the user would expect to see.
There's at least some precedent for this kind of expansion: `git
for-each-ref refs/remotes` lists *all* references under that prefix,
even if they have multiple levels.
Michael
On 11/06/2017 02:23 AM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> writes:
>
>> [1] I say "almost entirely" because putting them in one function means
>> that only `pattern` needs to be scanned for glob characters. But that is
>>
rmalized_pattern, prefix, pattern);
void ensure_blob(struct strbuf *pattern);
The caller in this patch would call the functions one after the other
(or the `ensure_blob` behavior could be inlined in
`for_each_glob_ref_in()`, since it doesn't yet have any callers). And
the callers introduced in patch 2 would only need to call the first
function.
> static inline const char *has_glob_specials(const char *pattern)
> {
> return strpbrk(pattern, "?*[");
>
Michael
[1] I say "almost entirely" because putting them in one function means
that only `pattern` needs to be scanned for glob characters. But that is
an unimportant detail.
as two "not". I suggest changing it
to "prefix must not start ...", because that makes it clearer that the
caller is at fault.
What if the caller passes the empty string as prefix? In that case, the
end result would be "/", which is also bogus.
> +
> if (!prefix && !starts_with(pattern, "refs/"))
> strbuf_addstr(normalized_pattern, "refs/");
> else if (prefix)
Michael
parentheses to its
definition to avoid potential future mishaps.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs.h | 4 +---
refs/files-backend.c | 25 -
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/refs.h b/refs.h
We want to make `REF_ISPRUNING` internal to the files backend. For
this to be possible, `ref_transaction_add_update()` mustn't know about
it. So move the check that `REF_ISPRUNING` is only used with
`REF_NODEREF` from this function to `files_transaction_prepare()`.
Signed-off-by: Michael Haggerty
Even after working with this code for years, I still see this constant
name as "ref node ref". Rename it to make it's meaning clearer.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
builtin/am.c | 2 +-
builtin/branch.c | 2 +-
builtin/che
Callers shouldn't be passing disallowed flags into
`ref_transaction_update()`. So instead of masking them off, treat it
as a bug if any are set.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/refs.c b/
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs.c| 2 +-
refs.h| 8
refs/files-backend.c | 19 +--
refs/packed-backend.c | 2 +-
refs/ref-cache.c | 4 ++--
refs/refs-internal.h | 18 +-
6
`.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs.h | 67 ++--
refs/files-backend.c | 45 +++
refs/refs-internal.h | 67
3 files c
as branch `tidy-ref-update-flags` [2].
Michael
[1] https://public-inbox.org/git/cover.1509183413.git.mhag...@alum.mit.edu/
[2] https://github.com/mhagger/git
Michael Haggerty (9):
files_transaction_prepare(): don't leak flags to packed transaction
prune_ref(): call `ref_transaction_add_update
logically what
we want, so include it. In fact it is actually ignored by the packed
backend (which doesn't support symbolic references), but that's its
own business.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/files-backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 del
Underscores are cheap, and help readability.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/files-backend.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 71e088e811..bb10b715a8
Change `write_packed_entry()` to take `struct object_id *` rather than
`unsigned char *` arguments.
Signed-off-by: Michael Haggerty <mhag...@alum.mit.edu>
---
refs/packed-backend.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/refs/packed-backend.c
On 11/01/2017 09:18 AM, Martin Ågren wrote:
> On 28 October 2017 at 11:49, Michael Haggerty <mhag...@alum.mit.edu> wrote:
>> The constants used for `ref_update::flags` were rather disorganized:
>
>> * The documentation wasn't very consistent and partly still referred
&
On 10/30/2017 05:44 AM, Junio C Hamano wrote:
> Michael Haggerty <mhag...@alum.mit.edu> writes:
>
>> The files backend uses `ref_update::flags` for several internal flags.
>> But those flags have no meaning to the packed backend. So when adding
>> updates for the pac
1 - 100 of 4489 matches
Mail list logo
