Collaboration and excluding files [message #758611] |
Wed, 23 November 2011 16:20  |
Eclipse User |
|
|
|
Hi,
I'm trying to roll out git in the company i work for. We all use eclipse. I have experience using git from the command line, but I'm hoping to get a workflow in place that can be done entirely within eclipse, for ease of use.
i've run up against the following problem, which seems it must be a common one, but I've googled it to death to no avail.
Question is how to deal with files like .project and .settings/* that you want to ignore? There are two aspects to this problem:
1. Suppose Alice creates a project, shares it and pushes to upstream. Bob can then easily import the project as a whole, but as a result he has Alice's project settings, which is bad. But if Alice excludes the settings files when she shares her project, and does not push them to upstream, then Bob cannot import the project because Eclipse does not recognise it as being a project.
2. I can find no way of removing a file from source control while keeping the local copy. So if some project settings files, or other files that we want to exclude, get into source control by mistake, how could this be corrected? I've tried "untrack" and "ignore" but nothing seems to stop EGit from including a file in source control, and letting it be overwritten by a pull, however hard I try.
Am I just missing something obvious here, or is that kind of workflow just impossible without using the command line? Is there a more suitable way to conceive of what we are trying to do here? Any advice appreciated!
|
|
|
Re: Collaboration and excluding files [message #758837 is a reply to message #758611] |
Thu, 24 November 2011 11:54   |
Eclipse User |
|
|
|
> 1. Suppose Alice creates a project, shares it and pushes to upstream. Bob can then
> easily import the project as a whole, but as a result he has Alice's project
> settings, which is bad. But if Alice excludes the settings files when she shares her
> project, and does not push them to upstream, then Bob cannot import the project
> because Eclipse does not recognise it as being a project.
Most projects I know do share their .projects and .settings files. Sharing .projects and .classpath makes it easy to import the project into eclipse. Sharing .settings is useful to share compiler settings, source encoding etc.
> 2. I can find no way of removing a file from source control while keeping the local
> copy. So if some project settings files, or other files that we want to exclude, get
> into source control by mistake, how could this be corrected? I've tried "untrack"
> and "ignore" but nothing seems to stop EGit from including a file in source control,
Do you want to delete it in the repository but keep a local copy? This is done by "untrack". It corresponds to git rm --cached on the command line. You then have to commit the change and push it to the server. Anyone who then pulls the change from the server will get the deletion. She then would have to checkout the file from the previous commit to keep the local copy.
After that you should add the files to the .ignore file in the git repo, e.g. with the "ignore" command. You should commit the .ignore file. Then these files will not be presented in the EGit commit dialog or in the staging view anymore.
> and letting it be overwritten by a pull, however hard I try.
If the file is still in the remote repository there is no means in EGit to prevent it from being overwritten by a pull. I even do not know if that's possible on the command line. You would have to stash the local change before pull and so stash apply afterwards.
|
|
|
|
|
|
Re: Collaboration and excluding files [message #759614 is a reply to message #759290] |
Tue, 29 November 2011 05:59  |
Eclipse User |
|
|
|
Thanks Stefan, that explains it! I was going round in circles with that thinking it was me not getting it.
By they way the reason we need to keep .settings out of the repo is that we are doing Salesforce development and each dev will have their own bit of the cloud to compile their code in - and the individual config for this is defined in .settings so has to be different for each person. (Not sure about .project.) It is a different situation from collaborating on a Java proj.
Cheers
Naomi
|
|
|
Powered by
FUDForum. Page generated in 0.08006 seconds