• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Medium Medium
    • 1.3.2
    • None
    • None
    • None

      Perhaps related to https://jira.atlassian.com/browse/SRCTREE-1292 but there are other conditions which cause this error. Search Mac source for 'SRCTREE-1292' to get the diff.

      Reported via AAC here: https://answers.atlassian.com/questions/190694/my-sourcetree-don-t-want-to-show-the-log-it-says-git-log-failed-with-code-128-with-no-messages

            [SRCTREEWIN-826] Git log error code 128

            Brian R added a comment -

            FWIW, this isn't the same error that I got, nor was it the one described above. That was fixed for me in the release after 11/13/13, as they said above.

            Your error message is different (looks like some sort of argument error), whereas this error was specifically stating a "revision error" when we tried to view the log under specific circumstances. You didn't specify whether you saw this error on the log or not.

            Brian R added a comment - FWIW, this isn't the same error that I got, nor was it the one described above. That was fixed for me in the release after 11/13/13, as they said above. Your error message is different (looks like some sort of argument error), whereas this error was specifically stating a "revision error" when we tried to view the log under specific circumstances. You didn't specify whether you saw this error on the log or not.

            I get the same error message with sourcetree (latestversion) on all my git projects:

            "git status failed Code 128 "C.\Users/myself/.config/git/config':Invalid argument (e:\myproject)

            my other git gui clients work as exspected.

            Daniel Schmid added a comment - I get the same error message with sourcetree (latestversion) on all my git projects: "git status failed Code 128 "C.\Users/myself/.config/git/config':Invalid argument (e:\myproject) my other git gui clients work as exspected.

            @Gordon: Perfect, thank you for the detailed repro case. The precise set of circumstances that were needed to create this were that you were on a commit which started with [blah] in the commit text, and the branch you were on was not tracking any remote branch, and you were in that Current Branch view. I think I only ever had 2 of these at once in my tests so I didn't see it.

            Basically it was mistaking the tracking branch information and that was causing the error. This will be fixed from the next update.

            Steve Streeting (Inactive) added a comment - @Gordon: Perfect, thank you for the detailed repro case. The precise set of circumstances that were needed to create this were that you were on a commit which started with [blah] in the commit text, and the branch you were on was not tracking any remote branch, and you were in that Current Branch view. I think I only ever had 2 of these at once in my tests so I didn't see it. Basically it was mistaking the tracking branch information and that was causing the error. This will be fixed from the next update.

            I just ran into this. Here's what I did:

            I cloned git://git.eclipse.org/gitroot/jetty/org.eclipse.jetty.project.git
            I expanded the tags list, and selected jetty-9.0.7.v20131031
            I did not right-click and checkout or anything, just selected it, so the top right pane scrolled to that commit.
            I right clicked on the commit in the upper right pane, and selected "branch..."
            I gave it a name, and left it set to "specified commit", and "checkout new branch" was checked.
            The upper right pane got updated with my new branch label shown next to the tag, and the left pane now showed both 'master' and 'new branch'
            I selected the new branch in the left pane, and then changed "all branches" in the commit view to "current branch". Dialog showed:
            'git log' failed with error code 128: fatal: bad revision 'maven-release-plugin' (C:\Users\petteyg\dev\org.eclipse.jetty.project.git)

            The commit message for the specific commit is '[maven-release-plugin] prepare release jetty-9.0.7.v20131031'

            In cmd.exe,
            C:\Users\petteyg\dev\org.eclipse.jetty.project.git>..\..\AppData\Local\Atlassian\SourceTree\git_local\bin\git.exe log
            works fine.

            I suspect that SourceTree is appending the commit message to the 'git log' command (and possibly other commands, given other comments here), though I have no idea why it would do so.

            I'm using version 1.3.1.0 with embedded git 1.8.3.

            Gordon Pettey added a comment - I just ran into this. Here's what I did: I cloned git://git.eclipse.org/gitroot/jetty/org.eclipse.jetty.project.git I expanded the tags list, and selected jetty-9.0.7.v20131031 I did not right-click and checkout or anything, just selected it, so the top right pane scrolled to that commit. I right clicked on the commit in the upper right pane, and selected "branch..." I gave it a name, and left it set to "specified commit", and "checkout new branch" was checked. The upper right pane got updated with my new branch label shown next to the tag, and the left pane now showed both 'master' and 'new branch' I selected the new branch in the left pane, and then changed "all branches" in the commit view to "current branch". Dialog showed: 'git log' failed with error code 128: fatal: bad revision 'maven-release-plugin' (C:\Users\petteyg\dev\org.eclipse.jetty.project.git) The commit message for the specific commit is ' [maven-release-plugin] prepare release jetty-9.0.7.v20131031' In cmd.exe, C:\Users\petteyg\dev\org.eclipse.jetty.project.git>..\..\AppData\Local\Atlassian\SourceTree\git_local\bin\git.exe log works fine. I suspect that SourceTree is appending the commit message to the 'git log' command (and possibly other commands, given other comments here), though I have no idea why it would do so. I'm using version 1.3.1.0 with embedded git 1.8.3.

            I am also having this problem. It started today when I tried to fetch after some failed attempts to merge a branch using Bitbucket. For the record, Bitbucket just froze every time I tried to merge the mentioned branch.

            Cassio Santos Pereira added a comment - I am also having this problem. It started today when I tried to fetch after some failed attempts to merge a branch using Bitbucket. For the record, Bitbucket just froze every time I tried to merge the mentioned branch.

            I've run through the steps a number of times and haven't reproduced it yet.

            We do cache a bit of information like the current branch so I could imagine that it's possible that if the cached current branch was still Issue-ABC and you selected 'Current Branch', that there could be a second or two where the current branch was incorrect and a git command possibly issued looking for that branch. However I've found it impossible to create that situation because you cannot delete the branch you're on, you have to switch to another before deleting the original. So I can't even get a small way through that checkout / delete sequence without the current branch already being refreshed to the correct one (develop) before I delete the branch I was previously on. Unless the current branch refresh is particularly slow and somehow slower than the checkout/delete sequence I can't see how this could happen.

            Steve Streeting (Inactive) added a comment - I've run through the steps a number of times and haven't reproduced it yet. We do cache a bit of information like the current branch so I could imagine that it's possible that if the cached current branch was still Issue-ABC and you selected 'Current Branch', that there could be a second or two where the current branch was incorrect and a git command possibly issued looking for that branch. However I've found it impossible to create that situation because you cannot delete the branch you're on, you have to switch to another before deleting the original. So I can't even get a small way through that checkout / delete sequence without the current branch already being refreshed to the correct one (develop) before I delete the branch I was previously on. Unless the current branch refresh is particularly slow and somehow slower than the checkout/delete sequence I can't see how this could happen.

            Brian R added a comment -

            I should also note that if I repeat this process, the "bad revision" branch name is always the one I just previously deleted. Almost like it's "one behind."

            Brian R added a comment - I should also note that if I repeat this process, the "bad revision" branch name is always the one I just previously deleted. Almost like it's "one behind."

            Brian R added a comment - - edited

            I'm able to consistently reproduce this in my commonly-used repository at work. I'll list the steps here with as much detail as possible, knowing that some of them are likely irrelevant.

            I use GitFlow to create a new feature branch, in a sub-folder underneath "feature." For example, when creating the branch via GitFlow, I type the branch name as <sub-folder name>/Issue-XYZ. I make sure this isn't the only branch in this same subfolder. For example, there is already an "Issue-ABC" branch in the same sub-folder when I create the Issue-XYZ branch.
            GitFlow automatically points to the new branch as my working copy. I then change my working copy to develop.

            • Note that I have not pushed this new feature branch to the origin. I think that is an important component here.

            I manually delete the new feature branch while on develop (NOT using GitFlow to "finish" it).
            I then change to the Issue-ABC branch as my working copy.
            On the History view, I select "Current Branch" and check off "Show Remote Branches."
            I get this error message. Note that if I'm on develop as my working copy, I can do the previous step and get no errors.

            I think it has something to do with deleting branches that I haven't ever pushed to the origin, but that's just pure speculation on my part.

            I am using Source Tree version 1.2.3.0.

            Brian R added a comment - - edited I'm able to consistently reproduce this in my commonly-used repository at work. I'll list the steps here with as much detail as possible, knowing that some of them are likely irrelevant. I use GitFlow to create a new feature branch, in a sub-folder underneath "feature." For example, when creating the branch via GitFlow, I type the branch name as <sub-folder name>/Issue-XYZ. I make sure this isn't the only branch in this same subfolder. For example, there is already an "Issue-ABC" branch in the same sub-folder when I create the Issue-XYZ branch. GitFlow automatically points to the new branch as my working copy. I then change my working copy to develop. Note that I have not pushed this new feature branch to the origin. I think that is an important component here. I manually delete the new feature branch while on develop (NOT using GitFlow to "finish" it). I then change to the Issue-ABC branch as my working copy. On the History view, I select "Current Branch" and check off "Show Remote Branches." I get this error message. Note that if I'm on develop as my working copy, I can do the previous step and get no errors. I think it has something to do with deleting branches that I haven't ever pushed to the origin, but that's just pure speculation on my part. I am using Source Tree version 1.2.3.0.

            I've re-opened this one. Attempts to reproduce this haven't been successful yet so there's clearly some intersection of conditions happening; on the assumption that you can't allow us access to a repository of yours that is affected (if you can, great!), are you able to reproduce the problem in a test repo on one of the machines that has been affected? Or do you find like me that you can't reproduce it on demand?

            Steve Streeting (Inactive) added a comment - I've re-opened this one. Attempts to reproduce this haven't been successful yet so there's clearly some intersection of conditions happening; on the assumption that you can't allow us access to a repository of yours that is affected (if you can, great!), are you able to reproduce the problem in a test repo on one of the machines that has been affected? Or do you find like me that you can't reproduce it on demand?

            PaulV added a comment -

            There are no branches or tags with '[maven-release-plugin]'; it's just in the commit message. More details - on a repository that has this problem, when they create the local branch they see the error. The local branch is created despite the error. However, you are unable to checkout the branch - you keep getting the git log error. The strange thing is if you push the branch to the remote repository, then you are able to checkout the local branch without taking any errors.

            Should we re-open this ticket and close SRCTREEWIN-1106, or should we start putting comments over there?

            PaulV added a comment - There are no branches or tags with '[maven-release-plugin]'; it's just in the commit message. More details - on a repository that has this problem, when they create the local branch they see the error. The local branch is created despite the error. However, you are unable to checkout the branch - you keep getting the git log error. The strange thing is if you push the branch to the remote repository, then you are able to checkout the local branch without taking any errors. Should we re-open this ticket and close SRCTREEWIN-1106 , or should we start putting comments over there?

              sstreeting Steve Streeting (Inactive)
              ksenior KieranA
              Affected customers:
              3 This affects my team
              Watchers:
              8 Start watching this issue

                Created:
                Updated:
                Resolved: