This revealed that the output from blame and tag was not chomped
properly and was relying on HTML output not noticing that extra
whitespace that resulted from the newline, which was also fixed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I started to find it very annoying that my test application kept
opening at the wrong location on my desktop, so now we save the
basic window geometry and sash positions into the config file as
gui.geometry.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Caching the Signed-Off-By line isn't very important (as its not
performance critical). The major improvement here is that we
now report an error to the user if we can't obtain their name
from git-var.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There's really no great reason to show the entire commit object id
within the GUI, especially if the user is unable to copy and paste
it into another interface such as gitk or a terminal window. So
we'll just show them the first 8 digits and hope that is unique
within their repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
At least one user was confused by the term 'check-in'; he thought that
clicking that button would commit just that one file, but he wanted to
include all modified files into his next commit.
Since git doesn't really have a check-in concept this really was poor
language to use. Git does have an update-index concept but that is a
little too low level to show to the user.
So instead we now talk about including files in a commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Just make it take over blame's place. Documentation and command
have all stopped mentioning "git-pickaxe". The built-in synonym
is left in the command table, so you can still say "git pickaxe",
but it probably is a good idea to retire it as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise, commit log template would get the remainder of the
filename start on a new line unquoted and the log gets messed
up.
I initially considered using the full quote_c_style(), but the
output from the command is primarily for human consumption so
chose to leave other control characters and bytes with high-bits
unmolested.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Replace "gitweb diff header" with its full sha1 of blobs and replace
it by "git diff" header and extended diff header. Change also somewhat
highlighting of diffs.
Added `file_type_long' subroutine to convert file mode in octal to
file type description (only for file modes which used by git).
Changes:
* "gitweb diff header" which looked for example like below:
file:_<sha1 before>_ -> file:_<sha1 after>_
where 'file' is file type and '<sha1>' is full sha1 of blob is
changed to
diff --git _a/<file before>_ _b/<file after>_
In both cases links are visible and use default link style. If file
is added, a/<file> is not hyperlinked. If file is deleted, b/<file>
is not hyperlinked.
* there is added "extended diff header", with <path> and <hash>
hyperlinked (and <hash> shortened to 7 characters), and <mode>
explained: '<mode>' is extended to '<mode> (<file type description>)',
where added text is slightly lighter to easy distinguish that it
was added (and it is difference from git-diff output).
* from-file/to-file two-line header lines have slightly darker color
than removed/added lines.
* chunk header has now delicate line above for easier finding chunk
boundary, and top margin of 2px, both barely visible.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of simply hiding control characters in esc_path by replacing
them with '?', use Character Escape Codes (CEC) i.e. alphabetic
backslash sequences like those found in C programming language and
many other languages influenced by it, such as Java and Perl. If
control characted doesn't have corresponding character escape code,
use octal char sequence to escape it.
Alternatively, controls can be replaced with Unicode Control
Pictures U+2400 - U+243F (9216 - 9279), the Unicode characters
reserved for representing control characters when it is
necessary to print or display them.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Extend unquote subroutine, which unquotes quoted and escaped filenames
which git may return, to deal not only with octal char sequence
quoting, but also quoting ordinary characters including '\"' and '\\'
which are respectively quoted '"' and '\', and to deal also with
C escape sequences including '\t' for TAB and '\n' for LF.
Add esc_path subroutine for gitweb quoting and HTML escaping filenames
(currently it does equivalent of ls' --hide-control-chars, which means
showing undisplayable characters (including '\n' and '\t') as '?'
(question mark) character, and use 'span' element with cntrl CSS class
to help rendering them differently.
Convert gitweb to use esc_path correctly to print pathnames.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A forked project is defined to be $projname/$forkname.git for
$projname.git; the code did not check this correctly and mistook
$projname/.git to be a fork of itself. This minimally fixes the
breakage.
Also forks were not checked when index.aux file was in use.
Listing the forked ones in index.aux would show them also on the
toplevel index which may go against the hierarchical nature of
forks, but again this is a minimal fix to whip it in a better
shape suitable to be in the 'master' branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently this code was never tested without "forks". check-feature
returns a one-element list (0) when disabled, and assigning that to a
scalar variable made it to be called in a scalar context, which meant
my $check_forks = gitweb_check_feature("forks") were always 1!
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a file jumps between the file lists due to its state changing we
crashed thanks to a stale variable reference within the procedure as we
tried to setup the new icon.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If there are modified files present in the working directory then we
should not let the user perform a pull as it may fail due to the modified
files being uncommitted but needing to be merged at the file level.
Yes there are many cases where a merge will complete successfully even
though there are modified or untracked files sitting in the working
directory. But users generally shouldn't be attempting merges like that,
and if they are they probably are advanced enough to just use the command
line and bypass this little safety check.
We also no longer run a rescan after a successful pull has completed.
Usually this is unnecessary as a successful pull won't leave modified
files laying around. Instead we just update our HEAD and PARENT values
with the new commit, if there is one.
Unfortunately this does let the user get into an insane state as there
are bugs in core Git's git-pull and git-merge programs where the exit
status is sent back as a 0 rather than non-0 when a failure is detected.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have the index locked then no pull command is allowed to proceed
(as it would fail to get the index lock itself). So disable the pull
menu items when we are doing any index based operations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The user must not modify the index while a git pull operation is running,
doing so might cause problems for the merge driver and specific strategy
being used. Normally on the command line people are just really good and
don't try to run index altering operations while they are also running a
pull. But in a slick GUI like git-gui we can't trust the user quite as
much.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On very large projects (~1000 files) on Windows systems the update-index
--refresh stage of the rescan process takes a nontrival amount of time.
If the user is generally very careful with their file modification such
that the modification timestamp of the file differs only when the content
also differs then we can skip this somewhat expensive step and go right
to the diff-index and diff-files processes.
We save the user's prefernce in the current repository if they modify the
setting during a git-gui session, but we also load it through our dump of
repo-config --list so the user could move it to their ~/.gitconfig file
if they wanted it globally disabled.
We still keep update-index --refresh enabled by default however, as most
users will probably want it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most users of git-gui probably shouldn't be invoking git repack directly;
instead we should be looking at how many loose objects they have and
how many active packs they have and making the decision for them. But
that's more work to code, and there's always going to be discussion about
what is the right default threshold and how do we know that the user is
willing to do the repack when we decide its time, etc.
So instead we'll just keep it simple and offer up the menu option.
Unfortunately right now we get now progress indication back from
git-pack-objects as its being invoked not through a tty, which makes
it disable progress output and the git-repack.sh wrapper won't let us
pass through --progress.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since Tk will only supply new space gained from growing the top level to
the bottom/right most widget within a panedwindow and most users will be
growing a git-gui main window for the purposes of seeing more of the
currently shown diff, flipping the order around makes Tk do what the
user wants by default.
Of course because we also removed the paned window from the commit buffer
area it is now impossible to increase the visible space for the commit
message. But I don't see this as a huge concern right now as its actually
very awkward to try and balance three paned window dividers within the
same top level window. We could always add it back if users really want
to expand the commit buffer and see more.
I also corrected a number of bugs that I accidentally introduced in the
last commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Removed as much as possible from the merge_state proc, which is where
we spent most of our time before UI update. This change makes our
running time match that of git status, except that we then need about
7 additional seconds to draw 6900 files on screen.
Apparently the [array names a -exact $v] operator in Tcl is O(n) rather
than O(1), which is really quite disappointing given that each array can
only have one entry for a given value. Switching to a lookup with a
catch (whose error we ignore) runs in O(1) time and bought us most of
that improvement.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Loading 6900 newly added files required about 90 seconds on one system.
This is just far too long to perform a "status" type of operation.
git-status on the same system completes in just 8.2 seconds if it is
redirected to /dev/null.
Most of our performance improvement comes from moving all of the UI
updating out of the main fileevent handlers for the status process.
Instead we are only updating the file_states array and then only doing
the UI update when all states are known and have been finally determined.
The rescan execution is now down to almost 30 seconds for the same case,
a good (but not really all that impressive) improvement.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we were receiving a lot of output from diff-index we split records
at the wrong locations and started using the file status information
(mode and SHA1s) as path names, and then proceeded to try to use part
of the path names as status data. This caused all sorts of havoc.
So I rewrote the parsing implementation to scan for the pair of null
bytes along the buffer and stop scanning (waiting for more data) if
both can't be found during this event. This seems to work well under
high load (like when processing 6,983 added files).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
With this,
git pickaxe -L '/--progress/,+20' v1.4.0 -- pack-objects.c
gives you 20 lines starting from the first occurrence of
'--progress' in pack-objects, digging from v1.4.0 version.
You can also say
git pickaxe -L '/--progress/,-5' v1.4.0 -- pack-objects.c
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds documentation for --progress and --all-progress, remove a
duplicate --progress handling and make usage string more readable.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In wt-status.c there is a test which does nothing.
This patch removes it.
Signed-off-by: Tero Roponen <teanropo@jyu.fi>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/read-tree:
t6022: ignoring untracked files by merge-recursive when they do not matter
merge-recursive: adjust to loosened "working file clobbered" check
merge-recursive: make a few functions static.
merge-recursive: use abbreviated commit object name.
merge: loosen overcautious "working file will be lost" check.
* np/index-pack:
remove .keep pack lock files when done with refs update
have index-pack create .keep file more carefully
improve fetch-pack's handling of kept packs
git-fetch can use both --thin and --keep with fetch-pack now
Teach receive-pack how to keep pack files based on object count.
Allow pack header preprocessing before unpack-objects/index-pack.
Remove unused variable in receive-pack.
Revert "send-pack --keep: do not explode into loose objects on the receiving end."
missing small substitution
Teach git-index-pack how to keep a pack file.
Only repack active packs by skipping over kept packs.
Allow short pack names to git-pack-objects --unpacked=.
send-pack --keep: do not explode into loose objects on the receiving end.
index-pack: minor fixes to comment and function name
enhance clone and fetch -k experience
mimic unpack-objects when --stdin is used with index-pack
add progress status to index-pack
make index-pack able to complete thin packs.
enable index-pack streaming capability
We now create one menu entry per remote listing the first Pull: or fetch
entry associated with that remote as the branch to pull into the current
branch.
This is actually quite incorrect as we should be using the default
remote branch name listed in branch.<name>.merge for a new-style remote
described in the config file. But its a good default to get started with.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We're likely going to need key/value pairs from the repo-config beyond
just remote.*.url, so cache them all up front into a Tcl array where we
have fast access to them without needing to refork a repo-config --list
process.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user closes a console and we get more ouptut for it then we
will get a Tcl error in the readable event handle for the file channel.
Since this loses the actual output and is quite unfriendly to the end
user instead reopen any console which the user closed prior to the
additional output arriving.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The user might be using the new style config syntax remote.name.url
rather than the older standalone remote file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because the remote end is likely to send us progress meters by
resetting each line with a CR (and no LF) we should display those
meters by replacing the last line of text with the next line,
just like a normal xterm would do.
This makes the output of fetch look about the same as if we ran it
from within an xterm.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently accelerators really only work correctly for function keys
(F1-F12) and "Cmd-q". Apparently wish on Mac OS X reports itself
as unix and the OS is Darwin, this makes it a little difficult to
be sure we are running under Aqua.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we cd after getting the cdup value from Git we can't try
to get the gitdir until after we perform the cd, as usually the
gitdir is relative to the current working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently the Cygwin tclsh/wish executables don't pass the environment
that they inherited onto any children that they invoke. This causes a
problem for some users during 'git fetch' or 'git push' as critical
environment variables like GIT_SSH and SSH_AUTH_SOCK aren't available
to the git processes.
So we work around this by forcing sh to start a login shell, thus
reloading the user's environment, then cd to the current directory,
and finally start the requested process. Of course this won't
correctly handle any transient environment variables that were
inherited but were not supplied by the user's login shell.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Make sure we are in the top level working directory. This
way we can access files using their repository path.
* Reload the diff viewer if the current file's status has changed;
as the diff may now be different.
* Correctly handle the 'AD' file state: added but now gone from
the working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Also fixed a bug related that caused a crash if the file currently
in the diff viewer is no longer modified after the commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We can now commit any type of commit (initial, normal or merge) using
the same techniques as git-commit.sh does for these types of things.
If invoked as git-citool we run exit immediately after the commit was
finished. If invoked as git-gui then we stay running.
Also fixed a bug which caused the commit message buffer to be lost
when the application shutdown and restarted.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
