git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
* git rebase and MacOS 10.7.2 file versions
@ 2012-01-30 16:46 Thomas Röfer
  2012-01-30 19:11 ` Torsten Bögershausen
  0 siblings, 1 reply; 2+ messages in thread
From: Thomas Röfer @ 2012-01-30 16:46 UTC (permalink / raw
  To: git

Hi,

I get mysterious behavior during git rebase on MacOS 10.7.x. git reports unresolvable conflicts, stops the rebase, but afterwards the list of files that needs to be fixed is empty. git rebase --skip does not help, because then the commit is actually missing.

What helps is to abort the rebase, copy the conflicting files, delete the originals and move back the copies instead. The files themselves are identical before deleting and after restoring and their access rights are also unchanged. What is actually different is that all the conflicting files so far had older versions stored by Lion's "file versions" feature. The restored copies do not have such a version history. Since "file versions" cannot be deactivated, editing a file with an application that supports it (e.g. TextEdit) will basically result in strange git conflicts later.

I have tested this with a number of git versions, but the behavior is always the same.

All this may simply be a bug in MacOS 10.7.x, but maybe there is a workaround for git to make this work again.

Best regards,

Thomas Röfer

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: git rebase and MacOS 10.7.2 file versions
  2012-01-30 16:46 git rebase and MacOS 10.7.2 file versions Thomas Röfer
@ 2012-01-30 19:11 ` Torsten Bögershausen
  0 siblings, 0 replies; 2+ messages in thread
From: Torsten Bögershausen @ 2012-01-30 19:11 UTC (permalink / raw
  To: Thomas Röfer; +Cc: git

On 30.01.12 17:46, Thomas Röfer wrote:
> Hi,
> 
> I get mysterious behavior during git rebase on MacOS 10.7.x. git reports unresolvable conflicts, stops the rebase, but afterwards the list of files that needs to be fixed is empty. git rebase --skip does not help, because then the commit is actually missing.
> 
> What helps is to abort the rebase, copy the conflicting files, delete the originals and move back the copies instead. The files themselves are identical before deleting and after restoring and their access rights are also unchanged. What is actually different is that all the conflicting files so far had older versions stored by Lion's "file versions" feature. The restored copies do not have such a version history. Since "file versions" cannot be deactivated, editing a file with an application that supports it (e.g. TextEdit) will basically result in strange git conflicts later.
> 
> I have tested this with a number of git versions, but the behavior is always the same.
> 
> All this may simply be a bug in MacOS 10.7.x, but maybe there is a workaround for git to make this work again.
> 
> Best regards,
> 
> Thomas Röfer
Hi,

is that problem reproducable? It seems so.

Could provide a simple demo, what you have done and how to reproduce the error?
 
If that is the case, chances that we can reproduce it are much better.
And so are the chances that somebody reading this list can help you.

>Lion's "file versions" feature..
Are the files identical when you run e.g. md5sum on them?
And what does a simple "ls" from a terminal say?


/Torsten

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2012-01-30 19:11 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-01-30 16:46 git rebase and MacOS 10.7.2 file versions Thomas Röfer
2012-01-30 19:11 ` Torsten Bögershausen

Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).