Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.gitignore files get lost #85

Closed
ohumbel opened this issue Nov 30, 2015 · 8 comments
Closed

.gitignore files get lost #85

ohumbel opened this issue Nov 30, 2015 · 8 comments
Assignees
Labels
Milestone

Comments

@ohumbel
Copy link
Member

ohumbel commented Nov 30, 2015

Today I had the shock of my life...

Well not really, but quite a shock: A colleague told me that the migrated git repository misses .gitignore files.

Debugging the whole migration showed that we follow the lifecycle of .jazzignore/.gitignore absolutely perfect. But nonetheless, at the end of the migration all .gitignore files were absent.

Debugging twice again - and focussing on the removal of .gitignore files - showed this in the console:

11:14:48 - Accepting: 22404: Enterprise LOGIN: Create enterprise repository - created ant/build xml (Date: 2013-11-14 13:33:14, Author: Tanner Markus, Revision: _0ksH0k0oEeOFO7Ms2bLlhg, Component: _81p5sDJnEeOq9PDTyN2FkQ, Accepted: False)
11:14:48 - Executed Command: "lscm accept -v -o -r https://rtc.bison-group.com/ccm/ -t HUO_Migrate_EMS3 --changes _0ksH0k0oEeOFO7Ms2bLlhg" --> /home/huo/gitrepos/ohumbel/rtc2git/Logs/accept.txt
11:14:48 - Executed Command: "git diff --quiet"
11:14:48 - Start (re)loading current workspace: lscm load -r https://rtc.bison-group.com/ccm/ HUO_Migrate_EMS3 --force
11:14:48 - Executed Command: "lscm load -r https://rtc.bison-group.com/ccm/ HUO_Migrate_EMS3 --force"
The following resources had uncommitted changes and were overwritten:
  A copy of each file is available in "/d500/rtcmigrated/migrate_EMS3/EMS3/.jazzShed/b15-11-30_11.14.49.595".
    /EnterpriseConsole/.gitignore
    /EnterpriseMgmtService/.gitignore
    /EmsPersistence/.gitignore
Successfully loaded items into the sandbox.
11:14:49 - Load of workspace finished
11:14:49 - Accepted change 11/498 into working directory
11:14:49 - Executed Command: "git status --untracked-files=all -z"
@ohumbel ohumbel added the bug label Nov 30, 2015
@ohumbel ohumbel self-assigned this Nov 30, 2015
@ohumbel ohumbel added this to the 1.2 milestone Nov 30, 2015
@ohumbel
Copy link
Member Author

ohumbel commented Nov 30, 2015

A quick first analysis: We have to reload --force the RTC workspace, because an accept not always arrives in the local filesystem (these cases are detected by git diff --quiet). Such a reload seems to copy the .gitignore files into .jazzShed/.

@WtfJoke
Copy link
Member

WtfJoke commented Nov 30, 2015

Yeah I know. I have seen that by the logfile you provided.
A simple solution would be to create the gitignore file later, after the loading of the workspace. Cause once its commited, it wont get lost anymore.

EDIT: This will be always a problem on every force reload.... Not sure how to avoid it.

@ohumbel
Copy link
Member Author

ohumbel commented Dec 1, 2015

Exactly.
Because .gitignore is not known to RTC, it will always be removed on force reload, regardless of the git status. In my case everything was already committed to git...

My strategy is to:

  • catch the output of the force command
  • detect if something was moved to .jazzShed
  • if yes, copy all the .gitignore files back from there

@ohumbel
Copy link
Member Author

ohumbel commented Dec 1, 2015

Or - better - check them out from git again.
This is probably the safer way.

@ohumbel
Copy link
Member Author

ohumbel commented Dec 1, 2015

Thanks @reinhapa for bringing me back to the safe path!

The implementation will be as follows:

  • detect a reload --force
  • scan all deletions (from the output of git status -z)
  • for all .gitignore files that were deleted and have a sibling .jazzignore file: git checkout -- gitignorefilename
  • update git status -z if necessary

@ohumbel
Copy link
Member Author

ohumbel commented Dec 1, 2015

This was a hard nut to crack.
Pull request #86 fixes it.

@WtfJoke
Copy link
Member

WtfJoke commented Dec 1, 2015

Or - better - check them out from git again.
This is probably the safer way

Great Idea! Didnt think about that. Nice one! 👍 👌

@ohumbel
Copy link
Member Author

ohumbel commented Dec 4, 2015

PR #86 is now updated with new tests.
The sibling check was missing. This could lead to very strange errors.
Now I am confident that this issue is really solved 😉

@WtfJoke WtfJoke closed this as completed in 31e77d6 Dec 7, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants