Community
Participate
Working Groups
Even though some git operations, which modify working tree, index or local repository, are implemented as idempotent, we should be careful about calling them multiply times (retrying) in case a repository state has changed in the meantime. Eg. "git add" is currently implemented as PUT on /git/index/..., so retrying this call seems to be safe, unless the index has been modified, for instance on a different browser tab. A synchronization token would allow us to detect such situation and at least warn the user. The token could be very similar to ETag for bug 338121, bug 338122 and bug 339846.
See also bug 335195 for detecting conflicts for files.
Even more important would be a way to detect that the index looks different than what the git-status.html page has last seen, and abort the commit in that case.
My fix to the last issue (aborting commit when index file was modified in the meantime): https://github.com/pjanik/orion.server/tree/bug339848 https://github.com/pjanik/orion.client/tree/bug339848 I wrote all this code and have the rights to contribute it to Eclipse under the eclipse.org web site terms of use.
Update: fixed issue connected with pushing changes to remote repository, when commit history on the log page is out of sync.
'push' on git-log consults ETags as well as 'commit' on the git-status page. You need to fix 'push' on the git-status still.
Right, fixed.
It works, but something is wrong with the approach. For instance when you are doing a commit i.e. POST /git/commit you pass ETag for status (not commit) in the "If-Match" header. I know it is a more complicated case than regular files, but I would expect to use ETags of the same resource in "If-Match".
So, what is "commit ETag"? A hash of commit history? It's not enough to make safe commit, as state of index is also important (and imo even more important than commit history in this case). So, I've named this "StatusETag", as it combines state of index and state of commit history ("status" because it is what we can see on the status page and it's returned by StatusHandler). I think that we can't limit this ETag only to commit resource. And because of that, I've created another helper class with methods for generating ETags, as one ETag contains information about state of two resources (index and commit). Ofc I can change names from "StatusETag" to "CommitETag", and from "CommitsETag" to "CommitHistoryETag" if this would change anything. In this case, StatusHandler would return "CommitETag". Always there would be that kind of conflict, as StatusHandler returns etag, which is passed to CommitHandler. ;)
Hmm. I can't see any StatusETag or CommitETag in responses from the server. There are just ETags. I don't care what are method names on the server, but what is returned in responses. And AFAIK it is always ETag in status and commit resources. My point was that when I'm doing GET on a resource and I get ETag, I would expect to use this ETag for other operations on the same resource, like we do for files. It would be easier to address the ETag issue if the commit was an operation on the status resource. We would get a status with some ETag and then POST on the status would do the commit. If the status was changed in the meantime, we would get 412. However our current approach is that we do POST on commit to commit the index. If commit ETag is computed only using the log, it is not enough here, I agree. We would need to take into account the index state too. But it would not work for GET on commit for getting the log. I mean we would call GET on commit, then index is changed and another GET on commit would return the full response instead of 304. I don't know what the right solution is here. I'm waiting for suggestions.
post 0.3.
Not going to work on it.
