This also adds a hook in the Makefile I can use to automatically
include pointers to documentation for older releases when updating
the pages at http://kernel.org/pub/software/scm/git/docs/.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The documentation still talked about the unnecessary 'safety'
in git-checkout.
Pointed out by Matthias Lederhofer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Here's a patch that I think we can merge right now. There may be
other places that need this, but this at least points out the
three places that read/write working tree files for git
update-index, checkout and diff respectively. That should cover
a lot of it [jc: git-apply uses an entirely different codepath
both for reading and writing].
Some day we can actually implement it. In the meantime, this
points out a place for people to start. We *can* even start with
a really simple "we do CRLF conversion automatically, regardless
of filename" kind of approach, that just look at the data (all
three cases have the _full_ file data already in memory) and
says "ok, this is text, so let's convert to/from DOS format
directly".
THAT somebody can write in ten minutes, and it would already
make git much nicer on a DOS/Windows platform, I suspect.
And it would be totally zero-cost if you just make it a config
option (but please make it dynamic with the _default_ just being
0/1 depending on whether it's UNIX/Windows, just so that UNIX
people can _test_ it easily).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a repository with a large number of refs, the following command line
could easily overflow the command line size limitations
git-rev-list $newref $(git-rev-parse --not --all)
Fortunately, git-rev-list already has the means to cope with this
situation with the --stdin switch
git-rev-parse --not --all | git-rev-list --stdin $newref
Which is exactly what this patch does.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The config variable gc.packrefs is tristate now: "true", "false"
and "notbare", where "notbare" is the default.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use the same --exclude-existing filter as we use for automatic
tag following to avoid overwriting existing tags with replacement
ones the other side created.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Similar to commit eb8381c8, we need to use for_each_reflog() to make
sure we do not miss objects reachable from HEAD reflog.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some of the git-svn tests can fail on fast machines due to a race in
Subversion: if a file is modified in the same second it was checked out
(or in for that matter), Subversion will not consider it modified. This
works around the problem by increasing the timestamp by one second
before each commit.
[jc: with "touch -r -d" replacement from Eric]
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The old text suggested that git-update-server-info only needs to be run
if new tags or branches are created, but not for new commits.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also spawn the the new blameview in the background
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Subtle bugs remained on both Cygwin and Linux that caused the various
window panes to be restored in positions different than where the user
last placed them. Sergey Vlasov posed a pair of suggested fixes to this,
what is done here is slightly different. The basic fix here involves
a) explicitly remembering and restoring the sash positions for the upper
window, and b) using paneconfigure to redundantly set height and width of
other elements. This redundancy is needed as Cygwin Tcl has a nasty habit
of setting pane sizes to zero if their slaves are not configured with a
specific size, but Linux Tcl does not honor the specific size given.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm exporting gitexecdir because git-gui wants to know where
it should install git-gui and git-citool. These belong under
gitexecdir, just like git-diff, as the git wrapper is able to
invoke these commands for the end-user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Change base version to 0.6.
git-gui: Guess our version accurately as a subproject.
git-gui: Handle gitgui tags in version gen.
git-gui: Generate a version file on demand.
git-gui: Rename GIT_VERSION to GITGUI_VERSION.
git-gui: Allow gitexecdir, INSTALL to be set by the caller.
This is the start of the 0.6 series of git-gui. I'm calling it 0.6
(rather than any other value) as I already had a private tag on
one system based on 0.5, and that tag is quite a bit behind this
version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are included as a subproject, such as how git.git carries
us, we want to retain our own version number and not the version
number assigned by git.git's own tags. Consequently we need to
locate the correct tag which applies to our tree content and
its commit lineage.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I've decided to use gitgui-0.5 as the format for tags in the
git-gui repository. The prefix of gitgui was chosen here to
make its namespace different from the namespace used by git
itself, allowing developers to pull both tag namespaces into
the same repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because git-gui is being shipped as a subproject of the main
Git project and will often have a different lifecycle than
the main Git project, we should ship our own version number
in the release tarball rather than relying on the main Git
version file.
Git's master Makefile will invoke our own with the target
dist-version, asking us to save off our GITGUI_VERSION value
into our own version file, so that our GIT-VERSION-GEN script
can recover it at build time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that the decision has been made to treat git-gui as a
subproject, rather than merging it directly into git, we
should use a different substitution for our version value
to avoid any possible confusion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When used as a subproject within git.git our Makefile must honor
the gitexecdir which git.git's Makefile is passing down to us,
ensuring that we install our executables into the libexec chosen
by the end-user or packager.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is a bug with this $git_mode variable which should be 0644
or 0755, but nothing else I think.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It was suggested on the mailing list that being able to use `from`
in any commit to reset the current branch is useful in some types of
importers, such as a darcs importer.
We originally did not permit resetting an existing branch with a
new `from` command during a `commit` command, but this restriction
was only to help debug the hacked up cvs2svn that Jon Smirl was
developing in parallel with git-fast-import. It is probably more
of a problem to disallow it than to allow it. So now we permit a
`from` during any `commit`.
While making the changes required to permit multiple `from`
commands on the same branch, I discovered we no longer needed the
last_commit field to be set to 0 during a reset, so that was removed.
(Reset was originally setting the field to 0 to signal cmd_from()
that it was OK to execute on the branch.)
While poking around in this section of fast-import I also realized
the `reset` command was not working as intended if the corresponding
`from` command was omitted (as allowed by the BNF grammar and the
code). If `from` was omitted we cleared out the tree but we left
the tree SHA-1 and parent commit SHA-1 intact. This is not what
the user intended in this case. Instead they would be trying to
reset the branch to have no parent and to have no tree, making the
branch look new-born during the next commit. We now clear these
SHA-1 values during `reset`, ensuring the branch looks new-born if
`from` does not get supplied.
New test cases for these were also added.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This merges git-gui project of Shawn as a subproject of git.git
at git-gui/ subdirectory.
This merge only melds two histories together. The toplevel Makefile
does not even know about git-gui yet.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is originally from Andy Parkins whose patch used --patchdepth; let's
use -p which is more in line with the underlying git-apply.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
bash: Hide git-fast-import.
fast-import: Add tip about importing renames.
fast-import: Hide the pack boundary commits by default.
The new git-fast-import command is not intended to be invoked
directly by an end user. So offering it as a possible completion
for a subcommand is not very useful.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most users don't need the pack boundary information that fast-import
was printing to standard output, especially if they were calling
it with --quiet.
Those users who do want this information probably want it captured
so they can go back and use it to repack the imported repository.
So dumping the boundary commits to a log file makes more sense then
printing them to standard output.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that git 1.5.0 and later contains a version of gitk that uses
correct geometry on Windows platforms, even if ~/.gitk exists, we
should not delete the user's ~/.gitk to work around the bug. It
is downright mean to remove a user's preferences for another app.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
gitk was saving widget sizes and positions when the main window was
destroyed, which is after all child widgets are destroyed. The cure
is to trap the WM_DELETE_WINDOW event before the gui is torn down. Also,
the saved geometry was captured using "winfo geometry .", rather than
"wm geometry ." Under Linux, these two return different answers and the
latter one is correct.
[jc: credit goes to Brett Schwarz for suggesting the use of "wm protocol";
I also squashed the follow-up patch to remove extraneous -0
from expressions.]
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Quote both file names separately when printing a rename, yielding
something like
"foo" => "bar"
instead of the current
"foo => bar"
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This avoids some code duplication, and yields more readable results
for directory renames.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow setting the path of asciidoc in only one place when creating
the documentation.
Signed-off-by: Dotan Barak <dotanb@dev.mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some of the short help texts that are shown e.g. when running 'git'
without any parameters wrap on a 80-column terminal. They are just
one character over the line. This patch avoids it by decreasing the
number of spaces around the preceding command name from four to
three (on both sides for symmetry).
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't append a space after '--bool', so we can't expect
a regular expression to match the space.
Semi-noticed by Junio C Hamano :)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the alias expansion is prefixed with an exclamation point, treat
it as a shell command which is run using system(3).
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Among the low-level output functions called from flush_one_pair(),
this was the only function that did not take (filepair, options)
as arguments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This file is incomplete, unmaintained, and it doesn't belong in the GIT
package anyway.
A more complete version is already included in the Linux -mm tree and
is about to make its way into mainline RSN.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the support for automatically updating the buffer while editing.
A configuration variable git-blame-autoupdate controls whether this should
be enabled or not.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git-blame use the current buffer contents for the blame, instead of
the saved file. This makes the blame correct even if there are unsaved
changes.
Also added a git-reblame command.
Signed-off-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change installation instructions to using either "(require 'git-blame)"
or appropriate autoload instruction in GNU Emacs init file, .emacs
This required adding "(provide 'git-blame)" at the end of git-blame.el
and adding [preliminary] docstring to `git-blame-mode' function for
consistency (to mark function as interactive in `autoload' we have to
provide docstring as DOCSTRING is third arg, and INTERACTIVE fourth,
and both are optional). `git-blame-mode' is marked to autoload.
While at it ensure that we add `git-blame-mode' to `minor-mode-alist'
only once (in a way that does not depend on `cl' package).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add Emacs Lisp file headers, according to "Coding Conventions" chapter
in Emacs Lisp Reference Manual and Elisp Area Convetions for
EmacsWiki:
http://www.emacswiki.org/cgi-bin/wiki/ElispAreaConventions
Those include: copyright notice, GNU GPL boilerplate, description and
instalation instructions as provided in email and in commit message
introducing git-blame.el, compatibility notes from another email by
David Kågedal about what to change to use it in GNU Emacs 20, and
"git-blame ends here" to detect if file was truncated. First line
includes setting file encoding via first line local variable values
(file variables).
Added comment to "(require 'cl)" to note why it is needed; "Coding
Conventions" advises to avoid require the `cl' package of Common Lisp
extensions at run time.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The way 'git pull' without explicit parameters work were not
explained well in any existing documentation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When refs/remotes/gfi/master and refs/remotes/gfi/HEAD exist,
and the latter is a symref that points at the former, dwim_ref()
resolves string "gfi" to "refs/remotes/gfi/master" as expected,
but dwim_log() does not understand "gfi@{1.day}" and needs to be
told "gfi/master@{1.day}". This is confusing.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than trying to mark the background color of the line numbers
to show which lines have annotated data loaded, we now show a ruler
between the line numbers and the file data. This ruler is just 1
character wide and its background color is set to grey to denote
which lines have annotation ready. I had to make this change as I
kept loosing the annotation marker when a line was no longer colored
as part of the current selection.
We now color the lines blamed on the current commit in yellow, the
lines in the commit which came after (descendant) in red (hotter,
less tested) and the lines in the commit before (ancestor) in blue
(cooler, better tested).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To help clue users into the fact that annotation data arrives
incrementally, and that they should try to locate the region
they want while the tool is running, we jump to the first line
of the first annotation if the user has not already clicked on
a line they are interested in and if the window is still looking
at the very top of the file.
Since it takes a second (at least on my PowerBook) to even generate
the first annotation for git-gui.sh, the user should have plenty of
time to adjust the scrollbar or click on a line even before we get
that first annotation record in, which allows the user to bypass
our automatic jumping.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Using 180 columns worth of screen space to display just 20 columns of
file data and 160 columns worth of annotation information is not
practically useful. Users need/want to see the file data, and have
the anotation associated with it displayed in a detail pane only when
they have focused on a particular region of the file.
Now our file viewer has a small 10-line high pane below the file
which shows the commit message for the commit this line was blamed
on. The columns have all been removed, except the current line
number column as that has some real value when trying to locate an
interesting block.
To keep the user entertained we have a progress meter in the status
bar of the viewer which lets them know how many lines have been
annotated, and how much has been completed. We use a grey background
on the line numbers for lines which we have obtained annotation from,
and we color all lines in the current commit with a yellow background,
so they stand out when scanning through the file. All other lines
are kept with a white background, making the yellow really pop.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since "git log origin/master" uses dwim_log() to match
"refs/remotes/origin/master", it makes sense to do that for
"git log --reflog", too.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, when format-patch outputs more than 9 patches, the numbers
are padded accordingly. Example:
[PATCH 009/167] The 9th patch of a series of 167
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that core Git has "renamed" git-repo-config to git-config,
we should do the same. I don't know how long core Git will
keep the repo-config command, and since git-gui's userbase
is so small and almost entirely on some flavor of 1.5.0-rc2
or later, where the rename has already taken place, it should
be OK to rename now.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
One user that I spoke with recently was confused why the 'Add All'
button did not add all of his 'Changed But Not Updated' files.
The particular files in question were new, and thus not known to
Git. Since the 'Add All' routine only updates files which are
already tracked, they were not added automatically.
I suspect that calling this action 'Add Existing' would be less
confusing, so I'm renaming it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are invoked as `git-foo`, then we should run the `foo` subcommand,
as the user has made some sort of link from `git-foo` to our actual
program code. So we should honor their request.
If we are invoked as `git-gui foo`, the user has not made a link (or
did, but is not using it right now) so we should execute the `foo`
subcommand.
We now can start the single commit UI mode via `git-citool` and also
through `git gui citool`.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If you say "git log -g --relative-date", it is very likely that
you want to see the reflog names in terms of a relative date.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Viewing annotated files is one of those tasks that is relatively
difficult to do in a simple vt100 terminal emulator. The user
really wants to be able to browse through a lot of information,
and to interact with it by navigating through revisions.
Now users can start our file viewer with annotations by running
'git gui blame commit path', thereby seeing the contents of the
given file at the given commit. Right now I am being lazy by
not allowing the user to omit the commit name (and have us thus
assume HEAD).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some reflogs are/were generated without a message; do not plainly
ignore those entries.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
tar archive frontend for fast-import.
Correct spelling of fast-import in docs.
Correct some language in fast-import documentation.
Correct ^0 asciidoc syntax in fast-import docs.
It makes "git reflog [show]" act as
git log -g --pretty=oneline --abbrev-cmit
and is fairly straightforward. So you can just write
git reflog
or
git reflog show
and it will show you the reflog in a nice format.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add -C[NUM] to git-am and git-rebase so that patches can be applied even
if context has changed a bit.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the commit area does not exist, don't save the commit message to
a file, or the window geometry. The reason I'm doing this is I want
to make the main window entirely optional, such as if the user has
asked us to show a blame from the command line. In such cases the
commit area won't exist and trying to get its text would cause an
error.
If we are running without the commit message area, we cannot save
our window geometry either, as the root window '.' won't be a normal
commit window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a minor code cleanup to make working with what used to be the
$single_commit flag easier. Its also to better handle various UI
configurations, depending on command line parameters given by the
user, or perhaps user preferences.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We already replace \n with \\n so that Tk widgets don't start a new
display line with part of a file path which is just unlucky enough
to contain an LF. But then its confusing to read a path whose name
actually contains \n as literal characters. Escaping \ to \\ would
make that case display as \\n, clarifying the output.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users want to navigate the file list shown in our branch browser
windows using the keyboard. So we now support basic traversal
with the arrow keys:
Up/Down: Move the "selection bar" to focus on a different name.
Return: Move into the subtree, or open the annotated file.
M1-Right: Ditto.
M1-Up: Move to the parent tree.
M1-Left: Ditto.
Probably the only feature missing from this is to key a leading part
of the file name and jump directly to that file (or subtree).
This change did require a bit of refactoring, to pull the navigation
logic out of the mouse click procedure and into more generic routines
which can also be used in bindings.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has created (or deleted) a branch through an external tool,
and uses Rescan, they probably are trying to make git-gui update to show
their newly created branch.
So now we load all known heads and update the branch menu during any
rescan operation, just in-case the set of known branches was modified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is an example fast-import frontend, in less than 100 lines
of Perl. It accepts one or more tar archives on the command line,
passes them through gzcat/bzcat/zcat if necessary, parses out the
individual file headers and feeds all contained data to fast-import.
No temporary files are involved.
Each tar is treated as one commit, with the commit timestamp coming
from the oldest file modification date found within the tar.
Each tar is also tagged with an annotated tag, using the basename
of the tar file as the name of the tag.
Currently symbolic links and hard links are not handled by the
importer. The file checksums are also not verified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its spelled 'fast-import', not 'gfi'. Linus and Dscho have both
recently pointed this out to me on the mailing list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Default values for command line options can be saved in .git/config (or the
global ~/.gitconfig). Config option names match the command line option names,
so cvsimport.d corresponds to git-cvsimport -d. One may also set
cvsimport.module to specify a default cvs module name.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Minor documentation improvements, as suggested on the Git mailing
list by Horst H. von Brand and Karl Hasselström.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I wrote this documentation with asciidoc 7.1.2, but apparently
asciidoc 8 assumes ^ means superscript. The solution was already
documented in rev-parse's manpage and is to use {caret} instead.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For commit messages, we should really put the "line_termination" when we
output the character in between different commits, *not* between the
commit and the diff. The diff goes hand-in-hand with the commit, it
shouldn't be separated from it with the termination character.
So this:
- uses the termination character for true inter-commit spacing
- uses a regular newline between the commit log and the diff
We had it the other way around.
For the normal case where the termination character is '\n', this
obviously doesn't change anything at all, since we just switched two
identical characters around. So it's very safe - it doesn't change any
normal usage, but it definitely fixes "git log -z".
By fixing "git log -z", you can now also do insane things like
git log -p -z |
grep -z "some patch expression" |
tr '\0' '\n' |
less -S
and you will see only those commits that have the "some patch expression"
in their commit message _or_ their patches.
(This is slightly different from 'git log -S"some patch expression"',
since the latter requires the expression to literally *change* in the
patch, while the "git log -p -z | grep .." approach will see it if it's
just an unchanged _part_ of the patch context)
Of course, if you actually do something like the above, you're probably
insane, but hey, it works!
Try the above command line for a demonstration (of course, you need to
change the "some patch expression" to be something relevant). The old
behaviour of "git log -p -z" was useless (and got things completely wrong
for log entries without patches).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, when a path that was removed from the working tree was
chosen for update subcommand, you got an error like this:
error: git-resolve.sh: does not exist and --remove not passed
fatal: Unable to process file git-resolve.sh
Signed-off-by: Junio C Hamano <junkio@cox.net>
Quite nonstandard "date -d @11111111 +%s" does not even fail on
OpenBSD but gives the current date in "seconds since epoch"
format, which is useless for the purpose of this test. We want
to make sure that this returns exactly the same input before
proceeding.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'ml/gitk' (early part):
gitk: Use show-ref instead of ls-remote
Make gitk work reasonably well on Cygwin.
gitk - remove trailing whitespace from a few lines.
Not on all platforms are size_t and unsigned long equivalent.
Since I do not know how portable %z is, I play safe, and just
cast the respective variables to unsigned long.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we remove the last reflog in a directory, opendir() would
succeed and we would iterate over its dirents, expecting retval
to be initialized to zero and setting it to non-zero only upon
seeing an error. If the directory is empty, oops!, we do not
have anybody that touches retval.
The problem is because we initialize retval to errno even on
success from opendir(), which would leave the errno unmolested.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
Add a Tips and Tricks section to fast-import's manual.
Don't crash fast-import if the marks cannot be exported.
Dump all refs and marks during a checkpoint in fast-import.
Teach fast-import how to sit quietly in the corner.
Teach fast-import how to clear the internal branch content.
Minor timestamp related documentation corrections for fast-import.
Earlier we only used loose refs to anchor already existing
objects. When cloning from a repository that forked relatively
long time ago from the reference repository, this made the
want/have exchange by fetch-pack to do unnecessary work.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There has been some informative lessons learned in the gfi user
community, and these really should be written down and documented
for future generations of frontend developers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Use sed instead, it comes with cygwin and there is almost no chance of
someone installing a sed with default CRLF lineendings by accident.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently fast-import used to die a horrible death if we
were unable to open the marks file for output. This is
slightly less than ideal, especially now that we dump
the marks as part of the `checkpoint` command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the frontend asks us to checkpoint (via the explicit checkpoint
command) its probably because they are afraid the current import
will crash/fail/whatever and want to make sure they can pickup from
the last checkpoint. To do that sort of recovery, we will need the
current tip of every branch and tag available at the next startup.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Often users will be running fast-import from within a larger frontend
process, and this may be a frequent periodic tool such as a future
edition of `git-svn fetch`. We don't want to bombard users with our
large stats output if they won't be interested in it, so `--quiet`
is now an option to make gfi be more silent.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some frontends may not be able to (easily) keep track of which files
are included in the branch, and which aren't. Performing this
tracking can be tedious and error prone for the frontend to do,
especially if its foreign data source cannot supply the changed
path list on a per-commit basis.
fast-import now allows a frontend to request that a branch's tree
be wiped clean (reset to the empty tree) at the start of a commit,
allowing the frontend to feed in all paths which belong on the branch.
This is ideal for a tar-file importer frontend, for example, as
the frontend just needs to reformat the tar data stream into a gfi
data stream, which may be something a few Perl regexps can take
care of. :)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As discussed on the mailing list, the documentation used here was
not quite accurate. Improve upon it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This was useful when the current recursive was in development, and
the original Python version was still called git-merge-recursive.
Now the synonym has served us well, it is time to move on.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport: (81 commits)
S_IFLNK != 0140000
Don't do non-fastforward updates in fast-import.
Support RFC 2822 date parsing in fast-import.
Minor fast-import documentation corrections.
Remove unnecessary null pointer checks in fast-import.
Correct fast-import timezone documentation.
Correct minor style issue in fast-import.
Correct compiler warnings in fast-import.
Remove --branch-log from fast-import.
Initial draft of fast-import documentation.
Don't support shell-quoted refnames in fast-import.
Reduce memory usage of fast-import.
Include checkpoint command in the BNF.
Accept 'inline' file data in fast-import commit structure.
Reduce value duplication in t9300-fast-import.
Create test case for fast-import.
Support delimited data regions in fast-import.
Remove unnecessary options from fast-import.
Use fixed-size integers when writing out the index in fast-import.
Always use struct pack_header for pack header in fast-import.
...
If not, the binaries get built once with the correct CFLAGS, and then again
with the ones in the Makefile when installing
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If fast-import is being used to update an existing branch of
a repository, the user may not want to lose commits if another
process updates the same ref at the same time. For example, the
user might be using fast-import to make just one or two commits
against a live branch.
We now perform a fast-forward check during the ref updating process.
If updating a branch would cause commits in that branch to be lost,
we skip over it and display the new SHA1 to standard error.
This new default behavior can be overridden with `--force`, like
git-push and git-fetch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since some frontends may be working with source material where
the dates are only readily available as RFC 2822 strings, it is
more friendly if fast-import exposes Git's parse_date() function
to handle the conversion. This way the frontend doesn't need
to perform the parsing itself.
The new --date-format option to fast-import can be used by a
frontend to select which format it will supply date strings in.
The default is the standard `raw` Git format, which fast-import
has always supported. Format rfc2822 can be used to activate the
parse_date() function instead.
Because fast-import could also be useful for creating new, current
commits, the format `now` is also supported to generate the current
system timestamp. The implementation of `now` is a trivial call
to datestamp(), but is actually a whole whopping 3 lines so that
fast-import can verify the frontend really meant `now`.
As part of this change I have added validation of the `raw` date
format. Prior to this change fast-import would accept anything
in a `committer` command, even if it was seriously malformed.
Now fast-import requires the '> ' near the end of the string and
verifies the timestamp is formatted properly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Corrected a couple of header markup lines which were shorter than the
actual header, and made the `data` commands two formats into a named
list, which matches how we document the two formats of the `M` command
within a commit.
Also tried to simplify the language about our decimal integer format;
Linus pointed out I was probably being too specific at the cost of
reduced readability.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is no need to check for a NULL pointer before invoking free(),
the runtime library automatically performs this check anyway and
does nothing if a NULL pointer is supplied.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Andy Parkins and Linus Torvalds both noticed that the description
of the timezone was incorrect. Its not expressed in minutes.
Its more like "hhmm", where "hh" is the number of hours and "mm"
is the number of minutes shifted from GMT/UTC.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This allows you to set up mothership-satellite configuration
more symmetrically and naturally by allowing the globbing
wildcard refspec for git-push. On your satellite machine:
[remote "mothership"]
url = mothership:project.git
fetch = refs/heads/*:refs/remotes/mothership/*
push = refs/heads/*:refs/remotes/satellite/*
You would say "git fetch mothership" to update your tracking
branches under mothership/ to keep track of the progress on the
mothership side, and when you are done working on the satellite
machine, you would "git push mothership" to update their
tracking branches under satellite/. Corresponding configuration
on the mothership machine can be used to make "git fetch satellite"
update its tracking branch under satellite/. on the mothership.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio noticed that I was using a different style in fast-import
for returned pointers than the rest of Git. Before merging this
code into the main git.git tree I'd like to make it consistent,
as this style variation was not intentional.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio noticed these warnings/errors in fast-import when compiling
with `-Werror -ansi -pedantic`. A few changes are to reduce compiler
warnings, while one (in cmd_merge) is a bug fix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The --branch-log option and its associated code hasn't been used in
several months, as its not really very useful for debugging fast-import
or a frontend. I don't plan on supporting it in this state long-term,
so I'm killing it now before it gets distributed to a wider audience.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Completing the 3 core subcommands to git-remote, along with the
names of remotes for 'show' and 'prune' (which take only existing
remotes) is handy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently `git-rebase -m` uses a metadata directory within .git
(.git/.dotest-merge) rather than .dotest used by git-am (and
git-rebase without the -m option). This caused the completion code
to not offer --continue, --skip or --abort when working within a
`git-rebase -m` session.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a first pass at the manpage for git-fast-import.
I have tried to cover the input format in extreme detail, creating a
reference which is more detailed than the BNF grammar appearing in
the header of fast-import.c. I have also covered some details about
gfi's performance and memory utilization, as well as the average
learning curve required to create a gfi frontend application (as it
is far lower than it might appear on first glance).
The documentation still lacks real example input streams, which may
turn out to be difficult to format in asciidoc due to the blank lines
which carry meaning within the format.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The current implementation of shell-style quoted refnames and
SHA-1 expressions within fast-import contains a bad memory leak.
We leak the unquoted strings used by the `from` and `merge`
commands, maybe others. Its also just muddling up the docs.
Since Git refnames cannot contain LF, and that is our delimiter
for the end of the refname, and we accept any other character
as-is, there is no reason for these strings to support quoting,
except to be nice to frontends. But frontends shouldn't be
expecting to use funny refs in Git, and its just as simple to
never quote them as it is to always pass them through the same
quoting filter as pathnames. So frontends should never quote
refs, or ref expressions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It used to be ls-remote on self was the only easy way to grab
the ref information. Now we have show-ref which does not
involve fork and IPC, so use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The gitk gui layout was completely broken on Cygwin. If gitk was started
without previous geometry in ~/.gitk, the user could drag the window sashes
to get a useable layout. However, if ~/.gitk existed, this was not possible
at all.
The fix was to rewrite makewindow, changing the toplevel containers and
the particular geometry information saved between sessions. Numerous bugs
in both the Cygwin and the Linux Tk versions make this a delicate
balancing act: the version here works in both but many subtle variants
are competely broken in one or the other environment.
Three user visible changes result:
1 - The viewer is fully functional under Cygwin.
2 - The search bar moves from the bottom to the top of the lower left
pane. This was necessary to get around a layout problem on Cygwin.
3 - The window size and position is saved and restored between sessions.
Again, this is necessary to get around a layout problem on Cygwin.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
The earlier commit d7b6c3c0 (Aug 15, 2006) introduced this
mismerge when most of the CFLAGS were renamed to BASIC_CFLAGS.
Not that it matters right now, since we do not compile XS
Perl extensions which wanted non GNU subset of ALL_CFLAGS for
compilation, but we should make things consistent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you resize the terminal while less is waiting for input, less
will exit entirely without even showing the output. This is very
noticeable if you do something like "git diff" on a big and
cold-cache tree and git takes a few seconds to think, and then
you resize the window while it's preparing. Boom. No output AT
ALL.
The way to reproduce the problem is to do some pager operation
that takes a while in git, and resizing the window while git is
thinking about the output. Try
git diff --stat v2.6.12..
in the kernel tree to do something where it takes a while for git to start
outputting information.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds three options to 'git-remote add'.
* -f (or --fetch) option tells it to also run the initial "git
fetch" using the newly created remote shorthand.
* -t (or --track) option tells it not to use the default
wildcard to track all branches.
* -m (or --master) option tells it to make the
remote/$name/HEAD point at a remote tracking branch other
than master.
For example, with this I can say:
$ git remote add -f -t master -t quick-start -m master \
jbf-um git://linux-nfs.org/~bfields/git.git/
to
(1) create remote.jbf-um.url;
(2) track master and quick-start branches (and no other); the
two -t options create these two lines:
fetch = +refs/heads/master:refs/remotes/jbf-um/master
fetch = +refs/heads/quick-start:refs/remotes/jbf-um/quick-start
(3) set up remotes/jbf-um/HEAD to point at jbf-um/master so
that later I can say "git log jbf-um"
Or I could do
$ git remote add -t 'ap/*' andy /home/andy/git.git
to make Andy's topic branches kept track of under refs/remotes/andy/ap/.
Other possible improvements I considered but haven't implemented
(hint, hint) are:
* reject wildcard letters other than a trailing '*' to the -t
parameter;
* make -m optional and when the first -t parameter does not
have the trailing '*' default to that value (so the above
example does not need to say "-m master");
* if -m is not given, and -t parameter ends with '*' (i.e. the
above defaulting did not tell us where to point HEAD at), and
if we did the fetch with -f, check if 'master' was fetched
and make HEAD point at it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-merge-recursive wants an null tree as the fake merge base
while producing the merge result tree. The null tree does not
have to be written out in the object store as it won't be part
of the result, and it is a prime example for using the new
pretend_sha1_file() function.
git-blame needs to register an arbitrary data to in-core index
while annotating a working tree file (or standard input), but
git-blame is a read-only application and the user of it could
even lack the privilege to write into the object store; it is
another good example for pretend_sha1_file().
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new interface allows an application to temporarily hash a
small number of objects and pretend that they are available in
the object store without actually writing them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Warning: this changes the semantics.
This makes "git blame" without any positive rev to start digging
from the working tree copy, which is made into a fake commit
whose sole parent is the HEAD.
It also adds --contents <file> option to pretend as if the
working tree copy has the contents of the named file. You can
use '-' to make the command read from the standard input.
If you want the command to start annotating from the HEAD
commit, you need to explicitly give HEAD parameter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Here's another version of git-blame.el that automatically tries to
create a sensible list of colors to use for both light and dark
backgrounds. Plus a few minor fixes.
To use:
1) Load into emacs: M-x load-file RET git-blame.el RET
2) Open a git-controlled file
3) Blame: M-x git-blame-mode
Signed-off-by: Junio C Hamano <junkio@cox.net>
This can be used to compress multiple changesets into one, for example
like
git cvsexportcommit -P cvshead mybranch
without having to do so in git first.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch helps when you accidentally run something like git-clean
in the git directory instead of the work tree.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
hg-to-git.py is able to convert a Mercurial repository into a git one,
and preserves the branches in the process (unlike tailor)
hg-to-git.py can probably be greatly improved (it's a rather crude
combination of shell and python) but it does already work quite well for
me. Features:
- supports incremental conversion
(for keeping a git repo in sync with a hg one)
- supports hg branches
- converts hg tags
Signed-off-by: Stelian Pop <stelian@popies.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Double clicking on the row execs a new blameview with commit hash
as argument.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the repository directory name is in non-ascii, $project needs to be
converted from perl internal to utf-8 because it will be used as
title, page path, and snapshot filename.
use to_utf8() to do the conversion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now offer completion support for git-bisect's subcommands,
as well as ref name completion on the good/bad/reset subcommands.
This should make interacting with git-bisect slightly easier on
the fingers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've recently added --add as an argument to git-config, but I
missed putting it into the earlier round of git-config updates
within the bash completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't offer resolve as a possible subcommand completion. If you
read the top of the script, there is a big warning about how it
will go away soon in the near future. People should not be using it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm lazy. I don't want to type out --prune if bash can do it for
me with --<tab>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently nobody really makes use of git-diff-stages, as nobody
has complained that it is not supported by the git-diff frontend.
Since its likely this will go away in the future, we should not
offer it as a possible subcommand completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I just realized I did not support ref name completion for git-cherry.
This tool is just too useful to contributors who submit patches
upstream by email; completion support for it is very handy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This particular use of git-rebase to remove a single commit or a
range of commits from the history of a branch recently came up on
the mailing list. Documenting the example should help other users
arrive at the same solution on their own.
It also was not obvious to the newcomer that git-rebase is able to
accept any commit for --onto <newbase> and <upstream>. We should
at least minimally document this, as much of the language in
git-rebase's manpage refers to 'branch' rather than 'committish'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The documentation for git-for-each-ref said that the refname variable
would return "the part after $GIT_DIR/refs/", which isn't true.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We at least know that the test as written has a problem in an
environment where "touch '$p'; ls | fgrep '$p'" fails, and have
a clear understand why it fails.
This tests if the filesystem has that particular issue we know "git
add" has a problem with, and skips the test in such an environment.
This way, we might catch issues "git add" might have in other environments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some structs are allocated rather frequently, but were using integer
types which were far larger than required to actually store their
full value range.
As packfiles are limited to 4 GiB we don't need more than 32 bits to
store the offset of an object within that packfile, an `unsigned long`
on a 64 bit system is likely a 64 bit unsigned value. Saving 4 bytes
per object on a 64 bit system can add up fast on any sizable import.
As atom strings are strictly single components in a path name these
are probably limited to just 255 bytes by the underlying OS. Going
to that short of a string is probably too restrictive, but certainly
`unsigned int` is far too large for their lengths. `unsigned short`
is a reasonable limit.
Modes within a tree really only need two bytes to store their whole
value; using `unsigned int` here is vast overkill. Saving 4 bytes
per file entry in an active branch can add up quickly on a project
with a large number of files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This command isn't encouraged (as its slow) but it does exist and
is accepted, so it still should be covered in the BNF.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit 80c797764a.
Back when I committed this, it seemed to be a good idea. People
who always use remote tracking branches can optionally use the
local name they happen to use to specify what to merge, which meant
that I did not have to teach them why we use the name at the remote
side every time they are confused.
But allowing it seems to break other people's scripts. The real
solution is not to allow more ways to express the same thing, but
to educate people to use the right syntax.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/dreflog:
show-branch -g: default to the current branch.
Let git-checkout always drop any detached head
Enable HEAD@{...} and make it independent from the current branch
scan reflogs independently from refs
add reflog when moving HEAD to a new branch
create_symref(): do not assume pathname from git_path() persists long enough
add logref support to git-symbolic-ref
move create_symref() past log_ref_write()
add reflog entries for HEAD when detached
enable separate reflog for HEAD
lock_ref_sha1_basic(): remember the original name of a ref when resolving it
make reflog filename independent from struct ref_lock
Mention git-revert as an alternative to git-reset to revert changes.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using --reference to borrow objects from a neighbouring
repository while cloning, we copy the entire set of refs under
temporary "refs/reference-tmp/refs" space and set up the object
alternates. However, a textual symref copied this way would not
point at the right place, and causes later steps to emit error
messages (which is harmless but still alarming). This is most
visible when using a clone created with the separate-remote
layout as a reference, because such a repository would have
refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master'
as its contents.
Although we do not create symbolic-link based refs anymore, they
have the same problem because they are always supposed to be
relative to refs/ hierarchy (we dereference by hand, so it only
is good for HEAD and nothing else).
In either case, the solution is simply to remove them after
copying under refs/reference-tmp; if a symref points at a true
ref, that true ref itself is enough to ensure that objects
reachable from it do not needlessly get fetched.
Signed-off-by: Junio C Hamano <junkio@cox.net>
format-patch/log/whatchanged all take --not and --all as options
to the internal revlist process. So these should be supported
as possible completions.
gitk takes anything rev-list/log/whatchanged takes, so we should
use complete_revlist to handle its options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because our use of -o nospace prevents bash from adding a trailing space
when a completion is unique and has been fully completed, we need to
perform this addition on our own. This (large) change converts all
existing uses of compgen to our wrapper __gitcomp which attempts to
handle this by tacking a trailing space onto the end of each offered
option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In many cases we know a completion will be unique, but we've disabled
bash's automatic space addition (-o nospace) so we need to do it
ourselves when necessary.
This change adds additional support for new configuration options
added in 1.5.0, as well as some extended completion support for
the color.* family of options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most of these commands are not ones you want to invoke from the
command line on a frequent basis, or have been renamed in 1.5.0 to
more friendly versions, but the old names are being left behind to
support existing scripts in the wild.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we use the nospace option for our completion function for
the main 'git' wrapper bash won't automatically add a space after a
unique completion has been made by the user. This has been pointed
out in the past by Linus Torvalds as an undesired behavior. I agree.
We have to use the nospace option to ensure path completion for
a command such as `git show` works properly, but that breaks the
common case of getting the space for a unique completion. So now we
set IFS=$'\n' (linefeed) and add a trailing space to every possible
completion option. This causes bash to insert the space when the
completion is unique.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new --interactive mode of git-add can be very useful, so users
will probably want to have completion for it.
Likewise the new git-add--interactive executable is actually a
plumbing command. Its invoked by `git add --interactive` and is
not intended to be invoked directly by the user. Therefore we
should hide it from the list of available Git commands.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-show is capable of displaying any file content from any
revision and is the approved Porcelain-ish level method of doing so,
cat-file should no longer be classified as a user-level utility by
the bash completion package.
I'm also classifying the new git-reflog command as plumbing for the
time being as there are no subcommands which are really useful to
the end-user. git-gc already invokes `git reflog expire --all`,
which makes it rather unnecessary for the user to invoke it directly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The short options (-l, -f, -d) for git-branch are rather silly to
include in the completion generation as these options must be fully
typed out by the user and most users already know what the options
are anyway, so including them in the suggested completions does
not offer huge value. (The same goes for git-checkout and git-diff.)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we have a separate reflog on HEAD, show-branch -g without an explicit
parameter defaults to the current branch, or HEAD when it is detached
from branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to refuse leaving a detached HEAD when it wasn't matching an
existing ref so not to lose any commit that might have been performed
while not on any branch (unless -f was provided).
But this protection was completely bogus since it was still possible
to move to HEAD^ while still remaining detached but losing the last
commit anyway if there was one.
Now that we have a proper reflog for HEAD it is best to simply remove
that bogus (and admitedly annoying) protection and simply display the
last HEAD position instead. If one wants to recover a lost detached
state then it can be retrieved from the HEAD reflog.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is to resolve conflicts early in preparation for possible
inclusion of "reflog on detached HEAD" series by Nico, as having
it in 1.5.0 would really help us remove confusion between
detached and attached states.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Its really nice to be able to run a test with -v and automatically
see the "debugging" dump from merge-recursive, especially if we
are actually trying to debug merge-recursive.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My earlier fix (8371234e) to delete renamed tracked files from the
working directory also caused merge-recursive to delete untracked
files that were in the working directory.
The problem here is merge-recursive is deleting the working directory
file without regard for which branch it was associated with. What we
really want to do during a merge is to only delete files that were
renamed by the branch we are merging into the current branch,
and that are still tracked by the current branch. These files
definitely don't belong in the working directory anymore.
Anything else is either a merge conflict (already handled in other
parts of the code) or a file that is untracked by the current branch
and thus is not even participating in the merge. Its this latter
class that must be left alone.
For this fix to work we are now assuming that the first non-base
argument passed to git-merge-recursive always corresponds to the
working directory. This is already true for all in-tree callers
of merge-recursive. This assumption is also supported by the
long time usage message of "<base> ... -- <head> <remote>", where
"<head>" is implied to be HEAD, which is generally assumed to be
the current tree-ish.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Jakub Narebski pointed out the positional notation in git-remote's
documentation was very confusing, especially now that we have 3
supported subcommands. Instead of referring to subcommands by
position, refer to them by name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "git-config --rename-section" implementation would match sections
that are substrings of the section name to be renamed.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Even when --unified=0 is given, the main loop to show the
combined textual diff needs to handle a line that is unchanged
but has lines that were deleted relative to a parent before it
(because that is where the lost lines hang). However, such a
line should not be emitted in the final output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I was reading the tutorial and noticed that we say this:
Also, don't use "git reset" on a publicly-visible branch that
other developers pull from, as git will be confused by history
that disappears in this way.
I do not think this is a good explanation. For example, if we
do this:
(1) I build a series and push it out.
---o---o---o---j
(2) Alice clones from me, and builds two commits on top of it.
---o---o---o---j---a---a
(3) I rewind one and build a few, and push them out.
---o---o---o...j
\
h---h---h---h
(4) Alice pulls from me again:
---o---o---o---j---a---a---*
\ /
h---h---h---h
Contrary to the description, git will happily have Alice merge
between the two branches, and never gets confused.
Maybe I did not want to have 'j' because it was an incomplete
solution to some problem, and Alice may have fixed it up with
her changes, while I abandoned that approach I started with 'j',
and worked on something completely unrelated in the four 'h'
commits. In such a case, the merge Alice would make would be
very sensible, and after she makes the merge if I pull from her,
the world will be perfect. I started something with 'j' and
dropped the ball, Alice picked it up and perfected it while I
went on to work on something else with 'h'. This would be a
perfect example of distributed parallel collaboration. There is
nothing confused about it.
The case the rewinding becomes problematic is if the work done
in 'h' tries to solve the same problem as 'j' tried to solve in
a different way. Then the merge forced on Alice would make her
pick between my previous attempt with her fixups (j+a) and my
second attempt (h). If 'a' commits were to fix up what 'j'
started, presumably Alice already studied and knows enough about
the problem so she should be able to make an informed decision
to pick between what 'j+a' and 'h' do.
A lot worse case is if Alice's work is not at all related to
what 'j' wanted to do (she did not mean to pick up from where I
left off -- she just wanted to work on something different).
Then she would not be familiar enough with what 'j' and 'h'
tried to achieve, and I'd be forcing her to pick between the
two. Of course if she can make the right decision, then again
that is a perfect example of distributed collaboration, but that
does not change the fact that I'd be forcing her to clean up my
mess.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows git-cherry-pick and git-revert to properly identify
themselves in the resulting reflog entries. Earlier they were
recorded as what git-commit has done.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Even when -l is not given from the command line, the repository
may have the configuration variable core.logallrefupdates set,
or an old-timer might have done ": >.git/logs/refs/heads/new"
before running "git branch new". In these cases, the code gave
an uninitialized msg[] from the stack to be written out as the
reflog message.
This also passes a different message when '-f' option is used.
Saying "git branch -f branch some-commit" is a moral equilvalent
of doing "git-reset some-commit" while on the branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, the search for all reflogs depends on the existence of
corresponding refs under the .git/refs/ directory. Let's scan the
.git/logs/ directory directly instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If open_packed_git failed it may have been because the packfile
actually exists and is readable, but some sort of verification
did not pass. In this case open_packed_git left pack_fd filled
in, as the file descriptor is valid. We don't want to leak the
file descriptor, nor do we want to allow someone in the future
to use this packed_git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The default post-commit hook is actually empty; it is the update hook
that sends an email. This patch corrects hooks.txt to reflect that.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
--pretty=o is a valid abbreviation, --pretty=omfg is not
Noticed by: Nicolas Vilz
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Matthias Lederhofer identified a race condition where a Git reader
process was able to locate an object in a packed_git index, but
was then preempted while a `git repack -a -d` ran and completed.
By the time the reader was able to seek in the packfile to get the
object data, the packfile no longer existed on disk.
In this particular case the reader process did not attempt to
open the packfile before it was deleted, so it did not already
have the pack_fd field popuplated. With the packfile itself gone,
there was no way for the reader to open it and fetch the data.
I'm fixing the race condition by teaching find_pack_entry to ignore
a packed_git whose packfile is not currently open and which cannot
be opened. If none of the currently known packs can supply the
object, we will return 0 and the caller will decide the object is
not available. If this is the first attempt at finding an object,
the caller will reprepare_packed_git and try again. If it was
the second attempt, the caller will typically return NULL back,
and an error message about a missing object will be reported.
This patch does not address the situation of a reader which is
being starved out by a tight sequence of `git repack -a -d` runs.
In this particular case the reader will try twice, probably fail
both times, and declare the object in question cannot be found.
As it is highly unlikely that a real world `git repack -a -d` can
complete faster than a reader can open a packfile, so I don't think
this is a huge concern.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because I want to reuse open_packed_git in a context where I don't
want the process to die if the packfile in question is bogus, I'm
changing its behavior to return error("...") rather than die("...")
when it detects something is wrong with the packfile it was given.
Right now we still must die out of use_pack should open_packed_git
fail, as none of use_pack's callers are prepared to handle a failure
from that function.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After staring at the comment and the associated for loop, I
realized the comment was completely bogus. The section of
code its talking about is trying to avoid duplicate mapping
of the same packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is little point in having the linked list insertion code
appearing in install_packed_git, and then again just 30 lines
further down in the same file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since it can be annoying to manually cleanup 40 tracking branches
which were removed by the remote system, 'git remote prune <n>'
can now be used to delete any tracking branches under <n> which
are no longer available on the remote system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I want to reuse the stale branch detection to implement a new
'git remote prune' subcommand. Easiest way to do that is to use
the same logic that 'git remote show' uses to determine the stale
tracking branches, then delete those.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This mainly quiets down warnings when running git svn log.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is shorter than HEAD@{...} and being nameless it has no semantic
issues.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The work in progress to enable separate reflog for HEAD will make it
independent from reflog of any branch HEAD might be pointing to. In
the mean time disallow HEAD@{...} until that work is completed. Otherwise
people might get used to the current behavior which makes HEAD@{...} an
alias for <current_branch>@{...} which won't be the case later.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Converts one use of git-checkout in git-bisect not to say "switching
to branch". It looks like all the other cases it is friendlier to
give notice to the end user.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Those new messages are certainly nice, but there might be cases where
they are simply unwelcome, like when git-commit is used within scripts.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates "git-checkout" to report which branch you are
switching to. Especially for people who do not use __git_ps1
from contrib/completion/git-completion.bash this would give a
friendlier feedback of what is going on, and should make the
reminder message much less scary.
Here is a sample session (the prompt tells which branch I am on).
* I have some local modification and realize that the change deserves
to be on its own new topic branch.
[git.git (master)]$ git diff --stat
git-checkout.sh | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
* So I switch to a new branch. I get a listing of local modifications
and assuring "Switched to a new branch" message.
[git.git (master)]$ git checkout -b jc/checkout
M git-checkout.sh
Switched to a new branch "jc/checkout"
* If I switch back to "master", I get essentially the same.
[git.git (jc/checkout)]$ git checkout master
M git-checkout.sh
Switched to branch "master"
* Detaching head would say which commit I am at and reminds me that
I am not on any branch (not that I would detach my HEAD while keeping
precious local changes around in any real-world workflow -- this is
just a sample session).
[git.git (master)]$ git checkout master^
M git-checkout.sh
Note: you are not on any branch and are at commit "master^"
If you want to create a new branch from this checkout, you may do so
(now or later) by using -b with the checkout command again. Example:
git checkout -b <new_branch_name>
* Coming back to an attached state can lose the detached HEAD, so
I get warned and stopped.
[git.git]$ git checkout master
You are not on any branch and switching to branch 'master'
may lose your changes. At this point, you can do one of two things:
(1) Decide it is Ok and say 'git checkout -f master';
(2) Start a new branch from the current commit, by saying
'git checkout -b <branch-name>'.
Leaving your HEAD detached; not switching to branch 'master'.
* Moving around while my HEAD is detached is Ok. I still get the list
of local modifications.
[git.git]$ git checkout master^0
M git-checkout.sh
* The previous step that switched to the tip commit is an obscure but
useful trick. My HEAD is still detached but now it is pointed at by
an existing ref, so I can come back safely.
[git.git]$ git checkout master
M git-checkout.sh
Switched to branch "master"
* And we are back on the "master" branch.
[git.git (master)]$ exit
Signed-off-by: Junio C Hamano <junkio@cox.net>
It does not seem to need it either and gives an error on FC5 I use
at kernel.org to cut documentation tarballs, so remove it in the
meantime.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is in the hope of giving JBF's user-manual wider exposure.
I am not very happy with trailing whitespaces in the new
document, but let's not worry too much about the formatting
issues for now, but concentrate more on the structure and the
contents.
The last test in t9200 wants to see if executable bit is
retained, which has no chance of succeeding on a filesystem that
does not handle executable bit correctly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For the purpose of this test we do not really care if the paths
are in latin-1, but people on Cygwin seem to be having problem
on foreign-looking pathnames that do not play well with their
locale.
Let's try to re-code them in UTF-8 and see who screams,
thanks, or reports no-improvements.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the index wasn't clean, git-rebase would simply show the output from
git-diff-index with no further comment to the user.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In particular, it fixes the following (typical for cygwin) problem:
$ git-update-index --chmod=-x ../wrapper/Jamfile
fatal: git-update-index: cannot chmod -x '../wrapper/Jamfile'
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recent commit ae1dffcb28 by Junio
changed the way --upload-pack was passed around between clone,
fetch and ls-remote and modified the handling of the command
line parameter parsing.
Unfortunately FreeBSD 6.1 insists that the expression
expr --upload-pack=git-upload-pack : '-[^=]*=\(.*\)'
is illegal, as the --upload-pack option is not supported by their
implementation of expr.
Elsewhere in Git we use z as a leading prefix of both arguments,
ensuring the -- isn't seen by expr.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Apparently if we are unable to parse an object update-server-info
coredumps, as it doesn't bother to check the return value of its
call to parse_object.
Instead of coredumping, skip the ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is not meant to frighten people or even to suggest they might be
doing something wrong, but rather to notify them of a state change and
provide a likely option in the case this state was entered by mistake.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... which I broke when we introduced user.signingkey configuration.
There was no reason to add a new variable keyid to the script.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'd like complete gitweb setup instructions some day, but for now just
refer to the gitweb README.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
git-fast-import requires use of inttypes.h, but the master branch has
added it to git-compat-util differently than git-fast-import originally
had used it. This merge back of master to the fast-import topic is to
get (and use) inttypes.h the way master is using it.
This is a partially evil merge to remove the call to setup_ident(),
as the master branch now contains a change which makes this implicit
and therefore removed the function declaration. (commit 01754769).
Conflicts:
git-compat-util.h
Fix blameview to use git-cat-file to read the file content.
This make sure we show the right content when we have modified
file in the working directory which is not committed.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... with:
$ git fetch ${remote} HEAD
Also
$ git fetch ${remote} :${localref}
worked, but
$ git fetch ${remote} HEAD:{localref}
didn't. Now both are equivalent.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
rfc2047 unquoter spitted out an annoying "- unquoted" which was
added during debugging but I forgot to remove.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier change df391b192 to rename fsck-objects to fsck broke
fsck-objects. This should fix it again.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
To help the user visually see which lines are associated with each other
in the file we attempt to sign a unique background color to each commit
and then render all text associated with that commit using that color.
This works out OK for a file which has very few commits in it; but
most files don't have that property.
What we really need to do is look at what colors are used by our
neighboring commits (if known yet) and pick a color which does not
conflict with our neighbor. If we have run out of colors then we
should force our neighbor to recolor too. Yes, its the graph coloring
problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Using a panedwindow to display the blame viewer's individual columns
just doesn't make sense. Most of the important data fits within the
columns we have allocated, and those that don't the leading part fits
and that's good enough. There are just too many columns within this
viewer to let the user sanely control individual column widths. This
change shouldn't really be an issue for most git-gui users as their
displays should be large enough to accept this massive dump of data.
We now also have a properly working horizontal scrollbar for the
current file data area. This makes it easier to get away with a
narrow window when screen space is limited, as you can still scroll
around within the file content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I started to get confused about what each column meant in the blame
viewer, and I'm the guy who wrote the code! So now git-gui hints to
the user about what each column is by drawing headers at the top.
Unfortunately this meant I had to use those dreaded frame objects
which seem to cause so much pain on Windows.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we annotate a file and show its line data, we're already asking
for copy and movement detection (-M -C). This costs extra time, but
gives extra data. Since we are asking for the extra data we really
should show it to the user.
Now the blame UI has two additional columns, one for the original
filename (in the case of a move/copy between files) and one for the
original line number of the current line of code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We used to use lock_any_ref_for_update() because the command
needs to also update HEAD (which is not under refs/, so
lock_ref_sha1() cannot be used). The function however did not
check for refs with illegal characters in them.
Use check_ref_format() to catch malformed refs. For this check,
we specifically do not want to say having less than two levels
in the name is illegal to allow HEAD (and perhaps other special
refs in the future).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Anytime are about to open a pipe on what may be user data we need to
make sure the value is escaped correctly into a Tcl list, so that the
executed subprocess will receive the right arguments. For the most
part we were already doing this correctly, but a handful of locations
did not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we run blame incrementally in the background we might as well get
as much data as we can from the file. Adding -M and -C definately makes
it take longer to compute the revision annotations, but since they are
streamed in and updated as they are discovered we'll get recent data
almost immediately anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users may need to be able to alter their user.name or user.email
configuration settings. If they are mostly a git-gui user they
should be able to view/set these important values from within
the git-gui environment, rather than needing to edit a raw text
file on their local filesystem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than using HEAD for the current branch, use the actual name of
the current branch in the browser. This way the user knows what a
browser is browsing if they open up different browsers while on different
branches.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Real icons which seem to indicate going up to the parent (an up arrow)
and a subdirectory (an open folder). Files are now drawn with the
file_mod icon, like a modified file is. This just looks better as it
is more consistent with the rest of our UI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Document Junio's show-branch trick for finding out which tags are
descendents of a given comit.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I still really want a section on interoperability with CVS, subversion,
etc., but I'm not getting around to it very fast, so just add this to
the TODO section for now. And a few other minor todo updates.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Add a brief discussion of reflogs. Also recovery of dangling commits
seems to fit in here, so move some of the discussion out of Linus's
email to here.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
This rather huge change provides a browser for the current branch. The
browser simply shows the contents of tree HEAD, and lets the user drill
down through the tree. The icons used really stink, as I just copied in
icon which we already had. I really need to replace the file_dir and
file_uplevel icons with something more useful.
If the user double clicks on a file within the browser we open it in
a blame viewer. This makes use of the new incremental blame feature
that Linus just added yesterday to core Git. Fortunately the feature
will be in 1.5.0 final so we can rely on having it available here.
Since the blame engine is incremental the user will get blame data
for groups which can be determined early. Git will slowly fill in
the remaining lines as it goes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Running on Cygwin is different than if we were running through MinGW.
In the Cygwin case we have cygpath available to us, we need to perform
UNIX<->Windows path translation sometimes, and we need to perform odd
things like spawning our own login shells to perform network operations.
But in the MinGW case these don't occur. Git knows native Windows file
paths, and login shells may not even exist.
Now git-gui will avoid running cygpath unless it knows its on Cygwin.
It also uses a different shortcut type when Cygwin is not present, and
it avoids invoking /bin/sh to execute hooks if Cygwin is not present.
This latter part probably needs more testing in the MinGW case.
This change also improves how we start gitk. If the user is on any type
of Windows system its known that gitk won't start right if ~/.gitk exists.
So we delete it before starting if we are running on any type of Windows
operating system. We always use the same wish executable which launched
git-gui to start gitk; this way on Windows we don't have to jump back to
/bin/sh just to go into the first wish found in the user's PATH. This
should help on MinGW when we probably don't want to spawn a shell just
to start gitk.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users may want to be able to read Git documentation, even if they
are not command line users. There are many important concepts and
terms covered within the standard Git documentation which would be
useful to even non command line using people.
We now try to offer an 'Online Documentation' menu option within the
Help menu. First we try to guess to see what browser the user has
setup. We default to instaweb.browser, if set, as this is probably
accurate for the user's configuration. If not then we try to guess
based on the operating system and the available browsers for each.
We prefer documentation which is installed parallel to Git's own
executables, e.g. `git --exec-path`/../Documentation/index.html, as
that is how I typically install the HTML docs. If those are not found
then we open the documentation published on kernel.org.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Direct editing of config files may be more natural for users than using
the git-config commandline; but we should still reference the
git-config man page when we describe such editing, so people know where
to go for details on the config file syntax and meanings of the
variables.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Looks like we're going to allow git-config as the preferred alias to
git-repo-config, so let's document that instead.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Initial import of fsck and dangling objects discussion, mostly lifted from
an email from Linus.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I know it's only an example, but having this might save someone else the
trouble of writing an enhanced version for themselves.
It basically does the same job as the old update hook, but with these
differences:
* The recipients list is read from the repository config file from
hooks.mailinglist
* Updating unannotated tags can be allowed by setting
hooks.allowunannotated
* Announcement emails (via annotated tag creation) can be sent to a
different mailing list by setting hooks.announcelist
* Output email is more verbose and generates specific content depending
on whether the ref is a tag, an annotated tag, a branch, or a
tracking branch
* The email is easier to filter; the subject line is prefixed with
[SCM] and a project description pulled from the "description" file
* It catches (and displays differently) branch updates that are
performed with a --force
Obviously, it's nothing that clever - it's the update hook I use on my
repositories but I've tried to keep it general, and tried to make the
output always relevant to the type of update.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I got bitten because in the UK (where one would expect 1970-01-01 00:00
to be UTC 0) some politicians decided to mess around with daylight
savings time from 1968 to 1971; it was permanently BST (+0100). That
means that on my computer the following is true:
$ date --date="1970-01-01 00:00" +"%F %T %z (%Z)"
1970-01-01 00:00:00 +0100 (BST)
This of course means that the --date argument to date is specified in
local time, not UTC. So when the hooks--update script does this:
date=$(date --date="1970-01-01 00:00:00 $ts seconds")
It's actually saying (in my timezone) "1970-01-01 01:00:00 UTC" + $ts.
Clearly this is wrong. The UNIX epoch started at midnight UTC not 1am
UTC.
This leads to the tagged time in hooks--update being shown as one hour
earlier than the true tagged time (in my timezone). The problem would
be worse for other timezones. For a +1300 timezone on 1970-01-01, the
tagged time would be 13 hours earlier. Oops.
The solution is to force the reference time to UTC, which is what this
patch does. In my timezone:
$ date --date="1970-01-01 00:00 +0000" +"%F %T %z (%Z)"
1970-01-01 01:00:00 +0100 (BST)
Much better.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Love it or hate it, some people actually still program in Tcl. Some
of those programs are meant for interfacing with Git. Programs such as
gitk and git-gui. It may be useful to have Tcl-safe output available
from for-each-ref, just like shell, Perl and Python already enjoy.
Thanks to Sergey Vlasov for pointing out the horrible flaws in the
first and second version of this patch, and steering me in the right
direction for Tcl value quoting.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows pushing over the git:// protocol, and while it's not
authenticated, it could make sense from within a firewalled
setup where nobody but trusted internal people can reach the git
port. git-daemon is possibly easier and faster to set up in the
kind of situation where you set up git instead of CVS inside a
company.
"git-receive-pack" is disabled by default, so you need to enable it
explicitly by starting git-daemon with the "--enable=receive-pack"
command line argument, or by having your config enable it automatically.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* The description of valid colour specifications was rather
incomplete, so fix it so that it actually describes colour specs as
accepted by color_parse().
* The list of colour items allowed in color.diff.BLAH was missing the
`commit' and `whitespace' entries.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Starting a pager defeats the purpose of the incremental output
mode. This changes git-blame to only paginate if --incremental
was not given.
git -p blame --incremental still starts the pager, though.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Being lazy to rely on the cycling N buffers mkpath() and friends
return is nice in general, but it makes it too easy to introduce
new bugs that are "mysterious".
Introduction of read_ref() in create_symref() after calling
git_path() to get the git_HEAD value (i.e. the path to create a
new symref at) consumed more than the available buffers and
broke a later call to mkpath() that derives lockpath from it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This doesn't change the code at all. It is done to make the next patch
more obvious.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If HEAD is tied to a branch then both logs/HEAD and logs/heads/<branch> are
updated. This is also true for any symbolic refs in general, but only HEAD
will see its reflog created automatically.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A ref might be pointing to another ref but only the name of the last ref
is remembered. Let's remember about the first name as well.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows for ref_log_write() to be used in a more flexible way,
and is needed for future changes.
This is only code reorg with no behavior change.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My prior change to git-describe attempts to print the distance
between the input commit and the best matching tag, but this distance
was usually only an estimate as we always aborted revision walking
as soon as we overflowed the configured limit on the number of
possible tags (as set by --candidates).
Displaying an estimated distance is not very useful and can just be
downright confusing. Most users (heck, most Git developers) don't
immediately understand why this distance differs from the output
of common tools such as `git rev-list | wc -l`. Even worse, the
estimated distance could change in the future (including decreasing
despite no rebase occuring) if we find more possible tags earlier
on during traversal. (This could happen if more tags are merged
into the branch between queries.) These factors basically make an
estimated distance useless.
Fortunately we are usually most of the way through an accurate
distance computation by the time we abort (due to reaching the
current --candidates limit). This means we can simply finish
counting out the revisions still in our commit queue to present
the accurate distance at the end. The number of commits remaining
in the commit queue is probably less than the number of commits
already traversed, so finishing out the count is not likely to take
very long. This final distance will then always match the output of
`git rev-list | wc -l`.
We can easily reduce the total number of commits that need to be
walked at the end by stopping as soon as all of the commits in the
commit queue are flagged as being merged into the already selected
best possible tag. If that's true then there are no remaining
unseen commits which can contribute to our best possible tag's
depth counter, so further traversal is useless.
Basic testing on my Mac OS X system shows there is no noticable
performance difference between this accurate distance counting
version of git-describe and the prior version of git-describe,
at least when run on git.git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you get two different describes at different
times from a non-rewinding branch and they both come up with the same
tag name, you can tell which is the 'newer' one by distance. This is
rather common in practice, so its incredibly useful.
[jc: still needs documentation and fixups when traversal gives up
early.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise a pathname that has funny characters such as LF would
screw up the parsing programs of the output.
Strictly speaking, this is not backward compatible, but the
current output for pathnames that have embedded LF and such
cannot be sanely parsed anyway, and pathnames that only use
characters from the portable pathname character set won't be
affected.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --incremental option to help GUI porcelains to show
the result from git-blame incrementally. The output gives the
origin information in the same format as the porcelain format.
The first line has commit object name, the line number of the
first line in the group in the original file, the line number of
that file in the final image, and number of lines in the group.
Then subsequent lines show the metainformation for the commit
when the commit is shown for the first time, except the filename
information is always shown (we cannot even make it conditional
to -C option as blame always follows the renaming of the file
wholesale).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Back when only handful commands that created commit and tag were
the only users of committer identity information, it made sense
to explicitly call setup_ident() to pre-fill the default value
from the gecos information. But it is much simpler for programs
to make the call automatic when get_ident() is called these days,
since many more programs want to use the information when updating
the reflog.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
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>
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>
Keep git remote discussion in the first chapter, but postpone
lower-level git fetch usage (to fetch individual branches) till later.
Import a bunch of slightly modified text from the readme to give an
architectural overview at the end.
Add more discussion of history rewriting.
And a bunch of other miscellaneous changes....
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
It received the return value from xwrite() in a size_t variable
'written' and expected comparison with 0 would catch an error
from xwrite().
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
It used to throw potentially multi-line log message at reflog.
Just record the heads that were given to be merged at the command
line and the action.
Revert the removal of the check in "git-update-ref -m" I made earlier
which was only a work-around for this.
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
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>
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>
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>
Document the recommended way to prime a repository with tons of
references with 'pack-refs --all -prune'.
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>
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>
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>
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>
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>
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>
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).
But this definitely needs extra sets of eyeballs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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: Junio C Hamano <junkio@cox.net>
Do *NOT* try this on a repository you care about:
git pack-refs --all --prune
git pack-refs
because while the first "pack-refs" does the right thing, the second
pack-refs will totally screw you over.
This is because the second one tries to pack only tags; we should
also pack what are already packed -- otherwise we would lose them.
[jc: with an additional test]
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
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>
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>
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>
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>
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>
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>
This introduces the config item remote.<name>.uploadpack to override the
default value (which is "git-upload-pack").
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
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>
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>
This allows transfer.unpackLimit to specify what these two
configuration variables want to set.
We would probably want to deprecate the two separate variables,
as I do not see much point in specifying them independently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With --keep-auto option, fetch-pack decides to keep the pack
without exploding it just like receive-pack does.
We may want to later make this the default.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
[jc: original motivation from Uwe]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Just some option name disambiguation. This is the counter part to
commit d23842fd which made a similar change for push and send-pack.
--exec continues to work.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
A short-hand "-g" for "git log --walk-reflogs" and "git
show-branch --reflog" makes it easier to access the reflog
info.
[jc: added -g to show-branch for symmetry]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/config.txt:
Variable value ending in a '`\`' is continued on the next line in the
customary UNIX fashion.
Test it.
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
This newline is stupid; it doesn't get put here unless the file
is very large, and then its just sort of out of place.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
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>
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>
Although unusual, tags can point at any object. Warning only
once is fine, but warning every time about the same tag gets
annoying.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
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>
An earlier commit ded9f400 added $opt_a support to disable the
cvsps grace period mechanism, but forgot to tell the option
parser about it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
which happens if you use ActiveState Perl and a
pipe workaround specially for it.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise it tries to tie it to a scalar and complains about missing
method. Dunno why, may be ActiveState brokenness again.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also add "git" to the pipe parameters, otherwise it does not work at all, as
no git commands are usable out of git context.
Signed-off-by: Alex Riesen <raa.lkml@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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
This reverts commit 9b088c4e39.
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.
Marco Candrian noticed that one cat-file example refers to a
blob object that is never used in the example sequence.
The bug is interesting in that the output from the botched
sample command is consistent with the incorrect blob object
name ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
We sometimes see a mode line show up in a diff if the file mode was
changed. But its not something we format specially.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It appears git-gc will no longer prune automatically, so we don't
need to tell people not to do other stuff while running it.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
If we are making an initial commit our branch head did not exist when
we scanned for all heads during startup. Consequently we won't have
it in our branch menu. So force it to be put there after the ref was
created.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I didn't really like the way a new git-gui launched in a new repository
as the window geometry wasn't quite the best layou. So this is a minor
tweak to try and get space distributed around the window better.
By decreasing the widths we're also able to shrink the gui smaller
without Tk clipping content at the edge of the window. A nice feature.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Up until now git-gui did not support the new wildcard syntax used to
fetch any remote branch into a tracking branch during 'git fetch'. Now
if we identify a tracking branch as ending with the string '/*' then
we use for-each-ref to print out the reference names which may have
been fetched by that pattern. We also now correctly filter any
tracking branches out of refs/heads, if they user has placed any there.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the user selects a starting revision from one of our offered popup
lists (local branches or tracking branches) or enters in an expression
in the expression input field we should automatically activate the
corresponding radio button for them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user is tabbing through fields in the options dialog they are
likely to want to just enter a new value for the field, rather than
edit the value in-place. This is easier if we select the entire value
upon focusing into the field.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are in a dialog such as the new branch dialog or our options
dialog we should permit the user to traverse around through the available
widgets with their Tab/Shift-Tab key combinations. So in any single
line text field where we don't want tab characters to actually be
inserted into the value rebind Tab and Shift-Tab to honor what the
tk_focusPrev and tk_focusNext scripts recommend.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Typically I'm creating all new branches with the same prefix, e.g. 'sp/'.
So its handy to be able to setup a repository (or global) level config
option for git gui which contains this initial prefix. Once set then
git-gui will load it into the new branch name field whenever a new
branch is being created.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
New branches must have a name. An empty one is not a valid ref, but the
generic message "We do not like '' as a branch name." is just too vague
or difficult to read. So detect the missing name early and tell the
user it must be entered.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I refactored the common code related to tracking branch listing into
a new procedure all_tracking_branches. This saves a few lines and
should make the create and delete dialogs easier to maintain.
We now don't offer a radio button to create from a tracking branch
or merge-check a tracking branch if there are no tracking branches
known to git-gui. This prevents us from creating an empty option
list and letting the user try to shoot themselves in the foot by
asking us to work against an empty initial revision.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some of my file paths in some of my repositories are very long, this
is rather typical in Java projects where the path name contains a deep
package structure and then the file name itself is rather long and
(hopefully) descriptive. Seeing these paths line wrap in the file lists
looks absolutely horrible. The entire rendering is almost unreadable.
Now we draw both horizontal and vertical scrollbars for both file lists,
and we never line wrap within the list text itself.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because users who use git-gui are likely to also be using gitk, we
should at least match gitk's default colors and formatting within the
diff viewer.
Unfortunately this meant that I needed to change the background colors
of the hunks in a 'diff --cc' output, as the green used for 'added line'
was completely unreadable on the old color. We now use ivory1 to show
hunks which came from HEAD/parent^1, which are the portions that the
current branch has contributed, and are probably the user's own changes.
We use a very light blue for the portions which came from FETCH_HEAD,
as this makes the changes made by the other branch stand out more in the
diff.
I've also modified the hunk header lines to be blue, as that is how gitk
is showing them.
Apparently I forgot to raise the sel tag above everything else in the
diff viewer, which meant that selections in the diff viewer were not
visible if they were made on a 'diff --cc' hunk which had a background.
Its now the higest priority tag, ensuring the selection is always visible
and readable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a path is really unmerged, such as because it has been deleted and
also modifed, we cannot obtain a diff for it. Instead Git is sending
back '* Unmerged path <blah>' for file <blah>. We should display this
line as-is as our tag selecting switches don't recognize it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has not added any files yet they cannot commit. But
telling them this isn't an error, its really just an informational
note meant to push the user in the correct direction.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Just like how we split out the local and remote branches into two
different pick lists for branch creation, we should do the same
thing for branch deletion. This means that there are really 3
modes of operation here:
* delete only if merged into designated local branch;
* delete only if merged into designated tracking (remote) branch;
* delete no matter what
So we now use radio buttons to select between these operations.
We still default to checking for merge into the current branch,
as that is probably the most commonly used behavior. It also is
what core Git's command line tools do.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Using a stack of frames in the Starting Revision section of the new
branch dialog turned out to be a mess. The varying lengths of each
label caused the optionMenu widgets to be spread around the screen
at unaligned locations, making the interface very kludgy looking.
Now we layout the major sections of the branch dialog using grid
rather than pack, allowing these widgets to line up vertically in
a nice neat column. All extra space is given to column 1, which is
where we have located the text fields.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The new branch name input box was showing up too close to the labelframe
border, it was basically right on top of it on Windows. This didn't
look right when compared to the Starting Revision's expression input
field, as that had a 5 pixel padding.
So I've put the new name input box into its own frame and padded that
frame by 5 pixels, making the UI more consistent.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its impossible to commit an index which has unmerged stages.
Unfortunately a bug in git-gui allowed the user to try to do exactly that,
as we broke out of our file scanning loop as soon as we found a valid AMD
index state. That's wrong, as the files are coming back from our array
in pseudo-random order; an unmerged file may get returned only after all
merged files.
I also noticed the grammer around here in our dialog boxes still used
the term 'include', so this has been updated to reflect current usage.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes you want to just force the diff to redisplay itself without
rescanning every file in the filesystem (as that can be very costly
on large projects and slow operating systems). Now you can force a
diff-only refresh from the context menu. Previously you could also
do this by reclicking on the file name in the UI, but it may not be
obvious to all users, having a context menu option makes it more
clear.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A prior commit tried to use the old index state for the old working
directory state during a UI refresh of a file. This caused files
which were being unstaged (and thus becoming unmodified) to drop
out of the working directory side of the display, at least until
the user performed a rescan to force the UI to redisplay everything.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user switches the currently shown file from one side of the UI
to the other then how its diff is presented would be different. And
leaving the old diff up is downright confusing.
Since the diff is probably not interesting to the user after the switch
we should just clear the diff viewer. This saves the user time, as they
won't need to wait for us to reload the diff.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We were not correctly setting the old state of an index display to
_ if the index was previously unmerged. This caused us to try and
update a U->M when resolving a merge conflict but we were unable to
do so as the icon did not exist in the index viewer. Tk did not
like being asked to modify an icon which was undefined.
Now we always transform both the old and the new states for both
sides (index and working directory) prior to updating the UI.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we are using 'git diff' to display unmerged working directory
files we are getting 'diff --cc' output rather than 'diff --combined'
output. Further the markers in the first two columns actually make
sense here, we shouldn't attempt to rewrite them to something else.
I've added 'diff --cc *' to the skip list in our diff viewer, as that
particular line is not very interesting to display.
I've completely refactored how we perform detection of the state of a
line during diff parsing; we now report an error message if we don't
understand the particular state of any given line. This way we know
if we aren't tagging something we maybe should have tagged in the UI.
I've also added special display of the standard conflict hunk markers
(<<<<<<<, =======, >>>>>>>). These are formatted without a patch op
as the patch op is always '+' or '++' (meaning the line has been added
relative to the committed state) and are displayed in orange bold text,
sort of like the @@ or @@@ marker line is at the start of each hunk.
In a 3 way merge diff hunks which came from our HEAD are shown with a
azure2 background, and hunks which came from the incoming MERGE_HEAD
are displayed with a 'light goldenrod yellow' background. This makes
the two different hunks clearly visible within the file. Hunks which
are ++ or -- (added or deleted relative to both parents) are shown
without any background at all.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a file has a merge conflict we want it to show up in the 'Changed
But Not Updated' file list rather than the 'Changes To Be Committed'
file list. This way the user can mostly ignore the left side (the
HEAD<->index comparsion) while resolving a merge and instead focus
on the merge conflicts, which are just shown on the right hand side.
This requires detecting the U state in the index side and drawing
it as though it were _, then forcing the working directory side to
have a U state. We have to delay this until presentation time as
we don't want to change our internal state data to be different
from what Git is telling us (I tried, the patch for that was ugly
and didn't work).
When showing a working directory diff and its a merge conflict we
don't want to use diff-files as this would wind up showing any
automatically merged hunks obtained from MERGE_HEAD in the diff.
These are not usually very interesting as they were completed by
the system. Instead we just want to see the conflicts. Fortunately
the diff porcelain-ish frontend (aka 'git diff') detects the case of
an unmerged file and generates a --cc diff against HEAD and MERGE_HEAD.
So we now force any working directory diff with an index state of 'U'
to go through that difference path.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The combined diff format can be very confusing, especially to new users
who may not even be familiar with a standard two way diff format. So
for files which are already staged for commit and which are modifed in
the working directory we should show two different diffs, depending on
which side the user clicked on.
If the user clicks on the "Changes To Be Committed" side then we should
show them the PARENT<->index difference. This is the set of changes they
will actually commit.
If the user clicks on the "Changed But Not Updated" side we should show
them the index<->working directory difference. This is the set of changes
which will not be committed, as they have not been staged into the index.
This is especially useful when merging, as the "Changed But Not Updated"
files are the ones that need merge conflict resolution, and the diff here
is the conflict hunks and/or any evil merge created by the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now need to keep track of which side the current diff is for,
HEAD<->index or index<->working directory. Consequently we need
an additional "current diff" variable to tell us which side the
diff is for. Since this is really only necessary in reshow_diff
I'm going to declare a new global, rather than try to shove both
the path and the side into current_diff.
To keep things clear later on, I'm renaming current_diff to
current_diff_path. There is no functionality change in this
commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since references may be packed, it's no longer as helpful to
introduce references as paths relative to .git.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
If the user asked us to checkout the branch after creating it then
we should try to do so. This may fail, especially right now since
branch switching from within git-gui is not supported.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its possible for the user to select a branch for the merge test
(while deleting branches) and also select that branch for deletion.
Doing so would have bypassed our merge check for that branch, as
a branch is always a strict subset of itself. So we will simply
skip over a branch and not delete it if that is the branch which
the user selected for the merge check.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user is deleting a branch which is fully merged into the
selected test branch we should not confirm the delete with them,
the fact that the branch is fully merged means we can recover the
branch and no work will be lost.
If a branch is not fully merged, we should warn the user about which
branch(es) that is and continue deleting those which are fully merged.
We should only delete a branch if the user disables the merge check,
and in that case we should confirm with the user that a delete should
occur as this may cause them to lose changes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The only reason the commit_prehook logic was broken out into its own
proc was so it could be invoked after the current set of files that
were already added to the commit could be refreshed if 'Allow Partially
Added Files' was set to false. Now that we no longer even offer that
option to the user there is no reason to keep this code broken out
into its own procedure.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we take the approach of core Git where we allow the user to
stage their changes directly into the index all of the time there is
absolutely no reason to have the Allow Partially Added Files option,
nor is there a reason or desire to default that option to false.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Mac OS X wish does not draw borders around text fields, making the
field look like its not even there until the user focuses into it. I
don't know the Mac OS X UI standards very well, but that just seems
wrong. Other applications (e.g. Terminal.app) show their input boxes
with a sunken relief, so we should do the same.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes you want to create a branch from a remote tracking branch.
Needing to enter it in the revision expression field is very annoying,
so instead let the user select it from a list of known tracking branches.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most of the time when you are deleting branches you want to delete
those which have been merged into your upstream source. Typically
that means it has been merged into the tip commit of some tracking
branch, and the current branch (or any other head) doesn't matter.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users can now delete a local branch by selecting from a list of
available branches. The list automatically does not include
the current branch, as deleting the current branch could be quite
dangerous and should not be supported.
The user may also chose to have us verify the branches are fully
merged into another branch before deleting them. By default we
select the current branch, matching 'git branch -d' behavior,
but the user could also select any other local branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Creating branches is a common enough activity within a Git project
that we probably should give it a keyboard accelerator. N is not
currently used and seems reasonable to stand for "New Branch". To
bad our menu calls it create.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users may now create new branches by activating the Branch->Create menu
item. This opens a dialog which lets the user enter the new branch
name and select the starting revision for the new branch.
For the starting revision we allow the user to either select from a
list of known heads (aka local branches) or to enter an arbitrary
SHA1 expression. For either creation technique we run the starting
revision through rev-parse to verify it is valid before trying to
create the ref with update-ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It looks horrible to have the cancel and save buttons wedged up against
each other in our options dialog. Therefore toss a 5 pixel pad between
them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that our lists represent more defined states it no longer makes any
sense to permit a user to make selections from both lists at once, as
the each available operation acts only on files whose status corresponds
to only one of the lists.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
During unstaging we can simplify the way we perform the output by
combining our four puts into a single call.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The list of states which are valid for update-index were a little
too verbose and fed a few too many cases to the program. We can
do better with less lines of code by using more pattern matching,
and since we already were globbing here there's little change in
runtime cost.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We can revert any file which has a valid stage 0 (is not unmerged)
and which is has a working directory status of M or D. This vastly
simplifies our pattern matching on file status when building up the
list of files to perform a checkout-index against.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than relying on the file state and just inverting it, we should
look at which file icon the user clicked on. If they clicked on the
one in the "Changes To Be Committed" list then they want to unstage
the file. If they clicked on the icon in the "Changed But Not Updated"
list then they want to add the file to the commit. This should be much
more reliable about capturing the user's intent then looking at the file
state.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that core Git refers to resetting paths in the index as "unstaging"
the paths we should do the same in git-gui, both internally in our code
and also within the menu action name. The same follows for our staging
logic, as core Git refers to this as 'add'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Updated the state descriptions for individual file states to try and
make them more closely align with what git-runstatus might display.
This way a user who is reading Git documentation will be less confused
by our descriptions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The DM state cannot really happen. Its implying that the file has
been deleted in the index, but the file in the working directory has
been modified relative to the file in the index. This is complete
nonsense, the file doesn't exist in the index for it to be different
against!
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently my earlier suspicion that the file state DD was a bug was
correct. A file which has been deleted from the working directory and
from the index will always get the state of D_ during a rescan. Thus
the only valid state for this to have is D_. We should always use only
D_ internally during our state changes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a rather drastic change to the git-gui user interface, but it
doesn't really look any different yet. I've taken the two lists and
converted them to being "changes to be committed" and "changed but
not updated". These lists correspond to the same lists output by
git-runstatus based on how files differ in the HEAD<->index and the
index<->working directory comparsions it performs.
This change is meant to correlate with the change in Git 1.5.0 where
we have brought the index more into the foreground and are trying to
teach users to make use of it as part of their daily operations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm going to refactor the way file status information gets displayed
so it more closely aligns with the way 'git-runstatus' displays the
differences between HEAD<->index and index<->working directory. To
that end the other file list is going to be changed to be the working
directory difference. So this change renames it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has many git-gui icons it may be confusing when they
start one which git-gui is still coming up. So on the windows
systems we now include an echo statement which displays the full
pathname of the working directory we are trying to enter into.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we usually say "Operation... please wait..." we should do
the same thing when starting gitk.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because it is such a common idiom to use [gitdir] along with [file join]
to locate the path of an item within the .git directory of the current
repository we might as well allow gitdir to act as a wrapper for the
file join operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The gitdir global variable is essentially read-only, and is used rather
frequently. So are appname and reponame. Needing to constantly declare
'global appname' just so we can access the value as $appname is downright
annoying and redundant. So instead I'm declaring these as procedures and
changing all uses to invoke the procedure rather than access the global
directly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We use reponame in a number of locations, and every time its always the
same value. Instead of computing this multiple times with code that was
copied and pasted around we can compute it once immediately after the
global gitdir has been computed and set.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users often forget to repack their object database, then start to
complain about how slow it is to perform common operations after
they have collected thousands of loose objects in their objects
directory. A simple repack usually restores performance.
During startup git-gui now asks git-count-objects how many loose
objects exist, and if this number exceeds a hardcoded threshold
we suggest that the user compress the database (aka run 'git gc')
at this time. I've hardcoded this to 2000 objects on non-Windows
systems as there the filesystems tend to handle the ~8 objects
per directory just fine. On Windows NTFS and FAT are just so slow
that we really start to lag when more than 200 loose objects exist,
so the hardcoded threshold is much lower there.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I really hate that I have this specialized hack within git-gui, but
its here. The hack shouldn't be offered unless miga's required .pvcsrc
file is in the top level of the repository's working directory. If
this file is missing miga will fail to startup properly, and the user
cannot wouldn't be able to use it within this directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a user wants to report an issue they will likely want to include
the version number with their issue report. This may be difficult
to enter if the version number includes an abbreviated commit SHA1
on the end of it. So we now give the user a context menu option
on the version box which allows them to copy all of the relevant
version data to the clipboard, ready for pasting into a report.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm stealing the exact logic used by core Git within its own Makefile to
setup the version number within scripts and executables. This way we
can be sure that the version number is always updated after a commit,
and that the version number also reflects when it is coming from a dirty
working directory (and is thus pretty worthless).
I've cleaned up some of the version display code in the about dialog too.
There were simply too many blank lines in the bottom section where we
showed the version data.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We're a true GPL program, and we're interactive. We should show the
entire GPL notice and disclaimer of warranty in our about dialog upon
request by the user, as well as include it in the header of our source.
Perhaps overkill, but is recommended by our license.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we know what version git-gui is, the about dialog should
display it to the end-user. This way users can find out what version
they have before they report a problem or request a feature.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We want to embed the version of git-gui directly into the script file,
so that we can display it properly in the about dialog. Consequently
I've refactored the Makefile process to act like the one in core git.git
with regards to shell scripts, allowing git-gui to be constructed by a
sed replacement performed on git-gui.sh.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The user really doesn't need to see the technical details of how we
launch git-gui from within their "desktop icon". Instead we should hide
the command line from being displayed when the icon launches by putting
@ at the start of the line. If they really need to see the command we
are running they can edit the batch file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I just found a whole slew of places where we still were using the term
'include' rather than 'add' to refer to the act of updating the index
with modifications from the working directory. To be consistent with
all Git documentation and command line tools, these should be 'add'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There appears to be a bug on one of my test systems where cygpath with
the --long-name option is generating a corrupt string that does not
actually refer to sh.exe. This breaks any desktop icon created by
git-gui as the executable we are trying to invoke does not exist.
Since Cygwin is typically installed as C:\cygwin long path names is
probably not actually necessary to link to the shell.
I also added a small echo to the start of the icon script, as it can
take one of my test systems several seconds to startup git-gui. This
way the user knows we're starting git-gui, and was politely asked to
wait for the action to complete.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We no longer describe updating the index as including changes, as we
now use the add notation used by core Git's command line tools. So
its confusing to be talking about unincluded changes within the revert
dialog. Instead we should used language like 'unadded changes'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently I did not account for the D_ file state. This can occur when
a file has been marked for deletion by deleting it from the index, and
the file also does not exist in the working directory. Typically this
happens when the user deletes the file, hits Rescan, then includes the
missing file in the commit, then hits Rescan again. We don't find the
file in the working directory but its been removed in the index, so the
state becomes D_.
This state should be identical with DD. I'm not entirely sure why DD
occurs sometimes and D_ others, it would seem like D_ is the state that
should be happening instead of DD, leading me to believe there is a quirk
in git-gui's state manipulation code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that git 1.5.0-rc1 and later has a 'git gc' command which performs
all important repository management activites (including reflog pruning,
repacking local objects, unnecessary loose object pruning and rerere cache
expiration) we should run 'gc' when the user wants us to cleanup their
object database for them.
I think the name 'gc' is horrible for a GUI application like git-gui,
so I'm labeling the menu action 'Compress Database' instead. Hopefully
this will provide some clue to the user about what the action does.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Loop through every remote.<name>.fetch entry and add it as a valid
option in the Pull menu. This way users can pull any remote branch
that they track, without needing to leave the gui. Its a rather crude
work around for not having a full merge interface.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In one particular case I have a tool called 'miga' which users may need
to invoke on their repository. This is a homegrown tool which is not
(and should be) part of git-gui, but I still want to be able to run it
from within the gui.
Right now I'm taking a shortcut and adding it to the Tools menu if
we are not on Mac OS X and the support script used to launch the tool
exists in the local filesystem. This is nothing but a complete and
utter hack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that git-add is a first class citizen in core Git (Nico's 366bfcb6)
users may start to expect the term 'add' to refer to the act of including
a file's changes into a commit. So I'm replacing all uses of the term
'Include' in the UI with 'Add'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This option gives grace period to objects that are unreachable
from the refs from getting pruned.
The default value is 24 hours and may be changed using
gc.prunegrace.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since you can reset --hard to any revision you already had, when
traversing the reflog ancestry, we may not free() the commit buffer.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not allow uninteresting commits with --walk-reflogs, since it is
not clear what should be shown in these cases:
$ git log --walk-reflogs master..next
$ git log --walk-reflogs ^master
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
When called with "--walk-reflogs", as long as there are reflogs
available, the walker will take this information into account, rather
than the parent information in the commit object.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For example, it makes no sense to check the presence of a file
named "HEAD" when calling "git log HEAD" in a bare repository.
Noticed by Han-Wen Nienhuys.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
The static variable "prefix" was shadowed by an unused parameter
of the same name. In case of execution in a subdirectory, the
static variable was accessed, leading to a crash.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
We pass a timestamp (i.e. number of seconds elapsed since Jan 1 1970,
00:00:00 GMT) to the function. So there is no need to "fix" the
timestamp according to the timezone.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
This changes the output so the list at the top shows the reflog
message, along with their relative timestamps.
You can use --reflog=<n> to show <n> most recent log entries, or
use --reflog=<n>,<b> to show <n> entries going back from the
entry <b>. <b> can be either a number (so --reflog=4,20 shows 4
records starting from @{20}) or a timestamp (e.g. --reflog='4,1 day').
Here is a sample output (with --list option):
$ git show-branch --reflog=10 --list jc/show-reflog
[jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
[jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
[jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog: sho
[jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend read_ref_a
[jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow retrievi
[jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
[jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --reflog: use
This shows what I did more cleanly:
$ git show-branch --reflog=10 jc/show-reflog
! [jc/show-reflog@{0}] (3 minutes ago) commit (amend): show-branch --ref
! [jc/show-reflog@{1}] (5 minutes ago) reset HEAD^
! [jc/show-reflog@{2}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{3}] (14 minutes ago) commit: show-branch --reflog:
! [jc/show-reflog@{4}] (18 minutes ago) commit (amend): Extend read_
! [jc/show-reflog@{5}] (18 minutes ago) commit (amend): Extend read
! [jc/show-reflog@{6}] (18 minutes ago) commit (amend): Extend rea
! [jc/show-reflog@{7}] (18 minutes ago) am: read_ref_at(): allow
! [jc/show-reflog@{8}] (18 minutes ago) reset --hard HEAD~4
! [jc/show-reflog@{9}] (61 minutes ago) commit: show-branch --r
----------
+ [jc/show-reflog@{0}] show-branch --reflog: show the reflog
+ [jc/show-reflog@{2}] show-branch --reflog: show the reflog
+++ [jc/show-reflog@{1}] show-branch --reflog: show the reflog
+++++ [jc/show-reflog@{4}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{5}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{6}] Extend read_ref_at() to be usable fro
+ [jc/show-reflog@{7}] read_ref_at(): allow retrieving the r
+ [jc/show-reflog@{9}] show-branch --reflog: use updated rea
+ [jc/show-reflog@{9}^] read_ref_at(): allow reporting the c
+ [jc/show-reflog@{9}~2] show-branch --reflog: show the refl
+ [jc/show-reflog@{9}~3] read_ref_at(): allow retrieving the
++++++++++ [jc/show-reflog@{8}] dwim_ref(): Separate name-to-ref DWIM
At @{9}, I had a commit to complete 5 patch series, but I wanted
to consolidate two commits that enhances read_ref_at() into one
(they were @{9}^ and @{9}~3), and another two that touch show-branch
into one (@{9} and @{9}~2).
I first saved them with "format-patch -4", and then did a reset
at @{8}. At @{7}, I applied one of them with "am", and then
used "git-apply" on the other one, and amended the commit at
@{6} (so @{6} and @{7} has the same parent). I did not like the
log message, so I amended again at @{5}.
Then I cherry-picked @{9}~2 to create @{3} (the log message
shows that it needs to learn to set GIT_REFLOG_ACTION -- it uses
"git-commit" and the log entry is attributed for it). Another
cherry-pick built @{2} out of @{9}, but what I wanted to do was
to squash these two into one, so I did a "reset HEAD^" at @{1}
and then made the final commit by amending what was at the top.
Signed-off-by: Junio C Hamano <junkio@cox.net>
You can pass an extra argument to the function to receive the
reflog message information. Also when the log does not go back
beyond the point the user asked, the cut-off time and count are
given back to the caller for emitting the error messages as
appropriately.
We could later add configuration for get_sha1_basic() to make it
an error instead of it being just a warning.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For now it's just to get a more descriptive name. Later we might update the
push protocol to run more than one program on the other end. Moreover this
matches better the corresponding config option remote.<name>. receivepack.
--exec continues to work
Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Having to specify git push --exec=... is annoying if you cannot have
git-receivepack in your PATH on the remote side (or don't want to).
This introduces the config item remote.<name>.receivepack to override
the default value (which is "git-receive-pack").
Signed-off-by: Uwe Kleine-König <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds two new classes (pure-helpers and "Interacting with
Others") to the command list in the main manual page. The
latter class is primarily about foreign SCM interface and is
placed before low-level (plumbing) commands.
Also it promotes a handful commands to mainporcelain category
while demoting some others.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code uses mmap() to read reflog data, but moves the pointer around
while reading, and uses that updated pointer in the call to munmap().
Signed-off-by: Junio C Hamano <junkio@cox.net>
The callback function can signal an early return by returning non-zero,
but the function leaked the FILE * opened on the reflog when doing so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the source of the list of commands and categorization
to the end of Documentation/cmd-list.perl, so that re-categorization
and re-ordering would become easier to manage.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Non-GNU touch do not have the -d option to take free form
date strings. The POSIX -t option should be more widespread.
For this to work, date needs to output YYYYMMDDHHMM.SS date strings.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Plain integer types without a fixed size can vary between platforms. Even
though all common platforms use 32-bit ints, there is no guarantee that
this won't change at some point. Furthermore, specifying an integer type
with explicit size makes the definition of structures more obvious.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Its very annoying to need to specify the file content ahead of a
commit and use marks to connect the individual blobs to the commit's
file modification entry, especially if the frontend can't/won't
generate the blob SHA1s itself. Instead it would much easier to
use if we can accept the blob data at the same time as we receive
each file_change line.
Now fast-import accepts 'inline' instead of a mark idnum or blob
SHA1 within the 'M' type file_change command. If an inline is
detected the very next line must be a 'data n' command, supplying
the file data.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It is error prone to list the value of each file twice, instead we
should list the value only once early in the script and reuse the
shell variable when we need to access it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that its easier to craft test cases (thanks to 'data <<')
we should start to verify fast-import works as expected.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
During testing its nice to not have to feed the length of a data
chunk to the 'data' command of fast-import. Instead we would
prefer to be able to establish a data chunk much like shell's <<
operator and use a line delimiter to denote the end of the input.
So now if a data command is started as 'data <<EOF' we will look
for a terminator line containing only the string EOF on that line.
Once found, we stop the data command. Everything between the two
lines is used as the data value.
The 'data <<' syntax is slower than 'data n', as we don't know how
many bytes to expect and instead must grow our buffer on the fly.
It also has the problem that the frontend must use a string which
will not appear on a line by itself in the input, and the data
region will always end in an LF. For these reasons real import
frontends are encouraged to continue to use _only_ 'data n'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The --objects command line option is rather unnecessary. Internally
we allocate objects in 5000 unit blocks, ensuring that any sort
of malloc overhead is ammortized over the individual objects to
almost nothing. Since most frontends don't know how many objects
they will need for a given import run (and its hard for them to
predict without just doing the run) we probably won't see anyone
using --objects. Further since there's really no major benefit
to using the option, most frontends won't even bother supplying
it even if they could estimate the number of objects. So I'm
removing it.
The --max-objects-per-pack option was probably a mistake to even
have added in the first place. The packfile format is limited
to 4 GiB today; given that objects need at least 3 bytes of data
(and probably need even more) there's no way we are going to exceed
the limit of 1<<32-1 objects before we reach the file size limit.
So I'm removing it (to slightly reduce the complexity of the code)
before anyone gets any wise ideas and tries to use it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Currently the pack .idx file format uses 32-bit unsigned integers
for the fan-out table and the object offsets. We had previously
defined these as 'unsigned int', but not every system will define
that type to be a 32 bit value. To ensure maximum portability we
should always use 'uint32_t'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Previously we were using 'unsigned int' to update the hdr_entries
field of the pack header after the file had been completed and
was being hashed. This may not be 32 bits on all platforms.
Instead we want to always uint32_t.
I'm actually cheating here by just using the pack_header like the
rest of Git and letting the struct definition declare the correct
type. Right now that field is still 'unsigned int' (wrong) but a
pending change submitted by Simon 'corecode' Schubert changes it
to uint32_t. After that change is merged in fast-import will do
the right thing all of the time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Editors often give easier handling of patch files if the
filename ends with .patch, so use it instead of .txt.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It does not make much sense to generate a patch that cannot be
applied. If --text is specified on the command line it still
takes precedence.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --summary output in addition to the --stat to the
output from git-format-patch by default.
I think additions, removals and filemode changes are rare but
notable events and always showing it makes sense.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches "git-format-patch" to honor the --max-count
parameter revision traversal machinery takes, so that you can
say "git-format-patch -3" to process the three topmost commits
from the current HEAD (or "git-format-patch -2 topic" to name a
specific branch).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Way back when Junio developed the 64 bit index topic he came up
with a means of changing the .idx file format so that older Git
clients would recognize that they don't understand the file and
refuse to read it, while newer clients could tell the difference
between the old-style and new-style .idx files. Unfortunately
this wasn't recorded anywhere.
This change documents how we might go about changing the .idx
file format by using a special signature in the first four bytes.
Credit (and possible blame) goes completely to Junio for thinking
up this technique.
The change also modifies the error message of the current Git code
so that users get a recommendation to upgrade their Git software
should this version or later encounter a new-style .idx which it
cannot process. We already do this for the .pack files, but since
we usually process the .idx files first its important that these
files are recognized and encourage an upgrade.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The revision specification syntax (sometimes referred to as
SHA1-expressions) is accepted almost everywhere in Git by
almost every tool. Unfortunately it is only documented in
git-rev-parse.txt, and most users don't know to look there.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In ab2a1a32 Junio improved the reflog query logic to support
obtaining the n-th prior value of a ref, but this was never
documented in git-rev-parse. Now it is.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of keeping the confused end user reading low-level
documentation, suggest the higher level commands that implement
what the user may want to do using them upfront.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Current README content is way too esoteric for someone looking at GIT
for the first time. Instead it should provide a quick summary of what
GIT is with a few pointers to other resources.
The bulk of the previous README content is moved to
Documentation/core-intro.txt.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The default can also be changed with "format.suffix" configuration.
Leaving it empty would not add any suffix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add discussion section to git-checkout documentation and mention
detached HEAD in repository-layout document.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Branches are only contained by a packfile if the branch actually
had its most recent commit in that packfile. So new branches are
set to MAX_PACK_ID to ensure they don't cause their commit to list
as part of the first packfile when it closes out if the commit was
actually in existance before fast-import started.
Also corrected the type of last_commit to be umaxint_t to prevent
overflow and wraparound on very large imports. Though that is
highly unlikely to occur as we're talking 4 billion commits, which
no real project has right now.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently the git convention is to declare any function which
takes no arguments as taking void. I did not do this during the
early fast-import development, but should have.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The length of an atom string cannot be negative. So make it
explicit and declare it as an unsigned value.
The shift width in a mark table node also cannot be negative.
I'm also moving it to after the pointer arrays to prevent any
possible alignment problems on a 64 bit system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that fast-import uses uintmax_t (the largest available unsigned
integer type) for marks we don't want to say its an unsigned 32
bit integer in ASCII base 10 notation. It could be much larger,
especially on 64 bit systems, and especially if a frontend uses
a very large number of marks (1 per file revision on a very, very
large import).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This allows "git checkout -m <other-branch>" to notice renames and
carry local changes in the working tree forward.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* Promiscous pull shows the distributed nature of git better.
* Add a new step after that to teach "remote add".
* Highlight that with the shorthand defined you will get
remote tracking branches for free.
* Fix Alice's workflow.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
From time to time, I would get this error:
[...]
sed: -e expression #8, char 41: Unterminated `s' command
make: *** [git-add--interactive] Error 1
Turns out that the function WriteMakefile() called in Makefile.PL
outputs the message "Writing perl.mak for Git" to stdout! Thus,
the output of "make -C perl -s --no-print-directory instlibdir"
would be prefixed by that message whenever Makefile.PL was newer
than perl.mak.
This is fixed by redirecting stdout to stderr in Makefile.PL.
Signed-off-by: Johannes E. Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
To help callers repack very large repositories into a series of
packfiles fast-import now outputs the last commits/tags it wrote to
a packfile when it prints out the packfile name. This information
can be feed to pack-objects --revs to repack. For the first pack
of an initial import this is pretty easy (just feed those SHA1s on
stdin) but for subsequent packs you want to feed the subsequent
pack's final SHA1s but also all prior pack's SHA1s prefixed with
the negation operator. This way the prior pack's data does not
get included into the subsequent pack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since object_count is limited to 'unsigned long' (really an
unsigned 32 bit integer value) by the pack file format we may as
well use exactly that type here in fast-import for that counter.
An earlier change by me incorrectly made it uintmax_t.
But since object_count is a counter for the current packfile only,
we don't want to output its value at the end. Instead we should
sum up the individual type counters and report that total, as that
will cover all of the packfiles.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently amd64 has defined 'unsigned long' to be a 64 bit value,
which means -1 was way over the 4 GiB packfile limit. Whoops.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
People that redirect STDOUT output should always see STDERR
prompts interactively.
STDERR should always be flushed without buffering, so
they should always show up. If that is unset, we still
explicitly flush by calling STDERR->flush.
The svn command-line client prompts to STDERR, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The reflog code clears empty directories when rename returns
either EISDIR or ENOTDIR. Seems to be the only place.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not all echos know -n. This was causing a test failure in
t5401-update-hooks.sh, but not t3800-mktag.sh for some reason.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
AIX 5.3 seems to need _ALL_SOURCE for struct addrinfo, but that
introduces a struct list in grp.h.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Much like the pack_sha1 the pack_fd is an unnecessary global
variable, we already have the fd stored in our struct packed_git
*pack_data so that the core library functions in sha1_file.c are
able to lookup and decompress object data that we have previously
written. Keeping an extra copy of this value in our own variable
is just a hold-over from earlier versions of fast-import and is
now completely unnecessary.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we are renaming the packfile into its file destination we
need to be sure its not open when the rename is called, otherwise
some operating systems (e.g. Windows) may prevent the rename from
occurring.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because fast-import automatically updates all references (heads
and tags) at the end of its run the repository is corrupt unless
the objects are available in the .git/objects/pack directory prior
to the refs being modified. The easiest way to ensure that is true
is to move the packfile and its associated index directly into the
.git/objects/pack directory as soon as we have finished output to it.
But the only safe way to do this is to create the a temporary .keep
file for that pack, so we use the same tricks that index-pack uses
when its being invoked by receive-pack.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than maintaing our own packfile level sha1 variable we
can make use of the one already available in struct packed_git.
Its meant for the SHA1 of the index but it can also hold the
SHA1 of the packfile itself between final checksumming of the
packfile and creation of the index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Prior to git having read_in_full() fast-import used its own private
function yread to perform the header reading task. No sense in
keeping that around now that read_in_full is a public, stable
function.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a frontend wants to use a mark per file revision and per commit
and is doing a truly huge import (such as a 32 GiB SVN repository)
we may need more than 2**32 unique mark values, especially if the
frontend is unable (or unwilling) to recycle mark values. For mark
idnums we should use the largest unsigned integer type available,
hoping that will be at least 64 bits when we are compiled as a 64
bit executable. This way we may consume huge amounts of memory
storing our mark table, but we'll at least be able to process
the entire import without failing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we previously were using a delta but we needed to checkpoint the
current packfile and switch to a new packfile we need to throw away
the delta and compress the raw object by itself, as delta chains
cannot span non-thin packfiles. Unfortunately the output buffer
in this case needs to grow, as the size of the compressed object
may be quite a bit larger than the size of the compressed delta.
I've also avoided recompressing the object if we are checkpointing
and we didn't use a delta. In this case the output buffer is the
correct size and has already been populated with the right data,
we just need to close out the current packfile and open a new one.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
My bash refused to run the two scripts missing a #!, and it's
better to use the same line for all the scripts.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead, we complain to the user and suggest that they explicitly
specify the remote and branch. We depend on the exit status of
git-symbolic-ref, so let's go ahead and document that.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we are on a detached HEAD, there is no current branch.
There is no reason to leak the error messages to the end user
since this is a situation we expect to see.
This adds -q option to git-symbolic-ref to exit without issuing
an error message if the given name is not a symbolic ref.
By the way, with or without this patch, there currently is no
good way to tell failure modes between "git symbolic-ref HAED"
and "git symbolic-ref HEAD". Both says "is not a symbolic ref".
We may want to do something about it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Caller scripts may want to know what packfiles the fast-import
process just wrote out for them. This is now output to stdout,
one packfile name per line, after we checkpoint each packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the number of objects or number of bytes gets close to the limit
allowed by the packfile format (or configured on the command line by
our caller) we should automatically checkpoint the current packfile
and start a new one before writing the object out. This does however
require that we abandon the delta (if we had one) as its not valid
in a new packfile.
I also added the simple rule that if we got a delta back but the
delta itself is the same size as or larger than the uncompressed
object to ignore the delta and just store the object data. This
should avoid some really bad behavior caused by our current delta
strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are generating multiple packfiles at once we only need
to scan the blocks of object_entry structs which contain objects
for the current packfile. Because the most recent blocks are at
the front of the linked list, and because all new objects going
into the current file are allocated from the front of that list,
we can stop scanning for objects as soon as we identify one which
doesn't belong to the current packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the last packfile is going to be empty (has 0 objects) then it
shouldn't be kept after the import has terminated, as there is no
point to the packfile. So rather than hashing it and making the
index file, just delete the packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To help importers which are dealing with massive amounts of data
fast-import needs to be able to close the packfile it is currently
writing to and open a new packfile for any additional data that
will be received. A new 'checkpoint' command has been introduced
which can be used by the frontend import process to force this
to occur at any time. This may be useful to ensure a very long
running import doesn't lose any work due to unexpected failures.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is little reason to be keeping a global duplicate_count
value when we also keep it per object type. The global counter can
easily be computed at the end, once all processing has completed.
This saves us a couple of machine instructions in an unimportant
part of code. But it looks slightly better to me to not keep
two counters around.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we are starting to see some really large projects (such
as KDE or a fork of FreeBSD) get imported into Git we're running
into the upper limit on packfile object count as well as overall
byte length. The KDE and FreeBSD projects are both likely to
require more than 4 GiB to store their current history, which means
we really need multiple packfiles to handle their content.
This is a fairly simple restructuring of the internal code to help
us support creating multiple packfiles from within fast-import.
We are now adding a 5 digit incrementing suffix to the end of the
basename supplied to us by the caller, permitting up to 99,999
packs to be generated in a single fast-import run.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git://git.kernel.org/pub/scm/gitk/gitk:
[PATCH] Make gitk work when launched in a subdirectory
[PATCH] gitk: add current directory to main window title
Always call the current HEAD 'HEAD', and name the patch being
cherry-picked or reverted by its oneline subject rather than
its SHA1. This matches git am's behavior and is done because
users most commonly are cherry-picking by SHA1 rather than by
ref name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes revert and cherry-pick to use merge-recursive, to
allow them to notice renames. A pair of test scripts
demonstrate that an old change before a rename happened can be
applied (reverted) after a rename with cherry-pick (with revert).
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've squelched output from merge-recursive, and git-merge when
used with recursive does not attempt the trivial one first
anymore, so there won't be "Trying ... Nope." messages now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently we don't use the util field of struct commit but we want
fast access to the highest priority name that references any given
commit object during our matching loop. A really simple approach
is to just store the name directly in the util field.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We really want to always favor an annotated tag over a lightweight
tag when describing a commit. Unfortunately git-describe wasn't
doing this as it was favoring the depth attribute of a possible_tag
over the priority. Now priority is the highest sort and we only
consider a lightweight tag if no annotated tags were identified.
Rather than searching for the minimum tag using a simple loop we
now sort them using a stable sort algorithm, this way the possible
tags display in order if --debug gets used. The stable sort helps
to preseve the inherit topology/date order that we obtain during
our search loop.
This fix allows the tests in t6120-describe.sh to pass.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My prior version of git-describe ran very slowly on even reasonably
sized projects like git.git and linux.git as it tended to identify
a large number of possible tags and then needed to generate the
revision list for each of those tags to sort them and select the
best tag to describe the input commit.
All we really need is the number of commits in the input revision
which are not in the tag. We can generate these counts during
the revision walking and tag matching loop by assigning a color to
each tag and coloring the commits as we walk them. This limits us
to identifying no more than 26 possible tags, as there is limited
space available within the flags field of struct commit.
The limitation of 26 possible tags is hopefully not going to be a
problem in real usage, as most projects won't create 26 maintenance
releases and merge them back into a development trunk after the
development trunk was tagged with a release candidate tag. If that
does occur git-describe will start to revert to its old behavior of
using the newer maintenance release tag to describe the development
trunk, rather than the development trunk's own tag. The suggested
workaround would be to retag the development trunk's tip.
However since even 26 possible tags can take a while to generate a
description for on some projects I'm defaulting the limit to 10 but
offering the user --candidates to increase the number of possible
matches if they need a more accurate result. I specifically chose
10 for the default as it seems unlikely projects will have more
than 10 maintenance releases merged into a development trunk before
retagging the development trunk, and it seems to perform about the
same on linux.git as v1.4.4.4 git-describe.
A large amount of debugging information was also added during
the development of this change, so I've left it in to be toggled
on with --debug. It may be useful to the end user to help them
understand why git-describe took one particular tag over another.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a project has a really huge number of tags (such as several
thousand tags) then we are likely to have nearly a hundred tags in
some buckets. Scanning those buckets as linked lists could take
a large amount of time if done repeatedly during history traversal.
Since we are searching for a unique commit SHA1 we can sort all
tags by commit SHA1 and perform a binary search within the bucket.
Once we identify a particular tag as matching this commit we walk
backwards within the bucket matches to make sure we pick up the
highest priority tag for that commit, as the binary search may
have landed us in the middle of a set of tags which point at the
same commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a project has a very large number of tags then git-describe
will spend a good part of its time looping over the tags testing
them one at a time to determine if it matches a given commit.
For 10 tags this is not a big deal, but for hundreds of tags the
time could become considerable if we don't find an exact match for
the input commit and we need to walk back along the history chain.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Several people have suggested that its always better to describe
a commit using an annotated tag, and to only use a lightweight tag
if absolutely no annotated tag matches the input commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
1) talk about "git merge" instead of "git pull ."
2) suggest "git repo-config" instead of directly editing config files
3) echo "URL: blah" > .git/remotes/foo is obsolete and should be
"git repo-config remote.foo.url blah"
4) support for partial URL prefix has been removed (see commit
ea560e6d64) so drop mention of it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that the sha1_file.c library routines use the sliding mmap
routines to perform efficient access to portions of a packfile
I can remove that code from fast-import.c and just invoke it.
One benefit is we now have reloading support for any packfile which
uses OBJ_OFS_DELTA. Another is we have significantly less code
to maintain.
This code reuse change *requires* that fast-import generate only
an OBJ_OFS_DELTA format packfile, as there is absolutely no index
available to perform OBJ_REF_DELTA lookup in while unpacking
an object. This is probably reasonable to require as the delta
offsets result in smaller packfiles and are faster to unpack,
as no index searching is required. Its also only a temporary
requirement as users could always repack without offsets before
making the import available to older versions of Git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We say "this shows only the most often used ones"; so instead of
teaching --max-number=<n> form, list -<n> form which is much
easier to type.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that we are showing the output messages for verbosity levels
<5 after all actions have been performed (due to the progress meter
running during the actions) it can be confusing to see messages in
the present tense when the user is looking at a '100% done' message
right above them. Converting the messages to past tense will appear
more correct in this case, and shouldn't affect a developer who is
debugging the application and running it at a verbosity level >=5.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because large merges on slow systems can take up to a minute to
execute we should try to keep the user entertained with a progress
meter to let them know how far we have progressed through the
current merge.
The progress meter considers each entry in the in-memory index to
be a unit, which means a single recursive merge will double the
number of units in the progress meter. Files which are unmerged
after the 3-way tree merge are also considered a unit within the
progress meter.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Buffering all message output until a merge invocation is complete is
necessary to prevent intereferring with a progress meter that would
indicate the number of files completely merged, and how many remain.
This change does not introduce a progress meter, but merely lays
the groundwork to buffer the output.
To aid debugging output buffering is only enabled if verbosity
is lower than 5. When using verbosity levels above 5 the user is
probably debugging the merge program itself and does not want to
see the output delayed, especially if they are stepping through
portions of the code in a debugger.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano <junkio@cox.net> writes:
>
> I think the output from merge-recursive can be categorized into 5
> verbosity levels:
>
> 1. "CONFLICT", "Rename", "Adding here instead due to D/F conflict"
> (outermost)
>
> 2. "Auto-merged successfully" (outermost)
>
> 3. The first "Merging X with Y".
>
> 4. outermost "Merging:\ntitle1\ntitle2".
>
> 5. outermost "found N common ancestors\nancestor1\nancestor2\n..."
> and anything from inner merge.
>
> I would prefer the default verbosity level to be 2 (that is, show
> both 1 and 2).
and this change makes it so. I think level 3 is probably pointless
as its only one line of output above level 2, but I can see how some
users may want to view it but not view the slightly more verbose
output of level 4.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because the output_indent always matches the call_depth value
there is no reason to pass around the call_depth to the merge
function during each recursive invocation.
This is a simple refactoring that will make the code easier to
follow later on as I start to add output verbosity controls.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/int:
More tests in t3901.
Consistent message encoding while reusing log from an existing commit.
t3901: test "format-patch | am" pipe with i18n
Use log output encoding in --pretty=email headers.
* jc/subdir:
Allow whole-tree operations to be started from a subdirectory
Use cd_to_toplevel in scripts that implement it by hand.
Define cd_to_toplevel shell function in git-sh-setup
Originally I introduced read_or_die for the purpose of reading
the pack header and trailer, and I was too lazy to print proper
error messages.
Linus Torvalds <torvalds@osdl.org>:
> For a read error, at the very least you have to say WHICH FILE
> couldn't be read, because it's usually a matter of some file just
> being too short, not some system-wide problem.
and of course Linus is right. Make it so.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user doesn't have SVN::Core installed or working then the
SVN tests properly turn themselves off. But the user doesn't need
to know that SVN::Core isn't loadable as a Perl module. Unless of
course they are trying to debug the test, so lets relegate the Perl
failures to --verbose only.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm bringing master in early so that the OBJ_OFS_DELTA implementation
is available as part of the topic. This way git-fast-import can
learn about this new slightly smaller and faster packfile format,
and can generate them directly rather than needing to have them be
repacked with git-pack-objects.
Due to the API changes in master during the period of development
of git-fast-import, a few minor tweaks to fast-import.c are needed
to produce a working merge. I've done them here as part of the
merge to ensure bisection always works.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some importers may want to create a branch long before they actually
commit to it, or in some cases they may never commit to the branch
but they still need the ref to be created in the repository after
the import is complete.
This extends the 'reset ' command to automatically create a new
branch if the supplied reference isn't already known as a branch.
While I'm at it I also modified the syntax of the reset command
to terminate with an empty line, like commit and tag operate.
This just makes the command set more consistent.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some importers are able to determine when branch merges occurred
within their source data. In these cases they will want to supply
the correct commits to fast-import so that a proper merge commit
will exist in Git. This is now supported by supplying a 'merge '
command after the commit message and optional from command.
A merge is not actually performed by fast-import, its assumed that
the frontend performed any sort of merging activity already and
that fast-import should simply be storing its result.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently we did not copy the blob SHA1 into the stack variable
'sha1' when a mark is used to refer to a prior blob. This code
was not previously tested as the Mozilla CVS -> git-fast-import
program always fed us full SHA1s for modified blobs and did not
use the mark feature there.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The new tree delta implementation caused blob SHA1s to be used
instead of a tree SHA1 when a tree was written out. This really
only appeared to happen when converting an existing file to a tree,
but may have been possible in some other situations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since most commits and tag objects are around the same size and we
only generate one at a time we can reuse the same buffer rather than
xmalloc'ing and free'ing the buffer every time we generate a commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We only ever generate at most two tree streams at a time. Since most
trees are around the same size we can simply recycle the buffers from
one tree generation to the next rather than constantly xmalloc'ing
and free'ing them. This should perform slightly better when handling
a large number of trees as malloc has less work to do.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now store for every tree entry two modes and two sha1 values;
the base (aka "version 0") and the current/new (aka "version 1").
When we generate a tree object we also regenerate the prior version
object and use that as our base object for a delta. This strategy
saves a significant amount of memory as we can continue to use the
atom pool for file/directory names and only increases each tree
entry by an additional 24 bytes of memory.
Branches should automatically delta against their ancestor tree,
unless the ancestor tree is already at the delta chain limit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes an import frontend may need to work with a temporary branch
which will actually contain many different branches over the life
of the import. This is especially useful when the frontend needs
to create a tag from a set of file versions which are otherwise
never a commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When generating a very large pack file (for example close to 1 GB
in size) it may be impossible for the kernel to find a contiguous
free range within a 32 bit address space for the mapping to be
located at. This is especially problematic on large imports where
there is a lot of malloc activity occuring within the same process
and the malloc'd regions may straddle the previously mapped regions,
thereby creating large holes in the address space.
So instead we map only 128 MB of the pack at any given time.
This will likely increase the number of times the file gets mapped
(with additional system time required to update the page tables
more frequently) but will allow the program to handle packs up to
4 GB in size.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fast-import was encounting a GPF when it ran out of free tree_entry
objects but didn't know this was the cause because the last
tree_entry wasn't terminated with a NULL pointer. The missing NULL
pointer occurred when we allocated additional entries via xmalloc
but didn't set the last tree_entry's "next" pointer to NULL.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This option can be used to have a record of every commit, the mark
(if supplied) and branch name of the commit recorded into a log file
when the commit is generated. This log can be useful to verify the
results of an import as the commits can be compared to some source
repository matching commits through the mark value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The marks table can be used by the frontend to load any commit after
the import and compare it to whatever data the frontend knows about
that commit. If the mark idnums can be easily correlated to some
reference source then its relatively trivial to compare the GIT
tree to the reference to verify the accuracy of the import.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
cvs2svn has three phases: begin_commit, middle_commit, end_commit.
The ancester is computed in the middle_commit phase. So its easier
to generate a stream if the from command appears after the commit
message itself but before the file change commands.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Jon Smirl was finding it difficult to alter cvs2svn to generate
branch commands prior to the first commit of the same branch.
This change moves the 'from' command to be an optional parameter of
the 'commit' command, thereby allowing a new branch to be defined
at the moment it gets used to create the first commit on that branch.
This change makes it impossible to create a branch with no commits
on it as at least one commit is needed to register the branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some architectures (e.g. SPARC) would require that we access pointers
only on pointer-sized alignments. So ensure the pool allocator
rounds out non-pointer sized allocations to the next pointer so we
don't generate bad memory addresses. This could have occurred if
we had previously allocated an atom whose string was not a whole
multiple of the pointer size, for example.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Tree reloading allows fast-import to swap out the least-recently used
branch by simply deallocating the data structures from memory that
were associated with that branch. Later if the branch becomes active
again it can lazily recreate those structures on demand by reloading
the necessary trees from the pack file it originally wrote them to.
The reloading process is implemented by mmap'ing the pack into
memory and using a much tighter variant of the pack reading code
contained in sha1_file.c. This was a blatent copy from sha1_file.c
but the unpacking functions were significantly simplified and are
actually now in a form that should make it easier to map only the
necessary regions of a pack rather than the entire file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Tags received from the frontend are generated in memory in a simple
linked list in the order that the tag commands were sent by the
frontend. If multiple different tag objects for the same tag name
get generated the last one sent by the frontend will be the one
that gets written out at termination. Multiple tag objects for
the same name will cause all older tags of the same name to be lost.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the branch load count exceeds the number of branches created then
the frontend is causing fast-import to page branches into and out of
memory due to the way its ordering its commits. Performance can
likely be increased if the frontend were to alter its commit
sequence such that it stays on one branch before switching to another
branch, then never returns to the prior branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Marks are now saved when the mark directive gets used by the frontend
and may be used in place of a SHA1 expression to locate a previous
SHA1 which fast-import may have generated. This is particularly
useful with commits where the frontend does not (easily) have the
ability to compute the SHA1 for an arbitrary commit but needs it
to generate a branch or tag from that commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The following command line options are now accepted before the
pack name:
--objects=n # replaces the object count after the pack name
--depth=n # delta chain depth to use (default is 10)
--active-branches=n # maximum number of branches to keep in memory
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Growing a tree caused all subtrees to be deallocated and put back
into the free list yet those subtree's contents were still actively
in use. Consequently they were doled out again and got stomped
on elsewhere. Releasing a tree is now performed in two parts,
either releasing only the content array or releasing the content
array and recursively releasing the subtree(s).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a frontend is smart enough to import a symlink then we should
let them do so. We'll assume that they were smart enough to first
generate a blob to hold the link target, as that's how symlinks
get represented in GIT.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Frontend clients can now send a text stream to fast-import rather
than a binary stream. This should facilitate developing frontend
software as the data stream is easier to view, manipulate and debug
my hand and Mark-I eyeball.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When accepting revision SHA1 IDs from the frontend verify the SHA1
actually refers to a blob and is known to exist. Its an error
to use a SHA1 in a tree if the blob doesn't exist as this would
cause git-fsck-objects to report a missing blob should the pack get
closed without the blob being appended into it or a subsequent pack.
So right now we'll just ask that the frontend "pre-declare" any
blobs it wants to use in a tree before it can use them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The tree of the current commit can be altered by file_change commands
before the commit gets written to the pack. The file changes are
rather primitive as they simply allow removal of a tree entry or
setting/adding a tree entry.
Currently trees and commits aren't being deltafied when written to
the pack and branch reloading from the current pack doesn't work,
so at most 5 branches can be worked with at any one time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This provides the basic data structures needed to store trees in
memory while we are processing them for a branch. What we are
attempting to do is track one complete tree for each branch that
the frontend has registered with us through the 'newb' (new_branch)
command. When the frontend edits that tree through 'updf' or 'delf'
commands we'll mark the affected tree(s) as being dirty and recompute
their objects during 'comt' (commit).
Currently the protocol is decidedly _not_ user friendly. I crashed
fast-import by giving it bad input data from Perl. I may try to
improve upon it, or at least upon its error handling.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Moved the new_blob logic off into a new subroutine and
invoked it when getting the 'blob' command.
Added statistics dump to STDERR when the program terminates listing
what it did at a high level. This is somewhat interesting.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Too many globals variables were being used not not enough
code was resuable to process trees and commits so this is
a simple refactoring of the existing blob processing code
to get into a state that will be easier to handle trees
and commits in.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Although its easy to ask the user to tell us how many objects they
will need, its probably better to dynamically grow the object table
in large units. But if the user can give us a hint as to roughly
how many objects then we can still use it during startup.
Also stopped printing the SHA1 strings to stdout as no user is
currently making use of that facility.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Suggesting the use of [-a|-i|-o] with git-commit is unnecessarily
complex and confusing. In this context -o is totally useless and -i
requires extra arguments which are not mentioned. The only sensible
hint (besides reading the man page but let's not go there) is
"commit -a".
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds tests for "cherry-pick" and "rebase --merge" (and
indirectly "commit -C" since it is used in the latter) to make
sure they create a new commit with correct encoding.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The following commands can reuse log message from an existing
commit while creating a new commit:
git-cherry-pick
git-rebase (both with and without --merge)
git-commit (-c and -C)
When the original commit was made in a different encoding from
the current i18n.commitencoding, "cat-file commit" would give a
string that is inconsistent with what the resulting commit will
claim to be in. Replace them with "git show -s --encoding".
"git-rebase" without --merge is "git format-patch" piped to "git
am" in essence, and has been taken care of before this commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This checks combinations of i18n.commitencoding (declares what
encoding you are feeding commit-tree to make commits) and
i18n.logoutputencoding (instructs what encoding to emit the
commit message out to log output, including e-mail format) to
make sure the "format-patch | am" pipe used in git-rebase works
correctly.
I suspect "git cherry-pick" and "git rebase --merge" may fail
similar tests. We'll see.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some of the recent changes and shortcuts to the tests broke
things for people using older versions of svn:
t9104-git-svn-follow-parent.sh:
v1.2.3 (from SuSE 10.0 as reported by riddochc on #git
(thanks!)) required an extra 'svn up'. I was also able to
reproduce this with v1.1.4 (Debian Sarge).
lib-git-svn.sh:
SVN::Repos bindings in versions up to and including 1.1.4
(Sarge again) do not pass fs-config options to the underlying
library. BerkeleyDB repositories also seem completely broken
on all my Sarge machines; so not using FSFS does not seem to
be an option for most people.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This can help people keep track of which gitk is which, when they
have several on the screen.
Signed-off-by: Doug Maxey <dwm@enoyolf.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This updates five commands (merge, pull, rebase, revert and cherry-pick)
so that they can be started from a subdirectory.
This may not actually be what we want to do. These commands are
inherently whole-tree operations, and an inexperienced user may
mistakenly expect a "git pull" from a subdirectory would merge
only the subdirectory the command started from.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This converts scripts that do "cd $(rev-parse --show-cdup)" by
hand to use cd_to_toplevel.
I think git-fetch does not have to go to the toplevel, but that
should be dealt with in a separate patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Steven Grimm noticed that git-repack's verbosity is inconsistent
because pack-objects is chatty and prune-packed is not. This
makes the latter a bit more chatty and gives -q option to
squelch it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
While 'init-db' still is and probably will always remain a valid git
command for obvious backward compatibility reasons, it would be a good
idea to move shipped tools and docs to using 'init' instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Andy Parkins noticed that the error message some "whole tree"
oriented commands emit is stated misleadingly when they refused
to run from a subdirectory.
We could probably allow some of them to work from a subdirectory
but that is a semantic change that could have unintended side
effects, so let's start at first by rewording the error message
to be easier to read without doing anything else to be safe.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is not available in the outermost merge, and it is only
useful for debugging merge-recursive in the inner merges.
Sergey Vlasov noticed that the old code accesses an
uninitialized location.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code previously checked it's own name and called 'die' upon
an error. However 'die' was not yet defined because git-sh-setup
had not been sourced yet. Instead simply write the error message
to stderr and exit with an error as was originally desired.
Signed-off-by: Bob Proulx <bob@proulx.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Despite what the documentation claims, git-commit does not check commit
for suspicious lines: all hooks are disabled by default,
and the pre-comit hook could be changed to do something else.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "read_or_die()" function would silently NOT die for a partial read,
and since it was of type "void" it obviously couldn't even return the
partial number of bytes read.
IOW, it was totally broken. This hopefully fixes it up.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With the new-and-improved write_in_full() semantics, where a partial write
simply always returns a real error (and always sets 'errno' when that
happens, including for the disk full case), a lot of the callers of
write_in_full() were just unnecessarily complex.
In particular, there's no reason to ever check for a zero length or
return: if the length was zero, we'll return zero, otherwise, if a disk
full resulted in the actual write() system call returning zero the
write_in_full() logic would have correctly turned that into a negative
return value, with 'errno' set to ENOSPC.
I really wish every "write_in_full()" user would just check against "<0"
now, but this fixes the nasty and stupid ones.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recently git.git itself encountered a situation on its master and
next branches where git-describe stopped reporting 'v1.5.0-rc0-gN'
and instead started reporting 'v1.4.4.4-gN'. This appeared to be
a backward jump in version numbering.
maint o-------------------4
\ \
master o-o-o-o-o-o-o-5-o-C-o-W
The issue is that commit C in the diagram claims it is version
1.5.0, as the tag v1.5.0 is placed on commit 5. Yet commit W
claims it is version 1.4.4.4 as the tag v1.5.0 has an older tag
date than the v1.4.4.4 tag.
As it turns out this situation is very common. A bug fix applied
to maint and later merged into master occurs frequently enough that
it should Just Work Right(tm).
Rather than taking the first tag that gets found git-describe will
now generate a list of all possible tags and select the one which
has the most number of commits in common with HEAD (or whatever
revision the user requested the description of).
This rule is based on the principle shown in the diagram above.
There are a large number of commits on the primary development branch
'master' which do not appear in the 'maint' branch, and many of
these are already tagged as part of v1.5.0-rc0. Additionally these
commits are not in v1.4.4.4, as they are part of the v1.5.0 release
still being developed. The v1.5.0-rc0 tag is more descriptive of
W than v1.4.4.4 is, and therefore should be used.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/bare:
Disallow working directory commands in a bare repository.
git-fetch: allow updating the current branch in a bare repository.
Introduce is_bare_repository() and core.bare configuration variable
Move initialization of log_all_ref_updates
* jc/detached-head:
git-checkout: handle local changes sanely when detaching HEAD
git-checkout: safety check for detached HEAD checks existing refs
git-checkout: fix branch name output from the command
git-checkout: safety when coming back from the detached HEAD state.
git-checkout: rewording comments regarding detached HEAD.
git-checkout: do not warn detaching HEAD when it is already detached.
Detached HEAD (experimental)
git-branch: show detached HEAD
git-status: show detached HEAD
If you do:
$ /bin/rm foo
$ git status
we used to say "git add ... to add content to commit". But
suggsting "git add" to record the deletion of a file is simply
insane.
So this rewords various things:
- The section header is the old "Changed but not updated",
instead of "Changed but not added";
- Suggestion is "git add ... to update what will be committed",
instead of "... to add content to commit";
- If there are removed paths, the above suggestion becomes "git
add/rm ... to update what will be committed";
- For untracked files, the suggestion is "git add ... to
include in what will be committed".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Often the user would do "/bin/rm foo" before telling git, but
then want to tell git about it. "git rm foo" however would fail
because it cannot unlink(2) foo.
Treat ENOENT error return from unlink(2) as if a successful
removal happened.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unfortunately, while {read,write}_in_full do take into account
zero-sized reads/writes; their die and whine variants do not.
I have a repository where there are zero-sized files in
the history that was triggering these things.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes another problem that Andy's case showed: git-fsck-objects
reports nonsensical results for corrupt objects.
There were actually two independent and confusing problems:
- when we had a zero-sized file and used map_sha1_file, mmap() would
return EINVAL, and git-fsck-objects would report that as an insane and
confusing error. I don't know when this was introduced, it might have
been there forever.
- when "parse_object()" returned NULL, fsck would say "object not found",
which can be very confusing, since obviously the object might "exist",
it's just unparseable because it's totally corrupt.
So this just makes "xmmap()" return NULL for a zero-sized object (which is
a valid thing pointer, exactly the same way "malloc()" can return NULL for
a zero-sized allocation). That fixes the first problem (but we could have
fixed it in the caller too - I don't personally much care whichever way it
goes, but maybe somebody should check that the NO_MMAP case does
something sane in this case too?).
And the second problem is solved by just making the error message slightly
clearer - the failure to parse an object may be because it's missing or
corrupt, not necessarily because it's not "found".
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
These days, the command does a lot more than just initialise the
object database (such as setting default config-variables,
installing template hooks...), and "git init" is actually a more
sensible name nowadays.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Correct command line examples of repo-config, format-patch and am.
A full object name is 40-hexdigit; it may be 20-byte but
20-digit is misleading.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the early days of Git we performed a 3-way read-tree based merge
before attempting any specific merge strategy, as our core merge
strategies of merge-one-file and merge-recursive were slower script
based programs which took far longer to execute. This was a good
performance optimization in the past, as most merges were able to
be handled strictly by `read-tree -m -u`.
However now that merge-recursive is a C based program which performs
a full 3-way read-tree before it starts running we need to pay the
cost of the 3-way read-tree twice if we have to do any sort of file
level merging. This slows down some classes of simple merges which
`read-tree -m -u` could not handle but which merge-recursive does
automatically.
For a really trivial merge which can be handled entirely by
`read-tree -m -u`, skipping the read-tree and just going directly
into merge-recursive saves on average 50 ms on my PowerPC G4 system.
May sound odd, but it does appear to be true.
In a really simple merge which needs to use merge-recursive to handle
a file that was modified on both branches, skipping the read-tree
in git-merge saves on average almost 100 ms (on the same PowerPC G4)
as we avoid doing some work twice.
We only avoid `read-tree -m -u` if the only strategy to use is
merge-recursive, as not all merge strategies perform as well as
merge-recursive does.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user tries to run a porcelainish command which requires
a working directory in a bare repository they may get unexpected
results which are difficult to predict and may differ from command
to command.
Instead we should detect that the current repository is a bare
repository and refuse to run the command there, as there is no
working directory associated with it.
[jc: updated Shawn's original somewhat -- bugs are mine.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This revamps the merge-recursive implementation following the
outline in:
Message-ID: <7v8xgileza.fsf@assigned-by-dhcp.cox.net>
There is no need to write out the index until the very end just
once from merge-recursive. Also there is no need to write out
the resulting tree object for the simple case of merging with a
single merge base.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The merge-recursive implementation in C inherited the invariant
that the on-file index file is written out and later read back
after any index operations and writing trees from the original
Python implementation. But it was only because the original
implementation worked at the scripting level.
There is no need to write out the index file after handling
every path.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since 98bf8a47c2 status would claim that
git-commit could be useful even if there are no changes except untracked files.
Since wt-status is already computing all the information needed go the whole
way and actually track the (non-)emptiness of all three sections separately,
unify the code, and provide useful messages for each individual case.
Thanks to Junio and Michael Loeffler for suggestions.
Signed-off-by: Jürgen Rühle <j-r@online.de>
On Cygwin, newly builtins are not recognized, because there exist both
the executable binaries (with .exe extension) _and_ the now-obsolete
scripts (without extension), but the script is executed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-send-email sends out the message taken from format-patch
output without quoting nor encoding. When copying the From:
line to form in-body From: field, it should not copy it
verbatim, because the From: for the header is quoted according
to RFC 2047 when not ASCII.
The original came from Jürgen Rühle, but I moved the
string munging into a separate function so that later other
people can tweak it more easily. Bugs introduced during the
translation are mine.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Oops. Commit 515377ea9e missed one
file, git-init documentation.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since c869753e, core.filemode is hardwired to false on Cygwin.
So this test had no chance to succeed, since an early commit
(changing just the filemode) failed, and therefore all subsequent
tests.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commit buffer (message of the commit) is not actually
used by the git-describe process. We can save some memory
by not keeping it around.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching branches, we usually first try read-tree to make
sure that we do not lose the local changes and then updated the
HEAD using update-ref. However, we detached and updated HEAD
before these checks, which was quite bad in a repository with
local changes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
My sp/mmap changes to pack-check.c modified the function such that
it expects packed_git.pack_size to be populated with the total
bytecount of the packfile by the caller.
But that isn't the case for packs obtained by git-http-fetch as
pack_size was not initialized before being accessed. This caused
verify_pack to think it had 2^32-21 bytes available when the
downloaded pack perhaps was only 305 bytes in length. The use_pack
function then later dies with "offset beyond end of packfile"
when computing the overall file checksum.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Checking for reachability from refs does not help much if the
state we are currently on is somewhere in the middle. We will
lose where we were.
So this makes sureh that HEAD is something directly pointed at
by one of the existing refs (most likely a tag for a user who
has been "sightseeing").
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-svn requires the SVN::* Perl library, the manpage doesn't need
to describe what happens when you don't have it.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using cygwin with cygwin.dll before 1.5.22 the system call pread() is buggy.
This patch introduces NO_PREAD. If NO_PREAD is set git uses a sequence of
lseek()/xread()/lseek() to emulate pread.
Signed-off-by: Stefan-W. Hahn <stefan.hahn@s-hahn.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix case when git_patchset_body didn't close <div class="patch">,
for patchsets with last patch empty.
This patch also removes some commented out code in git_patchset_body.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also use `concat' instead of `format' in the pretty-printer since
format doesn't preserve properties under XEmacs.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise we get an error like this on stderr:
cat: [...]/.git/refs/remotes/origin/master: No such file or directory
which makes it look like git-clone failed.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This means that
git show HEAD:
will now return HEAD^{tree}, which is logically consistent with
git show HEAD:Documentation
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Found by running "git archive --format=tar HEAD" in Documentation/
directory.
It's surprising that nobody has noticed this from the beginning...
Signed-off-by: Junio C Hamano <junkio@cox.net>
Returning negative value from there does not stop the caller from using
the earlier part.
Noticed by Linus.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It used to ignore the return value of the helper function; now, it
expects it to return 0, and stops iteration upon non-zero return
values; this value is then passed on as the return value of
for_each_reflog_ent().
Further, it makes no sense to force the parsing upon the helper
functions; for_each_reflog_ent() now calls the helper function with
old and new sha1, the email, the timestamp & timezone, and the message.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
find_header() function is used to read and parse the patchfile
and it detects errors in the patch, but one place ignored the
error and went ahead, which was quite bad.
Noticed by Jeff Garzik.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Suggested by Jakub Narebski <jnareb@gmail.com> on the list.
When we send a value to store_write_pair(), make sure that the value
that gets read out matches the one passed in. This means that for any
value that contains leading or trailing whitespace or any comment
character (# and ;), we need to surround it in quotes.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
These new commands weren't added to .gitignore. Add them so we don't
end up with copies of them in the repo.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch, cvs add / cvs commit echoes back to the client
the correct file version (1.1) so that the file in the checkout
is recognised as up-to-date.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
if the SHA1 of our head matches the last SHA1 seen in the DB, avoid further
processing.
[jc: an "Oops, please amend" patch rolled in]
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/reflog:
reflog --fix-stale: do not check the same trees and commits repeatedly.
reflog expire --fix-stale
Move traversal of reachable objects into a separate library.
builtin-prune: separate ref walking from reflog walking.
builtin-prune: make file-scope static struct to an argument.
We need to check that the writes we perform during the update of
the users configuration work. Convert to using write_in_full().
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have a number of badly checked write() calls. Often we are
expecting write() to write exactly the size we requested or fail,
this fails to handle interrupts or short writes. Switch to using
the new write_in_full(). Otherwise we at a minimum need to check
for EINTR and EAGAIN, where this is appropriate use xwrite().
Note, the changes to config handling are much larger and handled
in the next patch in the sequence.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have a number of badly checked read() calls. Often we are
expecting read() to read exactly the size we requested or fail, this
fails to handle interrupts or short reads. Add a read_in_full()
providing those semantics. Otherwise we at a minimum need to check
for EINTR and EAGAIN, where this is appropriate use xread().
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We recently introduced a write_in_full() which would either write
the specified object or emit an error message and fail. In order
to fix the read side we now want to introduce a read_in_full()
but without an error emit. This patch cleans up the naming
of this family of calls:
1) convert the existing write_or_whine() to write_or_whine_pipe()
to better indicate its pipe specific nature,
2) convert the existing write_in_full() calls to write_or_whine()
to better indicate its nature,
3) introduce a write_in_full() providing a write or fail semantic,
and
4) convert write_or_whine() and write_or_whine_pipe() to use
write_in_full().
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we are talking about allowing potentially incompatible UI
changes in v1.5.0 iff the change improves the general situation,
I would say why not.
There is --no-utf8 flag to avoid re-coding from botching the log
message just in case, but we may not even need it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Prevent a client from overrunning the on stack ref buffer.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching branches with "git checkout", we internally did $arg^0
(aka $arg^{commit}) suffix but there was no need to.
The improvement is easily visible in the change to an existing
test t/3200-branch.sh in this commit; it was expecting rather
ugly message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After making commits in the detached HEAD state, if you run "git
checkout" to switch to an existing branch, you will lose your
work. Make sure the switched-to branch is a fast-forward of the
current HEAD, or require -f when switching.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to say "you are not on a branch" before the initial
commit. This is incorrect -- the user is on a branch yet to be
born, but its name has been already determined.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows "git checkout v1.4.3" to dissociate the HEAD of
repository from any branch. After this point, "git branch"
starts reporting that you are not on any branch. You can go
back to an existing branch by saying "git checkout master", for
example.
This is still experimental. While I think it makes sense to
allow commits on top of detached HEAD, it is rather dangerous
unless you are careful in the current form. Next "git checkout
master" will obviously lose what you have done, so we might want
to require "git checkout -f" out of a detached HEAD if we find
that the HEAD commit is not an ancestor of any other branches.
There is no such safety valve implemented right now.
On the other hand, the reason the user did not start the ad-hoc
work on a new branch with "git checkout -b" was probably because
the work was of a throw-away nature, so the convenience of not
having that safety valve might be even better. The user, after
accumulating some commits on top of a detached HEAD, can always
create a new branch with "git checkout -b" not to lose useful
work done while the HEAD was detached.
We'll see.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-branch show a detached HEAD as '* (no branch)'.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is bad manners to leave these sizable files
around when we are done with them.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes the earlier "wait for 10 minutes before importing" safety
overridable with "-a(ll)" flag, and adds necessary documentation.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes, people have only fetch access into a bare repository
that is used as a back-up location (or a distribution point) but
does not have a push access for networking reasons, e.g. one end
being behind a firewall, and updating the "current branch" in
such a case is perfectly fine.
This allows such a fetch without --update-head-ok, which is a
flag that should never be used by end users otherwise.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This removes the old is_bare_git_dir(const char *) to ask if a
directory, if it is a GIT_DIR, is a bare repository, and
replaces it with is_bare_repository(void *). The function looks
at core.bare configuration variable if exists but uses the old
heuristics: if it is ".git" or ends with "/.git", then it does
not look like a bare repository, otherwise it does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The patches to prevent Porcelainish that require working tree
from doing any damage in a bare repository make a lot of sense,
and I want to make the is_bare_git_dir() function more reliable.
In order to allow the repository owner override the heuristic
implemented in is_bare_git_dir() if/when it misidentifies a
particular repository, it would make sense to introduce a new
configuration variable "[core] bare = true/false", and make
is_bare_git_dir() notice it.
The scripts would do a 'repo-config --bool --get core.bare' and
iff the command fails (i.e. there is no such variable in the
configuration file), it would use the heuristic implemented at
the script level [*1*].
However, setup_git_env() which is called a lot earlier than we
even read from the repository configuration currently makes a
call to is_bare_git_dir(), in order to change the default
setting for log_all_ref_updates. It somehow feels that this is
a hack.
By the way, [*1*] is another thing I hate about the current
config mechanism. "git-repo-config --get" does not know what
the possible configuration variables are, let alone what the
default values for them are. It allows us not to maintain a
centralized configuration table, which makes it easy to
introduce ad-hoc variables and gives a warm fuzzy feeling of
being modular, but my feeling is that it is turning out to be a
rather high price to pay for scripts.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some users apparently create local heads with the same basename
as the remote branch they're tracking.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also, document --{trunk,branches,tags} options while we're
documenting multi-init options.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clarify definition of "reachable" (what chain?)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add discussion of git-rebase, patch series, history rewriting.
Mention "pull ." as a synonym for "merge".
Remind myself of another case I want to cover in the other-vcs's chapter.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Add a brief description of the organization to the preface, expand the
final notes/todo's section, in hopes maybe some others will want to
contribute.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
This fixes newly introduced bug when the incremental cycle edge revisions
are imported twice.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch, cvsimport will skip commits made
in the last 10 minutes. The recent-ness test is of
5 minutes + cvsps fuzz window (5 minutes default).
When working with a CVS repository that is in use,
importing commits that are too recent can lead to
partially incorrect trees. This is mainly due to
- Commits that are within the cvsps fuzz window may later
be found to have affected more files.
- When performing incremental imports, clock drift between
the systems may lead to skipped commits.
This commit helps keep incremental imports of in-use
CVS repositories sane.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove superfluous trailing "|" separator from difftree part of "commit"
view for new files (created in given commit).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since git-reset has learned restoring the absence of paths git-rm --cached is
no longer necessary. Therefore remove it from the cached content header hint.
Also remove the unfortunate wording 'Cached' from the header itself.
Signed-off-by: Jürgen Rühle <j-r@online.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make "init" the equivalent of "init-db". This should make first GIT
impression a little more friendly.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The goals are:
- Readable from beginning to end in order without having read
any other git documentation beforehand.
- Helpful section names and cross-references, so it's not too
hard to skip around some if you need to.
- Organized to allow it to grow much larger (unlike the
tutorials)
It's more liesurely than tutorial.txt, but tries to stay focused on
practical how-to stuff. It adds a discussion of how to resolve merge
conflicts, and partial instructions on setting up and dealing with a
public repository.
I've lifted a little bit from "branching and merging" (e.g., some of the
discussion of history diagrams), and could probably steal more if that's
OK. (Similarly anyone should of course feel free to reuse bits of this
if any parts seem more useful than the whole.)
There's a lot of detail on managing branches and using git-fetch, just
because those are essential even to people needing read-only access
(e.g., kernel testers). I think those sections will be much shorter
once the new "git remote" command and the disconnected checkouts are
taken into account.
I do feel bad about adding yet another piece of documentation, but I we
need something that goes through all the basics in a logical order, and
I wasn't seeing how to grow the tutorials into that.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
* sp/mmap: (27 commits)
Spell default packedgitlimit slightly differently
Increase packedGit{Limit,WindowSize} on 64 bit systems.
Update packedGit config option documentation.
mmap: set FD_CLOEXEC for file descriptors we keep open for mmap()
pack-objects: fix use of use_pack().
Fix random segfaults in pack-objects.
Cleanup read_cache_from error handling.
Replace mmap with xmmap, better handling MAP_FAILED.
Release pack windows before reporting out of memory.
Default core.packdGitWindowSize to 1 MiB if NO_MMAP.
Test suite for sliding window mmap implementation.
Create pack_report() as a debugging aid.
Support unmapping windows on 'temporary' packfiles.
Improve error message when packfile mmap fails.
Ensure core.packedGitWindowSize cannot be less than 2 pages.
Load core configuration in git-verify-pack.
Fully activate the sliding window pack access.
Unmap individual windows rather than entire files.
Document why header parsing won't exceed a window.
Loop over pack_windows when inflating/accessing data.
...
Conflicts:
cache.h
pack-check.c
This is shorter and easier to read, and also makes sure the
constant expression does not overflow integer range.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jr/status:
Improve cached content header of status output
Support --amend on initial commit in status output
Improve "nothing to commit" part of status output
Clarify syntax and role of git-add in status output
When <path> exists in the index (either merged or unmerged), and
<tree> does not have it, git-reset should be usable to restore
the absense of it from the tree. This implements it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the way diffcore represents an unmerged pair
somewhat. It used to be that entries with mode=0 on both sides
were used to represent an unmerged pair, but now it has an
explicit flag. This is to allow diff-index --cached to report
the entry from the tree when the path is unmerged in the index.
This is used in updating "git reset <tree> -- <path>" to restore
absense of the path in the index from the tree.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we use the reachability tracking machinery now, we should
keep the already checked trees and commits whose completeness is
known, to avoid checking the same thing over and over again.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The logic in an earlier round to detect reflog entries that
point at a broken commit was not sufficient. Just like we do
not trust presense of a commit during pack transfer (we trust
only our refs), we should not trust a commit's presense, even if
the tree of that commit is complete.
A repository that had reflog enabled on some of the refs that
was rewound and then run git-repack or git-prune from older
versions of git can have reflog entries that point at a commit
that still exist but lack commits (or trees and blobs needed for
that commit) between it and some commit that is reachable from
one of the refs.
This revamps the logic -- the definition of "broken commit"
becomes: a commit that is not reachable from any of the refs and
there is a missing object among the commit, tree, or blob
objects reachable from it that is not reachable from any of the
refs. Entries in the reflog that refer to such a commit are
expired.
Since this computation involves traversing all the reachable
objects, i.e. it has the same cost as 'git prune', it is enabled
only when a new option --fix-stale. Fortunately, once this is
run, we should not have to ever worry about missing objects,
because the current prune and pack-objects know about reflogs
and protect objects referred by them.
Unfortunately, this will be absolutely necessary to help people
migrate to the newer prune and repack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves major part of builtin-prune into a separate file,
reachable.c. It is used to mark the objects that are reachable
from refs, and optionally from reflogs.
The patch looks very large, but if you look at it with diff -C,
which this message is formatted in, most of them are copied
lines and there are very little additions.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is necessary for the next step, because the reason I am
making the connectivity walker into a library is because I want
to use it for cleaning up stale reflog entries.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I want to make the first part of 'git prune' that marks the
reachable objects callable as a library, so this starts the
first step toward the goal by making the callchain to pass
rev_info structure as an argument.
No functionality change should be in this step.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not replace /dev/null in two-line from-file/to-file diff header for
split patches ("split" patch mean more than one patch per one
diff-tree raw line) by a/file or b/file link.
Split patches differ from pair of deletion/creation patch in git diff
header: both a/file and b/file are hyperlinks, in all patches in a
split.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 1ebb948f65,
as that patch quieted warning but was not proper solution.
The previous commit was.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now do not skip over empty patches in git_patchset_body (where
empty means that they consist only of git diff header, and of extended
diff header, for example "pure rename" patch). This means that after
extended diff header there can be next patch (i.e. /^diff /) or end of
patchset, and not necessary patch body (i.e. /^--- /).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix error in git_patchset_body subroutine, which caused "rename to"/"copy
to" line in extended diff header to be displayed incorrectly.
While at it, fix align.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$from_id, $to_id variables should be local per PATCH.
Fix error in git_patchset_body for file creation (deletion) patches,
where instead of /dev/null as from-file (to-file) diff header line, it
had link to previous file with current file name. This error occured
only if there was another patch before file creation (deletion) patch.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Edit for conciseness.
Add a "Making changes" section header.
When possible, make sure that stuff in text boxes could be entered literally.
(Don't use "..." unless we want a user to type that.)
Move 'commit -a' example into a literal code section, clarify that it finds
modified files automatically.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clarify that dcommit creates a revision in SVN for every commit
in git. Also, add 'merge' to the rebase vs pull section because
git-merge is now a first-class UI.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clean svn path from leading '/' when accessing SVN repo.
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds ability to do import "in chunks" (default 1000 revisions),
after each chunk git repo will be repacked. The option -R is used to
change default value of chunk size (or how often repository will
repacked).
Signed-off-by: Sasha Khapyorsky <sashak@voltaire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead, reinitialize the keywords after the fact. This avoids
conflicts with other users of log-edit mode, like pcl-cvs.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It doesn't make a difference for git.el, but it helps when interacting
with git-rebase and friends.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'quiet' flag is set by -q, but it's not used anywhere.
Remove it and set the 'echo1' variable instead.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a branch other than "master" is checked out in the origin repository,
git-clone makes a local copy of that branch rather than the origin's
"master"
branch. This patch describes the actual behavior.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In order to make the generated tar files more friendly to users who
extract them as root using GNU tar and its implied -p option, change
the default umask to 002 and change the owner name and group name to
root. This ensures that a) the extracted files and directories are
not world-writable and b) that they belong to user and group root.
Before they would have been assigned to a user and/or group named
git if it existed. This also answers the question in the removed
comment: uid=0, gid=0, uname=root, gname=root is exactly what we
want.
Normal users who let tar apply their umask while extracting are
only affected if their umask allowed the world to change their
files (e.g. a umask of zero). This case is so unlikely and strange
that we don't need to support it.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we have a 64 bit address space we can easily afford to commit
a larger amount of virtual address space to pack file access.
So on these platforms we should increase the default settings of
core.packedGit{Limit,WindowSize} to something that will better
handle very large projects.
Thanks to Andy Whitcroft for pointing out that we can safely
increase these defaults on such systems.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier test timestamp was too old; I forgot that the bare
unixtime integer had to be after Jan 1, 2000. This changes
test_tick to use the git-epoch timestamp.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somehow we forgot to turn save_commit_buffer off while walking
the reachable objects. Releasing the memory for commit object
data that we do not use matters for large projects (for example,
about 90MB is saved while traversing linux-2.6 history).
Signed-off-by: Junio C Hamano <junkio@cox.net>
It might be handy to have a single command that helps you manage
your configuration that relates to downloading from remote
repositories. This currently does only about 20% of what I want
it to do.
$ git remote
shows the list of 'remotes' you have defined somewhere, and
$ git remote origin
shows the details about the named remote (in this case
"origin"). How the branches are tracked, if you have a
tracking branch that is stale, etc.
$ git add another git://git.kernel.org/pub/...
defines the default remote.another.url and remote.another.fetch
entries just like a clone does; you can say "git fetch another"
afterwards.
For it to be useful, I think it should be enhanced to:
- check overlaps of tracking branches and warn;
- offer to remove stale tracking branches in one go;
- offer ways to remove or rename remote;
- offer ways to update an existing remote, perhaps have an
interactive mode;
Other enhancements might be also possible, but I do not think of
anything that is absolutely necessary other than the above right
now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Blame currently displays the commit id which introduced a
block of one or more lines, the line numbers wrt the current
listing of the file and the file's line contents.
The commit id displayed is hyperlinked to the commit.
Currently the linenr links are hyperlinked to the same
commit id displayed to the left, which is _no_ different
than the block of lines displayed, since it is the _same
commit_ that is hyperlinked. And thus clicking on it leads
to the same state of the file for that chunk of
lines. I.e. data mining is not currently possible with
gitweb given a chunk of lines introduced by a commit.
This patch makes such data mining possible.
The line numbers are now hyperlinked to the parent of the
commit id of the block of lines. Furthermore they are
linked to the line where that block was introduced.
Thus clicking on a linenr link will show you the file's
line(s) state prior to the commit id you were viewing.
So clicking continually on a linenr link shows you how this
line and its line number changed over time, leading to the
initial commit where it was first introduced.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix "Use of uninitialized value" warning in git_tags_body generated
for lightweight tags of tree and blob object; those don't have age
($tag{'age'}) defined.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since fetch reforks itself at most every 1000 revisions, we
need to update the counter in the parent process to have a
working count if we set our repack interval to be > ~1000
revisions. multi-fetch has always done this correctly
because of an extra process; now fetch uses the extra process;
as well.
While we're at it, only compile the $sha1 regex that checks for
repacking once.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It now requires at least one of the (trunk|branch|tags) arguments
(either from the command-line or in .git/config). Also we make
sure that anything that is passed as a URL ('help') in David's
case is actually a URL.
Thanks to David Kågedal for reporting this issue.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The variable named entry is allocated using malloc() and then
forgotten, it being shadowed by an automatic variable of the
same name. Fixing the array size at 3 worked so far because
the only caller of traverse_trees() needed only as much
entries. Simply remove the shadowing varaible and we're able
to traverse more than three trees and save stack space at the
same time!
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes sparse complaining about a missing include file
if 'make check' is run on clean sources.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There was an obvious thinko in memmove() to remove an entry that
was resolved from the in-core data structure.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Running the SHA1_Update() on the whole packfile in a single call
revealed an overflow problem we had in the SHA-1 implementation
on POWER architecture some time ago, which was fixed with commit
b47f509b (June 19, 2006). Other SHA-1 implementations may have
a similar problem.
The sliding mmap() series already makes chunked calls to
SHA1_Update(), so this patch itself will become moot when it
graduates to "master", but in the meantime, run the hash
function in smaller chunks to prevent possible future problems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
My change in 190d7fdcf3 had a small bug
found by Michael Krufky which caused the passed in hash value to be
ignored, so shortlog would only show the HEAD revision.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the guts of print_ref_list() into a revamped print_ref_info(),
which at the same time gets renamed to print_ref_item().
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now do not skip over empty patches in git_patchset_body
(where empty means that they consist only of git diff header,
and of extended diff header), so uncomment branch of code dealing
with empty patches (patches which do not have even two-line
from/to header)
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix bug in git_difftree_body subroutine; it was used '!=' comparison
operator for strings (file type) instead of correct 'ne'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- Teach how to delete a branch with "git branch -d name".
- Usually a commit has one parent; merge has more.
- Teach "git show" instead of "git cat-file -p".
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This modifies pretty_print_commit() to make the output of git-rev-list and
friends a bit more predictable.
A commit body starting with blank lines might be unheard-of, but still possible
to create using git-commit-tree (so is bound to appear somewhere, sometime).
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added color.branch and color.branch.<slot> to configuration list.
Style copied from color.status and meanings derived from the code.
Moved the color meanings from color.diff.<slot> to color.branch.<slot>
since the latter comes first alphabetically.
Added --color and --no-color to git-branch's usage and documentation.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of "$projectroot/$pr->{'path'}" to get the path to project
GIT_DIR, it was used "$projectroot/$project" which is valid only
for actions where project parameter is set, and 'project_index' is not
one of them.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was stupid to link the same element twice to lock_file_list
and end up in a loop, so we certainly need a fix.
But it is not like we are taking a lock on multiple files in
this case. It is just that we leave the linked element on the
list even after commit_lock_file() successfully removes the
cruft.
We cannot remove the list element in commit_lock_file(); if we
are interrupted in the middle of list manipulation, the call to
remove_lock_file_on_signal() will happen with a broken list
structure pointed by lock_file_list, which would cause the cruft
to remain, so not removing the list element is the right thing
to do. Instead we should be reusing the element already on the
list.
There is already a code for that in lock_file() function in
lockfile.c. The code checks lk->next and the element is linked
only when it is not already on the list -- which is incorrect
for the last element on the list (which has NULL in its next
field), but if you read the check as "is this element already on
the list?" it actually makes sense. We do not want to link it
on the list again, nor we would want to set up signal/atexit
over and over.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This tries to be more to the point while also including a pointer on how to
unstage changes from the index.
Since this header is printed in two different code paths and the name of the
reference commit is needed for the unstage part, provide a new printing
function.
Signed-off-by: Jürgen Rühle <j-r@online.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We check the existence of the parent commit to determine whether the status is
requested for an initial commit. Since the parent commit depends on the
presence of the --amend switch do initial commit detection after command line
arguments have been handled.
Signed-off-by: Jürgen Rühle <j-r@online.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously git-status in a clean working directory would advice the user to use
git add. This isn't very helpful when there is nothing to add in the working
directory, therefore note a clean working directory while displaying the other
sections and print the appropriate message for each case.
Signed-off-by: Jürgen Rühle <j-r@online.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses the actual (simplified) synopsis line from the git-add man page and
advertises its incremental nature.
Signed-off-by: Jürgen Rühle <j-r@online.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When passing the revisions list to pack-objects we do not check for
errors nor short writes. Introduce a new write_in_full which will
handle short writes and report errors to the caller. Use this to
short cut the send on failure, allowing us to wait for and report
the child in case the failure is its fault.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've noticed that Apache 2.2 on a Debian etch machine has
these compiled as modules.
Also set ServerName to avoid a warning at startup.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
They are used in atexit() for clean-up, and you will be
accessing unallocated memory at that point.
See 31f584c2 for the fix for a similar problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
"Use it with care" is a wrong wording to say "this is purely internal
and you are supposed to know what you are doing if you use this".
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'sp/merge' (early part):
Use merge-recursive in git-am -3.
Allow merging bare trees in merge-recursive.
Move better_branch_name above get_ref in merge-recursive.
Update examples, stop using branch named "origin" as an example.
Remove large example of use of remotes; that particular case is
nicely automated by default, so it's not so pressing to explain, and
we can refer to git-repo-config for the details.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Removal of them is needed regardless of errors. The original
code had the removal outside of the process which sets the flag
to tell the later step what to remove, but it runs as a
downstream of a pipeline and its effect was lost.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After a pull that results in a conflicted merge, a new user
often tries another "git pull" in desperation. When the index
is unmerged, merge backends correctly bail out without touching
either index nor the working tree, so this does not make the
wound any worse.
The user will however see several lines of messsages during this
process, such as "filename: needs merge", "you need to resolve
your current index first", "Merging...", and "Entry ... would be
overwritten by merge. Cannot merge.". They are unnecessarily
alarming, and cause useful conflict messages from the first pull
scroll off the top of the terminal.
This changes pull and merge to run "git-ls-files -u" upfront and
stop them much earlier than we currently do. Old timers may
know better and would not to try pulling again before cleaning
things up; this change adds extra overhead that is unnecessary
for them. But this would be worth paying for to save new people
from needless confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This removes some unnecessary 'svn up' calls throughout
t9103-git-svn-graft-branches.sh:
* removed an 'svn log' call that was leftover from debugging
* removed multiple git-svn calls with a multi-init / multi-fetch
combination (which weren't tested before, either)
* replaced `rev-list ... | head -n1` with `rev-parse ...`
(not sure what I was thinking when I wrote that)
All this saves about 9 seconds from a test run
(53s -> 44s for 'make t91*') on my 1.3GHz Athlon
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't support the svn command-line client anymore; nor
do we support anything before SVN 1.1.0, so we can be certain
symlinks will be supported in the SVN repository.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We require the libraries now, so we can create repositories
using them (and save some executable load time while we're at
it).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We special case the case where encoding recorded in the commit
and the output encoding are the same and do not call iconv().
But we should drop 'encoding' header for this case as well for
consistency.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When your fetch configuration has only the wildcards, we would
pick the lexicographically first ref from the remote side for
merging, which was complete nonsense. Make sure nothing except
the one that is specified with branch.*.merge is merged in this
case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update tutorial's discussion of origin branch to reflect new defaults,
and include a brief mention of git-repo-config.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update glossary entry for "origin" to reflect fact that it normally now refers
to a remote repository, not a branch.
Also, warning not to work on remote-tracking branches is no longer necessary
since git doesn't allow that.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix a couple remaining references to the origin branch.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I couldn't think of a really quick way to give all the details, so just refer
readers to the git-repo-config man page instead.
I haven't tested recent cvs import behavior--some time presumably it should be
updated to do something more similar to clone.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Verify that the update hooks work as documented/advertised. This is
a simple set of tests to check that the update hooks run with the
parameters expected, have their STDOUT and STDERR redirected to
the client side of the connection, and that their STDIN does not
contain any data (as its actually /dev/null).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Corrected minor typos and documented the new k/m/g suffix for
core.packedGitWindowSize and core.packedGitLimit.
[jc: with a minor markup fix.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master:
Documentation/config.txt (and repo-config manpage): mark-up fix.
Teach Git how to parse standard power of 2 suffixes.
Use /dev/null for update hook stdin.
Redirect update hook stdout to stderr.
Remove unnecessary argc parameter from run_command_v.
Automatically detect a bare git repository.
Replace "GIT_DIR" with GIT_DIR_ENVIRONMENT.
Use PATH_MAX constant for --bare.
Force core.filemode to false on Cygwin.
Fix formatting for urls section of fetch, pull, and push manpages
Fix yet another subtle xdl_merge() bug
i18n: drop "encoding" header in the output after re-coding.
commit-tree: cope with different ways "utf-8" can be spelled.
Move commit reencoding parameter parsing to revision.c
Documentation: minor rewording for git-log and git-show pages.
Documentation: i18n commit log message notes.
t3900: test log --encoding=none
commit re-encoding: fix confusion between no and default conversion.
Sometimes its necessary to supply a value as a power of two in a
configuration parameter. In this case the user may want to use the
standard suffixes such as K, M, or G to indicate that the numerical
value should be multiplied by a constant base before being used.
Shell scripts/etc. can also benefit from this automatic option
parsing with `git repo-config --int`.
[jc: with a couple of test and a slight input tightening]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently the update hook invoked by receive-pack has its stdin
connected to the pushing client. The hook shouldn't attempt to
read from this stream, and doing so may consume data that was
meant for receive-pack. Instead we should give the update hook
/dev/null as its stdin, ensuring that it always receives EOF and
doesn't disrupt the protocol if it attempts to read any data.
The post-update hook is similar, as it gets invoked with /dev/null
on stdin to prevent the hook from reading data from the client.
Previously we had invoked it with stdout also connected to /dev/null,
throwing away anything on stdout, to prevent client protocol errors.
Instead we should redirect stdout to stderr, like we do with the
update hook.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If an update hook outputs to stdout then that output will be sent
back over the wire to the push client as though it were part of
the git protocol. This tends to cause protocol errors on the
client end of the connection, as the hook output is not expected
in that context. Most hook developers work around this by making
sure their hook outputs everything to stderr.
But hooks shouldn't need to perform such special behavior. Instead
we can just dup stderr to stdout prior to invoking the update hook.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The argc parameter is never used by the run_command_v family of
functions. Instead they require that the passed argv[] be NULL
terminated so they can rely on the operating system's execvp
function to correctly pass the arguments to the new process.
Making the caller pass the argc is just confusing, as the caller
could be mislead into believing that the argc might take precendece
over the argv, or that the argv does not need to be NULL terminated.
So goodbye argc. Don't come back.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Many users find it unfriendly that they can create a bare git
repository easily with `git clone --bare` but are then unable to
run simple commands like `git log` once they cd into that newly
created bare repository. This occurs because we do not check to
see if the current working directory is a git repository.
Instead of failing out with "fatal: Not a git repository" we should
try to automatically detect if the current working directory is
a bare repository and use that for GIT_DIR, and fail out only if
that doesn't appear to be true.
We test the current working directory only after we have tried
searching up the directory tree. This is to retain backwards
compatibility with our previous behavior on the off chance that
a user has a 'refs' and 'objects' subdirectories and a 'HEAD'
file that looks like a symref, all stored within a repository's
associated working directory.
This change also consolidates the validation logic between the case
of GIT_DIR being supplied and GIT_DIR not being supplied, cleaning
up the code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We tend to use the nice constant GIT_DIR_ENVIRONMENT when we
are referring to the "GIT_DIR" constant, but git.c didn't do
so. Now it does.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For easier portability we prefer PATH_MAX over seemingly random
constants like 1024. Make it so.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Many users have noticed that core.filemode doesn't appear to be
automatically set right on Cygwin when using a repository stored
on NTFS. The issue is that Cygwin and NTFS correctly supports
the executable mode bit, and Git properly detected that, but most
native Windows applications tend to create files such that Cygwin
sees the executable bit set when it probably shouldn't be.
This is especially bad if the user's favorite editor deletes the
file then recreates it whenever they save (vs. just overwriting)
as now a file that was created with mode 0644 by checkout-index
appears to have mode 0755.
So we introduce NO_TRUSTABLE_FILEMODE, settable at compile time.
Setting this option forces core.filemode to false, even if the
detection code would have returned true. This option should be
enabled by default on Cygwin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The line:
[remote "<remote>"]
was getting swallowed up by asciidoc, causing a critical line in the
explanation for how to store the .git/remotes information in .git/config
to go missing from the git-fetch, git-pull, and git-push manpages.
Put all of the examples into delimited blocks to fix this problem and to
make them look nicer.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In very obscure cases, a merge can hit an unexpected code path (where the
original code went as far as saying that this was a bug). This failing
merge was noticed by Alexandre Juillard.
The problem is that the original file contains something like this:
-- snip --
two non-empty lines
before two empty lines
after two empty lines
-- snap --
and this snippet is reduced to _one_ empty line in _both_ new files.
However, it is ambiguous as to which hunk takes the empty line: the first
or the second one?
Indeed in Alexandre's example files, the xdiff algorithm attributes the
empty line to the first hunk in one case, and to the second hunk in the
other case.
(Trimming down the example files _changes_ that behaviour!)
Thus, the call to xdl_merge_cmp_lines() has no chance to realize that the
change is actually identical in both new files. Therefore,
xdl_refine_conflicts() finds an empty diff script, which was not expected
there, because (the original author of xdl_merge() thought)
xdl_merge_cmp_lines() would catch that case earlier.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After re-coding the commit message into the encoding the user
specified (either with core.logoutputencidng or --encoding
option), this drops the "encoding" header altogether. The
output is after re-coding as the user asked (either with the
config or --encoding=<encoding> option), and the extra header
becomes redundant information.
Signed-off-by: Junio C Hamano <junkio@cox.net>
People can spell config.commitencoding differently from what we
internally have ("utf-8") to mean UTF-8. Try to accept them and
treat them equally.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Telling the git-log family not to do any character conversion is
done with --encoding=none, which sets log_output_encoding to an
empty string. However, logmsg_reencode() confused this with
log_output_encoding and commit_encoding set to NULL. The latter
means we should use the default encoding (i.e. utf-8).
Signed-off-by: Junio C Hamano <junkio@cox.net>
send-pack builds a pipeline that runs "rev-list | pack-objects"
and sends the output from pack-objects to the other side, while
feeding the input side of that pipe from itself. However, the
file descriptor that is given to this pipeline (so that it can
be dup2(2)'ed into file descriptor 1 of pack-objects) is closed
by the caller before the complex fork+exec dance! Worse yet,
the caller already dup2's it to 1, so the child process did not
even have to.
I do not understand how this code could possibly have been
working, but it somehow was working by accident.
Merging the sliding mmap() code reveals this problem, presumably
because it keeps one extra file descriptor open for a packfile
and changes the way file descriptors are allocated. I am too
tired to diagnose the problem now, but this seems to be a
sensible fix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I do not have any proof that this matters to any existing
problems I am seeing, but I do not think of any reason not to do
this.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code calls use_pack() to make that the variably encoded
offset fits in the mmap'ed window, but it forgot that the
operation gives the pointer to the beginning of the asked
region.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio noticed that 'non-trivial' pushes were failing if executed
using the sliding window mmap changes. This was somewhat difficult
to track down as the failure was appearing randomly.
It turns out this was a failure caused by the delta base reference
(either ref or offset format) spanning over the end of a mmap window.
The error in pack-objects was we were not recalling use_pack
after the object header was unpacked, and therefore we did not
get the promise of at least 20 bytes in the buffer for the delta
base parsing. This would case later memcmp() calls to walk into
unassigned address space at the end of the window.
The reason Junio and I had hard time tracking this down in current
Git repositories is we were both probably packing with offset deltas,
which minimized the odds of the delta base reference spanning over
the end of the mmap window. Stepping back and repacking with
version 1.3.3 (which only supported reference deltas) increased
the likelyhood of seeing the bug.
The correct technique (as used in sha1_file.c) is to invoke
use_pack() after unpack_object_header_gently to ensure we have
enough data available for the delta base decoding.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When I converted the mmap() call to xmmap() I failed to cleanup the
way this routine handles errors and left some crufty code behind.
This is a small cleanup, suggested by Johannes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In some cases we did not even bother to check the return value of
mmap() and just assume it worked. This is bad, because if we are
out of virtual address space the kernel returned MAP_FAILED and we
would attempt to dereference that address, segfaulting without any
real error output to the user.
We are replacing all calls to mmap() with xmmap() and moving all
MAP_FAILED checking into that single location. If a mmap call
fails we try to release enough least-recently-used pack windows
to possibly succeed, then retry the mmap() attempt. If we cannot
mmap even after releasing pack memory then we die() as none of our
callers have any reasonable recovery strategy for a failed mmap.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we are about to fail because this process has run out of memory we
should first try to automatically control our appetite for address
space by releasing enough least-recently-used pack windows to gain
back enough memory such that we might actually be able to meet the
current allocation request.
This should help users who have fairly large repositories but are
working on systems with relatively small virtual address space.
Many times we see reports on the mailing list of these users running
out of memory during various Git operations. Dynamically decreasing
the amount of pack memory used when the demand for heap memory is
increasing is an intelligent solution to this problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the compiler has asked us to disable use of mmap() on their
platform then we are forced to use git_mmap and its emulation via
pread. In this case large (e.g. 32 MiB) windows for pack access
are simply too big as a command will wind up reading a lot more
data than it will ever need, significantly reducing response time.
To prevent a high latency when NO_MMAP has been selected we now
use a default of 1 MiB for core.packedGitWindowSize. Credit goes
to Linus and Junio for recommending this more reasonable setting.
[jc: upcased the name of the symbolic constant, and made another
hardcoded constant into a symbolic constant while at it. ]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a basic set of tests for the sliding window mmap. We mostly
focus on the verify-pack and pack-objects implementations (including
delta reuse) as these commands appear to cover the bulk of the
affected portions of sha1_file.c.
The test cases don't verify the virtual memory size used, as
this can differ from system to system. Instead it just verifies
that we can run with very low values for core.packedGitLimit and
core.packedGitWindowSize.
Adding pack_report() to the end of both builtin-verify-pack.c and
builtin-pack-objects.c and manually inspecting the statistics output
can help to verify that the total virtual memory size attributed
to pack mmap usage is what one might expect on the current system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Much like the alloc_report() function can be useful to report on
object allocation statistics while debugging the new pack_report()
function can be useful to report on the behavior of the mmap window
code used for packfile access.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a command opens a packfile for only temporary access and does not
install the struct packed_git* into the global packed_git list then
we are unable to unmap any inactive windows within that packed_git,
causing the overall process to exceed core.packedGitLimit.
We cannot force the callers to install their temporary packfile
into the packed_git chain as doing so would allow that (possibly
corrupt but currently being verified) temporary packfile to become
part of the local ODB, which may allow it to be considered for
object resolution when it may not actually be a valid packfile.
So to support unmapping the windows of these temporary packfiles we
also scan the windows of the struct packed_git which was supplied
to use_pack(). Since commands only work with one temporary packfile
at a time scanning the one supplied to use_pack() and all packs
installed into packed_git should cover everything available in
memory.
We also have to be careful to not close the file descriptor of
the packed_git which was handed to use_pack() when all of that
packfile's windows have been unmapped, as we are already past the
open call that would open the packfile and need the file descriptor
to be ready for mmap() after unuse_one_window returns.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we are unable to mmap the a region of the packfile with the mmap()
system call there may be a good reason why, such as a closed file
descriptor or out of address space. Reporting the system level
error message can help to debug such problems.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We cannot allow a window to be smaller than 2 system pages.
This limitation is necessary to support the feature of use_pack()
where we always supply at least 20 bytes after the offset to help
the object header and delta base parsing routines.
If packedGitWindowSize were allowed to be as small as 1 system page
then we would be completely unable to access an object header which
spanned over a page as we would never be able to arrange a mapping
such that the header was contiguous in virtual memory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that our pack access code's behavior may be altered by the
setting of core.packedGitWindowSize or core.packedGitLimit we need
to make sure these values are set as configured in the repository's
configuration file rather than to their defaults.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This finally turns on the sliding window behavior for packfile data
access by mapping limited size windows and chaining them under the
packed_git->windows list.
We consider a given byte offset to be within the window only if there
would be at least 20 bytes (one hash worth of data) accessible after
the requested offset. This range selection relates to the contract
that use_pack() makes with its callers, allowing them to access
one hash or one object header without needing to call use_pack()
for every byte of data obtained.
In the worst case scenario we will map the same page of data twice
into memory: once at the end of one window and once again at the
start of the next window. This duplicate page mapping will happen
only when an object header or a delta base reference is spanned
over the end of a window and is always limited to just one page of
duplication, as no sane operating system will ever have a page size
smaller than a hash.
I am assuming that the possible wasted page of virtual address
space is going to perform faster than the alternatives, which
would be to copy the object header or ref delta into a temporary
buffer prior to parsing, or to check the window range on every byte
during header parsing. We may decide to revisit this decision in
the future since this is just a gut instinct decision and has not
actually been proven out by experimental testing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
To support multiple windows per packfile we need to unmap only one
window at a time from that packfile, leaving any other windows in
place and available for reference.
We treat all windows from all packfiles equally; the least recently
used, not-in-use window across all packfiles will always be closed
first.
If we have unmapped all windows in a packfile then we can also close
the packfile's file descriptor as its possible we won't need to map
any window from that file in the near future. This decision about
when to close the pack file descriptor may need to be revisited in
the future after additional testing on several different platforms
can be performed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we parse the object header or the delta base reference we
don't bother to loop over use_pack() calls. The reason we don't
need to bother with calling use_pack for each byte accessed is that
use_pack will always promise us at least 20 bytes (really the hash
size) after the offset. This promise from use_pack simplifies a
lot of code in the header parsing logic, as well as helps out the
zlib library by ensuring there's always some data for it to consume
during an inflate call.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When multiple mmaps start getting used for all pack file access it
is not possible to get all data associated with a specific object
in one contiguous memory region. This limitation prevents simply
passing a single address and length to SHA1_Update or to inflate.
Instead we need to loop until we have processed all data of interest.
As we loop over the data we are always interested in reusing the same
window 'cursor', as the prior window will no longer be of any use
to us. This allows the use_pack() call to automatically decrement
the use count of the prior window before setting up access for us
to the next window.
Within each loop we need to make use of the available length output
parameter of use_pack() to tell us how many bytes are available in
the current memory region, as we cannot tell otherwise.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Part of the implementation concept of the sliding mmap window for
pack access is to permit multiple windows per pack to be mapped
independently. Since the inuse_cnt is associated with the mmap and
not with the file, this value is in struct pack_window and needs to
be incremented/decremented for each pack_window accessed by any code.
To faciliate that implementation we need to replace all uses of
use_packed_git() and unuse_packed_git() with a different API that
follows struct pack_window objects rather than struct packed_git.
The way this works is when we need to start accessing a pack for
the first time we should setup a new window 'cursor' by declaring
a local and setting it to NULL:
struct pack_windows *w_curs = NULL;
To obtain the memory region which contains a specific section of
the pack file we invoke use_pack(), supplying the address of our
current window cursor:
unsigned int len;
unsigned char *addr = use_pack(p, &w_curs, offset, &len);
the returned address `addr` will be the first byte at `offset`
within the pack file. The optional variable len will also be
updated with the number of bytes remaining following the address.
Multiple calls to use_pack() with the same window cursor will
update the window cursor, moving it from one window to another
when necessary. In this way each window cursor variable maintains
only one struct pack_window inuse at a time.
Finally before exiting the scope which originally declared the window
cursor we must invoke unuse_pack() to unuse the current window (which
may be different from the one that was first obtained from use_pack):
unuse_pack(&w_curs);
This implementation is still not complete with regards to multiple
windows, as only one window per pack file is supported right now.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
To efficiently support mmaping of multiple regions of the same pack
file we want to keep the pack's file descriptor open while we are
actively working with that pack. So we are now keeping that file
descriptor in packed_git.pack_fd and closing it only after we unmap
the last window.
This is going to increase the number of file descriptors that are
in use at once, however that will be bounded by the total number of
pack files present and therefore should not be very high. It is
a small tradeoff which we may need to revisit after some testing
can be done on various repositories and systems.
For code clarity we also want to seperate out the implementation
of how we open a pack file from the implementation which locates
a suitable window (or makes a new one) from the given pack file.
Since this is a rather large delta I'm taking advantage of doing
it now, in a fairly isolated change.
When we open a pack file we need to examine the header and trailer
without having a mmap in place, as we may only need to mmap
the middle section of this particular pack. Consequently the
verification code has been refactored to make use of the new
read_or_die function.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Like write_or_die read_or_die reads the entire length requested
or it kills the current process with a die call.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since the index_size and pack_size members of struct packed_git
are the lengths of those corresponding files we should use the
off_t size of the operating system to store these file lengths,
rather than an unsigned long. This would help in the future should
we ever resurrect Junio's 64 bit index implementation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The idea behind the sliding mmap window pack reader implementation
is to have multiple mmap regions active against the same pack file,
thereby allowing the process to mmap in only the active/hot sections
of the pack and reduce overall virtual address space usage.
To implement this we need to refactor the mmap related data
(pack_base, pack_use_cnt) out of struct packed_git and move them
into a new struct pack_window.
We are refactoring the code to support a single struct pack_window
per packfile, thereby emulating the prior behavior of mmap'ing the
entire pack file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than hardcoding the maximum number of bytes which can be
mmapped from pack files we should make this value configurable,
allowing the end user to increase or decrease this limit on a
per-repository basis depending on the size of the repository
and the capabilities of their operating system.
In general users should not need to manually tune such a low-level
setting within the core code, but being able to artifically limit
the number of bytes which we can mmap at once from pack files will
make it easier to craft test cases for the new mmap sliding window
implementation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The unpack_entry_gently function currently has only two callers:
the delta base resolution in sha1_file.c and the main loop of
pack-check.c. Both of these must change to using unpack_entry
directly when we implement sliding window mmap logic, so I'm doing
it earlier to help break down the change set.
This may cause a slight performance decrease for delta base
resolution as well as for pack-check.c's verify_packfile(), as
the pack use counter will be incremented and decremented for every
object that is unpacked.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When '*.ig' is ignored, and you have two files f.ig and d.ig/foo
in the working tree,
$ git add .
correctly ignored f.ig but failed to ignore d.ig/foo. This was
caused by a thinko in an earlier commit 4888c534, when we tried
to allow adding otherwise ignored files.
After reverting that commit, this takes a much simpler approach.
When we have an unmatched pathspec that talks about an existing
pathname, we know it is an ignored path the user tried to add,
so we include it in the set of paths directory walker returned.
This does not let you say "git add -f D" on an ignored directory
D and add everything under D. People can submit a patch to
further allow it if they want to, but I think it is a saner
behaviour to require explicit paths to be spelled out in such a
case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not that this reveals anything new, but I did test_tick shell
function in test-lib and found it rather cute and nice.
Signed-off-by: Junio C Hamano <junkio@cox.net>
By switching from merge-resolve to merge-recursive in the 3-way
fallback behavior of git-am we gain a few benefits:
* renames are automatically handled, like in rebase -m;
* conflict hunks can reference the patch name;
* its faster on Cygwin (less forks).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
To support wider use cases, such as from within `git am -3`, the
merge-recursive utility needs to accept not just commit-ish but
also tree-ish as arguments on its command line.
If given a tree-ish then merge-recursive will create a virtual commit
wrapping it, with the subject of the commit set to the best name we
can derive for that tree, which is either the command line string
(probably the SHA1), or whatever string appears in GITHEAD_*.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
To permit the get_ref function to use the static better_branch_name
function to generate a string on demand I'm moving it up earlier.
The actual logic was not affected in this change.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/utf8:
t3900: test conversion to non UTF-8 as well
Rename t3900 test vector file
UTF-8: introduce i18n.logoutputencoding.
Teach log family --encoding
i18n.logToUTF8: convert commit log message to UTF-8
Move encoding conversion routine out of mailinfo to utf8.c
Conflicts:
commit.c
This changes the default remote.origin.fetch configuration
created by git-clone so that it allows non-fast-forward updates.
When using the separate-remote layout with reflog enabled, it
does not make much sense to refuse to update the remote tracking
branch just because some of them do not fast-forward. git-fetch
issues warnings on non-fast-forwardness, and the user can peek
at what the previous state was using the reflog.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In some environments, certain tests have no way of succeeding
due to platform limitation, such as lack of 'unzip' program, or
filesystem that do not allow arbitrary sequence of non-NUL bytes
as pathnames.
You should be able to say something like
$ cd t
$ GIT_SKIP_TESTS=t9200.8 t9200-git-cvsexport-commit.sh
and even:
$ GIT_SKIP_TESTS='t[0-4]??? t91?? t9200.8' make test
to omit such tests. The value of the environment variable is a
SP separated list of patterns that tells which tests to skip,
and either can match the "t[0-9]{4}" part to skip the whole
test, or t[0-9]{4} followed by ".$number" to say which
particular test to skip.
Note that some tests in the existing test suite rely on previous
test item, so you cannot arbitrarily disable one and expect the
remainder of test to check what the test originally was intended
to check.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise, sending the diagnostic to stdout would provoke a
protocol failure.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function xdl_refine_conflicts() tries to break down huge
conflicts by doing a diff on the conflicting regions. However,
this does not make sense when one side is empty.
Worse, when one side is not only empty, but after EOF, the code
accessed unmapped memory.
Noticed by Luben Tuikov, Shawn Pearce and Alexandre Julliard, the
latter providing a test case.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This could be useful in finding new problems and helping users
debug.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have less code to worry about now. As a bonus, --revision
can be used to reliably skip parts of history whenever fetch is
run, not just the first time. I'm not sure why anybody would
want to skip history in the middle, however...
For people (nearly everyone at the moment) without the
do_switch() function in their Perl SVN library, the entire tree
must be refetched if --follow-parent is used and a parent is
found. Future versions of SVN will have a working do_switch()
function accessible via Perl.
Accessing repositories on the local machine (especially file://
ones) is also slightly slower as a result; but I suspect most
git-svn users will be using it to access remote repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I don't think anybody running tests needs to know they're
running init-db and creating a repository for testing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We get an extra measure of error checking here as well.
While we're at it, also removed a less portable use of export.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/shallow:
fetch-pack: Do not fetch tags for shallow clones.
get_shallow_commits: Avoid memory leak if a commit has been reached already.
git-fetch: Reset shallow_depth before auto-following tags.
upload-pack: Check for NOT_SHALLOW flag before sending a shallow to the client.
fetch-pack: Properly remove the shallow file when it becomes empty.
shallow clone: unparse and reparse an unshallowed commit
Why didn't we mark want_obj as ~UNINTERESTING in the old code?
Why does it mean we do not have to register shallow if we have one?
We should make sure that the protocol is still extensible.
add tests for shallow stuff
Shallow clone: do not ignore shallowness when following tags
allow deepening of a shallow repository
allow cloning a repository "shallowly"
support fetching into a shallow repository
upload-pack: no longer call rev-list
Now that git-merge knows how to use the pull.{twohead,octopus}
configuration options to select the default merge strategy there
is no reason for git-pull to do the same immediately prior to
invoking git-merge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If git-merge is invoked without a strategy argument it is probably
being run as a porcelain-ish command directly and is not being run
from within git-pull. However we still should honor whatever merge
strategy the user may have selected in their configuration, just as
`git-pull .` would have.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If git-merge exits with a non-zero exit status so should git-pull.
This way the caller of git-pull knows the task did not complete
successfully simply by checking the process exit status.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a three-way merge in git-rebase generates a conflict then we
should take advantage of git-merge-recursive's ability to include
the branch name of each side of the conflict hunk by setting the
GITHEAD_* environment variables.
In the case of rebase there aren't really two clear branches; we
have the branch we are rebasing onto, and we have the branch we are
currently rebasing. Since most conflicts will be arising between
the user's current branch and the branch they are rebasing onto
we assume the stuff that isn't in the current commit is the "onto"
branch and the stuff in the current commit is the "current" branch.
This assumption may however come up wrong if the user resolves one
conflict in such a way that it conflicts again on a future commit
also being rebased. In this case the user's prior resolution will
appear to be in the "onto" part of the hunk.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
To help correctly log actions caused by porcelain which invoke
git-reset directly we should honor the setting of GIT_REFLOG_ACTION
which we inherited from our caller.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio rightly pointed out that the --reflog-action parameter
was starting to get out of control, as most porcelain code
needed to hand it to other porcelain and plumbing alike to
ensure the reflog contained the top-level user action and
not the lower-level actions it invoked.
At Junio's suggestion we are introducing the new set_reflog_action
function to all shell scripts, allowing them to declare early on
what their default reflog name should be, but this setting only
takes effect if the caller has not already set the GIT_REFLOG_ACTION
environment variable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Following advice from CGI(3pm) man page, precompile all CGI routines
for mod_perl, in the BEGIN block.
If you want to compile without importing use the compile() method
instead:
use CGI();
CGI->compile();
This is particularly useful in a mod_perl environment, in which you
might want to precompile all CGI routines in a startup script, and then
import the functions individually in each mod_perl script.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add mod_perl version string (the value of $ENV{'MOD_PERL'} if it is
set) to "generator" meta header.
The purpose of this is to identify version of gitweb, now that
codepath may differ for gitweb run as CGI script, run under
mod_perl 1.0 and run under mod_perl 2.0.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It appears ISO-2022-JP is more widely accepted than ISO2022JP, so
rename it that way. We probably would need to have a way to skip
this test altogether in locale-challenged environments.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It appears that curl_easy_duphandle() from libcurl 7.16.0
returns a curl session handle which fails GOOD_MULTI_HANDLE()
check in curl_multi_add_handle(). This causes fetch_ref() to
fail because start_active_slot() cannot start the request.
For now, check for 7.16.0 to work this issue around.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* sp/gc:
Use 'repack -a -d -l' instead of 'repack -a -d' in git-gc
everyday: replace a few 'prune' and 'repack' with 'gc'
Create 'git gc' to perform common maintenance operations.
It is plausible for somebody to want to view the commit log in a
different encoding from i18n.commitencoding -- the project's
policy may be UTF-8 and the user may be using a commit message
hook to run iconv to conform to that policy (and either not have
i18n.commitencoding to default to UTF-8 or have it explicitly
set to UTF-8). Even then, Latin-1 may be more convenient for
the usual pager and the terminal the user uses.
The new variable i18n.logoutputencoding is used in preference to
i18n.commitencoding to decide what encoding to recode the log
output in when git-log and friends formats the commit log message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This should not be necessary for people who only use NTFS, but for
people with FAT32 it seems to be an issue. Let's ship with a safer
default.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Re-enable rev-list --parents for parse_commit which was removed in
(208b2dff95). rev-list --parents is not
just used to return the parent headers in the commit object, it
includes any grafts which are vaild for the commit.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If user hits enter at the prompt for
"Who should the emails appear to be from?",
the value for "From:" field was emptied instead of GIT_COMMITER_IDENT.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is to adjust to:
count-objects -v: show number of packs as well.
which will break a test in this series.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio asked for a 'git gc' utility which users can execute on a
regular basis to perform basic repository actions such as:
* pack-refs --prune
* reflog expire
* repack -a -d
* prune
* rerere gc
So here is a command which does exactly that. The parameters fed
to reflog's expire subcommand can be chosen by the user by setting
configuration options in .git/config (or ~/.gitconfig), as users may
want different expiration windows for each repository but shouldn't
be bothered to remember what they are all of the time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recent "git push" keeps transferred objects packed much more aggressively
than before. Monitoring output from git-count-objects -v for number of
loose objects is not enough to decide when to repack -- having too many
small packs is also a good cue for repacking.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/fsck-reflog:
Add git-reflog to .gitignore
reflog expire: do not punt on tags that point at non commits.
reflog expire: prune commits that are not incomplete
Don't crash during repack of a reflog with pruned commits.
git reflog expire
Move in_merge_bases() to commit.c
reflog: fix warning message.
Teach git-repack to preserve objects referred to by reflog entries.
Protect commits recorded in reflog from pruning.
add for_each_reflog_ent() iterator
Fix minor mark-up mistakes and adjust to v1.5.0 BCP, namely:
- use "git add" instead of "git update-index";
- use "git merge" instead of "git pull .";
- use separate remote layout;
- use config instead of remotes/origin file;
Also updates "My typical git day" example since now I have
'next' branch these days.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a followup to dd31da2fdc.
Regardless of whether we commit an alternate head, we always
diff-tree based on the current HEAD, and rebase against our
remote reference as necessary.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The latest changes to git-commit have made it more verbose; and
I was running the setup of the tests outside of the test_expect_*,
so errors in those were not caught. Now we move them to where
they can be eval'ed and have their output trapped.
export var=value has been removed
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After checking to see if the commit message already has the target
signed-off-by (for example in --amend commits), this patch generates a
signed off by line from the repository owner and adds it to the commit
message.
Based on Johannes Schindelin's earlier patch to perform the same
function.
Originally, this was done in the pre-commit hook but Junio pointed out
that the commit-msg hook allows the message to be edited. This has the
aditional advantage that the commit-msg hook gets passed the name of the
message file as a parameter, so it doesn't have to figure out GIT_DIR for
itself.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Updated commit objects record the encoding used in their
encoding header. This updates the log family to reencode it
into the encoding specified in i18n.commitencoding (or the
default, which is "utf-8") upon output.
To force a specific encoding that is different, log family takes
command line flag --encoding=<encoding>; giving --encoding=none
entirely disables the reencoding and lets you view log messges
in their original encoding.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When i18n.commitencoding is set to a non UTF-8 encoding,
commit-tree records the encoding in an extra header after
author/committer headers in the commit object.
An earlier version used trailer but Johannes points out that
there is little risk breaking existing Porcelains with a new
header.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is unusual for a tag to point at a non-commit, and it is also
unusual for a tag to have reflog, but that is not an error and
we should still prune its reflog entries just as other refs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Older fsck-objects and prune did not protect commits in reflog
entries, and it is quite possible that a commit still exists in
the repository (because it was in a pack, or something) while
some of its trees and blobs are long gone. Make sure the commit
and its associated tree is complete and expire incomplete ones.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user has been using reflog for a long time (e.g. since its
introduction) then it is very likely that an existing branch's
reflog may still mention commits which have long since been pruned
out of the repository.
Rather than aborting with a very useless error message during
git-repack, pack as many valid commits as we can get from the
reflog and let the user know that the branch's reflog contains
already pruned commits. A future 'git reflog expire' (or whatever
it finally winds up being called) can then be performed to expunge
those reflog entries.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master:
Introduce a global level warn() function.
Rename imap-send's internal info/warn functions.
_XOPEN_SOURCE problem also exists on FreeBSD
parse-remote: mark all refs not for merge only when fetching more than one
git-reset --hard: tell the user what the HEAD was reset to
git-tag: support -F <file> option
Revert "git-pull: refuse default merge without branch.*.merge"
Suggest 'add' in am/revert/cherry-pick.
Use git-merge-file in git-merge-one-file, too
diff --check: fix off by one error
Documentation/git-branch: new -r to delete remote-tracking branches.
Fix system header problems on Mac OS X
spurious .sp in manpages
This prepares a place to collect reflog management subcommands,
and implements "expire" action.
$ git reflog expire --dry-run \
--expire=4.weeks \
--expire-unreachable=1.week \
refs/heads/master
The expiration uses two timestamps: --expire and --expire-unreachable.
Entries older than expire time (defaults to 90 days), and entries older
than expire-unreachable time (defaults to 30 days) and records a commit
that has been rewound and made unreachable from the current tip of the
ref are removed from the reflog.
The parameter handling is still rough, but I think the
core logic for expiration is already sound.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When ref@{N} is specified on a ref that has only M entries (M < N),
instead of saying the initial timestamp the reflog has, warn that
there is only M entries.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a new option --reflog to pack-objects and revision
machinery; do not bother documenting it for now, since this is
only useful for local repacking.
When the option is passed, objects reachable from reflog entries
are marked as interesting while computing the set of objects to
pack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user has partial includes disabled then it doesn't matter what
state the working directory is in; if the file has been included in
the next commit its index state is A or M and we should immediately
run update-index on the working directory file to bring the index in
sync with the working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a file has a merge conflict (index state = U) the user will need to
run update-index on that file to resolve all stages down to stage 0,
by including the file in the working directory.
Like core Git we'll just trust the user that their resolution is
correct, and that they didn't just include the file into the commit
while merge conflicts still exist within the file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This implementation of switch_branch is not yet finished, and thus
it throws a "NOT FINISHED" error rather than completing the switch.
But its a rough sketch of the procedure required.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since this list is really the set of refs which match "refs/heads/*" it
really is the set of heads and not necessarily the set of all branches,
as the remote tracking branches are not listed in this set, even if it
appears in the "refs/heads/*" namespace (e.g. an old style repository).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since the user should not work on a tracking branch we automatically
hide any branch which is used as a tracking branch by either a
remote.<name>.fetch config entry or by a Pull: line in a remotes file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm not currently ready to implement branch switching, so I'm just
going to punt on it for now. :-)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Even though the user shouldn't have a remote branch checked out, if
they do we should still show as short of the branch name as possible.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A better fix may be to only fetch tags that point to commits that we
are downloading, but git-clone doesn't have support for following
tags. This will happen automatically on the next git-fetch though.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise fetching the tags could also fetch commits up to the
specified depth, which isn't the expected behavior.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A commit may have been put on the shallow list, and then reached from
another branch and marked NOT_SHALLOW without being removed from the
list.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Tags should be considered when truncating the
commit list. The patch below fixes it, and fetches the right number of
commits for each tag. However the correct fix is probably to not fetch
historical tags at all.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, by saying "git fetch -depth <n> <repo>" you can deepen
a shallow repository.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
By specifying a depth, you can now clone a repository such that
all fetched ancestor-chains' length is at most "depth". For example,
if the upstream repository has only 2 branches ("A" and "B"), which
are linear, and you specify depth 3, you will get A, A~1, A~2, A~3,
B, B~1, B~2, and B~3. The ends are automatically made shallow
commits.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A shallow commit is a commit which has parents, which in turn are
"grafted away", i.e. the commit appears as if it were a root.
Since these shallow commits should not be edited by the user, but
only by core git, they are recorded in the file $GIT_DIR/shallow.
A repository containing shallow commits is called shallow.
The advantage of a shallow repository is that even if the upstream
contains lots of history, your local (shallow) repository needs not
occupy much disk space.
The disadvantage is that you might miss a merge base when pulling
some remote branch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is trivial to do now, and it is needed for the upcoming shallow
clone stuff.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is an early start at branch management from within git-gui. The
branch menu has create/delete command entries to create and delete
branches as well as a list of radiobutton entries for each branch
found in the repository through for-each-ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently I missed the file state MD, which is a file modified and
updated in the index but then removed from the working directory. This
should be treated just like AD, an added file which has been deleted from
the working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users want to know what branch they are sitting on before making a commit,
as they may need to switch to a different branch first.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users sometimes need to be able to throw away locally modified files
in order to go back to the last committed version of that file. To
perform a revert the user must first uninclude each file from the new
commit as the working file must at least partially match the index,
and we use git-checkout-index to update the working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Just like prior to a commit its only an informational message that
we refuse to perform a pull on a dirty working directory. Therefore
we should not use an error icon.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since gitk is currently broken on Mac OS X and is unable to start itself
when given command line parameters just don't offer the "Visual All
Branches" menu option on Mac OS X.
Once this feature of gitk is fixed we should change this section of code
to make sure a working version of gitk will be executed before we offer
the option up to the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes its useful to start gitk with the --all option, to view all of
the known branches and tags within this repository. Rather than making
the user startup gitk and then edit the view we can pass the option along
for them.
This also makes it slightly more explicit, that when gitk starts up by
default its showing the current branch and not everything. Yes gitk
isn't showing that to the user, but the fact that the user had to make
a decision between seeing this current branch or all branches will
hopefully make them study gitk's display before jumping to a conclusion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because the Tcl binary distributed with Cygwin tends to not pass along
its own environment (the env array) to its children, its unlikely that
any Git commands spawned by git-gui will receive the same environment
variables that git-gui itself received from the shell which started it.
If the user is counting on environment variables to pass down, like say
GIT_INDEX_FILE, they may not, so we warn them during git-gui startup
that things may not work out as the user intended. Perhaps one day
when git-gui and git are running on native Windows (rather than through
the Cygwin emulation layers) things will work better.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Darwn based UNIX systems are not necessarily Mac OS X. However the only
windowing system used by Tk that is Mac OS X is 'aqua', and only 'aqua'
exists on Mac OS X. Therefore this is a more reliable test for the
Macintosh platform.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like the is_MacOSX proc we shouldn't keep repeating the platform test
for Windows. Instead abstract the code out into a procedure and use
the procedure whenever we need to do something special.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users may need to know what version of Tcl they are running git-gui
under, in case there is an interesting interface quirk or other
compatability problem we don't know about right now that we may
need to explore (and maybe fix). Since its simple enough to show
a line with this version data we should do so.
We also try to reduce the amount of text shown as often the Tcl and Tk
version numbers will be identical; when this happens we should only show
the one version number.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The copyright notice we display in the about dialog should be the same
as the one at the top of our source code. By putting the copyright
notice that appears at the top of our source code into a global variable
rather than a comment we can trivially make them the same at all times.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It is tradition for applications to store their about and preferences
menu options within the application menu. This is the first menu in
the menu bar, just after the apple menu. Apparently the way to access
this menu from Tk on Mac OS X systems is to create a special menu whose
name ends in ".apple" and place it into the menu bar.
So now if we are on Mac OS X we move our about menu and our options menu
into the application menu, like other Mac OS X applications.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Created a help menu with an about dialog box. This about dialog
shows the copyright notice for the application, the fact that it
is covered by the GPL v2.0 or later, the authors, and the current
version of Git it is invoking when users perform actions within it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since all of the actions in our Project menu actually apply to the
Git concept of a repository, it is a disservice to our users to
call it "project". This is especially true if Git ever gets any
sort of subproject support, as the term would then most definately
conflict.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The project menu is just too cluttered without using separator entries
to split out the database operations (such as repack and verify) from
the other options in the same menu.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It would be something of a disservice to our users if we refer to
fsck-objects as "verify". So instead we call it fsck-objects in
the console title, and indicate that's how we are verifying the
object database.
We probably should call our menu option "fsck-objects" or similar
but I really do think that "Verify Database" more accurately describes
the action then "fsck-objects" does, especially to users who aren't
file system developers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we don't automatically restart in amend mode when we quit while
in amend mode the commit message buffer shouldn't be saved to GITGUI_MSG
as it would be misleading when the user restarts the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I recently found a need to run fsck-objects in a number of repositories
that I also use git-gui against. Tossing in a menu option to invoke
fsck-objects and have its output show up in a console window is simple
enough to do.
We probably need to enhance the console window used by fsck-objects,
like to open up the Git fsck-objects manual page and let the user see
what each message means (such as "dangling commit") and to also let the
user invoke prune, to cleanup any such dangling objects. But right now
I'm going to ignore that problem in favor of getting other more important
features implemented.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its useful to be able to amend the last commit even if it was a merge
commit, so we really should support that in the gui. We now do so by
making PARENT a list. We always diff against the first parent but we
create a commit consisting of the parent(s) listed in this list, in
order.
We also should recheck the repository state during an amend. Earlier
I was bitten by this exact bug when I switched branches through a
command prompt and then did not do a rescan in git-gui. When I hit
"Amend Last Commit" I was surprised to see information from the prior
branch appear. This was due to git-gui caching the data from the last
rescan and using that data form the amend data load request, rather than
the data of the current branch.
Improved error text in the dialogs used to tell the user why an amend is
being refused by git-gui. In general this is only during an initial
commit (nothing prior to amend) and during a merge commit (it is simply
too confusing to amend the last commit while also trying to complete a
merge).
Fixed a couple of minor bugs in the pull logic. Since this code isn't
really useful nobody has recently tested it and noticed the breakage.
It really needs to be rewritten anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In order to allow the user to toggle include/exclude from next commit
for files which were partially included in the last commit we need the
current index mode+sha1 data stored in our file_states array. For
any partially included file we have this information from diff-files,
so we just have to copy it over to the diff-index portion of our state
array.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The tags used for diff formatting (which I inherited from gitool) just
didn't make a whole lot of sense, especially if you wanted to try to
match them to the diff output you were seeing on screen. It did not
help that the diff-index -c output's first two columns are also munged
to make the diff output more user friendly.
So this is a large refactoring of the tags used for diff display. Now
our tag names match what we put in the left column of each line, which
makes it easier to correlate presentation and implementation.
I removed bold font usage from everything except the hunk headers as I
really did not like the way bold font caused column alignments to become
out of whack within the diff viewer. It also drew attention to the parts
of the file which were identically changed in both the index and in the
working directory, yet these are usually the parts I find myself caring
the least about. So its very counter-intuitive.
Lines which are changed differently by both the index and the working
directory are now shown with background colors which span the entire line,
making these lines easier to pick out of the diff. In general these are
the lines that appear to be more interesting to me when looking at the
3-way diff as they are the ones which contain recent and quite different
changes.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
New files also lack index data from diff-files therefore we cannot use
their diff-files index data when we update-index. Instead we can use
the fact that Git has them hardcoded as "0 0{40}" and do the same thing
ourselves. This way you can toggle an untracked file into added status
and back out to untracked.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Currently core-git's diff utilities report a deleted symlink as a
deleted file with a mode of 120000. This is not nearly as user
friendly as one might like, as the user must remember that 120000
is the UNIX mode bits for a symlink. So instead we transform
the not-so-friendly message from core-git into a slightly more
user friendly "deleted symlink" message.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Tcl let me assign two different types of values to the variable $n.
Prior to 1461c5f3 $n was the total number of bytes in the string;
but in that commit it also became the current info list for the
current file. This caused $c < $n to fail as $n was now treated
as 0 and we only loaded the first file in each buffer.
So use a different variable, like $i, instead.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There was a bug with the way we handled deleted file status. A file
really shouldn't be in D_ state when it has been deleted, instead it
is really DD. Therefore we should have toggled _D to DD, not D_,
thereby letting us toggle back to _D.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user clicks on the icon associated with a file we now flip to the
inverse status. Partially included files first fully include, then fully
uninclude, as we don't keep track of intermediate partial inclusions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes the user may want to keep their working directory file to be
the same content but they don't want it to be part of the current commit
anymore. In this case we need to undo any changes made to the index
for that file (by reloading the info from HEAD or removing the file
from the index) but leave the working directory alone.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Turns out that we really don't need the Contents/PkgInfo file on Mac OS
10.4. The Finder will still launch the application properly without one.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The previous implementation of do_include_selection did not actually
add files in state _O (untracked, not added) into the repository when
they were in the selection and Commit->Include Selected Files was used.
This was due to the file state filtering logic being the same as that
of Commit->Include All Files, which only considers existing files.
Also fixed a minor issue with rejected attempts to amend an initial
commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its not an error that a rescan is required before commit; its just
something we do as a safety feature to try and ensure the user knows
what is going into this commit. So the dialog should use the info
icon (if one is used by the host OS) rather than the error icon.
Its also not "highly likely" that another Git program modified the
repository, its completely the case. There is no reason why the
repository would not match our last scanned state unless another
Git program modified the repository (or someone else did so by hand).
So don't be vague about it, own up to the issue and go on with our
business.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since git-commit also checks that the user has a GIT_COMMITTER_IDENT
value before it lets the user make a commit we should do the same check
here in git-gui. We cache the result and assume that the user won't
do something which would change the status of GIT_COMMITTER_IDENT while
we are running.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I was starting to find it annoying that once you entered the 'Amend Last'
mode there was no way to go back to the 'New Commit' mode without quitting
and restarting git-gui. Its just confusing for the end-user.
Now we can flip back and forth between a new commit and an amend commit
through a pair of radio buttons on the header of the commit buffer area
and through a pair of radio menu buttons in the Commit menu.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we immediately start a rescan operation, but do so slightly
delayed (by 1 ms, to let the UI show before we start forking off
git processes), we can't let the user try to activate any of the
restricted GUI commands before the 1 ms timer expires and we kick
off the rescan.
So now we lock the index before we enter the Tk event loop, ensuring
that it is impossible for the user to inject a conflicting UI event
before our rescan can begin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the user selects a number of files they would typically expect
to be able to act on that selection, such as by including those files
into the next commit.
So we now have a menu option under the Commit menu that lets the user
include only the selection, rather than everything. If there is no
selection but there is a file in the diff viewer than we consider that
to be the selection (a selection of 1). Unfortunately we don't disable
this option yet when there's nothing selected to include, but this is
probably not a big deal as there are very few situations where there
are no selected files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It just felt wrong to me that I was using _ as part of the mode argument
to display_file to mean "don't care/use existing" and * as part of
the mode argument to mean "force to _".
So instead use ? to mean "don't care/use existing" and _ to mean
"force to _". The code is a lot clearer this way and hopefully it
won't drive another developer insane, as it did me.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I noticed that we were reshowing the current diff during a commit;
this occurs because we feed every added and modified file through
update-index just before commit. During the update-index process
we reshow the current diff if the current file in the diff pane
was one of those added or modified files we reprocessed. This
just slows down the UI more than is necessary.
So refactoring update_index so that we don't call reshow_diff
from within that code; instead we do it at a higher level.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently I never really tested the logic for making or amending an
initial commit, so although most of the code was here in git-gui it
didn't quite work as it was intended to.
So this is all just bug fixes to make initial commits correctly
generate the list of files going into the initial commit, or to
show a newly added file's diff, and to amend an initial commit.
Because we really want to diff the index against a tree-ish and
there is no such tree-ish on an initial commit we create an empty
tree through git-mktree and diff against that. This unfortunately
creates a dangling tree, which may confuse a new user who uses
git-gui to make a new commit and then immediately afterwards runs
git fsck-objects to see if their object database is corrupt or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we can't locate a .git directory for the given directory we need to
show a message to the user to let them know the directory wasn't found.
But since this is before we have shown our main application window we
cannot use that as the parent for the error popup; on Mac OS X this
causes an error and prevents the dialog from showing.
Instead only add -parent . to the popup call if we have mapped (shown)
the main window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a user works with a repository frequently they may want to just
create an icon they can use to launch git-gui against that repository.
Since we already support this concept on Windows we can do the same on
Mac OS X by creating a .app file with a tiny shell script in it that
sets up the necessary environment then invokes our script.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Don't offer to fetch from a remote unless we have at least one Pull:
line in its .git/remotes/<name> file or at least one configuration
value for remote.<name>.fetch. Ditto for push.
Users shouldn't be fetching or pushing branch groups unless they
have them configured; anything else is just crazy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we have some serious problems with the GIT_DIR environment variable
on Windows we cannot let the user use a non-standard GIT_DIR with their
working directory.
So require that the GIT_DIR name is actually ".git", that it exists,
and that its parent directory is our working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are running on Windows we now offer a 'Create Desktop Icon' menu
item under the Project menu. This pops up a save dialog box letting
the user create a .bat file on their desktop (or somewhere else). The
.bat script will startup Cygwin with a login shell then launch git-gui
in the current working directory.
This is very useful for Windows users who have little to no desire to
start a command window just to run a git-gui session.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some users may want to start us by running "git --git-dir=... gui"
rather than trying to cd into the directory first. This is especially
true if they want to just make a shortcut to our executable on Windows
and always have that associated with a certain repository.
Since Tcl on Windows throws away our environment and doesn't pass it
down to the child process correctly we cannot call git-rev-parse to
get the GIT_DIR environment variable. So instead we ask for it
specifically ourselves; if its not defined then we ask rev-parse.
This should actually reduce startup by 1 fork/exec if we were started
as "git gui" as GIT_DIR will be set for us.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we want to be installed in gitexecdir so that "git gui" works we
can guess where that directory is by asking the git wrapper executable
and locating ourselves at the same location using the same install
rules as core git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is no reason why the user should be able to operate on the diff
buffer if there is no currently selected diff; likewise the "File:"
label text appears rather silly looking all by itself when no diff
is being shown in the diff buffer.
So now we only enable widgets (like menu items) if there is a diff
currently showing, and we disable them when a diff isn't showing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user has "Allow Partially Included Files" disabled (and most
probably will as its the default setting) we should run update-index
on every included file before commit to make sure that any changes
made by the user since the last rescan will still be part of this
commit.
If we don't update-index every modified file the user will likely
become confused when part of their changes were committed and other
parts weren't; and those other parts won't show up until a later
rescan occurs. Since we don't rescan immediately after a commit
this may be a while.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like rescan we also have cases where we need to perform a script
after we have finished updating a number of files in the index. By
changing the parameter structure of update_index we can easily pass
through any script we need to run afterwards, such as picking up
in the middle of a commit, or finishing what is left of a rescan.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There are some situations where we need to run rescan and have it do
more than just updating the status in the UI when its complete. To
help with that this changes the rescan procedure to take a script which
it will run at the global level as soon as the rescan is done and the
UI has finished updating with the results. This is useful for example
if we performed a rescan as part of a commit operation; we can go back
to the commit where we left off when the rescan got initiated.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we refer to the act of updating our memory structures with index
and working directory differences as a rescan in the UI its probably
a good idea to make the related procedures have the same name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because I want to let users apply actions to more than one file at
a time we really needed a concept of "the current selection" from
the two file lists.
Since I'm abusing a Tk text widget for the file displays I can't
really use the Tk selection to track which files are picked and
which aren't. So instead we keep this in an array to tell us
which paths are currently selected and we use an inverse fg/bg
for the selected file display. This is common most operating
systems as a selection indicator.
The selection works like most users would expect; single click will
clear the selection and pick only that file, M1-click (aka Ctrl-click
or Cmd-click) will toggle the one file in/out of the selection, and
Shift-click will select the range between the last clicked file and
the currently clicked file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Mac OS X the no differences informational message was linewrapped
at the wrong points due to the limited width of the system dialog,
yet the LFs embedded in the message (where I linewrapped it manually)
were also being honored. This resulted in a very difficult to read
paragraph of text.
So this narrows the text down by another 10 columns or so, making it
more readable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm not a huge fan of putting the left and right mouse actions into
the same procedure. Originally this is how Paul had implemented the
logic in gitool and I had carried some of that over into git-gui, but
now that I'm getting ready to implement right mouse click features to
act on files I really should split this apart.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The concept of the Git index is confusing for many users, especially
those who are newer to Git.
Since git-gui is (at least partially) intended to be used by newer
users who don't need the complexity of the index to be put in front
of them early on, we should hide it by making any partially included
file fully included as soon as we identify it. To do this we just
run a quick update_index pass on any file which differs both in the
index and the working directory, as these files have already been
at least partially included by the user.
A new option has been added in the options dialog (gui.partialinclude)
which lets the user enable accessing the index from git-gui. This
just disables the automatic update_index pass on partially included
files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
So although a text field with a flat relief looks like a label on
Windows it doesn't on Mac OS X. The Aqua version of Tk is still
drawing a border around the text field and that makes the diff pane
header look pretty ugly.
Earlier I had made the file name area into a text widget so the user
could highlight parts of it and copy them onto the clipboard; but with
the context menu being present this isn't quite as necessary as the user
can copy the file name to the clipboard using that instead. So although
this is a small loss in functionality for non-Mac OS X systems I think it
is still reasonable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Moved the Close button over to the lower right corner where our
Cancel/Save buttons are in the options dialog. This should fit
better with our own look and feel as well as that of most apps
on Mac OS X and Windows.
Also set the lower status bar in a console window to indicate the
process is working and that the user should wait for it to finish.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because the Tk pack layout manager gives all space to the right/bottom
most widget during expand/contract of the frame we were adding and
removing all space from the status area of the bar and not from the
file name, which is what we actually wanted.
A simple enough fix is to just put the status of the given file on
the left side of the diff viewer header rather than on the right.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When I changed from 'check in' to 'include' I missed the human friendly
status displayed in the right side of the diff viewer heading. It was
still reporting 'Checked in' for a fully included file, which is not
what we wanted it to say.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There's a lot of reasons why the user might need to obtain the
complete (or just part of) path of a file which they are currently
viewing in the diff viewer pane. So now we allow selection on this
widget by using a text widget instead of a label. We also offer a
context menu which has actions for copying the selection or the entire
value onto the clipboard.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we shove a large number of files at update-index and they have
very short path names we are likely going to fit a large number of
them into the pipe buffer very early; thereby seeing a huge progress
update followed by lots of waiting between progress updates due to
the latency of update-index.
Using a smaller buffer should help smooth out the progress updates
as we are better able to keep tabs on the update-index process'
progress through our list of paths.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its a little surprising to see the UI update the icons for files
in random order, due to the fact that the files are updating in
the order they appear within the array (which is based on a hash
function and not order). So sort the list of files before we send
any to update-index so the order of operation is means something to
the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When displaying a diff the Git default of 3 line of context may not be
enough for a user to see what has actually changed. Consequently we
set our own program default to 5 lines of context and then allow the
user to adjust this on a per-repository and global level through our
options dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'd like to allow the user to have more control over how we format
the diff in the diff viewer; to that end we need to add additional
options to the diff-index command line as we construct the command
for execution.
So cleanup the command handling code now to use lappend so we can
come back and add in our additional options.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We can't ask the diff viewer to recompute the diff until after our
update-index child process terminates, as the diff programs need to
be able to read the updated index in order to generate the correct
diff. This is actually why we prevent diffs from being generated
while there is an update lock on the index, which is why we ignored
our own show_diff invocation in the middle of the write_update_index
event handler.
So now we mark a flag if we identify that the file currently in the
diff viewer was also sent to update-index; then later when the
update-index process has terminated we update the diff viewer if
the flag is true.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is one of those stupid Tcl mistakes that an experienced Tcl
programmer just wouldn't make. We should always use eq and ne to
compare string values (and never == or !=) as when we use ==/!=
Tcl will attempt to convert either side to numeric if one of the
two sides looks like a numeric. This could cause some trouble if
a file named "1" exists and a different file named "1.0" also exists;
their paths are equal according to == but not according to eq.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since git-commit.sh invokes hooks/post-commit after running git rerere
we should do the same if its available and executable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We were originally trying to use $commit_active to tell us if there was
a commit currently in progress, just so we didn't attempt to start a
second (parallel) one by mistake. But really the index lock handles
this for us as it won't let us lock the index if it is already locked
for update. So this can't happen.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I started to notice on Windows that commits took a lot longer to get
going than on my Mac OS X system. The real reason is the repositories
that I'm testing with on Windows all enabled the standard pre-commit hook
while my test repository on Mac OS X doesn't have it executable (so its
not running). So the Windows repositories are spending this
lag time running that hook.
Now we run the pre-commit hook in the background, allowing the UI to
update and tell the user we are busy doing things.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because the pull diffstat summary can take as long as the pull itself
some users may just choose to disable the summary and save themselves
an extra few seconds during each pull. This is especially true if the
user really doesn't care about the other files being modified, as due
to their project organizational structure they aren't really responsible
for their content.
This adds an option to the options panel which lets the user disable
the diffstat summary (and thus we pass --no-summary to git-pull) but
there does appear to be a bug in the config saving code where we did
not set the local repo config differently from the global config.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since git-repo-config will supply us a union of both the global and
the local repository configuration data when we invoke it during startup
there is no reason to go get the global configuration with an extra call
to repo-config unless the user is trying to view & edit all options in
the options dialog.
Since skipping this extra repo-config invocation save us a little bit of
time its nice to be able to avoid it when we are invoked as git-citool
and won't be running very long.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user is invoking us as git-citool then they want to perform a
single commit and exit quickly. Since we are about to be a very short
lived process we should do what we can to avoid spending CPU time setting
up menus which the user will never use, like the fetch/push/pull menus.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently Tcl is being helpful on Windows during exec and is throwing a
\ in front of every { it finds in the string. I'm guessing they think
the value might be read by another Tcl program? Anyway, Git faithfully
stores the \{ sequence and sends it back that way to Tcl, at which point
Tcl parses the list wrong and starts to break it in the middle of any
element which contains spaces. Therefore a list such as:
-family {Times New Roman}
gets broken up into the pairs:
{-family \{Times}
{New Roman}
which is very incorrect. So now we replace all { and } with "", at which
point Tcl doesn't throw \ in front of the " on the way out to Git yet it
reads it correctly as a list on the way back in.
I also found and fixed a bug in the way we restored the fonts when the
user presses Restore Defaults in the options dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The tkwait visibility command and Windows doesn't seem to realize
the window is visible, consequently we are never finishing our
initialization by calling update_status.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since the font name can only be chosen from within the options dialog
giving the user fast access to this dialog from within a context menu
that already talks about increasing and decreasing the font size may
help users to locate the font name setting as well.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Display the name of "this" repository rather than the quite ambiguous
string "This". The idea is that seeing the name of the directory the
repository is stored in should help jog the user's memory about what
they are setting options for.
Also place the options dialog immediately over the git-gui main window
when it gets opened. This way the user isn't scrolling very far away
to gain access to the window. At least on my Mac OS X system not doing
this makes the options dialog open rather far away, thus requiring lots
of mouse activity to reach it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-update-index process can take a while to process a large
number of files; for example my laptop would probably need almost
an hour to chug through 20,000 modified files. In these incredibly
large cases the user should be given at least some feedback to let
them know the application is still working on their behalf, even if
it won't them do anything else (as the index is locked).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This turned out to take a lot more time than I thought it would take;
but now users can edit the main UI font and the diff/fixed with font
by changing both the family name and/or the point size of the text.
We save the complete Tk font specification to the user's ~/.gitconfig
file upon saving options. This is probably more verbose than it needs
to be as there are many useless options recorded (e.g. -overstrike 0)
that a user won't really want to use in this application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I decided that the options menu was going to turn into a mess after
a while as I start to add additional features to git-gui. The better
approach would be to create a dialog that lets the user edit the options,
including their --global options.
We also wisely let the user press Cancel (or destroy the window) to abort
any sort of option editing session, without the options being changed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Arrow is available on all Tk platforms and is mapped to the native
system cursor on Windows and Mac OS X. Consequently its the better
cursor choice as it should match whatever the system has configured
for the standard pointing thingy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently <Button-3> doesn't work on my single button PowerBook
mouse under Mac OS X. I'm guessing this is because Tk is stealing
every event and doesn't realize that Control-Button-1 is actually
supposed to invoke the context menu on this platform.
So now we have a utility procedure is_MacOSX to guess if we are
running on a Mac OS X system, and if so setup Control-Button-1 to
also activate what Button-3 should have. This does mean that I need
to stay away from using Control-Button-1 as a binding in any other
context. Of course we should use $M1B for that, which is M1 (aka
Command) on Mac OS X so that shouldn't prove to be a problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The native Tk font system is actually quite powerful and has the nice
property that modifications to a named font are immediately reflected
throughout all widgets currently displayed. This really saves us
from needing to write all of the reconfigure code as part of our font
display.
I also fixed the way we detect and apply the system font on the main
UI widgets as although it worked on a Windows 2000 system it does not
work at all on my Mac OS 10.4 system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the user has enabled the Trust File Modification Timestamp option
then we may display a file as being modified yet that file may not have
a difference. When the user clicks on that file we wind up displaying
an empty diff viewer, which makes no sense to the user.
So instead if we get an empty diff and the user has this option enabled
and the file's current state is _M (no change in index but the working
file appears modified) then run a quick update-index on just that file
and remove it from the list of modified files. We also give the user
a quick dialog stating we are removing it, and why.
Usually I don't run into this situation when I have the Trust File
Modification Timestamp option enabled, so its not that annoying to
have a dialog pop open to remind me why there are no differences.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because the diff area is one of the most important areas to be able to
read users should be able to increase or decrease the size of the font
used within that area.
Currently we save that back to the global configuration, even if it
may have originated from the local repository configuration. This
is probably going to be considered to be a bug by at least one user
who wants some sort of different font within a given repository, but
I'm just going to ignore the problem for now.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than hardcoding our fonts to something that I thought was
reasonable, guess font_ui off the font used by the system in the
menu bar. This way the application conforms by default to whatever
the user's desktop is setup to.
We also now let the user supply font configuration through their
repository configuration as gui.fontui (the overall UI font) and
gui.fontdiff (the font used for the diff viewer).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we sign off on a commit we want to add a blank line between
whatever is in the commit buffer and the new Signed-off-by line,
unless there already is a Signed-off-by (or Acked-by) tag at the end
of the buffer already. This change makes us do the right thing more
often.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The mouse cursor (at least on Windows) seemed to be picking up the
cursor from the sash controls and then never resetting itself back
to the standard text cursor (the I-beam) when it was over a text area
that the user can edit (like the commit buffer) or over a text area
the user can copy from (like the diff viewer).
So now we always set the cursor to left_ptr (which according to the Tk
documentation should be available everywhere) and only for the two text
areas which we use to list file names, as the user clicks in these but
is not permitted to select text.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This change adds a context menu to the commit message buffer providing
fast access to the contents of the Edit menu, and to the console text
buffer, providing easy ways to copy selections of the buffer or the
entire buffer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Make sure the file_lists array has both elements set at all times,
otherwise we get Tcl errors during mouse clicks in the file list
areas due to the list not being defined.
Also added M1-A as a keyboard binding within the console window
text area. This lets users select all text easily and copy it
to the clipboard.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A number of lines were line wrapping in a rather ugly way when opened
in vim with line numbers enabled, so I split most of these lines over
two lines using a sensible wrapping policy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The gui.geometry config value was starting to contain
the odd string \\{ as part of its value due to the
way the Tcl lists were being supplied to git repo-config.
Now we write out only three values: the overall window
geomtry, the y position of the horizontal sash, and
the x position of the vertical sash. All other data is
skipped, which makes the gui.geometry value simpler.
While debugging this I noticed that the save_my_config
procedure was being invoked multiple times during exit
due to do_quit getting invoked over and over again. So
now we set a flag in do_quit and don't perform any of our
"at exit" type of logic if we've already been through the
do_quit procedure once.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Added an extra blank line between the first line of each error message
and the rest of the message, as usually the rest of the message is
coming from Tcl or is the stderr output of a git command we tried to
invoke. This makes it easier to read the output (if any).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than drawing our own toplevel for error messages we really
should just use the the native tk_messageBox command to display
any error messages.
Major benefits for doing so are:
- automatically centers over main window;
- less code required on our part in git-gui;
- includes a nifty error icon on most systems;
- better fits the look-and-feel of the operating system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I found difffont to be a very awkward varible name, due to the use
of three f's in a row. So use easier to read variable names.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we reshow the current diff file it can be faster to just fetch
the value from the file_states array than it is to ask for all paths
whose name exactly matches the one we want to show. This is because
[array names -exact] is O(n) in the number of files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we commit we know that whatever was in the index went as part
of the commit. Since we generally assume that the user does not
update the index except through our user interface we can be reasonably
certain that any file which was marked as A/M/D in the index will have
had that A/M/D state changed to an _ (not different) by the commit.
We can use this knowledge to update the user interface post commit
by simply updating the index part of the file state of all files whose
index state was A/M/D to _ and then removing any file memory any which
wound up with a final state of __ (not different anywhere). Finally we
redraw the file lists and update the diff view.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are given a file whose path name contains an LF (\n) we now
escape it by inserting the common escape string \n instead of the
LF character whenever we display the name in the UI. This way the
text fields don't start to span multiple lines just to display one
file, and it keeps the line numbers correct within the file lists.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we did a rescan to update the file lists we lost the tag which
indicated which file was currently in the diff viewer. This occurs
because we delete every line from the two file list boxes (thus
removing the tag) and then redisplay the diff in the diff viewer
but then fail to restore the tag in the file list.
Now we restore that tag by searching for the file in the file lists
and adding the tag back when the diff viewer displays something.
We also no longer obtain the file path directly from the file list
text box. Instead we now keep two Tcl lists, one for each file list,
holding the file names in sorted order. These lists can be searched
with the native [lsearch -sorted] operation (which should be faster
than our crude bsearch) or can be quickly accessed by index to return
the file path. This should help make things safer should we ever be
given a file name which contains an LF within it (as that would span
two lines in the file list, not one).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we load a message file (e.g. MERGE_MSG) or we have just finished
making a commit and are clearing out the commit buffer we should also
clear out the undo/redo stack associated with that buffer. The prior
undo/redo stack has no associated with the new content and therefore
is not useful to the user.
Also modified the sign-off operation to perform the entire update in
a single undo/redo operation, allowing the user to undo the signoff
in case they didn't actually want to do that.
I also noticed what may be a crash on Windows related to the up and
down arrow keys navigating within the diff viewer. Since I got back
no stack trace (just an application exit with a loss of the commit
message) I suspect that the binding to scroll the text widget crashed
with an error and the wish process just terminated. So now we catch
(and ignore) any sort of error related to the arrow keys in the diff
viewer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users have come to expect basic editing features within their
applications, such as cut/copy/paste/undo/redo/select-all. I
found these features to be lacking in git-gui so now we have
them.
I also added basic keyboard bindings for the diff viewing area
so that the arrow keys move around single units (lines or columns)
and the M1-X/C keys will copy the selected text and the M1-A key
will select the entire diff.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we call the update-index all files action "Include All" it
makes more sense to make this M1-I (so Control-I or Command-I depending
on platform) than M1-U, which stood for update but is somewhat confusing
to users.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
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>
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>
A user shouldn't perform a commit if any of the following are true:
* The repository state has changed since the last rescan.
* There are no files updated in the index to commit.
* There are unmerged stages still in the index.
* The commit message has not been provided.
* The pre-commit hook is executable and declined.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are refreshing from the index or updating the index we shouldn't
let the user cause other index based operations to occur as these would
likely conflict with the currently running operations possibly causing
some index changes to be lost.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* Run refresh before diff-index.
* Load saved commit message during rescan.
* Save current commit message (if any) during quit.
* Add Signed-off-by line to commit buffer.
* Batch update-index invocations through --stdin.
* Better highlight which file is in the diff viewer.
* Key bindings for signoff, check-in all and commit.
* Improved formatting of status table within source.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is based on Paul Mackerras' gitool prototype which he offered up
to the community earlier in 2006. Its mostly however a rewrite from
scratch of a Tcl/Tk based graphical interface for Git and the most
common commands users might need to perform.
Currently it can display the status of the current repository, and not
much else.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2006-11-06 14:20:27 -05:00
374 changed files with 27215 additions and 6065 deletions
@ -34,6 +34,15 @@ The output from this command is designed to be used as a commit
template comments, and all the output lines are prefixed with '#'.
CONFIGURATION
-------------
The command honors `color.status` (or `status.color` -- they
mean the same thing and the latter is kept for backward
compatibility) and `color.status.<slot>` configuration variables
to colorize its output.
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
