git-log -g --pretty=oneline should display the reflog message
In the context of reflog output the reflog message is more useful than
the commit message's first line. When relevant the reflog message
will contain that line anyway.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow the tag signing key to be specified in the config file
I did this:
$ git tag -s test-sign
gpg: skipped "Andy Parkins <andyparkins@gmail.com>": secret key not available
gpg: signing failed: secret key not available
failed to sign the tag with GPG.
The problem is that I have used the comment field in my key's UID
definition.
$ gpg --list-keys andy
pub 1024D/4F712F6D 2003-08-14
uid Andy Parkins (Google) <andyparkins@gmail.com>
So when git-tag looks for "Andy Parkins <andyparkins@gmail.com>";
obviously it's not going to be found.
There shouldn't be a requirement that I use the same form of my name in
my git repository and my gpg key - I might want to be formal (Andrew) in
my gpg key and informal (Andy) in the repository. Further I might have
multiple keys in my keyring, and might want to use one that doesn't
match up with the address I use in commit messages.
This patch adds a configuration entry "user.signingkey" which, if
present, will be passed to the "-u" switch for gpg, allowing the tag
signing key to be overridden. If the entry is not present, the fallback
is the original method, which means existing behaviour will continue
untouched.
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
OK, its official, I'm not reading documentation as well as I should be.
Core Git's merge.summary configuration option is used to control the
generation of the text appearing within the merge commit itself. It
is not (and never has been) used to default the --no-summary command
line option, which disables the diffstat at the end of the merge.
I completely blame Git for naming two unrelated options almost the
exact same thing. But its my own fault for allowing git-gui to
confuse the two.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If abbrev is set to zero in git-describe, don't add the unique suffix
When on a non-tag commit, git-describe normally outputs descriptions of
the form v1.0.0-g1234567890
Some scripts (for example the update hook script) might just want to
know the name of the nearest tag, so they then have to do
x=$(git-describe HEAD | sed 's/-g*//')
This is costly, but more importantly is fragile as it is relying on the
output format of git-describe, which we would then have to maintain
forever.
This patch adds support for setting the --abbrev option to zero. In
that case git-describe does as it always has, but outputs only the
nearest found tag instead of a completely unique name. This means that
scripts would not have to parse the output format and won't need
changing if the git-describe suffix is ever changed.
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
fix suggested branch creation command when detaching head
Doing:
$ git checkout HEAD^
Generates the following message:
|warning: you are not on ANY branch anymore.
|If you meant to create a new branch from the commit, you need -b to
|associate a new branch with the wanted checkout. Example:
| git checkout -b <new_branch_name> HEAD^
Of course if the user does as told at this point the created branch
won't be located at the expected commit. Reword this message a bit to
avoid such confusion.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
vc-git.el: Take into account the destination name in vc-checkout.
This is necessary for vc-version-other-window. Based on a patch by Sam
Vilain <sam.vilain@catalyst.net.nz>.
Currently, the vc-git-checkout function uses `git checkout' to fetch a
file from the git repository to the working copy. However, it is
completely ignoring the input argument that specifies the destination
file. `git-checkout' does not support specifying this, so we have to
use `git-cat-file', capture the output in a buffer and then save it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
The file format dictates that entries are LF terminated so
the message cannot have one in it. Chomp the message to make
sure it only has a single line if necessary, while removing the
leading whitespace.
Changed our private merge summary config option to be the same as the
merge.summary option supported by core Git. This means setting the
"Show Merge Summary" flag in git-gui will have the same effect on
the command line.
In the same vein I've also added merge.verbosity to the gui options,
allowing the user to adjust the verbosity level of the recursive
merge strategy. I happen to like level 1 and suggest that other users
use that, but level 2 is the core Git default right now so we'll use
the same default in git-gui.
Unfortunately it appears as though core Git has broken support for
the merge.summary option, even though its still in the documentation
For the time being we should pass along --no-summary to git-merge if
merge.summary is false.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Always offer scrollbars for branch lists.
Anytime we use a listbox to show branch names its possible for the
listbox to exceed 10 entries (actually its probably very common).
So we should always offer a scrollbar for the Y axis on these
listboxes. I just forgot to add it when I defined them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Don't allow merges in the middle of other things.
If the user is in the middle of a commit they have files which are
modified. These may conflict with any merge that they may want
to perform, which would cause problems if the user wants to abort
a bad merge as we wouldn't have a checkpoint to roll back onto.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Don't allow users to commit a bad octopus merge.
If an octopus merge goes horribly wrong git-merge will leave the
working directory and index dirty, but will not leave behind a
MERGE_HEAD file for a later commit. Consequently we won't know
its a merge commit and instead would let the user resolve the
conflicts and commit a single-parent commit, which is wrong.
So now if an octopus merge fails we notify the user that the
merge did not work, tell them we will reset the working directory,
and suggest that they merge one branch at a time. This prevents
the user from committing a bad octopus merge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I got slightly confused when I did two merges in a row, as the status
bar said "merge completed successfully" while the second merge was
still running. Now we show what branches are actively being merged.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Let users abort with `reset --hard` type logic.
If you get into the middle of a merge that turns out to be horrible
and just not something you want to do right now, odds are you need
to run `git reset --hard` to recover your working directory to a
pre-merge state.
We now offer Merge->Abort Merge for exactly this purpose, however
its also useful to thow away a non-merge, as its basically the same
logic as `git reset --hard`.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To allow users to merge local heads and tracking branches we now offer
a dialog which lets the user select 1-15 branches and merge them using
the stock `git merge` Grand Unified Merge Driver.
Originally I had wanted to implement this merge internally within git-gui
as I consider GUMD to be mostly Porcelain-ish, but the truth is it does
its job exceedingly well and its a relatively complex chunk of code.
I'll probably circle back later and try to remove the invocation of GUMD
from git-gui, but right now it lets me get the job done faster.
Users cannot start a merge if they are currently in the middle of one,
or if they are amending a commit. Trying to do either is just stupid
and should be stopped as early as possible.
I've also made it simple for users to startup a gitk session prior to
a merge by offering a Visualize button which runs `gitk $revs --not HEAD`,
where $revs is the list of branches currently selected in the merge
dialog. This makes it quite simple to find out what the damage will
be to the current branch if you were to carry out the currently proposed
merge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio added the found variable to enforce commit date order when two
tags have the same distance from the requested commit. Except it is
unnecessary as match_cnt is already used to record how many possible
tags have been identified thus far.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Older Solaris machines lack stdint.h but have inttypes.h.
The standard has inttypes.h including stdint.h, so at worst
this pollutes the namespace a bit.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
Technically the new git-gc command is strictly Porcelain; its invoking
multiple plumbing commands to do its work. Since git-gui tries to not
rely on Porclain we shouldn't be invoking git-gc directly, instead we
should perform its tasks on our own.
To make this easy I've created console_chain, which takes a list of
tasks to perform and runs them all in the same console window. If
any individual task fails then the chain stops running and the window
shows a failure bar. Only once all tasks have been completed will it
invoke console_done with a successful status.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Refactor console success/failure handling.
Because I want to be able to run multiple output-producing commands
in a single 'console' window within git-gui I'm refactoring the
console handling routines to require the "after" argument of console_exec.
This should specify a procedure to execute which will receive two args,
the first is the console window handle and the second is the status of
the last command (0 on failure, 1 on success).
A new procedure console_done can be passed to the last console_exec
command to forward perform all cleanup and enable the Close button.
Its status argument is used to update the final status bar on the
bottom of the console window.
This isn't any real logic changing, and no new functionality is in
this patch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Right now `git-push -v` is actually not that verbose; it merely adds
the URL it is pushing to. This can be informative if you are pushing
to a configured remote, as you may not actually remember what URL that
remote is connected to. That detail can be important if the push
fails and you attempt to communicate the errors to a 3rd party to help
you resolve the issue.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Remove no longer used pull from remote code.
Because we aren't going to support single click pulling of changes from
an existing remote anytime in the near future, I'm moving the code which
used to perform that action. Hopefully we'll be able to do something
like it in the near-future, but also support local branches just as
easily.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because its common for some users to push topic branches to a remote
repository for review and merging by other parties, users need an
easy way to push one or more branches to a remote repository without
needing to edit their .git/config file anytime their set of active
branches changes.
We now provide a basic 'Push...' menu action in the Push menu which
opens a dialog allowing the user to select from their set of local
branches (refs/heads, minus tracking branches). The user can designate
which repository to send the changes to by selecting from an already
configured remote or by entering any valid Git URL.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Always use lsearch -exact, to prevent globbing.
Anytime we are using lsearch we are doing [lsearch -sorted] and we
are applying it to file paths (or file path like things). Its valid
for these to contain special glob characters, but when that happens
we do not want globbing to occur. Instead we really need exact
match semantics. Always supplying -exact to lsearch will ensure that
is the case.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Maintain the same file list for diff during refresh.
I just noticed that a file was always jumping to compare against HEAD
and the index during a refresh, even if the diff viewer was comparing
the index against the working directory prior to the refresh. The
bug turned out to be caused by a foreach loop going through all file
list names searching for the path. Since $ui_index was the first one
searched and the file was contained in that file list the loop broke
out, leaving $w set to $ui_index when it had been set by the caller
to $ui_workdir. Silly bug caused by using a parameter as a loop
index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
diffcore-pickaxe: fix infinite loop on zero-length needle
The "contains" algorithm runs into an infinite loop if the needle string
has zero length. The loop could be modified to handle this, but it makes
more sense to simply have an empty needle return no matches. Thus, a
command like
git log -S
produces no output.
We place the check at the top of the function so that we get the same
results with or without --pickaxe-regex. Note that until now,
git log -S --pickaxe-regex
would match everything, not nothing.
Arguably, an empty pickaxe string should simply produce an error
message; however, this is still a useful assertion to add to the
algorithm at this layer of the code.
Noticed by Bill Lear.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow non-developer to clone, checkout and fetch more easily.
The code that uses committer_info() in reflog can barf and die
whenever it is asked to update a ref. And I do not think
calling ignore_missing_committer_name() upfront like recent
receive-pack did in the aplication is a reasonable workaround.
What the patch does.
- git_committer_info() takes one parameter. It used to be "if
this is true, then die() if the name is not available due to
bad GECOS, otherwise issue a warning once but leave the name
empty". The reason was because we wanted to prevent bad
commits from being made by git-commit-tree (and its
callers). The value 0 is only used by "git var -l".
Now it takes -1, 0 or 1. When set to -1, it does not
complain but uses the pw->pw_name when name is not
available. Existing 0 and 1 values mean the same thing as
they used to mean before. 0 means issue warnings and leave
it empty, 1 means barf and die.
- ignore_missing_committer_name() and its existing caller
(receive-pack, to set the reflog) have been removed.
- git-format-patch, to come up with the phoney message ID when
asked to thread, now passes -1 to git_committer_info(). This
codepath uses only the e-mail part, ignoring the name. It
used to barf and die. The other call in the same program
when asked to add signed-off-by line based on committer
identity still passes 1 to make sure it barfs instead of
adding a bogus s-o-b line.
- log_ref_write in refs.c, to come up with the name to record
who initiated the ref update in the reflog, passes -1. It
used to barf and die.
The last change means that git-update-ref, git-branch, and
commit walker backends can now be used in a repository with
reflog by somebody who does not have the user identity required
to make a commit. They all used to barf and die.
I've run tests and all of them seem to pass, and also tried "git
clone" as a user whose GECOS is empty -- git clone works again
now (it was broken when reflog was enabled by default).
contrib/emacs/vc-git.el: support vc-version-other-window
Currently, the vc-git-checkout function uses `git checkout' to fetch a
file from the git repository to the working copy. However, it is
completely ignoring the input argument that specifies the destination
file. `git-checkout' does not support specifying this, so we have to
use `git-cat-file', capture the output in a buffer and then save it.
git-gui: Don't switch branches if changing to the current branch.
Its pointless to switch to the current branch, so don't do it. We
are already on it and the current index and working directory should
just be left alone.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Remove Pull menu and cleanup Branch/Fetch/Push menus.
The Pull menu as it stands right now is a really horrible idea. Most
users will have too many branches show up in this menu, and what with
the new globbing syntax for fetch entries we were offering up possible
merging that just isn't really valid. So this menu is dead and will
be rewritten to support better merge capabilities.
The Branch menu shouldn't include a separator entry if there are no
branches, it just looks too damn weird. This can happen in an initial
repository before any branches have been created and before the first
commit.
The Fetch and Push menus should just be organized around their own
menus rather than being given the menu to populate.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Prefer Tk's entry widget over a 1 line text field.
I'm a fool and previously used a text widget configured with a height
of 1 and special bindings to handle focus traversal rather than the
already built (and properly behaved) entry widget.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Pad the database statistics dialog window.
The stat frame was right on the edge of the window on Mac OS X,
making the frame's border blend in with the window border. Not
exactly the effect I had in mind.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Support 'Visualize All Branches' on Mac OS X.
Now that recent versions of gitk (shipping with at least git 1.5.0-rc1
and later) actually accept command line revision specifiers without
crashing on internal Tk errors we can offer the 'Visualize All Branches'
menu item in the Repository menu on Mac OS X.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Force focus to the diff viewer on mouse click.
Apparently a "feature" of Tcl/Tk on Mac OS X is that a disabled text
widget cannot receive focus or receive a selection within it. This
makes the diff viewer almost useless on that platform as you cannot
select individual parts of the buffer.
Now we force focus into the diff viewer when its clicked on with
button 1. This works around the feature and allows selection to
work within the viewer just like it does on other less sane systems,
like Microsoft Windows.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Cleanup end-of-line whitespace in commit messages.
When committing changes its useless to have trailing whitespace on the
end of a line within the commit message itself; this serves no purpose
beyond wasting space in the repository. But it happens a lot on my
Mac OS X system if I copy text out of a Terminal.app window and paste
it into git-gui.
We now clip any trailing whitespace from the commit buffer when loading
it from a file, when saving it out to our backup file, or when making
the actual commit object.
I also fixed a bug where we lost the commit message buffer if you quit
without editing the text region. This can happen if you quit and restart
git-gui frequently in the middle of an editing session.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
New files in git weren't being downloaded during CVS update
If a repository was checked out via git-cvsserver and then later a new
file is added to the git repository via some other method; a CVS update
wasn't fetching the new file.
It would be reported as a new file as
A some/dir/newfile.c
but would never appear in the directory.
The problem seems to be that git-cvsserver was treating these two cases
identically, as "A" type results.
1. New file in repository
2. New file locally
In fact, traditionally, case 1 is treated as a "U" result, and case 2
only is treated as an "A" result. "A", should just report that the file
is added locally and then skip that file during an update as there is
(of course) nothing to send.
In both these cases there is no working revision, so the checking for
"is there no working revision" will return true. The test for case 2
needs refining to say "if there is no working revision and no upstream
revision". This patch does just that, leaving case 1 to be handled by
the normal "U" handler.
I've also updated the log message to more accurately describe the
operation. i.e. that "A" means that content is scheduled for addition;
not that it actually has been added.
Signed-off-by: Andy Parkins <andyparkins@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-gui: Elide CRs appearing in diff output from display.
If we are displaying a diff for a DOS-style (CRLF) formatted file then
the Tk text widget would normally show the CR at the end of every line;
in most fonts this will come out as a square box. Rather than showing
this character we'll tag it with a tag which forces the character to
be elided away, so its not displayed. However since the character is
still within the text buffer we can still obtain it and supply it over
to `git apply` when staging or unstaging an individual hunk, ensuring
that the file contents is always fully preserved as-is.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Just like `git-add --interactive` we can now stage and unstage individual
hunks within a file, rather than the entire file at once. This works
on the basic idea of scanning backwards from the mouse position to
find the hunk header, then going forwards to find the end of the hunk.
Everything in that is sent to `git apply --cached`, prefixed by the
diff header lines.
We ignore whitespace errors while applying a hunk, as we expect the
user's pre-commit hook to catch any possible problems. This matches
our existing behavior with regards to adding an entire file with
no whitespace error checking.
Applying hunks means that we now have to capture and save the diff header
lines, rather than chucking them. Not really a big deal, we just needed
a new global to hang onto that current header information. We probably
could have recreated it on demand during apply_hunk but that would mean
we need to implement all of the funny rules about how to encode weird
path names (e.g. ones containing LF) into a diff header so that the
`git apply` process would understand what we are asking it to do. Much
simpler to just store this small amount of data in a global and replay
it when needed.
I'm making absolutely no attempt to correct the line numbers on the
remaining hunk headers after one hunk has been applied. This may
cause some hunks to fail, as the position information would not be
correct. Users can always refresh the current diff before applying a
failing hunk to work around the issue. Perhaps if we ever implement
hunk splitting we could also fix the remaining hunk headers.
Applying hunks directly means that we need to process the diff data in
binary, rather than using the system encoding and an automatic linefeed
translation. This ensures that CRLF formatted files will be able to be
fed directly to `git apply` without failures. Unfortunately it also means
we will see CRs show up in the GUI as ugly little boxes at the end of
each line in a CRLF file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Only allow Refresh in diff context menu when we have a diff.
There is no reason to attempt refreshing an empty diff viewer, so
the Refresh option of our diff context menu should be disabled when
there is no diff currently shown.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Just as we show the amount of disk space taken by the loose objects,
its interesting to know how much space is taken by the packs directory.
So show that in our Database Statistics dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In the new branch dialog and delete branch dialog we are using the
system default labelframe border settings (whatever those are) and
they look reasonable on both Windows and Mac OS X. But for some
unknown reason to me I used a raised border for the options dialog.
It doesn't look consistent anymore, so I'm switching it to the
defaults.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Implement basic branch switching through read-tree.
If the user selects a different branch from the Branch menu, or asks
us to create a new branch and immediately checkout that branch we
now perform the update of the working directory by way of a 2 way
read-tree invocation.
This emulates the behavior of `git checkout branch` or the behavior
of `git checkout -b branch initrev`. We don't however support the
-m style behavior, where a switch can occur with file level merging
performed by merge-recursive. Support for this is planned for a
future update.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Display database stats (count-objects -v) on demand.
Its nice to know how many loose objects and roughly how much disk space
they are taking up, so that you can guestimate about when might be a
good time to run 'Compress Database'. The same is true of packfiles,
especially once the automatic keep-pack code in git-fetch starts to
be more widely used.
We now offer the output of count-objects -v in a nice little dialog
hung off the Repository menu. Our labels are slightly more verbose
than those of `count-objects -v`, so users will hopefully be able
to make better sense of what we are showing them here.
We probably should also offer pack file size information, and data
about *.idx files which exist which lack corresponding *.pack files
(a situation caused by the HTTP fetch client). But in the latter
case we should only offer the data once we have way to let the user
clean up old and inactive index files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fetch-pack: remove --keep-auto and make it the default.
This makes git-fetch over git native protocol to automatically
decide to keep the downloaded pack if the fetch results in more
than 100 objects, just like receive-pack invoked by git-push
does. This logic is disabled when --keep is explicitly given
from the command line, so that a very small clone still keeps
the downloaded pack as before.
The 100 threshold can be adjusted with fetch.unpacklimit
configuration. We might want to introduce transfer.unpacklimit
to consolidate the two unpacklimit variables, which will be a
topic for the next patch.
ls-remote and clone: accept --upload-pack=<path> as well.
This makes them consistent with other commands that take the
path to the upload-pack program. We also pass --upload-pack
instead of --exec to the underlying fetch-pack, although it is
not strictly necessary.
Documentation: --amend cannot be combined with -c/-C/-F.
We used to get the following confusing error message:
$ git commit --amend -a -m foo
Option -m cannot be combined with -c/-C/-F
This is because --amend cannot be combined with -c/-C/-F, which makes
sense, because they try to handle the same log message in different ways.
So update the documentation to reflect this.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/config.txt: Correct info about subsection name
Contrary to variable values, in subsection names parsing character
escape codes (besides literal escaping of " as \", and \ as \\)
is not performed; subsection name cannot contain newlines.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit c1a4278e switched the "merging checkout" implementation
from 3-way read-tree to merge-recursive, but forgot that
merge-recursive will signal an unmerged state with its own exit
status code. This prevented the clean-up phase (paths cleanly
merged should not be updated in the index) from running.
Git prefers that all log messages are encoding in UTF-8. So now when
git-gui generates the commit message it converts the commit message
text from the internal Tcl Unicode representation into a UTF-8 file.
The file is then fed as stdin to git-commit-tree. I had to start
using a file here rather than feeding the message in with << as
<< uses the system encoding, which we may not want.
When we reload a commit message via git-cat-file we are getting the
raw byte stream, with no encoding performed by Git itself. So unless
the new 'encoding' header appears in the message we should probably
assume it is utf-8 encoded; but if the header is present we need to
use whatever it claims.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since git operates on filenames using the operating system encoding
any data we are receiving from it by way of a pipe, or sending to it
by way of a pipe must be formatted in that encoding. This should
be the same as the Tcl system encoding, as its the encoding that
applications should be using to converse with the operating system.
Sadly this does not fix the gitweb/test file in git.git on Macs;
that's due to something really broken happening in the filesystem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: When possible show the type of an untracked file.
Users may want to know what a file is before they add it to the
repository, especially if its a binary file. So when possible
invoke 'file' on the path and try to get its output. Since
this is strictly advice to the user we won't bother to report
any failures from our attempt to run `file`.
Since some file commands also output the path name they were
given we look for that case and strip it off the front of the
returned output before placing it into the diff viewer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our internal diff viewer displays untracked files to help users see if
they should become tracked, or not. It is not meant as a full file
viewer that handles any sort of input. Consequently it is rather
unreasonable for users to expect us to show them very large files.
Some users may click on a very big file (and not know its very big)
then get surprised when Tk takes a long time to load the content and
render it, especially if their memory is tight and their OS starts to
swap processes out.
Instead we now limit the amount of data we load to the first 128 KiB
of any untracked file. If the file is larger than 128 KiB we display
a warning message at the top of our diff viewer to notify the user
that we are not going to load the entire thing. Users should be able
to recognize a file just by its first 128 KiB and determine if it
should be added to the repository or not.
Since we are loading 128 KiB we may as well scan it to see if the
file is binary. So I've removed the "first 8000 bytes" rule and
just allowed git-gui to scan the entire data chunk that it read in.
This is probably faster anyway if Tcl's [string range] command winds
up making a copy of the data.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Don't show content of untracked binary files.
A binary file can be very large, and showing the complete content of
one is horribly ugly and confusing. So we now use the same rule that
core Git uses; if there is a NUL byte (\0) within the first 8000 bytes
of the file we assume it is binary and refuse to show the content.
Given that we have loaded the entire content of the file into memory
we probably could just afford to search the whole thing, but we also
probably should not load multi-megabyte binary files either.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we got an empty diff its probably because the modification time of
the file was changed but the file content hasn't been changed. Typically
this happens because an outside program modified the file and git-gui
was told to not run 'update-index --refresh', as the user generally
trusts file modification timestamps. But we can also get an empty diff
when a program undos a file change and still updates the modification
timestamp upon saving, but has undone the file back to the same as what
is in the index or in PARENT.
So even if gui.trustmtime is false we should still run a rescan on
an empty diff. This change also lets us cleanup the dialog message
that we show when this case occurs, as its no longer got anything to
do with Trust File Modification Timestamps.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Ignore 'No newline at end of file' marker line.
If one or both versions of the file don't have a newline at the end
of the file we get a line telling us so in the diff output. This
shouldn't be tagged, nor should it generate a warning about not
being tagged.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes the Select All action from our context menus doesn't work
unless the text field its supposed to act on has focus. I'm not
really sure why adding the sel tag requires having focus. It
technically should not be required to update the sel tag membership,
but perhaps there is a bug in Tcl/Tk 8.4.1 on Windows which is
causing this odd behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Don't attempt to tag new file/deleted file headers in diffs.
We don't want to tag these new file/delete file lines, as they aren't
actually that interesting. Its quite clear from the diff itself that
the file is a new file or is a deleted file (as the entire thing will
appear in the diff).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
format-patch: fix bug with --stdout in a subdirectory
We set the output directory to the git subdirectory prefix if one has
not already been specified. However, in the case of --stdout, we
explicitly _don't_ want the output directory to be set. The result was
that "git-format-patch --stdout" in a directory besides the project root
produced the "standard output, or directory, which one?" error message.
Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
[PATCH] honor --author even with --amend, -C, and -c.
Earlier code discarded GIT_AUTHOR_DATE taken from the base
commit when --author was specified. This was often wrong as
that use is likely to fix the spelling of author's name.
git-gui: Force an update-index --refresh on unchanged files.
Its possible for external programs to update file modification dates of
many files within a repository. I've seen this on Windows with a popular
virus scanner, sadly enough. If the user has Trust File Modification
Timestamp enabled and the virus scanner touches a large number of files
it can be annoying trying to clear them out of the 'Changed But Not
Updated' file list by clicking on them one at a time to load the diff.
So now we force a rescan as soon as one such file is found, and for
just that rescan we disable the Trust File Modification Timestamp option
thereby allowing Git to update the modification dates in the index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-svn: remove leading slash when printing removed directories
Not sure why it was there in the first place, we always do our
work relative to the URL we're connected to; even if that URL is
the root of the repository, so the leading slash is pointless...
Lets be consistent when printing things for the user to see.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
sha1_file.c: Avoid multiple calls to find_pack_entry().
We used to call find_pack_entry() twice from read_sha1_file() in order
to avoid printing an error message, when the object did not exist. This
is fixed by moving the call to error() to the only place it really
could be called.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
Separate part of Documentation/config.txt which deals with git config file
syntax into "Syntax" subsection, and expand it. Add information about
subsections, boolean values, escaping and escape sequences in string
values, and continuing variable value on the next line.
Add also proxy settings to config file example to show example of
partially enclosed in double quotes string value.
Parts based on comments by Junio C Hamano, Johannes Schindelin,
config.c, and the smb.conf(5) man page.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This separates the connectivity check into separate codepaths,
one for reachable objects and the other for unreachable ones,
while adding a lot of comments to explain what is going on.
When checking an unreachable object, unlike a reachable one, we
do not have to complain if it does not exist (we used to
complain about a missing blob even when the only thing that
references it is a tree that is dangling). Also we do not have
to check and complain about objects that are referenced by an
unreachable object.
This makes the messages from fsck-objects a lot less noisy and
more useful.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-prune is not safe when run uncontrolled in parallel while
other git operations are creating new objects. To avoid
mistakes, do not run git-prune by default from git-gc.
shallow repository: disable unsupported operations for now.
We currently do not support fetching/cloning from a shallow repository
nor pushing into one. Make sure these are not attempted so that we
do not have to worry about corrupting repositories needlessly.
Make sure git_connect() always give two file descriptors.
Earlier, git_connect() returned the same fd twice or two
separate fds, depending on the way the connection was made (when
we are talking to the other end over a single socket, we used
the same fd twice, and when our end is connected to a pipepair
we used two).
This forced callers who do close() and dup() to really care
which was which, and most of the existing callers got this
wrong, although without much visible ill effect. Many were
closing the same fd twice when we are talking over a single
socket, and one was leaking a fd.
This fixes it to uniformly use two separate fds, so if somebody
wants to close only reader side can just do close() on it
without worrying about it accidentally also closing the writer
side or vice versa.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Protecting 'mature' objects does not make it any safer. We should
admit that git-prune is inherently unsafe when run in parallel with
other operations without involving unwarranted locking overhead,
and with the latest git, even rebase and reset would not immediately
create crufts anyway.