From: "René Scharfe" <l.s.r@web.de>
To: "brian m. carlson" <sandals@crustytoothpaste.net>,
Michael Ward <mward@smartsoftwareinc.com>,
git@vger.kernel.org, Derrick Stolee <dstolee@microsoft.com>
Subject: Re: Git 2 force commits but Git 1 doesn't
Date: Tue, 23 Jun 2020 10:59:28 +0200 [thread overview]
Message-ID: <09a7fa54-d7ae-772c-fb36-29dbd27bc626@web.de> (raw)
In-Reply-To: <20200623010519.GR6531@camp.crustytoothpaste.net>
Am 23.06.20 um 03:05 schrieb brian m. carlson:
> On 2020-06-22 at 22:17:21, Michael Ward wrote:
>> This is assuming that the repository is completely empty to start. Setup:
>>
>> git clone [repository] repo1
>> git clone [repository] repo2
>> cd repo1
>> echo "test1" > testfile
>> git add testfile
>> git commit -m 'initializing test from 1'
>> git push
>> cd ../repo2
>> git pull
>> cd ../repo1
>>
>> Now for the issue:
>>
>> echo "test1 update" >> testfile
>> git add testfile
>> git commit -m 'update test from 1'
>> git push
>> cd ../repo2
>> echo "test2" >> testfile
>> git commit -m 'update test from 2'
>> git push
>>
>> At this point using the git 2.26 client if I pull in repo1, the commit with
>> comment "update test from 1" is gone and the head is now the commit from 2
>> with "update test from 2" as the comment along with a borked tree. Using the
>> 1.18 client, the push from 2 will prompt to pull first.
>
> Thanks, I can reproduce this with the following test in t5540:
>
> test_expect_success 'non-force push fails if not up to date' '
> git init --bare "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo_conflict.git &&
> git -C "$HTTPD_DOCUMENT_ROOT_PATH"/test_repo_conflict.git update-server-info &&
> git clone $HTTPD_URL/dumb/test_repo_conflict.git "$ROOT_PATH"/c1 &&
> git clone $HTTPD_URL/dumb/test_repo_conflict.git "$ROOT_PATH"/c2 &&
> test_commit -C "$ROOT_PATH/c1" path1 &&
> git -C "$ROOT_PATH/c1" push origin HEAD &&
> git -C "$ROOT_PATH/c2" pull &&
> test_commit -C "$ROOT_PATH/c1" path2 &&
> git -C "$ROOT_PATH/c1" push origin HEAD &&
> test_commit -C "$ROOT_PATH/c2" path3 &&
> git -C "$ROOT_PATH/c1" log --graph --all &&
> git -C "$ROOT_PATH/c2" log --graph --all &&
> test_must_fail git -C "$ROOT_PATH/c2" push origin HEAD
> '
>
> The relevant code is here:
>
> if (!has_object_file(&ref->old_oid) ||
> !ref_newer(&ref->peer_ref->new_oid,
> &ref->old_oid)) {
>
> In this case, ref_newer returns 1 (true), which is wrong. _However_, if
> I add a debugging statement that prints ref_newer immediately above that
> line, like so:
>
> fprintf(stderr, "debug: a: %s %s %d\n", oid_to_hex(&ref->old_oid), oid_to_hex(&ref->peer_ref->new_oid), ref_newer(&ref->peer_ref->new_oid, &ref->old_oid));
>
> The test starts passing (that is, ref_newer must return 0).
>
> I'm CCing Derrick Stolee, to whom that code blames, because I'm not sure
> that we should be returning different results in this case with what
> must be the same arguments.
The following patch helps by avoiding a commit flag collision between
http-push.c and commit-reach.c. I don't know if it causes other
collisions, though.
How could we possibly check that? Perhaps by having a commit flag
register (a global unsigned int) and having functions announce their
bits in it. Colliding announcements would BUG().
diff --git a/http-push.c b/http-push.c
index 822f326599..99adbebdcf 100644
--- a/http-push.c
+++ b/http-push.c
@@ -70,10 +70,10 @@ enum XML_Status {
#define LOCK_REFRESH 30
/* Remember to update object flag allocation in object.h */
-#define LOCAL (1u<<16)
-#define REMOTE (1u<<17)
-#define FETCHING (1u<<18)
-#define PUSHING (1u<<19)
+#define LOCAL (1u<<11)
+#define REMOTE (1u<<12)
+#define FETCHING (1u<<13)
+#define PUSHING (1u<<14)
/* We allow "recursive" symbolic refs. Only within reason, though */
#define MAXDEPTH 5
diff --git a/object.h b/object.h
index b22328b838..a496d2e4e1 100644
--- a/object.h
+++ b/object.h
@@ -67,7 +67,7 @@ struct object_array {
* builtin/blame.c: 12-13
* bisect.c: 16
* bundle.c: 16
- * http-push.c: 16-----19
+ * http-push.c: 11-----14
* commit-graph.c: 15
* commit-reach.c: 16-----19
* sha1-name.c: 20
next prev parent reply other threads:[~2020-06-23 8:59 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-22 19:40 Git 2 force commits but Git 1 doesn't Michael Ward
2020-06-22 20:21 ` brian m. carlson
2020-06-22 20:30 ` Michael Ward
2020-06-22 20:31 ` Michael Ward
2020-06-22 20:43 ` brian m. carlson
2020-06-22 20:52 ` Michael Ward
2020-06-22 21:09 ` brian m. carlson
2020-06-22 22:17 ` Michael Ward
2020-06-23 1:05 ` brian m. carlson
2020-06-23 8:59 ` René Scharfe [this message]
2020-06-23 15:30 ` brian m. carlson
2020-06-23 16:42 ` René Scharfe
2020-06-23 19:13 ` brian m. carlson
2020-06-24 13:05 ` René Scharfe
2020-06-23 20:21 ` [PATCH] http-push: ensure unforced pushes fail when data would be lost brian m. carlson
2020-06-23 21:28 ` Eric Sunshine
2020-06-23 21:50 ` brian m. carlson
2020-06-23 21:52 ` [PATCH v2] " brian m. carlson
2020-06-23 22:41 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=09a7fa54-d7ae-772c-fb36-29dbd27bc626@web.de \
--to=l.s.r@web.de \
--cc=dstolee@microsoft.com \
--cc=git@vger.kernel.org \
--cc=mward@smartsoftwareinc.com \
--cc=sandals@crustytoothpaste.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).