From: Junio C Hamano <hidden> Date: 2016-06-15 22:42:02
Linus Torvalds [off-list ref] writes:
Just teach "parse_commit()" to look at a ".git/fake_parents" file, and
insert fake extra parents for commits that way - you can graft any tree on
top of any other tree that way, and it's probably a nice idea for testing
things out.
Nicely put, thanks. That was exactly what I meant by
"grafting".
And the file would obviously be per-project, so according to
Pasky's suggestion that would be ".gitinfo/fake_parents" ;-).
And the file would obviously be per-project, so according to
Pasky's suggestion that would be ".gitinfo/fake_parents" ;-).
I'd _really_ prefer to not have any preferences or other metadata files
under version control within that same project.
If you want to version control them, that's fine, but don't tie the
versioning to the main project itself. You can have a _separate_ git
index, and a separate branch for the preferences and other metadata (but
you can, if you want to, obviously share the .git directory contents and
mix up the objects).
The thing is, different people might want to tie in these things different
ways. For example, one thing this kind of "grafting" is useful for is to
literally graft two different projects together, even if you may actually
want to export them independently (ie you do _not_ want the graftign
itself to be visible when you export it).
Think of something like a collection of projects, each under their own
subdirectory. We could eventually literally make them _look_ like one big
project, with cross-project commits grafted together, but they'd
technically be totally independent (think "git" vs "gitk" - rather than
having a very tight merge like I did, we could have tried to make it be a
more virtual graft instead).
And personal preferences are just that - personal. I do _not_ want to have
the kernel project history have things like "editor preferences" etc in
the revision history - you might want to revision them, but that would be
totally independent of the history of the project itself.
Linus
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:02
Dear diary, on Fri, Jul 22, 2005 at 11:53:41PM CEST, I got a letter
where Linus Torvalds [off-list ref] told me that...
On Fri, 22 Jul 2005, Junio C Hamano wrote:
quoted
And the file would obviously be per-project, so according to
Pasky's suggestion that would be ".gitinfo/fake_parents" ;-).
I'd _really_ prefer to not have any preferences or other metadata files
under version control within that same project.
If you want to version control them, that's fine, but don't tie the
versioning to the main project itself. You can have a _separate_ git
index, and a separate branch for the preferences and other metadata (but
you can, if you want to, obviously share the .git directory contents and
mix up the objects).
I think that is a bad idea. Suddenly, you do not have the two things in
the same timeline, which may be quite confusing especially in case of
some hooks which depend on the contents of the tree of the project
itself, in case of commit templates and such.
And personal preferences are just that - personal. I do _not_ want to have
the kernel project history have things like "editor preferences" etc in
the revision history - you might want to revision them, but that would be
totally independent of the history of the project itself.
Yes, but this stuff is not for personal preferences. It is for
project-wide preferences and policies, which can be still normally
overridden or altered locally in each repository.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
Yes, but this stuff is not for personal preferences. It is for
project-wide preferences and policies, which can be still normally
overridden or altered locally in each repository.
What you are describing is a nightmare.
Let's assume that a user alters the settings locally.
EVERY SINGLE TIME he does a "cg-commit", those local alterations would get
committed, since that config file is part of the same project, and cogito
by default commits all changes.
That's just insane. It means that in practive it's simply not reasonable
to have your own local copies of that file. So what would you do? You'd
add more and more hacks to cover this up, and have a "commit-ignore" file
that ignores the .gitinfo files etc etc. UGLY. All because of a design
mistake.
In contrast, let's say that the .gitinfo/xyzzy files were in another
unrelated branch altogether: that means that normally those files wouldn't
even be seen by git as being under revision control (the "index" file
doesn't mention them, nor the tree pointed to by HEAD), but you could, if
you wanted to, do a simple
#
# edit the control files and check the
# changes in to the control stream
#
git switch control-files
.. edit .gitinfo/xyzzy
git commit --all
#
# get back to the real project
#
git switch master
and it just works. In the above "git switch" would be exactly the same as
a normal "git checkout", except it's told to not update the current
directory contexts on switch and instead just save the index file away and
restore it. (In contrast, using a full "git checkout" would remove the
real project when switching to the control files, and then again remove
the control files when switching back to the main project).
Linus
From: Petr Baudis <hidden> Date: 2016-06-15 22:42:02
Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter
where Linus Torvalds [off-list ref] told me that...
On Sat, 23 Jul 2005, Petr Baudis wrote:
quoted
Yes, but this stuff is not for personal preferences. It is for
project-wide preferences and policies, which can be still normally
overridden or altered locally in each repository.
What you are describing is a nightmare.
Let's assume that a user alters the settings locally.
EVERY SINGLE TIME he does a "cg-commit", those local alterations would get
committed, since that config file is part of the same project, and cogito
by default commits all changes.
No, no, no. A user does not alter the settings locally in .gitinfo/ -
.gitinfo/ is for per-_project_ stuff, not per-user. If user wants an
override, he does it per-repository in his .git/conf directory, which is
not version-tracked (actually, core GIT does not even let me to).
That's just insane. It means that in practive it's simply not reasonable
to have your own local copies of that file. So what would you do? You'd
add more and more hacks to cover this up, and have a "commit-ignore" file
that ignores the .gitinfo files etc etc. UGLY. All because of a design
mistake.
Actually, commit-ignore might be useful in other cases, e.g. when
someone (me, a thousand times in the past) needs to keep temporary hacks
in the Makefile so that he can actually build the thing on his weird
system etc. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox