path rather than the <PBGitTree: 0x...> object.
For example:
"This is a tree with path <PBGitTree: 0x1313000>"
..instead of:
"This is a tree with path Documentation/ReleaseNotes"
This addresses an issue with non-bare repos which had no core.bare
variable in the config. The isBareRepository-function would work
on the full fileURL (pointing to the .git subdir), which in turn would
indicate a bare repo (this is what git rev-parse --is-bare-repository
returns in .git, and the opposite is true for the superdir).
We work around by using the working-dir for a repo (and directly
indicating a bare repo if there is no workdir). The only issue remaining
is the case of a bare repo manually set to "core.bare = false".
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
We used to use git log with a custom pretty command to reread the commit message,
but this rewraps the subject line, and also adds extra newlines. We fix this
by reading in the raw commit from git-cat-file, and then searching for the
double newline.
This fixes ticket #132, where setting color.ui = always in the gitconfig
caused GitX to received colorized output for "git show", thereby
destroying the diff-output.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
Resulting from the last change to Info.plist in 3e21d041ef we were no
longer able to open directories called <foo>.<bar> wheren bar != git.
Using this code allows us to open all directories again and also to
drag-and-drop to the dock.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
The encoding used to write a new .gitignore was based on an
uninitialized value. Fix this by using UTF-8 as the default.
Found by the clang static analyzer.
This uses the new way to stop tracking the index when
adding files. This can be noticed when staging more than
one file, as the tables might have to refresh dozens
of times.
I'm not sure if we should use the release notes here or rather
use the tags, but this follows other information on the site
like the "Release History", so at least it's internally consistent.
Show a very simple user-dialog when trying to delete a branch or a
tag.
This satisfies ticket #115.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
This makes use of the rules that are explicit in the
preferences. By default, Gists are always private and there
will always be a confirmation message.
Both options can be changed from the preferences menu.
This patch relates to ticket #58. It adds a method which will ask for
confirmation when pasting to Gist as an anonymous user. Since users
which have github.user and github.token set can easily delete pasted
snippets no confirmation is needed for them.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
We used the whole output of git describe before, not realizing that
neither MacOS nor Sparkle are ok with alphabetic characters but instead
want monotonically increasing integers. So now we just take the major
version number appended with the number of commits since the last tag.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
We do this by preprocessing the Info.plist file
and adding a prefix header with the current revision
#define'd. This seems to be the most reliable way,
unfortunately
This should ship binaries with debugging symbols in them.
I'm not sure if there's a negative side effect somewhere,
but this should make parsing the crash logs a lot easier :)
When unstaging the last cached hunk of a file, the file remained in the
"Staged Changes" column, with the notice "This file has no more changes"
and the "Unstage"-button remaining in the diff-view.
This fixes this behaviour by correctly distinguishing files in the
files-array not only by filename but also by unstaged/cached status,
s.t. for a file with unstaged and cached changes, there are two entries
in the files-array.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
* commit '3e21d041efb95b6358c749e021bf5ddbcc05bcd7':
Info.plist: Make GitX open any file/folder on drop
diffHighlighter: Correctly match unified diff hunks
diffHighlighter: Fix indent-after-stagebutton bug
This was seriously broken after we moved to a hash
to store the refs in ddc9ae7654. Apparently nobody
noticed this earlier.
We fix it by doing the right thing. Don't remove the array
if it's empty, but check in the drawing if we really have refs.
We used to change the PBFile status every time we found a
similarly named file. Because the unstagedFilesController
had a filter and sort predicate for these, the array was
rearranged every time an existing file was found. This quickly
leads to stalling.
We fix it by temporarily disabling the automatic rearranging
and then reenabling it when we're finished.
Hunks in unified diffs are usually in the form of @@ -a,b +x,y @@, but
sometimes the ,b (i.e. the range) can be ommitted, in which case our
code didn't match the hunk-header at all, resulting in line-numbers
off-by-one in commit-view.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
- display context lines in own <div>.
- Stagebutton no longer is float: left.
This fixes ticket #104
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
When trying to install the gitx symlink into /usr/local/bin, GitX would
fail if the directory /usr/local/bin didn't exist yet. We simply call
mkdir -p in advance, which only creates the directory if doesn't exist.
When there is no diff to display (i.e. empty-file mode-changes, deletion
or creation) we don't draw a diff-box (div) but just list the filename.
Also fixes a bug with mode-changes not displaying new-mode.
Plain-text files which have been created are not diffed against
/dev/null, but have a "new file mode" line. This patch catches this case
and also highlights that the control-flow in diffHighlighter is less
than optimal.
If the repository we're working on is bare and through some default
value we are asked to display the commit-view, we simply change it back
to history.
dbr