This adds a removeBranch method similar to the addBranch method. It
calls these methods when a branch is created/deleted in the UI, avoiding
the cost of simply calling refresh afterwards.
Signed-off-by: Johannes Gilger <heipei@hackvalue.de>
* stable:
When selecting a folder in tree-view, display the
PBGitRepository: Correctly indicate bare/non-bare repos
Get rid of some unnecessary casts
CommitController: Don't rewrap commit message when amending
Release notes for 0.6.3
PBGitCommit: Call git show with --no-color to be safe
Info.plist: Fix handling of directories
PBGitIndexController: fix uninitialized value
Conflicts:
PBGitCommitController.m
Some hooks, such as commit-msg and
prepare-commit-msg require at least one argument.
This allows executeHook to take an array of
arguments to be passed on to the hook.
We already keep this dictionary in our repository. Rather than adding a
pointer to it on every commit in our rev walk, just look it up lazily in the
dictionary when we need to. That cuts down some time in the initial revwalk
and also removes some stupid code :)
This wasn't used anyway. A good idea would be to create a new
branchcontroller that takes care of all these revs, rather than
letting PBGitRepository take care of that
That's why it's there, after all. This also makes the system
more robust and catches some more errors.
The next thing this enables is to also allow right-clicking
on refs in the commit list.
Since 63523d00e8 (History view:
Make lozenge of currently checked out branch (HEAD) bold, same as gitk.),
-[PBGitRepository headRef] was called every time a cell needed redrawing.
This made GitX slow overall, but especially when resizing the window.
So, it's better to cache the value. We'll still reload it with an
explicit refresh though.
This introduces the PBGitConfig class. It is KVC compliant as far
as I can see, in that you can actually bind to it in IB and use
ValueForKeyPath to retrieve values. It currently only handles
strings; it should be possible to add functions to process
booleans and numbers to it.
This changes a lot of code, so quick review:
* RepositoryDocumentController now returns the document without selecting a ref
* PBGitWindowController now optionally shows the default view, or selects no view at all
* PBGitRepository keeps a pointer to its WindowController so that it can change views
This adds the "hasRef" boolean member in PBGitCellInfo which is set to true
if the specific commit has symbolic refs.
This is the first part in supporting labels just like gitk has. For now,
commits with refs are just displayed with a red circle.
Things that need to be done to support all refs:
* Make the NSDictionary in PBGitRepository contain arrays of refs,
not a single string
* Make PBGitGrapher store all refs of a commit in the PBGitCellInfo
* Figure out a nice way to display the labels in PBGitRevisionCell
Multiple repositories can now be opened by using the File → Open… menu option.
Each document is a PBGitRepository with a PBDetailController controlling the window. PBRepositoryDocumentController is the document controller.
When launched, the application will attempt to open a repository with the current directory as its path. If this fails it will display an open panel to allow the user to select one.
The revision walking code made the PBGitRepository unclean. Especially if
we want to keep multiple PBGitRepository objects around (e.g. persistent
data store), it needs to be more simple. This neatly extracts the revision
walking code from the repository code.
This makes the initial startup much faster. Commits get loaded in a separate
thread, and are displayed every 1000 commits.
There is a bug in here that makes fails a click while it is loading the commit
list. Not sure how to fix this, perhaps send the arrayController?
Pieter de Bie