Exception File has been modified

[spyropoulosl]

Hello I'm getting this when I try to gitcc checkin

Exception: File has been modified: package/className.java. Try rebasing.
Full traceback:

> cleartool unco -rm package/className.java
Traceback (most recent call last):
  File "d:/tools/git-cc/gitcc", line 48, in <module>
    main()
  File "d:/tools/git-cc/gitcc", line 14, in main
    return invoke(cmd, args)
  File "d:/tools/git-cc/gitcc", line 38, in invoke
    cmd.main(*args)
  File "d:\tools\git-cc\checkin.py", line 44, in main
    checkout(statuses, comment.strip(), initial)
  File "d:\tools\git-cc\checkin.py", line 88, in checkout
    stat.stage(transaction)
  File "d:\tools\git-cc\status.py", line 31, in stage
    t.stage(self.file)
  File "d:\tools\git-cc\checkin.py", line 133, in stage
    raise Exception('File has been modified: %s. Try rebasing.' % file)
Exception: File has been modified: package/className.java. Try rebasing.

When I do rebase I get no updates.Is there something I am missing?

[charleso]

Hi Leonidas,

Hmm. So that warning is part of the 'safety' protocol of git-cc that makes sure that the last revision of a file in Git matches the current version of the file in Clearcase. This is to make sure that as git-cc replays your commits in Clearcase that it doesn't accidentally override something.

I would look at the Clearcase history of package/className.java and see if the last commit matches what is in Git. If it does, or in any case, what you can do is check out the git_cc branch, which is where the last sync was from, copy the latest version of that file, commit and then rebase master. That will ensure that you've resolved any merge conflicts and don't lose any changes.

I'm also curious why the rebase isn't picking up changes from Clearcase. git-cc works purely off the timestamp. If you get the timestamp of the git_cc branch commit, and then run cleartool -since $TIME package/className.java. Does it return what you expect?

Finally, as a work around you can do --force, but I really wouldn't recommend that.

Good luck, and let me know how all that goes.

Charles

[spyropoulosl]

I didn't understand the fix you propose if the ClearCase history matches the Git history.

What I noticed though is that the command:

$ git log -n 1 --pretty=format:%ai master_cc
2013-10-29 18:24:13 +0000

and when I do a gitcc rebase --stash the timestamp is 1 second different:

$ gitcc rebase
> git ls-files --modified
> git log -n 1 --pretty=format:%ai master_cc
> cleartool lsh -fmt %o%m|%Nd|%u|%En|%Vn|%Nc\n -recurse -since 29-Oct-2013.18:24:14 .

As it stands at the moment I can't commit my changes to package/className.java file. I haven't tried the gitcc checkin --force action yet but I would like to eliminate any other possible solution first (and maybe help resolve a bug)

[charleso]

Hi Leonidas,

That extra second is intentional. You don't want to re-add the changes that already exist in Git.

What is the output from running cleartool lsh from above? Or looking at the history tree for that matter?

To work around the issue (and not use --force-) you can take the contents of the className.java file and override the contents in Git you can trick git-cc into thinking it rebased the correct contents. Something like (maybe back up your Git repository before running any of these commands):

git checkout git-cc
cleartool update /view                                                                 # make sure we have the latest
cp /view/package/className.java /git/package/className.java
git add .
git commit -C HEAD                                                                   # Use an old timestamp so we don't miss anything else
git rebase git-cc master
git branch -f git-ci git-cc                                                              # git-cc is the place where we last pushed from, which I'm assuming is equal to git-cc

This is essentially what git-cc does anyway, but without keeping the history. It would be nice to know why lsh isn't picking up the changes. The problem will most likely be that the last commit on master_cc will be after the change to className.java, and thus are no longer picked up.

You could also 'go back in time' and rebase again to see if it managed to pick up the changes.

git branch -f git-cc COMMIT_BEFORE_CHANGE                        # find out when the history diverged, and go back to a commit before that happened
git rebase --onto git-cc git-ci master                                            # you need to be on master for this stunt to work
git branch -f git-ci git-cc
git-cc rebase                                                                             # fetch from an older point in time

I hope this is somewhat helpful.

Charles

[spyropoulosl]

Hi Charles,

That is useful as general knowledge. I eventually rebase the whole repository again and applied my changes. I think it could be related to line endings. I know that by default the gitcc use autocrlf=false but my IDE (Intellij Idea) keeps on asking to "fix" this to autocrlf=true. I stopped IDEA of making line-endings for GIT and keep them as is (from ClearCase).

Is it possible to leave this ticket open for some time (~1 week) to confirm it's working?

Leonidas

[charleso]

Hi Leonidas,

Doh! Of course - line endings is the other possibility. I never got around to fixing this problem. It was always easier/safer to not mess with line endings. If you could stick with autocrlf=false that will certainly make your life easier.

You're welcome to keep this ticket open. Let me know how you go.

Cheers,
Charles

[spyropoulosl]

Seems like the line endings was the problem so I can close this. Thanks!