Re: [git-users] Merge conflict not going away

[Konstantin Khomoutov]

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 may fail due to conflicts.

"Textually" means that the changes introduced by a commit are tried to be
applied as a textual patch represneting those changes - basically, as if you'd
do `git show` on that commit followed by `git apply` of its results.

> (I cannot fathom any non-far-fetched reason to commit a file which is in a
> conflicting state)

I mean, by default Git inserts the so-called conflict markers into each
text file with conflicts - changing the contents of those files in a way that
"breaks" the syntax of such contents. To bring an example, a Dockerfile with
conflict markers won't be successfully processed by `docker build`. Hence I
fail to see what such committing would be useful for - except as a way to
"transfer" such conflicting state somewhere a human being would deal
with the conflicts, thus restoring the syntactic correctness of the files
involved.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/20230516151005.4sjahvf7kj3r44wr%40carbon.

Re: [git-users] Merge conflict not going away

[Konstantin Khomoutov]

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
>  2716  git commit -m 'Merge conflicts' requirements.txt.m4
>  2717  git rebase --continue
>  2718  cp ../../requirements.txt.m4 requirements.txt.m4
> ...multiple times, after the initial git rebase.
> 
> Speculation: Could this be because there were multiple changes to that file?

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 may fail due to conflicts.

I honestly have no idea what exactly you are trying to achieve (I cannot
fathom any non-far-fetched reason to commit a file which is in a conflicting
state) but I think the easiest fix would be to somewhat reverse your workflow:
instead of rebasing you could go with a "squash merge".
Basically, instead of doing `git rebase master`, you could do

  git reset --hard master # this would save the current HEAD as HEAD@{1}
  git merge --squash HEAD@{1}
  git commit -a -m 'Merge conflicts'

A "squash merge" produces a single commit out of any set of changes which are
about to be merged, so you're going to get a single conflict no matter what
(well, except if here's simply no difference to be merged in the first place).

Note that the approach just demonstrated relies on the so-called "reflog" to
be turned on, which is always the case for "normal" repositories unless
explicitly turned off.


I would also suggest to look at `git rerere` - may be this is a more suitable
tool for your use case.

> We were also wondering if the 'git commit' was strictly necessary.

If we're talking about a merge conflict in a middle of a rebase operation,
then no, it suffices to mark all outstanding conflicts as resolved (`git add`
is one way of doing so) and then continue rebasing.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/20230516124626.vzfoyr2ptvn44ic5%40carbon.

Re: [git-users] Merge conflict not going away

[Dan Stromberg]

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 --continue
 2718  cp ../../requirements.txt.m4 requirements.txt.m4
...multiple times, after the initial git rebase.

Speculation: Could this be because there were multiple changes to that file?

We were also wondering if the 'git commit' was strictly necessary.

Thanks!

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/53a83d8c-e8c5-4073-b2f3-06c0a8cd29dfn%40googlegroups.com.

Re: [git-users] Merge conflict not going away

[Dan Stromberg]

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 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. 

Hi, Dan!

Hi Konstantin.
 

I cannot reproduce it on Linux/amd64 with Git 2.39.2

Maybe I should try upgrading.

I'm using git version 2.34.1 on an Ubuntu  22.04.1 LTS virtual machine.


I upgraded to git 2.40.1 
using  https://tecadmin.net/how-to-install-latest-git-on-ubuntu-22-04/ , 
but I'm still seeing the same problem.

I suppose that means the problem stems from something in my commit history?

Anyway, here's partial output from the script I posted (modified slightly 
to get the updated version of docker/requirements.txt.m4 from .. instead of 
/tmp) :

+ cp ../requirements.txt.m4 docker/.
+ git add docker/requirements.txt.m4
+ git commit -m 'Dealt with merge conflicts' docker/requirements.txt.m4
[detached HEAD 50537f7] Dealt with merge conflicts
 1 file changed, 3 insertions(+), 1 deletion(-)
+ git rebase --continue
dropping 03004b1fb98ce23b134a250319f925e76a955b95 add git to prod images -- 
patch contents already upstream
Auto-merging docker/requirements.txt.m4
CONFLICT (content): Merge conflict in docker/requirements.txt.m4
error: could not apply 921af1e... Merged conflict resolved
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm ", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git 
rebase --abort".
Could not apply 921af1e... Merged conflict resolved

Does that say anything relevant?

Thanks :)

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/5467f11d-672f-407f-8d28-7c57e60c5034n%40googlegroups.com.

Re: [git-users] Merge conflict not going away

[Dan Stromberg]

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 conflict to go away? I'm surprised that the 
> add+commit+rebase --continue isn't enough to deal with that file. 

Hi, Dan!

Hi Konstantin.
 

I cannot reproduce it on Linux/amd64 with Git 2.39.2

Maybe I should try upgrading.

I'm using git version 2.34.1 on an Ubuntu  22.04.1 LTS virtual machine.

Thanks for the response!

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/cd2d7c22-1adf-4a7c-8325-67a20ae91b1an%40googlegroups.com.

Re: [git-users] Merge conflict not going away

[Konstantin Khomoutov]

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 isn't enough to deal with that file.

Hi, Dan!

I cannot reproduce it on Linux/amd64 with Git 2.39.2 - I have run the
following commands in a freshly initialized repo:

8<
$ echo aaa > aaa.txt
$ git add aaa.txt
$ git commit -m 'aaa'
[master (root-commit) 6928baf] aaa
 1 file changed, 1 insertion(+)
 create mode 100644 aaa.txt

$ git checkout -b foo
Switched to a new branch 'foo'

$ echo bbb > aaa.txt
$ git add aaa.txt
$ git commit -m bbb
[foo b38fda8] bbb
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git checkout -
Switched to branch 'master'

$ echo xyzzy > aaa.txt
$ git add aaa.txt
$ git commit -m xyzzy
[master a819c04] xyzzy
 1 file changed, 1 insertion(+), 1 deletion(-)

$ git checkout -
Switched to branch 'foo'

$ git rebase master
Auto-merging aaa.txt
CONFLICT (content): Merge conflict in aaa.txt
error: could not apply b38fda8... bbb
hint: Resolve all conflicts manually, mark them as resolved with
hint: "git add/rm ", then run "git rebase --continue".
hint: You can instead skip this commit: run "git rebase --skip".
hint: To abort and get back to the state before "git rebase", run "git rebase 
--abort".
Could not apply b38fda8... bbb

$ git add aaa.txt
$ git commit -m conflict
[detached HEAD 59649d5] conflict
 1 file changed, 4 insertions(+)

$ git rebase --continue; echo $?
Successfully rebased and updated refs/heads/foo.
0
$
8<

Notice that `git rebase --continue` returned 0, so if that were your script,
`set -e` wouldn't make the script fail.

Hence I'm inclined to think you're either observing a bug pertaining to your
particular version of Git (or its flavor - I would not be too much surprized
if, say, Git for Windows version X.Y.Z has slight quirks compared to "vanilla"
Git X.Y.Z, -  or even to your platform) or it's something more local to your
case like, maybe, more files actually being in conflicting state.

The original script is kept for reference:

> #!/bin/bash
> 
> set -eux
> set -o pipefail
> 
> if [ -f vars ]
> then
> # This just sets repo_name, my_url and upstream_url to real life values.
> source ./vars
> else
> repo_name='example-repo-name'
> my_url="g...@ghosthub.example.com:dstromberg/$repo_name.git"
> upstream_url="g...@ghosthub.example.com:shared/$repo_name.git"
> fi
> 
> rm -rf "$repo_name"
> 
> git clone "$my_url" "$repo_name"
> cd "$repo_name"
> git config --add checkout.defaultRemote origin
> git remote add upstream "$upstream_url"
> 
> git checkout develop  # already there, actually.
> git fetch upstream
> # This consistently gives a conflict in docker/requirements.txt.m4
> git rebase upstream/develop develop || true
> cp /tmp/requirements.txt.m4 docker/.  # Normally I'd edit this to fix the 
> conflicts, but that got old quick :)
> git add docker/requirements.txt.m4
> git commit -m 'Dealt with merge conflicts' docker/requirements.txt.m4
> # This also consistently gives the same conflict again in 
> docker/requirements.txt.m4
> git rebase --continue
> # We never get to this point, because of the set -e
> git push --force origin develop

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/git-users/20230515181729.hlp53dujfks3ns7f%40carbon.

Re: [git-users] Merge conflict error, when there was no change in mentioned file

[Philip Oakley]

Part of the problem is deciding how to represent the  conflict for 
such non-printable characters for such merge conflicts.

At the moment there are no  good ideas about what whould be inserted into the 
file as a conflict marker, and how then it would be handled.

If you have any good ideas for that then it may be worth a discussion on the 
main git list (and probably the Git for Windows dev list as well).

Part of the problem is that even once a suitable display format is decided for 
the conflict marker, we would still have the 'competing editor' issue where 
Git's internal diff would be making one EOL assumption and your editor still 
happens to have the alternate EOL assumption when you remove the conflict 
markers, but leave in that un-see-able extra (or missing) part of the EOL 
sequence (and the problem reappears/repeats).

There is a patch just being developed on the main Git list that will report on 
the various conventions in use for: the file in the file system, the file in 
the index/staging area, and the file in the repo, and what the 
config/attributes says it expects it to be (that's four different ways!).

>From this week's "What's cooking":
* tb/ls-files-eol (2015-11-28) 2 commits
 - convert.c: mark a file-local function static
 - ls-files: Add eol diagnostics

 Add options to ls-files to help diagnose end-of-line problems.

 This latest round hasn't gotten any review yet.

 Waiting for review.
--
I'm sure that a user feedback would help, even if only to (thoughtfully) concur 
as to its likely usefulness.
http://thread.gmane.org/gmane.comp.version-control.git/281785/focus=281797

Philip
  - Original Message - 
  From: Quentin Neill 
  To: Git for human beings 
  Cc: wor...@alum.mit.edu 
  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 
"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, 2015 at 6:47:22 PM UTC-5, Dale R. Worley wrote:
"Philip Oakley" <philip...@iee.org> 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, but the recorded hash for the 
directories won't be (because the files' modes are stored in the 
directory object, not the file object). 

Dale 


  -- 
  You received this message because you are subscribed to the Google Groups 
"Git for human beings" group.
  To unsubscribe from this group and stop receiving emails from it, send an 
email to git-users+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Merge conflict error, when there was no change in mentioned file

[Quentin Neill]

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, 2015 at 6:47:22 PM UTC-5, Dale R. Worley wrote:
>
> "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, but the recorded hash for the 
> directories won't be (because the files' modes are stored in the 
> directory object, not the file object). 
>
> Dale 
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Merge conflict error, when there was no change in mentioned file

[Philip Oakley]

Konrad,

Thanks for the report confirming how you solved it.

For others, the SO post notes:
I had a git (Add/Add) conflict. The information from Janos provided the 
insight needed for a solution. The files appeared identical, but my 
conflicting folder of files were added with a permission of 664 on one branch, 
and a permission of 755 on another branch. Using git status revealed the 
difference between the files.

Were you able to confirm that it was a similar mode change problem? 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-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 there was no change in 
mentioned file


  Finally solved the problem, based on solution used in following thread:
  
http://stackoverflow.com/questions/19475387/how-to-handle-fix-git-add-add-conflicts/20626817#20626817

  # Deleted all files from the local workdir.

rm -rfv myconflictedfolder
  # commit this change

git commit -m 'Resolve git Add/Add branch merge conflict by deleting conflicted 
folder and files in myconflictedfolder'
  # do merge from remote 

git pull origin master
  Pull was executed successfully.


  Best regards,
  Konrad


  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 
mentioned file


  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): Merge conflict in admin/process_email.php
  Automatic merge failed; fix conflicts and then commit the result.




  I checked process_email.php using P4Merge, but shows no conflict, 
furthermore there were no changes at all, no difference.


  I get 


  $ git status
  On branch master
  nothing to commit, working directory clean on both repos. 




  Also I tried 


  $ git pull -X theirs origin/master master



  But still get the same error.

  I want to merge the remote origin repo with my local repo.
  I want to overwite local repo with remote origin repo content as the 
remote repo is newer, contains the latest code.

  More than 2000 files are conflicting, while I checked the conflict and 
they have the same content. I would not want to do manual conflict handling. 

  I have 

  autocrlf = False
  in the .gitconfig.



  Why do I get conflict error for files, which have exactly the same 
content?

Konrad,

An easy way to see what is going on is to split the 'git pull' into 'git 
fetch' (*) and then 'git merge' (*).

You may need extra options on the fetch and merge depending on your version 
to select the branches you want from the remote server into your 
remote-tracking branches (rtb) for that server.  

This separates out the issues and once you have all the remote changes held 
locally in your rtb's you can more easily do diffs between the two branches.

It can be quite a mind-wrench when you grok that rtb's are just local 
branches with a convenient name, rather than someting special that's to be 
'feared'.

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.

--

Philip


  -- 
  You received this message because you are subscribed to the Google Groups 
Git for human beings group.
  To unsubscribe from this group and stop receiving emails from it, send an 
email to git-users+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Merge conflict error, when there was no change in mentioned file

[Konrád Lőrinczi]

Finally solved the problem, based on solution used in following thread:
http://stackoverflow.com/questions/19475387/how-to-handle-fix-git-add-add-conflicts/20626817#20626817

# Deleted all files from the local workdir.

rm -rfv myconflictedfolder


# commit this change

git commit -m 'Resolve git Add/Add branch merge conflict by deleting conflicted 
folder and files in myconflictedfolder'


# do merge from remote 

git pull origin master


Pull was executed successfully.


Best regards,
Konrad


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 
 mentioned file

 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): Merge conflict in admin/process_email.php
 Automatic merge failed; fix conflicts and then commit the result.



 I checked process_email.php using P4Merge, but shows no conflict, 
 furthermore there were no changes at all, no difference.


 I get 

  $ git status
 On branch master
 nothing to commit, working directory clean on both repos. 



 Also I tried 

  $ git pull -X theirs origin/master master


 But still get the same error.

 I want to merge the remote origin repo with my local repo.
 I want to overwite local repo with remote origin repo content as the 
 remote repo is newer, contains the latest code.

 More than 2000 files are conflicting, while I checked the conflict and 
 they have the same content. I would not want to do manual conflict 
 handling. 

 I have 
  autocrlf = False
 in the .gitconfig.


 Why do I get conflict error for files, which have exactly the same content?

 Konrad,
  
 An easy way to see what is going on is to split the 'git pull' into 'git 
 fetch' (*) and then 'git merge' (*).
  
 You may need extra options on the fetch and merge depending on your 
 version to select the branches you want from the remote server into your 
 remote-tracking branches (rtb) for that server.  
  
 This separates out the issues and once you have all the remote changes 
 held locally in your rtb's you can more easily do diffs between the two 
 branches.
  
 It can be quite a mind-wrench when you grok that rtb's are just local 
 branches with a convenient name, rather than someting special that's to be 
 'feared'.
  
 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.
  
 --
  
 Philip
  


-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Merge conflict error, when there was no change in mentioned file

[Dale R. Worley]

Philip Oakley philipoak...@iee.org 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 look the same but the merge
program doesn't like them that there is an end-of-line problem.  Worse,
the *same file contents* can mean logically different things if one
version of the file is interpreted in one way in regard to line endings
and the other version is interpreted in a different way.

To start diagnosing the problem, the first thing is to extract the
hashes of the files as Git has them recorded.  Another is to get Git to
output the two files and you save them into two files.  Then use some
stupid program like cmp to check whether the files are *actually*
byte-by-byte identical.  (When you're having problems like this, avoid
using any intelligent file comparison program, because such programs
often apply their own interpretation to the files they handle -- 99% of
the time, it helps the user, but this is one of the 1% situations.)

Another thing to do is check out one of the commits, then manually run a
checksum program (e.g., sha1sum) on the file in question.  Then check
out the other commit, and manually run the checksum.  Are the checksums
the same?  Do they agree with the checksums Git has recorded for the
files in the commit objects?

Dale

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Merge conflict error, when there was no change in mentioned file

[Konrád Lőrinczi]

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ájus 16., szombat 17:10:58 UTC+2 időpontban Dale Worley a következőt 
írta:

 Philip Oakley philip...@iee.org javascript: 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 look the same but the merge 
 program doesn't like them that there is an end-of-line problem.  Worse, 
 the *same file contents* can mean logically different things if one 
 version of the file is interpreted in one way in regard to line endings 
 and the other version is interpreted in a different way. 

 To start diagnosing the problem, the first thing is to extract the 
 hashes of the files as Git has them recorded.  Another is to get Git to 
 output the two files and you save them into two files.  Then use some 
 stupid program like cmp to check whether the files are *actually* 
 byte-by-byte identical.  (When you're having problems like this, avoid 
 using any intelligent file comparison program, because such programs 
 often apply their own interpretation to the files they handle -- 99% of 
 the time, it helps the user, but this is one of the 1% situations.) 

 Another thing to do is check out one of the commits, then manually run a 
 checksum program (e.g., sha1sum) on the file in question.  Then check 
 out the other commit, and manually run the checksum.  Are the checksums 
 the same?  Do they agree with the checksums Git has recorded for the 
 files in the commit objects? 

 Dale 


-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Merge conflict error, when there was no change in mentioned file

[Philip Oakley]

From: Dale R. Worley wor...@alum.mit.edu

Philip Oakley philipoak...@iee.org 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 look the same but the merge
program doesn't like them that there is an end-of-line problem. 
Worse,

the *same file contents* can mean logically different things if one
version of the file is interpreted in one way in regard to line 
endings

and the other version is interpreted in a different way.

To start diagnosing the problem, the first thing is to extract the
hashes of the files as Git has them recorded.  Another is to get Git 
to

output the two files and you save them into two files.  Then use some
stupid program like cmp to check whether the files are *actually*
byte-by-byte identical.  (When you're having problems like this, avoid
using any intelligent file comparison program, because such programs
often apply their own interpretation to the files they handle -- 99% 
of

the time, it helps the user, but this is one of the 1% situations.)

Another thing to do is check out one of the commits, then manually run 
a

checksum program (e.g., sha1sum) on the file in question.  Then check
out the other commit, and manually run the checksum.  Are the 
checksums

the same?  Do they agree with the checksums Git has recorded for the
files in the commit objects?

Dale


Hi Dale,
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!)


It looks like the SO 
http://stackoverflow.com/questions/1580596/how-do-i-make-git-ignore-file-mode-chmod-changes 
gets linked a lot, but only after the source of 'problem' has been 
determined.


It does feel like another of those Git Gotcha's [1], where the key data 
is missing for the 'normal' user's status commands.


I may try to repeat the problem scenario (as I perceive it) and see what 
the 'right' commands would be to determine the fault.


--
Philip


[1] Gotcha: a sudden unforeseen problem. 


--
You received this message because you are subscribed to the Google Groups Git for 
human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Merge conflict error, when there was no change in mentioned file

[Philip Oakley]

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.


  I try to pull the whole content into local repo.


  git pull origin master
  From ssh://.../site.git
   * branchmaster - FETCH_HEAD
  ...
  CONFLICT (add/add): Merge conflict in admin/process_email.php
  Automatic merge failed; fix conflicts and then commit the result.




  I checked process_email.php using P4Merge, but shows no conflict, furthermore 
there were no changes at all, no difference.


  I get 


  $ git status
  On branch master
  nothing to commit, working directory clean on both repos. 




  Also I tried 


  $ git pull -X theirs origin/master master



  But still get the same error.

  I want to merge the remote origin repo with my local repo.
  I want to overwite local repo with remote origin repo content as the remote 
repo is newer, contains the latest code.

  More than 2000 files are conflicting, while I checked the conflict and they 
have the same content. I would not want to do manual conflict handling. 

  I have 

  autocrlf = False
  in the .gitconfig.



  Why do I get conflict error for files, which have exactly the same content?

Konrad,

An easy way to see what is going on is to split the 'git pull' into 'git fetch' 
(*) and then 'git merge' (*).

You may need extra options on the fetch and merge depending on your version to 
select the branches you want from the remote server into your remote-tracking 
branches (rtb) for that server.  

This separates out the issues and once you have all the remote changes held 
locally in your rtb's you can more easily do diffs between the two branches.

It can be quite a mind-wrench when you grok that rtb's are just local branches 
with a convenient name, rather than someting special that's to be 'feared'.

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.

--

Philip

-- 
You received this message because you are subscribed to the Google Groups Git 
for human beings group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Merge Conflict

[Philip Oakley]

From: Andrew Hardy andrew_ha...@hardysoft.co.uk 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 'delete' it/them from both branches using 'git rm file', 
and then commit that change to each branch.
This will make it so that the merge does not see either file in their 
respective 'last commit's.


This highlights that it is possible to 'track' ignored files, either as 
a continuation of a previous 'add', or by adding an otherwise ignored 
'file'.



to merge and it would just be added
rather than a binary merge being atempoted.

However now I have
LOCAL: delete
REMOTE:
Binary files a/:l:...  .suo and b/:3...suo differ

how do I get the merge to work.
I am not interested in su files any more in any way re git
hence putting *.suo in gitignore file


The rest of the merge will not go because of this.  How do I resolve 
this?


-
Philip 


--
You received this message because you are subscribed to the Google Groups Git for 
human beings group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to 
git-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/git-users?hl=en.

Fwd: Re: [git-users] Merge Conflict

[Andrew Hardy]

  
  
Because I cannot delete the binary file on the remote branch I
copied the file from github.com using 'raw' and saved it directly
into the local branch and committed it.
So now the merge should see the files as identical.

However the merge still fails saying binary files differ!!

 Original Message 

  

  Subject: 
  Re: [git-users] Merge Conflict


  Date: 
  Tue, 22 May 2012 23:06:30 +0100


  From: 
  Andrew Hardy andrew_ha...@hardysoft.co.uk


  Reply-To:
  
  andrew_ha...@hardysoft.co.uk


  To: 
  git-users@googlegroups.com

  



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" andrew_ha...@hardysoft.co.uk 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 'delete' it/them from both branches using 'git rm file', 
 and then commit that change to each branch.
 This will make it so that the merge does not see either file in their 
 respective 'last commit's.

 This highlights that it is possible to 'track' ignored files, either 
 as a continuation of a previous 'add', or by adding an otherwise 
 ignored 'file'.

 to merge and it would just be added
 rather than a binary merge being atempoted.

 However now I have
 LOCAL: delete
 REMOTE:
 Binary files a/:l:...  .suo and b/:3...suo differ

 how do I get the merge to work.
 I am not interested in su files any more in any way re git
 hence putting *.suo in gitignore file


 The rest of the merge will not go because of this.  How do I resolve 
 this?

 -
 Philip

  


-
This message sent via VFEmail.net
$14.95 Lifetime accounts! 15GB disk! 
Commercial Mail Options!   No Bandwidth Quotas!







-- 
You received this message because you are subscribed to the Google Groups "Git for human beings" group.
To post to this group, send email to git-users@googlegroups.com.
To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/git-users?hl=en.