I was reviewing the rev-list documentation and it struck me that
dense/sparse command line flag do not make much sense.
Since dense is by default in effect, --dense is a no-op. One
possible use of it would be to hardcode --dense on a rev-list
command line in a script, like:
git-rev-list $some_opts --dense $some_paths
to defeat user-supplied --sparse that can be in $some_opts, but
for this to work the script needs to have parsed out user input
into some_opts and some_paths in the first place anyway, so it
can just detect and remove --sparse just as easily.
The --sparse flag does not seem to have much use either; not
giving pathspec has the same effect.
On Sun, 30 Oct 2005, Junio C Hamano wrote:
The --sparse flag does not seem to have much use either; not
giving pathspec has the same effect.
No.
--sparse _does_ have effect, but it's subtler.
Try "--sparse" together with a pathspec. It will only do the merge
follow optimization.
Now, how useful is that? It's potentially useful as a way to "linearize
the history". For example, let's say that you wanted to simplify the
commit history for a project, and you only cared about the history of
certain files - but you do want all the other files to _exist_ in that
history.
So then you could do "git-rev-list --sparse HEAD -- filelist" and you'd
get the minimal history that is still relevant in those files. Any merges
that touch anything else than those files will becomes just regular diffs:
they'll have been linearized away.
Useful? Quite possibly not. But I felt that simplifying merges was
conceptually a very different operation from then compressing a linear
history.
Linus
Linus Torvalds [off-list ref] writes:
Try "--sparse" together with a pathspec. It will only do the merge
follow optimization.
Ah, I saw (paths && dense) everywhere but there indeed is one
that only checks paths to call merge simplification -- I missed
that part.