Re: git replace: should it check for object type, and can it replace merges?

From: Christian Couder <christian.couder@gmail.com>
Date: Aug 5, 2013, 10:57 UTC
Message-ID: <CAP8UFD3yHMKfBdjHc6CxeAXSdQ=ua1MddAb5rRXV3TU0ZW7g6w@mail.gmail.com>
In-Reply-To: <24928554D0C34B4696DAD74F569E2E17@PhilipOakley>

Hi,

On Sat, Aug 3, 2013 at 5:13 PM, Philip Oakley <philipoakley@iee.org> wrote:

Show 5 quoted lines

> A recent comment http://stackoverflow.com/a/18027030/717355 on a question I
> asked two years ago about 'grafts' and 'replace' indicates that users think
> that 'git replace' can't replace a merge commit. The documentation doesn't
> have any examples and gives the naive impression that one should only
> replace a simple commit with another simple commit.

I am sorry if the documentation gives this impression. I'd like to fix it, but I am not sure what should be changed. Should adding an example be enough? Or do you want it to state that explicitely?

> Having looked at the code, I realised that anything can be replaced with
> anything, which is perhaps not what was intended.

The documentation says in the "BUGS" section:

"And of course things may break if an object of one type is replaced by an object of another type (for example a blob replaced by a commit)."

So yes it is a know bug.

Show 5 quoted lines

> A simple thought is that
> the replace should be like-for-like with regard to object type, though that
> would not include replacing a sub-module for a tree (and vice versa).
>
> Should 'git replace' check the object types to ensure they are sensible?

It would probably be a good idea to do that, yeah. But I don't know much about submodules, so I can't say if replacing a sub-module for a tree (and vice versa) should be allowed. Or if there should be a --force-different-objects option for these kinds of special cases.

> Would it be reasonable to add examples to indicate the range of
> replacements, and how to prepare alternative merge commits, or is that a
> hostage to fortune?

Yeah, adding examples would be a good idea. I don't understand what do you mean with "range of replacements", though.

I am not sure preparing alternative commits or merge commits should be an important part of the examples.

There are many cases that could be interesting to different users:

- replacing a non merge commit with a merge commit (if someone forgot
to use --no-ff when merging for example)
- replacing a merge commit with a non merge commit (if a rebase should
have been done)
- and of course replacing a non merge commit with a non merge commit,
or a merge commit with a merge commit

So I think explaining how another commit can be created from existing commits belongs to some other parts of the git documentation. Perhaps there could be such examples in the git hash-object and git filter-branch documentation and we could just point to them.

Best, Christian.