git leaves master branch #1154

Closed
ChipSelect opened this Issue Jan 19, 2013 · 32 comments

Comments

Projects
None yet
7 participants

Hi there,
in one of several shared folders (sparkleshare instances), at some point in time, sparkleshare 1.0 leaves the master branch and won't return back, no matter what git command I try (acc. to help pages a la stack overflow) in order to force it back to master branch. Sparkleshare only reports frequently that a conflict happened but apparently no action is effective to come back on track, even though it tells otherwise. See log attached.

Two Macs with identical version numbers are running on OSX 10.8.2 and of course git 1.8.0 which comes bundled with sparkleshare. The repo is on a virtual server running git 1.7.2.5.

This occurs not before the second client will access the repo.

I'm not very much used to git, so I'm quite lost in bringing the local folder back in sync. Any help would be much appreciated.

Thanks a lot for making SparkleShare an (hopefully) for any good advise or bug fix to make this error go away.

20:06:50 | Listener | Announcing message 21d21f7a38a7257d03ac18a3c6bc02a3bd4bd3a6 to 8add3da31f44467f5fcc7793e61f3a999065f5ca on tcp://notifications.sparkleshare.org:443/
20:06:51 | Listener | Got message 21d21f7a38a7257d03ac18a3c6bc02a3bd4bd3a6 from 8add3da31f44467f5fcc7793e61f3a999065f5ca on tcp://notifications.sparkleshare.org:443/
20:06:52 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
20:07:30 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
20:07:38 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
20:09:46 | Listener | Got message fedef6a342def6b37804604f322ba66e36018bbc from bd539e07c997da646429a6d930c414aadde5ab92 on tcp://notifications.sparkleshare.org:443/
20:09:46 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rev-parse HEAD
20:09:46 | futurePrinting | Syncing due to announcement
20:09:46 | SyncDown | futurePrinting | Initiated
20:09:46 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rev-parse HEAD
20:09:46 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" fetch --progress "ssh://storage@<HOST>/home/storage/futurePrinting-crypto" master
20:09:46 | Git | futurePrinting | remote: Counting objects: 7, done.        
20:09:47 | Git | futurePrinting | remote: Total 4 (delta 1), reused 0 (delta 0)        
20:09:47 | Git | futurePrinting | From ssh://<HOST>/home/storage/futurePrinting-crypto
20:09:47 | Git | futurePrinting |  * branch            master     -> FETCH_HEAD
20:09:47 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
20:09:47 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config core.ignorecase true
20:09:47 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rebase FETCH_HEAD
20:09:47 | Git | futurePrinting | Conflict detected, trying to get out...
20:09:47 | Git | futurePrinting | Conflict resolved
20:09:47 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config core.ignorecase false
20:09:47 | SyncDown | futurePrinting | Done
20:09:47 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" log --since=1.month --raw --find-renames --date=iso --format=medium --no-color --no-merges
20:09:47 | Cmd | futurePrinting | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rev-parse HEAD
Owner

hbons commented Jan 20, 2013

thanks for the thorough report. i'm pretty sure this is the same issue as #1108. this is really bad bug that i still haven't solved yet.

the log says there was a conflict in a file. was this actually the case? did you change the same file on two machines around the same time?

can you open a terminal to run the following, and then give me the output?

cd ~/SparkleShare/futurePrinting
rebase FETCH_HEAD

you can return to the master branch by running git checkout master. if you any made changes on the "no branch" you may want to commit them first: git add -A and git commit -m "message". this garantees that any changes you made will be put into git's database, so you can get them back later by using git revlog.

issue #1108 seems to be alike. Though to me git does a lot of foo I don't understand (yet), therefore I raised a new issue/bug for this one.

Regarding the conflict: no concurrent actions.
This is what happend:

  1. SparkleShare's managed folder on computer A did an initial sync to the (then new and empty) repo with plenty of time to finish.
  2. After that, I brought computer B into play to sync with that folder, which went fine too.
  3. On computer B, I modified a file in that folder. Precisely, I moved in a file with the same name and type, that previously existed on B outside SparkleShare's focus. It had a timestamp which was a few hours earlier than the to-be-overwritten file in folder on B. But AFAIK that has no effect on how git manages changes. The file got overwritten with different content.
  4. As soon as this file was in and git finished pushing that commit to the repo, SparkeShare on A started complaining ("conflict, but don't worry ...") and still does.

As a matter of fact, I had a bunch of situations like this before in shares with lots of files in a variety of sizes and a combination of fast and slow network connections interplaying. For this bug report, I isolated and simplified things as much as possible. In any of this more complex cases, I only could help myself in wiping the screwed folders entirely from every system including repo. Of course I also manually deleted the corresponding entries in ~/.config/sparkleshare/config.xml.

The state after step 4 is what the above mentioned log reflects. Until now, I did not touch this setting. A git log on B reports the latest valid commit including that file I moved in. On system A git log is one step behind (the complaining one).

To the rebase thing (I assume you meant git rebase FETCH_HEAD):

$ git rebase FETCH_HEAD
Cannot rebase: You have unstaged changes.
Please commit or stash them.
$

Thank you for your hints wrangling with git by hand. I'll do this a bit later, and in case it turns out to be interesting, I'll attach comments to this thread.

Cheers!

Don't know if relevant: comp A has HFS+ with case-insensitivity, whereas system B has HFS+ with case-sensivity. Just came to my mind.

Owner

hbons commented Jan 20, 2013

thanks. i've closed the other issue, as this one describes much better what is going on.

yes, i did mean to say git rebase FETCH_HEAD. so it says there are local changes in the repo, so it can't start to rebase. is this right after the error, or did you make any changes to the local repo that caused this message? (i assume it's the first, but it's worth to double check this) what does a git status say in this state? the output of git status --porcelain would be handy as well.

i don't think this has anything to do with case sensitivity, but we'll see.

In the meantime, I gave the command git checkout master a shot (on system A, the complaining one), which only noted to already beeing on master.

To your questions reg. rebasing: I personally didn't do any changes in folder on computer A. Since I observed this several times before in different folders (which I wiped), I was aware of potential conflicts, not to say expecting them to happen.

What comes to my mind right now is the existence of files like .DS_Store in every ordinary (Finder-managed) directory which store desktop stuff like window position and such. A simple window move alters that file. I'm sure you're aware of that in SparkleShare.

Yes, I did the above pasted debug.log snap shot right after the error came up first time. The output of git status --porcelain nothing but CR+LF.

Hi there,
my setup is still suffering from this bug. And so am I. All my repos are affected except one which is very rarely used. Needless to say that this renders sparkleshare nearly useless for me. Because I am so positive about sparkleshare, is there any further detail I could possibly provide to help nailing this bug? Pls let me know.

KimSJ commented Feb 26, 2013

Hmm. Running in to same problem. my win machine is currently in a state where git status reports "not in any branch, you are currently rebasing, all conflicts fixed, nothing to commit, working directory clean". Running git rebase -- continue doesn't help: applying xxxx / no changes - did you forget to use git add? If there's nothign left to stage chances are that something else already introduced the same changes. you might want to skip this patch. When you have resolved this problem, run git rebase --continue. If you prefer to skip, run git rebase -- continue" / Nothing to commit"
At this point trying "git checkout master" gives "Deletion of directory "Old/Wombat" failed, should I try again?"

I think this gives a clue as to how I broke things... I was creating a new repo by dragging directories from my dropbox. At one point, I changed my mind about the directory structure and (I think) dragged a directory into its parent, probably whilst previous push was in progress. (some of these directories are big-ish... 1.6Gb of data)

The Win machine has only about 15% of the data sync-ed at the moment.

Unfortunately, I can't remember exactly what I moved where, when. But does this give anyone else an idea of what to be looking for?

Also just noticed that my network connection failed. Bizzarely, having reset the machine, it is reporting that the win box is 38 commits ahead of the origin. But all the changes have been coming from the Linux box...

Hmm. Now in a state wheren the Linux box has 10,036 items, totalling 1.7Gb, Windows box has 8579 files, 893 folders, size 465Mb. Both on branch master, both "up to date". Git pull on Linux box pulled in the fast-forward commits. At least one directory I can see (in the top directory of the project) is on the Linux box but not on the PC.

So, my conclusion is that maybe this is all about doing stuff to the tree whilst commits are in progress? Not something git is designed to handle, I suspect. May be quite a fundamental problem with this architecture.

Owner

hbons commented Feb 26, 2013

@KimSJ so where does the problem occur? on the receiving end?

the "38 commits ahead" isn't actually true, it's a harmless side effect to how Git is used and unrelated.

KimSJ commented Feb 26, 2013

OK. Theory to repair the world... this may be overkill (possibly the git push ... --force would fix everything; didn't try that)

First, stop SparkleShare on the machine that you want to be the new master

For safety, save away a backup copy of the shared directory. This will of course have the .git shadow directory in it. You will need the .git/config file from that. Also save copies of any stuff on other computers that are in the shared project and not in your "master -- they will disappear when the new forced master takes effect: you can put them back after the resync is completed.

cd the sparkleshare project directory

rm -r .git
# git repositories have only one hidden entry; the .git
# directory structure in the top level of the repo
# so this forgets all about being a git project

git init
# so now we put back a new stucture

now copy .git/config from the backup directory copy you made

git add *
git commit -m "Restart project"

git push origin master --force

Stupidly I didn't do a du -sm on the origin before I did the above, so not sure what state the origin actually was. However, now, I'm in a state where the Win client is reporting that it's up to date, in fact four commits ahead of the orign/master, and has "invented" a modified file. So none of the new forced HEAD is getting pulled in to the win box. Ah, I spoke too soon... receiving now. We'll see what happens... stuck at "99%" for a while... files appearing...

KimSJ commented Feb 26, 2013

Now got a bunch of conflict files appearing in my top level project directory...one a minute for four files. I'm guessing this is because the pull is taking longer than the poll interval?

KimSJ commented Feb 26, 2013

OK. Fifteen mins on, there are fifteen copies of those four conflicted files, and 33 Sparkle process hammering away (mostly) writing to the disk. I know I have a problem with file system access speed on this system, which doesn't help... up to 1.3G written now (of 1.7G target), so it seems to be going in the right direction

KimSJ commented Feb 27, 2013

Aaah... at least part of the problem is revealed... I have a .gitignore_global on my Linux box, which ignores compiled results, zip packages, etc. Running git config core.excludesfile "" in the project directory fixed things. Guess that should be a standard addition to the project config. I've posted #1194 on this issue. Still doesn't explain why win box SparkleShare client got stuck at 99%. In the end I killed the process and manually forced a reset to origin/master.

Owner

hbons commented Feb 27, 2013

@KimSJ which part of the problem did removing the global gitignore fix?

KimSJ commented Feb 27, 2013

The "not copying everything across, even when apparently working as intended" part. Though remember that I still started yesterday in a state where not everything that should have been copied across was successfully duplicated: about 1.3G should have been in repo before I sorted the gitignores; only about 345M got across on the first try.

KimSJ commented Feb 27, 2013

Win machine stuck again this morning... did a hard reset before I went to bed. now we have SS reporting "project up to date", but...

C:\Users\Kim\SparkleShare\kim>git status
# Not currently on any branch.
# You are currently rebasing.
#   (all conflicts fixed: run "git rebase --continue")
#
nothing to commit, working directory clean

C:\Users\Kim\SparkleShare\kim>git rebase --continue
Applying: + ‘Home/Aude/Aude's Business Cards v3.svg’
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

sooo... tried a skip:

C:\Users\Kim\SparkleShare\kim>git rebase --skip
Applying: + ‘Old/Backups/My Library.rdf’
Using index info to reconstruct a base tree...
<stdin>:1551: trailing whitespace.
<html><head>
<stdin>:1552: trailing whitespace.

<stdin>:1553: trailing whitespace.
<title>Terms and conditions</title>
<stdin>:1554: trailing whitespace.
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<stdin>:1555: trailing whitespace.
<link media="screen" rel="stylesheet"
warning: squelched 1493 whitespace errors
warning: 1498 lines add whitespace errors.
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
Applying: + ‘Old/Untitled Folder/’
Applying: + ‘Old/OpenHub/’
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Applying: + ‘Old/OpenHub/PCBs_old/Derby DCU Dwgs/GA.dwg’
Using index info to reconstruct a base tree...
<stdin>:7247: trailing whitespace.
[InternetShortcut]
<stdin>:7248: trailing whitespace.
URL=http://uk.rs-online.com/web/search/searchBrowseAction.html?method=searchProducts&searchTerm=666-1608&x=0&y=0
<stdin>:13907: trailing whitespace.
[InternetShortcut]
<stdin>:13908: trailing whitespace.
URL=http://www.farnell.com/datasheets/55299.pdf
<stdin>:13915: trailing whitespace.
[InternetShortcut]
warning: squelched 103712 whitespace errors
warning: 103717 lines add whitespace errors.
Falling back to patching base and 3-way merge...
error: Your local changes to the following files would be overwritten by merge:
        Old/Untitled Folder/.empty
Please, commit your changes or stash them before you can merge.
Aborting
Failed to merge in the changes.
Patch failed at 0030 + ‘Old/OpenHub/PCBs_old/Derby DCU Dwgs/GA.dwg’
The copy of the patch that failed is found in:
   c:/Users/Kim/SparkleShare/kim/.git/rebase-apply/patch

When you have resolved this problem, run "git rebase --continue".
If you prefer to skip this patch, run "git rebase --skip" instead.
To check out the original branch and stop rebasing, run "git rebase --abort".

Leads me to wonder if these "whitespace errors" are to do with CRLF conversion, and that might be contributing to problems? By the way, I have not made any manual local changes on this machine. And I have no idea where "Old/Untitled Folder" came from; it doesn't exist in the Linux version of the tree.

KimSJ commented Feb 27, 2013

Hmm. Stranger and stranger. Both clients have got core.autocrlf set to "false", so where are the whitespace errors comming from?

KimSJ commented Feb 27, 2013

Found this set of runes for restting local copy at https://help.github.com/articles/dealing-with-line-endings ... seemed to work well, when applied whilst SS was not running.

git rm --cached -r .
# Remove everything from the index.


git reset --hard
# Write both the index and working directory from git's database.

At this point, I had four (.txt) files which claimed to have been modified... as usual, I'd not touched them.

git add .
# Prepare to make a commit by staging all the files that will get normalized.

# This is your chance to inspect which files were never normalized. You should 
# get lots of messages like: "warning: CRLF will be replaced by LF in file."

git commit -m "Normalize line endings"
# Commit

However, when I tired to push this...

C:\Users\Kim\SparkleShare\kim>git push origin master
user@server's password:
To ssh://user@server/~/kim
 ! [rejected]        master -> master (non-fast-forward)
error: failed to push some refs to 'ssh://user@server/~/kim'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
hint: before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.

trying git pull brings up massive numbers of merge conflicts (maybe a hundred or so)

KimSJ commented Feb 27, 2013

Hmm. Curiouser and curiouser. git reset --hard (with or without specifying HEAD) still leaves a bunch of modified files reported by git status. I thought that wasn't possible, or have I misunderstood git reset? Interstingly, all the reported files are .txt files.

Owner

hbons commented Feb 27, 2013

@KimSJ thanks for all the (overwhelming) info. :) it could have something to do with the line endings. at least we have kind of a clue where this may be coming from.

KimSJ commented Feb 27, 2013

Currently trying to get the two ends back in sync, using raw git Linux end thought it was up to date, but git push resulted in many hours of transfer(!). Interstingly, the push errored at one point (so far this has happened twice, after ~500 and ~800Mb of data) and had to be restarted (remote end hung up unexpectedly). Push seems not to be restartable from middle, so we start again from the beginning... sigh Is it possible the SS doesn't handle this error case, and thinks it has done the push?

And I've learned that doing a single git commit of 1.7Gbytes is a bad plan :-)

KimSJ commented Feb 27, 2013

core.whitespace cr-at-eol may be a good option to set? Or maybe better would be to create a .gitattributes file, and set

* -crlf -diff
Owner

hbons commented Feb 27, 2013

http://lostechies.com/keithdahlby/2011/04/06/windows-git-tip-hide-carriage-return-in-diff/

"One downside of turning off autocrlf is that the output of git diff highlights CR characters (indicated by ^M) as whitespace errors. To turn off this “error”, you can use the core.whitespace setting:"

maybe that's what's going on?

KimSJ commented Feb 28, 2013

Further explanation of my issues: git initial commit included huge objects, which exceeded memory allocation on my server, so was never going to work (origin git receive process kept getting killed). But Linux client SS totally failed to notice this error condition, and reported life as good. To be fair, my attempts to fix things using raw git may have confused things; not sure how SS would handle things given a fresh start. But since this seems to be a fundamental problem for me, I guess I'll have to find an alternative approach. Good luck with SparkleShare. :-)

Hi there, I recently ran into the same symptoms as originally reported by ChipSelect.

I am using SparkleShare 1.0.0 for OS X and Windows clients with several shared projects. I found the problem started after 0 length files were added to a SparkleShare project.

After that, 'git status' returned 'nothing to commit, working directory clean'. However a 'git diff' reported differences in the 0 length files. After this, all other clients got stuck in the situation above with SparkleShare logs showing 'Conflict detected, trying to get out...' and 'Conflict resolved' situation repeatedly:

11:09:38 | ListenerTcp | Received pong from tcp://notifications.sparkleshare.org:443/
11:14:33 | Git | Rel | Checking for remote changes...
11:14:33 | Cmd | Rel | git rev-parse HEAD
11:14:33 | Cmd | Rel | git ls-remote --heads --exit-code "ssh://storage@blah/home/storage/Rel-crypto" master
11:14:34 | Git | Rel | Remote changes found, local: a522463ce5e246c7179d1c559817820c094aa0dc, remote: 5a4bcc240951cca4e3cec2b4c527e8723fa81064
11:14:34 | SyncDown | Rel | Initiated
11:14:34 | Cmd | Rel | git rev-parse HEAD
11:14:34 | Cmd | Rel | git fetch --progress "ssh://storage@blah/home/storage/Rel-crypto" master
11:14:35 | Git | Rel | From ssh://blah/home/storage/Rel-crypto
11:14:35 | Git | Rel |  * branch            master     -> FETCH_HEAD
11:14:35 | Cmd | Rel | git status --porcelain
11:14:36 | Cmd | Rel | git config core.ignorecase true
11:14:36 | Cmd | Rel | git rebase FETCH_HEAD
11:14:38 | Git | Rel | Conflict detected, trying to get out...
11:14:38 | Git | Rel | Conflict resolved
11:14:38 | Cmd | Rel | git config core.ignorecase false
11:14:38 | SyncDown | Rel | Done
11:14:38 | Cmd | Rel | git log --since=1.month --raw --find-renames --date=iso --format=medium --no-color --no-merges 

I found the workaround was to delete all 0 length files in the SparkleShare folders on all clients. Those file deletes got pushed to the repository and it started working again.

Apologies that I don't have the 'git status' and 'git diff' output, I lost those a few weeks back when I had to re-image my OS HDD. However this should be easy to reproduce if needed, I can setup a test project if that would help.

Given I was seeing the same symptoms, I am wondering if this could be the cause of some of the problems reported by other users?

Owner

hbons commented May 4, 2013

@pstonela indeed, it does seem to have something to do with empty files. i've only managed to reproduce this on encrypted repos so far though, not on regular ones.

pstonela commented May 4, 2013

All the repositories I am using are encrypted; a single 0 length file is enough to reproduce 100% of the time.

Anything I can do to help move this forward?

Thanks, Paul

On May 4, 2013, at 2:13 PM, Hylke Bons wrote:

@pstonela indeed, it does seem to have something to do with empty files. i've only managed to reproduce this on encrypted repos so far though, not on regular ones.


Reply to this email directly or view it on GitHub.

Owner

hbons commented May 4, 2013

which version of git are you all using?
git-bin seemed to have the same issue due to older versions of git being used: https://github.com/Mighty-M/git-bin/issues/13 but i'm running 1.8 here and can still reproduce the issue.

pstonela commented May 4, 2013

git version 1.8.0

On May 4, 2013, at 2:34 PM, Hylke Bons wrote:

which version of git are you all using?
git-bin seemed to have the same issue due to older versions of git being used: Mighty-M/git-bin#13 but i'm running 1.8 here and can still reproduce the issue.


Reply to this email directly or view it on GitHub.

4nduril commented May 6, 2013

Hi,
I have the same problem: crypto-project, 0-length-files added --> Same conflict/stop-syncing-problem.
Git-Version is 1.7.9.5 on one client (the one from where I added the 0-length-files), 1.8.1.2 on the other client. The server says it runs git 1.8.1.GIT.
If I can provide you with any other useful information, I will happily do so.
Oh, and I wanted to note that I haven't seen any branch switching/losing. Both clients say they are on master.

Collaborator

BarryThePenguin commented Jul 2, 2013

Getting the following in OSX 1.8.2 and SparkleShare 1.1
Is this related?

The user complained the other day of "Host Unreachable for a few days now with respect to /staff/"
I got them to send through the first debug, but I failed to notice the git error.
But this seemed to disappear with a reboot followed by an upgrade of SparkleShare from 0.9.7 to 1.1

Now today he is getting a "Failed to send some errors" in the same project. This is shown in the second debug log and appears to be branch related.

First Debug Log

12:26:59 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" log --since=1.month --raw --find-renames --date=iso --format=medium --no-color --no-merges
12:27:01 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config --get filter.bin.clean
12:27:01 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config remote.origin.url "ssh://git@documents.web.org/staff"
12:27:01 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
12:27:01 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
12:27:02 | SyncUp | staff | Initiated
12:27:02 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
12:27:02 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" add --all
12:27:02 | Git | staff | Changes staged
12:27:02 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
12:27:03 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config user.name "User Name"
12:27:03 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config user.email "User.Name@gmail.com"
12:27:03 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" commit --all --message="/ ‘message’ " --author="User Name <User.Name@gmail.com>"
12:27:03 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" push --progress "ssh://git@documents.web.org/staff" master
12:27:04 | Git | staff | To ssh://git@documents.web.org/staff
12:27:04 | Git | staff |  ! [rejected]        master -> master (non-fast-forward)
12:27:04 | Git | staff | error: failed to push some refs to 'ssh://git@documents.web.org/staff'
12:27:04 | Git | staff | hint: Updates were rejected because the tip of your current branch is behind
12:27:04 | Git | staff | hint: its remote counterpart. Merge the remote changes (e.g. 'git pull')
12:27:04 | Git | staff | hint: before pushing again.
12:27:04 | Git | staff | hint: See the 'Note about fast-forwards' in 'git push --help' for details.
12:27:05 | SyncUp | staff | Error
12:27:05 | SyncDown | staff | Initiated
12:27:05 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rev-parse HEAD
12:27:05 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" fetch --progress "ssh://git@documents.web.org/staff" master
12:27:06 | Git | staff | remote: Counting objects: 27, done.        
12:30:22 | Git | staff | remote: Total 22 (delta 12), reused 0 (delta 0)        
12:30:23 | Git | staff | From ssh://git@documents.web.org/staff
12:30:23 | Git | staff |  * branch            master     -> FETCH_HEAD
12:30:23 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
12:30:23 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rebase FETCH_HEAD
12:30:24 | Git | staff | Conflict detected, trying to get out...
12:30:24 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
12:30:24 | Git | staff | Conflict resolved
12:30:24 | SyncDown | staff | Done

Second Debug Log

10:43:49 | /Users/username/SparkleShare/staff | Initializing...
10:43:49 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" log --since=1.month --raw --find-renames --date=iso --format=medium --no-color --no-merges
10:43:50 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config core.ignorecase false
10:43:50 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config --get filter.bin.clean
10:43:50 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config remote.origin.url "ssh://git@documents.web.org/staff"
10:43:50 | Git | staff | Checking for remote changes...
10:43:50 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rev-parse HEAD
10:43:50 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rev-parse --abbrev-ref HEAD
10:43:50 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" ls-remote --heads --exit-code "ssh://git@documents.web.org/staff" HEAD
10:43:51 | SyncUp | staff | Initiated
10:43:51 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" add --all
10:43:51 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
10:43:51 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" push --progress "ssh://git@documents.web.org/staff" HEAD
10:43:52 | Git | staff | error: unable to push to unqualified destination: HEAD
10:43:52 | Git | staff | The destination refspec neither matches an existing ref on the remote nor
10:43:52 | Git | staff | begins with refs/, and we are unable to guess a prefix based on the source ref.
10:43:52 | Git | staff | error: failed to push some refs to 'ssh://git@documents.web.org/staff'
10:43:53 | SyncUp | staff | Error
10:43:53 | SyncDown | staff | Initiated
10:43:53 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rev-parse HEAD
10:43:53 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" fetch --progress "ssh://git@documents.web.org/staff" HEAD
10:43:54 | Git | staff | From ssh://documents.web.org/staff
10:43:54 | Git | staff |  * branch            HEAD       -> FETCH_HEAD
10:43:54 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" status --porcelain
10:43:54 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config core.ignorecase true
10:43:54 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" rebase FETCH_HEAD
10:43:54 | Cmd | staff | git --exec-path="/Applications/SparkleShare.app/Contents/Resources/git/libexec/git-core" config core.ignorecase false
10:43:54 | SyncDown | staff | Done
Owner

hbons commented Dec 2, 2013

the problem with empty files in encrypted projects has now been fixed in 074c91c.

i think this will fix this issue as well. Git seems to have a much easier time merging than rebasing. in any case, merging won't leave the master branch, so it doesn't look like you've lost files. testing appreciated.

@hbons hbons closed this Dec 2, 2013

ccverg commented Feb 6, 2014

@hbons you should claim this bounty as well!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment