Git status bothers me about untracked files:
# Untracked files: # (use "git add <file>..." to include in what will be committed) # # src/modules/Gz/zlib_machine.h.in # src/modules/Pipe/config.h.in # src/modules/SANE/config.h.in # src/modules/_Image_GIF/config.h.in # src/modules/_Image_JPEG/config.h.in # src/modules/_Image_TIFF/config.h.in # src/modules/_Image_XFace/config.h.in # src/modules/_Regexp_PCRE/pcre_machine.h.in # src/post_modules/_ADT/config.h.in # src/post_modules/_Image_SVG/config.h.in
Turns out that the patterns for these files in .gitignore have trailing whitespace, something cvs apparently ignored but git does not.
It'd be nice if the conversion had taken care of this, but I guess the only option now is to correct the patterns at the branch heads?
We could use git filter-branch to cleanup the .gitignore files, but that would mean new commit ids for all commits.
And that everyone must rebase their work. If we are to go through all that hassle, it's probably best to wait a while and see if there are more adjustments to do. Otoh waiting means that more commit ids find their way into commit messages and other places. :\
Git still doesn't record the tip in the last rebase (or merge), but instead tries to calculate which commits are different all the way up to the common ancestor. If the roots aren't the same I don't think it can rebase without --onto. And even if they share a commit somewhere far back, my experience is that it can easily snag on some old commit along the way, and one will end up with a complete mess. So I'd use --onto in any case.
Not that it's particularly difficult or anything, but it requires a bit of coordination so that people don't push any old branch tips and thereby pushes the whole old repository back in.
Hmm, interesting. I wonder how it works when there have been fetches without rebases earlier. Are there docs anywhere on this?
I've always found it a bit annoying that there's no variant of git pull that skips the network and just updates the local branch from the remote tracking one, using the same branch tracking settings. When I have a bunch of branches I want to pull, there's no sense in querying the server once for each of them. I want to make myself a script that only skips the fetching but otherwise works the same.
Don't know about documentation; I simply read the source of git-pull, which is a shellscript, to figure out how it works. :-)
And that everyone must rebase their work. If we are to go through all that hassle, it's probably best to wait a while and see if there are more adjustments to do. Otoh waiting means that more commit ids find their way into commit messages and other places. :\
Mast identified another problem earlier today; git fsck complains about the timezone offsets. This is due to a bug in my converter.
Spot the bug:
write("# Committing %s\n" "commit refs/%s\n" "mark %s\n" "author %s <%s> %d %+04d\n" "committer %s <%s> %d %+04d\n" "data %d\n" "%s\n", uuid, main_leaf[..<1], git_id = new_mark(), author_info[0], author_info[1], timestamp, atz, committer_info[0], committer_info[1], commit_timestamp, ctz, sizeof(message), message);
People have been good about not writing git-hash-crap in the logs, so a reexport shouldn't be too painful.
Hopefully, at least. But with a re-export you would have to re-import any changes already made afterwards. And you would have have to re-validate everything again since it would be a new import from scratch. So it seems like a worse way to do it.
Of course, you could do both and verify that you actually do get the same end result (which should only amount to comparing the SHA:s of the heads and tags)...
Hopefully, at least. But with a re-export you would have to re-import any changes already made afterwards. And you would have have to re-validate everything again since it would be a new import from scratch. So it seems like a worse way to do it.
Maybe.
Of course, you could do both and verify that you actually do get the same end result (which should only amount to comparing the SHA:s of the heads and tags)...
True.
Before we do anything about it, I'd like to know if there are any other known conversion bugs with the Pike git repository than:
* The TZ offsets are three decimals when they should be four. - git-fsck complains about ~ all commits. - Some third party git tools may get confused.
* The automatically generated .gitignore files contain extraneous whitespace at EOL in some cases. - Files that are supposed to be ignored by git aren't.
In particular, do any of the email addresses or author names need to be adjusted?
On Thu, Oct 28, 2010 at 08:30:03AM +0000, Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum wrote:
In particular, do any of the email addresses or author names need to be adjusted?
peter bortas is listed with 2 email addresses: bortas.org lysator.liu.se and there is a root at bernard.roxen.com that looks odd
greetings, martin.
On Thu, Oct 28, 2010 at 08:30:03AM +0000, Henrik Grubbstr�m (Lysator) @ Pike (-) developers forum wrote:
In particular, do any of the email addresses or author names need to be adjusted?
peter bortas is listed with 2 email addresses: bortas.org lysator.liu.se
Are you sure? I only see bortas.org.
the place i checked was the user list at the librarian site.
but i didn't think to check for actual commits, i just asumed the list of users would be for the pike repository only.
so you are right, only bortas.org in the pike repository: http://pike-librarian.lysator.liu.se/index.xml?m=pike.git&starttag=&...
turns out i messed up the list in the editor too,
below are some real name duplicates.
however, i don't think they are worth fixing. they are all changes from one address to another, and with git more such changes will eventually happen anyways. people just need to pay attention to what name/address they set in their local git repository.
Artur Skawina (changed from o2.pl to gmail.com) http://pike-librarian.lysator.liu.se/index.xml?checkins=915070e069e605c8fb7a... http://pike-librarian.lysator.liu.se/index.xml?checkins=556e6b301b76fd25d2f0... btw: it seems like this link hangs the librarian, or at least ever since clicking this link, the librarian got very slow :-(
Marcus Comstedt (latest commit from mc.pp.se, all others from pike.ida.liu.se) http://pike-librarian.lysator.liu.se/index.xml?checkins=d3f9dc694fc4d59babef... http://pike-librarian.lysator.liu.se/index.xml?m=pike.git&starttag=&... (the permalink for this one is way to long)
Per Hedbor (changed from pike.ida.liu.se to opera.com) http://pike-librarian.lysator.liu.se/index.xml?checkins=ec431f4edae907a8d54d... http://pike-librarian.lysator.liu.se/index.xml?m=pike.git&starttag=&...
Stefan Wallström (changed from pike.ida.liu.se to roxen.com) http://pike-librarian.lysator.liu.se/index.xml?m=pike.git&starttag=&... http://pike-librarian.lysator.liu.se/index.xml?checkins=daa35e8c6429932a0788...
greetings, martin.
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Bähr -
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum