Remove special casing for PSEUDOREF updates #673
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hanwen
changed the title
|
/submit |
hanwen
changed the title
|
Submitted as [email protected] |
![gitgitgadget[bot]](https://avatars.githubusercontent.com/in/12836?s=60&v=4){kind=small}
| @@ -739,102 +739,6 @@ long get_files_ref_lock_timeout_ms(void) | |||
| return timeout_ms; | |||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Han-Wen Nienhuys via GitGitGadget" <[email protected]> writes:
> Subject: Re: [PATCH 1/2] Modify pseudo refs through ref backend storage
> From: Han-Wen Nienhuys <[email protected]>
With what definition of "pseudo refs" has this change been made?
Those things like HEAD, CHERRY_PICK_HEAD, FETCH_HEAD etc. that have
traditionally been written as a plain text file in $GIT_DIR and are
used to name objects by having a full object name in it?
Or the entities that behave like refs and stored in ref backends,
with all-uppercase-names but do not sit inside refs/ hierarchy?
I think it is OK (and possibly a good move in the longer term, but
that is just my gut feeling) to make ref backends resopnsible for
enumerating, reading and writing them (i.e. I think we want to use
the latter definition for the longer term health of the project).
And we would want to ...
> The previous behavior was introduced in commit 74ec19d4be
> ("pseudorefs: create and use pseudoref update and delete functions",
> Jul 31, 2015), with the justification "alternate ref backends still
> need to store pseudorefs in GIT_DIR".
... declare that justification invalid for that purpose.
Is that what is going on? I just want to make sure I am following
your flow of thought.
> Refs such as REBASE_HEAD are read through the ref backend. This can
> only work consistently if they are written through the ref backend as
> well. Tooling that works directly on files under .git should be
> updated to use git commands to read refs instead.
OK.
> diff --git a/refs/files-backend.c b/refs/files-backend.c
> index 6516c7bc8c..9951c2e403 100644
> --- a/refs/files-backend.c
> +++ b/refs/files-backend.c
> @@ -1228,7 +1228,6 @@ static int files_delete_refs(struct ref_store *ref_store, const char *msg,
>
> for (i = 0; i < refnames->nr; i++) {
> const char *refname = refnames->items[i].string;
> -
> if (refs_delete_ref(&refs->base, msg, refname, NULL, flags))
> result |= error(_("could not remove reference %s"), refname);
> }
Unreleated change?
> @@ -2436,7 +2435,9 @@ static int lock_ref_for_update(struct files_ref_store *refs,
> update->backend_data = lock;
>
> if (update->type & REF_ISSYMREF) {
> - if (update->flags & REF_NO_DEREF) {
> + if (update->flags & REF_NO_DEREF ||
> + (ref_type(update->refname) == REF_TYPE_PSEUDOREF &&
> + strcmp(update->refname, "HEAD"))) {
> /*
> * We won't be reading the referent as part of
> * the transaction, so we have to read it here
The old "if we are not dereferencing" condition in if() exactly
matched the comment, but the condition in if() after this change is
not "if we are not dereferencing". Even if we are dereferencing,
under some new condition, we would still drop into this block and do
not follow the "else" side that creates a new update for the
referent. Is this part of "modify pseudo refs via backend" topic,
or should it be a separate modification? Why is this change needed?
It seems that no matter where in the refs/ hierarchy (or even
outside) a symbolic ref resides, the way to update itself (not the
referent through the symbolic ref) should be the same, which is what
the original says, and we want to change that reasoning here, but it
is not quite clear to me why.
> @@ -2782,8 +2783,10 @@ static int files_transaction_finish(struct ref_store *ref_store,
> struct ref_update *update = transaction->updates[i];
> struct ref_lock *lock = update->backend_data;
>
> - if (update->flags & REF_NEEDS_COMMIT ||
> - update->flags & REF_LOG_ONLY) {
> + if ((ref_type(lock->ref_name) != REF_TYPE_PSEUDOREF ||
> + !strcmp(lock->ref_name, "HEAD")) &&
> + (update->flags & REF_NEEDS_COMMIT ||
> + update->flags & REF_LOG_ONLY)) {
And this one stops the files backend from touching all pseudorefs
other than HEAD with this codepath. That somehow feels totally
opposite from what the log message explained above---weren't we
updating the code to write these pseudorefs through the individual
backends, which the files backend is one example of? Isn't this
change stopping the backend from writing the pseudorefs other than
HEAD instead?
Puzzled.
> if (files_log_ref_write(refs,
> lock->ref_name,
> &lock->old_oid,
> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
> index 27171f8261..6b8030e8fe 100755
> --- a/t/t1400-update-ref.sh
> +++ b/t/t1400-update-ref.sh
> @@ -476,7 +476,7 @@ test_expect_success 'git cat-file blob master@{2005-05-26 23:42}:F (expect OTHER
> test_expect_success 'given old value for missing pseudoref, do not create' '
> test_must_fail git update-ref PSEUDOREF $A $B 2>err &&
> test_path_is_missing .git/PSEUDOREF &&
The reason why I asked what this patch thinks the definition of
pseudoref is is because of this thing. Shouldn't this line be fixed
not to depend on the files backend? Likewise for $(cat .git/PSEUDOREF)
in the remaining two hunks.
> - test_i18ngrep "could not read ref" err
> + test_i18ngrep "unable to resolve reference" err
> '
>
> test_expect_success 'create pseudoref' '
> @@ -497,7 +497,7 @@ test_expect_success 'overwrite pseudoref with correct old value' '
> test_expect_success 'do not overwrite pseudoref with wrong old value' '
> test_must_fail git update-ref PSEUDOREF $D $E 2>err &&
> test $C = $(cat .git/PSEUDOREF) &&
> - test_i18ngrep "unexpected object ID" err
> + test_i18ngrep "cannot lock ref.*expected" err
> '
>
> test_expect_success 'delete pseudoref' '
> @@ -509,7 +509,7 @@ test_expect_success 'do not delete pseudoref with wrong old value' '
> git update-ref PSEUDOREF $A &&
> test_must_fail git update-ref -d PSEUDOREF $B 2>err &&
> test $A = $(cat .git/PSEUDOREF) &&
> - test_i18ngrep "unexpected object ID" err
> + test_i18ngrep "cannot lock ref.*expected" err
> '
>
> test_expect_success 'delete pseudoref with correct old value' '
There was a problem hiding this comment.
On the Git mailing list, Han-Wen Nienhuys wrote (reply to this):
On Mon, Jul 6, 2020 at 10:27 PM Junio C Hamano <[email protected]> wrote:
>
> "Han-Wen Nienhuys via GitGitGadget" <[email protected]> writes:
>
> > Subject: Re: [PATCH 1/2] Modify pseudo refs through ref backend storage
> > From: Han-Wen Nienhuys <[email protected]>
>
> With what definition of "pseudo refs" has this change been made?
> Those things like HEAD, CHERRY_PICK_HEAD, FETCH_HEAD etc. that have
> traditionally been written as a plain text file in $GIT_DIR and are
> used to name objects by having a full object name in it?
>
> Or the entities that behave like refs and stored in ref backends,
> with all-uppercase-names but do not sit inside refs/ hierarchy?
I thought these were the same? - see below :)
> I think it is OK (and possibly a good move in the longer term, but
> that is just my gut feeling) to make ref backends resopnsible for
> enumerating, reading and writing them (i.e. I think we want to use
> the latter definition for the longer term health of the project).
> And we would want to ...
>
> > The previous behavior was introduced in commit 74ec19d4be
> > ("pseudorefs: create and use pseudoref update and delete functions",
> > Jul 31, 2015), with the justification "alternate ref backends still
> > need to store pseudorefs in GIT_DIR".
>
> ... declare that justification invalid for that purpose.
>
> Is that what is going on? I just want to make sure I am following
> your flow of thought.
yep.
> > const char *refname = refnames->items[i].string;
> > -
> > if (refs_delete_ref(&refs->base, msg, refname, NULL, flags))
> > result |= error(_("could not remove reference %s"), refname);
> > }
>
> Unreleated change?
oops.
> > @@ -2436,7 +2435,9 @@ static int lock_ref_for_update(struct files_ref_store *refs,
> > update->backend_data = lock;
> >
> > if (update->type & REF_ISSYMREF) {
> > - if (update->flags & REF_NO_DEREF) {
> > + if (update->flags & REF_NO_DEREF ||
> > + (ref_type(update->refname) == REF_TYPE_PSEUDOREF &&
> > + strcmp(update->refname, "HEAD"))) {
> > /*
> > * We won't be reading the referent as part of
> > * the transaction, so we have to read it here
>
> The old "if we are not dereferencing" condition in if() exactly
> matched the comment, but the condition in if() after this change is
> not "if we are not dereferencing". Even if we are dereferencing,
> under some new condition, we would still drop into this block and do
> not follow the "else" side that creates a new update for the
> referent. Is this part of "modify pseudo refs via backend" topic,
> or should it be a separate modification? Why is this change needed?
There is a test (mentioned in the commit message), t1405, which does
$RUN create-symref FOO refs/heads/master nothing &&
# calls refs_create_symref()
..
$RUN delete-refs 0 nothing FOO refs/tags/new-tag &&
# calls refs_delete_refs, which calls delete_pseudoref
..
git rev-parse master >expected &&
Previously, the delete_pseudoref code would delete just .git/FOO file.
Without the change here, going through the ref backend ends up in the
!REF_NO_DEREF case, deleting the master branch.
I don't know what the correct semantics are (are symrefs used for
anything except HEAD ?), so
> It seems that no matter where in the refs/ hierarchy (or even
> outside) a symbolic ref resides, the way to update itself (not the
> referent through the symbolic ref) should be the same, which is what
> the original says, and we want to change that reasoning here, but it
> is not quite clear to me why.
>
> > @@ -2782,8 +2783,10 @@ static int files_transaction_finish(struct ref_store *ref_store,
> > struct ref_update *update = transaction->updates[i];
> > struct ref_lock *lock = update->backend_data;
> >
> > - if (update->flags & REF_NEEDS_COMMIT ||
> > - update->flags & REF_LOG_ONLY) {
> > + if ((ref_type(lock->ref_name) != REF_TYPE_PSEUDOREF ||
> > + !strcmp(lock->ref_name, "HEAD")) &&
> > + (update->flags & REF_NEEDS_COMMIT ||
> > + update->flags & REF_LOG_ONLY)) {
>
> And this one stops the files backend from touching all pseudorefs
> other than HEAD with this codepath. That somehow feels totally
> opposite from what the log message explained above---weren't we
> updating the code to write these pseudorefs through the individual
> backends, which the files backend is one example of? Isn't this
> change stopping the backend from writing the pseudorefs other than
> HEAD instead?
There is a test
'core.logAllRefUpdates=always creates no reflog for ORIG_HEAD'
that wants there to not be reflog updates for ORIG_HEAD. I don't see
why that behavior exists, and would be happy to change it, but I'm too
much of a newbie to decide what is right here.
> > --- a/t/t1400-update-ref.sh
> > +++ b/t/t1400-update-ref.sh
> > @@ -476,7 +476,7 @@ test_expect_success 'git cat-file blob master@{2005-05-26 23:42}:F (expect OTHER
> > test_expect_success 'given old value for missing pseudoref, do not create' '
> > test_must_fail git update-ref PSEUDOREF $A $B 2>err &&
> > test_path_is_missing .git/PSEUDOREF &&
>
> The reason why I asked what this patch thinks the definition of
> pseudoref is is because of this thing. Shouldn't this line be fixed
> not to depend on the files backend? Likewise for $(cat .git/PSEUDOREF)
> in the remaining two hunks.
This patch doesn't introduce reftable yet, so both definitions are
equivalent for the sake of this patch.
--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
Han-Wen Nienhuys <[email protected]> writes:
>> Or the entities that behave like refs and stored in ref backends,
>> with all-uppercase-names but do not sit inside refs/ hierarchy?
>
> I thought these were the same? - see below :)
>> > --- a/t/t1400-update-ref.sh
>> > +++ b/t/t1400-update-ref.sh
>> > @@ -476,7 +476,7 @@ test_expect_success 'git cat-file blob master@{2005-05-26 23:42}:F (expect OTHER
>> > test_expect_success 'given old value for missing pseudoref, do not create' '
>> > test_must_fail git update-ref PSEUDOREF $A $B 2>err &&
>> > test_path_is_missing .git/PSEUDOREF &&
>>
>> The reason why I asked what this patch thinks the definition of
>> pseudoref is is because of this thing. Shouldn't this line be fixed
>> not to depend on the files backend? Likewise for $(cat .git/PSEUDOREF)
>> in the remaining two hunks.
>
> This patch doesn't introduce reftable yet, so both definitions are
> equivalent for the sake of this patch.
But at the end of the tunnel, we do want to see people stop
expecting that .git/PSEUDOREF file is what PSEUDOREF ref is, no? I
think that is what "pseudo refs are not just files directly under
$GIT_DIR, but managed by the backend" means, and that in turn is a
valid justification for other changes introduced in this patch.
Expecting the effect of modifying pseudo refs _after_ the code is
changed that such modifications are properly done through the ref
API to appear on the filesystem feels like it goes against the
reason why we are making this change, compared to checking to see if
the pseudoref really got updated as desired via the ref API, at
least to me.
There was a problem hiding this comment.
On the Git mailing list, Han-Wen Nienhuys wrote (reply to this):
On Tue, Jul 7, 2020 at 5:20 PM Junio C Hamano <[email protected]> wrote:
> >> The reason why I asked what this patch thinks the definition of
> >> pseudoref is is because of this thing. Shouldn't this line be fixed
> >> not to depend on the files backend? Likewise for $(cat .git/PSEUDOREF)
> >> in the remaining two hunks.
> >
> > This patch doesn't introduce reftable yet, so both definitions are
> > equivalent for the sake of this patch.
>
> But at the end of the tunnel, we do want to see people stop
> expecting that .git/PSEUDOREF file is what PSEUDOREF ref is, no? I
> think that is what "pseudo refs are not just files directly under
> $GIT_DIR, but managed by the backend" means, and that in turn is a
> valid justification for other changes introduced in this patch.
> Expecting the effect of modifying pseudo refs _after_ the code is
> changed that such modifications are properly done through the ref
> API to appear on the filesystem feels like it goes against the
> reason why we are making this change, compared to checking to see if
> the pseudoref really got updated as desired via the ref API, at
> least to me.
I can fix this specific instance here (which is what I think you
want), for this commit to practice what it preaches. At the same time
there are probably about 100 or so other places where the tests check
the file system directly for ref(log) existence, so it would never be
totally consistent.
The only way to systematically find the offending places is to
introduce a new ref backend and then fix all the tests, and I think
that goes outside the scope of this small series.
--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
Han-Wen Nienhuys <[email protected]> writes:
> I can fix this specific instance here (which is what I think you
> want), for this commit to practice what it preaches. At the same time
> there are probably about 100 or so other places where the tests check
> the file system directly for ref(log) existence, so it would never be
> totally consistent.
>
> The only way to systematically find the offending places is to
> introduce a new ref backend and then fix all the tests, and I think
> that goes outside the scope of this small series.
Good. I think we are on the same page. I suggested to make the
patch internally consistent, nothing more. And fixing everything in
the world is outside the scope of these two patches.
Thanks.
| @@ -676,10 +676,9 @@ int dwim_log(const char *str, int len, struct object_id *oid, char **log) | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Junio C Hamano wrote (reply to this):
"Han-Wen Nienhuys via GitGitGadget" <[email protected]> writes:
> From: Han-Wen Nienhuys <[email protected]>
>
> This is consistent with the definition of REF_TYPE_PSEUDOREF
> (uppercase in the root ref namespace).
I wonder if some special casing we saw for "HEAD" in 1/2 (e.g. we no
longer do this to pseudorefs in this codepath but HEAD is different
and will continue to be dealt with in the codepath) needs adjustment
after this change? HEAD still needs to be able to have a different
value (either detached or pointing to another ref) per worktree, but
it is unclear where that knowledge now resides in the new code. Are
we declaring that all pseudorefs are per worktree (which I think is
not wrong)?
> Signed-off-by: Han-Wen Nienhuys <[email protected]>
> ---
> refs.c | 7 +++----
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/refs.c b/refs.c
> index a2fd42364f..265767a234 100644
> --- a/refs.c
> +++ b/refs.c
> @@ -676,10 +676,9 @@ int dwim_log(const char *str, int len, struct object_id *oid, char **log)
>
> static int is_per_worktree_ref(const char *refname)
> {
> - return !strcmp(refname, "HEAD") ||
> - starts_with(refname, "refs/worktree/") ||
> - starts_with(refname, "refs/bisect/") ||
> - starts_with(refname, "refs/rewritten/");
> + return starts_with(refname, "refs/worktree/") ||
> + starts_with(refname, "refs/bisect/") ||
> + starts_with(refname, "refs/rewritten/");
> }
>
> static int is_pseudoref_syntax(const char *refname)
There was a problem hiding this comment.
On the Git mailing list, Han-Wen Nienhuys wrote (reply to this):
On Mon, Jul 6, 2020 at 10:30 PM Junio C Hamano <[email protected]> wrote:
> > This is consistent with the definition of REF_TYPE_PSEUDOREF
> > (uppercase in the root ref namespace).
>
> I wonder if some special casing we saw for "HEAD" in 1/2 (e.g. we no
> longer do this to pseudorefs in this codepath but HEAD is different
> and will continue to be dealt with in the codepath) needs adjustment
> after this change? HEAD still needs to be able to have a different
> value (either detached or pointing to another ref) per worktree, but
> it is unclear where that knowledge now resides in the new code. Are
> we declaring that all pseudorefs are per worktree (which I think is
> not wrong)?
the source code already says
enum ref_type {
REF_TYPE_PER_WORKTREE, /* refs inside refs/ but not shared */
REF_TYPE_PSEUDOREF, /* refs outside refs/ in current worktree */
but considers HEAD a REF_TYPE_PER_WORKTREE, counter to the comment.
IIRC, this change actually has almost no effect, because most code
treats both enum values as equivalent. (see eg. builtin/reflog.c),
except for the code that the preceding commit changes.
--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
|
There are issues in commit a25092600d1ce184697cecf0d968aa9db5926cd1: |
|
/submit |
|
Submitted as [email protected] |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
/submit |
|
Submitted as [email protected] |
|
This branch is now known as |
|
This patch series was integrated into seen via git@d3bbd5b. |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
This patch series was integrated into seen via git@c062f2a. |
|
This patch series was integrated into seen via git@16d8606. |
| @@ -148,12 +148,13 @@ still see a subset of the modifications. | |||
|
|
|||
There was a problem hiding this comment.
On the Git mailing list, Johannes Schindelin wrote (reply to this):
Hi Han-Wen,
On Thu, 16 Jul 2020, Han-Wen Nienhuys via GitGitGadget wrote:
> From: Han-Wen Nienhuys <[email protected]>
>
> The previous behavior was introduced in commit 74ec19d4be
> ("pseudorefs: create and use pseudoref update and delete functions",
> Jul 31, 2015), with the justification "alternate ref backends still
> need to store pseudorefs in GIT_DIR".
>
> Refs such as REBASE_HEAD are read through the ref backend. This can
> only work consistently if they are written through the ref backend as
> well. Tooling that works directly on files under .git should be
> updated to use git commands to read refs instead.
>
> The following behaviors change:
>
> * Updates to pseudorefs (eg. ORIG_HEAD) with
> core.logAllRefUpdates=always will create reflogs for the pseudoref.
>
> * non-HEAD pseudoref symrefs are also dereferenced on deletion. Update
> t1405 accordingly.
Unfortunately, there is still a breakage in t1405, although it only really
shows up on Windows and macOS because of case-insensitive filesystems.
https://github.com/gitgitgadget/git/runs/879772942?check_suite_focus=true
shows the concrete problem: t1405.17 'delete_ref(refs/heads/foo)' will
fail thusly:
++ test-tool ref-store main delete-ref msg refs/heads/foo c90e4dc5e12224a428dedfbd45ba11e5531706a2 0
error: cannot lock ref 'refs/heads/foo': is at 1e995a94b5a60488b6ebaf78ec779d85a55ea700 but expected c90e4dc5e12224a428dedfbd45ba11e5531706a2
error: last command exited with $?=1
The reason is that there exists a `refs/heads/foo` _and_ the symref `FOO`
(which points to `refs/heads/master`, which is at 1e995a).
An earlier symptom of this bug is visible on Linux, too, though: when
you run t1405.4 'delete_refs(FOO, refs/tags/new-tag)', it shows this:
+ git rev-parse FOO --
warning: ignoring dangling symref FOO
fatal: bad revision 'FOO'
(Seeing this warning suggests to me that this should probably be caught
_by the regression test_, i.e. stderr should be redirected, and it should
be verified via `test_i18ngrep` that that warning is not shown.)
The reason for this warning is that the symref `.git/FOO` is no longer
removed as part of t1405.4 'delete_refs(FOO, refs/tags/new-tag)'. I've
used this patch to bisect the breakage down to this here patch:
-- snip --
diff --git a/t/t1405-main-ref-store.sh b/t/t1405-main-ref-store.sh
index a8d695cd4f1..779906d607f 100755
--- a/t/t1405-main-ref-store.sh
+++ b/t/t1405-main-ref-store.sh
@@ -34,6 +34,7 @@ test_expect_success 'delete_refs(FOO, refs/tags/new-tag)' '
m=$(git rev-parse master) &&
$RUN delete-refs 0 nothing FOO refs/tags/new-tag &&
test_must_fail git rev-parse FOO -- &&
+ test_path_is_missing .git/FOO &&
test_must_fail git rev-parse refs/tags/new-tag --&&
test_must_fail git rev-parse master -- &&
git update-ref refs/heads/master $m
-- snap --
Hopefully you can figure out what is going wrong.
Ciao,
Dscho
There was a problem hiding this comment.
On the Git mailing list, Han-Wen Nienhuys wrote (reply to this):
On Fri, Jul 17, 2020 at 12:18 PM Johannes Schindelin
<[email protected]> wrote:
> The reason is that there exists a `refs/heads/foo` _and_ the symref `FOO`
> (which points to `refs/heads/master`, which is at 1e995a).
>
> An earlier symptom of this bug is visible on Linux, too, though: when
> you run t1405.4 'delete_refs(FOO, refs/tags/new-tag)', it shows this:
>
> + git rev-parse FOO --
> warning: ignoring dangling symref FOO
> fatal: bad revision 'FOO'
Thanks, this was very helpful for debugging.
The reason is that we do split_symref_update(), where a transaction
that modifies SYMREF (pointing to REFERENT) without REF_NO_DEREF is
changed to a transaction that modifies REFERENT and a reflog-only
update for SYMREF. In this case, that leaves the FOO symref in place.
This seems very specific to the test (is there any use of symrefs
beyond HEAD?) , and I fixed it by passing REF_NO_DEREF to the
delete-refs call.
It would also be nice if this behavior was lifted out of the files
backend and into the generic layer, but it's not yet clear to me if
this is possible.
--
Han-Wen Nienhuys - Google Munich
I work 80%. Don't expect answers from me on Fridays.
--
Google Germany GmbH, Erika-Mann-Strasse 33, 80636 Munich
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
|
This patch series was integrated into seen via git@8f85217. |
|
This patch series was integrated into seen via git@1cda0c2. |
|
This patch series was integrated into seen via git@342854c. |
|
This patch series was integrated into seen via git@5b2ba95. |
|
This patch series was integrated into seen via git@93c2228. |
|
This patch series was integrated into seen via git@94c31ad. |
|
This patch series was integrated into seen via git@88cae4f. |
|
This patch series was integrated into seen via git@111b36a. |
wa268
referenced
this pull request
Jul 25, 2020
The "reference transaction" hook was introduced in commit 6754159 (refs: implement reference transaction hook, 2020-06-19). The name of the hook is declared as "reference-transaction" in "refs.c" and testcases, but the name declared in "githooks.txt" is different. Signed-off-by: Bojun Chen <[email protected]> Reviewed-by: Patrick Steinhardt <[email protected]> Signed-off-by: Junio C Hamano <[email protected]>
wa268
referenced
this pull request
Jul 25, 2020
A new hook. * ps/ref-transaction-hook: githooks.txt: use correct "reference-transaction" hook name
|
This patch series was integrated into seen via git@3a41dd3. |
|
This patch series was integrated into seen via git@750f130. |
|
This patch series was integrated into seen via git@77580fb. |
|
This patch series was integrated into seen via git@641b6fa. |
|
This patch series was integrated into seen via git@c15b717. |
|
This patch series was integrated into seen via git@ddbf547. |
|
This patch series was integrated into seen via git@50b124c. |
|
On the Git mailing list, Han-Wen Nienhuys wrote (reply to this): |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
This patch series was integrated into seen via git@8091ebc. |
|
This patch series was integrated into seen via git@1269f83. |
|
This patch series was integrated into seen via git@924658a. |
|
On the Git mailing list, Han-Wen Nienhuys wrote (reply to this): |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
|
This patch series was integrated into seen via git@a2b1cda. |
|
This patch series was integrated into seen via git@277ca30. |
|
This patch series was integrated into next via git@43ac0bc. |
|
This patch series was integrated into seen via git@335aff3. |
|
This patch series was integrated into seen via git@76d03bf. |
|
This patch series was integrated into seen via git@95c687b. |
|
This patch series was integrated into next via git@95c687b. |
|
This patch series was integrated into master via git@95c687b. |
|
Closed via 95c687b. |
|
On the Git mailing list, Han-Wen Nienhuys wrote (reply to this): |
|
On the Git mailing list, Junio C Hamano wrote (reply to this): |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This gets rid of the special casing code for pseudorefs in refs.c
This is in preparation for reftable.
v4