Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Mon, 23 Apr 2007, Junio C Hamano wrote: > ... >> ... I am inclined to think that this is quite fundamental. I >> think you just fell into category who want "extended semantics" >> Linus talked about in $gmane/45214: >> >> I suspect that this gets some complaining off our back, but I *also* >> suspect that people will actually end up really screwing themselves with >> something like this and then blaming us and causing a huge pain down the >> line when we've supported this and people want "extended semantics" that >> are no longer clean. >> >> which is kind of dissapointing. I think this was the biggest worry. If even Dscho, who is among a dozen people with the most intimate knowledge of git on the planet, gets it wrong, I can almost guarantee that we will get into the mess Linus predicted above. >> Even if you somehow solved the issue of "stat" rule, I do not >> know what your plans are to manage the blobs that you drop in >> the object store. The list of object names in the mail-index >> file you are generating do not count as connectivity for the >> purpose of fetch/push/fsck/prune. > > I had the idea to update a ref, which holds "trees" of message-id -> blob > pairs, and get updated at the same time. I somehow thought this mailbox thing was because you wanted to transfer mailboxes across repositories. How would you prevent that ref from getting out of sync with the mail-index file git knows nothing about its involvement in connectivity? - 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