Re: git-format-patch for binary files / merges [Re: Expose subprojects as special files to "git diff" machinery]

On Wed, 18 Apr 2007, Sam Vilain wrote:

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