Good news everyone!
At long last grubba has returned from his excursions into the land of commit graph archeology and brings back with him the complete and unified Pike history in one git repository.
Marcus has been sacrificing copious amounts of defenceless computrons on the operation of verifying that the completed repository looks correct and has now provided his seal of approval.
The switch from CVS to git is thus now completed. The instructions for cloning your very own copy of the pike repository are available here:
http://pike.ida.liu.se/development/git/rw-git.xml
To avoid the wrath of your fellow developers, please read the instructions carefully, and get a new enough git binary before checking out!
In other news, Pike 7.9 is now open for commits and is the default branch.
Enjoy!
Sidenote: Anyone who has made a checkin the last 3 years automatically got their ssh keys copied to the git server.
If any oldtimers suddenly decide you want to commit again then use the same contacts as for creating a new account.
First c0mmit!1!!1 :)
Nah, Comstedt was actually first by opening up 7.9.
So could we please hear the story with the hooks and the idents?
I started to rebase my stuff from the old pikex repo, and I noticed that the commit hooks don't run on rebase. I guess they still do on the server though, but I haven't tested that.
It'll be some fiddling with all those foreign_ident attributes.. :\
Yes, the server hook will check all commits on push if you push to an existing branch.
I guess you could do an interactive rebase to check them client-side first?
Even an interactive rebase won't run them, if the commit is done by the rebase command. So far I haven't found any better way than this:
git rebase -i origin/7.9
*mark every commit with "edit"* For every commit: *note the current commit id* > git reset HEAD^ > git commit -C <the noted commit id> *check and fix errors* > git rebase --continue
You don't need to reset; commit --amend runs the hooks. So the "For every commit" part can be simplified to
git commit -C HEAD --amend *check and fix errors* git rebase --continue
Tried that, but it got through for me:
git commit --amend
*just closed the editor that popped up* No modified files, so no updates needed. [detached HEAD f75c04d] Made it more explicit that we avoid yielding in bad places. 3 files changed, 55 insertions(+), 17 deletions(-)
I closed the editor instead of saying -C HEAD, but that shouldn't matter. I think the problem is "No modified files, so no updates needed."
Huh? The commit does not modify any files?
What error were you expecting, by the way?
Hmm, no, I'm confused. That message was from the editor. The hooks do get run, but they let it through.
I was expecting the foreign_ident check to trig there. It misses the file if I do --amend, but not if I reset and commit:
git commit --amend -C HEAD
[detached HEAD c531787] Avoid yielding to other threads in some places where the lvalue is temporarily cleared for single ref optimizations. 1 files changed, 16 insertions(+), 2 deletions(-)
git reset HEAD^
Unstaged changes after reset: M src/interpret_functions.h
git commit -a -C c531787
File src/interpret_functions.h has the foreign_ident attribute. Please remove it before commit.
Hm, could it be that "git diff --cached" compares the index to the old version of the commit, rather than to the parent (of both the old and new version) of the commit, when making an amend?
In that case, how can the hook know, and compare against the right version? Of course, the hook doesn't get any arguments at all, so it has to guess what's going on, as per usual in git land...
As a kluge I could check everything _again_ in the post-commit hook. At that time it is at least obivious (I hope!!!) what the new commit contains and which its parents are.
Well, it looks like there is no way in heck for the pre-commit hook to figure out that the commit is an amend, so we'll have to go with the kluge.
I also added a hook to check rebases (it can't actually stop the rebase at the error, but it can at least present them afterwards, so you know what commits to stop at in an interactive rebase).
To activate the new hook, you need to re-run githelper.pike after you pull it.
I guess the reasoning is that pre-commit should only concern itself about the new content being committed. What's in is already in, and it can't be thrown out. An amend is a special case of a rewrite, so it calls post-rewrite, which of course can warn about invalidness but not do anything about it.
So the bottom line is that pre-commit should check and stop the commit based on the index, and post-rewrite should warn, but post-commit has nothing to do with the committed content.
With your latest version I got some strange behavior: I amended without any change to check for the foreign_ident error. Then if I got it I removed the line in .gitattributes and amended again. Sometimes the .gitattributes change didn't get in at that point, instead I got "Removed foreign_ident from unchanged file foo". I had to reset HEAD^ and commit to get it in when that happened.
I also got "Unexpected output from git ls-tree" when check_ident was called for a file being deleted. I've pushed a simple fix for that, and I assume the githelper on the server needs to be updated with it before I can push my 7.9 tree. Or does that happen automatically?
[...], instead I got "Removed foreign_ident from unchanged file foo". I had to reset HEAD^ and commit to get it in when that happened.
Yes, because what the pre-commit hook saw was that you made a spurious change of .gitattributes, removing the foreign_ident attribute from foo without actually modifying foo itself, which is not allowed.
So this hiding of some of the changes hits you both coming and going, I'm afraid. What you can do is commit with --no-verify, which skips the pre-commit hook altogether. I think it still runs the post-commit hook, so you'll get the checks there.
[...] and I assume the githelper on the server needs to be updated with it before I can push my 7.9 tree. Or does that happen automatically?
It's automatic; there's a message to that effect displayed when you push githelper, but I guess it can get lost in the other line noise.
Speaking of forign idents: The CVS revisions are archived in the commit messages which gets a bit chatty.
I changed librarian a bit so that the revision messages are removed from the changelog and inserted after the filenames instead. Those are the (crev: X.Y) parenthesises on all the old checkins.
pike-devel@lists.lysator.liu.se
-
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter Bortas -
Peter Bortas ＠ Pike developers forum