Home » Developing U++ » U++ Developers corner » external GIT clones differ in HASH --> problem when merging
| external GIT clones differ in HASH --> problem when merging [message #31591] |
Wed, 16 March 2011 17:43  |
 |
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
hi everyone,
using an own UPP git clone (from svn) for a cuple of months, maybe over a year now i noticed, that the SHA1 hashes differ, so when interchaning things later (pulling from someone's else tree) this will deffinitely make some problems. the hashes determine common history.
i cloned my repo long time ago, from googlecode, and it has the hash 5c79e9b795c796e852787a1d185c05cea3e776a2 as its first hash while the git repo listed in download section (gitorious) has 6abd54c7c1415955b79c152cfc132d42c3d615a8. both versions started from svn revision 281.. donno why. and donno why they differ. maybe it has to do with the autocrlf setting in .git/config.
i dont remember beeing able to view the svn history way down to 1. 281 was the first. why that? i also remember upp had a svn crash some not too long ago, maybe a few monts. and now, both googlecode and upp dev svn have svn history down to rev 1.
so when people are going to use git as their SVC and will clone the thing entirely, they wont be able to merge it with the tree from gitorious cause of hash mismatch.
can anyone clarify this up a bit what has happened to the svn history?
meanwhile a suggestion:
when doing 'git svn clone http://upp-mirror.googlecode.com/svn'
make sure that under windows, your git installation has been set to 'checkout windows style (crlf), commit unix style (lf)' which will set the autocrlf=true, and that it is not overridden in your .git/config.
then, the first hash has to be f84f01f3d6b42e00035494c9a86289eadeedc057
maybe i have cloned it from linux, that time. dont quite remember. but under linux, autocrlf=input needs to be taken, which is 'checkout as is, commit unix style'.
any further infos/suggestions on that?
[EDIT]
just double checked in linuzx, git svn clone produces the same f84f01f3d6b42e00035494c9a86289eadeedc057 hash as in windows.
so i suppose that the svn tree had changed twice  right?
[Updated on: Wed, 16 March 2011 18:02] Report message to a moderator |
|
|
|
| Re: external GIT clones differ in HASH --> problem when merging [message #31601 is a reply to message #31591] |
Wed, 16 March 2011 22:14  |
|
|
| kohait00 wrote on Wed, 16 March 2011 17:43 |
so i suppose that the svn tree had changed twice right?
|
Well, I remember only one change... Some time ago the mirror on googlecode had to be recreated from scratch, because it got out of sync with the main repository. There were some subsequent problems with it even when using subversion, so it doesn't really surprise me that git doesn't like it too
As for the last unexplained hash, I don't know. My guess would be the line endings are involved, as you already mentioned.
The reason why svn versioning used to start at 281 is probably because it was first synced to the mirror in some obscure way and alter, when it was recreated after the crash, it was just done properly, from revision 1...
Honza
|
|
|
|
| Re: external GIT clones differ in HASH --> problem when merging [message #31608 is a reply to message #31601] |
Thu, 17 March 2011 10:02 |
|
kohait00
Messages: 939
Registered: July 2009
Location: Germany
|
Experienced Contributor |
|
|
seems as if i found out why svn 281..
the comment to that revision states 'svn layout change', which has introduced trunk/branches/tags.
the offered git repo in downloads has, like i did, sure been created with
'git svn clone -s http://upp-mirror.googlecode.com/svn .'
where the -s stands for standard svn layout (trunk/branches/tags).
since the previous revisions 1-280 have not been using them, the clone ignores them.
i have used the same approach in http://www.ultimatepp.org/forum/index.php?t=msg&&th= 3486&goto=24387#msg_24387
but since the svn had to be rebuild, maybe the hash has changed, so i had another one than the one in gitorious.
now is the question, are the first revisions 1-280 worth it to be included in common history in git?
the problem is that it'd have to be checked out *without* the -s flag, which results in full history, but renders a git repo whit trunk/branches/tags folders. -s translates them to real branches and tags in git history..
i'd prefer to have a well running git history, the first 280 revs are not too important if you ask me.
so the current starting hash would remain the one in the public git repo from tojokey or andrejnikitin?
6abd54c7c1415955b79c152cfc132d42c3d615a8
cheers..
EDIT:
i tried both clones, with autocrlf = false (no changes) and autocrlf = input (changes) under linux, hash values are the same. even autocrlf = true under windows produced the same thing.
[Updated on: Thu, 12 May 2011 18:40] Report message to a moderator |
|
|
|
|
|
|
|
|
|
Goto Forum:
Current Time: Sat Apr 20 17:20:43 CEST 2024
Total time taken to generate the page: 0.04409 seconds
|
Members
Pages
Help
Register
Login
Home
