Hmm... if that is the case, I feel like I am staring "into my own
future", reading up on the horrors that may await me ...
I assume you know about all the usual tricks of ignoring particular
files that are user-specific, such as workspace profile configurations,
in either Eclipse or IntelliJ. Those are also fairly easy to find on the
internet. (For example:
When I was doing a quick search I did notice some alternative project
configuration that is stored in the '.idea' directory which contains
multiple (smaller, simpler?) files. It might be worthwhile to try out
this new project configuration structure? May be it is easier to merge?
I don't quite see your problem.
Yeah ... I was mostly expressing frustration. I am a well known git fan.
My workflow is typically the following:
1. clone git repo (using commandline git client)
2. (in my case) import project into Eclipse. Just leave the project
files on the location they are now.
3. Set up run configuration with environment variables.
I am not using Eclipse and with IntelliJ I need to make changes to the environment in order for it to behave the way I need it to.
Then when I need to switch branches:
1. git checkout <branch/hash>
Result: code modified in place, Eclipse (with Git plugin) will adjust
Oh wow! I've never seen this actually happen :). I would *always* get conflicts on project files. Trying to make git ignore them has been a remarkable waste of time and at some point it always ends up attempting to merge them.
The same issues apply when moving through branches.
For completeness I have to say that I do a refresh in Eclipse. But of
course that only works if the checkout was successful.
The classpath file, a simple xml file, would often just merge changes.
And even if a conflict arises, it's typically just a manner of inserting
both or such.
or in case of getting new commits
1. git fetch
2. git rebase origin/master
Result: my current branch rebases to tip of Jitsi-branch
Same as above. Things never work out for me that way.
In the case where I do have changed files, I typically stash them
temporarily, switch branches and unstash them.
Except that I also get conflicts when unstashing ....
Also, I gnerally forget
that 'add'-ed files still get stashed if you do not use the
'--keep-index' argument. Other than this, it is mostly effortless.
I occasionally see a new jar library being added, but that does not
That's one of my main grievanes. Working on ice4j for example, irrevocably causes conflicts on ice4j.jar as soon as someone touches it in the repo.
The only way I can think of is creating a separate branch for this work,
and not updating that as often as you would a normal branch while you
are still working on a "big change".
When checking out another branch in git, you should not get conflicts,
since you are not combining different commits. Instead you're just
getting a different version of the project.
In the beginning I did do some additional configuration
in the Eclipse classpath file, but since that is XML it is easy to merge
by hand. Eclipse does not change the project file unless the project
configuration is actually changed, so this makes it easier.
Up to now a fairly pleasant experience.
I really and sincerely envy you!
It could just be that mine is a very short experience blessed with
ignorance. We'll just have to see
On 02/24/2014 05:17 PM, Emil Ivov wrote:
On 24.02.2014, at 00:20, Danny van Heumen <firstname.lastname@example.org> wrote:
On 02/23/2014 03:58 PM, Emil Ivov wrote:
Another more important question actually:
Are project files actually working for anyone? How do you handle
switching branches? How about attaching sources? Is this working for
anyone without having to constantly fight git?
On Sun, Feb 23, 2014 at 2:55 PM, Emil Ivov <email@example.com> wrote:
So I tried everything here but I am still having a hard time making
.git behave in a reasonable way. I've ignore the ipr and iml files
with .git/info/exclude and also "assume unchanged". That's not enough
apparently though because now I can't pull:
First, rewinding head to replay your work on top of it...
error: Your local changes to the following files would be overwritten
Please, commit your changes or stash them before you can switch branches.
On Fri, Jan 17, 2014 at 11:00 AM, Emil Ivov <firstname.lastname@example.org> wrote:
On 17.01.14, 09:44, Paweł Domas wrote:
On Fri, Jan 17, 2014 at 9:00 AM, Emil Ivov <email@example.com> wrote:
I am regularly having conflicts on project files such as .classpath
jitsi.ipr, jitsi.iml and others. As a result, sharing those files is
primarily a source of problems for me and causes me to waste more time
the occasional update of .classpath with new jars.
I haven't found reliable ways of making git ignore these files.
I am wondering what the best way to solve this would be. Kicking those
back into IDE specific directories is the first thing that came to my
There just scroll down to "Ignored versioned files" and this describes
how suspend/restore tracking changes in choosen files.
Suspend tracking changes:
git update-index --assume-unchanged path/to/file.txt
Restore tracking changes:
git update-index --no-assume-unchanged path/to/file.txt
I am quite sure I tried this too but also had problems there. I realize I am
not being helpful by saying what they were. I just don't remember. I'll try
this again soon and let you know.
dev mailing list
Unsubscribe instructions and other list options: