Eclipse Community Forums: EGit » Forcing merge to accept "new" version from repository

Home » Eclipse Projects » EGit » Forcing merge to accept "new" version from repository(Forcing merge to accept "new" version from repository)

Show: Today's Messages :: Show Polls :: Message Navigator

Forcing merge to accept "new" version from repository [message #783156]

Wed, 25 January 2012 02:25

Jouk Jansen
Messages: 3
Registered: January 2012

Junior Member

Hi All,

I'm using jgit as a stand-alone application on a OpenVMS system. The filesystem on this machine does not allow files without a "." So when I perform a "jgit clone" files like NEWS become NEWS. So far so good
However these files give a problem when trying
jgit fetch
jgit merge "origin/master"
Later and the file NEWS is changed in the repository (and not in the loval copy). I get than messages that there is a conflict.
How can I force jgit to accept the new versions from the repository for these files?

Jouk

Report message to a moderator

Re: Forcing merge to accept "new" version from repository [message #783206 is a reply to message #783156]

Wed, 25 January 2012 04:36

Christian Halstrick is currently offline

Christian Halstrick
Messages: 18
Registered: July 2009

Junior Member

A filesystem not accepting files without a '.'? How will this work at all for all the
files which git writes into the .git directory? E.g. all the refs, object files - they all don't have a '.'. Will the filesystem at least find the file if I specify the filename without the '.'? If I search for the file './.git/refs/heads/master' will it find './.git/refs/heads/master.' And will the java.io.File object tell me that the name of the file is 'master'? If not I doubt that you can run jgit on top of this filesystem.

If yes, there are still problems. What is if the git repo contain two files which differ only in a trailing '.', e.g. 'content' and 'content.' . JGit would not be able to checkout these two file into the same working-tree. Maybe the case you describe is of that kind: originally there was only 'NEWS' but somebody on OpenVMS added a 'NEWS.' because that is what he saw in his filesystem. Could that be?

Report message to a moderator

Re: Forcing merge to accept "new" version from repository [message #783217 is a reply to message #783206]

Wed, 25 January 2012 04:56

Jouk Jansen
Messages: 3
Registered: January 2012

Junior Member

How it works on OpenVMS
if you open/create a file (i.e master) the actual file created/opened is master.
If you later request a list of files master. is returned and not master

So as long as you do not try get files from directory list but access the directly using the name with/or without the dot it both filenames point to the same name. In principle this may give problems if the remote repo contains both files with and without the dot.

The problem is that git merge apperently matches the names in the remote repo and the local copy and reads the former as master and the latter as master., which results in a conflict. Note that after jgit clone, nothing was changed in the local copy on the OpenVMS side.

The problem never occurs in the .git directory, there the files are only created/opened and are "tranlated" to valid openVMS names by Java (actually not java but an extra language independend OpenVMS layer).

Jouk

Report message to a moderator

Re: Forcing merge to accept "new" version from repository [message #783286 is a reply to message #783217]

Wed, 25 January 2012 07:31

Christian Halstrick
Messages: 18
Registered: July 2009

Junior Member

What I don't understand is: you solved this problem for the .git folder by some layer doing translation. But why doesn't the same layer does this magic also for the working-tree files?

Regarding merge I can only guess what has happened: During merge we first try to merge together the two given commits. As long as we don't have to do a real content-merge (for a single file producing new content containing changes from both commits) we don't touch the filesystem but store everything in the index. If this step is over we checkout what we have prepared in index. This will copy what is in index to the filesystem. Before we copy we check that you have not locally modified the file because otherwise we would silently overwrite your changes (something git never does). For that check we list what's in the working tree. If your filesystem tells us there is only a file "NEWS." but no file "NEWS" anymore then we are in trouble. It looks like you have deleted the file "NEWS" locally and this deletion conflicts with the modification which was done remotely. Who should win: the modification or the deletion? Git can't decide - that's a conflict. Even if you would do the merge with a different strategy (e.g. THEIRS: always take what comes from the other branch and throw away what I have) the problem still persists: When we want to checkout we think your working tree file is dirty (locally deleted).

To have a better guess could you please tell whats in MergeResult.getConflicts() and MergeResult.getFailingPaths.

Report message to a moderator

Re: Forcing merge to accept "new" version from repository [message #784205 is a reply to message #783286]

Fri, 27 January 2012 02:38

Jouk Jansen
Messages: 3
Registered: January 2012

Junior Member

I did not solve anything for the .git drectory, because the interface java and the filesystem takes care of all the translations from java to the filesystem

What I think is that jgit uses during a merge a some sort of directory listing is used and not an attempt to access the file and that listing the file with a "." is listed and is assumed to be a "new" file and the file without the dot is not present on the listing.

For VMS in principle it works like this:
-java tries to acccess a file
file name is tranlated to something suitable for the file system (ODS5)
If you compare in this situation the original filename with the one actual written
you will detect a difference

Note that when only files of the form <filename>.<ext> are changed every thing works fine with merge.

Jouk

Report message to a moderator

Re: Forcing merge to accept "new" version from repository [message #786381 is a reply to message #784205]

Mon, 30 January 2012 05:53

Christian Halstrick
Messages: 71
Registered: July 2009

Member

your guess is right: jgit will do a directory listing during checkout to find out (among other things) about new/deleted files. A merge includes a checkout - that's why you see this problem. In detail we trigger the directory listing through a java.io.File.listFiles() call in [1]. After we have all the File objects we ask them for their name with java.io.File.getName in [2]. If the getName() call returns "NEWS." for a file which was added to git with name "NEWS" (maybe the file was added to the repo on a linux box and you just cloned to your VMS) then jgit will think the file "NEWS." is new and "NEWS" has been deleted in the filesystem. I see your
problem but I don't know how to solve it. Especially when I think about repos containing both: "NEWS" and "NEWS.". Do you have any ideas?

[1] https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/treewalk/FileTreeIterator.java#n133
[2] https://git.eclipse.org/c/jgit/jgit.git/tree/org.eclipse.jgit/src/org/eclipse/jgit/treewalk/FileTreeIterator.java#n174

Ciao
Chris

Report message to a moderator

Previous Topic:	Exception on Push to github repository
Next Topic:	History of selected resource broken?

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Sat May 18 04:52:48 EDT 2013