Hi, 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 commit)." 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. Best, Christian. -- 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
