Johannes Schindelin wrote:
Hi,
On Mon, 12 Feb 2007, Rogan Dawes wrote:
Johannes Schindelin wrote:
(my favourite:)
- use git-split to create a new branch, which only contains doc/. Do work
only on that branch, and merge into mainline from time to time.
Your third option sounds quite clever, apart from the problem of attributing a
commit and a commit message to someone, when the actual commit doesn't match
what they actually did :-(
This problem is not related to subprojects at all. If the commit message
does not match the patch, you are always fscked.
Well, I was thinking about the fact that the files originally checked in
will not match the files "checked in" in the rewritten commit.
As well as wondering what happens when they check out a few more files. Do we
rewrite those commits as well? What happens if the user has made some commits
already? What happens if they have already sent those upstream? etc.
I think you misunderstood. My favourite option would make docs a
_separate_ project, with its own history. It just happens to be pulled
from time to time, just like git-gui, gitk and git-fast-import in git.git.
I see. However, that does not allow for the random single-file checkout
scenario I sketched out. Which may or may not be common/desirable, but
it is an extreme case of the partial checkout, without fixed delineation.
I think the best solution is ultimately to make git able to cope with
certain missing objects.
Hmm. I am not convinced. On nice thing about git is its level of
integrity. Which means that no random objects are missing.
Good point. :-(
I started writing this in response to another message, but it will do fine
here, too:
The description I give here will likely horrify people in terms of
communications inefficiency, but I'm sure that can be improved.
[goes on... and describes the lazy clone!]
>
AFAICT this really is the lazy clone. And it was already determined that
it is all to easy to pull in all commit objects by accident. Which boils
down to a substantial chunk of the repository.
Not so much a lazy clone as a partial clone. It is only in the "clone",
"fetch" or "checkout" code paths that new objects will be retrieved from
the source repo. Things like "git log"/"git show" would not do so, and
would be required to handle missing objects gracefully.
But if you want to play with it: by all means, go ahead. It might just be
that you overcome the fundamental difficulties, and we get something nice
out of it.
Ciao,
Dscho
Maybe ;-) We'll see if I get any time for it.
Rogan
-
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