Skip to content

send-pack: do not check for sha1 file when GVFS_MISSING_OK set #68

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
kewillford merged 1 commit into from
Nov 27, 2018
Merged

send-pack: do not check for sha1 file when GVFS_MISSING_OK set #68

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion send-pack.c
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -15,6 +15,7 @@
#include "sha1-array.h"
#include "gpg-interface.h"
#include "cache.h"
#include "gvfs.h"

int option_parse_push_signed(const struct option *opt,
const char *arg, int unset)
Expand Down Expand Up @@ -50,7 +51,7 @@ static int send_pack_config(const char *var, const char *value, void *unused)

static void feed_object(const struct object_id *oid, FILE *fh, int negative)
{
if (negative && !has_sha1_file(oid->hash))
if (negative && !gvfs_config_is_set(GVFS_MISSING_OK) && !has_sha1_file(oid->hash))

@derrickstolee derrickstolee Nov 16, 2018

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@kewillford We should be a bit careful here. Specifically, git push starts with an info/refs call to find the current branch tips. If those tips have moved ahead of our prefetch packfiles, then those commits will require the read-object hook. This logic will prevent those commits from being sent to send-pack and hence will not be considered as --not commits in the revision walk. This can lead to over-pushing objects.

In a particularly egregious case, think about a fresh clone with master as the only branch favorite. I clone, make a simple change, and push. The master branch has moved ahead, but now we tell pack-objects to pack our commit and sends zero --not commits. We will pack the entire repo and try to push it.

Let me know if I'm misunderstanding the effect of this change.

@derrickstolee derrickstolee Nov 16, 2018

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's more likely that I am missing something, as if master moves ahead in a vanilla git repo, we don't have the object, so we continue without marking that as a --not commit. Instead, we probably use our refs/remote/origin/... refs. I'm going to do some digging and come back to this soon.

@derrickstolee derrickstolee Nov 16, 2018

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I talked with @kewillford offline and we determined that I was wrong, for multiple reasons. I was misreading some things and it took a while to shake them all out. Here is my new understanding of what's going on:

  1. git push calls git remote-https which calls git send-pack.
  2. Before, git send-pack would trigger the read-object hook and somehow this was causing timing issues.
  3. The change here is to remove the read-object calls from the send-pack logic by understanding we are in a virtualized environment and has_sha1_file(hash) will always return true.
  4. This change does not alter the set of --not commits passed to git pack-objects.
  5. The read-object hook will still be run by git pack-objects, but somehow this timing change prevents the failure.

return;

if (negative)
Expand Down