git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Elijah Newren <newren@gmail.com>
Cc: Jeff King <peff@peff.net>, Git Mailing List <git@vger.kernel.org>
Subject: Re: Bug report: git branch behaves as if --no-replace-objects is passed
Date: Tue, 30 Mar 2021 16:04:01 -0700	[thread overview]
Message-ID: <xmqqlfa4b5we.fsf@gitster.g> (raw)
In-Reply-To: <CABPp-BEVFi+EsGMCv=qEhe_OGwmWwXF-mg9rjWYNuF0tDZnASg@mail.gmail.com> (Elijah Newren's message of "Tue, 30 Mar 2021 15:43:32 -0700")

Elijah Newren <newren@gmail.com> writes:

> Your "as long as" is I think the assumption that's violated in the
> workflow in question.  You may have the replace ref defined, but
> others don't[1].  Neither party has the actual original deadbeef
> commit[2].  Having deadbeef in refs/heads/foobar leads eventually to
> creating commits with deadbeef as an explicit parent, as we discussed
> above.  While that's internally consistent, as you point out, can you
> push your new commit elsewhere without pushing the replace refs too?

I think the change to "branch --contains" would be an improvement
whether you actually have deadbeef or not, but in any case, defining
(eh, rather, being able to define) a replacement for something you
do not have is the ultimate source of the problem.  And that "bug"
has not very much specific to how "branch --contains" should behave.

> Why does `git branch` (in conjunction with one user deciding to fetch
> replace refs) make it so easy to create a branch that cannot readily
> be shared with others?

In other words, I do not think it is "git branch" or "git checkout -b"
that brought your repository into a broken state.  The "replace"
mechanism may have room for improvement to avoid such a corruption.

IIRC, the original "graft" mechanism did not even have any UI, so it
was pretty much "you can graft any parent to any child, and if you
break the repository you can keep both halves".  Now "replace" has a
dedicated UI component in the form of "git replace" command, we should
be able to teach it how to record replacement more safely.


  reply	other threads:[~2021-03-30 23:04 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-30  6:05 Bug report: git branch behaves as if --no-replace-objects is passed Elijah Newren
2021-03-30  7:02 ` Jeff King
2021-03-30 18:58   ` Junio C Hamano
2021-03-30 21:19     ` Elijah Newren
2021-03-30 21:30       ` Elijah Newren
2021-03-30 21:59         ` Junio C Hamano
2021-03-30 21:53       ` Junio C Hamano
2021-03-30 22:43         ` Elijah Newren
2021-03-30 23:04           ` Junio C Hamano [this message]
2021-03-31  0:32             ` Elijah Newren

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=xmqqlfa4b5we.fsf@gitster.g \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=newren@gmail.com \
    --cc=peff@peff.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).