I have changed the git ignore file to ignore *.suo
however I had a *.suo file which will not merge from one branch to
another because it is binary.
So i deleted it from the "merge to" branch thinking this would allow me
to merge and it would just be added
rather than a binary merge being ate
I only use Git to get the bleeding edge version of the project.
A little while ago I added someone's topic to review the files. It has
since been removed.
It modified one file in master.
Now, when I do a pull, I get a merge conflict.
Stashing it doesn't work.
How do I fix this?
--
You received
From: "Andrew Hardy" Sent: Tuesday, May
22, 2012 6:59 PM
I have changed the git ignore file to ignore *.suo
however I had a *.suo file which will not merge from one branch to
another because it is binary.
So i deleted it from the "merge to" branch thinking this would allow
me
You need to
one of the branches is a remote branch
I cannot find a way to delete the file on this branch
either in git / git win gui
or on github.com where the 'actual' remote repository resides.
What do you suggest?
On 22/05/2012 19:22, Philip Oakley wrote:
From: "Andrew Hardy" Sent: Tuesday, May
22, 20
ing binary files differ!!
Original Message
Subject:
Re: [git-users] Merge Conflict
Date:
Tue, 22 May 2012 23:06:30 +0100
From:
An
I put together this little script to show what I'm seeing.
The comments pretty much say what's going on. But in summary, how can I
get the merge conflict to go away? I'm surprised that the
add+commit+rebase --continue isn't enough to deal with that file.
#!/bin/bash
set -eux
set -o pipefail
ry files differ!!
Original Message
Subject:
Re: [git-users] Merge Conflict
Date:
Tue, 22 May 2012 23:06:30 +0100
From:
After moving a submodule in a development branch, I get a merge conflict
every time I merge changes up from the master branch. To resolve, I must git
add mysubmodule. How can I avoid resolving this conflict every time I merge
up? Here is a script which illustrates the problem:
cd ~/src
git
On Thu, May 11, 2023 at 11:02:44AM -0700, Dan Stromberg wrote:
> I put together this little script to show what I'm seeing.
>
> The comments pretty much say what's going on. But in summary, how can I
> get the merge conflict to go away? I'm surprised that the
> add+commit+rebase --continue is
On Monday, May 15, 2023 at 11:17:36 AM UTC-7 Konstantin Khomoutov wrote:
On Thu, May 11, 2023 at 11:02:44AM -0700, Dan Stromberg wrote:
> I put together this little script to show what I'm seeing.
>
> The comments pretty much say what's going on. But in summary, how can I
> get the merge co
On Monday, May 15, 2023 at 12:09:41 PM UTC-7 Dan Stromberg wrote:
On Monday, May 15, 2023 at 11:17:36 AM UTC-7 Konstantin Khomoutov wrote:
On Thu, May 11, 2023 at 11:02:44AM -0700, Dan Stromberg wrote:
> I put together this little script to show what I'm seeing.
>
> The comments pretty much
But in summary, how can I get the merge conflict to go away? I'm surprised
that the
add+commit+rebase --continue isn't enough to deal with that file.
It turned out I needed to:
2715 git add requirements.txt.m4
2716 git commit -m 'Merge conflicts' requirements.txt.m4
2717 git rebase --c
On Mon, May 15, 2023 at 03:22:09PM -0700, Dan Stromberg wrote:
> But in summary, how can I get the merge conflict to go away? I'm surprised
> that the
> add+commit+rebase --continue isn't enough to deal with that file.
>
>
> It turned out I needed to:
> 2715 git add requirements.txt.m4
> 27
Two clarifications -
On Tue, May 16, 2023 at 03:46:27PM +0300, Konstantin Khomoutov wrote:
[...]
> Ah, that might indeed easily explain the observed behavior: `git rebase`
> textually applies each commit from those your branch has compared to the
> "base" branch, one-by-one, and each application m
I have a site local repo and a remote repo.
Local repo contains the 1-2 month old content of remote repo.
I try to pull the whole content into local repo.
git pull origin master
From ssh://.../site.git
* branchmaster -> FETCH_HEAD
...
CONFLICT (add/add): Merg
From: Konrád Lőrinczi
To: git-users@googlegroups.com
Sent: Saturday, May 16, 2015 1:03 PM
Subject: [git-users] Merge conflict error, when there was no change in
mentioned file
I have a site local repo and a remote repo.
Local repo contains the 1-2 month old content of remote repo
rad
2015. május 16., szombat 14:37:28 UTC+2 időpontban Philip Oakley a
következőt írta:
>
>
> *From:* Konrád Lőrinczi
>
> *To:* git-...@googlegroups.com
> *Sent:* Saturday, May 16, 2015 1:03 PM
> *Subject:* [git-users] Merge conflict error, when there was no change in
>
kezőt írta:
>
>
> *From:* Konrád Lőrinczi
>
> *To:* git-...@googlegroups.com
> *Sent:* Saturday, May 16, 2015 1:03 PM
> *Subject:* [git-users] Merge conflict error, when there was no change in
> mentioned file
>
> I have a site local repo and a remote repo.
> Local repo c
ve the mode change, while the
post suggests it would.
Philip
- Original Message -
From: Konrád Lőrinczi
To: git-users@googlegroups.com
Cc: philipoak...@iee.org ; klorin...@gmail.com
Sent: Saturday, May 16, 2015 3:42 PM
Subject: Re: [git-users] Merge conflict error, when the
roblem? I note
> that your 'git status' (in the original post) didn't give the mode change,
> while the post suggests it would.
>
> Philip
>
>
> - Original Message -
> *From:* Konrád Lőrinczi
> *To:* git-...@googlegroups.com
> *Cc:* philip..
"Philip Oakley" writes:
> You may find that there are 'end of line' differences between the
> commits in the server, and the commits you have locally, which after
> eol conversion, look identical, but the different eol strings makes
> the sha1's different.
Yes, it's usually the case when files lo
I checked line endings in Notepad++ and both were unix.
Unfortunately I can not reproduce the problem anymore, as when I fixed the
problem I stepped to the next development problem.
sha1 compare and binary check are good idea for next time.
Thanks your help & ideas anyway,
Konrad
2015. máju
From: "Dale R. Worley"
"Philip Oakley" writes:
You may find that there are 'end of line' differences between the
commits in the server, and the commits you have locally, which after
eol conversion, look identical, but the different eol strings makes
the sha1's different.
Yes, it's usually th
"Philip Oakley" writes:
> I think in this case the byte by byte check was identical,including line
> endings, which made it all the more awkward to sort out. (detecting file
> mode changes!)
Oh, that's interesting. Internally, it means that the recorded hash for
files matches between versions,
Hi Philip,,
This is an area of interest to me, any headway on this?
I would suggest some extra output be added about *why* files conflict when
"git-merge" is run with -v
In the past I noticed not much difference between "-q, [nooption], and -v"
in the output.
--
Quentin
On Sunday, May 17, 2
Sent: Friday, December 04, 2015 4:24 PM
Subject: Re: [git-users] Merge conflict error, when there was no change in
mentioned file
Hi Philip,,
This is an area of interest to me, any headway on this?
I would suggest some extra output be added about *why* files conflict when
"gi
26 matches
Mail list logo
