Re: [RFD] Rewriting safety - warn before/when rewriting published history

On Mon, Feb 6, 2012 at 15:44, Jakub Narebski <jnareb@gmail.com> wrote:

True. I too believe that this will be most helpful if it is enabled by default. That said, the easiest way to get there might be through first demonstrating that it works in practice when implemented as hooks.

Hmm. I don't think we'll be able to "plug" all the holes that might leave the user in a rewritten state (e.g. what if the user (possibly with the help of some tool) does an "echo $SHA1 > .git/refs/head/master"?). And trying to plug too many holes might end up annoying more experienced users who "know what they're doing". Instead we might want to add a client-side check at push time. I realize that this check is already done by the remote end, but the client-side might be able to give a more helpful response along the lines of:

  You are trying to push branch X to remote Y, but remote Y already
has a branch X that is N commits in front of you. You may want to
rebase your work on top of the remote branch (see 'git pull
--rebase'), If you instead force this push (with --force), you will
remove those N commits, and replace them with the M last commits from
your branch X.

  (followed by a list of the remote N and local M commits, respectively)

[...]

First, we don't need to annotate _all_ commits. For the 'public' state, we only annotate the last/tip commit that was pushed/published. From there, we can defer that all ancestor commits are also 'public'. For the 'secret' state, we do indeed annotate _all_ secret commits, but I believe this will be a somewhat limited number of commits. If your workflow forces you to annotate millions of commits as 'secret', I claim there is something wrong with your workflow.

Second, git-notes were indeed designed scale well to handle a large number of notes, up to the same order of magnitude as the number of commits in your repo. (When git-notes was originally written, I successfully tested it on versions of a linux-kernel repo where every single commit was annotated). In this case, the number of 'public' annotations in your repo would be equal to the number of pushes you do, and the number of 'secret' annotations would be equal to the number of 'secret' commits in your repo. I'd expect both of these numbers to be orders of magnitude smaller than the total number of commits in your repo (given a fairly typical workflow in a fairly typical repo).

I believe the 'public' state is a "feature of revision walking" (i.e. one annotated 'public' commit implies that all its ancestors are also 'public'). However, the 'secret' state should be bound to the individual commit, IMHO.

Good point. There are two questions we may need to answer: "Has commit X ever been published?", and "Has commit X ever been published in the context of branch Y?". In the latter case, we do indeed need to take the upstream branch into account.

Basically, there are three different "levels" for this rewrite/publish protection to run at:

1. Do not meddle at all. This is the current behavior, and assumes
that if the user rewrites and pushes something, the user knows what
he/she is doing, and Git should not meddle (obviously unless the
server refuses the push).

2. Warn/refuse rewriting commits in your upstream. This would only
check branch X against its registered upstream. Only if there is a
registered upstream, and you're about to rewrite commits that are
reachable from the upstream remote-tracking branch, should Git
intervene and warn/refuse the rewrite. This level would IMHO provide
most of the benefit, and little or no trouble (i.e. false positives).

3. Warn/refuse rewriting _any_ 'public' commit. Refuse to rewrite any
commit that is reachable from any remote-tracking branch. Some would
say that this is a Good Thing(tm), since it prevents a commit from
being _copied_ (i.e. rebased or cherry-picked) between branches (you'd
be in this camp if you run a tightly-controlled workflow, where you
e.g. mandate upmerging patches from the oldest applicable branch
instead of cherry-picking patches from a newer branch). However, other
people would say that this is too limiting, and imposes unnecessary
rules on the workflow of the project (where e.g. copying (by way of
git-rebase) a topic branch from one place to another would cause an
annoying false positive).

[...]

Have fun! :)

...Johan