On Sat, Aug 3, 2013 at 5:13 PM, Philip Oakley <philipoak...@iee.org> wrote:
> 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
So yes it is a know bug.
> 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.
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html