Hi all,
The reason why I (and others, eg CDT) started using "loose version specifiers"
and composite repos was,
That we wanted to avoid the manual task of editing our versions in the B3
editor with every contribution.
I was not aware of the recommendation to use explicit versions so far.
So if
David,
For a while now I've been having trouble switching my simrel branch. I thought
it was just my system, but tried from another system recently. Any attempt to
switch to the Juno_maintenance branch is giving me:
"error: Your local changes to the following files would be overwritten by
che
Ok. got past it again by "unstaging" the file. and was able to checkout the
Juno branch, but it should still probably be looked into.
-Eric
On 18/01/2013 2:14 PM, Eric Gwin wrote:
David,
For a while now I've been having trouble switching my simrel branch. I thought
it was just my system, but
FWIW I have the very same issue, so sth is probably wrong in the git repo
itself indeed...
Benjamin
Eric Gwin a écrit :
Ok. got past it again by "unstaging" the file. and was able to checkout the
Juno branch, but it should still probably be looked into.
-Eric
On 18/01/2013 2:14 PM, Eric Gw
Hi
This is standard GIT protection for edited files.
As the message says you must either preserve of lose the changed files.
To lose it/them just replace all files shown in the Staging View by
HEAD. Then you're good to go.
Regards
Ed Willink
On 18/01/2013 21:45, Benjamin Cabé w
Another factor, sometimes the b3 aggregator editor will change a file,
that you did not purposely edit. Especially if you edit "simrel.b3aggr".
This too is expected behavior, because under some conditions the
aggregator (or, EMF) must "save the model" ... and "the model" is
represented by all t
Le 18 janv. 2013 à 22:54, Ed Willink a écrit :
> Hi
>
> This is standard GIT protection for edited files.
Sure, but neither git checkout -- soa-bpel.b3aggrecon, git stash, git reset
--hard, or even git clean -d -f seem to restore the file back in its HEAD
state…
Benjamin
_
That sounds like your Git client is normalizing line endings in this file.
Does "git diff" show any non-whitespace differences? This can happen when
different clients from different platforms (Win, Mac, Linux) have inconsistent
autocrlf settings.
The only solution I know of is to check the fi
Hi,
I understand that the message is usually a standard Git protection to keep me
from inadvertently overwriting edited files. However, my point is I haven't
edited the file. Ever. It "comes" edited when the repo is cloned. Therefore, I
surmise that the file is, in fact, corrupt in the repo, an
Do people who always have to "deal with the consequences" use Windows?
Linux? Mac?
Do they use EGit or command line?
I ask, since I do not see the problem you describe, using Linux and EGit.
But, I did look closely at the file, and see that it had mixed line
endings (some "windows" CRLF and
David,
Perhaps EGit "helps out" so you didn't see the issue. I typically work directly
from the Git command-line or use GUI tools, like TortoiseGit, or SourceTree.
All three reported the issue. None of the other Git repos I use have ever
gotten into that state. At least one of them is fairly ac
David,
I'm not sure it's good advice to suggest autocrlf=false. The problem
is, if the wrong endings are contributed by some tool, they'll end up
pushed to the actual repo in that incorrect form (the repo itself must
use \n) and then when anyone pulls, they'll end up with those wrong
endings
12 matches
Mail list logo
