On Wed, 18 Apr 2007, Sam Vilain wrote: > > Speaking of 'custom' patch file formats, anyone put any thought to a > format for the commits which can't be represented with patch, like > binary files and merges? We do already support binary patches, so those can be represented well in a patch (but you need "git-apply" to apply them, so they are disabled by default.. And while we have tests for them, I suspect not a lot of people really use them widely, so who knows how complete the coverage is. For example, will "git rebase" really work? Probably. Do I know for sure? No). As to merges, they are certainly something that *can* be represented as a patch (just tell what all the parents were, and desribe the end result as a patch against _one_ of them: that already really encodes all the information). So we *could* support it with some trivial extension (and I don't think the extension is necessarily even an expansion of the diff format itself - I think the parents information is a "higher-level" information, and independent of the actual patch). However, representing merges as a patch doesn't really make much sense. You really have two separate cases, and neither of them really makes sense to have a patch with: - you want to "rebase" the history, including merges. Quite frankly, I don't think a patch makes sense: you'd really need to re-do the merge with the old parents "remapped" to the new rebased parents, and what you might want to have is the "rerere" information from the previous merge. Maybe that's a patch, maybe it's not, but regardless, I don't think it really makes sense to describe it as a "patch" even if the implementation would do that: you don't do "remote rebases", so whatever it is would really be totally an internal thing to git-rebase. We currently simply don't support rebasing history with merges. Rebase is a linear history operation. If somebody wants to try to rebase complex history, I'd applaud the effort, but I think the problems are elsewhere than the actual "patch" part. - you want to send raw git commits to somebody else. Use the native git protocol. We already support that over email, it's called "bundles". I used "bundles" once or twice under BK (it was called "bk send" and "bk receive + bk resolve" or something like that), and I hated them. It wasn't BK's fault: I just found the workflow annoying. So I haven't even tested the git bundles, but if what you were looking for was to do a "git push/pull" by email, they are what you'd be using. (The reason I don't like bundles is that if I use email, I want to see the individual patches _in_ the email. And once I see them, I think it's better to take advantage of the flexibility that individual patches gives me, ie I can re-order them, decide to skip one, edit the messages or whatever before applying them. If I were to use bundles, I might as well just not blow up my mailbox, and just ask people to tell me where to pull from). Linus - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html