Re: [PATCH 0/2] apply.c: a fix and an enhancement
On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote: Now if we had a mechanism to graft a later history which starts at 2.6.12-rc2 on top of this earlier history leading up to it,... ;-) We do - it's not even very hard, we just end up with 2 commits for every change/merge that's unique to git, until we get to the current head: Take the last imported commit - we'll call this branch A. Take the 2.6.12-rc2 initial commit, we'll call this branch B. This algorithm should stitch things together: For each commit on branch B Copy all commit metadata (author,etc) Add a new parent Ai. Take the trees from commit B. Write a new commit, Ai+1 When we get to HEAD, we replace HEAD with this last commit we have created, and we now have a nice, parallel commit tree that stitches everything back together. Working from the initial import up, you'll need to work in parallel and handle create some mappings of old commit to new commit to create all the merges with the new commit ids, but I think this should be pretty straightforward to do. If this is all integrated, I'd suggest unpacking everything but the packs that are currently in the main tree, and repacking one very big pack to get the maximum posible benefit from the deltas. -- Ryan Anderson sometimes Pug Majere - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Ryan Anderson [EMAIL PROTECTED] writes: On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote: Now if we had a mechanism to graft a later history which starts at 2.6.12-rc2 on top of this earlier history leading up to it,... ;-) We do - it's not even very hard, we just end up with 2 commits for every change/merge that's unique to git, until we get to the current head: Aren't you essentially rewriting the history after 2.6.12-rc2?. I suspect that would invalidate the current linux-2.6 history people have been basing their work on since 2.6.12-rc2, which is unacceptable. That is not what I meant by grafting. What I meant was to give a hint to the core that says this 2.6.12-rc2 commit in the current linux-2.6.git tree is recorded as not having a parent, but please consider it the same as this other 2.6.12-rc2 commit in the 2.4.0-2.6.12-rc2 history when traversing the commit ancestry chain. If git-rev-list is taught about that, then you will see git log going across 2.6.12-rc2. If git-merge-base is taught about that, it will be able to find a merge base to merge a line of development that is forked from say 2.6.11 to the current tip of linux-2.6 tree. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Junio C Hamano wrote: Ryan Anderson [EMAIL PROTECTED] writes: On Fri, Jul 22, 2005 at 09:56:19AM -0700, Junio C Hamano wrote: Now if we had a mechanism to graft a later history which starts at 2.6.12-rc2 on top of this earlier history leading up to it,... ;-) We do - it's not even very hard, we just end up with 2 commits for every change/merge that's unique to git, until we get to the current head: Aren't you essentially rewriting the history after 2.6.12-rc2?. I suspect that would invalidate the current linux-2.6 history people have been basing their work on since 2.6.12-rc2, which is unacceptable. That is not what I meant by grafting. What I meant was to give a hint to the core that says this 2.6.12-rc2 commit in the current linux-2.6.git tree is recorded as not having a parent, but please consider it the same as this other 2.6.12-rc2 commit in the 2.4.0-2.6.12-rc2 history when traversing the commit ancestry chain. If git-rev-list is taught about that, then you will see git log going across 2.6.12-rc2. If git-merge-base is taught about that, it will be able to find a merge base to merge a line of development that is forked from say 2.6.11 to the current tip of linux-2.6 tree. I think that rewriting history in this case may be the better option in _this_ case. But only because the tools are new and the users are understanding. :-) To do it without the history rewrite, create an alternate_history directory under .git with it's own objects tree. And populate that object tree with alternative content for the objects in the normal trees. Then teach the things the lookup/read objects to look there first and to _not_ care about invalid SHAs. Of course, if you do this, you will never be able to trust your repository. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
On Fri, 22 Jul 2005, A Large Angry SCM wrote: To do it without the history rewrite, create an alternate_history directory under .git with it's own objects tree. And populate that object tree with alternative content for the objects in the normal trees. Then teach the things the lookup/read objects to look there first and to _not_ care about invalid SHAs. Of course, if you do this, you will never be able to trust your repository. You can do it much more nicely if you want. 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. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Linus Torvalds [EMAIL PROTECTED] 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 ;-). - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Linus Torvalds [EMAIL PROTECTED] writes: I'd _really_ prefer to not have any preferences or other metadata files under version control within that same project. Don't you think that would be a per-project decision? Is it acceptable if I make sure that .gitinfo/* is _optional_ and things do not break for projects that do not use it? I hope you are not vetoing the ongoing discussion in another thread from including the per-project configuration. Some people want to run their project differently, and one thing I see often done is to have pre-commit hooks that always run test suites [*1*]. I do not think it is an unreasonable thing for Porcelains to support, and what I am trying to get at is if two Porcelains decide to support it, they do it in a compatible way. 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. I agree. The .gitinfo/fake-parents may be a good thing in that sense to have project-wide, and as long as the kernel person (that is you) do not add .gitinfo/commit-template you would be happy, wouldn't you? [Footnote] *1* Personally sometimes I feel myself that is silly, but that is _other_ people's project, not my own. I think letting them follow their own workflow to slow themselves is better than outright forbidding it and telling them not to do it. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
On Fri, 22 Jul 2005, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: I'd _really_ prefer to not have any preferences or other metadata files under version control within that same project. Don't you think that would be a per-project decision? Is it acceptable if I make sure that .gitinfo/* is _optional_ and things do not break for projects that do not use it? It can't be a per-project decision, since the preferences are per-developer. In other words, if it's per-project, then that implies that every single developer has to agree on the same thing. Which just not possible - it makes no sense. In contrast, if you have a separate local _branch_ that maintains a .gitinfo totally separately (no common commits at all), then you can choose to propagate/participate in that branch or not, as you wish, on a per-developer basis. I agree. The .gitinfo/fake-parents may be a good thing in that sense to have project-wide, I disagree. Even something like fake-parents isn't project-wide. For example, what if I tried to dig out even _more_ information than what is in the BK CVS archives? Or if I wanted to have just the 2.6.0- history? The whole point of fake-parents is that you can do things like that - you can point your history at alternative views. If we'd make it project-global, then we might as well just rewrite the original commit entirely, and use git-convert-cache to convert the whole archive. At that point, fake-parents becomes pointless. and as long as the kernel person (that is you) do not add .gitinfo/commit-template you would be happy, wouldn't you? What you're saying is that people can be happy if they just don't use a stupid decision. That's a sure sign that the decision shouldn't have been made in the first place. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Dear diary, on Fri, Jul 22, 2005 at 11:53:41PM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Fri, 22 Jul 2005, Junio C Hamano wrote: 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Dear diary, on Sat, Jul 23, 2005 at 01:26:07AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Fri, 22 Jul 2005, Junio C Hamano wrote: Linus Torvalds [EMAIL PROTECTED] writes: I'd _really_ prefer to not have any preferences or other metadata files under version control within that same project. Don't you think that would be a per-project decision? Is it acceptable if I make sure that .gitinfo/* is _optional_ and things do not break for projects that do not use it? It can't be a per-project decision, since the preferences are per-developer. In other words, if it's per-project, then that implies that every single developer has to agree on the same thing. Which just not possible - it makes no sense. Some example of possible per-project settings: pre-commit hook killing trailing whitespaces global per-project ignore file (*.ko or something) common base commit template (standardized form developer fills in when committing, some remindments in the comment section, ...) Obviously, you still ought to have a way to locally override any of those per-repository in your .git/conf/. -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter where Linus Torvalds [EMAIL PROTECTED] told me that... On Sat, 23 Jul 2005, Petr Baudis wrote: 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/2] apply.c: a fix and an enhancement
Linus Torvalds [EMAIL PROTECTED] writes: In other words, if it's per-project, then that implies that every single developer has to agree on the same thing. Which just not possible - it makes no sense. I agree 75%. See the bottom for the rest 25%. In contrast, if you have a separate local _branch_ that maintains a .gitinfo totally separately (no common commits at all), then you can choose to propagate/participate in that branch or not, as you wish, on a per-developer basis. Ah, finally the lightbulb moment. And I think what you outlined using git switch in another message is a clean way to do it if somebody wanted to. For example, what if I tried to dig out even _more_ information than what is in the BK CVS archives? Or if I wanted to have just the 2.6.0- history? Good examples; I stand corrected. That is also per group of people who share the same view, i.e. per-developer thing that may be propagated among consenting branch participants. What you're saying is that people can be happy if they just don't use a stupid decision. That's a sure sign that the decision shouldn't have been made in the first place. I am not saying it that strongly. Rather, people can be happy if they do not have to use a decision that they feel stupid. In circles you are part of, especially in a project like the kernel where hundreds of people participate worldwode, I can see that having project-wide preference (or policy) and maintaining it may not make _any_ sense. But on the other hand, it is my understanding that it is a common practice to enforce some centralized policy (I am thinking about pre-commit hooks in particular) in a corporate settings, and for people wanting to have that kind of thing, it is not even a stupid decision. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
