Linus Torvalds wrote: > > On Mon, 23 Oct 2006, Josh Triplett wrote: >>> I wonder if using "git-log --full-history -- $project" to let the core >>> side omit commits that do not change the $project (but still give you >>> all merged branches) would have made your job any easier? >> I don't think it would. We still need to know what commit to use as the >> parent of any given commit, so we don't want commits in the log output >> with parents that don't exist in the log output. And rewriting parents >> in git-log based on which revisions change the specified subdirectory >> seems like a bad idea. > > Umm.. You didn't realize that git log already _does_ exactly that? No, I didn't, primarily because the git log output I've scrutinized most carefully came from git log --pretty=raw, which doesn't rewrite parents even when pointed at a subdirectory. > You need to rewrite the parents in order to get a nice and readable > history, which in turn is needed for any visualizer. So git has long done > the parent rewriting in order to be able to do things like > > gitk drivers/char > > on the kernel. > > And yes, that's done by the core revision parsing code, so when you do > > git log --full-history --parents -- $project > > you do get the rewritten parent output (of course, it's not actually > _simplified_, so you get a fair amount of duplicate parents etc which > you'd still have to simplify and which don't do anything at all). > > Without the "--full-history", you get a simplified history, but it's > likely to be _too_ simplified for your use, since it will not only > collapse multiple identical parents, it will also totally _remove_ parents > that don't introduce any new content. Considering that git-split does exactly that (remove parents that don't introduce new content, assuming they changed things outside the subtree), that might actually work for us. I just checked, and the output of "git log --parents -- $project" on one of my repositories seems to show the same sequence of commits as git log --parents on the head commit printed by git-split $project (apart from the rewritten sha1s), including elimination of irrelevant merges. > So there are multiple levels of history simplification, and right now the > internal git revision parser only gives you two choices: "none" > (--full-history) and "extreme" (which is the default when you give a set > of filenames). I don't think we need any middle ground here; why might we want less simplification? - Josh Triplett
Attachment:
signature.asc
Description: OpenPGP digital signature