The example provided with the update-hook-example does not work on
either bash 2.05b.0(1)-release nor 3.1.17(1)-release. The matcher did
not match the lines that it advertised to match, such as:
refs/heads/bw/ linus
refs/heads/tmp/* *
In POSIX 1003.2 regular expressions, the star (*), is not an wildcard
meaning "match everything", it matches 0 or more matches of the atom
preceding it.
So to match "refs/heads/bw/topic-branch", the matcher should be written
as "refs/heads/bw/.*" to match "refs/heads/bw/" and everything after it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This section has not been updated in a while and
--branches/--tags/--trunk options are commonly used nowadays.
Noticed-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier commit ece7b74903 added a test
for rebase that uses "am -3", but this adds a test to check "am -3"
itself.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 098e711e caused git-push to match only branches when
considering which refs to push. This patch updates the
documentation accordingly and adds a test for this behavior.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some people seem to create SVN branch names with spaces
or other shell metacharacters.
Signed-off-by: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because a partial commit is meant to be a way to ignore what are
staged in the index, "git rm --cached A && git commit A" should
just record what is in A on the filesystem. The previous patch
made the command sequence to barf, saying that A has not been
added yet. This fixes it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When making a partial commit, git-commit uses git-ls-files with
the --error-unmatch option to expand and sanity check the user
supplied path patterns. When any path pattern does not match
with the paths known to the index, it errors out, in order to
catch a common mistake to say "git commit Makefiel cache.h"
and end up with a commit that touches only cache.h (notice the
misspelled "Makefile"). This detection however does not work
well when the path has already been removed from the index.
If you drop a path from the index and try to commit that
partially, i.e.
$ git rm COPYING
$ git commit -m 'Remove COPYING' COPYING
the command complains because git does not know anything about
COPYING anymore.
This introduces a new option --with-tree to git-ls-files and
uses it in git-commit when we build a temporary index to
write a tree object for the partial commit.
When --with-tree=<tree-ish> option is specified, names from the
given tree are added to the set of names the index knows about,
so we can treat COPYING file in the example as known.
Of course, there is no reason to use "git rm" and git-aware
people have long time done:
$ rm COPYING
$ git commit -m 'Remove COPYING' COPYING
which works just fine. But this caused a constant confusion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Disable native platform text selection in "lists"
git-gui: Paper bag fix "Commit->Revert" format arguments
git-gui: Provide 'uninstall' Makefile target to undo an installation
git-gui: Font chooser to handle a large number of font families
git-gui: Make backporting changes from i18n version easier
git-gui: Don't delete send on Windows as it doesn't exist
git-gui: Trim trailing slashes from untracked submodule names
git-gui: Assume untracked directories are Git submodules
git-gui: handle "deleted symlink" diff marker
git-gui: show unstaged symlinks in diff viewer
git-gui: Avoid use of libdir in Makefile
git-gui: Disable Tk send in all git-gui sessions
git-gui: lib/index.tcl: handle files with % in the filename properly
git-gui: Properly set the state of "Stage/Unstage Hunk" action
git-gui: Fix detaching current branch during checkout
git-gui: Correct starting of git-remote to handle -w option
Earlier code took Unix time and appended a few random digits.
If you are firing off many messages within a second, you could
issue the same id to different messages, which is a no-no. If
you send out 31 messages within a single second, with random
integer taken out of rand(4200), you have about 10% chance of
producing the same message ID.
This fixes the problem by uses a prefix string which is
constant-per-invocation (time and pid), with a serial number for
each message generated by the process appended at the end.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The algorithm isn't right here: it accumulates any set of 8 spaces into
tabs even if they're separated by tabs, so
<four spaces><tab><four spaces><tab>
is converted to
<tab><tab><tab>
when it should be just
<tab><tab>
So teach git-apply that a tab hides any group of less than 8 previous
spaces in a row.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes we use a Tk text widget as though it were a listbox.
This happens typically when we want to show an icon to the left
of the text label or just when a text widget is generally a better
choice then the native listbox widget.
In these cases if we want the user to have control over the selection
we implement our own "in_sel" tag that shows the selected region
and we perform our own selection management in the background
via keybindings and mouse bindings. In such uses we don't want
the user to be able to activate the native platform selection by
dragging their mouse through the text widget. Doing so creates a
very confusing display and the user is left wondering what it may
mean to have two different types of selection in the same widget.
Tk doesn't allow us to delete the "sel" tag that it uses internally
to manage the native selection but it will allow us to make it
invisible by setting the tag to have the same display properties
as unselected text. So long as we don't actually use the "sel"
tag for anything in code its effectively invisible.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"git diff" does not record index lines for pure mode changes (i.e. no
lines changed). Therefore, apply --index-info would call out a bogus
error.
Instead, fall back to reading the info from the current index.
Incidentally, this fixes an error where git-rebase would not rebase a
commit including a pure mode change, and changes requiring a threeway
merge.
Noticed and later tested by Chris Shoemaker.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'maint' of git://linux-nfs.org/~bfields/git:
core-tutorial: minor cleanup
documentation: replace Discussion section by link to user-manual chapter
user-manual: todo updates and cleanup
user-manual: fix introduction to packfiles
user-manual: move packfile and dangling object discussion
user-manual: rewrite object database discussion
user-manual: reorder commit, blob, tree discussion
user-manual: rewrite index discussion
user-manual: create new "low-level git operations" chapter
user-manual: rename "git internals" to "git concepts"
user-manual: move object format details to hacking-git chapter
user-manual: adjust section levels in "git internals"
Revise the introduction for concision, add pointers to the tutorial and
user manual as appropriate, delete cvsimport note from the end, as that
work's been done elsewhere already.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The "Discussion" section has a lot of useful information, but is a
little wordy, especially for an already-long man page, and is designed
for an audience more of potential git hackers than users, which probably
doesn't make as much sense as git matures. Also, I (perhaps foolishly)
forked a version in the user manual, which has been significantly
rewritten in an attempt to address some of the above problems.
So, remove this section and replace it by a (very terse) summary of the
original material--my attempt at the World's Shortest Git Overview--and
a reference to the appropriate chapter of the user manual. It's
unfortunate to remove something that's been in this place for a long
time, as some people may still depend on finding it there. But I think
we'll want to do this some day anyway.
Cc: Andreas Ericsson <ae@op5.se>
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Actually I don't think we've previously mentioned .git/objects, so we
need a different introduction here.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Rewrite the introduction. Rewrite each section completely to make them
work in the new order, to add some examples, and to move plumbing
commands (like git-commit-tree) to the following chapter.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The bottom-up blog, tree, commit order makes sense unless you want to
give explicit examples--it's easier to discover objects to examine if
you go in the other order....,
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Add an example using git-ls-files, standardize on the new "index"
terminology (as opposed to "cache"), attempt to clarify discussion and
make it a little shorter, avoid some unnecessary jargon ("write-back
cache").
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The low-level index operations aren't as important to regular users as
the rest of this "git concepts" chapter; so move it into a separate
chapter, and do some minor cleanup.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
"git internals" sounds like something only git developers must know
about, but this stuff should be of wider interest. Rename the chapter
and give it a slightly friendlier introduction.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The descriptions of the various object types should all be a subsection
of the "Object Database" section.
I cribbed most of this chapter from the README (now core-intro.txt and
git(7)), because there's stuff in there people need to know and I was
too lazy to rewrite it. The audience isn't quite right, though--the
chapter is a mixture of user- and developer- level documentation that
isn't as appropriate now as it was originally.
So, reserve this chapter for stuff users need to know, and move the
source code introduction into a new "git hacking" chapter where we'll
also move any hacker-only technical details.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
We used to rely on the fact that cherry-pick would trigger the code path
to set limited = 1 in handle_commit(), when an uninteresting commit was
encountered.
However, when cherry picking between two independent branches, i.e. when
there are no merge bases, and there is only linear development (which can
happen when you cvsimport a fork of a project), no uninteresting commit
will be encountered.
So set limited = 1 when --cherry-pick was asked for.
Noticed by Martin Bähr.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In order to (almost) always show the name of the file without
relying on "-H" option of GNU grep, we used to add /dev/null to
the argument list unless we are doing -l or -L. This caused
"/dev/null:0" to show up when -c is given in the output.
It is not enough to add -c to the set of options we do not pass
/dev/null for. When we have too many files, we invoke grep
multiple times and we need to avoid giving a widow filename to
the last invocation -- otherwise we will not see the name.
This keeps two filenames when the argv[] buffer is about to
overflow and we have not finished iterating over the index, so
that the last round will always have at least two paths to work
with (and not require /dev/null).
An obvious and the only exception is when there is only 1 file
that is given to the underlying grep, and in that case we avoid
passing /dev/null and let the external "grep -c" report only the
number of matches.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bram Schoenmakers noticed that git-config document was formatted
incorrectly. Depending on the version of AsciiDoc and docbook
toolchain, it is sometimes taken as a numbered example by AsciiDoc,
some other times passed intact to roff format to confuse "man".
Since we refer to the repository metadata directory as $GIT_DIR
elsewhere, work it around by using that symbolic name.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit fixed type-change case in "git add -u".
This adds a test to make sure we do not introduce regression.
At the same time, it fixes a stupid typo in the error message.
Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The description of the option gave impression that there
were several formats available by using three dots. There are
no other formats than tar and gzip currently supported.
Clarify that the archive goes to the standard output.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds more proper rename detection limits. Instead of just checking
the limit against the number of potential rename destinations, we verify
that the rename matrix (which is what really matters) doesn't grow
ridiculously large, and we also make sure that we don't overflow when
doing the matrix size calculation.
This also changes the default limits from unlimited, to a rename matrix
that is limited to 100 entries on a side. You can raise it with the config
entry, or by using the "-l<n>" command line flag, but at least the default
is now a sane number that avoids spending lots of time (and memory) in
situations that likely don't merit it.
The choice of default value is of course very debatable. Limiting the
rename matrix to a 100x100 size will mean that even if you have just one
obvious rename, but you also create (or delete) 10,000 files, the rename
matrix will be so big that we disable the heuristics. Sounds reasonable to
me, but let's see if people hit this (and, perhaps more importantly,
actually *care*) in real life.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This will allow RFC-literate users to say:
format-patch --in-reply-to='<message.id@site.name>'
without forcing them to strip the surrounding angle brackets
like this:
format-patch --in-reply-to='message.id@site.name'
We accept both forms, and the latter gets necessary < and >
around it as before.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A duplicate of an already existing section in the documentation of
git-filter-branch was added in commit
f95eef15f2.
This patch removes that redundant section.
Signed-off-by: Ulrik Sverdrup <ulrik.sverdrup@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the curl program is not available (or not executable), and git clone is
started to clone a repository through http, this is the output
Initialized empty Git repository in /tmp/puppet/.git/
/usr/bin/git-clone: line 37: curl: command not found
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?
This patch improves the error message by checking the return code when
running curl to exit immediately if it's 126 or 127; the error output now
is
Initialized empty Git repository in /tmp/puppet/.git/
/usr/bin/git-clone: line 37: curl: command not found
Adrian Bridgett noticed this and reported through
http://bugs.debian.org/440976
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous check caused the hook to reject as unannotated any tag
whose SHA1 starts with a zero.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The recent bug fix to correctly handle filenames with %s (or any
other valid Tcl format specifier) missed a \ on this line and
caused the remaining format arguments to not be supplied when we
updated the status bar. This caused a Tcl error anytime the user
was trying to perform a file revert.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Several users have requested a "make uninstall" target be provided
in the stock git-gui Makefile so that they can undo an install
if git-gui goes to the wrong place during the initial install,
or if they are unhappy with the tool and want to remove it from
their system.
We currently assume that the complete set of files we need to delete
are those defined by our Makefile and current source directory.
This could differ from what the user actually has installed if they
installed one version then attempt to use another to perform the
uninstall. Right now I'm just going to say that is "pilot error".
Users should uninstall git-gui using the same version of source
that they used to make the installation. Perhaps in the future we
could read tclIndex and base our uninstall decisions on its contents.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Simon Sasburg noticed that on X11 if there are more fonts than can
fit in the height of the screen Tk's native tk_optionMenu does not
offer scroll arrows to the user and it is not possible to review
all choices or to select those that are off-screen. On Mac OS X
the tk_optionMenu works properly but is awkward to navigate if the
list is long.
This is a rewrite of our font selection by providing a new modal
dialog that the user can launch from the git-gui Options panel.
The dialog offers the user a scrolling list of fonts in a pane.
An example text shows the user what the font looks like at the size
they have selected. But I have to admit the example pane is less
than ideal. For example in the case of our diff font we really
should show the user an example diff complete with our native diff
syntax coloring.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Acked-by: Simon Sasburg <simon.sasburg@gmail.com>
This is a very trivial hack to define a global mc procedure that
does not actually perform i18n translations on its input strings.
By declaring an mc procedure here in our maint version of git-gui
we can take patches that are intended for the latest development
version of git-gui and easily backport them without needing to
tweak the mc calls first.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There was no newline at the end of the index commit message, putting
the shell prompt at its end after a 'git cat-file commit $id'. This is
similar to what was fixed in 843103d693.
Signed-off-by: Jean-Luc Herren <jlh@gmx.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Right now one can amend the last non-merge commit using a dirty index
and in the process maybe cause the last commit to have the same tree
as its parent. In such a case one would want to discard the last commit
instead of amending it.
This reverts commit 8588452ceb.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although message-id by defintion should have surrounding angle
brackets, there is no point forcing people to type them in.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On filesystems where it is appropriate to set core.filemode
to false, test 29 ("commitdiff(0): mode change") fails when
git-commit does not notice a file (execute) permission change.
A fix requires noting the new file execute permission in the
index with a "git update-index --chmod=+x", prior to the commit.
Add a function (note_chmod) which implements this idea, and
insert a call in each test that modifies the x permission.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The Windows port of Tk does not have the send command so we
cannot delete it from our global namespace, but the Mac OS
X and X11 ports do have it. Switching this delete attempt
into a catch makes send go away, or stay away.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
1) pushes happen less often than fetches, so the bandwidth saving is
much less visible in that case overall.
2) thin packs have to be complemented with missing delta bases to be
valid, so many received thin packs will take more disk space.
3) the bother of repacking should be distributed amongst "clients"
i.e. fetchers and pushers as much as possible, and not the server
being fetched or pushed, to keep disk and CPU usage low on the
server.
This is why a fetch should get thin packs but a push should not.
Both Nico and I have been assuming that --no-thin was the default
behavior of git-push ever since Nico introduced --fix-thin into the
index-pack process, which allowed fetch and receive-pack to avoid
exploding packfiles received during transfer. This patch finally
makes it so.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove obsolete details (core.legacyheaders is always true now).
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Most of this patch code and message was written by Shawn O. Pearce.
I made some tests to know what the problem was, and then I changed
the code related with the SIGPIPE signal.
If the user has misconfigured `user.signingkey` in their .git/config
or just doesn't have any secret keys on their keyring and they ask
for a signed tag with `git tag -s` we better make sure the resulting
tag was actually signed by gpg.
Prior versions of builtin git-tag allowed this failure to slip
by without error as they were not checking the return value of
the finish_command() so they did not notice when gpg exited with
an error exit status. They also did not fail if gpg produced an
empty output or if read_in_full received an error from the read
system call while trying to read the pipe back from gpg.
Finally, we did not actually honor any return value from the do_sign
function as it returns ssize_t but was being stored into an unsigned
long. This caused the compiler to optimize out the die condition,
allowing git-tag to continue along and create the tag object.
However, when gpg gets a wrong username, it exits before any read was done
and then the writing process receives SIGPIPE and program is terminated.
By ignoring this signal, anyway, the function write_or_die gets EPIPE from
write_in_full and exits returning 0 to the system without a message.
Here we better call to write_in_full directly so we can fail
printing a message and return safely to the caller.
With these issues fixed `git-tag -s` will now fail to create the
tag and will report a non-zero exit status to its caller, thereby
allowing automated helper scripts to detect (and recover from)
failure if gpg is not working properly.
Proposed-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Oddly enough `git ls-files --others` supplies us the name of an
untracked submodule by including the trailing slash but that
same git version will not accept the name with a trailing slash
through `git update-index --stdin`. Stripping off that final
slash character before loading it into our file lists allows
git-gui to stage changes to submodules just like any other file.
This change should give git-gui users some basic submodule support,
but it is strictly at the plumbing level as we do not actually know
about calling the git-submodule porcelain that is a recent addition
to git 1.5.3.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If `git ls-files --others` returned us the name of a directory then
it is because Git has decided that this directory itself contains a
valid Git repository and its files shouldn't be listed as untracked
for this repository.
In such a case we should label the object as a Git repository and
not just as a directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui has a minor problem with regards to symlinks that point
to directories.
git init
mkdir realdir
ln -s realdir linkdir
git gui
Now clicking on file names in the "unstaged changes" window,
there's a problem coming from the "linkdir" symlink: git-gui
complains with
error reading "file4": illegal operation on a directory
...even though git-gui can add that same symlink to the index just
fine.
This patch fix this by adding a check.
[sp: Minor fix to use {link} instead of "link" in condition
and to only open the path if it is not a symlink.]
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Use the rev-list --parents functionality to read the parents
of the commit. cat-file only shows the raw object with the
original parents and doesn't take into account grafts; so
we'll rely on rev-list machinery for the smarts here.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to squelch empty diffs introduced by commit
fb13227e08 would inadvertently
populate filespec "two" of a submodule change using the uninitialized
(null) SHA1, thereby replacing the submodule SHA1 by 0{40} in the output.
This change teaches diffcore_skip_stat_unmatch to handle
submodule changes correctly.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Dmitry V. Levin pointed out that on GNU linux libdir is often used
in Makefiles to mean "/usr/lib" or "/usr/lib64", a directory that
is meant to hold platform-specific binary files. Using a different
libdir meaning here in git-gui's Makefile breaks idomatic expressions
like rpm specifile "make libdir=%_libdir".
Originally I asked that the git.git Makefile undefine libdir before
it calls git-gui's own Makefile but it turns out this is very hard
to do, if not impossible. Renaming our libdir to gg_libdir resolves
this case with a minimum amount of fuss on our part.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tk designers blessed us with the "send" command, which on X11
will allow anyone who can connect to your X server to evaluate any
Tcl code they desire within any running Tk process. This is just
plain nuts. If git-gui wants someone running Tcl code within it
then would ask someone to supply that Tcl code to it; waiting for
someone to drop any random Tcl code into us is not fantastic idea.
By renaming send to the empty name the procedure will be removed
from the global namespace and Tk will stop responding to random Tcl
evaluation requests sent through the X server. Since there is no
facility to filter these requests it is unlikely that we will ever
consider enabling this command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Steps to reproduce the bug:
$ mkdir repo && cd repo && git init
Initialized empty Git repository in .git/
$ touch 'foo%3Fsuite'
$ git-gui
Then click on the 'foo%3Fsuite' icon to include it in a changeset, a
popup comes with:
'Error: bad field specifier "F"'
Vincent Danjean noticed the problem and also suggested the fix, reported
through
http://bugs.debian.org/441167
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We have a workaround for the reparent function not working
correctly on the SVN native protocol servers. This workaround
opens a new connection (SVN::Ra object) to the new
URL/directory.
Since libsvn appears limited to only supporting one connection
at a time, this workaround invalidates the Git::SVN::Ra object
that is $self inside gs_fetch_loop_common(). So we need to
restart that connection once all the fetching is done for each
loop iteration to be able to run get_log() successfully.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the tag was moved in CVS or SVN history, it will be moved in the
imported history as well. Tag history is not tracked.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we're counting, a smaller number is 'fewer' not 'less'
Signed-off-by: Mike Ralphson <mike@abacus.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many users get confused when `git push origin master:foo` works
when foo already exists on the remote repository but are confused
when foo doesn't exist as a branch and this form does not create
the branch foo.
This new example highlights the trick of including refs/heads/
in front of the desired branch name to create a branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Kristian Høgsberg pointed out that the two file modifications
we were doing during the 'creating initial files' step are not even
used within the test suite. This was actually confusing as we do
not even need these changes for the tests to pass. All that really
matters here is the specific commit dates are used so that these
appear in the branch's reflog, and that the dates are different so
that the branch will update when asked and the reflog entry is
also updated. There is no need for the file modification.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recently I found that doing a sequence like the following:
git-new-workdir a b
...
git-new-workdir a b
by accident will cause a (and now also b) to have an infinite cycle
in its refs directory. This is caused by git-new-workdir trying
to create the "refs" symlink over again, only during the second
time it is being created within a's refs directory and is now also
pointing back at a's refs.
This causes confusion in git as suddenly branches are named things
like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the
more commonly accepted "refs/heads/foo". Plenty of commands start
to see ambiguous ref names and others just take ages to compute.
git-clone has the same safety check, so git-new-workdir should
behave just like it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the preimage we are patching is shorter than what the patch
text expects, we tried to match the buffer contents at the
"original" line with the fragment in full, without checking we
have enough data to match in the preimage. This caused the size
of a later memmove() to wrap around and attempt to scribble
almost the entire address space. Not good.
The code that follows the part this patch touches tries to match
the fragment with line offsets. Curiously, that code does not
have the problem --- it guards against reading past the end of
the preimage.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Today I found yet another way for the "Stage Hunk" and "Unstage
Hunk" context menu actions to leave the wrong state enabled in
the UI. The problem this time was that I connected the state
determination to the value of $::current_diff_side (the side the
diff is from). When the user was last looking at a diff from the
index side and unstages everything the diff panel goes empty, but
the action stayed enabled as we always assumed unstaging was a
valid action.
This change moves the logic for determining when the action is
enabled away from the individual side selection, as they really
are two unrelated concepts.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user tried to detach their HEAD while keeping the working
directory on the same commit we actually did not completely do
a detach operation internally. The problem was caused by git-gui
not forcing the HEAD symbolic ref to be updated to a SHA-1 hash
when we were not switching revisions. Now we update the HEAD ref
if we aren't currently detached or the hashes don't match.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Current versions of git-remote apparently are passing the -w option
to Perl as part of the shbang line:
#!/usr/bin/perl -w
this caused a problem in git-gui and gave the user a Tcl error with
the message: "git-remote not supported: #!/usr/bin/perl -w".
The fix for this is to treat the shbang line as a Tcl list and look
at the first element only for guessing the executable name. Once
we know the executable name we use the remaining elements (if any
exist) as arguments to the executable, before the script filename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
HPA noticed that yum does not like the newer git RPM set; it turns out
that we do not ship git-p4 anymore but existing installations do not
realize the package is gone if we do not tell anything about it.
David Kastrup suggests using Obsoletes in the spec file of the new
RPM to replace the old package, so here is a try.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allow port specification in ssh:// URLs in the
usual notation:
ssh://[user@]host.domain[:<port>]/<path>
This allows git to be used over ssh-tunneling
networks.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a topic branch is rebased, some of whose commits are already
cherry-picked upstream:
o--X--A--B--Y <- master
\
A--B--Z <- topic
then 'git rebase -m master' would report:
Already applied: 0001 Y
Already applied: 0002 Y
With this fix it reports the expected:
Already applied: 0001 A
Already applied: 0002 B
As an added bonus, this change also avoids 'echo' of a commit message,
which might contain escapements.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The warning message to suggest "Consider running git-status" from
"git-diff" that we experimented with during the 1.5.3 cycle turns
out to be a bad idea. It robbed cache-dirty information from people
who valued it, while still asking users to run "update-index --refresh".
It was hoped that the new behaviour would at least have some educational
value, but not showing the cache-dirty paths like before meant that the
user would not even know easily which paths were cache-dirty, and it
made the need to refresh the index look like even more unnecessary chore.
This commit reinstates the traditional behaviour, but with a twist.
By default, the empty "diff --git" output is totally squelched out
from "git diff" output. At the end of the command, it automatically
runs "update-index --refresh" as needed, without even bothering the
user. In other words, people who do not care about the cache-dirtyness
do not even have to see the warning.
The traditional behaviour to see the stat-dirty output and to bypassing
the overhead of content comparison can be specified by setting the
configuration variable diff.autorefreshindex to false.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch removes certain behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring. The same
thing now could be achieved doing "git tag -l '*foo*'".
This feature was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.
Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substring*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.
Tests for "git tag" were also changed to reflect this.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although dcommit could detect if the first commit in the series
would conflict with the HEAD revision in SVN, it could not
detect conflicts in further commits it made.
Now we rebase each uncommitted change after each revision is
committed to SVN to ensure that we are up-to-date. git-rebase
will bail out on conflict errors if our next change cannot be
applied and committed to SVN cleanly, preventing accidental
clobbering of changes on the SVN-side.
--no-rebase users will have trouble with this, and are thus
warned if they are committing more than one commit. Fixing this
for (hopefully uncommon) --no-rebase users would be more complex
and will probably happen at a later date.
Thanks to David Watson for finding this and the original test.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the configuration of the user has "diff.color = true", the
output from "log" we invoke internally added color codes, which
broke the parser.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Eric Wong <normalperson@yhbt.net>
With this function, a commit filter can leave out unwanted commits
(such as temporary commits). It does _not_ undo the changeset
corresponding to that commit, but it _skips_ the revision. IOW
no tree object is changed by this.
If you like to commit early and often, but want to filter out all
intermediate commits, marked by "@@@" in the commit message, you can
now do this with
git filter-branch --commit-filter '
if git cat-file commit $GIT_COMMIT | grep '@@@' > /dev/null;
then
skip_commit "$@";
else
git commit-tree "$@";
fi' newbranch
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move the convenience functions to the top of git-filter-branch.sh, and
return from the script when the environment variable SOURCE_FUNCTIONS is
set.
By sourcing git-filter-branch with that variable set automatically, all
commit filters may access the convenience functions like "map".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The interactive mode of rebase can be used to split commits. Tell the
interested parties about it, with a dedicated section in the man page.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some time ago, filter-branch's syntax changed so that more than one
ref can be rewritten at the same time. This involved the removal of
the ref name for the result; instead, the refs are rewritten in-place.
This updates the last leftovers in the documentation to reflect the
new behavior.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lately I have been doing a lot of calls to `git tag -d` and also to
`git tag -v`. In both such cases being able to complete the names
of existing tags saves the fingers some typing effort. We now look
for the -d or -v option to git-tag in the bash completion support
and offer up existing tag names as possible choices for these.
When creating a new tag we now also offer bash completion support
for the second argument to git-tag (the object to be tagged) as this
can often be a specific existing branch name and is not necessarily
the current HEAD.
If the -f option is being used to recreate an existing tag we now
also offer completion support on the existing tag names for the
first argument of git-tag, helping to the user to reselect the
prior tag name that they are trying to replace.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"git log" family of commands, even when run from a subdirectory,
do not limit the revision range with the current directory as
the path limiter, but with double-dash without any paths after
it, i.e. "git log --" do so. It was a mistake to have a
difference between "git log --" and "git log" introduced in
commit ae563542bf (First cut at
libifying revlist generation).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already autodetect if filemode is reliable on the filesystem
to deal with VFAT and friends. Do the same for symbolic link
support.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When appending the "git-archimport-id:" line to the end of log entries,
git-archimport would use two blank lines as a separator when there was no
body in the arch log (only a Summary: line), and zero blank lines when there
was a body (making it hard to see the break between the actual log message
and the git-archimport-id: line).
This patch makes git-archimport generate one blank line as a separator in all
cases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code favoring shallower deltas when size is equal was triggered
only when previous delta was also cached. There should be no relation
between cached deltas and same sized deltas.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Later in a loop any existing ref whose path begins with it is
removed. It would be a disaster if you allowed it to say refs/head
for example.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Comments in both these strategies refer to the wrong number
of remotes
Signed-off-by: Tom Clarke <tom@u2i.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is most visible when you do "git commit Makefile Makefile"; it
may be a stupid request, but that is not a reason to fail the command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both --left-right and --cherry-pick are particularly long to type, so
help the user there.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "Show nearby tags" is turned off and the user did a cherry-pick,
we were trying to access variables relating to the descendent/ancestor
tag & head computations in addnewchild though they hadn't been set.
This makes sure we don't do that. Reported by Johannes Sixt.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Jari Aalto noticed a handful places in git-daemon documentation
that need to be improved.
* --inetd makes --pid-file to be ignored, in addition to --user
and --group
* receive-pack service was not described at all. We should, if
only to warn about the security implications of it.
* There was no example of per repository configuration.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As pointed out by Linus, these notations require the endpoints
given by the end user to be commits. Clarify.
Also, three-dots in AsciiDoc are turned into ellipses unless
quoted with bq. Be careful.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I think the trick with Git-side filename globbing is important and perhaps
not that well known. Clarify a bit in git-add documentation what it means.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently the error message seems to imply (at least to me) that only
the listed files were withheld and the rest of the files was added to the
index, even though that's obviously not the case.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'summary' views
This for example allows to put email address in the project owner
field in the projects index file (when $projects_list points to
a file, and not to a directory), in the form of:
path/to/repo.git Random+J+Developer+<random@developer.example.org>
Noticed-by: Jon Smirl <jonsmirl@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to trigger the special case "things not in origin"
semantics only when one and only one positive ref is given, and
no number (e.g. "git format-patch -4 origin") was specified, and
used the general revision range semantics for everything else.
This narrows the special case a bit more, by making:
git format-patch --root this_version
to show everything that leads to the named commit.
More importantly, document the two different semantics better.
The generic revision range semantics came later and bolted on
without being clearly documented.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This clarifies the logic to omit fast-forward check and omit
trivial merge before running the specified strategy.
The "index_merge" variable started out as a flag to say "do not
do anything clever", but when recursive was changed to skip the
trivial merge, the semantics were changed and the variable alone
does not make sense anymore.
This splits the variable into two, allow_fast_forward (which is
almost always true, and avoids making a merge commit when the
other commit is a descendant of our branch, but is set to false
for ours and subtree) and allow_trivial_merge (which is false
for ours, recursive and subtree).
Unlike the earlier implementation, the "ours" strategy allows an
up-to-date condition. When we are up-to-date, the result will
be our commit, and by definition, we will have our tree as the
result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"GIT_DIR=some.where git --bare cmd" and worse yet
"git --git-dir=some.where --bare cmd" were very confusing. They
both ignored git-dir specified, and instead made $cwd as GIT_DIR.
This changes --bare not to override existing GIT_DIR.
This has been like this for a long time. Let's hope nobody sane
relied on this insane behaviour.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Here is my attempt to fix this with a minimally intrusive patch.
* As "git --bare init" cannot tell if it was called with --bare or
just "GIT_DIR=. git init", I added an explicit assignment of
is_bare_repository_cfg on the codepath for "git --bare".
* GIT_WORK_TREE alone without GIT_DIR does not make any sense,
nor GIT_WORK_TREE with an explicit "git --bare". Catch that
mistake. It might make sense to move this check to "git.c"
side as well, but I tried to shoot for the minimum change for
now.
* Some scripts, especially from the olden days, rely on
traditional GIT_DIR behaviour in "git init". Namely, these
are some notable patterns:
(create a bare repository)
- mkdir some.git && cd some.git && GIT_DIR=. git init
- mkdir some.git && cd some.git && git --bare init
(create a non-bare repository)
- mkdir .git && GIT_DIR=.git git init
- mkdir .git && GIT_DIR=`pwd`/.git git init
This comes with a new test script and also passes the existing
test suite, but there may be cases that are still broken with
the current tip of master and this patch does not yet fix. I'd
appreciate help in straightening this mess out.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Uwe Kleine-König noticed that under certain circumstances, name-rev
picked a non-optimal tag. Jeff King analyzed that name-rev only
takes into account the number of merge traversals, and then the
_last_ number in the description.
As an easy way to fix it, use a weighting factor for merge traversals:
A merge traversal is now made 65535 times more expensive than a
first-parent traversal.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Options -d, -l, -v have already been explained in OPTIONS below.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Everything is already fully quoted along the way so I believe this to be
unnecessary at this point. It would pose trouble for regexp searches.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Correct 'git gui blame' in a subdirectory
git-gui: Do not offer to stage three-way diff hunks into the index
git-gui: Refactor diff pane popup support for future improvements
git-gui: Fix "unoptimized loading" to not cause git-gui to crash
git-gui: Paper bag fix "Stage Hunk For Commit" in diff context menu
git-gui: Allow git-merge to use branch names in conflict markers
git-gui: Fix window manager problems on ion3
Instead of disabling color all of the time during a git-commit, allow
the user's config preference in the situation where there is nothing
to commit. In this situation, the status is printed to the terminal
and not sent to COMMIT_EDITMSG, so honoring the status color setting
is expected.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, searchbox is CSS'd to have position: absolute, which has the
unfortunate consequence that if the viewport is too small and can't fit
into the page width together with the navbar, it gets overlapped and part
of the navbar gets obscured. This makes searchbox float: right instead,
thus the navbar simply gets wrapped.
Discovered and fix pointed out by Michael Olson <mwolson@gnu.org>.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://linux-nfs.org/~bfields/git:
Documentation/user-manual.txt: fix a few omissions of gitlink commands.
user-manual: fix incorrect header level
user-manual: use pithier example commit
user-manual: introduce the word "commit" earlier
user-manual: minor editing for conciseness
user-manual: edit "ignoring files" for conciseness
Documentation/user-manual.txt: fix a few omissions of gitlink commands.
Actually, we should have a competition for the favorite example commit.
Criteria:
- length: one-line changes with one-line comments preferred,
and no long lines
- significance/memorability
- comic value
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The immediate motivation for writing this section was to explain the
various places ignore patterns could be used. However, I still think
.gitignore is the case most people will want to learn about first. It
also makes it a bit more concrete to introduce ignore patterns in the
context of .gitignore first. And the existance of gitignore(5) relieves
the pressure to explain it all here.
So, stick to the .gitignore example, with only a brief mention of the
others, explain the syntax only by example, and leave the rest to
gitignore(5).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Cc: Johan Herland <johan@herland.net>
The usage string for the executable was missing --refresh. In
addition, the documentation referred to "file", but the usage string
referred to "filepattern". Updated the documentation to
"filepattern", as git-add does handle patterns.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The usage information in git-am.sh now matches that of the
documentation.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Under some types of packfile corruption the zlib stream holding the
data for a delta within a packfile may fail to inflate, due to say
a CRC failure within the compressed data itself. When this occurs
the unpack_compressed_entry function will return NULL as a signal to
the caller that the data is not available. Unfortunately we then
tried to use that NULL as though it referenced a memory location
where a delta was stored and tried to apply it to the delta base.
Loading a byte from the NULL address typically causes a SIGSEGV.
cate on #git noticed this failure in `git fsck --full` where the
call to verify_pack() first noticed that the packfile was corrupt
by finding that the packfile's SHA-1 did not match the raw data of
the file. After finding this fsck went ahead and tried to verify
every object within the packfile, even though the packfile was
already known to be bad. If we are going to shovel bad data at
the delta unpacking code, we better handle it correctly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
David Kastrup pointed out that the following sequence was not
working as we had intended:
$ cd lib
$ git gui blame console.tcl
fatal: cannot stat path lib/console.tcl: No such file or directory
The problem here was we disabled the chdir to the root of the
working tree when we are running with a "bare allowed" feature
such as blame or browser, but we still kept the prefix we found via
`git rev-parse --show-prefix`. This caused us to try and look for
the file "console.tcl" within the subdirectory but also include
the subdirectory's own path from the root of the working tree.
This is unlikely to succeed, unless the user just happened to have
a "lib/lib/console.tcl" file in the repository, in which case we
would produce the wrong result.
In the case of a bare repository we shouldn't get back a value from
`rev-parse --show-prefix`, so really $_prefix should only be set
to the non-empty string if we are in a working tree and we are in a
subdirectory of that working tree. If this is true we really want
to always be at the top level of the working tree, as all paths are
accessed as though they were relative to the top of the working tree.
Converting $_prefix to a ../ sequence is a fairly simple approach
to moving up the requisite levels.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Don't create the p4/HEAD symbolic ref if p4/master doesn't exist yet.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After a clone with "git clone" of a repository the p4 branches are only in remotes/origin/p4/* and not in remotes/p4/*.
Separate the code for detection and creation out of the P4Sync command class into standalone methods and use them
from the P4Branches command.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When not referring to the cvs command, CVS makes more sense.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After git-write-tree finishes computing the tree, it updates the
index so that later operations can take advantage of fully
populated cache tree.
However, anybody writing the index file has to mark the entries
that are racily clean. For each entry whose cached lstat(3)
data in the index exactly matches what is obtained from the
filesystem, if the timestamp on the index file was the same or
older than the modification timestamp of the file, the blob
contents and the work tree file, after convert_to_git(), need to
be compared, and if they are different, its index entry needs to
be marked not to match the lstat(3) data from the filesystem.
In order for this to work, convert_to_git() needs to work
correctly, which in turn means you need to read the config file
to get the settings of core.crlf and friends.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When squashing, rebase -i did not prevent fast forwards. This could
happen when picking some other commit than the first one, and then
squashing the first commit. So do not allow fast forwards when
squashing.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
MakeMaker supports three installation modes: perl, site, and vendor. The first
and third install manpages to $PREFIX/share/man, only site installs to
$PREFIX/man. For consistency with the rest of git, which does not make the
distinction and writes all manpages to $PREFIX/share/man, this change makes
sure that perl does too, even when it's installed in site mode.
Signed-off-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --stdlayout option to git-svn init/clone initialises the default
Subversion values of trunk,tags,branches: -T trunk -b branches -t tags.
If any of the -T/-t/-b options are given in addition, they are given
preference.
[ew: fixed whitespace and added "-s" shortcut]
Signed-off-by: martin f. krafft <madduck@madduck.net>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
A particularly bad case was HASH_LIMIT <= hash_count[i] < 2*HASH_LIMIT:
in that case, only a single hash survived. For larger cases,
2*HASH_LIMIT was the actual limiting value after pruning.
Signed-off-by: David Kastrup <dak@gnu.org>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-apply does not accept a patch that was generated as a three-way
combined diff format such as we see during merge conflicts. If we
get such a diff in our diff viewer and try to send it to git-apply
it just errors out and the user is left confused wondering why they
cannot stage that hunk.
Instead of feeding a known to be unacceptable hunk to git-apply we
now just disable the stage/unstage context menu option if the hunk
came from a three way diff. The user may still be confused about
why they cannot work with a combined diff, but at least they are
only confused as to why git-gui is not offering them the action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'master' of git://repo.or.cz/git/fastimport:
Teach bash about git-submodule and its subcommands
Teach bash to complete ref arguments to git-describe
Update bash completion with new 1.5.3 command line options
This will print out the URL that dcommit will operate on.
If used with --dry-run this will print out the URL without
making changes to the repository.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The current popup_diff_menu procedure is somewhat messy as it has a
few duplications of the same logic in each of the different legs of
the routine. We can simplify these by setting a few state variables
in the different legs.
No functional change, just a cleanup to make it easier to implement
future functional changes within this block.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-submodule command is new in 1.5.3 and contains a number
of useful subcommands for working on submodules. We usually try
to offer the subcommands of a git command in the bash completion,
so here they are for git-submodule.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm often finding that I need to run git-describe on very long
remote tracking branch names, to find out what tagged revision
the remote tracking branch is now at (or not at). Typing out
the ref names is painful, so bash completion on them is a very
useful feature.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A number of commands have learned new tricks as part of git 1.5.3.
If these are long options (--foo) we tend to support them in the
bash completion, as it makes the user's task of using the option
slightly easier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If you break out of the prompts presented to you by git send-email
your terminal can be left in an inconsistent state. Here we trap
the interrupt signal and reset the terminal before exiting.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For reason unknown a package in ActiveState Perl 5.8.7 must implement
READLINE method differently for scalar and array context. The code
tested to work for more sane and recent version of perl (5.8.8 shipped
with Ubuntu), so maybe it was always a requirement.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As noted by Mike Hommey, the documentation for the config setting tar.umask
is not up-to-date. Commit f08b3b0e2e changed
the default from 0 to 2; this patch finally documents it.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If core.bare is set to true in the config file of a repository that
the user is trying to create a working directory from we should
abort and suggest to the user that they remove the option first.
If we leave the core.bare=true setting in the config file then
working tree operations will get confused when they attempt to
execute in the new workdir, as it shares its config file with the
bare repository. The working tree operations will assume that the
workdir is bare and abort, which is not what the user wants.
If we changed core.bare to be false then working tree operations
will function in the workdir but other operations may fail in the
bare repository, as it claims to not be bare.
If we remove core.bare from the config then Git can fallback on
the legacy guessing behavior. This allows operations in the bare
repository to work as though it were bare, while operations in the
workdirs to act as though they are not bare.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
My day-job workflow involves using multiple workdirs attached to a
bunch of bare repositories. Such repositories are stored inside of
a directory called "foo.git", which means `git rev-parse --git-dir`
will return "." and not ".git". Under such conditions new-workdir
was getting confused about where the Git repository it was supplied
is actually located.
If we get "." for the result of --git-dir query it means we should
use the user supplied path as-is, and not attempt to perform any
magic on it, as the path is directly to the repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the tclsh command was not available to us at the time we were
"built" our lib/tclIndex just lists all of our library files and
we source all of them at once during startup, rather than trying
to lazily load only the procedures we need. This is a problem as
some of our library code now depends upon the git-version proc,
and that proc is not defined until after the library was fully
loaded.
I'm moving the library loading until after we have determined the
version of git we are talking to, as this ensures that the required
git-reversion procedure is defined before any library code can be
loaded. Since error_popup is defined in the library we instead use
tk_messageBox directly for errors found during the version detection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In a13ee29b97 I totally broke the
"Stage Hunk For Commit" feature by making this menu item always
appear in a disabled state, so it was never invokable. A "teaser
feature", just sitting there taunting the poor user who has become
used to having it available.
The issue caused by a13ee was I added a test to look at the data
in $file_states, but I didn't do that test correctly as it was
always looking at a procedure local $file_states array, which is
not defined, so the test was always true and we always disabled
the menu entry.
Instead we only want to disable the menu entry if the current file
we are looking at has no file state information (git-gui is just a
very confused little process) or it is an untracked file (and we
cannot stage individual hunks).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Hopefully last rc of 1.5.3 cycle, except a few documentation and
message wording changes, and git-gui 0.8.2.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Add a window to list branches, tags and other references
[PATCH] gitk: Handle 'copy from' and 'copy to' in diff headers.
gitk: Fix bug in fix for warning when removing a branch
Unless the user explicitly asked hardlinking with the '-l'
option, we should not say "oops we cannot hardlink as you asked
so we are copying".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds an entry to the File menu labelled "List references" which
pops up a window showing a sorted list of branches, tags, and other
references, with a little icon beside each to indicate what sort it
is. The list only shows refs that point to a commit that is included
in the graph, and if you click on a ref, the corresponding commit
is selected in the main window. The list of refs gets updated
dynamically.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Earlier when I rewrote the merge implementation for git-gui I broke
it such that the conflict markers for the "theirs" side of the hunk
was using a full SHA-1 ID in hex, rather than the name of the branch
the user had merged. This was because I got paranoid and passed off
the full SHA-1 to git-merge, instead of giving it the reference name
the user saw in the merge dialog.
I'd still like to resolve the SHA-1 upfront in git-gui and always use
that value throughout the merge, but I can't do that until we have a
full implementation of git-merge written in Tcl. Until then its more
important that the conflict markers be useful to the end-user, so we
need to pass off the ref name and not the SHA-1 ID.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-rev-parse manpage talks about the :$n:path notation (buried deep in
a list of other syntax) but it just says $n is a "stage number" -- someone
who is not familiar with the internals of git's merge implementation is
never going to be able to figure out that "1", "2", and "3" means.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --walk-reflogs logic and the --reverse logic are completely
incompatible with one another. Attempting to use both at the same
time leads to confusing results that sometimes violates the user's
formatting options or ignores the user's request to see the reflog
message and timestamp.
Unfortunately the implementation of both of these features is glued
onto the side of the revision walking machinary in such a way that
they are probably not going to be easy to make them compatible with
each other. Rather than offering the user confusing results we are
better off bailing out with an error message until such a time as
the implementations can be refactored to be compatible.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cehteh on #git noticed that secondary windows such as console
windows from push/fetch/merge or the blame browser failed on ion
when we tried to open them a second time.
The issue turned out to be the fact that on ion [winfo ismapped .]
returns false if . is not visible right now because it has been
obscured by another window in the same panel. So we need to keep
track of whether or not the root window has been displayed for this
application, and once it has been we cannot ever assume that ismapped
is going to return true.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This makes it easier to find out how to enable the reflog
for a bare repository by searching the documentation for
"reflog".
Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to not generate a patch ID for binary diffs, but that means that
some commits may be skipped as being identical to already-applied diffs
when doing a rebase.
So just delete the code that skips the binary diff. At the very least,
we'd want the filenames to be part of the patch ID, but we might also want
to generate some hash for the binary diff itself too.
This fixes an issue noticed by Torgil Svensson.
Tested-by: Torgil Svensson <torgil.svensson@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a thin pack wants to send a tree object at "sub/dir", and
the commit that is common between the sender and the receiver
that is used as the base object has a subproject at that path,
we should not try to use the data at "sub/dir" of the base tree
as a tree object. It is not a tree to begin with, and more
importantly, the commit object there does not have to even
exist.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
By default 'git reflog show' will show the reflog of 'HEAD' and not
the reflog of the current branch. This is most likely due to the
work done a while ago as part of the detached HEAD series to allow
HEAD to have its own reflog independent of each branch's reflog.
Since 'git reflog show' is really just an obscure alias for 'git
log -g --abbrev-commit --pretty=oneline' it should behave the same
way and its documentation should match.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
[PATCH] gitk: Make the date/time display configurable
[PATCH] gitk: Let user easily specify lines of context in diff view
gitk: Fix warning when removing a branch
* skip_optional_lf() decl is old-style -- please say
static skip_optional_lf(void)
{
...
}
* t9300 #14 fails, like this:
* expecting failure: git-fast-import <input
fatal: Branch name doesn't conform to GIT standards: .badbranchname
fast-import: dumping crash report to .git/fast_import_crash_14354
./test-lib.sh: line 143: 14354 Segmentation fault git-fast-import <input
-- >8 --
Subject: [PATCH] fastimport: Fix re-use of va_list
The va_list is designed to be used only once. The current code
reuses va_list argument may cause segmentation fault. Copy and
release the arguments to avoid this problem.
While we are at it, fix old-style function declaration of
skip_optional_lf().
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we crash the frontend developer (or end-user) may need to know
roughly around what part of the input stream we had a problem with
and aborted on. Because line numbers aren't very useful in this
sort of application we instead just keep the last 100 commands in
a FIFO queue and print them as part of the crash report.
Currently one problem with this design is a commit that has
more than 100 modified files in it will flood the FIFO and any
context regarding branch/from/committer/mark/comments will be lost.
We really should save only the last few (10?) file changes for the
current commit, ensuring we have some prior higher level commands
in the FIFO when we crash on a file M/D/C/R command.
Another issue with this approach is the FIFO only includes the
commands, it does not include the commit messages. Yet having a
commit message may be useful to help locate the relevant change in
the source material. In practice I don't think this is going to be a
major concern as the frontend can always embed its own source change
set identifier as a comment (which will appear in the crash report)
and the commit message(s) for the most recent commits of any given
branch should be obtainable from the (packed) commit objects.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As fast-import is quite strict about its input and die()'s anytime
something goes wrong it can be difficult for a frontend developer
to troubleshoot why fast-import rejected their input, or to even
determine what input command it rejected.
This change introduces a custom handler for Git's die() routine.
When we receive a die() for any reason (fast-import or a lower level
core Git routine we called) the error is first dumped onto stderr
and then a more extensive crash report file is prepared in GIT_DIR.
Finally we exit the process with status 128, just like the stock
builtin die handler.
An internal flag is set to prevent any further die()'s that may be
invoked during the crash report generator from causing us to enter
into an infinite loop. We shouldn't die() from our crash report
handler, but just in case someone makes a future code change we are
prepared to gaurd against small mistakes turning into huge problems
for the end-user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The existing checkpoint command is very useful to force fast-import
to dump the branches out to disk so that standard Git tools can
access them and the objects they refer to. However there was not a
way to know when fast-import had finished executing the checkpoint
and it was safe to read those refs.
The progress command can be used to make fast-import output any
message of the frontend's choosing to standard out. The frontend
can scan for these messages using select() or poll() to monitor a
pipe connected to the standard output of fast-import.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For the same reasons as the prior change we want to allow frontends
to omit the trailing LF that usually delimits commands. In some
cases these just make the input stream more verbose looking than
it needs to be, and its just simpler for the frontend developer to
get started if our parser is slightly more lenient about where an
LF is required and where it isn't.
To make this optional LF feature work we now have to buffer up to one
line of input in command_buf. This buffering can happen if we look
at the current input command but don't recognize it at this point
in the code. In such a case we need to "unget" the entire line,
but we cannot depend upon the stdio library to let us do ungetc()
for that many characters at once.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A few fast-import frontend developers have found it odd that we
require the LF following a `data` command, especially in the exact
byte count format. Technically we don't need this LF to parse
the stream properly, but having it here does make the stream more
readable to humans. We can easily make the LF optional by peeking
at the next byte available from the stream and pushing it back into
the buffer if its not LF.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Several frontend developers have asked that some form of stream
comments be permitted within a fast-import data stream. This way
they can include information from their own frontend program about
where specific data was taken from in the source system, or about
a decision that their frontend may have made while creating the
fast-import data stream.
This change introduces comments in the Bourne-shell/Tcl/Perl style.
Lines starting with '#' are ignored, up to and including the LF.
Unlike the above mentioned three languages however we do not look for
and ignore leading whitespace. This just simplifies the definition
of the comment format and the code that parses them.
To make comments work we had to stop using read_next_command() within
cmd_data() and directly invoke read_line() during the inline variant
of the function. This is necessary to retain any lines of the
input data that might otherwise look like a comment to fast-import.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Instead of growing our buffer by hand during the inline variant of
cmd_data() we can save a few lines of code and just use the nifty
new ALLOC_GROW macro already available to us.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Michael Haggerty <mhagger@alum.mit.edu> noticed while debugging a
Git backend for cvs2svn that fast-import was barfing when he tried
to use "TAG_FIXUP" as a branch name for temporary work needed to
cleanup the tree prior to creating an annotated tag object.
The reason we were rejecting the branch name was check_ref_format()
returns -2 when there are less than 2 '/' characters in the input
name. TAG_FIXUP has 0 '/' characters, but is technically just as
valid of a ref as HEAD and MERGE_HEAD, so we really should permit it
(and any other similar looking name) during import.
New test cases have been added to make sure we still detect very
wrong branch names (e.g. containing [ or starting with .) and yet
still permit reasonable names (e.g. TAG_FIXUP).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Something probably assumed that HT indentation is 4 characters.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This new option allows an arbitrary "cmd" to generate per patch
file specific "Cc:"s.
Signed-off-by: Joe Perches <joe@perches.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- Remove "DESTBRANCH" from usage, as it rewrites the branches given.
- Remove an = from an example usage, as the script doesn't understand
it.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If a commit contained a copy operation, the file name was not correctly
determined, and the corresponding part of the patch could not be
navigated to from the list of files.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Paul Mackerras <paulus@samba.org>
My fix in commit b1054ac985 was only
half-right, since it ignored the case where the descendent heads of
the head being removed correspond to two or more different commits.
This fixes it. Reported by Mark Levedahl.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is a follow-up to f34f2b0b; list_tree() function is where it
first notices that the command line fed too many trees for us to
handle, so move the error exit message to there, and raise the
MAX_TREES to 8 (not that it matters very much in practice).
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The t1301-shared-repo.sh testscript uses /usr/bin/stat to get the file
mode, which isn't portable. Implement the test in shell using 'ls' as
shown by Junio.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Not only are they unused, but the order in the function declaration
and the actual usage don't match.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apply "Subproject commit HEX" changes produced by git-diff.
As usual in the current git, only the superproject itself is actually
modified (possibly creating empty directories for new submodules).
Any checked-out submodule is left untouched and is not required to
be up-to-date.
With clean-ups from Junio C Hamano.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For multi-base merges, we allowed read-tree -m to take more than
three trees (the last two are our and their branches, and all the
earlier ones, typically one but potentially more, are used as the
merge base). Unfortunately, the conversion done by commit 933bf40
broke this.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-add -u also takes the path limiters, but unlike the
command without the -u option, the code forgot that it
could be invoked from a subdirectory, and did not correctly
handle the prefix.
Signed-off-by: Salikh Zakirov <salikh@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This applies to 'maint' to fix a rather serious data corruption
issue. When "git add -u" affects a subdirectory in such a way
that the only changes to its contents are path removals, the
next tree object written out of that index was bogus, as the
remove codepath forgot to invalidate the cache-tree entry.
Reported by Salikh Zakirov.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Always free .paths if .strdup_paths is set, no matter if the
parameter free_items is set or not, plugging a minor memory leak.
And to clarify the meaning of the flag, rename it to free_util,
since it now only affects the freeing of the .util field.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Running git-svn log <ref> -r<rev> against a <ref> other than the
current HEAD did not work if the <rev> was exclusive to the
other branch.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes .gitattributes files to be read from the index when
they are not checked out to the work tree. This is in line with
the way we always allowed low-level tools to operate in sparsely
checked out work tree in a reasonable way.
It swaps the order of new file creation and converting the blob
to work tree representation; otherwise when we are in the middle
of checking out .gitattributes we would notice an empty but
unwritten .gitattributes file in the work tree and will ignore
the copy in the index.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This splits out a common routine that parses a single line of
attribute file and adds it to the attr_stack. It should not
change any behaviour, other than attrs array in the attr_stack
structure is now grown with alloc_nr() macro, instead of one by
one, which relied on xrealloc() to give enough slack to be
efficient enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We can now read .gitattributes files out of the index, but the index
must be loaded for this to work.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we compare two non-tracked files, or explicitly
specify --no-index, the suggestion to run git-status
is not helpful.
The patch adds a new diff_options bitfield member, no_index, that
is used instead of the special value of -2 of the rev_info field
max_count to indicate that the index is not to be used. This makes
it possible to pass that flag down to diffcore_skip_stat_unmatch(),
which only has one diff_options parameter.
This could even become a cleanup if we removed all assignments of
max_count to a value of -2 (viz. replacement of a magic value with
a self-documenting field name) but I didn't dare to do that so late
in the rc game..
The no_index bit, if set, then tells diffcore_skip_stat_unmatch()
to not account for any skipped stat-mismatches, which avoids the
suggestion to run git-status.
Signed-off-by: Rene Scharfe <rene.scharfe@lsfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
xmkstemp() performs error checking and prints a standard error message when
an error occur.
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a wrapper for mkstemp() that performs error checking and
calls die() when an error occur.
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Print the index version when an error occurs so the user
knows what type of header (and size) we thought the index
should have had.
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When you try to merge a path that involves binary file-level
merge, merge-recursive died rudely without cleaning up its own
mess. A files added by the merge were left in the working tree,
but the index was not written out (because it just punted and
died), so it was cumbersome for the user to retry it by first
running "git reset --hard".
This changes merge-recursive to still warn but do the "binary"
merge for such a path; leave the "our" version in the working
tree, but still keep the path unmerged so that the user can sort
it out.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The new 'datetimeformat' configuration variable in ~/.gitk can be set
to a Tcl 'clock format' format string to modify the display of dates
and times.
http://www.tcl.tk/man/tcl8.4/TclCmd/clock.htm has a list of allowed
fields.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
More lines of context sometimes help to better understand a diff.
This patch introduces a text field above the box displaying the
blobdiffs. You can type in the number of lines of context that
you wish to view. The number of lines of context is saved to
~/.gitk.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When we had two heads on the same commit, and the user tried to remove
one of them, gitk was sometimes incorrectly saying that the commits
on that branch weren't on any other branch. This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
With this option git-log prints log message size
just before the corresponding message.
Porcelain tools could use this to speedup parsing
of git-log output.
Note that size refers to log message only. If also
patch content is shown its size is not included.
In case it is not possible to know the size upfront
size value is set to zero.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After starting to edit a working tree file but later when your edit ends
up identical to the original (this can also happen when you ran a
wholesale regexp replace with something like "perl -i" that does not
actually modify many of the paths), "git diff" between the index and the
working tree outputs many "empty" diffs that show "diff --git" headers
and nothing else, because these paths are stat-dirty. While it was a
way to warn the user that the earlier action of the user made the index
ineffective as an optimization mechanism, it was felt too loud for the
purpose of warning even to experienced users, and also resulted in
confusing people new to git.
This replaces the "empty" diffs with a single warning message at the
end. Having many such paths hurts performance, and you can run
"git-update-index --refresh" to update the lstat(2) information recorded
in the index in such a case. "git-status" does so as a side effect, and
that is more familiar to the end-user, so we recommend it to them.
The change affects only "git diff" that outputs patch text, because that
is where the annoyance of too many "empty" diff is most strongly felt,
and because the warning message can be safely ignored by downstream
tools without getting mistaken as part of the patch. For the low-level
"git diff-files" and "git diff-index", the traditional behaviour is
retained.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The first thing we teach in the tutorial is to set the default
identity in $HOME/.gitconfig using "git config --global". The
suggestion in the error message should match the order, while
hinting that per repository identity can later be configured
differently.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Quite a few of the scripts are rather careless about using GIT_DIR
while changing directories.
Some try their hands (with different likelihood of success) in making
GIT_DIR absolute.
This patch lets git-sh-setup.sh cater for absolute directories (in a
way that should work reliably also with non-Unix path names) and
removes the respective kludges in git-filter-branch.sh and
git-instaweb.sh.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some repositories started with the trunk in "/" and then moved it to the
standard "trunk/" location.
On these repositories, the correct thing would be to call git-svnimport -T "",
but because of the way the options are handled, it uses the default "trunk"
instead of the given empty string. This patch fixes that behaviour.
Reported by Leandro Lucarella <llucax@gmail.com>.
Signed-off-by: Alberto Bertogli <albertito@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When performing a git-p4 clone operation on a Perforce repository,
where the changelists change in order of magnitude (e.g. 100 to 1000),
the set of changes to import from is not sorted properly. This is
because the data in the list is strings not integers. The other place
where this is done already converts the value to an integer, so it is
not affected.
Acked-by: Simon Hausmann <simon@lst.de>
As Wincent Colaiuta found out, it's a bit unexpected for git diff to
start a pager even when the --quiet option is specified. The problem
is that the pager hides the return code -- which is the only output
we're interested in in this case.
Push pager setup down into builtin-diff.c and don't start the pager
if --exit-code or --quiet (which implies --exit-code) was specified.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Windows / cygwin don't support HT, LF, or TAB in file name so this test
is meaningless there.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows to refresh only a subset of the project files, based on
the specified pathspecs.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Here-text to create fake-editor did not use <<\EOF but <<EOF,
but there was no point doing so, as it quoted all the variables
anyway. Simplify it.
Also futureproof the special mode to edit COMMIT_EDITMSG file;
it is interested in editing the COMMIT_EDITMSG file in any
GIT_DIR; GIT_DIR may be given as an absolute path.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows jumping to the correct file with the diff-mode commands.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix bug causing Tcl error when updating graph
gitk: Fix bug introduced in commit 67a4f1a7
[PATCH] gitk: Show an error and exit if no .git could be found
[PATCH] gitk: Continue and show error message in new repos
[PATCH] gitk: Handle MouseWheel events on Windows
[PATCH] gitk: Enable selected patch text on Windows
gitk: Fix bug causing the "can't unset idinlist(...)" error
gitk: Add a context menu for file list entries
If "Show nearby tags" is turned off, selecting "Update" from the File
menu will cause a Tcl error. This fixes it. The problem was that
we were calling regetallcommits unconditionally, but it assumed that
getallcommits had been called previously. This also restructures
{re,}getallcommits to be a bit simpler.
Signed-off-by: Paul Mackerras <paulus@samba.org>
In fixing the "can't unset idinlist" error, I moved the setting of
idinlist into the loop that splits the parents into "new" parents
(i.e. those of which this is the first child) and "old" parents.
Unfortunately this is incorrect in the case where we hit the break
statement a few lines further down, since when we come back in,
we'll see idinlist($p) set for some parents that aren't in the list.
This fixes it by moving the loop that sets up newolds and oldolds
further down.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is to help people starting gitk from graphical file managers where
the stderr output is hidden.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
If there is no commit made yet, gitk just dumps a Tcl error on stderr,
which sometimes is hard to see. Noticed when gitk was run from Xfce
file manager (thunar's custom action).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Windows, unlike X-Windows, sends mousewheel events by default to the
window that has keyboard focus and uses the MouseWheel event to do so.
The window to be scrolled must be able to take focus, but gitk's panels
are disabled so cannot take focus. For all these reasons, a different
design is needed to use the mousewheel on Windows. The approach here is
to bind the mousewheel events to the top level window and redirect them
based upon the current mouse position.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
On windows, mouse input follows the keyboard focus, so to allow selecting
text from the patch canvas we must not shift focus back to the top level.
This change has no negative impact on X, so we don't explicitly test
for Win32 on this change. This provides similar selection capability
as already available using X-Windows.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Under some circumstances, having duplicate parents in a commit could
trigger a "can't unset idinlist" Tcl error. This fixes the cause
(the logic in layoutrows could end up putting the same commit into
rowidlist twice) and also puts a catch around the unset to ignore
the error.
Thanks to Jeff King for coming up with a test script to generate a
repo that shows the problem.
Signed-off-by: Paul Mackerras <paulus@samba.org>
If cmd-list.made has been created by a previous run as root, output
redirection to it will fail. So remove it before regeneration.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cr/tag:
Teach "git stripspace" the --strip-comments option
Make verify-tag a builtin.
builtin-tag.c: Fix two memory leaks and minor notation changes.
launch_editor(): Heed GIT_EDITOR and core.editor settings
Make git tag a builtin.
These patches use docbook2x in order to create an info version of the
git user manual. No existing Makefile targets (including "all") are
touched, so you need to explicitly say
make info
sudo make install-info
to get git.info created and installed. If the info target directory
does not already contain a "dir" file, no directory entry is created.
This facilitates $(DESTDIR)-based installations. The same could be
achieved with
sudo make INSTALL_INFO=: install-info
explicitly.
perl is used for patching up sub-par file and directory information in
the Texinfo file. It would be cleaner to place the respective info
straight into user-manual.txt or the conversion configurations, but I
find myself unable to find out how to do this with Asciidoc/Texinfo.
Signed-off-by: David Kastrup <dak@gnu.org>
As mentioned, the three-way case *should* be as trivial as the
following. It passes all the tests, and I verified that a conflicting
merge in the 100,000 file horror-case merged correctly (with the conflict
markers) in 0.687 seconds with this, so it works, but I'm lazy and
somebody else should double-check it [jc: followed all three-way merge
codepaths and verified it removes when it should].
Without this patch, the merge took 8.355 seconds, so this patch
really does make a huge difference for merge performance with lots and
lots of files, and we're not talking percentages, we're talking
orders-of-magnitude differences!
Now "unpack_trees()" is just fast enough that we don't need to avoid it
(although it's probably still a good idea to eventually convert it to use
the traverse_trees() infrastructure some day - just to avoid having
extraneous tree traversal functions).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On Windows (it can't touch open files in any way) the following fails:
git branch -D branch1 branch2
if the both branches are in packed-refs.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This eliminates all use of byte-at-a-time reading of data in this
function: as Junio noted, a bundle file is seekable so we can
reset the file position to the first part of the pack-file using lseek
after reading the header.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-bundle create on cygwin was nearly unusable due to 1 character
at a time (unbuffered) reading from an exec'ed process. Fix by using
fdopen to get a buffered stream.
Results for "time git bundle create test.bdl v1.0.3..v1.5.2" are:
before this patch:
cygwin linux
real 1m38.828s 0m3.578s
user 0m12.122s 0m2.896s
sys 1m28.215s 0m0.692s
after this patch:
real 0m3.688s 0m2.835s
user 0m3.075s 0m2.731s
sys 0m1.075s 0m0.149s
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mark Levedahl <mlevedahl@gmail.com> writes:
> Junio C Hamano wrote:
>> While "git bundle" was a useful way to sneakernet incremental
>> changes, we did not allow:
>>
> Thanks - I've been thinking for months I could fix this bug, never
> figured it out and didn't want to nag Dscho one more time. I confirm
> that this allows creation of bundles with arbitrary refs, not just
> those under refs/heads. Yahoo!
Actually, there is another bug nearby.
If you do:
git bundle create v2.6-20-v2.6.22.bndl v2.6.20..v2.6.22
the bundle records that it requires v2.6.20^0 commit (correct)
and gives you tag v2.6.22 (incorrect); the bug is that the
object it lists in fact is the commit v2.6.22^0, not the tag.
This is because the revision range operation .. is always about
set of commits, but the code near where my patch touches does
not validate that the sha1 value obtained from dwim_ref()
against the commit object name e->item->sha1 before placing the
head information in the commit.
The attached patch attempts to fix this problem.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
While "git bundle" was a useful way to sneakernet incremental
changes, we did not allow:
$ git bundle create v2.6.20.bndl v2.6.20
to create a bundle that contains the whole history to a
well-known good revision. Such a bundle can be mirrored
everywhere, and people can prime their repository with it to
reduce the load on the repository that serves near the tip of
the development.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This trivially optimizes the two-way merge case of git-read-tree too,
which affects switching branches.
When you have tons and tons of files in your repository, but there are
only small differences in the branches (maybe just a couple of files
changed), the biggest cost of the branch switching was actually just the
index calculations.
This fixes it (timings for switching between the "testing" and "master"
branches in the 100,000 file testing-repo-from-hell, where the branches
only differ in one small file).
Before:
[torvalds@woody bummer]$ time git checkout master
real 0m9.919s
user 0m8.461s
sys 0m0.264s
After:
[torvalds@woody bummer]$ time git checkout testing
real 0m0.576s
user 0m0.348s
sys 0m0.228s
so it's easily an order of magnitude different.
This concludes the series. I think we could/should do the three-way merge
too (to speed up merges), but I'm lazy. Somebody else can do it.
The rule is very simple: you need to remove the old entry if:
- you want to remove the file entirely
- you replace it with a "merge conflict" entry (ie a non-stage-0 entry)
and you can avoid removing it if you either
- keep the old one
- or resolve it to a new one.
and these rules should all be valid for the three-way case too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This optimizes bind_merge() and oneway_merge() to not unnecessarily
remove and re-add the old index entries when they can just get replaced
by updated ones.
This makes these operations much faster for large trees (where "large"
is in the 50,000+ file range), because we don't unnecessarily move index
entries around in the index array all the time.
Using the "bummer" tree (a test-tree with 100,000 files) we get:
Before:
[torvalds@woody bummer]$ time git commit -m"Change one file" 50/500
real 0m9.470s
user 0m8.729s
sys 0m0.476s
After:
[torvalds@woody bummer]$ time git commit -m"Change one file" 50/500
real 0m1.173s
user 0m0.720s
sys 0m0.452s
so for large trees this is easily very noticeable indeed.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes no changes to current code, but it allows the individual merge
functions to decide what to do about the old entry. They might decide to
update it in place, rather than force them to always delete and re-add it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This trivial patch avoids re-hashing files that are already clean in the
index. This mirrors what commit 0781b8a9b2
did for "git add .", only for "git commit ." instead.
This improves the cold-cache case immensely, since we don't need to bring
in all the file contents, just the index and any files dirty in the index.
Before:
[torvalds@woody linux]$ time git commit .
real 1m49.537s
user 0m3.892s
sys 0m2.432s
After:
[torvalds@woody linux]$ time git commit .
real 0m14.273s
user 0m1.312s
sys 0m0.516s
(both after doing a "echo 3 > /proc/sys/vm/drop_caches" to get cold-cache
behaviour - even with the index optimization git still has to "lstat()"
all the files, so with a truly cold cache, bringing all the inodes in
will take some time).
[jc: trivial "return 0;" fixed]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The read_tree() function is called only from the call chain to
run "git diff --cached" (this includes the internal call made by
git-runstatus to run_diff_index()). The function vacates stage
without any funky "merge" magic. The caller then goes and
compares stage #1 entries from the tree with stage #0 entries
from the original index.
When adding the cache entries this way, it used the general
purpose add_cache_entry(). This function looks for an existing
entry to replace or if there is none to find where to insert the
new entry, resolves D/F conflict and all the other things.
For the purpose of reading entries into an empty stage, none of
that processing is needed. We can instead append everything and
then sort the result at the end.
This commit changes read_tree() to first make sure that there is
no existing cache entries at specified stage, and if that is the
case, it runs add_cache_entry() with ADD_CACHE_JUST_APPEND flag
(new), and then sort the resulting cache using qsort().
This new flag tells add_cache_entry() to omit all the checks
such as "Does this path already exist? Does adding this path
remove other existing entries because it turns a directory to a
file?" and instead append the given cache entry straight at the
end of the active cache. The caller of course is expected to
sort the resulting cache at the end before using the result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This doesn't actually change any real code, but it changes the interface
to unpack_trees() to take an array of "struct tree_desc" entries, the same
way the tree-walk.c functions do.
The reason for this is that we would be much better off if we can do the
tree-unpacking using the generic "traverse_trees()" functionality instead
of having to the special "unpack" infrastructure.
This really is a pretty minimal diff, just to change the calling
convention. It passes all the tests, and looks sane. There were only two
users of "unpack_trees()": builtin-read-tree and merge-recursive, and I
tried to keep the changes minimal.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old behaviour was to unilaterally default to the cwd is the work tree
when GIT_DIR was set, but GIT_WORK_TREE wasn't, no matter if we are inside
the GIT_DIR, or if GIT_DIR is actually something like ../../../.git.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This attempts to force fixed-font in manpages for literal
blocks. I have tested this with docbook 1.71 and it seems to
work as expected.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This hides the backslash at the end of line from AsciiDoc
toolchain by introducing a trailing whitespace on one line in an
illustration in git-rev-parse.txt.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
- when sending several mails I got a slightly different behaviour for the first
mail compared to the second to last one. The reason is that $from was
assigned in line 608 and was not reset when beginning to handle the next
mail.
- Email::Valid can only handle properly quoted real names, so quote arguments
to extract_valid_address.
This patch cleans up variable naming to better differentiate between sender of
the mail and it's author.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Email::Valid does respect this considering such a mailbox specification
invalid. b06c6bc831 addressed the issue, but
only if Email::Valid is available.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We have to load a tree difference for the purpose of testing
file patterns. But if our branch is being created and there is no
specific base to difference against in the rule our base will be
'0'x40. This is (usually) not a valid tree-ish object in a Git
repository, so there's nothing to difference against.
Instead of creating the empty tree and running git-diff against
that we just take the output of `ls-tree -r --name-only` and mark
every returned pathname as an add.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some applications of the update hook a user may be allowed to
modify a branch, but only if the file level difference is also an
allowed change. This is the commonly requested feature of allowing
users to modify only certain files.
A new repository.*.allow syntax permits granting the three basic
file level operations:
A: file is added relative to the other tree
M: file exists in both trees, but its SHA-1 or mode differs
D: file is removed relative to the other tree
on a per-branch and path-name basis. The user must also have a
branch level allow line already granting them access to create,
rewind or update (CRU) that branch before the hook will consult
any file level rules.
In order for a branch change to succeed _all_ files that differ
relative to some base (by default the old value of this branch,
but it can also be any valid tree-ish) must be allowed by file
level allow rules. A push is rejected if any diff exists that
is not covered by at least one allow rule.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some applications of this paranoid update hook the set of ACL
rules that need to be applied to a user can be large, and the
number of users that those rules must also be applied to can be
more than a handful of individuals. Rather than repeating the same
rules multiple times (once for each user) we now allow users to be
members of groups, where the group supplies the list of ACL rules.
For various reasons we don't depend on the underlying OS groups
and instead perform our own group handling.
Users can be made a member of one or more groups by setting the
user.memberOf property within the "users/$who.acl" file:
[user]
memberOf = developer
memberOf = administrator
This will cause the hook to also parse the "groups/$groupname.acl"
file for each value of user.memberOf, and merge any allow rules
that match the current repository with the user's own private rules
(if they had any).
Since some rules are basically the same but may have a component
differ based on the individual user, any user.* key may be inserted
into a rule using the "${user.foo}" syntax. The allow rule does
not match if the user does not define one (and exactly one) value
for the key "foo".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-cvsserver used checkout-index internally for commit and annotate.
Since a work tree is required for this to function now, this was
breaking. Work around this by defining GIT_WORK_TREE=. in the
appropriate places.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Parse the files section in the "p4 change -o" output and remove lines with file changes in unrelated depot paths.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The basic idea was proposed by Steve Hoelzer; in order to make
the list easier to search, we keep the command list in the
script that generates it with "sort -d".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Detect symlinks as file type, set the git file mode accordingly and strip off the trailing newline in the p4 print output.
Make the mode handling a bit more readable at the same time.
Signed-off-by: Simon Hausmann <simon@lst.de>
Acked-by: Brian Swetland <swetland@google.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch I'm not able to properly send emails as I have a
non-ascii character in my name.
I removed the _rfc822 suffix from the function name as it now does more
than rfc822 quoting.
I dug through rfc822 to do the double quoting right. Only if that is not
possible rfc2047 quoting is applied.
Signed-off-by: Uwe Kleine-K,Av(Bnig <ukleinek@informatik.uni-freiburg.de>
Cc: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The basic idea is from Mark Levedahl. I do not use GZ=1 nor
quick-install-doc myself (there obviously is a chicken-and-egg
issue with quick-install-doc for me).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It was very unfortunate that we added core.pager setting to the
configuration file; even when the underlying command does not care
if there is no git repository is involved (think "git diff --no-index"),
the user would now rightfully want the configuration setting to be
honored, which means we would need to read the configuration file before
we launch the pager.
This is a minimum change in the sense that it restores the old
behaviour of not even reading config in setup_git_directory(),
but have the core.pager honored when we know it matters.
Note that this does not cover "git -p --git-dir where command";
the -p option immediately trigger the pager settings before we
even see --git-dir to learn where the configuration file is, so
we will end up reading the configuration from the place where
we would _normally_ find the git repository.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am expects the variable $resume to be empty or unset, which might not
be the case if $resume is set in the user's environment. So initialize
it to an empty value on startup.
The problem was noticed by Pierre Habouzit and reported through
http://bugs.debian.org/435807
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These instructions tell you how to create a clone of a repository
created with git-svn, that can in turn be used with git-svn.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
apply: remove directory that becomes empty by renaming the last file away
setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
We attempt to remove directory that becomes empty after removal
of a file. We should do the same when we rename an existing
file away.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have a working tree _file_ "foo", attempt to refer to a
branch "foo/bar" without -- to disambiguate, like this:
$ git log foo/bar
tried to make sure that foo/bar cannot be naming a working tree
file "foo/bar" (in which case we would say "which one do you
want? A rev or a working tree file? clarify with -- please").
We run lstat("foo/bar") to check that. If it does not succeed,
there is no ambiguity.
That is good. But we also checked the error status for the
lstat() and expected it to fail with ENOENT. In this particular
case, however, it fails with ENOTDIR. That should be treated as
"expected error" as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As with git-add, I think previous updates to the git-commit man page did
indeed help make it more user-friendly. But I think the banishment of
the word "index" from the description goes too far; reinstate its use,
to simplify some of the language slightly and smooth the transition to
other documentation.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://linux-nfs.org/~bfields/git:
documentation: use the word "index" in the git-add manual page
user-manual: mention git-gui
user-manual: mention git stash
user-manual: update for new default --track behavior
It was a neat trick to show that you could introduce the git-add manual
page without using the word "index", and it was certainly an improvement
over the previous man page (which started out "A simple wrapper for
git-update-index to add files to the index...").
But it's possible to use the standard terminology without sacrificing
user-friendliness. So, rewrite to use the word "index" when
appropriate.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The git gui project seems to be still in early stages, but at a point
where it's worth mentioning as an alternative way of creating commits.
One feature of interest is the ability to manipulate individual diff
hunks. However, people have found that feature not to be easily
discoverable from the user-interface. Pending some ui improvements, a
parenthetical hint here may help.
(Thanks to Steffen Prohask and Junio Hamano for suggesting the
language.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Update documentation to reflect the --track default.
That change seems to have happened in the 1.5.3 -rc's, so bump the "for
version x.y.z or newer" warning as well.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
The script starts in a subdirectory of the source directory to
muck with a branch whose structure does not have anything to
do with the actual work tree. Go up to the top to make it clear
that we operate on the whole tree.
It also exported GIT_DIR without any good reason. Remove it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sven originally raised this issue:
If you have a submodule checked out and you go back (or
forward) to a revision of the supermodule that contains a
different revision of the submodule and then switch to
another revision, it will complain that the submodule is not
uptodate, because git simply didn't update the submodule in
the first move.
The current policy is to consider it is perfectly normal that
checked-out submodule is out-of-sync wrt the supermodule index.
At least until we introduce a superproject repository
configuration option that says "in this repository, I do care
about this submodule and at any time I move around in the
superproject, recursively check out the submodule to match", it
is a reasonable policy, as we currently do not recursively
checkout the submodules at all. The most extreme case of this
policy is that the superproject index knows about the submodule
but the subdirectory does not even have to be checked out.
The function verify_uptodate(), called during the two-way merge
aka branch switching, is about "make sure the filesystem entity
that corresponds to this cache entry is up to date, lest we lose
the local modifications". As we explicitly allow submodule
checkout to drift from the supermodule index entry, the check
should say "Ok, for submodules, not matching is the norm" for
now.
Later when we have the ability to mark "I care about this
submodule to be always in sync with the superproject" (thereby
implementing automatic recursive checkout and perhaps diff,
among other things), we should check if the submodule in
question is marked as such and perform the current test.
Acked-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git-push it is the remote repository and not the
local repository which is fast forwarded. The description
of the -f option in the git-push manpage gets it the other
way round.
Signed-off-by: Jyotirmoy Bhattacharya <jyotirmoy@jyotirmoy.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The GIT_SSH environment variable has survived for quite a while
without being documented, but has been mentioned on list and on
my day-job repositories can only be accessed via magic supplied
through the wonderous hack that is GIT_SSH.
Advertising it alongside other "low level magic" such as GIT_PAGER
and GIT_MERGE_VERBOSITY will certainly help others who need to
spread their own pixie dust to make things work.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The commit b6093a5c, by Robert Fitzsimons:
"gitweb: Change atom, rss actions to use parse_commits."
forgot to pass $file_name parameter to parse_commits subroutine.
If git_feed is provided a file name, it ought to show only the history
affecting that file or a directory. The title was being set
correctly, but all commits from history were being shown.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a new addition to 1.5.3; let's teach it to the
completion before the final release.
[sp: Added missing git-stash completion configuration]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
OS X sends Button-2 on a "real" right click, such as with a three
button mouse, or by using the two-finger trackpad click.
Signed-off-by: Väinö Järvelä <v@pp.inet.fi>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The hashed contents did not matter in the end result, but it passed
an uninitialized variable to printf, which caused it to emit empty
while giving an error/usage message.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If somebody used to advertise his repository that physically
resides at /pub/lic.git/ as:
git://git.example.com/pub/lic.git/
but now wants to use --base-path to allow:
git://git.example.com/lic.git/
she can start git-daemon with --base-path option, like this:
git-daemon --base-path=/pub --export-all
During the transition, however, she would also want to allow
older URL as well. One natural way to achieve that is to create
a symlink:
ln -s /pub /pub/pub
so that a request to git://git.example.com/pub/lic.git/ is first
translated by --base-path to a request to /pub/pub/lic.git/
which goes to /pub/lic.git, thanks to the symlink.
So far so good.
However, gitweb chokes if there is such a symlink (File::Find
barfs with "/pub/pub is a recursive symbolic link"). Make the
code ignore such a symlink.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If there is no path currently shown in the diff viewer then we
were getting Tcl errors anytime the user right-clicked on the
diff viewer to bring up its popup menu. The bug here is caused
by trying to get the file_state for the empty string; this path
is never seen so we never have file_state for it. In such cases
we now disable the Stage Hunk For Commit option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In set_work_tree(), variable rel needs to be reinitialized to
NULL on every call (it should not be static).
Make sure the incoming dir variable is not too long before
copying to the temporary buffer, and make sure chdir to the
resulting directory succeeds.
This was spotted and fixed by Alex and Johannes in a handful
patch exchanges. Here is the final version.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
The current implementation of core.gitproxy only operates on
git:// URLs, so the ssh:// examples and custom protocol examples
have been removed or edited.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
read-tree is already marked with RUN_SETUP in git.c, so there is
no need to call setup_git_directory() a second time.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
processing
P4 change outputs the changes sorted for each directory separately. We
want the global ordering on the changes, hence we sort.
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
This changes the behaviour of cloning from a repository on the
local machine, by defaulting to "-l" (use hardlinks to share
files under .git/objects) and making "-l" a no-op. A new
option, --no-hardlinks, is also added to cause file-level copy
of files under .git/objects while still avoiding the normal
"pack to pipe, then receive and index pack" network transfer
overhead. The old behaviour of local cloning without -l nor -s
is availble by specifying the source repository with the newly
introduced file:///path/to/repo.git/ syntax (i.e. "same as
network" cloning).
* With --no-hardlinks (i.e. have all .git/objects/ copied via
cpio) would not catch the source repository corruption, and
also risks corrupted recipient repository if an
alpha-particle hits memory cell while indexing and resolving
deltas. As long as the recipient is created uncorrupted, you
have a good back-up.
* same-as-network is expensive, but it would catch the breakage
of the source repository. It still risks corrupted recipient
repository due to hardware failure. As long as the recipient
is created uncorrupted, you have a good back-up.
* The new default on the same filesystem, as long as the source
repository is healthy, it is very likely that the recipient
would be, too. Also it is very cheap. You do not get any
back-up benefit, though.
None of the method is resilient against the source repository
corruption, so let's discount that from the comparison. Then
the difference with and without --no-hardlinks matters primarily
if you value the back-up benefit or not. If you want to use the
cloned repository as a back-up, then it is cheaper to do a clone
with --no-hardlinks and two git-fsck (source before clone,
recipient after clone) than same-as-network clone, especially as
you are likely to do a git-fsck on the recipient if you are so
paranoid anyway.
Which leads me to believe that being able to use file:/// is
probably a good idea, if only for testability, but probably of
little practical value. We default to hardlinked clone for
everyday use, and paranoids can use --no-hardlinks as a way to
make a back-up.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We might make it something like: "if you use an url, we don't default to
local", so the difference would be that
git clone file:///directory/to/repo
would work the way it does now, but
git clone /directory/to/repo
would default to "-l" behaviour. That kind of would make sense (and should
be easy to implement.
This adds support for "file://" URL to underlying connect
codepath to make it happen.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes "make doc" work even if you made "sudo make doc" previously
by mistake. Apparently an oversight: the other targets did this already.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When calling "git rebase -i <upstream> <branch>", git should switch
to <branch> first. This worked before, but I broke it by my
"Shut git rebase -i up" patch.
Fix that, and add a test to make sure that it does not break again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[jc: adjusted t/t7501 as this makes -F and --amend compatible]
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The previous code only allowed specifying a single executable rather
than a complete command like "emacsclient --alternate-editor vi" in
those variables. Since VISUAL/EDITOR appear to be traditionally
passed to a shell for interpretation (as corroborated with "less",
"mail" and "mailx", while the really ancient "more" indeed allows only
an executable name), the shell function git_editor has been amended
appropriately.
"eval" is employed to have quotes and similar interpreted _after_
expansion, so that specifying
EDITOR='"/home/dak/My Commands/notepad.exe"'
can be used for actually using commands with blanks.
Instead of passing just the first argument of git_editor on, we pass
all of them (so that +lineno might be employed at a later point of
time, or so that multiple files may be edited when appropriate).
Strictly speaking, there is a change in behavior: when
git config core.editor
returns a valid but empty string, the fallbacks are still searched.
This is more consistent, and the old code was problematic with regard
to multiple blanks. Putting in additional quotes might have worked,
but quotes inside of command substitution inside of quotes is nasty
enough to not reliably work the same across "Bourne shells".
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It wont work for arguments with special characters (like ", : or *).
It is generally not possible on Windows, so I didn't even try.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Non-interactive rebase had this from the beginning -- match it by
using --cherry-pick option to rev-list.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comment did not make a good case why it makes sense.
Clarify, and remove stale comment about the caller being lazy.
The behaviour on NULL input is pretty much intentional.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The old version of work-tree support was an unholy mess, barely readable,
and not to the point.
For example, why do you have to provide a worktree, when it is not used?
As in "git status". Now it works.
Another riddle was: if you can have work trees inside the git dir, why
are some programs complaining that they need a work tree?
IOW it is allowed to call
$ git --git-dir=../ --work-tree=. bla
when you really want to. In this case, you are both in the git directory
and in the working tree. So, programs have to actually test for the right
thing, namely if they are inside a working tree, and not if they are
inside a git directory.
Also, GIT_DIR=../.git should behave the same as if no GIT_DIR was
specified, unless there is a repository in the current working directory.
It does now.
The logic to determine if a repository is bare, or has a work tree
(tertium non datur), is this:
--work-tree=bla overrides GIT_WORK_TREE, which overrides core.bare = true,
which overrides core.worktree, which overrides GIT_DIR/.. when GIT_DIR
ends in /.git, which overrides the directory in which .git/ was found.
In related news, a long standing bug was fixed: when in .git/bla/x.git/,
which is a bare repository, git formerly assumed ../.. to be the
appropriate git dir. This problem was reported by Shawn Pearce to have
caused much pain, where a colleague mistakenly ran "git init" in "/" a
long time ago, and bare repositories just would not work.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With the function set_git_dir() you can reset the path that will
be used for git_path(), git_dir() and friends.
The responsibility to close files and throw away information from the
old git_dir lies with the caller.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function get_relative_cwd() works just as getcwd(), only that it
takes an absolute path as additional parameter, returning the prefix
of the current working directory relative to the given path. If the
cwd is no subdirectory of the given path, it returns NULL.
is_inside_dir() is just a trivial wrapper over get_relative_cwd().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch adds convenience functions to work with absolute paths.
The function is_absolute_path() should help the efforts to integrate
the MinGW fork.
Note that make_absolute_path() returns a pointer to a static buffer.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I switched git.kernel.dk to --base-path a few minutes ago, to get rid of
a /data/git postfix in the posted urls. But transitioning is tricky,
since now all old paths will fail miserably.
So I added this --base-path-relaxed option, that will make git-daemon
try the absolute path without prefixing --base-path before giving up.
With this in place and --base-path-relaxed added, both my new url of
git://git.kernel.dk/linux-2.6-block.git
and the old
git://git.kernel.dk/data/git/linux-2.6-block.git
work fine.
Signed-off-by: Jens Axboe <jens.axboe@oracle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also don't require .git/info/exclude to exist in order to list unknown
files.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Acked-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check for non-0 exit code if the confiog file does not exist and
if it works exactly like when setting GIT_CONFIG.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are (really!) systems where using environment variables is very
cumbersome (yes, Windows, it has problems unsetting them). Besides this
form is shorter.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce new makefile variable lib to hold the name of the lib
directory ("lib" by default). Also introduce a switch for configure
to specify this name with --with-lib=ARG. This is useful for systems
that use a different name than "lib" (like "lib64" on some 64 bit
Linux architectures).
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some systems do not provide zlib development headers and libraries in
default search path of the compiler. For these systems we should allow
specifying the location by --with-zlib=PATH or by setting ZLIB_PATH in
the makefile.
Signed-off-by: Robert Schiele <rschiele@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
An earlier commit 366bfcb6 broke git-add by moving read_cache()
call down, because it wanted the directory walking code to grab
paths that are already in the index. The change serves its
purpose, but introduces a regression because the responsibility
of avoiding unnecessary reindexing by matching the cached stat
is shifted nowhere.
This makes it the job of add_file_to_index() function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In git some characters are invalid as documented
in git-check-ref-format. In subversion these characters might
be valid, so a translation is required.
This patch does this translation by url escaping characters, that
are not allowed.
Credit goes to Eric Wong, martin f. krafft and Jan Hudec
Signed-off-by: Robert Ewald <robewald@gmx.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The file used for per-repository attribute setting is not
$GIT_DIR/info/gitattributes, but $GIT_DIR/info/attributes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes rebase/am keep the original commit log message
better, even when it does not conform to "single line paragraph
to say what it does, then explain and defend why it is a good
change in later paragraphs" convention.
This change is a two-edged sword. While the earlier behaviour
would make such commit log messages more friendly to readers who
expect to get the birds-eye view with oneline summary formats,
users who primarily use git as a way to interact with foreign
SCM systems would not care much about the convenience of oneline
git log tools, but care more about preserving their own
convention. This changes their commits less useful to readers
who read them with git tools while keeping them more consistent
with the foreign SCM systems they interact with.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier these tools refused to create a reflog entry when the
message given by the calling Porcelain had a LF in it, partially
to keep the file format integrity of reflog file, which is
one-entry-per-line. These tools should not be dictating such a
policy.
Instead, let the codepath to write out the reflog entry worry
about the format integrity and allow messages with LF in them.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A reflog file is organized as one-line-per-entry records, and we
enforced the file format integrity by chomping the given message
at the first LF. This changes it to convert them to SP, which
is more in line with the --pretty=oneline format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* bs/lock:
Add test for symlinked configuration file updates.
use lockfile.c routines in git_commit_set_multivar()
fully resolve symlinks when creating lockfiles
* 'master' of git://repo.or.cz/git-gui: (50 commits)
git-gui: Minor refactoring of merge command line in merge support
git-gui: Use more modern looking icons in the tree browser
git-gui: Don't offer to stage hunks from untracked files
git-gui: Make sure remotes are loaded when picking revisions
git-gui: Use progress bar while resetting/aborting files
git-gui: Honor core.excludesfile when listing extra files
git-gui: Unify wording to say "to stage" instead of "to add"
git-gui: Don't kill modified commit message buffer with merge templates
git-gui: Remove usernames from absolute SSH urls during merging
git-gui: Format tracking branch merges as though they were pulls
git-gui: Cleanup bindings within merge dialog
git-gui: Replace merge dialog with our revision picker widget
git-gui: Show ref last update times in revision chooser tooltips
git-gui: Display commit/tag/remote info in tooltip of revision picker
git-gui: Save remote urls obtained from config/remotes setup
git-gui: Avoid unnecessary symbolic-ref call during checkout
git-gui: Refactor current branch menu items to make i18n easier
git-gui: Refactor diff popup into a procedure to ease i18n work
git-gui: Paper bag fix quitting crash after commit
git-gui: Clarify meaning of add tracked menu option
...
This is just a small code movement to cleanup how we generate
the command line for a merge. I'm only doing it to make the
next series of changes slightly more readable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a replacement of all of the icons in our tree browser
window, as the prior icons just looked too 1980s Tk-ish. The
icons used here are actually from a KDE themed look, so they
might actually be familiar to some users of git-gui.
Aside from using more modern looking icons we now have a special
icon for executable blobs, to make them stand out from the normal
non-executable blobs. We also denote symlinks now with a different
icon, so they stand out from the other types of objects in the tree.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user looks at an untracked file in our diff pane we used
to offer "Stage Hunk For Commit" in the context menu when they
right-clicked in that pane. The problem is we don't actually
have any diff hunks in untracked files, so there is nothing to
really select for staging. So we now grey out the menu item,
so the user cannot invoke it and think its broken when it does
not perform any useful action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are started for only a blame/browser/citool run we don't
usually initialize the list of remotes, or determine which refs
are tracking branches and which are local branch heads. This is
because some of that work is relatively expensive and is usually
not going to be needed if we are started only for a blame, or to
make a single commit.
However by not loading the remote configuration we were crashing
if the user tried to open a browser for another branch through
the Repository menu, as our load_all_heads procedure was unable
to decide which refs/heads/ items were actually local heads. We
now force all remote configuration data to be loaded if we have
not done so already and we are trying to create a revision mega
widget.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some people might prefer to be able to specify the find utility to
use.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The tree recursion behavior of git-diff may appear
inconsistent to the user because it depends on the format of
the patch as well as whether one is diffing between trees or
against the index.
Since git-diff is a porcelain wrapper for low-level diff
commands, it makes sense for its behavior to be consistent
no matter what is being diffed. This patch turns on
recursion in all cases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Resetting a large number of files on a slow filesystem can take
considerable time, just as switching branches in such a case can
take more than two seconds. We now take advantage of the progress
meter output by read-tree and show it in the main window status
bar, just like we do during checkout (branch switch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recent git versions have a git-status that honors the core.excludesfile
configuration option when it reports on untracked files. Unfortunately
I missed the introduction of this configuration option in the core
porcelain implementation, so it was not reflected here in git-gui.
Found and reported by Lars Noschinski <lars@public.noschinski.de>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Also, the warning message when clicking "Reset" is adapted to
the wording "Reset" rather than a confusion "Cancel commit?".
Signed-off-by: Christian Stimming <stimming@tuhh.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When using emacsclient or similar, a temporary buffer (file) named
'todo' could cause confusion with a pre-existing buffer of the same
name.
Signed-off-by: Seth Falcon <sethfalcon@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it possible to generate URLs with multivalued parameters in the
href() subroutine, via passing reference to array of values.
Example:
href(action=>"log", extra_options=>["--no-merges", "--first-parent"])
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Calling access(p, m) with p == NULL is not specified, so don't do that. On
GNU/Hurd systems doing so will result in a SIGSEGV.
Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Simplify and make more readable validation of 'opt' (extra options)
parameter, using exists($hash{key}) instead of grepping keys of a hash
for value.
Move 'opt' parameter to be the last (for now) in the URL.
Make use of '--no-merges' extra option ('opt') by adding "no merges"
RSS and Atom feeds to the HTML header. Note that alternate format
links in the RSS and Atom views do not use '--no-merges' option yet!
Adds tests for the 'opt' parameter to t9500-gitweb-standalone-no-errors.sh
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add S_ISGITLINK subroutine and S_IFGITLINK, S_IFINVALID constants.
Add support for "commit" (submodule) entries in the tree object to
mode_str ('m---------', following cgit), file_type and file_type_long
('submodule') subroutines.
There is only link to the history of submodule entry in the
supermodule (current repository) for now, because gitweb doesn't know
where to search for submodule repository objects.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Calling 'git-diff --name-status' will recursively show any
changes already, and it has for quite some time (at least as
far back as v1.4.1).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally, "apply --index" codepath was bolted on to the
"update working tree files and index, but then revert the
changes we make to the index except for added files so that we
do not forget about them" codepath, almost as an afterthought.
Because "apply --index" first prepares the final index state
upfront, "revert except the added paths" postprocessing does not
have to be done.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Two bugs that made the command practically unusable were fixed
with this.
- A stash created with a clean index does not have any
difference between the base tree and the index tree.
Trying to apply the diff between them to the index would
error out with "No changes". Even when the user asked to
unstash with --index, do not bother with --index action if
the base tree and the index tree match.
- After successfully performing the working tree merge, the
index was reloaded from an earlier state of unstashed index
with "read-tree"; this left all the paths cache dirty. By
moving the call to git-status after this read-tree, match the
cached stat information in the index.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier commit 7ab3cc70 fixed "stash clear" but broke save_stash,
because it forgot to make sure the reflog file exists before saving.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix bugs in the Find function
gitk: Wait for the window to become visible after creating it
[PATCH] gitk: Bind keyboard actions to the command key on Mac OS
[PATCH] gitk: Ignore ctrl-z as EOF on windows
gitk: Make the fake commit for the index changes green rather than magenta
gitk: Show changes in index and changes in working directory separately
When a squashing merge failed, the first commit would not be replaced,
due to "git reset --soft" being called with an unmerged index.
Noticed by Uwe Kleine-König.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At the moment this just has two entries, which allow you to add the file
that you clicked on to the list of filenames to highlight, or replace
the list with the file.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Changed git_commit_set_multivar() to use the routines provided by
lockfile.c to reduce code duplication and ensure consistent behavior.
Signed-off-by: Bradford C. Smith <bradford.carl.smith@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make the code for resolving symlinks in lockfile.c more robust as
follows:
1. Handle relative symlinks
2. recursively resolve symlink chains up to 5
[jc: removed lstat/stat calls to do things stupid way]
Signed-off-by: Bradford C. Smith <bradford.carl.smith@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If the user is in the middle of a merge and has already started to
modify their commit message we were losing the user's changes when
they pressed 'Rescan' after resolving issues or making changes in
the working directory.
The problem here was our background timer that saves the commit
message buffer. It marks the commit message buffer as not being
modified when it writes it out to disk, so during the rescan we
assumed the buffer should be replaced with what we read from the
MERGE_MSG file. So we now only read these files from .git if we
have a valid backup file. Since we clear it on commit this will
only have an impact while the user is actively editing the current
commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
With --strip-comments (or short -s), git stripspace now removes lines
beginning with a '#', too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This replaces "git-verify-tag.sh" with "builtin-verify-tag.c".
Testing relies on the "git tag -v" tests calling this command.
A temporary file is needed when calling to gpg, because git is
already creating detached signatures (gpg option -b) to sign tags
(instead of leaving gpg to add the signature to the file by itself),
and those signatures need to be supplied in a separate file to be
verified by gpg.
The program uses git_mkstemp to create that temporary file needed by
gpg, instead of the previously used "$GIT_DIR/.tmp-vtag", in order to
allow the command to be used in read-only repositories, and also
prevent other instances of git to read or remove the same file.
Signal SIGPIPE is ignored because the program sometimes was
terminated because that signal when writing the input for gpg.
The command now can receive many tag names to be verified.
Documentation is also updated here to reflect this new behaviour.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add it to the list in config.txt and explicitly say that the
--template option to git-commit overrides the configuration variable.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This fixes the problem reported by Brian Downing where searching for
a string that doesn't exist would give a Tcl error. The basic problem
was that we weren't reading the data for the last commit since it
wasn't terminated with a null. This effectively adds a null on the end
(if there isn't one already) to make sure we process the last commit.
This also makes the yellow background behind instances of the search
string appear more consistently, and fixes a bug where the "/" key
would just find the same commit again and again instead of advancing.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The NUL you see in "git log" (without diff) output are between records,
not at the end of each record.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When squashing, you no longer saw what the editor had to say to you
after commit 'Shut "git rebase -i" up when no --verbose was given'
(if you used a console based editor, at least).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If user's TMPDIR is insanely long, return negative after
setting errno to ENAMETOOLONG, pretending that the underlying
mkstemp() choked on a temporary file path that is too long.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In a working tree prepared in new-workdir (in contrib/), some files in .git/
directory are symbolic links to the original repository. The usual sequence of
lock-write-rename would break the symbolic link.
Ideally we should resolve relative symbolic link with maxdepth, but I do not
want to risk too elaborate patch before 1.5.3 release, so this is a minimum
and trivially obvious fix. new-workdir creates its symbolic links absolute,
and does not link from a symlinked workdir, so this fix should suffice for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code to find a more descriptive name given a commit in a
submodule were improved in bffe71f, but it forgot to remove the
older logic the patch replaced.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"module_name $path" function wants to look up a configuration
variable "submodule.<modulename>.path" whose value is $path, and
return the <modulename> found. "git-config --get-regexp" is the
natural thing to use for this, but (1) its value matching has an
unfortunate "feature" that takes leading '!' specially, and (2)
its output needs to be parsed with sed to extract <modulename>
part anyway.
This changes the call to "git-config --get-regexp" not to use
the value-regexp part, and moves the "pick the one whose value
is $path" part to the downstream sed.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent updates to snapshot code had a typo that broke the command line to
invoke underlying "git archive" command. This is a simple typofix for it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We say "SUBDIRECTORY_OK" but we did not chdir to toplevel; this
is fine as long as everything we use can be started from a
subdirectory, but unfortunately "merge-recursive" is not one of
the programs you can safely use from a subdirectory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we are being asked to merge a tracking branch that comes from a
remote repository accessed by the very common SSH URL format of
"user@host:/path/to/repo" then we really don't need the username
as part of the merge message, it only clutters up the history and
makes things more confusing. So we instead clip the username part
off if the local filesystem path is absolute, as its probably not
going to be an ambiguous URL even when it is missing the username.
On the other hand we cannot clip the username off if the URL is
not absolute, because in such cases (e.g. "user@host:myrepo") the
directory that the repository path is resolved in is relative to
the user's home directory, and the username becomes important.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are merging a tracking branch we know exactly what remote URL
that branch is fetched from, and what its name is on that remote
repository. In this case we can setup a merge message that looks
just like a standard `git-pull $remote $branch` operation by filling
out FETCH_HEAD before we start git-merge, and then run git-merge just
like git-pull does.
I think the result of this behavior is that merges look a lot nicer
when the came off of local tracking branches, because they no longer
say "commit 'origin/...'" to describe the commit being merged but
instead now mention the specific repository we fetched those commits
from.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we only support merging one branch we can offer the user
a better user interface experience by allowing them to select the
revision they want to merge through our revision picking widget.
This change neatly solves the problem of locating a branch out of
a sea of 200 tracking branches, and of dealing with very long branch
names that all have a common prefix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we can we now show the last modification date of a loose ref as
part of the tooltip information shown in the revision picker. This
gives the user an indication of when was the last time that the ref
was modified locally, and may especially be of interest when looking
at a tracking branch.
If we cannot find the loose ref file than we try to fallback on the
reflog and scan it for the date of the last record. We don't start
with the reflog however as scanning it backwards from the end is not
an easy thing to do in Tcl. So I'm being lazy here and just going
through the entire file, line by line. Since that is less efficient
than a single stat system call, its our fallback strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our revision chooser mega-widget now sets up tooltips for itself so
that it displays details about a commit (or a tag and the commit
it refers to) when the user mouses over that line in the filtered
ref list. If the item is from a remote tracking branch then we also
show the remote url and what branch on that remote we fetch from, so
the user has a clear concept of where that revision data originated.
To help the merge dialog I've also added a new constructor that
makes the dialog only offer unmerged revisions (those not in HEAD),
as this allows users to avoid performing merges only to get "Already
up to date" messages back from core Git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm storing the URLs of any pre-configured remote repositories
that we happen to come across so that we can later use these
URLs to show to the user in parts of the UI that might care.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Without argument the mode is toggled, which would do the wrong thing
if the file was already open.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CVS/Entries file can contain a line with single D to say "this
directory does not have any subdirectories". Do not get
confused with such an entry.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Test if the From: line contains "Mail System Internal Data" and if
it is, skip this mail.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These are useful in organizations that enforce particular formats
for commit messages, e.g., to specify bug IDs or test plans.
Use of the template is not enforced; it is simply used as the
initial content when the editor is invoked.
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you want to keep the reflogs around for a really long time, you should be
able to say so:
$ git config gc.reflogExpire never
Now it works, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When asking "git log -g --all", clearly you want to see only those refs
that do have reflogs, but you do not want it to fail, either.
So instead of die()ing, complain about it, but move on to the other refs.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If git cvsexportcommit is executed fast enough in sequence, the CVS
timestamps could end up being the same. CVS tries to fix this
by sleeping until the CPU clock changes seconds. Unfortunately,
the CPU clock and the file system clock are not necessarily the same, so
the timestamps could be the same anyway. When that happens CVS may not
recognize changed files and cvs will forget to commit some files.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Remove the two write-only fields executable and symlink from struct
tree_entry_list. Also replace usage of the field directory with
S_ISDIR checks on the mode field, and then remove this now obsolete
field, too. Noticed by David Kastrup.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On e.g. Ubuntu, dash is used as /bin/sh. Unlike bash it parses
commands like
a=$((echo stuff) | wc)
as an arithmetic expression while what we want is a subshell inside
a command substitution. Resolve the ambiguity by placing a space
between the two opening parentheses.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Improve error messages for snapshot format in git_snapshot:
distinguish between situation where snapshots are turned off, where
snapshot format ('sf') parameter is invalid, where given snapshot
format does not exist in %known_snapshot_formats hash, and where
gitweb was given unsupported snapshot format.
While at it, use first from all supported snapshots format as default,
if no snapshot format was provided.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we know which files have been modified, we can now run diff-index
or ls-files with a file list to refresh only the specified files
instead of the whole project.
This also allows proper refreshing of files upon add/delete/resolve,
instead of making assumptions about the new file state.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There have been several complaints against k.org's user-manual
page. The document is generated in ISO-8859-1 by the xsltproc
toolchain (I suspect this is because released docbook.xsl we use
has xsl:output element that says the output is ISO-8859-1) but
server delivers it with "charset=UTF-8", and all h*ll breaks
loose.
This attempts to force UTF-8 on the generating end.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The flag "no_walk" is present in struct rev_info since a long time, but
so far has been in use exclusively by "git show".
With this flag, you can see all your refs, ordered by date of the last
commit:
$ git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
which is extremely helpful if you have to juggle with a lot topic
branches, and do not remember in which one you introduced that uber
debug option, or simply want to get an overview what is cooking.
(Note that the "git log" invocation above does not output the same as
$ git show --abbrev-commit --pretty=oneline --decorate --all --quiet
since "git show" keeps the alphabetic order that "--all" returns the
refs in, even if the option "--date-order" was passed.)
For good measure, this also adds the "--do-walk" option which overrides
"--no-walk".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to take the first non-option argument as the name for the new
branch. This syntax is not extensible to support rewriting more than just
HEAD.
Instead, we now have the following syntax:
git filter-branch [<filter options>...] [<rev-list options>]
All positive refs given in <rev-list options> are rewritten. Yes,
in-place. If a ref was changed, the original head is stored in
refs/original/$ref now, for your inspecting pleasure, in addition to the
reflogs (since it is easier to inspect "git show-ref | grep original" than
to inspect all the reflogs).
This commit also adds the --force option to remove .git-rewrite/ and all
refs from refs/original/ before filtering.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch is literally
:%s/if \[ *\(.*[^ ]\) *\]/if test \1/
in vi, after making sure that the other instances of "[..]" are not
actually invocations of "test".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Up to now, git rebase -i was quite chatty, showing through all the
nice core programs it called.
Now it only shows a progress meter by default.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For some reason, I got this error message. Maybe it does not make sense,
but then we should not really try to convert the text when it is not
necessary.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the git log process returned an error immediately, we were
sometimes getting no main window and no error window displayed,
with the gitk process just hanging waiting for something. It appears
that the tkwait in show_error, which waits for the error window to
be destroyed, wasn't sufficient to allow the main window or the error
window to be mapped.
This adds a wait in the main startup code after the main window
has been created to wait until it is visible. This seems to fix the
problem.
Signed-off-by: Paul Mackerras <paulus@samba.org>
If we are checking out the branch we are already on then there is no
need to call symbolic-ref to update the HEAD pointer to the "new"
branch name, it is already correct.
Currently this situation does not happen very often, but it can be
seen in some workflows where the user always recreates their local
branch from a remote tracking branch and more-or-less ignores what
branch he/she is on right now. As they say, ignorance is bliss.
This case will however become a tad more common when we overload
checkout_op to actually also perform all of our merges. In that
case we will likely see that the branch we want to "checkout" is
the current branch, as we are actually just merging into it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The i18n team has also identified a rather ugly block of code in
git-gui that is used to make a pair of Repository menu items show
the current branch name. This code is difficult to convert to use
[mc ...] to lookup the translation, so I'm refactoring it into a
procedure.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The folks working on the i18n version of git-gui have had some
trouble trying to convert these English strings into [mc] calls
due to the double evaluation. Moving this block into a standard
procedure eliminates the double evaluation, making their work
easier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
My earlier introduction of the GITGUI_BCK file (which saves the user's
commit message buffer while they are typing it) broke the Quit function.
If the user makes a commit we delete the GITGUI_BCK file; if they then
immediately quit the application we fail to rename the GITGUI_BCK file
to GITGUI_MSG. This is because the file does not exist, but our flag
still says it does. The root cause is we did not unset the flag during
commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio recently pointed out on the mailing list that our "Add Existing"
feature is a lot like `git add -u`, which is generally described as
"(Re)Add Tracked Files". This came up during discussion of how to
translate "Add Existing" into Japanese, as the individual working on
the translation was not quite sure what the option meant and therefore
had some trouble selecting the best translation.
I'm changing the menu option to "Add Tracked Files To Commit" and the
button to "Add Tracked". This should help new users to better understand
the actions behind those GUI widgets.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Earlier commit which cleaned up snapshot support and introduced
support for multiple snapshot formats changed the format of
$feature{'snapshot'}{'default'} (gitweb configuration) and
gitweb.snapshot configuration variable (repository configuration).
It supported old gitweb.snapshot values of 'gzip', 'bzip2' and 'zip'
and tried to support, but failed to do that, old values of
$feature{'snapshot'}{'default'}; at least those corresponding to
old gitweb.snapshot values of 'gzip', 'bzip2' and 'zip', i.e.
['x-gzip', 'gz', 'gzip']
['x-bzip2', 'bz2', 'bzip2']
['x-zip', 'zip', '']
This commit moves legacy configuration support out of feature_snapshot
subroutine to separate filter_snapshot_fmts subroutine. The
filter_snapshot_fmts is used on result on result of
gitweb_check_feature('snapshot'). This way feature_snapshot deals
_only_ with repository config.
As a byproduct you can now use 'gzip' and 'bzip2' as aliases to 'tgz'
and 'tbz2' also in $feature{'snapshot'}{'default'}, not only in
gitweb.snapshot.
While at it do some whitespace cleanup: use tabs for indent, but
spaces for align.
Noticed-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Tested-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When looking for a lost blob, it is much nicer to be able to grep
through .git/lost-found/other/* than to write an inefficient loop
over the file names. So write the contents of the dangling blobs,
not their object names.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui already uses the command key for accelerators, but gitk has
never done so. I'm actually finding it very hard to move back and
forth between the two applications as git-gui is following the Mac
OS X conventions and gitk is not.
This trick is the same one that git-gui uses to determine which
key to bind actions to.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cygwin's Tcl is configured to honor any occurence of ctrl-z as an
end-of-file marker, while some commits in the git repository and possibly
elsewhere include that character in the commit comment. This causes gitk
ignore commit history following such a comment and incorrect graphs. This
change affects only Windows as Tcl on other platforms already has
eofchar == {}. This fixes problems noted by me and by Ray Lehtiniemi, and
the fix was suggested by Shawn Pierce.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The magenta was a bit close in color to the normal blue commits. This
makes them green instead as suggested by Linus.
Signed-off-by: Paul Mackerras <paulus@samba.org>
When a commit message doesn't have encoding information
and encoding output is utf-8 (default) then an useless
xstrdup() of commit message is done.
If we assume most of users live in an utf-8 world, this
useless copy is the common case.
Performance issue found with KCachegrind.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These options to log family were too long to type. Give them
shorter synonyms.
Fix the parsing of the long options while at it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we are trying to checkout a local branch which is matched to a
remote tracking branch, but the local branch is newer than the remote
tracking branch we actually just want to switch to the local branch.
The local branch is "Already up to date".
Unfortunately we tossed away the local branch's commit SHA-1 and kept
the remote tracking branch's SHA-1, which meant that the user lost the
local changes when we updated the working directory. At least we did
not update the local branch ref, so the user's data was still intact.
We now toss the tracking branch's SHA-1 and replace with the local
branch's SHA-1 before the checkout, ensuring that we pass of the right
tree to git-read-tree when we update the working directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This menu option of Tools/Migrate has been living inside of git-gui
as a local hack to support some coworkers of mine. It has no value
to anyone outside of my day-job team and never really should have
been in a release version of git-gui. So I'm pulling it out, so
that nobody else has to deal with this garbage.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
- Centralize knowledge about snapshot formats (mime types, extensions,
commands) in %known_snapshot_formats and improve how some of that
information is specified. In particular, zip files are no longer a
special case.
- Add support for offering multiple snapshot formats to the user so
that he/she can download a snapshot in the format he/she prefers.
The site-wide or project configuration now gives a list of formats
to offer, and if more than one format is offered, the "_snapshot_"
link becomes something like "snapshot (_tar.bz2_ _zip_)".
- If only one format is offered, a tooltip on the "_snapshot_" link
tells the user what it is.
- Fix out-of-date "tarball" -> "archive" in comment.
Alert for gitweb site administrators: This patch changes the format of
$feature{'snapshot'}{'default'} in gitweb_config.perl from a list of
three pieces of information about a single format to a list of one or
more formats you wish to offer from the set ('tgz', 'tbz2', 'zip').
Update your gitweb_config.perl appropriately. There was taken care
for old-style gitweb configuration to work as it used to, but this
backward compatibility works only for the values which correspond to
gitweb.snapshot values of 'gzip', 'bzip2' and 'zip', i.e.
['x-gzip', 'gz', 'gzip']
['x-bzip2', 'bz2', 'bzip2']
['x-zip', 'zip', '']
The preferred names for gitweb.snapshot in repository configuration
have also changed from 'gzip' and 'bzip2' to 'tgz' and 'tbz2', but
the old names are still recognized for compatibility.
Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A repeated call to read_sha1_file was not freing memory
when the buffer was allocated but returned size was zero.
Also, now the program does not allow many -F or -m options,
which was a bug too because it was not freing the memory
allocated for any previous -F or -m options.
Tests are provided for ensuring that only one option
-F or -m is given. Also, another test is shipped here,
to check that "git tag" fails when a non-existing file
is passed to the -F option, something that git-tag.sh
allowed creating the tag with an empty message.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the commit 'Add GIT_EDITOR environment and core.editor
configuration variables', this was done for the shell scripts.
Port it over to builtin-tag's version of launch_editor(), which
is just about to be refactored into editor.c.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Sometimes you want to squash more than two commits. Before this patch,
the editor was fired up for each squash command. Now the editor is
started only with the last squash command.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is actually just an underlying code improvement that has no user
visible component yet. UI improvements to actually fetch and merge via
an arbitrary remote with no tracking branches must still follow to make
this change useful for the end-user.
Our tracking branch specifications are a Tcl list of three components:
- local tracking branch name
- remote name/url
- remote branch name/tag name
This change just makes the first element optional. If it is an empty
string we will run the fetch, but have the value be saved only into the
special .git/FETCH_HEAD, where we can pick it up and use it for this one
time operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I totally missed this obvious optimization in the checkout code path.
If our current repository HEAD is actually at the commit we are moving
to, and we agreed to perform this switch earlier, then we have no files
to update in the working directory and any stale mtimes are simply not
of consequence right now. We can pretend like we ran a read-tree and
skip right into the post-read-tree work, such as updating the branch
and setting the symbolic-ref.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we are given a merge type we don't understand in checkout_op there
is probably a bug in git-gui somewhere that allowed this unknown merge
strategy to come into this part of the code path. We currently only
recognize three merge types ('none', 'ff' and 'reset') but are going
to be supporting more in the future. Rather than keep editing this
message I'm going with a very generic "Uh, we don't do that!" type of
error.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In both the ff and reset merge_types supported by checkout_op the
result is the same if the merge base of our target commit and the
existing commit is the existing commit: its a fast-forward as the
existing commit is fully contained in the target commit.
This minor cleanup in logic will make it easier to implement a
new kind of merge_type that actually merges the two trees with a
real merge strategy, such as git-merge-recursive.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I've decided to teach checkout_op how to perform more than just a
fast-forward and reset type of merge. This way we can also do a full
recursive merge even when we are recreating an existing branch from
a remote. To help with that process I'm saving the merge-base we
computed during the ff/reset/fail decision process, in case we need
it later on when we actually start a true merge operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A few users have been seeing crashes in Tk when using the undo key
binding to undo the last few keystroke events in the commit buffer.
Unfortunately that means the user loses their commit message and
must start over from scratch when the user restarts the process.
git-gui now saves the user's commit message buffer every couple of
seconds to a temporary file under .git (specifically .git/GITGUI_BCK).
At exit time we rename this file to .git/GITGUI_MSG if there is a
message, the file exists, and it is currently synchronized with the
Tk buffer. Otherwise we do our usual routine of saving the Tk buffer
to .git/GITGUI_MSG and delete .git/GITGUI_BCK, if it exists.
During startup we favor .git/GITGUI_BCK over .git/GITGUI_MSG. This
way a crash doesn't take out the user's message buffer but instead
will cause the user to lose only a few keystrokes. Most people do
not type more than 200 WPM, and with 30 possible saves per minute
we are unlikely to lose more than 7 words.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This replaces the script "git-tag.sh" with "builtin-tag.c".
The existing test suite for "git tag" guarantees the compatibility
with the features provided by the script version.
There are some minor changes in the behaviour of "git tag" here:
"git tag -v" now can get more than one tag to verify, like "git tag -d" does,
"git tag" with no arguments prints all tags, more like "git branch" does,
and "git tag -n" also prints all tags with annotations (without needing -l).
Tests and documentation were also updated to reflect these changes.
The program is currently calling the script "git verify-tag" for verify.
This can be changed porting it to C and calling its functions directly
from builtin-tag.c.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move @diff_opts declaration earlier, so that all gitweb options are
together (and not separated by %feature hash and some subroutines),
with the exception of $GITWEB_CONFIG which must be after all option
variables including %feature hash.
While at it, in the moved comment, note that diff option '-C' implies
'-M', instead of suggesting that '-M', '-C' is required.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These variables let you specify an editor that will be launched in
preference to the EDITOR and VISUAL environment variables. The order
of preference is GIT_EDITOR, core.editor, EDITOR, VISUAL.
[jc: added a test and config variable documentation]
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I'm working on refactoring the UI of the merge dialog, because as it
currently stands the dialog is absolutely horrible, especially when
you have 200+ branches available from a single remote system.
In that refactoring I plan on using the choose_rev widget to allow
the user to select exactly which branch/commit they want to merge.
However since that only selects a single commit I'm first removing
the code that supports octopus merges.
A brief consultation on #git tonight seemed to indicate that the
octopus merge strategy is not as useful as originally thought when
it was invented, and that most people don't commonly use them. So
making users fall back to the command line to create an octopus is
actually maybe a good idea here, as they might think twice before
they use it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we haven't yet loaded any commit information for a given line but
our tooltip timer fired and tried to draw the tooltip we shouldn't;
there is nothing to show.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a essentially a copy of Paul Mackerras encoding support from
gitk. I stole the code from gitk commit fd8ccbec4f, as Paul has
already done all of the hard work setting up this translation table.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Running global takes slightly longer than just accessing the variable
via its package name, especially if the variable is just only once in
the procedure, or isn't even used at all in the procedure. So this is
a minor cleanup for some of our commonly invoked procedures.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users who merge often may want to access the merge action quickly,
so we now bind M to the merge action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users shouldn't see this menu option if they startup a browser or
blame from the command line, especially if they are doing so on a
bare repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The new name is closer to the purpose of the function.
A NUL-terminated buffer makes things easier when callers need that.
Since the function returns only the memory written with data,
almost always allocating more space than needed because final
size is unknown, an extra NUL terminating the buffer is harmless.
It is not included in the returned size, so the function
remains working as before.
Also, now the function allows the buffer passed to be NULL at first,
and alloc_nr is now used for growing the buffer, instead size=*2.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://people.freedesktop.org/~hausmann/git-p4:
git-p4: Cleanup, used common function for listing imported p4 branches
git-p4: Fix upstream branch detection for submit/rebase with multiple branches.
git-p4: Cleanup, make listExistingP4Branches a global function for later use.
git-p4: input to "p4 files" by stdin instead of arguments
git-p4: use subprocess in p4CmdList
It was reported by Alex Riesen that "set -e" can break something as
trivial as "unset CDPATH" in bash.
So get rid of "set -e".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Changed filter for username in svn-authors file, so even 'user name' is accepted.
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At least in the kernel development community, we're generally slowly
converting to UTF-8 everywhere, and the old default of Latin1 in emails is
being supplanted by UTF-8, and it doesn't necessarily show up as such in
the mail headers (because, quite frankly, when people send patches
around, they want the email client to do as little as humanly possible
about the patch)
Despite that, it's often the case that email addresses etc still have
Latin1, so I've seen emails where this is a mixed bag, with Signed-off
parts being copied from email (and containing Latin1 characters), and the
rest of the email being a patch in UTF-8.
So this suggests a very natural change: if the target character set is
utf-8 (the default), and if the source already looks like utf-8, just
assume that it doesn't need any conversion at all.
Only assume that it needs conversion if it isn't already valid utf-8, in
which case we (for historical reasons) will assume it's Latin1.
Basically no really _valid_ latin1 will ever look like utf-8, so while
this changes our historical behaviour, it doesn't do so in practice, and
makes the default behaviour saner for the case where the input was already
in proper format.
We could do a more fancy guess, of course, but this correctly handled a
series of patches I just got from Andrew that had a mixture of Latin1 and
UTF-8 (in different emails, but without any character set indication).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command was recently updated to take message on the command line, but
this feature has not been documented.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In particular, when moving back to a commit without a given submodule
and then moving back forward to a commit with the given submodule,
we shouldn't complain that updating would lose untracked file in
the submodule, because git currently does not checkout subprojects
during superproject check-out.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For the html output we can use a stylesheet to make sure that the
listingblocks are presented in a monospaced font. For the manpages do
it manually by inserting a ".ft C" before and ".ft" after the block in
question.
In order for these roff commands to get through to the manpage they
have to be element encoded to prevent quoting.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't use git name-rev to locate the upstream git-p4 branch for rebase and submit but instead locate the branch by comparing the depot paths.
name-rev may produce results like wrongbranch~12 as it uses the first match.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
When "git checkout-index" checks out path A/B/C, it makes sure A
and A/B are truly directories; if there is a regular file or
symlink at A, we prefer to remove it.
We used to do this by catching an error return from mkdir(2),
and on EEXIST did unlink(2), and when it succeeded, tried
another mkdir(2).
Thomas Glanzmann found out the above does not work on Solaris
for a root user, as unlink(2) was so old fashioned there that it
allowed to unlink a directory.
As pointed out, this still doesn't guarantee that git won't call
"unlink()" on a directory (race conditions etc), but that's
fundamentally true (there is no "funlink()" like there is
"fstat()"), and besides, that is in no way git-specific (ie it's
true of any application that gets run as root).
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I've found that the class code makes it a whole lot easier to create
more complex GUI code, especially the dialogs. So before I make any
major improvements to the merge dialog's interface I'm going to first
switch it to use the class system, so the code is slightly cleaner.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Showing only five lines of heads/tags is not very useful to a user
when they have about 10 branches that match the filter expression.
The list is just too short to really be able to read easily, at
least not without scrolling up and down. Expanding the list out
to 10 really makes the revision picker easier to read and access,
as you can read the matching branches much more quickly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users who are new to Git may not realize that visualizing things in
a repository involves looking at history. Adding in a small amount
of text to the menu items really helps to understand what the action
might do, before you invoke it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now allow users to pick which commit they want to browse through
our revision picking mega-widget. This opens up in a dialog first,
and then opens a tree browser for that selected commit. It is a very
simple approach and requires minimal code changes.
I also clarified the language a bit in the Repository menu, to show
that these actions will access files. Just in case a user is not
quite sure what specific action they are looking for, but they know
they want some sort of file thing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like our blame subcommand the browser subcommand now accepts both
a revision and a path, just a revision or just a path. This way
the user can start the subcommand on any branch, or on any subtree.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A long time ago Linus Torvalds tried to run git-gui on a bare
repository to look at the blame viewer, but it failed to start
because we required that the user run us only from within a
working directory that had a normal git repository associated
with it.
This change relaxes that requirement so that you can start the
tree browser or the blame viewer against a bare repository. In
the latter case we do require that you provide a revision and a
pathname if we cannot find the pathname in the current working
directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
By moving our feature option determination up before we look for GIT_DIR
we can make a decision about whether or not we need a working tree up
front, before we look for GIT_DIR. A future change could then allow
us to start in a bare Git repository if we only need access to the ODB.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm moving the code related to looking to see if we should GC now
into a procedure closer to where it belongs, the database module.
This reduces our script by a few lines for the single commit case
(aka citool). But really it just is to help organize the code.
We now perform the check after we have been running for at least
1 second. This way the main window has time to open up and our
dialog (if we open it) will attach to the main window, instead of
floating out in no-mans-land like it did before on Mac OS X.
I had to use a wait of a full second here as a wait of 1 millisecond
made our console install itself into the main window. Apparently we
had a race condition with the console code where both the console and
the main window thought they were the main window.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some users may do odd things, like tag their own private version of
Git with an annotated tag such as 'testver', then compile that git
and try to use it with git-gui. In such a case `git --version` will
give us 'git version testver', which is not a numeric argument that
we can pass off to our version comparsion routine.
We now check that the cleaned up git version is a going to pass the
version comparsion routine without failure. If it has a non-numeric
component, or lacks at least a minor revision then we ask the user to
confirm they really want to use this version of git within git-gui.
If they do we shall assume it is git 1.5.0 and run with only the code
that will support.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Instead of running a full git-count-objects to count all of the loose
objects we can get a reasonably close approximation by counting the
number of files in the .git/objects/42 subdirectory. This works out
reasonably well because the SHA-1 hash has a fairly even distribution,
so every .git/objects/?? subdirectory should get a relatively equal
number of files. If we have at least 8 files in .git/objects/42 than it
is very likely there is about 8 files in every other directory, leaving
us with around 2048 loose objects.
This check is much faster, as we need to only perform a readdir of
a single directory, and we can do it directly from Tcl and avoid the
costly fork+exec.
All of the credit on how clever this is goes to Linus Torvalds; he
suggested using this trick in a post commit hook to repack every so
often.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have more than our desired number of objects and we try to
open the "Do you want to repack now?" dialog we cannot include a
-parent . argument if the main window has not been mapped yet.
On Mac OS X it appears this window isn't mapped right away, so we
had better hang avoid including it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Not every caller of 'git' or 'git_pipe' wants to use nice to lower the
priority of the process its executing. In many cases we may never use
the nice process to launch git. So we can avoid searching our $PATH
to locate a suitable nice if we'll never actually use it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-gui version check doesn't handle versions of the form
n.n.n.GIT which you can get by installing from an tarball produced by
git-archive.
Without this change you get an error of the form:
'Error in startup script: expected version number but got "1.5.3.GIT"'
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We haven't used bignum in rev-list from openssl nor elsewhere
for a long time. Also git-gui is now part of git.git itself,
and depends on wish.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This approach, suggested by Alex Riesen, bypasses the need for xargs-style
argument list handling. The handling in question looks broken in a corner
case with SC_ARG_MAX=4096 and final argument over 96 characters.
Signed-off-by: Scott Lamb <slamb@slamb.org>
Signed-off-by: Simon Hausmann <simon@lst.de>
This allows bidirectional piping - useful for "-x -" to avoid commandline
arguments - and is a step toward bypassing the shell.
Signed-off-by: Scott Lamb <slamb@slamb.org>
Signed-off-by: Simon Hausmann <simon@lst.de>
On Windows (which includes Cygwin) Tcl defaults to leaving the EOF
character of input file streams set to the ASCII EOF character, but
if that character were to appear in the data stream then Tcl will
close the channel early. So we have to disable eofchar on Windows.
Since the default is disabled on all platforms except Windows, we
can just disable it everywhere to prevent any sort of read problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
My prior change to allow git-gui to run with a version of Git
that was built from a working directory that had uncommitted
changes didn't account for the pattern starting with -, and
that confused Tcl.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user is running a 'dirty' version of git (one compiled in a
working directory with modified files) we want to just assume it
was a committed version, as we really only look at the part that
came from a real annotated tag anyway.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Renaming files with non-URI friendly characters caused
breakage when committing to DAV repositories (over http(s)).
Even if I try leaving out the $self->{url} from the return value
of url_path(), a partial (without host), unescaped path name
does not work.
Filenames for DAV repos need to be URI-encoded before being
passed to the library. Since this bug did not affect file://
and svn:// repos, the git-svn test library needed to be expanded
to include support for starting Apache with mod_dav_svn enabled.
This new test is not enabled by default, but can be enabled by
setting SVN_HTTPD_PORT to any available TCP/IP port on
127.0.0.1.
Additionally, for running this test, the following variables
(with defaults shown) can be changed for the suitable system.
The default values are set for Debian systems:
SVN_HTTPD_MODULE_PATH=/usr/lib/apache2/modules
SVN_HTTPD_PATH=/usr/sbin/apache2
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Move git-p4import.py and Documentation/git-p4import.txt into
a contrib/p4import directory. Add a README there directing
people to contrib/fast-import/git-p4 as a better alternative.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were many operations that did not notice and report errors
to the CVS client, which would have resulted in corrupt working
tree.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://repo.or.cz/git/fastimport:
Teach fast-import to recursively copy files/directories
Fix git-p4 on Windows to not use the Posix sysconf function.
Correct trivial typo in fast-import documentation
Make every builtin-*.c file #include "builtin.h".
Also takes care of some declaration/definition mismatches.
Signed-off-by: Peter Hagervall <hager@cs.umu.se>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some source material (e.g. Subversion dump files) perform directory
renames by telling us the directory was copied, then deleted in the
same revision. This makes it difficult for a frontend to convert
such data formats to a fast-import stream, as all the frontend has
on hand is "Copy a/ to b/; Delete a/" with no details about what
files are in a/, unless the frontend also kept track of all files.
The new 'C' subcommand within a commit allows the frontend to make a
recursive copy of one path to another path within the branch, without
needing to keep track of the individual file paths. The metadata
copy is performed in memory efficiently, but is implemented as a
copy-immediately operation, rather than copy-on-write.
With this new 'C' subcommand frontends could obviously implement an
'R' (rename) on their own as a combination of 'C' and 'D' (delete),
but since we have already offered up 'R' in the past and it is a
trivial thing to keep implemented I'm not going to deprecate it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add condition for Windows, since it doesn't support the os.sysconf module.
We hardcode the commandline limit to 2K, as that should work on most
Windows platforms.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
Acked-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We were previously sensitive to leading slashes in the fetch
lines and incorrectly writing them to the config if the user
used them (needlessly) in the command-line.
This fixes the issue and allows us to play nicely with legacy
configs that have leading slashes in fetch lines.
Thanks to Bradford Smith for figuring this out for me:
>
> This works:
>
> git-svn clone https://my.server.net/repos/path/ -Ttrunk/testing
> -ttags/testing -bbranches/testing testing
>
> This doesn't:
>
> git-svn clone https://my.server.net/repos/path -T/trunk/testing
> -t/tags/testing -b/branches/testing testing
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This script reads the existing commit log and .mailmap file,
and outputs author e-mail addresses that would map to more
than one names (most likely due to difference in the way they
are spelled, but some are due to ancient botched commits).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Replace uses of cat that do nothing but writing the contents of
a single file to another command via pipe.
[jc: Original patch from Josh was somewhat buggy and rewrote
"cat $file | wc -l" to "wc -l $file", but this one should be Ok.]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the previous behavior, "git-rm --cached" (without -f) had the same
restriction as "git-rm". This forced the user to use the -f flag in
situations which weren't actually dangerous, like:
$ git add foo # oops, I didn't want this
$ git rm --cached foo # back to initial situation
Previously, the index had to match the file *and* the HEAD. With
--cached, the index must now match the file *or* the HEAD. The behavior
without --cached is unchanged, but provides better error messages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now, git-log family can take full range of internally supported date format
to their --date=<format> argument. Document it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now we can use all internally supported date formats with
git log --date=<format>
syntax. Earlier, we only allowed relative/local/default.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These days, show_date() takes a date_mode parameter to specify
the output format, and a separate specialized function for dates
in E-mails does not make much sense anymore.
This retires show_rfc2822_date() function and make it just
another date output format.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support output of full ISO 8601 style dates in e.g. git log
and other places that use interpolation for formatting.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this change the commits will be left standalone, with
duplicated commit message.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes gitk show up to two fake commits when there are local changes
in the repository; one to represent the state of the index and one to
represent the state of the working directory. The commit representing
the working directory is colored red as before; the commit representing
the index state is colored magenta (as being between red and blue in
some sense).
Signed-off-by: Paul Mackerras <paulus@samba.org>
When using git-send-email.perl on a changeset that has:
Cc: <stable@kernel.org>
in the body of the description, and the Email::Valid perl module is
installed on the system, the email address will be deemed "invalid" for
some reason (Email::Valid isn't smart enough to handle this?) and
complain and not send the address the email.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When I added the "--" case to the code scanning the arguments, I missed
the fact that since the switch statement uses -regexp, the "--" case
will match any argument containing "--", e.g. "--all". This fixes it
by taking out the -regexp (since we don't actually need regular
expression matching) and adjusting the match strings.
A side effect of this is that previously any argument starting with
"-d" would be taken to indicate date mode; now the argument has to be
exactly "-d" if you want date mode.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Documentation based on description of commit 443f8338 which added
'-u'|'--untracked-files' option to git-status, and on git-runstatus(1)
man page.
Note that those options apply also to git-status.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document that '--message=<msg>' is long version of '-m <msg>' in
git-commit, and that '--no-checkout' is long version of '-n' in
git-clone.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add "Configuration" section to describe merge.summary
configuration variable (which is mentioned in git-fmt-merge-msg(1)
man page, but it is a plumbing command), and merge.verbosity
configuration variable (so there is a place to make reference
from "Environment Variables" section of git(7) man page) to the
git-merge(1) man page. Also describe GIT_MERGE_VERBOSITY
environment.
The configuration variable merge.verbosity and environment variable
GIT_MERGE_VERBOSITY were introduced in commit 8c3275ab, which also
documented configuration variable but not environment variable.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 5a235b5e was missing this little detail. Otherwise your pack
will explode.
Problem noted by Brian Downing.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Improve handling of -- and ambiguous arguments
gitk: Use git log and add support for --left-right
gitk: Fix bug causing "can't read commitrow(0,n)" error
[PATCH] gitk: Fix for tree view ending in nested directories
gitk: Remove the unused stopfindproc function
gitk: Fix bug in the anc_or_desc routine
gitk: Fix the find and highlight functions
Currently the only supported value is '--no-merges' for the 'rss', 'atom',
'log', 'shortlog' and 'history' actions, but it can be easily extended to allow
other parameters for other actions.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is necessary to make several editing functions work, like
C-u C-x v =
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After vainly searching the Documentation for how to follow renames, I
finally broke down and grepped the source. It would appear that Linus
didn't add write and docs for this feature when he wrote it. The
following patch rectifies that, hopefully sparing future users from
resorting to the source code.
Signed-off-by: Steven Walter <stevenrwalter@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The delta depth doesn't have to be stored in the global object array
structure since it is only used during the deltification pass.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds an option (--window-memory=N) and configuration variable
(pack.windowMemory = N) to limit the memory size of the pack-objects
delta search window. This works by removing the oldest unpacked objects
whenever the total size goes above the limit. It will always leave
at least one object, though, so as not to completely eliminate the
possibility of computing deltas.
This is an extra limit on top of the normal window size (--window=N);
the window will not dynamically grow above the fixed number of entries
specified to fill the memory limit.
With this, repacking a repository with a mix of large and small objects
is possible even with a very large window.
Cleaner and correct circular buffer handling courtesy of Nicolas Pitre.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Split out the nnn{k,m,g} parsing code from git_config_int into
git_parse_long, so command-line parameters can enjoy the same
functionality. Also add get_parse_ulong for unsigned values.
Make git_config_int use git_parse_long, and add get_config_ulong
as well.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Delta indices, at least on 64-bit platforms, tend to be larger than
the actual uncompressed data. As such, keeping track of this storage
is important if you want to successfully limit the memory size of your
pack window.
Squirrel away the total allocation size inside the delta_index struct,
and add an accessor "sizeof_delta_index" to access it.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a new try_delta heuristic. Don't bother trying to make a delta if
the target object size is much smaller (currently 1/32) than the source,
as it's very likely not going to get a match. Even if it does, you will
have to read at least 32x the size of the new file to reassemble it,
which isn't such a good deal. This leads to a considerable performance
improvement when deltifying a mix of small and large files with a very
large window, because you don't have to wait for the large files to
percolate out of the window before things start going fast again.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already apply a bias on the initial delta attempt with max_size being
a function of the base object depth. This has the effect of favoring
shallower deltas even if deeper deltas could be smaller, and therefore
creating a wider delta tree (see commits 4e8da195 and c3b06a69).
This principle should also be applied to all delta attempts for the same
object and not only the first attempt. With this the criteria for the
best delta is not only its size but also its depth, so that a shallower
delta might be selected even if it is larger than a deeper one. Even if
some deltas get larger, they allow for wider delta trees making the
depth limit less quickly reached and therefore better deltas can be
subsequently found, keeping the resulting pack size even smaller.
Runtime access to the pack should also benefit from shallower deltas.
Testing on different repositories showed slighter faster repacks,
smaller resulting packs, and a much nicer curve for delta depth
distribution with no more peak at the maximum depth level.
Improvements are even more significant with smaller depth limits.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit 'git-gui/master': (36 commits)
git-gui: Change prior tree SHA-1 verification to use git_read
git-gui: Include a space in Cygwin shortcut command lines
git-gui: Use sh.exe in Cygwin shortcuts
git-gui: Paper bag fix for Cygwin shortcut creation
git-gui: Improve the Windows and Mac OS X shortcut creators
git-gui: Teach console widget to use git_read
git-gui: Perform our own magic shbang detection on Windows
git-gui: Treat `git version` as `git --version`
git-gui: Assume unfound commands are known by git wrapper
git-gui: Correct gitk installation location
git-gui: Always use absolute path to all git executables
git-gui: Show a progress meter for checking out files
git-gui: Change the main window progress bar to use status_bar
git-gui: Extract blame viewer status bar into mega-widget
git-gui: Allow double-click in checkout dialog to start checkout
git-gui: Default selection to first matching ref
git-gui: Unabbreviate commit SHA-1s prior to display
git-gui: Refactor branch switch to support detached head
git-gui: Refactor our ui_status_value update technique
git-gui: Better handling of detached HEAD
...
* maint:
GIT 1.5.2.4
Teach read-tree 2-way merge to ignore intermediate symlinks
git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
git-gui: Don't linewrap within console windows
git-gui: Correct ls-tree buffering problem in browser
git-gui: Skip nicknames when selecting author initials
git-gui: Ensure windows shortcuts always have .bat extension
git-gui: Include a Push action on the left toolbar
git-gui: Bind M1-P to push action
git-gui: Don't bind F5/M1-R in all windows
git-gui: Unlock the index when cancelling merge dialog
git-gui: properly popup error if gitk should be started but is not installed
This makes gitk more consistent with git rev-list and git log in its
handling of arguments that could be either a revision or a filename;
now gitk displays an error message and quits, rather than treating it
as a revision and getting an error in the underlying git log. Now
gitk always passes "--" to git log even if no filenames are being
specified.
It also makes gitk display errors in invoking git log in a window
rather than on stderr, and makes gitk stop looking for a -d flag
when it sees a "--" argument.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Earlier in 16a4c61, we taught "read-tree -m -u" not to be
confused when switching from a branch that has a path frotz/filfre
to another branch that has a symlink frotz that points at xyzzy/
directory. The fix was incomplete in that it was still confused
when coming back (i.e. switching from a branch with frotz -> xyzzy/
to another branch with frotz/filfre).
This fix is rather expensive in that for a path that is created
we would need to see if any of the leading component of that
path exists as a symbolic link in the filesystem (in which case,
we know that path itself does not exist, and the fact we already
decided to check it out tells us that in the index we already
know that symbolic link is going away as there is no D/F
conflict).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
git-gui: Don't linewrap within console windows
git-gui: Correct ls-tree buffering problem in browser
git-gui: Skip nicknames when selecting author initials
git-gui: Ensure windows shortcuts always have .bat extension
git-gui: Include a Push action on the left toolbar
git-gui: Bind M1-P to push action
git-gui: Don't bind F5/M1-R in all windows
git-gui: Unlock the index when cancelling merge dialog
git-gui: properly popup error if gitk should be started but is not installed
This cat-file was done on maint, where we did not have git_read
available to us. But here on master we do, so we should make
use of it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
From Johannes Sixt <J.Sixt@eudaptics.com>:
> It seems that MSYS's wish does some quoting for Bourne shells,
> in particular, escape the first '{' of the "^{tree}" suffix, but
> then it uses cmd.exe to run "git rev-parse". However, cmd.exe does
> not remove the backslash, so that the resulting rev expression
> ends up in git's guts as unrecognizable garbage: rev-parse fails,
> and git-gui hickups in a way that it must be restarted.
Johannes originally submitted a patch to this section of commit.tcl
to use `git rev-parse $PARENT:`, but not all versions of Git will
accept that format. So I'm just taking the really simple approach
here of scanning the first line of the commit to grab its tree.
About the same cost, but works everywhere.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
An implementation easier to call from builtins. It is designed
to be used from the upcoming builtin-tag.c and builtin-commit.c,
because both need to remove unwanted spaces from messages.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This tool will print vaguely pretty information about a pack. It
expects the output of "git-verify-pack -v" as input on stdin.
$ git-verify-pack -v | packinfo.pl
See the documentation in the script (contrib/stats/packinfo.pl)
for more information.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch cleans up some complicated code, and replaces it with a
cleaner version, using code from remote.[ch], which got extended a
little in the process. This also enables us to fix two cases:
The earlier "fix" to setup tracking only when the original ref started
with "refs/remotes" is wrong. You are absolutely allowed to use a
separate layout for your tracking branches. The correct fix, of course,
is to set up tracking information only when there is a matching
remote.<nick>.fetch line containing a colon.
Another corner case was not handled properly. If two remotes write to
the original ref, just warn the user and do not set up tracking.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function for_each_remote() does exactly what the name
suggests.
The function remote_find_tracking() was extended to be able to
search remote refs for a given local ref. The caller sets
either src or dst (but not both) in the refspec parameter, and
remote_find_tracking() will fill in the other and return 0.
Both changes are required for the next step: simplification of
git-branch's --track functionality.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests check the syntax for the git tag -n option
and its output when one, none or many lines of the
message are requested.
Also this commit adds a missing && in the test
that checks the sorted output of git tag -l.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previous tests only had paragraphs of one line. This commit adds some
tests to check when many consecutive text lines are given.
Also, it adds tests for checking that many lines between paragraphs are
correctly reduced to one when there are tabs and spaces in those lines.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Moved some tests to another test_expect_success block.
Many tests now reuse the same "expect" file. Also replacing
many printf "" >expect with one >expect instruction.
Added missing && which concatenated tests in some
test_expect_success blocks.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you say --cherry-pick, you do not want to see patches which are
in the upstream. If you specify paths with that, what you usually
expect is that only those parts of the patches are looked at which
actually touch the given paths.
With this patch, that expectation is met.
Noticed by Sam Vilain.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For compatibility reasons, "git init --shared=all" does not write
"all" into the config, but a number. In the shared setup, you
really have to support even older clients on the _same_ repository.
But git_config_perm() did not pick up on it.
Also, "git update-server-info" failed to pick up on the shared
permissions.
This patch fixes both issues, and adds a test to prove it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: martin f krafft <madduck@madduck.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows gitweb users to set $projects_list_description_width
in their gitweb.conf to determine how many characters of a project
description are displayed before being truncated with an ellipsis.
Signed-off-by: Michael Hendricks <michael@ndrix.org>
Acked-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Functions for managing ref lists were named based on their use in
match_refs (for push). For fetch, they will be used for other purposes, so
rename them as a separate patch to make the future code readable.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of open-coding allocation wherever it happens, have a function.
Also, add a function to free a list of refs, which we currently never
actually do.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 334d28ae factored out git.o as an intermediate stage between
git.c and git$X. However:
- It left some no-longer-relevant flags in the rule for git$X.
- It failed to replace git$X with git.o in the list of files that
record GIT_VERSION. This broke incorporation of a changed
GIT_VERSION into git$X because, when GIT_VERSION changes, git.o isn't
remade and git$X is relinked from the git.o that still contains the
old GIT_VERSION.
This patch removes the irrelevant flags and fixes incorporation of a
changed GIT_VERSION into git$X.
Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Two-file merges were rare enough that they were dropped outside of the
radar. This fix is a trivial change to builtin-rerere.c::find_conflict().
It is still sane to insist that we do not do rerere for symlinks, and
require to have stages #2 and #3, but we can drop the requirement to have
stage #1. rerere does not use information from there anyway.
This fix is from Junio, together with two tests to verify that it works
as expected.
Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some source material (e.g. Subversion dump files) perform directory
renames without telling us exactly which files in that subdirectory
were moved. This makes it hard for a frontend to convert such data
formats to a fast-import stream, as all the frontend has on hand
is "Rename a/ to b/" with no details about what files are in a/,
unless the frontend also kept track of all files.
The new 'R' subcommand within a commit allows the frontend to
rename either a file or an entire subdirectory, without needing to
know the object's SHA-1 or the specific files contained within it.
The rename is performed as efficiently as possible internally,
making it cheaper than a 'D'/'M' pair for a file rename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The 'D' subcommand within a commit can also delete a directory
recursively. This wasn't clear in the prior version of the
documentation, leading to a question on the mailing list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we are trying to execute /bin/sh we know it must be a real
Windows executable and thus ends with the standard .exe suffix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We cannot execute the git directory, it is not a valid Tcl command
name. Instead we just want to pass it as an argument to our sq
proc.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we get more than 80 characters of text in a single line odds
are it is output from git-fetch or git-push and its showing a
lot of detail off to the right edge that is not so important to
the average user. We still want to make sure we show everything
we need, but we can get away with that information being off to
the side with a horizontal scrollbar.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our file browser was showing bad output as it did not properly buffer
a partial record when read from `ls-tree -z`. This did not show up on
my Mac OS X system as most trees are small, the pipe buffers generally
big and `ls-tree -z` was generally fast enough that all data was ready
before Tcl started to read. However on my Cygwin system one of my
production repositories had a large enough tree and packfile that it
took a couple of pipe buffers for `ls-tree -z` to complete its dump.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is based on patches from Linus Torvalds and Junio Hamano, so the
ideas here are theirs.
This makes gitk use "git log -z --pretty=raw" instead of "git rev-list"
to generate the list of commits, and also makes it grok the "<" and ">"
markers that git log (and git rev-list) output with the --left-right
flag to indicate which side of a symmetric diff a commit is reachable
from. Left-side commits are drawn with a triangle pointing leftwards
instead of a circle, and right-side commits are drawn with a triangle
pointing rightwards. The commitlisted list is used to store the
left/right information as well as the information about whether each
commit is on the boundary.
Signed-off-by: Paul Mackerras <paulus@samba.org>
In commit 66e46f37de I changed gitk to
store ids in rowrangelist and idrowranges rather than row numbers,
but I missed two places in the layouttail procedure. This resulted
in occasional errors such as the "can't read "commitrow(0,8572)":
no such element in array" error reported by Mark Levedahl. This fixes
it by using the id rather than the row number.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Unroll the prefix stack when assigning treeheights when leaving
proc treeview. Previously, when the ls-tree output ended in
multiple nested directories (for instance in a repository with a
single file "foo/bar/baz"), $treeheight("foo/bar/") was assigned
twice, and $treeheight("foo/") was never assigned. This led to
an error when expanding the "foo" directory in the gitk treeview.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
We now embed any GIT_* and SSH_* environment variables as well as
the path to the git wrapper executable into the Mac OS X .app file.
This should allow us to restore the environment properly when
we restart.
We also try to use proper Bourne shell single quoting when we can,
as this avoids any sort of problems that might occur due to a path
containing shell metacharacters.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we are pretty strict about setting up own absolute paths to
any git helper (saving a marginal runtime cost to resolve the tool)
we can do the same in our console widget by making sure all console
execs go through git_read if they are a git subcommand, and if not
make sure they at least try to use the Tcl 2>@1 IO redirection if
possible, as it should be faster than |& cat.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Change "try_delta" so that if it finds a delta that has the same size
but shallower depth than the existing delta, it will prefer the
shallower one. This makes certain delta trees vastly less deep.
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we cannot locate a .exe for a git tool that we want to run than
it may just be a Bourne shell script as these are popular in Git.
In such a case the first line of the file will say "#!/bin/sh" so
a UNIX kernel knows what program to start to parse and run that.
But Windows doesn't support shbang lines, and neither does the Tcl
that comes with Cygwin.
We can pass control off to the git wrapper as that is a real Cygwin
program and can therefore start the Bourne shell script, but that is
at least two fork+exec calls to get the program running. One to do
the fork+exec of the git wrapper and another to start the Bourne shell
script. If the program is run multiple times it is rather expensive
as the magic shbang detection won't be cached across executions.
On MinGW/MSYS we don't have the luxury of such magic detection. The
MSYS team has taught some of this magic to the git wrapper, but again
its slower than it needs to be as the git wrapper must still go and
run the Bourne shell after it is called.
We now attempt to guess the shbang line on Windows by reading the
first line of the file and building our own command line path from
it. Currently we support Bourne shell (sh), Perl and Python. That
is the entire set of shbang lines that appear in git.git today.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We know that the version subcommand of git is special. It does not
currently have an executable link installed into $gitexecdir and we
therefore would never match it with one of our file exists tests.
So we forward any invocations to it directly to the git wrapper, as
it is a builtin within that executable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we simplify history due to path limits, the parents list
for a rewritten commit can end up having duplicates. Instead of
filtering them out in the output codepath like earlier commit
88494423 did, remove them much earlier, when the parent
information actually gets rewritten.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If we cannot locate a command in $gitexecdir on our own then it may
just be because we are supposed to run it by `git $name` rather than
by `git-$name`. Many commands are now builtins, more are likely to
go in that direction, and we may see the hardlinks in $gitexecdir go
away in future versions of git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The master Makefile in git.git installs gitk into bindir, not
gitexecdir, which means gitk is located as a sibling of the git
wrapper and not as though it were a git helper tool.
We can also avoid some Tcl concat operations by letting eval do
all of the heavy lifting; we have two proper Tcl lists ($cmd and
$revs) that we are joining together and $revs is currently never
an empty list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than making the C library search for git every time we want
to execute it we now search for the main git wrapper at startup, do
symlink resolution, and then always use the absolute path that we
found to execute the binary later on. This should save us some
cycles, especially on stat challenged systems like Cygwin/Win32.
While I was working on this change I also converted all of our
existing pipes ([open "| git ..."]) to use two new pipe wrapper
functions. These functions take additional options like --nice
and --stderr which instructs Tcl to take special action, like
running the underlying git program through `nice` (if available)
or redirect stderr to stdout for capture in Tcl.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Sometimes switching between branches can take more than a second or
two, in which case `git checkout` would normally have shown a small
progress meter to the user on the terminal to let them know that we
are in fact working, and give them a reasonable idea of when we may
finish.
We now do obtain that progress meter from read-tree -v and include
it in our main window's status bar. This allows users to see how
many files we have checked out, how many remain, and what percentage
of the operation is completed. It should help to keep users from
getting bored during a large checkout operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we have a fancy status bar mega-widget we can reuse that
within our main window. This opens the door for implementating
future improvements like a progress bar.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our blame viewer has had a very fancy progress bar at the bottom of
the window that shows the current status of the blame engine, which
includes the number of lines completed as both a text and a graphical
meter. I want to reuse this meter system in other places, such as
during a branch switch where read-tree -v can give us a progress
meter for any long-running operation.
This change extracts the code and refactors it as a widget that we
can take advantage of in locations other than in the blame viewer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user double clicks a branch in the checkout dialog then they
probably want to start the checkout process on that branch. I found
myself doing this without realizing it, and of course it did nothing
as there was no action bound to the listbox's Double-Button-1 event
handler. Since I did it without thinking, others will probably also
try, and expect the same behavior.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have specifications listed in our revision picker mega-widget
then we should default the selection within that widget to the first
ref available. This way the user does not need to use the spacebar
to activate the selection of a ref within the box; instead they can
navigate up/down with the arrow keys and be done with it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the end-user feeds us an abbreviated SHA-1 on the command line for
`git gui browser` or `git gui blame` we now unabbreviate the value
through `git rev-parse` so that the title section of the blame or
browser window shows the user the complete SHA-1 as Git determined
it to be.
If the abbreviated value was ambiguous we now complain with the
standard error message(s) as reported by git-rev-parse --verify,
so that the user can understand what might be wrong and correct
their command line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a major rewrite of the way we perform switching between
branches and the subsequent update of the working directory. Like
core Git we now use a single code path to perform all changes: our
new checkout_op class. We also use it for branch creation/update
as it integrates the tracking branch fetch process along with a
very basic merge (fast-forward and reset only currently).
Because some users have literally hundreds of local branches we
use the standard revision picker (with its branch filtering tool)
to select the local branch, rather than keeping all of the local
branches in the Branch menu. The branch menu listing out all of
the available branches is simply not sane for those types of huge
repositories.
Users can now checkout a detached head by ticking off the option
in the checkout dialog. This option is off by default for the
obvious reason, but it can be easily enabled for any local branch
by simply checking it. We also detach the head if any non local
branch was selected, or if a revision expression was entered.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since the external interface seems to have stabilized for this
new feature, let's document it properly.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
user-manual: fix directory name in git-archive example
user-manual: more explanation of push and pull usage
tutorial: Fix typo
user-manual: grammar and style fixes
It seems that not everybody expects a difference between keeping a "pick"
line, and deleting it. So be a bit more explicit about that, with all
capitals to get the attention.
Noticed by vmiklos on IRC.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After interruption, be that an edit, or a conflicting commit, reset
the variables VERBOSE, STRATEGY and PRESERVE_MERGES, so that the
user does not have to respecify them with "rebase --continue".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "while" loop in the function do_rest is not supposed to ever be
exited. Instead, the function do_one checks if there is nothing left,
and cleans up and exits if that is the case. So the diffstat code
belongs there.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Non-interactive rebase requires the working tree to be clean, but
applies what is in the index without requiring the user to do it
herself. Imitate that, but (since we are interactive, after all)
fire up an editor with the commit message.
It also fixes a subtle bug: a forgotten "continue" was removed, which
led to an infinite loop when continuing without remaining patches.
Both issues noticed by Frank Lichtenheld.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When commit ed93b449 changed the script so that it does not
touch untracked working tree file, we forgot that we still
needed to resolve the index entry (otherwise they are left
unmerged).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If requested to signoff a commit, don't add another Signed-off-by: line
to the commit message if the exact same line is already there.
This was noticed and requested by Josh Triplett through
http://bugs.debian.org/430851
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio noticed that switching on autosetupmerge unilaterally started
cluttering the config for local branches. That is not the original
intention of branch.autosetupmerge, which was meant purely for
convenience when branching off of remote branches, but that semantics
got lost somewhere.
If you still want that "new" behavior, you can switch
branch.autosetupmerge to the value "all". Otherwise, it is interpreted
as a boolean, which triggers setting up defaults _only_ when branching
off of a remote branch, i.e. the originally intended behavior.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier when we read a tree into a temporary index, we read it
from scratch. Start from the current index and use read-tree -m
to preserve cached stat information as much as possible, in
order to speed up "git add -u". This makes "git stash" usable
in a source tree of nontrivial size.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I'm really starting to dislike global variables. The ui_status_value
global varible is just one of those that seems to appear in a lot of
code and in many cases we didn't even declare it "global" within the
proc that updates it so we haven't always been getting all of the
updates we expected to see.
This change introduces two new global procs:
ui_status $msg; # Sets the status bar to show $msg.
ui_ready; # Changes the status bar to show "Ready."
The second (special) form is used because we often update the area
with this message once we are done processing a block of work and
want the user to know we have completed it.
I'm not fixing the cases that appear in lib/branch.tcl right now
as I'm actually in the middle of a huge refactoring of that code
to support making a detached HEAD checkout.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the current branch is not a symbolic-ref that points to a
name in the refs/heads/ namespace we now just assume that the
head is a detached head. In this case we return the special
branch name of HEAD rather than empty string, as HEAD is a
valid revision specification and the empty string is not.
I have also slightly improved the current-branch function by
using string functions to parse the symbolic-ref data. This
should be slightly faster than using a regsub. I think the
code is clearer too.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user is creating a new local branch and has selected to use
a tracking branch as the starting revision they probably want to
make sure they are using the absolute latest version available of
that branch.
We now offer a checkbox "Fetch Tracking Branch" (on by default)
that instructs git-gui to run git-fetch on just that one branch
before resolving the branch name into a commit SHA-1 and making
(or updating) the local branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In some workflows users will want to almost always just create a new
local branch that matches a remote branch. In this type of workflow
it is handy to have the new branch dialog default to "Match Tracking
Branch" and "Starting Revision"-Tracking Branch", with the focus in
the branch filter field. This can save users working on this type
of workflow at least two mouse clicks every time they create a new
local branch or switch to one with a fast-forward.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When trying to create a branch from a tag most people are looking
for a recent tag, not one that is ancient history. Rather than
sorting tags by their string we now sort them by taggerdate, as
this places the recent tags at the top of the list and the very
old ones at the end. Tag date works nicely as an approximation
of the actual history order of commits.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
One of my production repositories has hundreds of remote tracking
branches. Trying to navigate these through a popup menu is just
not possible. The list is far larger than the screen and it does
not scroll fast enough to efficiently select a branch name when
trying to create a branch or delete a branch.
This is major rewrite of the revision chooser mega-widget. We
now use a single listbox for all three major types of named refs
(heads, tracking branches, tags) and a radio button group to pick
which of those namespaces should be shown in the listbox. A filter
field is shown to the right allowing the end-user to key in a glob
specification to filter the list they are viewing. The filter is
always taken as substring, so we assume * both starts and ends the
pattern the user wanted but otherwise treat it as a glob pattern.
This new picker works out really nicely. What used to take me at
least a minute to find and select a branch now takes mere seconds.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user elects to create a local branch that has the same name
as an existing branch and we can fast-forward the local branch to
the selected revision we might as well do the fast-forward for the
user, rather than making them first switch to the branch then merge
the selected revision into it. After all, its really just a fast
forward. No history is lost. The resulting branch checkout may
also be faster if the branch we are switching from is closer to
the new revision.
Likewise we also now allow the user to reset the local branch if
it already exists but would not fast-forward. However before we
do the actual reset we tell the user what commits they are going to
lose by showing the oneline subject and abbreviated sha1, and we also
let them inspect the range of commits in gitk.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some workflows have users create a local branch that matches a remote
branch they have fetched from another repository. If the user wants
to push their changes back to that remote repository then they probably
want to use the same branch name locally so that git-gui's push dialog
can setup the push refspec automatically.
To prevent typos with the local branch name we now offer an option to
use the remote tracking branch name as the new local branch name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In the next change I want to let the user create their local branch
name to match the remote branch name, so that the existing push
dialog can push the branch back up to the remote repository without
needing to do any sort of remapping. To do that we need to know
exactly what branch name the remote system is using.
So all_tracking_branches returns a list of specifications, where
each specification is itself a list of:
- local ref name (destination we fetch into)
- remote name (repository we fetch from)
- remote ref name (source ref we fetch from)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most people using Git 1.5.x and later are using the newer style
of remotes layout where all of their tracking branches are in
refs/remotes and refs/heads contains only the user's own local
branches.
In such a situation we can avoid calling is_tracking_branch
for each head we are considering because we know that all of
the heads must be local branches if no fetch option or Pull:
line maps a branch into that namespace.
If however any remote maps a remote branch into a local
tracking branch that resides in refs/heads we do exactly
what we did before, which requires scanning through all
fetch lines in case any patterns are matched.
I also switched some regexp/regsub calls to string match
as this can be a faster operation for prefix matching.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A simple refactoring of the delete branch dialog to allow use of
the class construct to better organize the code and to reuse the
revision selection code of our new choose_rev mega-widget.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This rather large change pulls the "Starting Revision" part of the
new branch dialog into a mega widget that we can use anytime we
need to select a commit SHA-1. To make use of the mega widget I
have also refactored the branch dialog to use the class system,
much like the delete remote branch dialog already does.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Its handy to be able to ask an object to do something for you by
handing it a subcommand. For example if we want to get the value
of an object's private field the object could expose a method that
would return that value. Application level code can then invoke
"$inst get" to perform the method call.
Tk uses this pattern for all of its widgets, so we'd certainly
like to use it for our own mega-widgets that we might develop.
Up until now we haven't needed such functionality, but I'm working
on a new revision picker mega-widget that would benefit from it.
To make this work we have to change the definition of $this to
actually be a procedure within the namespace. By making $this a
procedure any caller that has $this can call subcommands by passing
them as the first argument to $this. That subcommand then needs
to call the proper subroutine.
Placing the dispatch procedure into the object's variable namespace
ensures that it will always be deleted when the object is deleted.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our blame viewer only grabbed the first initial of the git.git
author string "Simon 'corecode' Schubert". Here the problem was we
looked at Simon, pulled the S into the author initials, then saw
the single quote as the start of the next name and did not like
this character as it was not an uppercase letter.
We now skip over single quoted nicknames placed within the author
name field and grab the initials following it. So the above name
will get the initials SS, rather than just S.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The blame window shows "who wrote the piece originally" and "who
moved it there" in two columns. In order to identify the former
more correctly, it helps to use the new -w option.
[sp: Minor change to only enable -w if underlying git >= 1.5.3]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some newer features of git-gui want to rely on features that are
new to Git 1.5.3. Since they were added as part of the 1.5.3
development series we cannot use those features with versions of
Git that are older than 1.5.3, such as from the stable 1.5.2 series.
We introduce [git-version >= 1.5.3] to allow the caller to get a
response of 0 if the current version of git is < 1.5.3 and 1 if
the current version of git is >= 1.5.3. This makes it easy to
setup conditional code based upon the version of Git available to
us at runtime.
Instead of parsing the version text by hand we now use the Tcl
[package vcompare] subcommand to compare the two version strings.
This works nicely, as Tcl as already done all of the hard work
of doing version comparsions. But we do have to remove the Git
specific components such as the Git commit SHA-1, commit count and
release candidate suffix (rc) as we want only the final release
version number.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently a user on the mailing list complained that they'd read the
manual but couldn't figure out how to keep a couple private repositories
in sync. They'd tried using push, and were surprised by the effect.
Add a little text in an attempt to make it clear that:
- Pushing to a branch that is checked out will have odd results.
- It's OK to synchronize just using pull if that's simpler.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
- "method of" is vulgar, "method for" is nicer
- "recovery" becomes "recovering" from Steve Hoelzer's original version
of this patch
- "if you want" is nicer as "if you wish"
- "you may" should be "you can"; "you may" is "you have permission to"
rather than "you can"'s "it is possible to"
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Recently in git.git change b4372ef136 Johannes Schindelin taught
git-commit.sh to invoke (or skip) calling git-rerere based upon
the rerere.enabled configuration setting:
So, check the config variable "rerere.enabled". If it is set
to "false" explicitely, do not activate rerere, even if
.git/rr-cache exists. This should help when you want to disable
rerere temporarily.
If "rerere.enabled" is not set at all, fall back to detection
of the directory .git/rr-cache.
We now do the same logic in git-gui's own commit implementation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This would hopefully make it easier to maintain. Initially we
would have "java" and "tex" defined, as they are the only ones
we already have.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A missing return statement in git_get_last_activity made gitweb think
a project with no commits was in age class "age0", so the "No commits"
appeared in bold green, which was ridiculous. I added the return so
those projects get "noage" and added a block to gitweb.css to format
the "No commits" text gray.
Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The search form generated traditional-style URLs with a "p=" parameter
even when the pathinfo feature was on. This patch makes it generate
pathinfo-style URLs when appropriate.
Signed-off-by: Matt McCutchen <hashproduct@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This way if $projects_list exists, it'll be used, otherwise get_file_owner()
will be used as before.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Acked-by: Luben Tuikov <ltuikov@yahoo.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If repeated calls to git_get_project_owner() are made, we would have read the
same file over and over again.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The code shuffling mistakenly lost binariness specified with the
attribute mecahnism and made it always guess from the data.
Noticed by Johannes, with two test cases to t4020.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git apply" used to take check the whitespace in the wrong
direction.
Noticed by Daniel Barkalow.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The static function read_directory in diff-lib.c is only ever called
with struct path_list lists with .strdup_paths turned on, i.e.
path_list_insert will strdup the paths for us (again). Let's take
advantage of that and stop doing it twice.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This updates the hunk header customization syntax. The special
case 'funcname' attribute is gone.
You assign the name of the type of contents to path's "diff"
attribute as a string value in .gitattributes like this:
*.java diff=java
*.perl diff=perl
*.doc diff=doc
If you supply "diff.<name>.funcname" variable via the
configuration mechanism (e.g. in $HOME/.gitconfig), the value is
used as the regexp set to find the line to use for the hunk
header (the variable is called "funcname" because such a line
typically is the one that has the name of the function in
programming language source text).
If there is no such configuration, built-in default is used, if
any. Currently there are two default patterns: default and java.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git branch --track" will setup config variables when branching from
a remote branch, so that if you say "git pull" while being on that
branch, it automatically fetches the correct remote, and merges the
correct branch.
Often people complain that this is not the default for "git branch".
Make it so.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Other code assumes that this is initialized, so do it
even if there were no arguments given.
Signed-off-by: Dirk Koopman <djk@tobit.co.uk>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git-submodule was updated to allow mapping between submodule name and
submodule path, the documentation was left untouched.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, "git rerere" was enabled by creating the directory
.git/rr-cache. That is definitely not in line with most other
features, which are enabled by a config variable.
So, check the config variable "rerere.enabled". If it is set
to "false" explicitely, do not activate rerere, even if
.git/rr-cache exists. This should help when you want to disable
rerere temporarily.
If "rerere.enabled" is not set at all, fall back to detection
of the directory .git/rr-cache.
[jc: with minimum tweaks]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The SYNOPSIS section of git-submodule.txt contains two forms. Since
it doesn't use the verse style, the line boundary between them is not
preserved and the second form can appear on the same line as the first
form. Adding [verse] enables the verse style, which preserves the
line boundary between them.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This one fixes a small formulation weirdness in
Documentation/user-manual.txt
Signed-off-by: Marcus Fritzsch <m@fritschy.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When given this subcommand, git-stash will try to merge the stashed
index into the current one. Only trivial merges are possible, since
we have no index for the index ;-) If a trivial merge is not possible,
git-stash will bail out with a hint to skip the --index option.
For good measure, finally include a test case.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes"diff -p" hunk headers customizable via gitattributes mechanism.
It is based on Johannes's earlier patch that allowed to define a single
regexp to be used for everything.
The mechanism to arrive at the regexp that is used to define hunk header
is the same as other use of gitattributes. You assign an attribute, funcname
(because "diff -p" typically uses the name of the function the patch is about
as the hunk header), a simple string value. This can be one of the names of
built-in pattern (currently, "java" is defined) or a custom pattern name, to
be looked up from the configuration file.
(in .gitattributes)
*.java funcname=java
*.perl funcname=perl
(in .git/config)
[funcname]
java = ... # ugly and complicated regexp to override the built-in one.
perl = ... # another ugly and complicated regexp to define a new one.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-gui: Ensure windows shortcuts always have .bat extension
git-gui: Include a Push action on the left toolbar
git-gui: Bind M1-P to push action
git-gui: Don't bind F5/M1-R in all windows
Conflicts:
git-gui.sh
Apparently under some setups on Windows Tk is hiding our file
extension recommendation of ".bat" from the user and that is
allowing the user to create a shortcut file which has no file
extension. Double clicking on such a file in Windows Explorer
brings up the associate file dialog, as Windows does not know
what application to launch.
We now append the file extension ".bat" to the filename of the
shortcut file if it has no extension or if it has one but it is
not ".bat".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Pushing changes to a remote system is a very common action for
many users of git-gui, so much so that in some workflows a user
is supposed to push immediately after they make a local commit
so that their change(s) are immediately available for their
teammates to view and build on top of.
Including the push button right below the commit button on the
left toolbar indicates that users should probably perform this
action after they have performed the commit action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users often need to be able to push the current branch so that they
can publish their recent changes to anyone they are collaborating
with on the project. Associating a keyboard action with this will
make it easier for keyboard-oriented users to quickly activate the
push features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We actually only want our F5/M1-R keystroke bound in the main window.
Within a browser/blame/console window pressing these keys should not
execute the rescan action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The instances of xdemitconf_t were initialized member by member.
Instead, initialize them to all zero, so we do not have
to update those places each time we introduce a new member.
[jc: minimally fixed by getting rid of a new global]
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This replaces an explicit initialization of filespec->is_binary
field used for rename/break followed by direct access to that
field with a wrapper function that lazily iniaitlizes and
accesses the field. We would add more attribute accesses for
the use of diff routines, and it would be better to make this
abstraction earlier.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The environment variable $EMAIL gives a better default of user's
preferred e-mail address than the hardcoded "username@hostname",
as it is understood by many existing programs.
We still honor GIT_*_EMAIL environment variables and user.email
configuration variable give them higher precedence, so that the
user can override $EMAIL or "username@hostname", as they are
likely to be more specific to the context of working on a
particular project.
Signed-off-by: Matt Kraai <kraai@ftbfs.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If GIT_WORK_TREE is set git-clone will use that path for the
working tree.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Bob cloned from Alice.
The origin url is actually Alice's repo.
Signed-off-by: Alecs King <alecsk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A common mistake is to provide a filter which fails unwantedly. For
example, this will stop in the middle:
git filter-branch --env-filter '
test $GIT_COMMITTER_EMAIL = xyz &&
export GIT_COMMITTER_EMAIL = abc' rewritten
When $GIT_COMMITTER_EMAIL is not "xyz", the test fails, and consequently
the whole filter has a non-zero exit status. However, as demonstrated
in this example, filter-branch would just stop, and the user would be
none the wiser.
Also, a failing msg-filter would not have been caught, as was the
case with one of the tests.
This patch fixes both issues, by paying attention to the exit status
of msg-filter, and by saying what failed before exiting.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Many other commands already have such an option, and I find it
practical to see where all the remotes actually come from.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This allows you to say:
$ git stash starting to implement X
while creating a stash, and the resulting "stash list entry
would read as:
$ git stash list
stash@{0}: On master: starting to implement X
instead of the default message which talks about the commit the
stash happens to be based on (hence does not have much to do
with what the stashed change is trying to do).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since git-clone is one of the many commands taking
URLs to remote repositories as an argument, it should include
the URL-types list from urls.txt.
Split up urls.txt into urls.txt and urls-remotes.txt. The latter
should be used by anything besides git-clone where a discussion of
using .git/config and .git/remotes/ to name URLs just doesn't make
as much sense.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Consider this history:
o--o-...-B <- origin
\ \
x--x--M--x--x <- master
In this situation, rebase considers master fully up-to-date and would
not do anything. However, if there were additional commits on origin,
the rebase would run and move the commits x on top of origin.
Here we change rebase to short-circuit out only if the history since origin
is strictly linear. Consequently, the above as well as a history like this
would be linearized:
o--o <- origin
\
x--x
\ \
x--M--x--x <- master
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-blame (and friends) specifically leave the pager turned off
in the case that --incremental is specified as this isn't for
human consumption. git-pickaxe and git-annotate will turn it on
themselves otherwise.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We now explicitly disconnect before starting new SVN::Ra
connections. SVN::Ra objects will automatically be disconnected
from the server on DESTROY.
SVN servers seem to have problems accepting multiple connections
from one client, and the SVN library has trouble being connected
to multiple servers at once. This appears to cause opening the
second connection to block, and cause git-svn to be unusable
after using the do_switch() function.
git-svn opens another connection because a workaround is
necesary for the buggy reparent function handling on certain
versions of svn:// and svn+ssh:// servers. Instead of using the
reparent function (analogous to chdir), it will reopen a new
connection to a different URL on the SVN server.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The status field of the remote branch delete dialog was marked to
expand, which meant that if the user grew the window vertically
most of the new vertical height was given to the status field and
not to the branch list. Since the status field is just a single
line of text there is no reason for it to gain additional height,
instead we should make sure all additional height goes to the
branch list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
- The map function used to fail, but no longer does (since 3520e1e8687.)
- Fix the "edge-graft" example.
- Show the same using .git/info/grafts.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
--tag-name-filter may have failed before because
warn is used for reporting but was not available.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As suggested by Junio, adding the current branch name to the
reflog message for git-checkout would be helpful. For example:
"checkout: moving from next to master"
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now you can do the following to create a repository which
has a separate working tree:
/tmp/foo$ export GIT_DIR=/tmp/bar
/tmp/foo$ git --work-tree . init
Initialized empty Git repository in /tmp/bar/
/tmp/foo$ git config core.worktree
/tmp/foo
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In user space, and for getcwd(), the check to see if the
resulting path begins with a '/' does not make sense. This is
merely a mistake by Linus who is so used to code for the kernel,
where a d_path() return value pathname can be either a real
path, or something like "pipe:[8003]", and the difference is the
'/' at the beginning.
Pointed out by Dscho, Matthias Lederhofer and clarified by Linus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of filling the screen with progress lines, use \r so that
the progress can be seen, but warning messages are more visible.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise the hooks will be executed on cygwin and the test will fail
because of the contributed hooks.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the map function didn't find the rewritten commit of the passed in
original id, it printed the original id, but it still fell through to
the 'cat', which failed with an error message.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because the --pretty can be given as --pretty=email which historically produced
mails with patches. IOW, exactly what git-format-patch does.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A stash is about a change on top of an existing commit, and not
about that commit that happened to be on which the change was
created. Match the message we see in "git stash list" with the
commit log message to make this clear.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Acked-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
This adds a configuration variable that performs the same function as,
but is overridden by, GIT_PAGER.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Acked-by: Johannes E. Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was a hangover from before the "Files" and "Pickaxe" parts of
the Find function were moved to the highlight facility in commit
60f7a7dc49. It serves no useful
purpose any more, so this removes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
I missed the case where both nodes have no children and therefore
have no incoming arcs. This fixes it.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This reworks the way that the "Find" button (and the /, ?, ^F, and ^G
keys) works. Previously, pressing the "Find" button would cause gitk
to go off and scan through every commit to see which commits matched,
and the user interface was completely unreponsive during that time.
Now the searching is done in chunks using the scheduler, so the UI
still responds, and the search stops as soon as a matching commit is
found.
The highlighting of matches using a yellow background is now done in
the commit-drawing code and the highlighting code. This ensures that
all the commits that are visible that match are highlighted without
the search code having to find them all.
This also fixes a bug where previously-drawn commits that need to be
highlighted were not being highlighted.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Most users these days are using a windowing system attached to a
monitor that has more than 600 pixels worth of vertical space
available for application use. As most files stored by Git are
longer than they are wide (have more lines than columns) we want
to dedicate as much vertical space as we can to the viewer.
Instead of always starting the window at ~600 pixels high we now
start the window 100 pixels shorter than the screen claims it has
available to it. This -100 rule is used because some popular OSen
add menu bars at the top of the monitor, and docks on the bottom
(e.g. Mac OS X, CDE, KDE). We want to avoid making our window too
big and causing the window's resize control from being out of reach
of the user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Pressing the escape key while in the merge dialog cancels the merge
and correctly unlocks the index. Unfortunately this is not true of
the Cancel button, using it closes the dialog but does not release
the index lock, rendering git-gui frozen until you restart it. We
now properly release the index lock when the Cancel button is used.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Document -<n> for git-format-patch
glossary: add 'reflog'
diff --no-index: fix --name-status with added files
Don't smash stack when $GIT_ALTERNATE_OBJECT_DIRECTORIES is too long
In the man page, there is an example which describes how to remove
single commits (although it keeps the changes which were not reverted
in the next non-removed commit). Better make sure that it works as
expected.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To prevent funky games with external diff engines, git-log and
friends prevent external diff engines from being called. That makes
sense in the context of git-format-patch or git-rebase.
However, for "git log -p" it is not so nice to get the message
that binary files cannot be compared, while "git diff" has no
problems with them, if you provided an external diff driver.
With this patch, "git log --ext-diff -p" will do what you expect,
and the option "--no-ext-diff" can be used to override that
setting.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This moves the documentation in git-filter-branch.sh to its own
man page, with a few touch ups (incorporating comments by Frank
Lichtenheld).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If I do
git cat-file commit $commitid
for a commit created by stash, the next prompt starts directly after the
shortlog of HEAD.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The -<n> option was not mentioned in git-format-patch's manpage till
now. Fix this.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch, an added file would be reported as /dev/null.
Noticed by David Kastrup.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no restriction on the length of the name returned by
get_object_directory, other than the fact that it must be a stat'able
git object directory. That means its name may have length up to
PATH_MAX-1 (i.e., often 4095) not counting the trailing NUL.
Combine that with the assumption that the concatenation of that name and
suffixes like "/info/alternates" and "/pack/---long-name---.idx" will fit
in a buffer of length PATH_MAX, and you see the problem. Here's a fix:
sha1_file.c (prepare_packed_git_one): Lengthen "path" buffer
so we are guaranteed to be able to append "/pack/" without checking.
Skip any directory entry that is too long to be appended.
(read_info_alternates): Protect against a similar buffer overrun.
Before this change, using the following admittedly contrived environment
setting would cause many git commands to clobber their stack and segfault
on a system with PATH_MAX == 4096:
t=$(perl -e '$s=".git/objects";$n=(4096-6-length($s))/2;print "./"x$n . $s')
export GIT_ALTERNATE_OBJECT_DIRECTORIES=$t
touch g
./git-update-index --add g
If you run the above commands, you'll soon notice that many
git commands now segfault, so you'll want to do this:
unset GIT_ALTERNATE_OBJECT_DIRECTORIES
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I realize that a lot of people use the "git-xyzzy" format, and we have
various historical reasons for it, but I also think that most people have
long since started thinking of the git command as a single command with
various subcommands, and we've long had the documentation talk about it
that way.
Slowly migrating away from the git-xyzzy format would allow us to
eventually no longer install hundreds of binaries (even if most of them
are symlinks or hardlinks) in users $PATH, and the _original_ reasons for
it (implementation issues and bash completion) are really long long gone.
Using "git xyzzy" also has some fundamental advantages, like the ability
to specify things like paging ("git -p xyzzy") and making the whole notion
of aliases act like other git commands (which they already do, but they do
*not* have a "git-xyzzy" form!)
Anyway, while actually removing the "git-xyzzy" things is not practical
right now, we can certainly start slowly to deprecate it internally inside
git itself - in the shell scripts we use, and the test vectors.
This patch adds a "remove-dashes" makefile target, which does that. It
isn't particularly efficient or smart, but it *does* successfully rewrite
a lot of our shell scripts to use the "git xyzzy" form for all built-in
commands.
(For non-builtins, the "git xyzzy" format implies an extra execve(), so
this script leaves those alone).
So apply this patch, and then run
make remove-dashes
make test
git commit -a
to generate a much larger patch that actually starts this transformation.
(The only half-way subtle thing about this is that it also fixes up
git-filter-branch.sh for the new world order by adding quoting around
the use of "git-commit-tree" as an argument. It doesn't need it in that
format, but when changed into "git commit-tree" it is no longer a single
word, and the quoting maintains the old behaviour).
NOTE! This does not yet mean that you can actually stop installing the
"git-xyzzy" binaries for the builtins. There are some remaining places
that want to use the old form, this just removes the most obvious ones
that can easily be done automatically.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this option, dangling objects are not only reported, but also
written to .git/lost-found/commit/ or .git/lost-found/other/. This
option implies '--full' and '--no-reflogs'.
'git fsck --lost-found' is meant as a replacement for git-lost-found.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change lets you use the format.subjectprefix config option to override the
default subject prefix.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In 2031427167 git add was fixed if unmerged
entries are in the index and core.filemode=false. core.symlinks=false is
a similar case, which touches the same code path. Here is a test that
makes sure that the symlink property in the index is preserved, too.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git push" is run without any refspec (neither on the
command line nor in the config), we used to push "matching refs"
in the sense that anything under refs/ hierarchy that exist on
both ends were updated. This used to be a sane default for
publishing your repository to another back when we did not have
refs/remotes/ hierarchy, but it does not make much sense these
days.
This changes the semantics to push only "matching branches".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I ran git-prune on a repository and got this:
$ git-prune
error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a commit
Segmentation fault (core dumped)
This repository was a strange one in that it was being used to provide
its own submodule. That is, the repository was cloned into a
subdirectory, an independent branch checked out in that subdirectory,
and then it was marked as a submodule. git-prune then failed in the
above manner.
The problem was that git-prune was not submodule aware in two areas.
Linus said:
> So what happens is that something traverses a tree object, looks at each
> entry, sees that it's not a tree, and tries to look it up as a blob. But
> subprojects are commits, not blobs, and then when you look at the object
> more closely, you get the above kind of object type confusion.
and included a patch to add an S_ISGITLINK() test to reachable.c's
process_tree() function. That fixed the first git-prune error, and
stopped it from trying to process the gitlink entries in trees as if
they were pointers to other trees (and of course failing, because
gitlinks _aren't_ trees). That part of this patch is his.
The second area is add_cache_refs(). This is called before starting the
reachability analysis, and was calling lookup_blob() on every object
hash found in the index. However, it is no longer true that every hash
in the index is a pointer to a blob, some of them are gitlinks, and are
not backed by any object at all, they are commits in another repository.
Normally this bug was not causing any problems, but in the case of the
self-referencing repository described above, it meant that the gitlink
hash was being marked as being of type OBJ_BLOB by add_cache_refs() call
to lookup_blob(). Then later, because that hash was also pointed to by
a ref, add_one_ref() would treat it as a commit; lookup_commit() would
return a NULL because that object was already noted as being an
OBJ_BLOB, not an OBJ_COMMIT; and parse_commit_buffer() would SEGFAULT on
that NULL pointer.
The fix made by this patch is to not blindly call lookup_blob() in
reachable.c's add_cache_refs(), and instead skip any index entries that
are S_ISGITLINK().
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ns/stash:
Documentation: quote {non-attributes} for asciidoc
git-stash: don't complain when listing in a repo with no stash
git-stash: fix "can't shift that many" with no arguments
git-stash: fix "no arguments" case in documentation
git-stash: require "save" to be explicit and update documentation
Document git-stash
Add git-stash script
* js/rebase:
Teach rebase -i about --preserve-merges
rebase -i: provide reasonable reflog for the rebased branch
rebase -i: several cleanups
ignore git-rebase--interactive
Teach rebase an interactive mode
Move the pick_author code to git-sh-setup
* jc/diffcore:
diffcore-delta.c: Ignore CR in CRLF for text files
diffcore-delta.c: update the comment on the algorithm.
diffcore_filespec: add is_binary
diffcore_count_changes: pass diffcore_filespec
Change "to made" to "made to", which is a typo. Use "reflog"
instead of "ref log", which is used elsewhere throughout the
documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Asciidoc treats {foo} as an attribute to be substituted; if
'foo' doesn't exist as an attribute, then the entire line
gets dropped. When the literal {foo} is desired, \{foo} is
required.
The exceptions to this rule are:
- inside literal blocks
- if the 'foo' contains non-alphanumeric characters (e.g.,
{foo|bar} is assumed not to be an attribute)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When an alias starts with an exclamation mark, the rest is interpreted
as a shell command. However, all arguments passed to git used to be
ignored.
Now you can have an alias like
$ git config alias.e '!echo'
and
$ git e Hello World
does what you expect it to do.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There were places using "GIT_DIR" instead of GIT_DIR_ENVIRONMENT and
"GIT_CONFIG" instead of CONFIG_ENVIRONMENT. This makes it easier to
find all places touching an environment variable using git grep or
similar tools.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clone supports cloning from a repo with detached HEAD,
but if this HEAD is not behind any branch tip then it
would not have been fetched over dumb http, resulting in a
fatal: Not a valid object name HEAD
Since 928c210a, this would also happen on a http repo
with a HEAD that is a symbolic link where someone has
forgotton to run update-server-info.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Some repositories might not use/have annotated tags (for example the
ones created with git-cvsimport) and git-submodule status might fail
because git-describe might fail to find a tag. This change allows the
status of a submodule to be described/displayed relative to lightweight
tags as well.
Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To make a submodule effectively usable, the path and
a URL where the submodule can be cloned need to be stored
in .gitmodules. This subcommand takes care of setting
this information after cloning the new submodule.
Only the index is updated, so, if needed, the user may still
change the URL or switch to a different branch of the submodule
before committing.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Asciidoc treats {foo} as an attribute to be substituted; if
'foo' doesn't exist as an attribute, then the entire line
gets dropped. When the literal {foo} is desired, \{foo} is
required.
The exceptions to this rule are:
- inside literal blocks
- if the 'foo' contains non-alphanumeric characters (e.g.,
{foo|bar} is assumed not to be an attribute)
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the git-log invocation would complain if a repo
had not had any stashes created in it yet:
$ git-init
$ git-stash
fatal: ambiguous argument 'refs/stash': unknown revision or
path not in the working tree.
Use '--' to separate paths from revisions
Instead, we only call git-log if we actually have a
refs/stash. We could alternatively create the ref when any
stash command is called, but it's better for the 'list'
command to not require write access to the repo.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Commit 9488e875 changed this from 'save' to 'list', but
missed this spot in the documentation.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When wc outputs whitespace, the test "$(command | wc -l)" = 1 is
broken because " 1" != "1". Let the shell eat the whitespace by
using test 1 = $(command | wc -l) instead.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a merge left unmerged entries, git add failed to pick up the
file mode from the index, when core.filemode == 0. If more than one
unmerged entry is there, the order of stage preference is 2, 1, 3.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This avoids warning messages from gpg while verifying the tags; without it,
the program complains that the key is not certified with a trusted signature.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* ei/worktree+filter:
filter-branch: always export GIT_DIR if it is set
setup_git_directory: fix segfault if repository is found in cwd
test GIT_WORK_TREE
extend rev-parse test for --is-inside-work-tree
Use new semantics of is_bare/inside_git_dir/inside_work_tree
introduce GIT_WORK_TREE to specify the work tree
test git rev-parse
rev-parse: introduce --is-bare-repository
rev-parse: document --is-inside-git-dir
This describes the git-stash command.
I borrowed a few paragraphs from Johannes's version, and added a few
examples.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cache the maximum revision for each rev_db URL rather than looking it
up each time. This saves a lot of time when rebuilding indexes on a
freshly cloned repository.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, whenever svn repository http server requests client
certificate, prompt provider is invoked, ignoring any
ssl-client-cert-file settings in ~/.subversion/servers.
Moreover, it happens more than once per session, which is quite
irritating.
Signed-off-by: Michael Krelin <hacker@klever.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This ignores CR byte in CRLF sequence in text file when
computing similarity of two blobs.
Usually this should not matter as nobody sane would be checking
in a file with CRLF line endings to the repository (they would
use autocrlf so that the repository copy would have LF line
endings).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The comment at the top of the file described an old algorithm
that was neutral to text/binary differences (it hashed sliding
window of N-byte sequences and counted overlaps), but long time
ago we switched to a new heuristics that are more suitable for
line oriented (read: text) files that are much faster.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diffcore-break and diffcore-rename would want to behave slightly
differently depending on the binary-ness of the data, so add one
bit to the filespec, as the structure is now passed down to
diffcore_count_changes() function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We may want to use richer information on the data we are dealing
with in this function, so instead of passing a buffer address
and length, just pass the diffcore_filespec structure. Existing
callers always call this function with parameters taken from a
filespec anyway, so there is no functionality changes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When my boss has something to show me and I have to update, for some
reason I am always in the middle of doing something else, and git pull
command refuses to work in such a case.
I wrote this little script to save the changes I made, perform the
update, and then come back to where I was, but on top of the updated
commit.
This is how you would use the script:
$ git stash
$ git pull
$ git stash apply
[jc: with a few fixlets from the list]
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This patch arose from a discussion started by Jim Meyering's patch
whose intention was to provide better diagnostics for failed writes.
Linus proposed a better way to do things, which also had the added
benefit that adding a fflush() to git-log-* operations and incremental
git-blame operations could improve interactive respose time feel, at
the cost of making things a bit slower when we aren't piping the
output to a downstream program.
This patch skips the fflush() calls when stdout is a regular file, or
if the environment variable GIT_FLUSH is set to "0". This latter can
speed up a command such as:
GIT_FLUSH=0 strace -c -f -e write time git-rev-list HEAD | wc -l
a tiny amount.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This switches the checks around upon the exit codepath of the
git wrapper, so that we may recover at least non-transient errors.
It's still not perfect. As I've been harping on, stdio simply isn't very
good for error reporting. For example, if an IO error happened, you'd want
to see EIO, wouldn't you? And yes, that's what the kernel would return.
However, with buffered stdio (and flushing outside of our control), what
would likely happen is that some intermediate error return _does_ return
EIO, but then the kernel might decide to re-mount the filesystem read-only
due to the error, and the actual *report* for us might be
"write failure on standard output: read-only filesystem"
which lost the EIO.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'show' and 'prune' commands accept an option '-n'; document what
it does.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This stop git-tag from emitting a "shift: can't shift that many"
error, when listing tags.
[jc: with further fixups from Sam Vilain merged in; it passes
the tests under dash now]
Signed-off-by: Alexandre Vassalotti <alexandre@peadrop.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Both `git-tag -l` and `git tag -v` fail on Mac OS X due to their
non-standard uses of sed. Actually `git tag -v` fails because the
underlying git-tag-verify uses a non-standard sed command.
We now stick to only standard sed, which does make our sed scripts
slightly more complicated, but we can actually list tags with more
than 0 lines of additional context and we can verify signed tags
with gpg. These major Git functions are much more important than
saving two or three lines of a simple sed script.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On 'Visualize ...', a gitk process is started. Since it is run in the
background, catching a possible startup error doesn't work, and the error
output goes to the console git-gui is started from. The most probable
startup error is that gitk is not installed; so before trying to start,
check for the existence of the gitk program, and popup an error message
unless it's found.
This was noticed and reported by Paul Wise through
http://bugs.debian.org/429810
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require $DISPLAY just to get --version
git-gui: Quiet our installation process
git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
git-gui: Correctly install to /usr/bin on Cygwin
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require $DISPLAY just to get --version
git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
git-gui: Correctly install to /usr/bin on Cygwin
It fixes the test on system where ActiveState Perl is used.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When creating a brand new git repository through git-cvsimport (not
incremental import), force a checkout of HEAD of master as working tree
after successful import using the -f switch to git checkout. Otherwise
the working tree is empty, and all files are reported as 'deleted' by
git status.
This was noticed and reported by Cameron Dale through
http://bugs.debian.org/430903
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
These tests are useful to develop the C version for git-tag.sh,
ensuring that the future builtin-tag.c will not break previous
behaviour.
The tests are focused on listing, verifying, deleting and creating
tags, checking always that the correct status value is returned
and everything remains as expected.
In order to verify and create signed tags, a PGP key was also
added, being created this way: gpg --homedir t/t7004 --gen-key
Type DSA and Elgamal, size 2048 bits, no expiration date.
Name and email: C O Mitter <committer@example.com>
No password given, to enable non-interactive operation.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now that git-init has an option to quiet itself, use it if the -q
option was specified on the clone command line.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-init lacks an option to suppress non-error and non-warning output -
this patch adds one.
Signed-off-by: Jeffrey C. Ollie <jeff@ocjtech.us>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This defines xdup() and xfdopen() in git-compat-util.h to give
us error-catching variants of them without cluttering the code
too much.
Signed-off-by: Jim Meyering <jim@meyering.net>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This change makes git-send-email's behavior easier to modify by adding config
equivalents for two more of git-send-email's flags.
The mapping of flag to config setting is:
--[no-]supress-from => sendemail.suppressfrom
--[no-]signed-off-cc => sendemail.signedoffcc
It renames the --threaded option to --thread/--no-thread; the
config variable is also called sendemail.thread.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Update selection background colorbar in prefs dialog
gitk: Use a spinbox for setting tabstop settings
The callback function was incorrectly set to update the background
colorbar when updated the selection background. This did not affect the
colors chosen or their use, just their presentation in the preferences
dialog box.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
The tabstop must be a smallish positive integer, and a spinbox is the
accepted UI control to accomplish this limiting rather than the text
entry box previously used.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
These tests check some features that git-stripspace already has
and those that it should manage well: Removing trailing spaces
from lines, removing blank lines at the beginning and end,
unifying multiple lines between paragraphs, doing the correct
when there is no newline at the last line, etc.
It seems that the implementation needs to save the whole line
in memory to be able to manage correctly long lines with
text and spaces conveniently distribuited on them.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The --threaded option controls whether the In-Reply-To header will be set on
any emails sent. The current behavior is to always set this header, so this
option is most useful in its negated form, --no-threaded. This behavior can
also be controlled through the 'sendemail.threaded' config setting.
Signed-off-by: Adam Roben <aroben@apple.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now the implementation gets more memory to store completely
each line before removing trailing spaces, and does it right
when the last line of the file ends with spaces and no newline
at the end.
Function stripspace needs again to be non-static in order to call
it from "builtin-tag.c" and the upcoming "builtin-commit.c".
A new parameter skip_comments was also added to the stripspace
function to optionally strips every shell #comment from the input,
needed for doing this task on those programs.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this, if the size of refs_file at that point is ever an exact
multiple of BUFSIZ, then an EIO or ENOSPC error on the final write would
not be diagnosed.
It's not worth worrying about EPIPE here.
Although theoretically possible that someone kill this process
with a manual SIGPIPE, it's not at all likely.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I audited git for potential undetected write failures.
In the cases fixed below, the diagnostics I add mimic the diagnostics
used in surrounding code, even when that means not reporting
the precise strerror(errno) cause of the error.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require $DISPLAY just to get --version
The Tools/Migrate menu option is a hack just for me. Yes, that's
right, git-gui has a hidden feature that really only works for me,
and the users that I support within my day-job's great firewall.
The menu option is not supported outside of that environment.
In the past we only enabled Tools/Migrate if our special local
script 'gui-miga' existed in the proper location, and if there
was a special '.pvcsrc' in the top level of the working directory.
This latter test for the '.pvcsrc' file is now failing, as the file
was removed from all Git repositories due to changes made to other
tooling within the great firewall's realm.
I have changed the test to only work on Cygwin, and only if the
special 'gui-miga' is present. This works around the configuration
changes made recently within the great firewall's realm, but really
this entire Tools/Migrate thing should be abstracted out into some
sort of plugin system so other users can extend git-gui as they need.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt reported that MinGW/MSYS does not have a nice.exe to
drop the priority of a child process when it gets spawned. So we
have to avoid trying to start `git blame` through nice when we are
on Windows and do not have Cygwin available to us.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Use \n as delimiter between key and value and \0 as
delimiter after each key/value pair. This should be
easily parsable output.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option "-p" (or long "--preserve-merges") makes it possible to
rebase side branches including merges, without straightening the
history.
Example:
X
\
A---M---B
/
---o---O---P---Q
When the current HEAD is "B", "git rebase -i -p --onto Q O" will yield
X
\
---o---O---P---Q---A'---M'---B'
Note that this will
- _not_ touch X [*1*], it does
- _not_ work without the --interactive flag [*2*], it does
- _not_ guess the type of the merge, but blindly uses recursive or
whatever strategy you provided with "-s <strategy>" for all merges it
has to redo, and it does
- _not_ make use of the original merge commit via git-rerere.
*1*: only commits which reach a merge base between <upstream> and HEAD
are reapplied. The others are kept as-are.
*2*: git-rebase without --interactive is inherently patch based (at
least at the moment), and therefore merges cannot be preserved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If your rebase succeeded, the HEAD's reflog will still show the whole
mess, but "<branchname>@{1}" now shows the state _before_ the rebase,
so that you can reset (or compare) the original and the rebased
revisions more easily.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Support "--verbose" in addition to "-v", show short names in the list
comment, clean up if there is nothing to do, and add several "test_ticks"
in the test script.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Print no space after the name of a key without value.
Otherwise keys without values are printed exactly the
same as keys with empty values.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The asciidoc documentation of the --get-regexp option was
incomplete. Add some missing pieces:
- List the option in SYNOPSIS
- Mention that key names are printed
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
RPM build broke with "File not found" error on git-gui.1 and git-citool.1
They actually are git-gui.1.gz and git-citool.1.gz
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A pack-file can get created without any objects in it (to transfer "no
data" - which can happen if you use a reference git repo, for example,
or just otherwise just end up transferring only branch head information
and already have all the objects themselves).
And while we probably should never create an index for such a pack, if we
do (and we do), the index file size sanity checking was incorrect.
This fixes it.
Reported-and-tested-by: Jocke Tjernlund <tjernlund@tjernlund.se>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch, the code would look for the submodule
commits in the superproject and (needlessly) fail when it
couldn't find them.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://git.kernel.org/pub/scm/gitk/gitk: (21 commits)
gitk: Add a progress bar to show progress while resetting
gitk: Improve handling of whitespace and special chars in filenames
gitk: Fix bug causing nearby tags/heads to sometimes not be displayed
gitk: Limit how often we change the canvas scrolling region
gitk: Add a "reset branch to here" row context-menu operation
gitk: Get rid of the childlist variable
gitk: Speed up the reading of references
gitk: Show local uncommitted changes as a fake commit
gitk: New algorithm for drawing the graph lines
gitk: Store ids in rowrangelist and idrowranges rather than row numbers
gitk: Disable the head context menu entries for the checked-out branch
gitk: Cope with commit messages with carriage-returns and initial blank lines
gitk: Implement a simple scheduler for the compute-intensive stuff
gitk: Improve the behaviour of the initial selection
gitk: Add some more comments to the optimize_rows procedure
gitk: Don't try to list large numbers of tags or heads in the details pane
gitk: New infrastructure for working out branches & previous/next tags
[PATCH] gitk: Allow specifying tabstop as other than default 8 characters.
[PATCH] gitk: Update fontsize in patch / tree list
[PATCH] gitk: Make selection highlight color configurable
...
Conflicts:
gitk
Since git reset now gets chatty while resetting, we were getting errors
reported when a reset was done using the "reset branch to here" menu
item. With this we now read the progress messages from git reset and
update a progress bar. Because git reset outputs the progress messages
to standard error, and Tcl treats messages to standard error as error
messages, we have to invoke git reset via a shell and redirect standard
error into standard output.
This also fixes a bug in computing descendent heads when head ids
are changed via a reset.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Rounding down the printed (dis)similarity index allows us to use
"100%" as a special value that indicates complete rewrites and
fully equal file contents, respectively.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This implements a suggestion from Johannes. It uses a separate field in
struct diff_score to keep the result of the file name comparison in the
rename detection logic. This reverts the value of the similarity index
to be a function of file contents, only, and basename comparison is only
used to decide between files with equal amounts of content changes.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is trying to implement the strict IO error checks that Jim Meyering
suggested, but explicitly limits it to just regular files. If a pipe gets
closed on us, we shouldn't complain about it.
If the subcommand already returned an error, that takes precedence (and we
assume that the subcommand already printed out any relevant messages
relating to it)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This should change no code at all, it just moves the definition of "struct
cmd_struct" out, and then splits out the running of the right command into
the "run_command()" function.
It also removes the long-unused 'envp' pointer passing.
This is just preparation for adding some more error checking.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't you just hate the fact sometimes, that git-rebase just applies
the patches, without any possibility to edit them, or rearrange them?
With "--interactive", git-rebase now lets you edit the list of patches,
so that you can reorder, edit and delete patches.
Such a list will typically look like this:
pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...
By replacing the command "pick" with the command "edit", you can amend
that patch and/or its commit message, and by replacing it with "squash"
you can tell rebase to fold that patch into the patch before that.
It is derived from the script sent to the list in
<Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
At the moment, only git-commit uses that code, to pick the author name,
email and date from a given commit.
This code will be reused in git rebase --interactive.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Using `git push origin +foo` to forcefully overwrite the remote
branch named foo is a common idiom, especially since + is shorter
than the long option --force and can be specified on a per-branch
basis.
We now complete `git push origin +foo` just like we do the standard
`git push origin foo`. The leading + on a branch refspec does not
alter the completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We always quote "unusual" byte values in a pathname using
C-string style, to make it safer for parsing scripts that do not
handle NUL separated records well (or just too lazy to bother).
The absolute minimum bytes that need to be quoted for this
purpose are TAB, LF (and other control characters), double quote
and backslash.
However, we have also always quoted the bytes in high 8-bit
range; this was partly because we were lazy and partly because
we were being cautious.
This introduces an internal "quote_path_fully" variable, and
core.quotepath configuration variable to control it. When set
to false, it does not quote bytes in high 8-bit range anymore
but passes them intact.
The variable defaults to "true" to retain the traditional
behaviour for now.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the original $from address fails to yield a valid-looking
e-mail address, we created a bogus looking message ID, formatted
like this:
Message-Id: <11823357623688-git-send-email->
This commit fixes it by moving call to make_message_id() to
where it matters, namely, before the $message_id is needed to be
placed in the generated e-mail header; this has an important
side effect of making it clear that $from is already available.
Also throw in Sys::Hostname::hostname() just for fun, although I
suspect that the code would never trigger due to the modified
call sequence that makes sure $from is always available. This
is based on a suggestion by Michael Hendricks.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make clear in the documentation that when using --branches/-b and
--prefix with 'init', the prefix must include a trailing slash.
This matches the actual behavior of git-svn, e.g.:
$ git svn init -Ttrunk -treleases -bbranches --prefix xxx \
http://svn.sacredchao.net/svn/quodlibet/
--prefix='xxx' must have a trailing slash '/'
$
This was noticed by R. Vanicat and reported through
http://bugs.debian.org/429443
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
rev-parse --git-dir outputs a full path - except for the single case
of when the path would be $(pwd)/.git, in which case it outputs simply
.git. Check for this special case and handle it.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb calls Encode::decode_utf8 with two arguments,
but old versions of perl only allow this function to be called
with one argument. Even older versions of perl do not even
have an Encode module.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://repo.or.cz/git/fastimport: (260 commits)
Avoid src:dst syntax as default bash completion for git push
Make it possible to specify the HEAD for the internal findUpstreamBranchPoint function.
Added git-p4 branches command that shows the mapping of perforce depot paths to imported git branches.
Warn about conflicting p4 branch mappings and use the first one found.
Fix the branch mapping detection to be independent from the order of the "p4 branches" output.
git-p4 fails when cloning a p4 depo.
Fix initial multi-branch import.
Only use double quotes on Windows
Fix git-p4 rebase to detect the correct upstream branch instead of unconditionally
Moved the code from git-p4 submit to figure out the upstream branch point
git-p4 submit: Fix missing quotes around p4 commands to make them work with spaces in filenames
Mention remotes/p4/master also in the documentation.
Provide some information for single branch imports where the commits go
git-p4: check for existence of repo dir before trying to create
Write out the options tag in the log message of imports only if we actually have
Fix support for explicit disabling of syncing with the origin
Fix depot-paths encoding for multi-path imports (don't split up //depot/path/foo)
Fix project name guessing
Fix updating/creating remotes/p4/* heads from origin/p4/*
Fixed the check to make sure to exclude the HEAD symbolic refs when updating
...
The main thing here is better parsing of the diff --git lines in the
output of git diff-tree -p. We now cope with filenames in quotes with
special chars escaped. If the filenames contain spaces they aren't
quoted, however, which can create difficulties in parsing. We get
around the difficulties by detecting the case when the filename hasn't
changed (chop the part after "diff --git " in two and see if the halves
match apart from a/ in one and b/ in the other), and if it hasn't
changed, we just use one half. If the filename has changed we wait
for the "rename from" and "rename to" lines, which give the old and
new filenames unambiguously.
This also improves the parsing of the output of git diff-tree.
Instead of using lindex to extract the filename, we take the part from
the first tab on, and if it starts with a quote, we use [lindex $str 0]
to remove the quotes and convert the escapes.
This also gets rid of some unused tagging of the diff text, uses
[string compare] instead of [regexp] in some places, and fixes the
regexp for detecting the @@ hunk-separator lines (the regexp wasn't
accepting a single number, as in "-0,0 +1" for example).
Signed-off-by: Paul Mackerras <paulus@samba.org>
When we compute descendent heads and descendent/ancestor tags, we
cache the results. We need to be careful to invalidate the cache
when we add stuff to the graph. Also make sure that when we cache
descendent heads for a node we only cache the heads that are actually
descendents of that node.
Signed-off-by: Paul Mackerras <paulus@samba.org>
For some unknown reason, changing the scrolling region on the canvases
provokes multiple milliseconds worth of computation in the X server,
and this can end up slowing gitk down significantly. This works around
the problem by limiting the rate at which we update the scrolling region
after the first 100 rows to at most 2 per second.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This adds an entry to the menu that comes up when the user does a
right-click on a row. The new entry allows the user to reset the
currently checked-out head to the commit for the row that they did
the right-click on. The user has to select what type of reset to
do, and confirm the reset, via a dialog box that pops up.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The information in childlist is a duplicate of what's in the children
array, and it wasn't being accessed often enough to be really worth
keeping the list around as well.
Signed-off-by: Paul Mackerras <paulus@samba.org>
We were doing two execs for each tag - one to map the tag ID to a
commit ID and one to read the contents of the tag for later display.
This speeds up the process by not reading the contents of the tag
(instead it is read later if needed), and by using the -d flag to
git show-ref, which gives us refs/tags/foo^{} lines which give us
the commit ID. Also this uses string operations instead of regexps.
Signed-off-by: Paul Mackerras <paulus@samba.org>
If there are local changes in the repository, i.e., git-diff-index HEAD
produces some output, then this optionally displays an extra row in
the graph as a child of the HEAD commit (but with a red circle to
indicate that it's not a real commit). There is a checkbox in the
preferences window to control whether gitk does this or not.
Clicking on the extra row shows the diffs between the working directory
and the HEAD (using git diff-index -p). The right-click menu on the
extra row allows the user to generate a patch containing the local diffs,
or to display the diffs between the working directory and any commit.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This only draws as much of the graph lines as is visible. This can
happen by adding coordinates on to an existing graph line or by
creating a new line. This means that we only need to have laid out
and optimized as much of the graph as is actually visible in order to
draw it, including the lines (previously we didn't draw a graph
line until we had laid out and optimized to the end of a segment of
the line, i.e. down to a down-arrow or to the row where the line's
commit is displayed). This also lets us get rid of the linesegends
list, and gives us an easy workaround for the X server bug that
causes long lines to be misdrawn. This also gets rid of the use
of rowoffsets in drawlineseg et al.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This removes the need for insertrow to go through rowrangelist and
idrowranges and adjust a lot of entries. The first entry for a given
id is now the row number of the first child, not that row number + 1,
and rowranges compensates for that so its callers didn't have to
change. This adds a ranges argument to drawlineseg so that we can
avoid calling rowranges a second time inside drawlineseg (all its
callers already called rowranges).
Signed-off-by: Paul Mackerras <paulus@samba.org>
Neither the "check out this branch" nor the "remove this branch"
menu item can be used on the currently-checked out branch, so disable
them.
Signed-off-by: Paul Mackerras <paulus@samba.org>
In some repositories imported from other systems we can get carriage
return characters in the commit message, which leads to a multi-line
headline being displayed in the summary window, which looks bad.
Also some commit messages start with one or more blank lines, which
leads to an empty headline. This fixes these problems.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This allows us to do compute-intensive processing, such as laying out
the graph, relatively efficiently while also having the GUI be
reasonably responsive. The problem previously was that file events
were serviced before X events, so reading from another process which
supplies data quickly (hi git rev-list :) could mean that X events
didn't get processed for a long time.
With this, gitk finishes laying out the graph slightly sooner and
still responds to the GUI while doing so.
Signed-off-by: Paul Mackerras <paulus@samba.org>
It used to be that if you clicked on a line while gitk was still drawing
stuff, it would immediately re-select the first line of the display.
This fixes that.
Signed-off-by: Paul Mackerras <paulus@samba.org>
With some large repositories, a commit can end up on thousands of
branches, which results in an extremely long "Branches:" line in the
details window, and that results in the window being extremely slow
to scroll.
This fixes it by just showing "many (N)" after "Branches:", "Follows:"
or "Precedes:", where N is the number of heads or tags. The limit
is currently set at 20 but could be made configurable (and the "many"
could be a link to pop up a window listing them all in case anyone
really wants to know).
Signed-off-by: Paul Mackerras <paulus@samba.org>
Instead of working out descendent heads and descendent & ancestor
branches in a two-pass algorithm, this reads and stores a simplified
version of the graph topology, and works out descendent/ancestor
tags and descendent heads on demand (with a bit of caching).
The advantages of this are, first, that we now don't have to use
--topo-order on the git rev-list process. Secondly, we don't have
to re-read the whole graph when tags or heads change or even when
the graph changes. Since we can cope with parents coming before
children, we can update the graph by running a git rev-list with
arguments that just give us the new commits, and merge the new
commits into the simplified graph.
The graph is simplified in the sense that commits with exactly one
parent and one child (which is >90% of them in most cases) are grouped
together into arcs joining nodes or 'branch/merge points', which are
the commits that don't have exactly 1 parent and 1 child. This reduces
the size of the graph substantially and decreases the time to traverse
it correspondingly.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This fixes "git log --follow" to hopefully not leak memory any more, and
also cleans it up a bit to look more like some of the other functions that
use "diff_queued_diff" (by *not* using it directly as a global in the
code, but by instead just taking a pointer to the diff queue and using
that).
As to "diff_queued_diff", I think it would be better off not as a global
at all, but as being just an entry in the "struct diff_options" structure,
but that's a separate issue, and there may be some subtle reason for why
it's currently a global.
Anyway, no real changes. Instead of having a magical first entry in the
diff-queue, we now end up just keeping the diff-queue clean, and keeping
our "preferred" file pairing in an internal "choice" variable. That makes
it easy to switch the choice around when we find a better one.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Ok, I've really held off doing this too damn long, because I'm lazy, and I
was always hoping that somebody else would do it.
But no, people keep asking for it, but nobody actually did anything, so I
decided I might as well bite the bullet, and instead of telling people
they could add a "--follow" flag to "git log" to do what they want to do,
I decided that it looks like I just have to do it for them..
The code wasn't actually that complicated, in that the diffstat for this
patch literally says "70 insertions(+), 1 deletions(-)", but I will have
to admit that in order to get to this fairly simple patch, you did have to
know and understand the internal git diff generation machinery pretty
well, and had to really be able to follow how commit generation interacts
with generating patches and generating the log.
So I suspect that while I was right that it wasn't that hard, I might have
been expecting too much of random people - this patch does seem to be
firmly in the core "Linus or Junio" territory.
To make a long story short: I'm sorry for it taking so long until I just
did it.
I'm not going to guarantee that this works for everybody, but you really
can just look at the patch, and after the appropriate appreciative noises
("Ooh, aah") over how clever I am, you can then just notice that the code
itself isn't really that complicated.
All the real new code is in the new "try_to_follow_renames()" function. It
really isn't rocket science: we notice that the pathname we were looking
at went away, so we start a full tree diff and try to see if we can
instead make that pathname be a rename or a copy from some other previous
pathname. And if we can, we just continue, except we show *that*
particular diff, and ever after we use the _previous_ pathname.
One thing to look out for: the "rename detection" is considered to be a
singular event in the _linear_ "git log" output! That's what people want
to do, but I just wanted to point out that this patch is *not* carrying
around a "commit,pathname" kind of pair and it's *not* going to be able to
notice the file coming from multiple *different* files in earlier history.
IOW, if you use "git log --follow", then you get the stupid CVS/SVN kind
of "files have single identities" kind of semantics, and git log will just
pick the identity based on the normal move/copy heuristics _as_if_ the
history could be linearized.
Put another way: I think the model is broken, but given the broken model,
I think this patch does just about as well as you can do. If you have
merges with the same "file" having different filenames over the two
branches, git will just end up picking _one_ of the pathnames at the point
where the newer one goes away. It never looks at multiple pathnames in
parallel.
And if you understood all that, you probably didn't need it explained, and
if you didn't understand the above blathering, it doesn't really mtter to
you. What matters to you is that you can now do
git log -p --follow builtin-rev-list.c
and it will find the point where the old "rev-list.c" got renamed to
"builtin-rev-list.c" and show it as such.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/filter:
filter-branch: subdirectory filter needs --full-history
filter-branch: Simplify parent computation.
Teach filter-branch about subdirectory filtering
filter-branch: also don't fail in map() if a commit cannot be mapped
filter-branch: Use rev-list arguments to specify revision ranges.
filter-branch: fix behaviour of '-k'
filter-branch: use $(($i+1)) instead of $((i+1))
chmod +x git-filter-branch.sh
filter-branch: prevent filters from reading from stdin
t7003: make test repeatable
Add git-filter-branch
Luiz Fernando N. Capitulino noticed the one in tree-walk.h where
we cast away constness while computing the legnth of a tree
entry.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When there are several candidates for a rename source, and one of them
has an identical basename to the rename target, take that one.
Noticed by Govind Salinas, posted by Shawn O. Pearce, partial patch
by Linus Torvalds.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Jakub Narebski pointed out that the git-gui blame viewer is not a
widely known feature, but is incredibly useful. Part of the issue
is advertising. Up until now we haven't even referenced git-gui from
within the core Git manual pages, mostly because I just wasn't sure
how I wanted to supply git-gui documentation to end-users, or how
that documentation should integrate with the core Git documentation.
Based upon Jakub's comment that many users may not even know that
the gui is available in a stock Git distribution I'm offering up
two basic manual pages: git-citool and git-gui. These should offer
enough of a starting point for users to identify that the gui exists,
and how to start it. Future releases of git-gui may contain their
own documentation system available from within a running git-gui.
But not today.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now uses git-tag instead of manually constructing the tag. This gives us a
correct timestamp, removes some crufty code, and makes it work the same as
git-cvsimport.
The generated tags are now lightweight tags instead of tag objects, which may
or may not be the behaviour we want.
Also, remove two unused variables from git-cvsimport.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Simon has asked that the git.git project include the git-p4 project
as at least a contrib/fast-import within git.git. I think it makes
a lot of sense, as git-p4 nicely complements the only other in-tree
fast-import user: import-tars.perl.
git-p4 is offered under the MIT license by its authors.
Raimund Bauer just discovered that the default bash completion for
a local branch name in a git-push line is not the best choice when
the branch does not exist on the remote system.
In the past we have always completed the local name 'test' as
"test:test", indicating that the destination name is the same as
the local name. But this fails when "test" does not yet exist on
the remote system, as there is no "test" branch for it to match
the name against.
Fortunately git-push does the right thing when given just the
local branch, as it assumes you want to use the same name in the
destination repository. So we now offer "test" as the completion
in a git-push line, and let git-push assume that is also the remote
branch name.
We also still support the remote branch completion after the :,
but only if the user manually adds the colon before trying to get
a completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio asked that we don't force the user to have a valid X11 server
configured in $DISPLAY just to obtain the output of `git gui version`.
This makes sense, the user may be an automated tool that is running
without an X server available to it, such as a build script or other
sort of package management system. Or it might just be a user working
in a non-GUI environment and wondering "what version of git-gui do I
have installed?".
Tcl has a lot of warts, but one of its better ones is that a comment
can be continued to the next line by escaping the LF that would have
ended the comment using a backslash-LF sequence. In the past we have
used this trick to escape away the 'exec wish' that is actually a Bourne
shell script and keep Tcl from executing it.
I'm using that feature here to comment out the Bourne shell script and
hide it from the Tcl engine. Except now our Bourne shell script is a
few lines long and checks to see if it should print the version, or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This isn't used right now in git-p4 but I use it in an external script that loads git-p4 as module.
Signed-off-by: Simon Hausmann <shausman@trolltech.com>
Alex Riesen wanted a quieter installation process for git and its
contained git-gui. His earlier patch to do this failed to work
properly when V=1, and didn't really give a great indication of
what the installation was doing.
These rules are a little bit on the messy side, as each of our
install actions is composed of at least two variables, but in the
V=1 case the text is identical to what we had before, while in the
non-V=1 case we use some more complex rules to show the interesting
details, and hide the less interesting bits.
We now can also set QUIET= (nothing) to see the rules that are used
when V= (nothing), so we can debug those too if we have to. This is
actually a side-effect of how we insert the @ into the rules we use
for the "lists of things", like our builtins or our library files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The blame viewer is composed of two different areas, the file
area on top and the commit area on the bottom. If users are
trying to shift the focus it is probably because they want to
shift from one area to the other, so we just setup Tab and
Shift-Tab to jump from the one half to the other in a cycle.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Mark Levedahl <mlevedahl@gmail.com> noted that installation on Cygwin
to /usr/bin can cause problems with the automatic guessing of our
library location. The problem is that installation to /usr/bin
means we actually have:
/usr/bin = c:\cygwin\bin
/usr/share = c:\cygwin\usr\share
So git-gui guesses that its library should be found within the
c:\cygwin\share directory, as that is where it should be relative
to the script itself in c:\cygwin\bin.
In my first version of this patch I tried to use `cygpath` to resolve
/usr/bin and /usr/share to test that they were in the same relative
locations, but that didn't work out correctly as we were actually
testing /usr/share against itself, so it always was equal, and we
always used relative paths. So my original solution was quite wrong.
Mark suggested we just always disable relative behavior on Cygwin,
because of the complexity of the mount mapping problem, so that's
all I'm doing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the remote repository does not have a "current branch", git-clone
was confused and did not set up the resulting new repository
correctly. It did not reset HEAD from the default 'master', and did
not write the SHA1 to the master branch.
Signed-off-by: Nanako Shiraishi <nanako3@bluebottle.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Frank Lichtenheld, Fri, Jun 15, 2007 03:01:53 +0200:
> +test_expect_failure 'req_Root failure (export-all w/o whitelist)' \
> + 'cat request-anonymous | git-cvsserver --export-all pserver >log 2>&1
> + || false'
This does not work, at least for bash in current Ubuntu:
GNU bash, version 3.2.13(1)-release
You have to put "||" on the previous line:
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Collect "unknown" source branches separately and register them at the end.
Also added a minor speed up to splitFilesIntoBranches by breaking out of the loop through all branches when it's safe.
Signed-off-by: Simon Hausmann <simon@lst.de>
ALLOC_GROW now expects the 'nr' argument to be "how much you
want" and not "how much you have". This fixes all cases
where we weren't previously adding anything to the 'nr'.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add_user_info() possibly adds way more than just the commit header line.
In fact, it sometimes needs so much more space that there is a buffer
overrun, leading to an ugly crash. For example, the date is printed in its
own line, and usually takes up more space than the equivalent Unix epoch.
So, for good measure, add 80 characters (a full line) to the allocated
space, in addition to the header line length.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The ALLOC_GROW macro will never let us fill the array completely,
instead allocating an extra chunk if that would be the case. This is
because the 'nr' argument was originally treated as "how much we do have
now" instead of "how much do we want". The latter makes much more
sense because you can grow by more than one item.
This off-by-one never resulted in an error because it meant we were
overly conservative about when to allocate. Any callers which passed
"how much we have now" need to be updated, or they will fail to allocate
enough.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Based on description of commit 477f2b4131
"git log --full-diff" adding this option.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation taken from paraphrased description of "--abbrev[=<n>]"
diff option, and from description of commit 5c51c985 introducing
this option.
Note that to change number of digits one must use "--abbrev=<n>",
which affects [also] diff output.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Note that git log does not understand this option yet:
$ git log --timestamp
fatal: unrecognized argument: --timestamp
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document --stale-fix, used in "git reflog expire --stale-fix --all"
to remove invalid reflog entries, to fix situation after running
non reflog-aware git-prune from an older git in the presence of
reflogs (see RelNotes-1.5.0.txt).
Based on description of commit 1389d9ddaa
"reflog expire --fix-stale"
which introduced this option.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A perforce command with all the files in the repo is generated to get
all the file content.
Here is a patch to break it into multiple successive perforce command
who uses 4K of parameter max, and collect the output for later.
It works, but not for big depos, because the whole perforce depo
content is stored in memory in P4Sync.run(), and it looks like mine is
bigger than 2 Gigs, so I had to kill the process.
[Simon: I added the bit about using SC_ARG_MAX, as suggested by Han-Wen]
Signed-off-by: Benjamin Sergeant <bsergean@gmail.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
Randal L. Schwartz noticed compilation problems on SunOS, which made
me look at the code again. The thing is, h_errno is not used by
connect(2), it is only for functions from netdb.h, like gethostbyname.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/remote:
git-push: Update description of refspecs and add examples
remote.c: "git-push frotz" should update what matches at the source.
remote.c: fix "git push" weak match disambiguation
remote.c: minor clean-up of match_explicit()
remote.c: refactor creation of new dst ref
remote.c: refactor match_explicit_refs()
* fl/cvsserver:
cvsserver: Actually implement --export-all
cvsserver: Let --base-path and pserver get along just fine
cvsserver: Add some useful commandline options
* lh/submodule:
gitmodules(5): remove leading period from synopsis
Add gitmodules(5)
git-submodule: give submodules proper names
Rename sections from "module" to "submodule" in .gitmodules
git-submodule: remember to checkout after clone
t7400: barf if git-submodule removes or replaces a file
You don't need to use string eval to define new functions; assigning a
code reference to the target symbol table is enough.
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Refspecs with no colons are left with no dst value, because they are
interepreted differently for fetch and push. For push, they mean to
reuse the src side. Fix this for patterns.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It turns out that the attribute definition we have had for a
long time to hide "^" character from AsciiDoc 7 was not honored
by AsciiDoc 8 even under "-a asciidoc7compatible" mode. There is
a similar breakage with the "compatible" mode with + characters.
The double colon at the end of definition list term needs
to be attached to the term, without a whitespace. After this
minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with
compatibility mode seems to produce reasonably good results.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes and Marco discovered that "git log -z" spent cycles in diff even
though there is no need to actually compute diffs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original code did not take hierarchical branch names into account at all.
[jc: cherry-picked 11f68d9 from 'master']
Tested-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
$EMAIL is a system-wide setup that is used for many many many
applications. If the git user chose a specific user.email setup,
then _this_ should be honoured rather than $EMAIL.
[jc: cherry-picked ec563e8 from 'master']
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already have two instances where we want to determine if a buffer
contains binary data as opposed to text.
[jc: cherry-picked 6bfce93e from 'master']
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function converts the value of h_errno (last error of name
resolver library, see netdb.h).
One of systems which supposedly do not have the function is SunOS.
POSIX does not mandate its presence.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Asciidoc treats a line starting with a period followed by a title as a
blocktitle element. My introduction of gitmodules(5) unfortunatly broke
the documentation build process due to this processing, since it made
asciidoc generate an illegal (empty) synopsis element. Removing the leading
period fixes the problem and also makes gitmodules(5) use the same synopsis
notation as gitattributes(5).
Noticed-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Embarrassing bug number two in my options patch.
Also enforce that --export-all is only ever used together with an
explicit whitelist. Otherwise people might export every git repository
on the whole system without realising.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Embarassing bug number one in my options patch.
Since the code for --base-path support rewrote
the cvsroot value after comparing it with a possible
existing value (i.e. from pserver authentication)
the check always failed.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
dcommit will still rewrite the HEAD commit and the history of the first
parents of each HEAD~1, HEAD~2, HEAD~3 as it always has.
However, any merge parents (HEAD^2, HEAD^^2, HEAD~2^2) will now be
preserved when the new HEAD and HEAD~[0-9]+ commits are rewritten to SVN
with dcommit. Commits written to SVN will still not have any merge
information besides anything in the commit message.
Thanks to Joakim Tjernlund, Junio C Hamano and Steven Grimm
for explanations, feedback, examples and test case.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also, this fixes a bug where in an odd case a remote named
"config" could get renamed to ".metadata".
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As reported by Matthieu Moy, this is causing svnserve to
terminate connections, because it segfaults.
This test is disabled by default and can be enabled by setting
SVNSERVE_PORT to an unbound (for 127.0.0.1) TCP port in the
environment (in addition to SVN_TESTS=1). I'm not comfortable
with having a test start a daemon by default and take up a port
that could potentially stay running if the test failed.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I hadn't looked at this code in a while and had to read this
again to figure out what it did. To avoid having to do this
again in the future, I just gave gave the hunk a descriptive
name.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pass -C -C option to git-blame so that blame browsing
works when the data is copied over from other files.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The async reading from the pipe was skipping some of the
input lines. Fix the same by making sure that we add the
partial content of the previous read to the newly read
data.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, the code would always set up the excludes, and then manually
pick through the pathspec we were given, assuming that non-added but
existing paths were just ignored. This was mostly correct, but would
erroneously mark a totally empty directory as 'ignored'.
Instead, we now use the collect_ignored option of dir_struct, which
unambiguously tells us whether a path was ignored. This simplifies the
code, and means empty directories are now just not mentioned at all.
Furthermore, we now conditionally ask dir_struct to respect excludes,
depending on whether the '-f' flag has been set. This means we don't have
to pick through the result, checking for an 'ignored' flag; ignored entries
were either added or not in the first place.
We can safely get rid of the special 'ignored' flags to dir_entry, which
were not used anywhere else.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When set, this option will cause read_directory to keep
track of which entries were ignored. While this shouldn't
effect functionality in most cases, it can make warning
messages to the user much more useful.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
so that an ugly commit message like this can be
handled sanely.
Currently, --pretty=oneline and --pretty=email (hence
format-patch) take and use only the first line of the commit log
message. This changes them to:
- Take the first paragraph, where the definition of the first
paragraph is "skip all blank lines from the beginning, and
then grab everything up to the next empty line".
- Replace all line breaks with a whitespace.
This change would not affect a well-behaved commit message that
adheres to the convention of "single line summary, a blank line,
and then body of message", as its first paragraph always
consists of a single line. Commit messages from different
culture, such as the ones imported from CVS/SVN, can however get
chomped with the existing behaviour at the first linebreak in
the middle of sentence right now, which would become much easier
to see with this change.
The Subject: and --pretty=oneline output would become very long
and unsightly for non-conforming commits, but their messages are
already ugly anyway, and thischange at least avoids the loss of
information.
The Subject: line from a multi-line paragraph is folded using
RFC2822 line folding rules at the places where line breaks were
in the original.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Traditionally we had 16kB limit when formatting log messages for
output, because it was easier to arrange for the caller to have
a reasonably big buffer and pass it down without ever worrying
about reallocating.
This changes the calling convention of pretty_print_commit() to
lift this limit. Instead of the buffer and remaining length, it
now takes a pointer to the pointer that points at the allocated
buffer, and another pointer to the location that stores the
allocated length, and reallocates the buffer as necessary.
To support the user format, the error return of interpolate()
needed to be changed. It used to return a bool telling "Ok the
result fits", or "Sorry, I had to truncate it". Now it returns
0 on success, and returns the size of the buffer it wants in
order to fit the whole result.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Aliases changing environment variables (GIT_DIR or
GIT_WORK_TREE) can cause problems:
git has to use GIT_DIR to read the aliases from the config.
After running handle_options for the alias the options of the
alias may have changed environment variables. Depending on
the implementation of setenv the memory location obtained
through getenv earlier may contain the old value or the new
value (or even be used for something else?). To avoid these
problems git errors out if an alias uses any option which
changes environment variables.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is in preparation for keeping two entry lists in the
dir object.
This patch adds and uses the ALLOC_GROW() macro, which
implements the commonly used idiom of growing a dynamic
array using the alloc_nr function (not just in dir.c, but
everywhere).
We also move creation of a dir_entry to dir_entry_new.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
'git-remote show remote-name' lists the refs that are pushed to the remote
by showing the 'Push' line from the config file. But before showing it,
it shortened 'refs/heads/here:refs/heads/there' to 'here:there'. However,
if the Push line is prefixed with a plus, the ref was not shortened.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
/.git or .git is removed from the project name and the
basename of the remaining path is used as the beginning of
the filename and as the directory in the archive.
The regexp will actually not strip off /.git or .git if there
wouldn't be anything left after removing it.
Currently the full project name is used as directory in the
archive and the basename is used as filename. For example a
repository named foo/bar/.git will have a archive named
.git-<version>.* and extract to foo/bar/.git. With this patch
the file is named bar-<version>.* and extracts to bar.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There are only a dozen or so uses of strdup in all of git.
Of those, most seem ok, but this one isn't:
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* aw/cvs:
cvsimport: add <remote>/HEAD reference in separate remotes more
cvsimport: update documentation to include separate remotes option
cvsimport: add support for new style remote layout
This changes the way git-submodule uses .gitmodules: Subsections no longer
specify the submodule path, they now specify the submodule name. The
submodule path is found under the new key "submodule.<name>.path", which is
a required key.
With this change a submodule can be moved between different 'checkout paths'
without upsetting git-submodule.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Rename [module] to [submodule], so that it would be more
forward compatible with the proposed extension by harmonizing
the section names used in .gitmodules and .git/config.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After the initial clone of a submodule, no files would be checked out in
the submodule directory if the submodule HEAD was equal to the SHA-1
specified in the index of the containing repository. This fixes the problem
by simply ignoring submodule HEAD for a fresh clone.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The test for an unmolested file wouldn't fail properly if the file had been
removed or replaced by something other than a regular file. This fixes it.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, a second "-C" on the command line had no effect.
But "--find-copies-harder" is so long to type, let's make doubled -C
enable that option. It is in line with how "git blame" handles such
doubled options to mean "work harder".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
All the other directory location variables do not have the trailing
slash.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Recent git-gui has the ability to determine the location of its library
files relative to the --exec-dir. Its Makefile enables this capability
depending on the install paths that are specified. However, without this
fix there is an extra slash in a path specification, so that the Makefile
does not recognize the equivalence of two paths that it compares.
A side-effect is that all "standard" builds (which do not set $(sharedir)
explicitly) now exploit above mentioned gut-gui feature.
Another side-effect is that an ugly compiled-in double-slash in
$(template_dir) is avoided.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Save geometry before the window layout is damaged
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Include 'war on whitespace' fixes from git.git
This makes --suppress-from actually work when you're unfortunate enough
to have non-ASCII in your name. Also, if there's a match use the optionally
RFC2047 quoted version from the email.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Save geometry before the window layout is damaged
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Include 'war on whitespace' fixes from git.git
Because Tk does not assure us the order that it will process
children in before it destroys the main toplevel we cannot safely
save our geometry data during a "bind . <Destroy>" event binding.
The geometry may have already changed as a result of a one or
more children being removed from the layout. This was pointed
out in gitk by Mark Levedahl, and patched over there by commit
b6047c5a81.
So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when
the window is closed by the user, and forward that close event to
our main do_quit routine.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently git-commit.sh (the command line commit user interface in
core Git) always gives precedence to the prior commit's message if
`commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists.
We actually were doing the same here in git-gui, but the amended
message got lost if $GIT_DIR/MERGE_MSG already existed because
we started a rescan immediately after loading the prior commit's
body into the edit buffer. When that happened the rescan found
MERGE_MSG existed and replaced the commit message buffer with the
contents of that file. This meant the user never saw us pick up
the commit message of the prior commit we are about to replace.
Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by
running `git cherry-pick -n $someid` and then trying to amend the
prior commit in git-gui, thus combining the contents of $someid
with the contents of HEAD, and reusing the commit message of HEAD,
not $someid. With the recent changes to make cherry-pick use the
$GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message
of $someid, not HEAD. Now we always use HEAD if we are amending.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Earlier git.git applied a large "war on whitespace" patch that was
created using 'apply --whitespace=strip'. Unfortunately a few of
git-gui's own files got caught in the mix and were also cleaned up.
That was a6080a0a44.
This patch is needed in git-gui.git to reapply those exact same
changes here, otherwise our version generator script is unable to
obtain our version number from git-describe when we are hosted in
the git.git repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When using git-p4 in this manner:
git-p4 clone //depot/path/project myproject
If "myproject" already exists as a dir, but not a valid git repo, it fails
to create the directory.
Signed-off-by: Kevin Green <Kevin.Green@morganstanley.com>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Internalize symbolic-ref HEAD reading logic
git-gui: Expose the merge.diffstat configuration option
git-gui: Allow users to delete remote branches
git-gui: Allow users to rename branches through 'branch -m'
git-gui: Disable tearoff menus on Windows, Mac OS X
git-gui: Provide fatal error if library is unavailable
git-gui: Enable verbose Tcl loading earlier
git-gui: Show the git-gui library path in 'About git-gui'
git-gui: GUI support for running 'git remote prune <name>'
git gui 0.8.0
* maint: (46 commits)
git-gui: Changed blame header bar background to match main window
git-gui: Favor the original annotations over the recent ones
git-gui: Improve our labeling of blame annotation types
git-gui: Use three colors for the blame viewer background
git-gui: Jump to original line in blame viewer
git-gui: Display both commits in our tooltips
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display the "Loading annotation..." message in italic
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Label the uncommitted blame history entry
git-gui: Switch internal blame structure to Tcl lists
git-gui: Cleanup redundant column management in blame viewer
git-gui: Better document our blame variables
git-gui: Remove unused commit_list from blame viewer
git-gui: Automatically expand the line number column as needed
git-gui: Make the line number column slightly wider in blame
git-gui: Use lighter colors in blame view
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Remove the loaded column from the blame viewer
git-gui: Clip the commit summaries in the blame history menu
...
* 'maint' of git://repo.or.cz/git-gui: (46 commits)
git-gui: Changed blame header bar background to match main window
git-gui: Favor the original annotations over the recent ones
git-gui: Improve our labeling of blame annotation types
git-gui: Use three colors for the blame viewer background
git-gui: Jump to original line in blame viewer
git-gui: Display both commits in our tooltips
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display the "Loading annotation..." message in italic
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Label the uncommitted blame history entry
git-gui: Switch internal blame structure to Tcl lists
git-gui: Cleanup redundant column management in blame viewer
git-gui: Better document our blame variables
git-gui: Remove unused commit_list from blame viewer
git-gui: Automatically expand the line number column as needed
git-gui: Make the line number column slightly wider in blame
git-gui: Use lighter colors in blame view
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Remove the loaded column from the blame viewer
git-gui: Clip the commit summaries in the blame history menu
...
* maint: (38 commits)
git-gui: Changed blame header bar background to match main window
git-gui: Favor the original annotations over the recent ones
git-gui: Improve our labeling of blame annotation types
git-gui: Use three colors for the blame viewer background
git-gui: Jump to original line in blame viewer
git-gui: Display both commits in our tooltips
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display the "Loading annotation..." message in italic
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Label the uncommitted blame history entry
git-gui: Switch internal blame structure to Tcl lists
git-gui: Cleanup redundant column management in blame viewer
git-gui: Better document our blame variables
git-gui: Remove unused commit_list from blame viewer
git-gui: Automatically expand the line number column as needed
git-gui: Make the line number column slightly wider in blame
git-gui: Use lighter colors in blame view
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Remove the loaded column from the blame viewer
git-gui: Clip the commit summaries in the blame history menu
...
Allow choosing between '-c' (combined diff) and '--cc' (compact
combined) diff format in 'commitdiff' view for merge (multiparent)
commits. Default is now '--cc'.
In the bottom part of navigation bar there is link allowing to change
diff format: "combined" for '-c' (when using '--cc') and "compact" for
'--cc' (when using '-c'), just on the right of "raw" link to
'commitdiff_plain" view.
About patchset part of diff --cc output: the difftree (whatchanged
table) has "patch" links to anchors to individual patches (on the same
page). The --cc option further compresses the patch output by
omitting some hunks; when this optimization makes all hunks disappear,
the patch is not shown (like in any other "empty diff" case). But the
fact that patch has been simplified out is not reflected in the raw
(difftree) part of diff output; the raw part is the same for '-c' and
'--cc' options. As correcting difftree is rather out of the question,
as it would require scanning patchset part before writing out
difftree, we add "Simple merge" empty diffs as a place to have anchor
to in place of those simplified out and removed patches.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add links to diff to file ('blobdiff' view) for each of individual
versions of the file in a merge commit to the from-file/to-file header
in the patch part of combined 'commitdiff' view for merges.
The from-file/to-file header for combined diff now looks like:
--- _1_/_git-gui/git-gui.sh_
--- _2_/_git-gui.sh_
+++ b/_git-gui/git-gui.sh_
where _<filename>_ link is link to appropriate version of a file
('blob' view), and _<n>_ is link to respective diff to mentioned
version of a file ('blobdiff' view). There is even hint provided in
the form of title attribute.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of using default, diff(1) like from-file/to-file header for
combined diff (for a merge commit), which looks like:
--- a/git-gui/git-gui.sh
+++ b/_git-gui/git-gui.sh_
(where _link_ denotes [hidden] hyperlink), create from-file(n)/to-file
header, using "--- <n>/_<filename>_" for each of parents, e.g.:
--- 1/_git-gui/git-gui.sh_
--- 2/_git-gui.sh_
+++ b/_git-gui/git-gui.sh_
Test it on one of merge commits involving rename, e.g.
95f97567c1887d77f3a46b42d8622c76414d964d (rename at top)
5bac4a6719 (file from one branch)
This is mainly meant to easier see renames in a merge commit.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This commit makes git_patchset_body easier to read, and reduces level of
nesting and indent level. It adds more lines that it removes because of
extra parameter passing in subroutines, and subroutine calls in
git_patchset_body. Also because there are few added comments.
Below there are descriptions of all split-off subroutines:
Separate formatting "git diff" header into format_git_diff_header_line.
While at it fix it so it always escapes pathname. It would be even more
useful if we decide to use `--cc' for merges, and need to generate by
hand empty patches for anchors.
Separate formatting extended (git) diff header lines into
format_extended_diff_header_line. This one is copied without changes.
Separate formatting two-lines from-file/to-file diff header into
format_diff_from_to_header subroutine. While at it fix it so it always
escapes pathname. Beware calling convention: it takes _two_ lines.
Separate generating %from and %to hashes (with info used among others to
generate hyperlinks) into parse_from_to_diffinfo subroutine. This one is
copied without changes.
Separate checking if file was deleted (and among others therefore does
not have link to the result file) into is_deleted subroutine. This would
allow us to easily change the algotithm to find if file is_deleted in
the result.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Check if 'hp' (hash_parent) parameter to 'commitdiff' view is one of
'h' (hash) commit parents, i.e. if commitdiff is of the form
"<commit>^<n> <commit>", and mark it as such in the bottom part of
navigation bar. The "next" link in commitdiff view was introduced
in commit 151602df00
If 'hb' is n-th parent of 'h', show the following at the bottom
of navigation bar:
(from parent n: _commit_)
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since commit-fb1dde4a we show combined diff for merges in 'commitdiff'
view, and since commit-208ecb2e also in 'commit' view. Sometimes
though one would want to see diff to one of merge commit parents. It
is easy in 'commit' view: in the commit header part there are "diff"
links for each of parent header. This commit adds such links also for
'commitdiff' view.
Add to difftree / whatchanged table row with "1", "2", ... links to
'commitdiff' view for diff with n-th parent for merge commits, as a
table header. This is visible only in 'comitdiff' view, and only for
a merge commit (comit with more than one parent).
To save space links are shown as "n", where "n" is number of a parent,
and not as for example shortened (to 7 characters) sha1 of a parent
commit. To make it easier to discover what links is for, each link
has 'title' attribute explaining the link.
Note that one would need to remember that difftree table in 'commit'
view has one less column (it doesn't have "patch" link column), if one
would want to add such table header also in 'commit' view.
Example output:
1 2 3
Makefile patch | diff1 | diff2 | diff3 | blob | history
cache.h patch | diff1 | diff2 | diff3 | blob | history
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
tutorial: use "project history" instead of "changelog" in header
Documentation: user-manual todo
user-manual: add a missing section ID
Fix typo in remote branch example in git user manual
user-manual: quick-start updates
In the kernel we have a rule for *.c -> *.s files exactly because
it's nice to be able to easily say "ok, what does that generate".
Here's a patch to add such a rule to git too, in case anybody is
interested. It makes it much simpler to just do
make sha1_file.s
and look at the compiler-generated output that way, rather than having to
fire up gdb on the resulting binary.
(Add -fverbose-asm or something if you want to, it can make the result
even more readable)
[jc: add *.s to .gitignore]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The word "changelog" seems a little too much like jargon to me, and beginners
must understand section headers so they know where to look for help.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
In Documentation/user-manual.txt the example
$ git checkout --track -b origin/maint maint
under "Getting updates with git pull", should read
$ git checkout --track -b maint origin/maint
This was noticed by Ron, and reported through
http://bugs.debian.org/427502
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Update text to reflect new position in appendix.
Update the name to reflect the fact that this is closer to reference
than tutorial documentation (as suggested by Jonas Fonseca).
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Make git-mergetool prefer meld under GNOME, and kdiff3 under KDE. When
considering emerge and vimdiff, check $VISUAL and $EDITOR to see which the
user might prefer.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: Josh Triplett <josh@freedesktop.org>
When refactoring code to split one iteration of a too deeply
nested loop into a separate function, it inevitably makes the
indentation levels shallower (that's the sole point of such a
refactoring). With "git blame -w", you can ignore such
re-indentation and pass blame for such moved lines to the
parent.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When two branches are merged that modify a subdirectory (possibly in
different intermediate steps) such that both end up identical, then
rev-list chooses only one branch. But when we filter history, we want to
keep both branches. Therefore, we must use --full-history.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We can use git rev-list --parents when we list the commits to rewrite.
It is not necessary to run git rev-list --parents for each commit in the
loop.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With git-filter-branch --subdirectory-filter <subdirectory> you can
get at the history, as seen by a certain subdirectory. The history
of the rewritten branch will only contain commits that touched that
subdirectory, and the subdirectory will be rewritten to be the new
project root.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier, when the local repository has a branch "frotz" and the
remote repository has a tag "frotz" (but not branch "frotz"),
"git-push frotz" mistakenly updated the tag at the remote side.
This was because the partial refname matching code was applied
independently on both source and destination side.
With this fix, when a colon-less refspec is given to git-push,
we first match it with the refs in the source repository, and
update the matching ref in the destination repository.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git push A:B" is given, and A (or B) is not a full refname
that begins with refs/, we require an unambiguous match with an
existing ref. For this purpose, a match with a local branch or
a tag (i.e. refs/heads/A and refs/tags/A) is called a "strong
match", and any other match is called a "weak match". A partial
refname is unambiguous when there is only one strong match with
any number of weak matches, or when there is only one weak match
and no other match.
However, as reported by Sparse with Ramsay Jones recently,
count_refspec_match() function had a bug where a variable in an
inner block masked a different variable of the same name, which
caused the weak matches to be ignored.
This fixes it, and adds tests for the fix.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When checking what ref the source refspec matches, we have no
business setting the default for the destination, so move that
code lower. Also simplify the result from the code block that
matches the source side by making it set matched_src only upon
unambiguous match.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This refactors open-coded sequence to create a new "struct ref"
and link it to the tail of dst list into a new function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This does not change functionality; just splits one block that
is deeply nested and indented out of a huge loop into a separate
function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In several of the text messages, the tense of the verb is inconsistent.
For example, "Add" vs "Creates". It is customary to use imperative for
command description.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
unzip -v on (at least) Ubuntu prints a screenful of version info
to stdout. Get rid of it since we only want to know if unzip is
installed or not.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
This was moved to the setup_revisions parsing in 7cbcf4d5, so it was
never being triggered.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make git-cvsserver understand some options inspired by
git-daemon, namely --base-path, --export-all, --strict-paths.
Also allow the caller to specify a whitelist of allowed
directories, again similar to git-daemon.
While already adding option parsing also support the common
--help and --version options.
Rationale:
While the gitcvs.enabled configuration option already
offers means to limit git-cvsserver access to a repository,
there are some use cases where other methods of access
control prove to be more useful.
E.g. if setting up a pserver for a collection of public
repositories one might want limit the exported repositories
to exactly the directory this collection is located whithout
having to worry about other repositories that might lie around
with the configuration variable set (never trust your users ;)
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The path submitted with the Root request has to be absolute
(cvs does it this way and it may save us some sanity checks
later)
If multiple roots are specified (e.g. because we use
pserver authentication which will already include the
root), ensure that they say all the same.
Probably neither is a security risk, and neither should ever
be triggered by a sane client, but when validating
input data, it's better to be save than sorry.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Define __slots__ for the Commit class. This reserves space in each Commit
object for only the defined variables. On my system this reduces heap usage
when viewing a kernel repo by 12% ~= 55868 KB.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This changes the Commit class to use new-style class, which has
been available since Python 2.2 (Dec 2001). This is a necessary
step in order to use __slots__[] declaration, so that we can
reduce the memory footprint in the next patch.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although it is not advisable, we have always allowed a branch
and a tag to have the same basename (i.e. it is not illegal to
have refs/heads/frotz and refs/tags/frotz at the same time).
When talking about a specific commit, the interpretation of
'frotz' has always been "use tag and then check branch",
although we warn when ambiguities exist.
However "git checkout $name" is defined to (1) first see if it
matches the branch name, and if so switch to that branch; (2)
otherwise it is an instruction to detach HEAD to point at the
commit named by $name. We did not follow this definition when
$name appeared under both refs/heads/ and refs/tags/ -- we
switched to the branch but read the tree from the tagged commit,
which was utterly bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Otherwise
git push 'remote-name' 'refs/heads/*:refs/remotes/other/*'
will consider references in "refs/heads" of the remote repository
"remote-name", instead of the ones in "refs/remotes/other", which
the given refspec clearly means.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The main window's diff header bar background switched from orange
to gold recently, and I liked the effect it had on readability of
the text. Since I wanted the blame viewer to match, here it is.
Though this probably should be a user defined color, or at least
a constant somewhere that everyone can reference.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Need to use min instead of max for prev/cur to avoid out-of-bounds
string access. Also treat "i" as index of the last match instead of
a length because in case of a complete match of the two strings
i was off by one.
Signed-off-by: Simon Hausmann <shausman@trolltech.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The problem is visible when cloning a local repo. The cloned
repository will have the origin url setup incorrectly: the origin name
will be copied verbatim in origin url of the cloned repository.
Normally, the name is to be expanded into absolute path.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently git-cvsimport tries to create tag objects directly via git-mktag
in a very broken way, e.g the stuff it writes into the tagger field of
the tag object doesn't really resemble the GIT_COMMITTER_IDENT. This makes
gitweb and possibly other tools that try to interpret tag objects to be
confused about tag date and authorship.
Fix this by calling git-tag instead. This also has a nice side effect of
not creating the tag object but only the lightweight tag as that's the only
thing CVS has anyways.
Signed-off-by: Elvis Pranskevichus <el@prans.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently filter-branch exports GIT_DIR only if it is an
relative path but git-sh-setup might also set GIT_DIR to an
absolute path that is not exported yet. Additionally export
GIT_WORK_TREE with GIT_DIR to ensure that cwd is used as
working tree even for bare repositories.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* js/filter:
filter-branch: also don't fail in map() if a commit cannot be mapped
filter-branch: Use rev-list arguments to specify revision ranges.
filter-branch: fix behaviour of '-k'
filter-branch: use $(($i+1)) instead of $((i+1))
chmod +x git-filter-branch.sh
filter-branch: prevent filters from reading from stdin
t7003: make test repeatable
Add git-filter-branch
Additionally there was a similar part calling setenv and getenv
in the same way which missed a check if getenv succeeded.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Up to now to check for a working tree this was used:
!is_bare && !inside_git_dir
(the check for bare is redundant because is_inside_git_dir
returned already 1 for bare repositories).
Now the check is:
inside_work_tree && !inside_git_dir
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
setup_gdg is used as abbreviation for setup_git_directory_gently.
The work tree can be specified using the environment variable
GIT_WORK_TREE and the config option core.worktree (the environment
variable has precendence over the config option). Additionally
there is a command line option --work-tree which sets the
environment variable.
setup_gdg does the following now:
GIT_DIR unspecified
repository in .git directory
parent directory of the .git directory is used as work tree,
GIT_WORK_TREE is ignored
GIT_DIR unspecified
repository in cwd
GIT_DIR is set to cwd
see the cases with GIT_DIR specified what happens next and
also see the note below
GIT_DIR specified
GIT_WORK_TREE/core.worktree unspecified
cwd is used as work tree
GIT_DIR specified
GIT_WORK_TREE/core.worktree specified
the specified work tree is used
Note on the case where GIT_DIR is unspecified and repository is in cwd:
GIT_WORK_TREE is used but is_inside_git_dir is always true.
I did it this way because setup_gdg might be called multiple
times (e.g. when doing alias expansion) and in successive calls
setup_gdg should do the same thing every time.
Meaning of is_bare/is_inside_work_tree/is_inside_git_dir:
(1) is_bare_repository
A repository is bare if core.bare is true or core.bare is
unspecified and the name suggests it is bare (directory not
named .git). The bare option disables a few protective
checks which are useful with a working tree. Currently
this changes if a repository is bare:
updates of HEAD are allowed
git gc packs the refs
the reflog is disabled by default
(2) is_inside_work_tree
True if the cwd is inside the associated working tree (if there
is one), false otherwise.
(3) is_inside_git_dir
True if the cwd is inside the git directory, false otherwise.
Before this patch is_inside_git_dir was always true for bare
repositories.
When setup_gdg finds a repository git_config(git_default_config) is
always called. This ensure that is_bare_repository makes use of
core.bare and does not guess even though core.bare is specified.
inside_work_tree and inside_git_dir are set if setup_gdg finds a
repository. The is_inside_work_tree and is_inside_git_dir functions
will die if they are called before a successful call to setup_gdg.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because of the way objects are sorted in a pack, unpacking them in
disk order is much more efficient than random access. Tests on the
Wine repository show a gain in pack validation time of about 35%.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* sv/objfixes:
Don't assume tree entries that are not dirs are blobs
git-cvsimport: Make sure to use $git_dir always instead of .git sometimes
fix documentation of unpack-objects -n
Accept dates before 2000/01/01 when specified as seconds since the epoch
When scanning the trees in track_tree_refs() there is a "lazy" test
that assumes that entries are either directories or files. Don't do
that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CVS import was failing on a couple repos I was trying to import.
I was setting GIT_DIR=newproj.git and using the -i flag, but this bug
was thwarting the effort... evil CVS.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
unpack-objects -n didn't print the object list as promised on the
manual page, so alter the documentation to reflect the behaviour
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tests with git-filter-branch on a repository that was converted from
CVS and that has commits reaching back to 1999 revealed that it is
necessary to parse dates before 2000/01/01 when they are specified
as seconds since 1970/01/01. There is now still a limit, 100000000,
which is 1973/03/03 09:46:40 UTC, in order to allow that dates are
represented as 8 digits.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The map() function can be used by filters to map a commit id to its
rewritten id. Such a mapping may not exist, in which case the identity
mapping is used (the commit is returned unchanged).
In the rewrite loop, this mapping is also needed, but was done
explicitly in the same way. Use the map() function instead.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A subset of commits in a branch used to be specified by options (-k, -r)
as well as the branch tip itself (-s). It is more natural (for git users)
to specify revision ranges like 'master..next' instead. This makes it so.
If no range is specified it defaults to 'HEAD'.
As a consequence, the new name of the filtered branch must be the first
non-option argument. All remaining arguments are passed to 'git rev-list'
unmodified.
The tip of the branch that gets filtered is implied: It is the first
commit that git rev-list would print for the specified range.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option '-k' says that the given commit and _all_ of its ancestors
are kept as-is.
However, if a to-be-rewritten commit branched from an ancestor of an
ancestor of a commit given with '-k', filter-branch would fail.
Example:
A - B
\
C
If filter-branch was called with '-k B -s C', it would actually keep
B (and A as its parent), but would rewrite C, and its parent.
Noticed by Johannes Sixt.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The expression $((i+1)) is not portable at all: even some bash versions
do not grok it. So do not use it.
Noticed by Jonas Fonseca.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This teaches 'git-submodule init' to register submodule paths and urls in
.git/config instead of actually cloning them. The cloning is now handled
as part of 'git-submodule update'.
With this change it is possible to specify preferred/alternate urls for
the submodules in .git/config before the submodules are cloned.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is just a simple refactoring of modules_init() with no change in
functionality.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When in separate remote mode (via -r <remote>) we can now use
the name HEAD for the CVS HEAD. In keeping with git-clone
remotes/<remote>/HEAD is creates as a symbolic ref to the user
specified name for the HEAD which defaults to master.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document the cvsimport -r <remote> option which switches cvsimport
to using a separate remote for tracking branches.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsimport creates any branches found in the remote CVS repository
in the refs/heads namespace. This makes sense for a repository
conversion. When using git as a sane interface to a remote CVS
repository, that repository may well remain as the 'master'
respository. In this model it makes sense to import the CVS
repository into the refs/remotes namespace.
Add a new option '-r <remote>' to set the remote name for
this import. When this option is specified branches are named
refs/remotes/<remote>/branch, with HEAD named as master matching
git-clone separate remotes layout. Without branches are placed
ion refs/heads, with HEAD named origin as before.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original code did not take hierarchical branch names into account at all.
Tested-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With this option, git-format-patch will generate simple
numbered files as output instead of the default using
with the first commit line appended.
This simplifies the ability to generate an MH-style
drafts folder with each message to be sent.
Signed-off-by: Jon Loeliger <jdl@freescale.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
$EMAIL is a system-wide setup that is used for many many many
applications. If the git user chose a specific user.email setup,
then _this_ should be honoured rather than $EMAIL.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
stdin is the list of commits when the env, tree and index
filter are executed. The filters are not supposed to read
anything from stdin so the best is to give them /dev/null
for reading.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usually when you are looking at blame annotations for a region of
a file you are more interested in why something was originally
done then why it is here now. This is because most of the time
when we get original annotation data we are looking at a simple
refactoring performed to better organize code, not to change its
semantic meaning or function. Reorganizations are sometimes of
interest, but not usually.
We now show the original commit data first in the tooltip. This
actually looks quite nice as the original commit will usually have an
author date prior to the current (aka move/copy) annotation's commit,
so the two commits will now tend to appear in chronological order.
I also found myself to always be clicking on the line of interest
in the file column but I always wanted the original tracking data
and not the move/copy data. So I changed our default commit from
$asim_data (the simple move/copy annotation) to the more complex
$amov_data (the -M -C -C original annotation).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It feels wrong to call the -M -C -C annotations "move/copy tracking"
as they are actually the original locations. So I'm relabeling
the status bar to show "copy/move tracking annotations" for the
current file (no -M -C -C) as that set of annotations tells us who
put the hunk here (who moved/copied it). I'm now calling the -M
-C -C pass "original location annotations" as that's what we're
really digging for.
I also tried to clarify some of the text in the hover tooltip.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To prevent neighboring lines that are different commits from using
the same background color we now use 3 colors and assign them
by selecting the color that is not used before or after the line
in question. We still color "on the fly" as we receive hunks from
git-blame, but we delay our color decisions until we are getting
the original location data (the slower -M -C -C pass) as that is
usually more fine-grained than the current location data.
Credit goes to Martin Waitz for the tri-coloring concept.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the user clicks on a commit link within one of the columns
in the blame viewer we now jump them not just to that commit/file
pair but also to the line of the original file. This saves the
user a lot of time, as they don't need to search through the new
file data for the chunk they were previously looking at.
We also restore the prior view when the user clicks the back button
to return to a pior commit/file pair that they were looking at.
Turned out this was quite tricky to get working in Tk. Every time
I tried to jump the text widgets to the correct locations by way
of the "yview moveto" or "see" subcommands Tk performed the change
until the current event finished dispatching, and then reset the
views back to 0, making the change never take place. Forcing Tk
to run the pending events before we jump the UI resolves the issue.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have commit data from both the simple blame and the
rename/move tracking blame and they differ than there is a
bigger story to tell. We now include data from both commits
so that the user can see that this link as moved, who moved
it, and where it originated from.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now perform two passes over any input file given to the blame
viewer. Our first pass is a quick "git-blame" with no options,
getting the details of how each line arrived into this file. We
are specifically ignoring/omitting the rename detection logic as
this first pass is to determine why things got into the state they
are in.
Once the first pass is complete and is displayed in the UI we run
a second pass, using the much more CPU intensive "-M -C -C" options
to perform extensive rename/movement detection. The output of this
second pass is shown in a different column, allowing the user to see
for any given line how it got to be, and if it came from somewhere
else, where that is.
This is actually very instructive when run on our own lib/branch.tcl
script. That file grew recently out of a very large block of code
in git-gui.sh. The first pass shows when I created that file, while
the second pass shows the original commit information.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user clicks on a line region that we haven't yet received
an annotation for from git-blame we show them "Loading annotation".
But I don't want the user to confuse this loading message with a
commit whose first line is "Loading annotation" and think we messed
up our display somehow. Since we never use italics for anything
else, I'm going with the idea that italic slant can be used to show
data is missing/elided out at the time being.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Calling the commit message pane $w_cmit is a tad confusing when
we also have the $w_cgrp column that shows the abbreviated SHA-1s.
So w_cmit -> w_cviewer, as it is the "commit viewer"; and
w_cgrp -> w_amov as it is the "annotated commit + move tracking"
column. Also changed line_data -> amov_data, as that list is
exactly the results shown in w_amov.
Why call the column "move tracking"? Because this column holds
data from "git blame -M -C". I'm considering adding an additional
column that holds the data from "git blame" without -M/-C, showing
who did the copy/move, and when they did it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user runs the blame viewer on a working directory file
instead of a specific commit-ish then we have no value for the
commit SHA1 or the summary line; this causes the history menu
to get an empty entry at the very bottom. We now look for this
odd case and call the meny entry "Working Directory".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tcl list datatype is significantly faster to work with than
the array type, especially if our indexes are a consecutive set
of numbers, like say line numbers in a file.
This rather large change reorganizes the internal data structure
of the blame viewer to use a proper Tcl list for the annotation
information about a line. Each line is given its own list within
the larger line_data list, where the indexes correspond to various
facts about that particular line.
The interface does seem to be more responsive this way, with less
time required by Tcl to process blame, and to switch to another
version of the same file. It could just be a placebo effect, but
either way most Tcl experts perfer lists for this type of work over
arrays.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The code to handle our three different text widgets is a bit
on the messy side as we issue the same command on all three
widgets one at a time. Adding (or removing) columns from the
viewer is messy, as a lot of locations need to have the new
column added into the sequence, or removed from it.
We also now delete the tags we create for each commit when
we switch to display another "commit:path" pair. This way the
text viewer doesn't get bogged down with a massive number of tags
as we traverse through history.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The array variable "order" used to be used to tell us in what
order each commit was received in. Recent changes have removed
that need for an ordering and the "order" array is now just a
boolean 'do we have that commit yet' flag.
The colors were moved to fields, so they appear inside of the
blame viewer instance. This keeps two different concurrently
running blame viewers from stepping on each other's ordering
of the colors in group_colors.
Most of the other fields were moved around a little bit so
that they are organized by major category and value lifespan.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This list used to store the commits in the order we received
them in. I originally was using it to update the colors of
the commit before and the commit after the current commit,
but since that interface concept turned out to be horribly
ugly and has been removed we no longer need this list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
After we finish reading a chunk of data from the file stream
we know how many digits we need in the line number column to
show the current maximum line number. If our line number column
isn't wide enough, we should expand it out to the correct width.
Any file over our default allowance of 5 digits (99,999 lines)
is so large that the slight UI "glitch" when we widen the column
out is trivial compared to the time it will take Git to fully do
the annotations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most source code files are under 9,999 lines of text, so using a
field width of 5 characters meant that we should have had one char
padding on the left edge (because we right-justify the line number).
Unfortunately when I added the right margin earlier (when I removed
the padding) I ate into the extra character's space, losing the left
margin. This put the line numbers too close to the commit column in
any file with more than 999 lines in it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The colors I originally picked out on a Mac OS X system look a
tad too dark on a Windows 2000 system; the greys are dark enough
to make it difficult to read some lines of text and the green used
to highlight the current commit was also difficult to read text on.
I also added a third grey to the mix, to try and help some files
that wind up with a number of neighboring chunks getting the same
colors.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Mac OS X the OS has "features" that like to draw thick black
borders around the text field that has focus. This is nice if
you want to know where your text is going and are blind as a bat,
but it isn't the best thing to have in a table that is being
faked through the abuse of Tk text widgets.
By setting our takefocus, highlightthickness and padx/y we can
get rid of this border and get our text widgets packed right next
to each other, with no padding between them. This makes the blame
background color smoothly run across the entire line of commit data,
line number and file content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Originally I had placed this loaded column between the line number
and the file line data to help users know if a particular line has
received annotation data or not yet. This way users would know if
the line(s) they were interested in were ready for viewing, or if
they still had to wait. It also was an entertaining way for the
user to spend their time waiting for git-blame --incremental to
compute the complete set of annotations.
However it is completely useless now that we show the abbreviated
commit SHA-1 and author initials in the leftmost column. That area
is empty until we get the annotation data, and as soon as we get it
in we display something there, indicating to the user that there is
now blame data ready. Further with the tooltips the user is likely
to see the data as soon as it comes in, as they are probably not
keeping their mouse perfectly still. So I'm removing the field to
save screen space for more useful things, like file content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some commit lines can get really long when users enter a lot of
text without linewrapping (for example). Rather than letting the
menu get out of control in terms of width we clip the summary to
the first 50+ characters.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently Tk on Mac OS X won't draw a button with an image using a
transparent background. Instead it draws the button using some sort
of 3D effect, even though I asked for no relief and no border. The
background is also not our orange that we expected it to be.
Earlier I had tried this same trick on Windows and it draws the same
way as the button did, so I'm going to switch to the label as that
seems to be more portable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have two commits right next to each other in the final
file and they were kept as different blocks in the leftmost
column then its probably because the original filename was
different. To help the user know where they are digging into
when they click on that link we now show the original file in
the tooltip, but to save space we do so only if the original
file is not the same as the file we are currently viewing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Consecutive chunks of a file could come from the same commit, but
have different original file names. Previously we would have put
them into a single group, but then the hyperlink would jump to only
one of the files, and the other would not be accessible. Now we can
get to the other file too.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
gitweb has long had a feature where the user can click on any
commit the blame display and go visit that commit's information
page. From the user could go get the blame display for the file
they are tracking, and try to digg through the history of any
part of the code they are interested in seeing.
We now offer somewhat similiar functionality in git-gui. The 4
digit commit abreviation in the first column of our blame view is
now offered as a hyperlink if the commit isn't the one we are now
viewing the blame output for (as there is no point in linking back
to yourself). Clicking on that link will stop the current blame
engine (if still running), push the new target commit onto the
history stack, and restart the blame viewer at that commit, using
the "original file name" as supplied by git-blame for that chunk
of the output.
Users can navigate back to a version they had been viewing before
by way of a back button, which offers the prior commits in a popup
menu displayed right below the back button. I'm always showing the
menu here as the cost of switching between views is very high; you
don't want to jump to a commit you are not interested in looking at
again.
During switches we throw away all data except the cached commit data,
as that is relatively small compared to most source files and their
annotation marks. Unfortunately throwing this per-file data away in
Tcl seems to take some time; I probably should move the line indexed
arrays to proper lists and use [lindex] rather than the array lookup
(usually lists are faster).
We now start the git-blame process using "nice", so that its priority
will drop hopefully below our own. If I don't do this the blame engine
gets a lot of CPU under Windows 2000 and the git-gui user interface is
almost non-responsive, even though Tcl is just sitting there waiting
for events.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Computing the blame records for a large file with a long project
history can take git a while to run; traditionally we have shown
a little meter in the status area of our blame viewer that lets
the user know how many lines have been finished, and how far we
are through the process.
Usually such progress indicators are drawn with a little progress
bar in the window, where the bar shows how much has been completed
and hides itself when the process is complete. I'm using a very
simple hack to do that: draw a canvas with a filled rectangle.
Of course the time remaining has absolutely no relationship to the
progress meter. It could take very little time for git-blame to get
the first 90% of the file, and then it could take many times that to
get the remaining 10%. So the progress meter doesn't really have any
sort of assurances that it relates to the true progress of the work.
But in practice on some ugly history it does seem to hold a reasonable
indicator to the completion status. Besides, its amusing to watch and
that keeps the user from realizing git is being somewhat slow.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
At one point I tried to present the blame viewer to an audience of
people on a 640 by 480 pixel LCD projector. This did not work at
all as the top area (the file data) was taking up all of the screen
realestate and the split point was not adjustable by the user. In
general locking the user into a specific ratio of display is just
not user friendly.
So we now place a split pane control into the middle of our blame
window, so the user can adjust it to their current needs. If the
window increases (or decreases) in height we assign the difference
to the file data area, as that is generally the area of the window
that users are trying to see more of when they grow the window.
Unfortunately there appears to be a bug in the "pack" layout manager
in Tcl/Tk 8.4.1. The status bar and the lower commit pane was being
squashed if the window decreased in height. I think the pack manager
was just not decreasing the size of the panedwindow slave properly if
the main window shrank. Switching to the "grid" layout manager fixes
the problem, but is slightly uglier setup code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Frequently when I'm looking at blocks of code in the blame
viewer I want to know who is the culprit, or who I should
be praising for a job well done. The tooltips nicely show
this if I mouse over a block, but it doesn't work to get
this detail at a glance.
Since we don't use the leftmost commit column for anything
after the first line within a commit group I'm now tossing
the author's initials into that field, right justified. It
is quite clearly not a SHA-1 number as we always show the
SHA-1 in lowercase, while we explicitly select only the
uppercase characters from an author's name field, and only
those that are following whitespace.
I'm using initials here over anything else as they are quite
commonly unique within small development teams. The leading
part of the email address field was out for some of the teams
I work with, as there the email addresses are all of the form
"Givenname.Surname@initech.com". That will never fit into the
4 characters available.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The | in the continued lines of the same commit group as not
easily seen on the left edge; putting a single space in front
of the pipe makes it slightly more visually appealing to me as
I can follow the line down through the group to the next commit
marker.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we no longer redraw colors every time we select a particular
commit there is no need to redraw the screen after we get a new commit
in from blame --incremental.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The selected commit's blame header is now drawn in green, using
the same background color that is shown in the main file content
viewer. The result is a much better looking commit pane, as we
use bold for header "keys" and proportional width fonts for the
stuff that doesn't need to be fixed width to maintain its formatting.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the mouse is over a particular line and we have blame data
for that line, but its not the active commit, we should show the
user information about that commit like who the author was and
what the subject (first line) was.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we don't allow the user to select text from the file
viewer right now I'm disabling the normal text cursor and
putting in a plain arror instead. This way users don't
think they can select and copy text, because they can't.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If two consecutive lines in the final file came from the same commit
then we store a "|" in the first column rather than the commit id,
for the second and subsequent lines in that block. This cleans up
the interface so runs associated with the same commit can be more
easily seen visually.
We also now use the abbreviation "work" for the uncommitted stuff in
your working directory, rather than "0000". This looks nicer to the
eyes and explains pretty quickly what is going on.
There was also a minor bug in the commit abbreviation column for the
last line of the file. This is now also fixed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-gui blame viewer has always been ugly as s**t. Linus Torvalds
suggested the coloring scheme I'm using here, which is two different
shades of grey for the background colors, and black text on a pale green
background for the currently selected/focused commit.
The difference is a massive improvement. The interface no longer will
cause seizures in people who are prone to that sort of thing. It no
longer uses a very offensive hot pink. The green being current actually
makes sense. And not having the background of the other non-current
lines change when you change the current commit is really a big deal.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The blame viewer has this silly blank line at the bottom of it;
we really don't want to see it displayed as we will never get
any blame data for that line (it doesn't exist in the source).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A lot of this code was pre-class, which meant that I just sort of
copied and pasted my way through it, rather than being really smart
and using a variable for each widget's path name. Since we have a
field for each path, we can use those throughout the constructor
and make things a lot neater.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now show the first 4 digits of each commit in the left most
column of our blame viewer, before the line numbers. These are
drawn as the data becomes available from git-blame --incremental,
and helps the user to visually group lines together.
I'm using only the first 4 digits because within a given cluster
of lines its unlikely that two neighboring commits will have the
same 4 digit prefix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The default font was already bold, so marking the selected file with bold
font did not work. Change that to lightgray background.
Also, the header colors are now softer, giving better readability.
Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We already have two instances where we want to determine if a buffer
contains binary data as opposed to text.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb assumes that everything is in UTF-8. If a text contains invalid
UTF-8 character sequences, the text must be in a different encoding.
This commit introduces $fallback_encoding which would be used as input
encoding if gitweb encounters text with is not valid UTF-8.
Add basic test for this in t/t9500-gitweb-standalone-no-errors.sh
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Tested-by: Alexandre Julliard <julliard@winehq.org>
Tested-by: Ismail Dönmez <ismail@pardus.org.tr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The <pattern> for -l is now a shell pattern, not a list of grep parameters.
Option -l may be repeated with another <pattern>.
The new -n [<num>] option specifies how many lines from
the annotation are to be printed.
Not specifieing -n or -n 0 will just produce the tag names
Just -n or -n 1 will show the first line of the annotation on
the tag line.
Other valuse for -n will show that number of lines from the annotation.
The exit code used to indicate if any tag was found.
This is changed due to a different implementation.
A good way to test a tag for existence is to use:
git show-ref --quiet --verify refs/tags/$TAGNAME
Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This script is derived from Pasky's cg-admin-rewritehist.
In fact, it _is_ the same script, minimally adapted to work without cogito.
It _should_ be able to perform the same tasks, even if only relying on
core-git programs.
All the work is Pasky's, just the adaption is mine.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Hopefully-signed-off-by: Petr "cogito master" Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make people aware of our testsuite, and of non-ASCII encodings.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Revert "Make the installation target of git-gui a little less chatty"
git-gui: Verify Tcl/Tk is new enough for our needs
git-gui: Attach font_ui to all spinbox widgets
This reverts commit c289f6fa1f.
Junio pointed out that Alex's change breaks in some cases, like
when V=1, and is more verbose than it should be even if that worked.
I'm backing it out and redoing it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For quite a while we have been assuming the user is running on
a Tcl/Tk 8.4 or later platform. This may not be the case on
some very old systems. Unfortunately I am pretty far down the
path of using the Tcl/Tk 8.4 commands and options and cannot
easily work around them to support earlier versions of Tcl/Tk.
So we'll check that we are using the correct version up front,
and if not we'll stop with a related error message.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Earlier I missed making sure our spinbox widgets used the same font
as the other widgets around them. This meant that using a main font
with a size of 20 would make every widget in the options dialog huge,
but the spinboxes would be left with whatever the OS native font is.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch unifies the write_index_file functions in
builtin-pack-objects.c and index-pack.c. As the name
"index" is overloaded in git, move in the direction of
using "idx" and "pack idx" when refering to the pack index.
There should be no change in functionality.
Signed-off-by: Geert Bosch <bosch@gnat.com>
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test tries to verify basic sanity of git-submodule, i.e. that it is
able to clone and update a submodule repository, that its status output is
sane, and that it barfs when the submodule path is occupied during init.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/pack:
fix repack with --max-pack-size
builtin-pack-object: cache small deltas
git-pack-objects: cache small deltas between big objects
builtin-pack-objects: don't fail, if delta is not possible
* sp/pack:
Style nit - don't put space after function names
Ensure the pack index is opened before access
Simplify index access condition in count-objects, pack-redundant
Test for recent rev-parse $abbrev_sha1 regression
rev-parse: Identify short sha1 sums correctly.
Attempt to delay prepare_alt_odb during get_sha1
Micro-optimize prepare_alt_odb
Lazily open pack index files on demand
The command is part of the main porcelain making git-add more
appropriate.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Use =20 when rfc2047 encoding spaces.
Create a new manpage for the gitignore format, and reference it elsewhere
Documentation: robustify asciidoc GIT_VERSION replacement
Encode ' ' using '=20' even though rfc2047 allows using '_' for
readability. Unfortunately, many programs do not understand this and
just leave the underscore in place. Using '=20' seems to work better.
[jc: with adjustment to t3901]
Signed-off-by: Kristian Høgsberg <hoegsberg@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only git-ls-files(1) describes the gitignore format in detail, and it does so
with reference to git-ls-files options. Most users don't use the plumbing
command git-ls-files directly, and shouldn't have to look in its manpage for
information on the gitignore format.
Create a new manpage gitignore(5) (Documentation/gitignore.txt), and factor
out the gitignore documentation into that file, changing it to refer to
.gitignore and $GIT_DIR/info/exclude as used by porcelain commands. Reference
gitignore(5) from other relevant manpages and documentation. Remove
now-redundant information on exclude patterns from git-ls-files(1), leaving
only information on how git-ls-files options specify exclude patterns and what
precedence they have.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of using sed on the resulting file, we now have a
git_version asciidoc attribute. This means that we don't
pipe the output of asciidoc, which means we can detect build
failures.
Problem reported by Scott Lamb, solution suggested by Jonas Fonseca.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Its wrong to exit the application if we destroy a random widget
contained withing something else; especially if its some small
trivial thing that has no impact on the overall operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To improve performance on fork+exec impoverished systems (such as
Windows) we want to avoid running git-symbolic-ref on every rescan
if we can do so. A quick way to implement such an avoidance is to
just read the HEAD ref ourselves; we'll either see it as a symref
(starts with "ref: ") or we'll see it as a detached head (40 hex
digits). In either case we can treat that as our current branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt pointed out that dropping to 0 lines of context
does allow the user to get more fine-grained hunk selection,
especially since we don't currently support "highlight and
apply (or revert)".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
- import into master/local if --import-local is set
- use Die() for exiting
- if --verbose is set, raise Exception()
- use joined strings iso. `list` for progress printing
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Commit 83572c1a91 changed many
realloc to xrealloc. This change was made in diff-delta.c too,
although the code can handle an out of memory failure.
This patch reverts this change in diff-delta.c.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-config: Improve documentation of git-config file handling
git-config: Various small fixes to asciidoc documentation
decode_85(): fix missing return.
fix signed range problems with hex conversions
* maint-1.5.1:
git-config: Improve documentation of git-config file handling
git-config: Various small fixes to asciidoc documentation
decode_85(): fix missing return.
fix signed range problems with hex conversions
The description which files git-config uses and how the various
command line options and environment variables affect its
behaviour was incomplete, outdated and confusing.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add '' around the only mentioned commandline option that didn't
have it.
Make reference to section EXAMPLE a link and rename it to
EXAMPLES because it actually contains a lot of examples.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Jon Smirl said:
| Once an object reference hits a pack file it is very likely that
| following references will hit the same pack file. So first place to
| look for an object is the same place the previous object was found.
This is indeed a good heuristic so here it is. The search always start
with the pack where the last object lookup succeeded. If the wanted
object is not available there then the search continues with the normal
pack ordering.
To test this I split the Linux repository into 66 packs and performed a
"time git-rev-list --objects --all > /dev/null". Best results are as
follows:
Pack Sort w/o this patch w/ this patch
-------------------------------------------------------------
recent objects last 26.4s 20.9s
recent objects first 24.9s 18.4s
This shows that the pack order based on object age has some influence,
but that the last-used-pack heuristic is even more significant in
reducing object lookup.
Signed-off-by: Nicolas Pitre <nico@cam.org> --- Note: the
--max-pack-size to git-repack currently produces packs with old objects
after those containing recent objects. The pack sort based on
filesystem timestamp is therefore backward for those. This needs to be
fixed of course, but at least it made me think about this variable for
the test.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Two issues here:
1) git-repack -a --max-pack-size=10 on the GIT repo dies pretty quick.
There is a lot of confusion about deltas that were suposed to be
reused from another pack but that get stored undeltified due to pack
limit and object size doesn't match entry->size anymore. This test
is not really worth the complexity for determining when it is valid
so get rid of it.
2) If pack limit is reached, the object buffer is freed, including when
it comes from a cached delta data. In practice the object will be
stored in a subsequent pack undeltified, but let's make sure no
pointer to freed data subsists by clearing entry->delta_data.
I also reorganized that code a bit to make it more readable.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use a generic make rule to build all the test programs, rather than
specifically mentioning each one.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user has no branches at all (their refs/heads/ is empty)
and they are on a detached HEAD we have a valid repository but
there are no branches to populate into the branch pulldown in
the create branch dialog. Instead of erroring out we can skip
that part of the dialog, much like we do with tracking branches
or tags when the user doesn't have any.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the function detected an invalid base85 sequence, it issued
an error message but forgot to return error status at that point
and kept going.
Signed-off-by: Jerald Fitzjerald <jfj@freemail.gr>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make hexval_table[] "const". Also make sure that the accessor
function hexval() does not access the table with out-of-range
values by declaring its parameter "unsigned char", instead of
"unsigned int".
With this, gcc can just generate:
movzbl (%rdi), %eax
movsbl hexval_table(%rax),%edx
movzbl 1(%rdi), %eax
movsbl hexval_table(%rax),%eax
sall $4, %edx
orl %eax, %edx
for the code to generate a byte from two hex characters.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- print commands with \n
- extractDepotPathsAndChangeFromGitLog -> extractSettings, returning
dict.
- store keepRepoPath in [git-p4: ] line
- create a main() function, so git-p4 can be pychecked
- use --destination for clone destination. This simplifies logic
for --keep-path
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Our style is to not put a space after a function name. I did here,
and Junio applied the patch with the incorrect formatting. So I'm
cleaning up after myself since I noticed it upon review.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In this particular location of fsck the index should have already
been opened by verify_pack, which is called just before we get
here and loop through the object names. However, just in case a
future version of that function does not use the index file we'll
double-check its open before we access the num_objects field.
Better safe now than sorry later.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My earlier lazy index opening patch changed this condition to check
index_data and call open_pack_index if it was NULL. In truth we only
care about num_objects. Since open_pack_index does no harm if the
index is already open, and all indexes are likely to be closed in
this application, the "performance optimization" of inlining the
index_data check here was wrong.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
My recent patch "Lazily open pack index files on demand" caused a
regression in the case of parsing abbreviated SHA-1 object names.
Git was unable to translate the abbreviated name into the full name
if the object was packed, as the pack .idx files were not opened
before being accessed.
This is a simple test to repack a repository then test for an
abbreviated SHA-1 within the packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
find_short_packed_object was not loading the pack index files.
Teach it to do so.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Creating deltas between big blobs is a CPU and memory intensive task.
In the writing phase, all (not reused) deltas are redone.
This patch adds support for caching deltas from the deltifing phase, so
that that the writing phase is faster.
The caching is limited to small deltas to avoid increasing memory usage very much.
The implemented limit is (memory needed to create the delta)/1024.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If builtin-pack-objects runs out of memory while finding
the best deltas, it bails out with an error.
If the delta index creation fails (because there is not enough memory),
we can downgrade the error message to a warning and continue with the
next object.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* db/remote:
Move refspec pattern matching to match_refs().
Update local tracking refs when pushing
Add handlers for fetch-side configuration of remotes.
Move refspec parser from connect.c and cache.h to remote.{c,h}
Move remote parsing into a library file out of builtin-push.
* jc/nodelta:
builtin-pack-objects: remove unnecessary code for no-delta
Teach "delta" attribute to pack-objects.
pack-objects: pass fullname down to add_object_entry()
* ar/run:
Allow environment variables to be unset in the processes started by run_command
Add ability to specify environment extension to run_command
Add run_command_v_opt_cd: chdir into a directory before exec
* maint:
cvsserver: Fix some typos in asciidoc documentation
cvsserver: Note that CVS_SERVER can also be specified as method variable
cvsserver: Correct inetd.conf example in asciidoc documentation
user-manual: fixed typo in example
Add test case for $Id$ expanded in the repository
git-svn: avoid md5 calculation entirely if SVN doesn't provide one
Makefile: Remove git-fsck and git-verify-pack from PROGRAMS
Fix stupid typo in lookup_tag()
git-gui: Guess our share/git-gui/lib path at runtime if possible
Correct key bindings to Control-<foo>
git-gui: Tighten internal pattern match for lib/ directory
Since this is a trivial variation of the general pserver
authentication, there is really no reason not to support
it.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we are too fast with our changes, the file in
the working copy might still have the same mtime
as noted in the CVS/Entries. This will cause CVS
to happily report to the server that the file is
unmodified which can lead to data loss (and in
our case test failure).
CVS sucks!
Work around that by sleeping for a second.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On one particular system I like to keep a cluster of bare Git
repositories and spawn new-workdirs off of them. Since the bare
repositories don't have working directories associated with them
they don't have a .git/ subdirectory that hosts the repository we
are linking to.
Using a bare repository as the backing repository for a workdir
created by this script does require that the user delete core.bare
from the repository's configuration file, so that Git auto-senses
the bareness of a repository based on pathname information, and
not based on the config file.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier commit d63bd9a broke the case where more than one input
files are fed to mailsplit by not incrementing the base counter
when splitting second and subsequent input files. This should
fix it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reasonably new versions of the cvs CLI client allow one to
specifiy CVS_SERVER as a method variable directly in
CVSROOT. This is way more convinient than using an
environment variable since it gets saved in CVS/Root.
Since I only discovered this by accident I guess there
might be others out there that learnt CVS on the 1.11
series (or even earlier) and profit from such a note
about cvs improvements in the last couple years.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While the given example worked, it made us look rather
incompetent. Give the correct reason why one needs the
more complex syntax and change the example to reflect
that.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test case would have caught the bug fixed by revision
c23290d5.
It puts various forms of $Id$ into a file in the repository,
without allowing git to collapse them to uniformity. Then enables the
$Id$ expansion on checkout, and checks that what is checked out has
coped with the various forms.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There's no point in calculating an MD5 if we're not going to use
it. We'll also avoid the possibility of there being a bug in the
Perl MD5 library not being able to handle zero-sized files.
This is a followup to 20b3d206ac,
which allows us to track repositories that do not provide MD5
checksums.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Guess our share/git-gui/lib path at runtime if possible
Correct key bindings to Control-<foo>
git-gui: Tighten internal pattern match for lib/ directory
Those are builtins. Remove them from PROGRAMS variable
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recently git-merge learned to avoid generating the diffstat after
a merge by reading the merge.diffstat configuration option. By
default this option is assumed to be true, as that is the old
behavior. However we can force it to false by setting it as a
standard boolean option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git has supported remote branch deletion for quite some time, but
I've just never gotten around to supporting it in git-gui. Some
workflows have users push short-term branches to some remote Git
repository, then delete them a few days/weeks later when that topic
has been fully merged into the main trunk. Typically in that style
of workflow the user will want to remove the branches they created.
We now offer a "Delete..." option in the Push menu, right below the
generic "Push..." option. When the user opens our generic delete
dialog they can select a preconfigured remote, or enter a random
URL. We run `git ls-remote $url` to obtain the list of branches and
tags known there, and offer this list in a listbox for the user to
select one or more from.
Like our local branch delete dialog we offer the user a way to filter
their selected branch list down to only those branches that have been
merged into another branch. This is a very common operation as the
user will likely want to select a range of topic branches, but only
delete them if they have been merged into some sort of common trunk.
Unfortunately our remote merge base detection is not nearly as strict
as the local branch version. We only offer remote heads as the test
commit (not any local ones) and we require that all necessary commits
to successfully run git-merge-base are available locally. If one or
more is missing we suggest that the user run a fetch first.
Since the Git remote protocol doesn't let us specify what the tested
commit was when we evaluated our decision to execute the remote delete
there is a race condition here. The user could do a merge test against
the trunk, determine a topic branch was fully merged, but before they
can start pushing the delete request another user could fast-forward
the remote topic branch to a new commit that is not merged into the
trunk. The delete will arrive after, and remove the topic, even though
it was not fully merged.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git's native command line interface has had branch renaming
support for quite a while, through the -m/-M options to the
git-branch command line tool. This is an extremely useful
feature as users may decide that the name of their current
branch is not an adequate description, or was just entered
incorrectly when it was created.
Even though most people would consider git-branch to be a
Porcelain tool I'm using it here in git-gui as it is the
only code that implements the rather complex set of logic
needed to successfully rename a branch in Git. Currently
that is along the lines of:
*) Backup the ref
*) Backup the reflog
*) Delete the old ref
*) Create the new ref
*) Move the backed up reflog to the new ref
*) Record the rename event in the reflog
*) If the current branch was renamed, update HEAD
*) If HEAD changed, record the rename event in the HEAD reflog
*) Rename the [branch "$name"] section in the config file
Since that is some rather ugly set of functionality to implement
and get right, and some of it isn't easily accessible through the
raw plumbing layer I'm just cheating by relying on the Porcelain.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Windows and Mac OS X platforms do not generally use the tearoff
menu feature found on traditional X11 based systems. On Windows the
Tk engine does support the feature, but it really is out of place and
just confuses people who aren't used to working on a UNIX system. On
Mac OS X its not supported for the root menu bar and its submenus, as
it doesn't fit into the overall platform UI model.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we cannot locate our git-gui library directory, or we find it
but the tclIndex file is not present there (or it is present but
is not something we are allowed to read) the user cannot use the
application. Rather than silently ignoring the errors related to
the tclIndex file being unavailable we report them up front and
display to the user why we cannot start.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are using our "non-optimized" tclIndex format (which is
just a list of filenames, in the order necessary for source'ing)
we are doing all of our loading before we even tested to see if
GITGUI_VERBOSE was set in the environment. This meant we never
showed the files as we sourced them into the environment.
Now we setup our overloaded auto_load and source scripts before
we attempt to define our library path, or source the scripts that
it mentions. This way GITGUI_VERBOSE is always honored if set.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we now try to automatically guess the library directory
in certain installations users may wonder where git-gui is getting
its supporting files from. We now display this location in our
About dialog, and we also include the location we are getting our
Git executables from.
Unfortunately users cannot use this 'About git-gui' dialog to
troubleshoot library loading problems; the dialog is defined by
code that exists in the library directory, creating a catch-22.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In some workflows it is common for a large number of temporary
branches to be created in a remote repository, get fetched to
clients that typically only use git-gui, and then later have
those branches deleted from the remote repository once they have
been fully merged into all destination branches. Users of git-gui
would obviously like to have their local tracking branches cleaned
up for them, otherwise their local tracking branch namespace would
grow out of control.
The best known way to remove these tracking branches is to run
"git remote prune <remotename>". Even though it is more of a
Porcelain command than plumbing I'm invoking it through the UI,
because frankly I don't see a reason to reimplement its ls-remote
output filtering and config file parsing.
A new configuration option (gui.pruneduringfetch) can be used to
automatically enable running "git remote prune <remotename>" after
the fetch of that remote also completes successfully. This is off
by default as it require an additional network connection and is
not very fast on Cygwin if a large number of tracking branches have
been removed (due to the 2 fork+exec calls per branch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt asked me to try to avoid embedding the runtime location
of git-gui's library directory in the executable script. Not embedding
it helps the MinGW to be relocatable to another directory should a user
wish to install the programs in a directory other than the location the
packager wanted them to be installed into.
Most of this is a hack. We try to determine if the path of our master
git-gui script will be able to locate the lib by ../share/git-gui/lib.
This should be true if $(gitexecdir) and $(libdir) have the same prefix.
If they do then we defer the assignment of $(libdir) until runtime, and
we get it from $argv0 rather than embedding it into the script itself.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is actually nothing left from the original LibXDiff code I used
over 2 years ago, and even the GIT implementation has diverged quite a
bit from LibXDiff's at this point. Let's update the copyright notice
to better reflect that fact.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Martin Koegler noted that create_delta() performs a new hash lookup
after every block copy encoding which are currently limited to 64KB.
In case of larger identical blocks, the next hash lookup would normally
point to the next 64KB block in the reference buffer and multiple block
copy operations will be consecutively encoded.
It is however possible that the reference buffer be sparsely indexed if
hash buckets have been trimmed down in create_delta_index() when hashing
of the reference buffer isn't well balanced. In that case the hash
lookup following a block copy might fail to match anything and the fact
that the reference buffer still matches beyond the previous 64KB block
will be missed.
Let's rework the code so that buffer comparison isn't bounded to 64KB
anymore. The match size should be as large as possible up front and
only then should multiple block copy be encoded to cover it all.
Also, fewer hash lookups will be performed in the end.
According to Martin, this patch should reduce his 92MB pack down to 75MB
with the dataset he has.
Tests performed on the Linux kernel repo show a slightly smaller pack and
a slightly faster repack.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not every input value passed to get_sha1 is an abbreviated SHA-1.
Its actually quite common for refs to be passed and for those
refs to resolve to full SHA-1s, in which case we may not need to
initialize the alternate object database list in this process.
I'm relocating the call to prepare_alt_odb closer to the code
that actually needs it to maintain the fix first introduced by
Junio in 99a19b43 (to avoid ambiguous SHA-1 abbreviations from
being accepted). This allows us to avoid the alt_odb list setup
if we won't actually need it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Calling getenv() is not that expensive, but its also not free,
and its certainly not cheaper than testing to see if alt_odb_tail
is not null.
Because we are calling prepare_alt_odb() from within find_sha1_file
every time we cannot find an object file locally we want to skip out
of prepare_alt_odb() as early as possible once we have initialized
our alternate list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In some repository configurations the user may have many packfiles,
but all of the recent commits/trees/tags/blobs are likely to
be in the most recent packfile (the one with the newest mtime).
It is therefore common to be able to complete an entire operation
by accessing only one packfile, even if there are 25 packfiles
available to the repository.
Rather than opening and mmaping the corresponding .idx file for
every pack found, we now only open and map the .idx when we suspect
there might be an object of interest in there.
Of course we cannot known in advance which packfile contains an
object, so we still need to scan the entire packed_git list to
locate anything. But odds are users want to access objects in the
most recently created packfiles first, and that may be all they
ever need for the current operation.
Junio observed in b867092f that placing recent packfiles before
older ones can slightly improve access times for recent objects,
without degrading it for historical object access.
This change improves upon Junio's observations by trying even harder
to avoid the .idx files that we won't need.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This command can be used to initialize, update and inspect submodules. It
uses a .gitmodules file, readable by git-config, in the top level directory
of the 'superproject' to specify a mapping between submodule paths and
repository url.
Example .gitmodules layout:
[module "git"]
url = git://git.kernel.org/pub/scm/git/git.git
With this entry in .gitmodules (and a commit reference in the index entry for
the path "git"), the command 'git submodule init' will clone the repository
at kernel.org into the directory "git".
Known issues
============
There is currently no way to override the url found in the .gitmodules file,
except by manually creating the subproject repository. The place to fix this
in the script has a rather long comment about a possible plan.
Funny paths will be quoted in the output from git-ls-files, but git-submodule
does not attempt to unquote (or even detect the presence of) such paths.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This just basically creates a "pack_refs()" function that could be used by
anybody. You pass it in the flags you want as a bitmask (PACK_REFS_ALL and
PACK_REFS_PRUNE), and it will do all the heavy lifting.
Of course, it's still static, and it's all in the builtin-pack-refs.c
file, so it's not actually visible to the outside, but the next step would
be to just move it all to a library file (probably refs.c) and expose it.
Then we could easily make "git gc" do this too.
While I did it, I also made it check the return value of the fflush and
fsync stage, to make sure that we don't overwrite the old packed-refs file
with something that got truncated due to write errors!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Fix git-svn to handle svn not reporting the md5sum of a file, and test.
Fix mishandling of $Id$ expanded in the repository copy in convert.c
More echo "$user_message" fixes.
Add tests for the last two fixes.
git-commit: use printf '%s\n' instead of echo on user-supplied strings
git-am: use printf instead of echo on user-supplied strings
Documentation: Add definition of "evil merge" to GIT Glossary
Replace the last 'dircache's by 'index'
Documentation: Clean up links in GIT Glossary
* maint-1.5.1:
Fix git-svn to handle svn not reporting the md5sum of a file, and test.
More echo "$user_message" fixes.
Add tests for the last two fixes.
git-commit: use printf '%s\n' instead of echo on user-supplied strings
git-am: use printf instead of echo on user-supplied strings
Documentation: Add definition of "evil merge" to GIT Glossary
Replace the last 'dircache's by 'index'
Documentation: Clean up links in GIT Glossary
This means that send-pack and http-push will support pattern refspecs,
so builtin-push.c doesn't have to expand them, and also git push can
just turn --tags into "refs/tags/*", further simplifying
builtin-push.c
check_ref_format() gets a third "conditionally okay" result for
something that's valid as a pattern but not as a particular ref.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the repository contained an expanded ident keyword (i.e. $Id:XXXX$),
then the wrong bytes were discarded, and the Id keyword was not
expanded. The fault was in convert.c:ident_to_worktree().
Previously, when a "$Id:" was found in the repository version,
ident_to_worktree() would search for the next "$" after this, and
discarded everything it found until then. That was done with the loop:
do {
ch = *cp++;
if (ch == '$')
break;
rem--;
} while (rem);
The above loop left cp pointing one character _after_ the final "$"
(because of ch = *cp++). This was different from the non-expanded case,
were cp is left pointing at the "$", and was different from the comment
which stated "discard up to but not including the closing $". This
patch fixes that by making the loop:
do {
ch = *cp;
if (ch == '$')
break;
cp++;
rem--;
} while (rem);
That is, cp is tested _then_ incremented.
This loop exits if it finds a "$" or if it runs out of bytes in the
source. After this loop, if there was no closing "$" the expansion is
skipped, and the outer loop is allowed to continue leaving this
non-keyword as it was. However, when the "$" is found, size is
corrected, before running the expansion:
size -= (cp - src);
This is wrong; size is going to be corrected anyway after the expansion,
so there is no need to do it here. This patch removes that redundant
correction.
To help find this bug, I heavily commented the routine; those comments
are included here as a bonus.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates t4014 to check the two fixes for git-am and git-commit
we observed with "echo" that does backslash interpolation by default
without being asked with -e option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the same issue git-am had, which was fixed by Jeff
King in the previous commit. Cleverly enough, this commit's log
message is a good test case at the same time.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Under some implementations of echo (such as that provided by
dash), backslash escapes are recognized without any other
options. This means that echo-ing user-supplied strings may
cause any backslash sequences in them to be converted. Using
printf resolves the ambiguity.
This bug can be seen when using git-am to apply a patch
whose subject contains the character sequence "\n"; the
characters are converted to a literal newline. Noticed by
Szekeres Istvan.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that the default delta depth is 50, it is a good idea to also bump
MAX_CHAIN to 50.
While at it, make the display a bit prettier by making the MAX_CHAIN
limit inclusive, and display the number of deltas that are above that
limit at the end instead of the beginning.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ensure that the same link is not repeated in single glossary entry,
and that there is no self-link i.e. link to current entry.
Add links to other definitions in git glossary.
Remove inappropriate (nonsense) links, or change link to link to
correct definition (to correct term).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The diffstat can be controlled either with command-line options
(--summary|--no-summary) or with merge.diffstat. The default is
left as it was: diffstat is active by default.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also, the patch makes the error messages more verbose. Helps when
diagnosing connect problems on weird systems.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I believe noone uses git-applymbox, and noone definitely should, since it
is supposed to be completely superseded and everything by its younger
cousin git-am. The only known person in the universe to use it was Linus
and he declared some time ago that he will try to use git-am instead in his
famous dotest script.
The trouble is that git-applymbox existence creates confusing UI. I'm a bit
like a recycled newbie to the git porcelain and *I* was confused by
git-applymbox primitiveness until I've realized a while later that I'm of
course using the wrong command.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
fix memory leak in parse_object when check_sha1_signature fails
name-rev: tolerate clock skew in committer dates
Update bash completion for git-config options
Teach bash completion about recent log long options
Teach bash completion about 'git remote update'
Update bash completion header documentation
Remove a duplicate --not option in bash completion
Teach bash completion about git-shortlog
Hide the plumbing diff-{files,index,tree} from bash completion
Update bash completion to ignore some more plumbing commands
* 'master' of git://repo.or.cz/git/fastimport:
Update bash completion for git-config options
Teach bash completion about recent log long options
Teach bash completion about 'git remote update'
Update bash completion header documentation
Remove a duplicate --not option in bash completion
Teach bash completion about git-shortlog
Hide the plumbing diff-{files,index,tree} from bash completion
Update bash completion to ignore some more plumbing commands
The packfile portion of the "remove redundant" code
near the bottom of git-repack.sh is broken when
pack splitting occurs. Particularly since this is
the only place where we automatically delete packfiles,
make sure it works properly for all cases, old or new.
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I've taught myself to use "git gc" instead of doing the repack explicitly,
but it doesn't actually do what I think it should do.
We've had packed refs for a long time now, and I think it just makes sense
to pack normal branches too. So I end up having to do
git pack-refs --all --prune
in order to get a nice git repo that doesn't have any unnecessary files.
So why not just do that in "git gc"? It's not as if there really is any
downside to packing branches, even if they end up changing later. Quite
often they don't, and even if they do, so what?
Also, make the default for refs packing just be an unambiguous "do it",
rather than "do it by default only for non-bare repositories". If you want
that behaviour, you can always just add a
[gc]
packrefs = notbare
in your ~/.gitconfig file, but I don't actually see why bare would be any
different (except for the broken reason that http-fetching used to be
totally broken, and not doing it just meant that it didn't even get
fixed in a timely manner!).
So here's a trivial patch to make "git gc" do a better job. Hmm?
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When check_sha1_signature fails, program is not terminated:
it prints an error message and returns NULL, so the
buffer returned by read_sha1_file should be freed before.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In git.git repository, "git-name-rev v1.3.0~158" cannot name the
rev, while adjacent revs can be named.
This was because it gives up traversal from the tips of existing
refs as soon as it sees a commit that has older commit timestamp
than what is being named. This is usually a good heuristics,
but v1.3.0~158 has a slightly older commit timestamp than
v1.3.0~157 (i.e. it's child), as these two were made in a
separate repostiory (in fact, in a different continent).
This adds a hardcoded slop value (1 day) to the cut-off
heuristics to work this kind of problem around. The current
algorithm essentially runs around from the available tips down
to ancient commits and names every single rev available that are
newer than cut-off date, so a single day slop would not add that
much overhead in repositories with long enough history where the
performance of name-rev matters.
I think the algorithm could be made a bit smarter by deepening
the graph on demand as a new commit is asked to be named (this
would require rewriting of name_rev() function not to recurse
itself but use a traversal list like revision.c traverser does),
but that would be a separate issue.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Alberto Bertogli reported on #git that git-gui was exiting with
alt-q, while gitk on the same system was exiting with ctrl-q.
That was not what I wanted. I really wanted M1B to be bound to
the Control key on most non-Mac OS X platforms, but according to
Sam Vilain M1 on most systems means alt. Since gitk always does
control, I'm doing the same thing for all non-Mac OS X systems.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A few new configuration options grew out of the woodwork during the
1.5.2 series. Most of these are pretty easy to support a completion
of, so we do so.
I wanted to also add completion support for the <driver> part of
merge.<driver>.name but to do that we have to look at all of the
.gitattributes files and guess what the unique set of <driver>
strings would be. Since this appears to be non-trivial I'm punting
on it at this time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
(Somewhat) recently git-log learned about --reverse (to show commits
in the opposite order) and a looong time ago I think it learned
about --raw (to show the raw diff, rather than a unified diff).
These are both useful options, so we should make them easy for the
user to complete.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently the git-remote command grew an update subcommand, which
can be used to execute git-fetch across multiple repositories
in a single step. These can be configured with the 'remotes.*'
configuration options, so we can offer completion for any name that
matches and appears to be useful to git-remote update.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To unset a variable, just specify its name, without "=". For example:
const char *env[] = {"GIT_DIR=.git", "PWD", NULL};
const char *argv[] = {"git-ls-files", "-s", NULL};
int err = run_command_v_opt_cd_env(argv, RUN_GIT_CMD, ".", env);
The PWD will be unset before executing git-ls-files.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is no way to specify and override for the environment:
there'd be no user for it yet.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It can make code simplier (no need to preserve cwd) and safer
(no chance the cwd of the current process is accidentally forgotten).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
1) Added a note about supporting the long options for most commands,
as we have been doing so for quite some time.
2) Include a notice that these routines are covered by the GPL,
as that may not be obvious, even though they are distributed
as part of the core Git distribution.
3) Added a short section on how to send patches to the routines,
and to whom they should get sent to. Currently that is me,
as I am the active maintainer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This was just me being silly; I put the --not option into the
completion list twice. There's no duplicates shown in the shell
as the shell removes them before showing them to the user. But we
really don't need the duplicates in the source script either.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We've had completion for git-log for quite some time, but just
today I noticed we don't have it for the new builtin shortlog
that runs git-log internally. This is indeed a handy thing to
have completion for, especially when your branch names are of
the Very-Very-Long-and-Hard/To-Type/Variety/That-Some-Use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The diff-* programs are meant to be plumbing for the diff frontend;
most end users aren't invoking these commands directly. Consequently
we should avoid showing them as possible completions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When e8438420bb allowed us to reload
the marks table on subsequent runs of fast-import we really broke
things, as we set pack_id to MAX_PACK_ID for any objects we imported
into the marks table. Creating a branch from that mark should fail
as we attempt to read the object through a non-existant packed_git
pointer. Instead we have to use the normal Git object system to
locate the older commit, as we ourselves do not have a reference
to the packed_git it resides in.
This bug only occurred because t9300 was not complete enough.
When we added the --import-marks feature we didn't actually test
its implementation enough to verify the function worked as intended.
I have corrected that, and included the changes as part of this fix.
Prior versions of fast-import fail the new test(s); this commit
allows them to pass.
Credit for this bug find goes to Simon Hausmann <simon@lst.de> as
he recently identified a similiar bug in the tree lazy-loading path.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To resolve a corner case uncovered by Simon Hausmann I need to
reuse the logic for the SHA-1 expression version of the 'from '
command within the mark version of the 'from ' command. This change
doesn't alter any functionality, but is merely breaking the common
code out to a function that I can reuse.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commit a5c1780a03 sets the pack_id of existing
objects to MAX_PACK_ID. When the same object is referenced later again it is
found in the local object hash. With such a pack_id fast-import should not try
to locate that object in the newly created pack(s).
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Fix uninitialized last_object->no_free variable that is accessed in
store_object.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-archive already knows how to generate an archive as a tar or a zip
file, but gitweb did not. zip archvies are much more usable in a Windows
environment due to native support and this patch allows a site admin the
option to deliver zip rather than tar files. The selection is done by
inserting
$feature{'snapshot'}{'default'} = ['x-zip', 'zip', ''];
in gitweb_config.perl.
Tar files remain the default option.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Explain the special code for detecting a corner-case error,
and complain about --stdout & --max-pack-size being used together.
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This works in repositories that have their refs packed by
"git-pack-refs --all --prune" whereas testing the file
$git_dir/refs/heads/$opt_o does not.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The parser was inconsistently done, in that it did not look at
the last command line parameter to see if it could be an unknown
option, although it was designed to notice unknown options if
they were given in positions the command expects to find them
(i.e. everything except the last parameter, which ought to be
<commit-ish>). This prevented a very natural invocation
$ git cherry-pick --usage
from issuing the usage help.
Signed-off-by: Junio C Hamano <junkio@cox.net>
As we do not consider objects marked as "no-delta" early, there
is no point to check if the other objects already in the delta
window are marked as such -- "no-delta" objects will not enter
the window to begin with.
Pointed out by Nico.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch documents the branch.autosetupmerge config option, added
by commit 0746d19a.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Our GITGUI_LIBDIR macro was testing only for @@ at the start of
the path, assuming nobody would ever find that to be a reasonable
prefix for a directory to install our library into. That is most
likely a valid assumption, but its even more unlikely they would
have the start be @@GITGUI_ and the end be @@. Note that we
cannot use the full string here because that would get expanded
by the sed replacement in our Makefile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
While we can easily test the cvs <-> git-cvsserver
communication with :fork: and git-cvsserver server
there are some pserver specifics we should test, too.
Currently this are two tests of the pserver authentication.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add some cvs update tests that include various merge
situations. Also add a basic test for update -C
since it fits so well in there.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a few test cases for the config file parsing
done by git-cvsserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches pack-objects to use .gitattributes mechanism so
that the user can specify certain blobs are not worth spending
CPU cycles to attempt deltification.
The name of the attrbute is "delta", and when it is set to
false, like this:
== .gitattributes ==
*.jpg -delta
they are always stored in the plain-compressed base object
representation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of giving a hash for grouping, pass fullname to add_object_entry().
I want to add "do not try deltifying this object" bit to object_entry based on
the settings in .gitattributes, and hashing the name down too early would
interfere with that plan.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Often users want to know not which tagged version a commit came
after, but which tagged version a commit is contained within.
This latter task is the job of git-name-rev, but most users are
looking to git-describe to do the job.
Junio suggested we make `git describe --contains` run the correct
tool, `git name-rev`, and that's exactly what we do here. The output
of name-rev was adjusted slightly through the new --name-only option,
allowing describe to execv into name-rev and maintain its current
output format.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the per-method enable logic disables the access, we should
not even look at the global one.
git-cvsserver.perl | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-add reads this variable, and honours the contents of that file if that
exists. Match this behaviour in git-status, too.
Noticed by Evan Carroll on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We do not appreciate C99 initializers, declarations after statements,
or "0" instead of "NULL".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Note: since the consequence of failure is to call die,
I don't bother to close "f".
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not all projects use the convention that one tabstop = 8 characters, and
a common convention is to use one tabstop = one level of indent. For such
projects, using 8 characters per tabstop often shows too much whitespace
per indent. This allows the user to configure the number of characters
to use per tabstop.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
When adjusting fontsize (using ctrl+/-), all panes except the lower right
were updated. This fixes that.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Cygwin's tk by default uses a very dark selection background color that
makes the currently selected text almost unreadable. On linux, the default
selection background is a light gray which is very usable. This makes the
default a light gray everywhere but allows the user to configure the
color as well.
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The earlier code removed one newline too many from the hunk that
adds new lines at the end of the file. Also the way the code
counted the added blank lines was somewhat roundabout; I think
the way updated code does it is more direct and easier to
follow:
* We keep track of the number of blank lines added;
* While processing each line, we notice if it adds a blank
line, and increment the counter, or reset it to zero
otherwise;
* When actually we apply the data, we remove the empty lines we
counted earlier if we are applying it at the end of the
file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
[sp: Modified Jonas' original patch to keep checkout-index
as a a valid completion.]
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add --max-pack-size parsing and usage messages.
Upgrade git-repack.sh to handle multiple packfile names,
and build packfiles in GIT_OBJECT_DIRECTORY not GIT_DIR.
Update documentation.
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rewrite write_pack_file() to break to a new packfile
whenever write_object/write_one request it, and
correct the header's object count in the previous packfile.
Change write_index_file() to write an index
for just the objects in the most recent packfile.
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With --max-pack-size, generate the appropriate write limit
for each object and check against it before each group of writes.
Update delta usability rules to handle base being in a previously-
written pack. Inline sha1write_compress() so we know the
exact size of the written data when it needs to be compressed.
Detect and return write "failure".
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add "pack_size_limit", the limit specified by --max-pack-size,
"written_list", the list of objects written to the current pack,
and "nr_written", the number of objects in written_list.
Put "base_name" at file scope again and add forward declarations.
Move write_index_file() call from cnd_pack_objects() to
write_pack_file() since only the latter will know how
many times to call write_index_file().
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
update=0 suppressed writing the final SHA-1 but was not used.
Now final=0 suppresses SHA-1 finalization, SHA-1 writing,
and closing -- in other words, only flush the buffer.
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add -l/--long option to git-ls-tree command, which displays
object size of a blob entry. Object size is placed after
object id (left-justified with minimum width of 7 characters).
For non-blob entries `-' is used.
Rationale: for non-blob entries size of an object has no much
meaning, and is not very interesting. Moreover, in planned
pack v4 tree objects would be constructed on demand, so tree
size would need to be calculated.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This also adds a --remote option to send-pack, which specifies the
configured remote being used. It is provided automatically by
git-push, and must match the url (which is still needed, since there
could be multiple urls).
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
These follow the pattern of the push side configuration, but aren't
taken from anywhere else, because git-fetch is still in shell.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new parser is different from the one in builtin-push in two ways:
the default is to use the current branch's remote, if there is one,
before "origin"; and config is used in preference to remotes.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: with an obvious microfix to avoid doing this unless --whitespace=strip]
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch introduces --extended-regexp and --regexp-ignore-case options to
tune what kind of patterns the pattern-limiting options (--grep, --author,
...) accept.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test runs gitweb (git web interface) as CGI script from
commandline, and checks that it would not write any errors
or warnings to log.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
annotate: make it work from subdirectories.
git-config: Correct asciidoc documentation for --int/--bool
t1300: Add tests for git-config --bool --get
unpack-trees.c: verify_uptodate: remove dead code
Use PATH_MAX instead of TEMPFILE_PATH_LEN
branch: fix segfault when resolving an invalid HEAD
* maint-1.5.1:
annotate: make it work from subdirectories.
git-config: Correct asciidoc documentation for --int/--bool
t1300: Add tests for git-config --bool --get
unpack-trees.c: verify_uptodate: remove dead code
Use PATH_MAX instead of TEMPFILE_PATH_LEN
branch: fix segfault when resolving an invalid HEAD
The asciidoc documentation seemed to indicate that type specifiers
are honoured on writing operations which they aren't. Make this
more clear.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed that there were only tests for --int, but not
for --bool. Add some.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Caused by return value of resolve_ref being passed directly
to xstrdup whereby the sanity checking was never reached.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
applying them to a Perforce checkout. This should make it possible to apply git
commits with binary files that cannot be handled by path.
Signed-off-by: Simon Hausmann <simon@lst.de>
* np/pack:
deprecate the new loose object header format
make "repack -f" imply "pack-objects --no-reuse-object"
allow for undeltified objects not to be reused
I didn't have a chance to test the off-by-default minimize-url
stuff enough before, but it's quite broken for people passing
the --trunk/-T, --tags/-t, --branches/-b switches to "init" or
"clone" commands.
Additionally, follow-parent functionality seems broken when we're
not connected to the root of the repository.
Default behavior for "traditional" git-svn users who only track
one directory (without needing follow-parent) should be
reasonable, as those users started using things before
minimize-url functionality existed.
Behavior for users more used to the git-svnimport-like command
line will also benefit from a more-flexible command-line than
svnimport given the assumption they're working with
non-restrictive read permissions on the repository.
I hope to properly fix these bugs when I get a chance to in the
next week or so, but I would like to get this stopgap measure of
reverting to the old behavior as soon as possible.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When sorting directory names by depth (slash ("/") count) and
closing the deepest directories first (as the protocol
requires), we failed to put the root baton (with an empty string
as its key "") after top-level directories (which did not have
any slashes).
This resulted in svnserve being in a situation it couldn't
handle and caused a segmentation fault on the remote server.
This bug did not affect users of DAV and filesystem repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Confirmed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The todo list at the end of the user manual says that something must be
said about .gitignore. Also, there seems to be a lack of documentation
on how to choose between the various types of ignore files (.gitignore
vs. .git/info/exclude, etc.).
This patch adds a section on ignoring files which try to introduce how
to tell git about ignored files, and how the different strategies
complement eachother.
The syntax of exclude patterns is explained in a simplified manner, with
a reference to git-ls-files(1) which already contains a more thorough
explanation.
Signed-off-by: Johan Herland <johan@herland.net>
Another amusing git exploration example brought up in irc. (Credit to
aeruder for the complete solution.)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I don't really want to look like we're encouraging the shared repository
thing. Take down some of the argument for using purely
single-developer-owned repositories and collaborating using patches and
pulls instead.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The embarassing history of this tutorial is that I started it without
really understanding the index well, so I avoided mentioning it.
And we all got the idea that "index" was a word to avoid using around
newbies, but it was reluctantly mentioned that *something* had to be
said. The result is a little awkward: the discussion of the index never
actually uses that word, and isn't well-integrated into the surrounding
material.
Let's just go ahead and use the word "index" from the very start, and
try to demonstrate its use with a minimum of lecturing.
Also, remove discussion of using git-commit with explicit filenames.
We're already a bit slow here to get people to their first commit, and
I'm not convinced this is really so important.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Mention the user manual, especially as an alternative introduction for
user's mainly interested in read-only operations.
And fix a typo while we're there.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Initial (root) commit has no parents, and $co{'parent'} is
undefined. Use '--root' for initial commit.
This fixes "Use of uninitialized value in open at gitweb/gitweb.perl
line 4925." warning.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'maint' of git://linux-nfs.org/~bfields/git:
user-manual: reorganize public git repo discussion
user-manual: listing commits reachable from some refs not others
user-manual: introduce git
user-manual: add a "counting commits" example
user-manual: move howto/using-topic-branches into manual
user-manual: move howto/make-dist.txt into user manual
Documentation: remove howto's now incorporated into manual
user-manual: move quick-start to an appendix
glossary: expand and clarify some definitions, prune cross-references
user-manual: revise birdseye-view chapter
Add a birdview-on-the-source-code section to the user manual
Sorry, this was inadverently introduced by my grep search patch. It causes
annoying "redefined" warnings.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-rev-list(1) talks about patterns as values for the
--grep, --committed etc. parameters, without going into detail.
This patch mentions that these patterns are actually regexps.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitattributes.txt says, of the crlf attribute:
Set::
Setting the `crlf` attribute on a path is meant to mark
the path as a "text" file. 'core.autocrlf' conversion
takes place without guessing the content type by
inspection.
That is to say that the crlf attribute does not force the file to have
CRLF line endings, instead it removes the autocrlf guesswork and forces
the file to be treated as text. Then, whatever line ending is defined
by the autocrlf setting is applied.
However, that is not what convert.c was doing. The conversion to CRLF
was being skipped in crlf_to_worktree() when the following condition was
true:
action == CRLF_GUESS && auto_crlf <= 0
That is to say conversion took place when not in guess mode (crlf attribute
not specified) or core.autocrlf set to true. This was wrong. It meant
that the crlf attribute being on for a given file _forced_ CRLF
conversion, when actually it should force the file to be treated as
text, and converted accordingly. The real test should simply be
auto_crlf <= 0
That is to say, if core.autocrlf is falsei (or input), conversion from
LF to CRLF is never done. When core.autocrlf is true, conversion from
LF to CRLF is done only when in CRLF_GUESS (and the guess is "text"), or
CRLF_TEXT mode.
Similarly for crlf_to_worktree(), if core.autocrlf is false, no conversion
should _ever_ take place. In reality it was only not taking place if
core.autocrlf was false _and_ the crlf attribute was unspecified.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As noted by Johan Herland, git-archive is a kind of checkout and needs
to apply any checkout filters that might be configured.
This patch adds the convenience function convert_sha1_file which returns
a buffer containing the object's contents, after converting, if necessary
(i.e. it's a combination of read_sha1_file and convert_to_working_tree).
Direct calls to read_sha1_file in git-archive are then replaced by calls
to convert_sha1_file.
Since convert_sha1_file expects its path argument to be NUL-terminated --
a convention it inherits from convert_to_working_tree -- the patch also
changes the path handling in archive-tar.c to always NUL-terminate the
string. It used to solely rely on the len field of struct strbuf before.
archive-zip.c already NUL-terminates the path and thus needs no such
change.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Helping a couple people set up public repos recently, I wanted to point
them at this piece of the user manual, but found it wasn't as helpful as
it could be:
- It starts with a big explanation of why you'd want a public
repository, not necessary in their case since they already knew
why they wanted that. So, separate that out.
- It skimps on some of the git-daemon details, and puts the http
export information first. Fix that.
Also group all the public repo subsections into a single section, and do
some miscellaneous related editing.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Move howto/using-topic-branches into the user manual as an example for
the "sharing development" chapter. While we're at it, remove some
discussion that's covered in earlier chapters, modernize somewhat (use
separate-heads setup, remotes, replace "whatchanged" by "log", etc.),
and replace syntax we'd need to explain by syntax we've already covered
(e.g. old..new instead of new ^old).
The result may not really describe what Tony Luck does any more.... Hope
that's not annoying.
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
There seems to be a perception that the howto's are bit-rotting a
little. The manual might be a more visible location for some of them,
and make-dist.txt seems like a good candidate to include as an example
in the manual.
For now, incorporate much of it verbatim. Later we may want to update
the example a bit.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
These two howto's have both been copied into the manual. I'd rather not
maintain both versions if possible, and I think the user-manual will be
more visible than the howto directory. (Though I wouldn't mind some
duplication if people really like having them here.)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The quick start interrupts the flow of the manual a bit. Move it to
"appendix A" but add a reference to it in the preface. Also rename the
todo chapter to "appendix B", and revise the preface a little.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Revise and expand some of the definitions in the glossary, based in part
on a recent thread started by a user looking for help with some of the
jargon. I've borrowed some of the language from Linus's email on that
thread. (I'm assuming standing permission to plagiarize Linus's
email....)
Also start making a few changes to mitigate the appearance of
"circularity" mentioned in that thread:
- feel free to use somewhat longer definitions and to explain
some things more than once instead of relying purely on
cross-references
- don't use cross-references when they're redundant: eliminate
self-references and repeated references to the same entry.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Some revisions suggested by Junio along with some minor style fixes and
one compile fix (asterisks need escaping).
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Currently, there are rather draconian restrictions on the strings accepted
by the pickaxe search, which degrades its usefulness for digging in code
significantly. This patch remedies mentioned limitation.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'grep' type of search greps the currently selected tree for given
regexp and shows the results in a fancy table with links into blob view.
The number of shown matches is limited to 1000 and the whole feature
can be turned off (grepping linux-2.6.git already makes repo.or.cz a bit
unhappy).
This second revision makes it in documentation explicit that grep accepts
regexps, and makes grep accept extended regexps instead of basic regexps.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, searchbar font was as big as the page heading font, because
font-size was made relative - but to the parent element, which was for some
reason indeed page_header. Since that seems to be illogical to me, I just
moved the div.search outside of div.page_header. I'm no CSS/DOM expert but
no adverse effects were observed by me.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
During the discussion of core.excludesfile in the user-manual, I realized
that the configuration wasn't mentioned in the man pages.
Signed-off-by: Michael Hendricks <michael@ndrix.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Checking if $diffinfo->{'status'} is equal 'D' is no longer the way to
check if the file was deleted in result. For merge commits
$diffinfo->{'status'} is reference to array of statuses for each
parent. Use the fact that $diffinfo->{'to_id'} is all zeros as sign
that file was deleted in result.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis pointed out the main git.git repository's Makefile dies
now if git-gui 0.7.0-rc1 or later is being used and TCL_PATH was not
set to a working tclsh program path. This breaks people who may have
a working build configuration today and suddenly upgrade to the latest
git release.
The tclIndex is required for git-gui to load its associated lib files,
but using the Tcl auto_load procedure to source only the files we need
is a performance optimization. We can emulate the auto_load by just
source'ing every file in that directory, assuming we source class.tcl
first to initialize our crude class system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
to use for the current import by looking at the p4 tags. The current approach of using
the log message works better.
Signed-off-by: Simon Hausmann <simon@lst.de>
it's creating a new branch from itself. It's a sensible error in general but
in the case of incremental imports we have to apply force :)
Signed-off-by: Simon Hausmann <simon@lst.de>
mutt version 1.5.14 (perhaps earlier versions too) permits alias files to have
white space before the 'alias' keyword.
Signed-off-by: Michael Hendricks <michael@ndrix.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In http://thread.gmane.org/gmane.comp.version-control.git/42479,
a birdview on the source code was requested.
J. Bruce Fields suggested that my reply should be included in the
user manual, and there was nothing of an outcry, so here it is,
not 2 months later.
It includes modifications as suggested by J. Bruce Fields, Karl
Hasselström and Daniel Barkalow.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Earlier commit 4280cde95f made gitweb
show "No differences found" message for empty diff, for the HTML
output. But for merge commits, either -c format we use or --cc format,
empty diff doesn't mean no differences, but trivial merge.
Show "Trivial merge" message instead of "No differences found" for
merges.
While at it reword conditional in the code for easier reading.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git notify the user about host resolution/connection attempts.
This is useful both as a progress indicator on slow links, and helps
reassure the user there are no firewall problems.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
format-patch: add MIME-Version header when we add content-type.
Fixed link in user-manual
import-tars: Use the "Link indicator" to identify directories
git name-rev writes beyond the end of malloc() with large generations
Documentation/branch: fix small typo in -D example
Separate search text, which is saved in $searchtext global variable,
and is used in links, as default value for the textfield in search
form, and for pickaxe search, from search regexp, which is saved in
$search_regexp global variable, and is used as parameter to --grep,
--committer or --author options to git-rev-list, and for searching
commit body in gitweb. For now $search_regexp is unconditionallt
equal to quotemeta($searchtext), meaning that we always search for
fixed string.
This fixes bug where 'next page' links for 'search' view didn't work
for searchtext containing quotable characters, like `@'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
David Kågedal proposed that gitweb should explicitely request
being somewhat smaller than normal, because it has good use for
long lines. However gitweb presents a table with several
columns, so having wider line is OK for it. Therefore explicit
'font-size: small' would make sense. Apparently many people on
the list seem to agree with him.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, we used the mode to determine if a name was associated with
a directory. This fails, since some tar programs do not set the mode
correctly. However, the link indicator _has_ to be set correctly.
Noticed by Chris Riddoch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch fixes all calls to xread() where the return value is not
stored into an ssize_t. The patch should not have any effect whatsoever,
other than putting better/more appropriate type names on variables.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The return value from xread() is ssize_t.
Paolo Teti <paolo.teti@gmail.com> pointed out that in this case, the
signed return value was assigned to an unsigned type (size_t). This patch
fixes that.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using git name-rev on my kernel tree I triggered a malloc()
corruption warning from glibc.
apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin
*** glibc detected *** malloc(): memory corruption: 0x0bff8950 ***
Aborted
This comes from name_rev() which is building the name of the revision
in a malloc'd string, which it sprintf's into:
char *new_name = xmalloc(len + 8);
[...]
sprintf(new_name, "%.*s~%d^%d", len, tip_name,
generation, parent_number);
This allocation is only sufficient if the generation number is
less than 5 digits, in my case generation was 13432. In reality
parent_number can be up to 16 so that also can require two digits,
reducing us to 3 digits before we are at risk of blowing this
allocation.
This patch introduces a decimal_length() which approximates the
number of digits a type may hold, it produces the following:
Type Longest Value Len Est
---- ------------- --- ---
unsigned char 256 3 4
unsigned short 65536 5 6
unsigned long 4294967296 10 11
unsigned long long 18446744073709551616 20 21
char -128 4 4
short -32768 6 6
long -2147483648 11 11
long long -9223372036854775808 20 21
This is then used to size the new_name.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Runtime is now independent of the number of modified files.
The old implementation executed 'cvs status' for each file touched by the patch
to be applied. The new code calls 'cvs status' only once with all touched files
and parses cvs's output to collect all available status information.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$Id$ is present already in SVN and CVS; it would mean that people
converting their existing repositories won't have to make any changes to
the source files should they want to make use of the ident attribute.
Given that it's a feature that's meant to calm those very people, it
seems obtuse to make them edit every file just to make use of it.
I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
monotone has $Id$ on its wishlist. I can't think of a good reason not
to stick with the de-facto standard and call ours $Id$ instead of
$ident$.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Prepare for 1.5.1.5 Release Notes
gitweb: Add a few comments about %feature hash
git-am: Clean up the asciidoc documentation
Documentation: format-patch has no --mbox option
builtin-log.c: Fix typo in comment
Fix git-clone buglet for remote case.
Hopefully we will have 1.5.2 soonish, to contain all of these,
but we should summarize what we have done regardless.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add --keep to synopsis.
The synopsys used a mix of tabs and spaces, unify to use only
spaces.
Shuffle options around in synopsys and description for grouping
them logically.
Add more gitlink references to other commands.
Various grammatical fixes and improvements.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-applymbox and git-mailinfo refer to a --mbox option of
git-format-patch when talking about their -k options. But there
is no such option. What -k does to the former two commands is
to keep the Subject: lines unmunged, meant to be used on output
generated with format-patch -k.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
c2f599e09f introduced a buglet while
cloning from a remote URL; we forgot to squelch the unnecessary
error message when we try to cd to the given "remote" name,
in order to see if it is a local directory.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After we send I HATE YOU we should probably exit and not happily
continue with I LOVE YOU and further communication.
Most clients will probably just exit and ignore everything we
send after the I HATE YOU and it is not a security problem
either because we don't really care about the user name anyway.
But it is still the right thing to do.
[jc: with a minor fixup to its exit code...]
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: "Martin Langhoff" <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Split description of pretty formats into list of pretty options
(--pretty and --encoding) in new file Documentation/pretty-options.txt
and description of formats itself as a separate "PRETTY FORMATS"
section in pretty-formats.txt
While at it correct formatting a bit, to be better laid out in the
resulting manpages: git-rev-list(1), git-show(1), git-log(1) and
git-diff-tree(1). Those manpages now include pretty options in the
same place as it was before, and description of formats just after
all options.
Inspired by the split into two filesdocumentation for merge strategies:
Documentation/merge-options.txt and Documentation/merge-strategies.txt
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix it so gitweb doesn't write "Use of unitialized value..." warnings
(which gets written in web server logs) for empty (no commits)
repository.
In empty repository "last change" (last activity) doesn't make sense;
also there is no sense in parsing commits which aren't there.
In projects list for empty repositories gitweb now writes "No commits"
using "noage" class, instead of leaving cell empty, in the last change
column.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-svn: don't attempt to minimize URLs by default
git-svn: fix segfaults due to initial SVN pool being cleared
git-svn: clean up caching of SVN::Ra functions
git-svn: don't drop the username from URLs when dcommit is run
RPM spec: include files in technical/ to package.
Remove stale non-static-inline prototype for tree_entry_extract()
git-config: test for 'do not forget "a.b.var" ends "a.var" section'.
git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.
Change the configuration parser so that it ignores
everything except for ^gitcvs.((ext|pserver).)?
This greatly reduces the risk of failing while
parsing some unknown and irrelevant config option.
The bug that triggered this change was that the
parsing doesn't handle sections that have a
subsection and a variable with the same name.
While this bug still remains, all remaining
causes can be attributed to user error, since
there are no defined variables gitcvs.ext and
gitcvs.pserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Try to avoid "Use of uninitialized value ..." errors caused by bad
revision, incorrect filename, wrong object id, bad file etc. (wrong
value of 'h', 'hb', 'f', etc. parameters). This avoids polluting web
server errors log.
Correct git_get_hash_by_path and parse_commit_text (and, in turn,
parse_commit) to return undef if object does not exist. Check in
git_tag if requested tag exists.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently
$ git grep '\([^t]\|^\)'link: user-manual.txt
gives four hits that refer to .txt version of the documentation
set, but at least "hooks" and "cvs-migration" have HTML variants
installed, so refer to them instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For tracking branches and tags, git-svn prefers to connect
to the root of the repository or at least the level that
houses branches and tags as well as trunk. However, users
that are accustomed to tracking a single directory have
no use for this feature.
As pointed out by Junio, users may not have permissions to
connect to connect to a higher-level path in the repository.
While the current minimize_url() function detects lack of
permissions to certain paths _after_ successful logins, it
cannot effectively determine if it is trying to access a
login-only portion of a repo when the user expects to
connect to a part where anonymous access is allowed.
For people used to the git-svnimport switches of
--trunk, --tags, --branches, they'll already pass the
repository root (or root+subdirectory), so minimize URL
isn't of too much use to them, either.
For people *not* used to git-svnimport, git-svn also
supports:
git svn init --minimize-url \
--trunk http://repository-root/foo/trunk \
--branches http://repository-root/foo/branches \
--tags http://repository-root/foo/tags
And this is where the new --minimize-url command-line switch
comes in to allow for this behavior to continue working.
Some parts of SVN always seem to use it, even if the SVN::Ra
object we're using is no longer used and we've created a new one
in its place. It's also true that only one SVN::Ra connection
can exist at once... Using SVN::Pool->new_default when the
SVN::Ra object is created doesn't seem to help very much,
either...
Hopefully this fixes all segfault problems users have been
experiencing over the past few months.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This patch was originally intended to make the Perl GC more
sensitive to the SVN::Pool objects and not accidentally clean
them up when they shouldn't be (causing segfaults). That didn't
work, but this patch makes the code a bit cleaner regardless
Put our caches for get_dir and check_path calls directly into
the SVN::Ra object so they auto-expire when it is destroyed.
dirents returned by get_dir() no longer needs the pool object
stored persistently along with the cache data, as they'll be
converted to native Perl hash references.
Since calling rev_proplist repeatedly per-revision is no longer
needed in git-svn, we do not cache calls to it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We no longer store usernames in URLs stored in git-svn-id lines
for dcommit, so we shouldn't rely on those URLs when connecting
to the remote repository to commit.
Not only that they are interesting to users, some of the
files are linked to by the included "Git User's Manual"
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When 4651ece8 made the function a "static inline", it should
have removd the stale prototype but everybody missed that.
Thomas Glanzmann noticed this broke compilation with Forte12
compiler on his Sun boxes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier code tried to be half-careful and knew the logic that
seeing "a.var" after seeing "a.b.var" is a sign of the previous
"a.b." section has ended, but forgot it has to handle the other
way. Seeing "a.b.var" after seeing "a.var" is a sign that "a."
section has ended, so a new "a.var2" variable should be added
before the location "a.b.var" appears.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Small additional changes to the cbb84e5d17
commit, which introduced documentation to pre-receive and post-receive:
- Mention that stdout and stderr are equivalent.
- Add one cross-section link and fix one other.
- Fix information on advantages of post-receive over post-update.
Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
checkout: allow detaching to HEAD even when switching to the tip of a branch
Updated documentation of hooks in git-receive-pack.
Allow fetching references from any namespace
tiny fix in documentation of git-clone
Fix an unmatched comment end in arm/sha1_arm.S
You cannot currently checkout the tip of an existing branch
without moving to the branch.
This allows you to detach your HEAD and place it at such a
commit, with:
$ git checkout master^0
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added documentation of pre-receive and post-receive hooks and updated
documentation of update and post-update hooks.
[jc: with minor copy-editing]
Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver has a bug in its configuration file output parser
that makes it choke if the configuration has these:
[diff]
color = auto
[diff.color]
whitespace = blue reverse
This needs to be fixed, but thanks to that bug, a separate bug
in t9400 test script was discovered. The test discarded
GIT_CONFIG instead of pointing at the proper one to be used in
the exoprted repository. This allowed user's .gitconfig and (if
exists) systemwide /etc/gitconfig to affect the outcome of the
test, which is a big no-no.
The patch fixes the problem in the test. Fixing the
git-cvsserver's configuration parser is left as an exercise to
motivated volunteers ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
not only from the three defined: heads, tags and remotes.
Noticed when I tried to fetch the references created by git-p4-import.bat:
they are placed into separate namespace (refs/p4import/, to avoid showing
them in git-branch output). As canon_refs_list_for_fetch always prepended
refs/heads/ it was impossible, and annoying: it worked before. Normally,
the p4import references are useless anywhere but in the directory managed
by perforce, but in this special case the cloned directory was supposed
to be a backup, including the p4import branch: it keeps information about
where the imported perforce state came from.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Both archive-tar and archive-zip needed to be taught about subprojects.
The tar function died when trying to read the subproject commit object,
while the zip function reported "unsupported file mode".
This fixes both by representing the subproject as an empty directory.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Get rid of "Use of uninitialized value in string eq at
gitweb/gitweb.perl line 2320" warning caused by the fact that "empty"
patches, consisting only of extended git diff header and with patch
body empty, such as patch for pure rename, does not have "index" line
in extended diff header. For such patches $from_id and $to_id, filled
from parsing extended diff header, are undefined. But such patches
cannot be continuation patches.
Test if $from_id and $to_id are defined before comparing them with
$diffinfo.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than updating all working tree paths, we limit
ourselves to paths listed on the command line.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching from a branch with both x86_64/boot/Makefile and
i386/boot/Makefile to another branch that has x86_64/boot as a
symlink pointing at ../i386/boot, the code incorrectly removed
i386/boot/Makefile.
This was because we first removed everything under x86_64/boot
to make room to create a symbolic link x86_64/boot, then removed
x86_64/boot/Makefile which no longer exists but now is pointing
at i386/boot/Makefile, thanks to the symlink we just created.
This fixes it by using the has_symlink_leading_path() function
introduced previously for git-apply in the checkout codepath.
Earlier, "git checkout" was broken in t4122 test due to this
bug, and the test had an extra "git reset --hard" as a
workaround, which is removed because it is not needed anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
HPA noticed that git-rebase fails when changes involve symlinks
in the middle of the hierarchy. Consider:
* The tree state before the patch is applied has arch/x86_64/boot
as a symlink pointing at ../i386/boot/
* The patch tries to remove arch/x86_64/boot symlink, and
create bunch of files there: .gitignore, Makefile, etc.
git-apply tries to be careful while applying patches; it never
touches the working tree until it is convinced that the patch
would apply cleanly. One of the check it does is that when it
knows a path is going to be created by the patch, it runs
lstat() on the path to make sure it does not exist.
This leads to a false alarm. Because we do not touch the
working tree before all the check passes, when we try to make
sure that arch/x86_64/boot/.gitignore does not exist yet, we
haven't removed the arch/x86_64/boot symlink. The lstat() check
ends up seeing arch/i386/boot/.gitignore through the
yet-to-be-removed symlink, and says "Hey, you already have a
file there, but what you fed me is a patch to create a new
file. I am not going to clobber what you have in the working
tree."
We have similar checks to see a file we are going to modify does
exist and match the preimage of the diff, which is done by
directly opening and reading the file.
For a file we are going to delete, we make sure that it does
exist and matches what is going to be removed (a removal patch
records the full preimage, so we check what you have in your
working tree matches it in full -- otherwise we would risk
losing your local changes), which again is done by directly
opening and reading the file.
These checks need to be adjusted so that they are not fooled by
symlinks in the middle.
- To make sure something does not exist, first lstat(). If it
does not exist, it does not, so be happy. If it _does_, we
might be getting fooled by a symlink in the middle, so break
leading paths and see if there are symlinks involved. When
we are checking for a path a/b/c/d, if any of a, a/b, a/b/c
is a symlink, then a/b/c/d does _NOT_ exist, for the purpose
of our test.
This would fix this particular case you saw, and would not
add extra overhead in the usual case.
- To make sure something already exists, first lstat(). If it
does not exist, barf (up to this, we already do). Even if it
does seem to exist, we might be getting fooled by a symlink
in the middle, so make sure leading paths are not symlinks.
This would make the normal codepath much more expensive for
deep trees, which is a bit worrisome.
This patch implements the first side of the check "making sure
it does not exist". The latter "making sure it exists" check is
not done yet, so applying the patch in reverse would still
fail, but we have to start from somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we are applying a patch that creates a blob at a path, or
when we are switching from a branch that does not have a blob at
the path to another branch that has one, we need to make sure
that there is nothing at the path in the working tree, as such a
file is a local modification made by the user that would be lost
by the operation.
Normally, lstat() on the path and making sure ENOENT is returned
is good enough for that purpose. However there is a twist. We
may be creating a regular file arch/x86_64/boot/Makefile, while
removing an existing symbolic link at arch/x86_64/boot that
points at existing ../i386/boot directory that has Makefile in
it. We always first check without touching filesystem and then
perform the actual operation, so when we verify the new file,
arch/x86_64/boot/Makefile, does not exist, we haven't removed
the symbolic link arc/x86_64/boot symbolic link yet. lstat() on
the file sees through the symbolic link and reports the file is
there, which is not what we want.
The function has_symlink_leading_path() function takes a path,
and sees if any of the leading directory component is a symbolic
link.
When files in a new directory are created, we tend to process
them together because both index and tree are sorted. The
function takes advantage of this and allows the caller to cache
and reuse which symbolic link on the filesystem caused the
function to return true.
The calling sequence would be:
char last_symlink[PATH_MAX];
*last_symlink = '\0';
for each index entry {
if (!lose)
continue;
if (lstat(it))
if (errno == ENOENT)
; /* happy */
else
error;
else if (has_symlink_leading_path(it, last_symlink))
; /* happy */
else
error; /* would lose local changes */
unlink_entry(it, last_symlink);
}
Signed-off-by: Junio C Hamano <junkio@cox.net>
The rebase and merge commands used diff-tree to display the summary stats of
what files had changed from the operation. diff-tree does not read the
diff ui configuration options, so the diff.color setting was not used.
Have rebase and merge call diff rather than diff-tree, which does read the
diff ui options.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-checkout is also adapted to make use of this new option
instead of the handcrafted command sequence.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This option causes 'git gc' to more aggressively optimize the
repository at the cost of taking much more wall clock and CPU time.
Today this option causes git-pack-objects to use --no-use-delta
option, and it allows the --window parameter to be set via the
gc.aggressiveWindow configuration parameter.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add config variables pack.compression and core.loosecompression ,
and switch --compression=level to pack-objects.
Loose objects will be compressed using core.loosecompression if set,
else core.compression if set, else Z_BEST_SPEED.
Packed objects will be compressed using --compression=level if seen,
else pack.compression if set, else core.compression if set,
else Z_DEFAULT_COMPRESSION. This is the "pack compression level".
Loose objects added to a pack undeltified will be recompressed
to the pack compression level if it is unequal to the current
loose compression level by the preceding rules, or if the loose
object was written while core.legacyheaders = true. Newly
deltified loose objects are always compressed to the current
pack compression level.
Previously packed objects added to a pack are recompressed
to the current pack compression level exactly when their
deltification status changes, since the previous pack data
cannot be reused.
In either case, the --no-reuse-object switch from the first
patch below will always force recompression to the current pack
compression level, instead of assuming the pack compression level
hasn't changed and pack data can be reused when possible.
This applies on top of the following patches from Nicolas Pitre:
[PATCH] allow for undeltified objects not to be reused
[PATCH] make "repack -f" imply "pack-objects --no-reuse-object"
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that we encourage and actively preserve objects in a packed form
more agressively than we did at the time the new loose object format and
core.legacyheaders were introduced, that extra loose object format
doesn't appear to be worth it anymore.
Because the packing of loose objects has to go through the delta match
loop anyway, and since most of them should end up being deltified in
most cases, there is really little advantage to have this parallel loose
object format as the CPU savings it might provide is rather lost in the
noise in the end.
This patch gets rid of core.legacyheaders, preserve the legacy format as
the only writable loose object format and deprecate the other one to
keep things simpler.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recomputing delta is much more expensive than recompressing
anyway, and when the user says 'repack -f', it is a sign that
the user is willing to spend CPU cycles.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently non deltified object data is always reused when possible.
This means that any change to core.compression has no effect on those
objects as they don't get recompressed when repacking them.
Let's add a --no-reuse-object flag to git-repack in order to force
recompression of all objects when desired.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now write to MERGE_MSG, not .msg. I missed this earlier
when I changed the target we write to.
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 0.7.0
git-gui: Paperbag fix blame in subdirectory
git-gui: Format author/committer times in ISO format
git-gui: Cleanup minor nits in blame code
git-gui: Generate blame on uncommitted working tree file
git-gui: Smarter command line parsing for browser, blame
git-gui: Use prefix if blame is run in a subdirectory
git-gui: Convert blame to the "class" way of doing things
git-gui: Don't attempt to inline array reads in methods
git-gui: Convert browser, console to "class" format
git-gui: Define a simple class/method system
git-gui: Allow shift-{k,j} to select a range of branches to merge
git-gui: Call changes "Staged" and "Unstaged" in file list titles.
Avoid specifying font sizes in pixels, since that is just pure evil.
Pointed out by Chris Riddoch.
Note that this is pretty much just a proposal; I didn't test if everything
fits perfectly right, but things seem to be pretty much okay. repo.or.cz
uses it now as a test drive - if you find any visual quirks, please point
them out, with a patch if possible since I'm total CSS noob and debugging
CSS is an extremely painful experience for me.
Note that this patch actually does change visual look of gitweb in Firefox
with my resolution and default settings - everything is bigger and I can't
explain the joy of actually seeing gitweb text that is in _readable_ size;
also, my horizontal screen real estate feels better used now. But judging
from the look of most modern webpages on the 'net, most people prefer
reading the web with strained eyes and/or a magnifying glass (I wonder what
species of scientists should look into this mystifying phenomenon) - so,
please tell us what you think.
Maybe we might want to get rid of absolute sizes other than font sizes in
the CSS file too in the long term.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch renames config_boolean() to config_bool() for consistency with
the commandline interface and because it is shorter but still obvious. ;-)
It also changes the return value from some obscure string to real Perl
boolean, allowing for clean user code.
Signed-off-by: Petr Baudis <pasky@suse.cz>
* maint:
.mailmap: add some aliases
SPECIFYING RANGES typo fix: it it => it is
git-clone: don't get fooled by $PWD
Fix documentation of tag in git-fast-import.txt
If you have /home/me/git symlink pointing at /pub/git/mine,
trying to clone from /pub/git/his/ using relative path would not
work as expected:
$ cd /home/me
$ cd git
$ ls ../
his mine
$ git clone -l -s -n ../his/stuff.git
This is because "cd ../his/stuff.git" done inside git-clone to
check if the repository is local is confused by $PWD, which is
set to /home/me, and tries to go to /home/his/stuff.git which is
different from /pub/git/his/stuff.git.
We could probably say "set -P" (or "cd -P") instead, if we know
the shell is POSIX, but the way the patch is coded is probably
more portable.
[jc: this is updated with Andy Whitcroft's improvements]
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb URLs use the a= parameter for the view to use on the given path, such
as "blob" or "tree". Currently, if a gitweb URL omits the a= parameter,
gitweb just shows the top-level repository summary, regardless of the path
given. gitweb could instead choose an appropriate view based on the file
type: blob for blobs (files), tree for trees (directories), and summary if
no path given (the URL included no f= parameter, or an empty f= parameter).
Apart from making gitweb more robust and supporting URL editing more easily,
this change would aid the creation of shortcuts to git repositories using
simple substitution, such as:
http://example.org/git/?p=path/to/repo.git;hb=HEAD;f=%s
With this patch, if given the hash through the h= parameter, or the hash
base (hb=) and a filename (f=), gitweb uses cat-file -t to automatically set
the a= parameter.
This feature was requested by Josh Triplett through
http://bugs.debian.org/410465
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/diffopt:
diff -S: release the image after looking for needle in it
diff -M: release the preimage candidate blobs after rename detection.
diff.c: do not use a separate "size cache".
diff: release blobs after generating textual diff.
* jn/gitweb:
gitweb: Show combined diff for merge commits in 'commit' view
gitweb: Show combined diff for merge commits in 'commitdiff' view
gitweb: Make it possible to use pre-parsed info in git_difftree_body
gitweb: Add combined diff support to git_patchset_body
gitweb: Add combined diff support to git_difftree_body
gitweb: Add parsing of raw combined diff format to parse_difftree_raw_line
Use the :fork: access method to force cvs to
call "$CVS_SERVER server" even when accessing a local
repository.
Add a basic test for checkout and some tests for update.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than storing the temporary commit message data in .msg (in
the working tree) we now store the message data in .git/MERGE_MSG.
By storing the message in the .git/ directory we are sure we will
never have a collision with a user file, should a project actually
have a ".msg" file in their top level tree. We also don't need to
worry about leaving this stale file behind during a `reset --hard`
and have it show up in the output of status.
We are using .git/MERGE_MSG here to store the temporary message as
it is an already established convention between git-merge, git-am
and git-rebase that git-commit will default the user's edit buffer
to the contents of .git/MERGE_MSG. If the user is going to need
to resolve this commit or wants to edit the message on their own
prepping that file with the desired message "just works".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
RPM packages did not include howto files which causes broken
links in howto-index.html
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a simple change to match what gitk does when it shows
a commit; we format using ISO dates (yyyy-mm-dd HH:MM:SS).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We can use [list ...] rather than "", especially when we are talking
about values as then they are properly escaped if necessary. Small
nit, but probably not a huge deal as the only data being inlined here
is Tk paths.
Some of the lines in the parser code were longer than 80 characters
wide, and they actually were all the same value on the end part of
the line. Rather than keeping the mess copied-and-pasted around we
can set the last argument into a local variable and reuse it many
times.
The commit display code was also rather difficult to read on an 80
character wide terminal, so I'm moving it all into a double quoted
string that is easier to read.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user doesn't give us a revision parameter to our blame
subcommand then we can generate blame against the working tree
file by passing the file path off to blame with the --contents
argument. In this case we cannot obtain the contents of the
file from the ODB; instead we must obtain the contents by
reading the working directory file as-is.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The browser subcommand now optionally accepts a single revision
argument; if no revision argument is supplied then we use the
current branch as the tree to browse. This is very common, so
its a nice option.
Our blame subcommand now tries to perform the same assumptions
as the command line git-blame; both the revision and the file
are optional. We assume the argument is a filename if the file
exists in the working directory, otherwise we assume the argument
is a revision name. A -- can be supplied between the two to force
parsing, or before the filename to force it to be a filename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I think it was Andy Parkins who pointed out that git gui blame HEAD f
does not work if f is in a subdirectory and we are currently running
git-gui within that subdirectory. This is happening because we did
not take the user's prefix into account when we computed the file
path in the repository.
We now assume the prefix as returned by rev-parse --show-prefix is
valid and we use that during the command line blame subcommand when
we apply the parameters.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our blame viewer code has historically been a mess simply
because the data for multiple viewers was all crammed into
a single pair of Tcl arrays. This made the code hard to
read and even harder to maintain.
Now that we have a slightly better way of tracking the data
for our "meta-widgets" we can make use of it here in the
blame viewer to cleanup the code and make it easier to work
with long term.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a variable reference to a field is to an array, and it is
the only reference to that field in that method we cannot make
it an inlined [set foo] call as the regexp was converting the
Tcl code wrong. We were producing "[set foo](x)" for "$foo(x)",
and that isn't valid Tcl when foo is an array. So we just punt
if the only occurance has a ( after it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we have a slightly easier method of working with per-widget
data we should make use of that technique in our browser and console
meta-widgets, as both have a decent amount of information that they
store on a per-widget basis and our current approach of handling
it is difficult to follow.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As most of the git-gui interface is based upon "meta-widgets"
that need to carry around a good deal of state (e.g. console
windows, browser windows, blame viewer) we have a good deal
of messy code that tries to store this meta-widget state in
global arrays, where keys into the array are formed from a
union of a unique "object instance id" and the field name.
This is a simple class system for Tcl that allows us to
hide much of that mess by making Tcl do what it does best;
process strings to manipulate its own code during startup.
Each object instance is placed into its own namespace. The
namespace is created when the object instance is created and
the namespace is destroyed when the object instance is removed
from the system. Within that namespace we place variables for
each field within the class; these variables can themselves be
scalar values or full-blown Tcl arrays.
A simple class might be defined as:
class map {
field data
field size 0
constructor {} {
return $this
}
method set {name value} {
set data($name) $value
incr size
}
method size {} {
return $size
} ifdeleted { return 0 }
}
All fields must be declared before any constructors or methods. This
allows our class to generate a list of the fields so it can properly
alter the definition of the constructor and method bodies prior to
passing them off to Tcl for definition with proc. A field may optionally
be given a default/initial value. This can only be done for non-array
type fields.
Constructors are given full access to all fields of the class, so they
can initialize the data values. The default values of fields (if any)
are set before the constructor runs, and the implicit local variable
$this is initialized to the instance identifier.
Methods are given access to fields they actually use in their body.
Every method has an implicit "this" argument inserted as its first
parameter; callers of methods must be sure they supply this value.
Some basic optimization tricks are performed (but not much). We
try to only upvar (locally bind) fields that are accessed within a
method, but we err on the side of caution and may upvar more than
we need to. If a variable is accessed only once within a method
and that access is by $foo (read) we avoid the upvar and instead
use [set foo] to obtain the value. This is slightly faster as Tcl
does not need to lookup the variable twice.
We also offer some small syntatic sugar for interacting with Tk and
the fileevent callback system in Tcl. If a field (say "foo") is used
as "@foo" we insert instead the true global variable name of that
variable into the body of the constructor or method. This allows easy
binding to Tk textvariable options, e.g.:
label $w.title -textvariable @title
Proper namespace callbacks can also be setup with the special cb proc
that is defined in each namespace. [cb _foo a] will invoke the method
_foo in the current namespace, passing it $this as the first (implied)
parameter and a as the second parameter. This makes it very simple to
connect an object instance to a -command option for a Tk widget or to
a fileevent readable or writable for a file channel.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I found it useful to be able to use j/k (vi-like keys) to move
up and down the list of branches to merge and shift-j/k to do
the selection, much as shift-up/down (arrow keys) would alter
the selection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
All menu entries talk about "staging" and "unstaging" changes, but the
titles of the file lists use different wording, which may confuse
newcomers.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Build fails for git 1.5.1.3 on AIX, with the message:
utf8.c:66: error: conflicting types for 'wcwidth'
/.../lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.3/include/string.h:266: error: previous declaration of 'wcwidth' was here
Fix this by renaming our static variant to our own name.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
More typo fixes from Santi Béjar, plus a couple other mistakes I noticed
along the way.
Cc: Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We already export these variables earlier in the Makefile, right
after they were 'declared'. There is no point in doing so again.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Use vi-like keys in merge dialog
git-gui: Include commit id/subject in merge choices
git-gui: Show all possible branches for merge
git-gui: Move merge support into a namespace
git-gui: Allow vi keys to scroll the diff/blame regions
git-gui: Move console procs into their own namespace
git-gui: Refactor into multiple files to save my sanity
git-gui: Track our own embedded values and rebuild when they change
git-gui: Refactor to use our git proc more often
git-gui: Use option database defaults to set the font
git-gui: Cleanup common font handling for font_ui
git-gui: Correct line wrapping for too many branch message
git-gui: Warn users before making an octopus merge
git-gui: Include the subject in the status bar after commit
Also perform an evil merge change to update Git's main Makefile to
pass the proper options down into git-gui now that it depends on
reasonable values for 'sharedir' and 'TCL_PATH'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we support vi-like keys for scrolling in other UI contexts
we can easily do so here too. Tk's handy little `event generate'
makes this a lot easier than I thought it would be. We may want
to go back and fix some of the other vi-like bindings to redirect
to the arrow and pageup/pagedown keys, rather than running the
view changes directly.
I've bound 'v' to visualize, as this is a somewhat common thing
to want to do in the merge dialog. Control (or Command) Return
is also bound to start the merge, much as it is bound in the
main window to activate the commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When merging branches using our local merge feature it can be
handy to know the first few digits of the commit the ref points
at as well as the short description of the branch name.
Unfortunately I'm unable to use three listboxes in a row, as Tcl
freaks out and refuses to let me have a selection in more than
one of them at any given point in time. So instead we use a
fixed width font in the existing listbox and organize the data
into three columns. Not nearly as nice looking, but users can
continue to use the listbox's features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt pointed out that git-gui was randomly selecting
which branch (or tag!) it will show in the merge dialog when
more than one ref points at the same commit. This can be a
problem for the user if they want to merge a branch, but the
ref that git-gui selected to display was actually a tag that
points at the commit at the tip of that branch. Since the
user is looking for the branch, and not the tag, its confusing
to not find it, and worse, merging the tag causes git-merge to
generate a different message than if the branch was selected.
While I am in here and am messing around I have changed the
for-each-ref usage to take advantage of its --tcl formatting,
and to fetch the subject line of the commit (or tag) we are
looking at. This way we could present the subject line in the
UI to the user, given them an even better chance to select
the correct branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like the console procs I have moved the code related to merge
support into their own namespace, so that they are isolated
from the rest of the world.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users who are used to vi and recent versions of gitk may want
to scroll the diff region using vi style keybindings. Since
these aren't bound to anything else and that widget does not
accept focus for data input, we can easily support that too.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To help modularize git-gui better I'm isolating the code and
variables required to handle our little console windows into
their own namespace. This way we can say console::new rather
than new_console, and the hidden internal procs to create the
window and read data from our filehandle are off in their own
private little land, where most users don't see them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm finding it difficult to work with a 6,000+ line Tcl script
and not go insane while looking for a particular block of code.
Since most of the program is organized into different units of
functionality and not all users will need all units immediately
on startup we can improve things by splitting procs out into
multiple files and let auto_load handle things for us.
This should help not only to better organize the source, but
it may also improve startup times for some users as the Tcl
parser does not need to read as much script before it can show
the UI. In many cases the user can avoid reading at least half
of git-gui now.
Unfortunately we now need a library directory in our runtime
location. This is currently assumed to be $(sharedir)/git-gui/lib
and its expected that the Makefile invoker will setup some sort of
reasonable sharedir value for us, or let us assume its going to be
$(gitexecdir)/../share.
We now also require a tclsh (in TCL_PATH) to just run the Makefile,
as we use tclsh to generate the tclIndex for our lib directory. I'm
hoping this is not an unncessary burden on end-users who are building
from source.
I haven't really made any functionality changes here, this is just a
huge migration of code from one file to many smaller files. All of
the new changes are to setup the library path and install the library
files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When commit shown is a merge commit (has more than one parent),
display combined difftree output (result of git-diff-tree -c).
Earlier (since commit 549ab4a307)
difftree output (against first parent) was not printed for merges.
Examples of non-trivial merges:
5bac4a6719 (includes rename)
addafaf92e (five parents)
95f97567c1887d77f3a46b42d8622c76414d964d (evil merge)
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When 'commitdiff' action is requested without 'hp' (hash parent)
parameter, and commit given by 'h' (hash) parameter is merge commit,
show merge as combined diff.
Earlier for merge commits without 'hp' parameter diff to first parent
was shown.
Note that in compact combined (--cc) format 'uninteresting' hunks
omission mechanism can make that there is no patch corresponding to
line in raw format (difftree) output. That is why (at least for now)
we use --combined and not --cc format for showing commitdiff for merge
commits.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make it possible to use pre-parsed, or generated by hand, difftree
info in git_difftree_body, similarly to how was and is it done in
git_patchset_body.
Use just introduced feature in git_commitdiff to parse difftree info
(raw diff output) only once: difftree info is now parsed in
git_commitdiff directly, and parsed information is passed to both
git_difftree_body and git_patchset_body. (Till now only git_blobdiff
made use of git_patchset_body ability to use pre-parsed or hand
generated info.) Additionally this makes rename info for combined diff
with renames (or copies) calculated only once in git_difftree_body;
the $difftree is modified and git_patchset_body makes use of added
info.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Calling convention for combined diff similar to the one for
git_difftree_body subroutine: difftree info (first parameter) must be
result of calling git-diff-tree with -c/--cc option, and all parents
of a commit must be passed as last parameters. See also description in
"gitweb: Add combined diff support to git_difftree_body"
This ability is not used yet.
Generating "src" file name for renames in combined diff was separated
into fill_from_file_info subroutine; git_difftree_body was modified to
use it. Currently git_difftree_body and git_patchset_body fills this
info separately.
The from-file line in two-line from-file/to-file header is not
hyperlinked: there can be more than one "from"/"src" file. This
differs from HTML output of ordinary (not combined) diff.
format_diff_line subroutine needs extra $from/$to parameters to format
combined diff patch line correctly.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
You have to pass all parents as final parameters of git_difftree_body
subroutine; the number of parents of a diff must be equal to the
number derived from parsing git-diff-tree output, raw combined diff
for git_difftree_body to display combined diff correctly (but it is
not checked).
Currently the possibility of displaying diffree of combined diff is
not used in gitweb code; git_difftree_body is always caled for
ordinary diff, and with only one parent.
Description of output for combined diff:
----------------------------------------
The difftree table for combined diff starts with a cell with pathname
of changed blob (changed file), which if possible is hidden link
(class="list") to the 'blob' view of final version (if it exists),
like for difftree for ordinary diff. If file was deleted in the final
commit then filename is not hyperlinked.
There is no cell with single file status (new, deleted, mode change,
rename), as for combined diff as there is no single status: different
parents might have different status.
If git_difftree_body was called from git_commitdiff (for 'commitdiff'
action) there is inner link to anchor to appropriate fragment (patch)
in patchset body; the "patch" link does not replace "diff" link like
for ordinary diff.
Each of "diff" links is in separate cell, contrary to output for
ordinary diff in which all links are (at least for now) in a single
cell.
For each parent, if file was not present we leave cell empty. If file
was deleted in the result, we provide link to 'blob' view. Otherwise
we provide link to 'commitdiff' view, even if patch (diff) consist
only of extended diff header, and contents is not changed (pure
rename, pure mode change). The only difference is that link to
"blobdiff" view with no contents change is with 'nochange' class.
At last, there is provided link to current version of file as "blob"
link, if the file was not deleted in the result, and lik to history of
a file, if there exists one. (The link to file history might be
confused, at least for now, by renames.)
Note that git-diff-tree raw output dor combined diff does not provide
filename before change for renames and copies; we use
git_get_path_by_hash to get "src" filename for renames (this means
additional call to git-ls-tree for a _whole_ tree).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add parsing line of raw combined diff ("git diff-tree -c/-cc" output)
as described in section "diff format for merges" in diff-format.txt
to parse_difftree_raw_line subroutine.
Returned hash (or hashref) has for combined diff 'nparents' key which
holds number of parents in a merge. At keys 'from_mode' and 'from_id'
there are arrayrefs holding modes and ids, respectively. There is no
'similarity' value, and there is only 'to_file' value and no
'from_file' value.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Randal L. Schwartz pointed out multiple times that we should be
testing the length of the name string here, not if it is "true".
The problem is the string '0' is actually false in Perl when we
try to evaluate it in this context, as '0' is 0 numerically and
the number 0 is treated as a false value. This would cause us
to break out of the import loop early if anyone had a file or
directory named "0".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We released the postimage candidate blobs after we are done to reduce
memory pressure. Do the same for preimage candidate blobs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff_filespec has a slot to record the size of the data already,
so make use of it instead of a separate size cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reduces the memory pressure when dealing with many paths.
An unscientific test of running "diff-tree --stat --summary -M"
between v2.6.19 and v2.6.20-rc1 in the linux kernel repository
indicates that the number of minor faults are reduced by 2/3.
Signed-off-by: Junio C Hamano <junkio@cox.net>
- git-ls-files.txt: typo in description of --ignored
- git-clean.txt: s/forceRequire/requireForce/
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This tests the -d, -n, -f, -x, and -X options to git-clean.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "git-ls-files --others --directory --ignored" behave
as documented and consequently also fixes "git-clean -d -X".
Previously, git-clean would remove non-excluded directories
even when using the -X option.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Documentation: don't reference non-existent 'git-cvsapplycommit'
user-manual: stop deprecating the manual
user-manual: miscellaneous editing
user-manual: fix .gitconfig editing examples
user-manual: clean up fast-forward and dangling-objects sections
user-manual: add section ID's
user-manual: more discussion of detached heads, fix typos
git-gui: Allow spaces in path to 'wish'
gitk: Allow user to choose whether to see the diff, old file, or new file
It's just as much a work-in-progress, but at least now it's gotten
enough technical review to shake out most of the really bad lies, so
hopefully it doesn't do any actual damage. And if we encourage people
to read it, they'll be more likely to whine about it, which will help
get it fixed faster.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I cherry-picked some additional miscellaneous fixes from those suggested
by Santi Béjar, including fixes to:
- correct discussion of repository/HEAD->repository shortcut
- add mention of git-mergetool
- add mention of --track
- mention "-f" as well as "+" for fetch
Cc: Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Santi Béjar points out that when telling people how to "introduce
themselves" to git we're advising them to replace their entire
.gitconfig file. Fix that.
Cc: "Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The previous commit calls attention to the fact that we have two
sections each devoted to fast-forwards and to dangling objects. Revise
and attempt to differentiate them a bit. Some more reorganization may
be required later....
Signed-off-by: J. Bruce Fields
Any section lacking an id gets an annoying warning when you build
the manual. More seriously, the table of contents then generates
volatile id's which change with every build, with the effect that
we get URL's that change all the time.
The ID's are manually generated and sometimes inconsistent, but
that's OK.
XXX: what to do about the preface?
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Nicolas Pitre pointed out a couple typos and some room for improvement
in the discussion of detached heads.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Cc: Nicolas Pitre <nico@cam.org>
* maint:
Small correction in reading of commit headers
Documentation: fix typo in git-remote.txt
Add test for blame corner cases.
blame: -C -C -C
blame: Notice a wholesale incorporation of an existing file.
Fix --boundary output
diff format documentation: describe raw combined diff format
Mention version 1.5.1 in tutorial and user-manual
Add --no-rebase option to git-svn dcommit
Fix markup in git-svn man page
This fixes a crash in broken repositories where random commits
suddenly disappear.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Check if a line of the header has enough characters to possibly
contain the requested prefix.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When you do this, existing "blame -C -C" would not find that the
latter half of the file2 came from the existing file1:
... both file1 and file2 are tracked ...
$ cat file1 >>file2
$ git add file1 file2
$ git commit
This is because we avoid the expensive find-copies-harder code
that makes unchanged file (in this case, file1) as a candidate
for copy & paste source when annotating an existing file
(file2). The third -C now allows it. However, this obviously
makes the process very expensive. We've actually seen this
patch before, but I dismissed it because it covers such a narrow
(and arguably stupid) corner case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The -C option to blame tries to find a section of a preimage
file by running diff against the lines whose origin is still
unknown, and excluding the different parts. The code however
did not cover the case where the tail part of the section
matched, which we handle for the normal non-move/copy codepath.
This breakage was most visible when preimage file matches in its
entirety and failed to pass blame in such a case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git log --boundary" incorrectly honoured the option only when
"left-right" was enabled.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add description of raw combined diff format to diff-formats.txt,
as "diff format for merges" section, before "Generating patches..."
section.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most other documentation will frequently be read from an installation
of git so will naturally be associated with the installed version.
But these two documents in particular are often read from web pages
while users are still exploring git. It's important to mention
version 1.5.1 since these documents provide example commands that
won't work with previous versions of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn dcommit exports commits to Subversion, then imports them back
to git again, and last but not least rebases or resets HEAD to the
last of the new commits. I guess this rebasing is convenient when
using just git, but when the commits to be exported are managed by
StGIT, it's really annoying. So add an option to disable this
behavior. And document it, too!
Signed-off-by: Karl Hasselström <kha@treskal.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some of the existing markup was just plain broken, and some subcommand
options weren't indented properly.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the -v is passed, git-tag will exit after it is processed like it
does with the -d and -l options. Additionally, missing code block caused
wrong rendering of an option example.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is actually a few different changes to request-pull,
making it slightly smarter:
1) Minor cleanup of revision->base variable names, making it
follow the head/headrev naming convention that is already
in use.
2) Compute the merge-base between the two revisions upfront
and reuse that selected merge-base to create the diffstat.
3) Refuse to generate a pull request for branches that have no
existing relationship. These aren't very common and would mess
up our diffstat generation.
4) Disable the PAGER when running shortlog and diff, as these
would otherwise activate the pager for each command when
git-request-pull is run on a tty. Instead users can get the
entire output paged (if desired) using `git -p request-pull`.
5) Use shortlog rather than `git log | git shortlog` now that
recent shortlog versions are able to run the revision listing
internally.
6) Attempt to resolve the input URL using the user's configured
remotes. This is useful if the URL you want the recipient to
see is also the one you used to push your changes. If not a
config-file remote could easily be setup for the public URL
and request-pull could be passed that name instead.
7) Automatically guess and include the remote branch name in the
body of the message. We list the branch name immediately after
the URL, making it easy for the recipient to copy and paste
the entire line onto a `git pull` command line. Rumor has it
Linus likes this format, for exactly that reason.
If multiple branches at the remote match $headrev we take the
first one returned by peek-remote and assume it is suitable.
If no branches are available we warn the user about the problem,
but insert a static string that is not a valid branch name
and would be obvious to anyone reading the message as being
totally incorrect. This allows users to still generate a
template message without network access (for example) and
hand-correct the bits that cannot be verified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
gitweb: use decode_utf8 directly
posix compatibility for t4200
Document 'opendiff' value in config.txt and git-mergetool.txt
Allow PERL_PATH="/usr/bin/env perl"
Make xstrndup common
diff.c: fix "size cache" handling.
http-fetch: Disable use of curl multi support for libcurl < 7.16.
Using decode() tries to decode data that is already UTF-8 and
borks, but decode_utf8 from Encode.pm has a built-in safety
against that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix t4200 so that it also works on OS X by not relying on gnu
extensions to sed.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is a mechanism PERL_PATH in the Makefile to specify path to
Perl binary, but sometimes it is convenient to let 'env' figure
out where Perl comes from, with PERL_PATH="/usr/bin/env perl".
Allowing this would make things easier to MacPorts, where we wish
to work with the MacPorts perl if it is installed, but fall back
to the system perl if it isn't.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This also improves the implementation to match how strndup is
specified (by GNU): if the length given is longer than the string,
only the string's length is allocated and copied, but the string need
not be null-terminated if it is at least as long as the given length.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We broke the size-cache handling when we changed the function
signature of sha1_object_info() in 21666f1a. We obviously
wanted to cache the size we obtained when sha1_object_info()
succeeded, not when it failed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
curl_multi_remove_handle() is broken in libcurl < 7.16, in that it
doesn't correctly update the active handles count when a request is
aborted. This causes the transfer to hang forever waiting for the
handle count to become less than the number of active requests.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There really isn't any point in turning off .mailmap. The
number of mailmap lookups are bounded by number of lines in the
target file, and the real blame processing is much more
expensive. If it turns out to be too costly, we should optimize
the mailmap lookup itself, instead of avoiding the call.
If the author information of commits of the project are
relatively clean, .mailmap would have only small number of
entries, and the overhead of looking it up will not be high. On
the other hand, if the author information is really screwed up
that a good .mailmap needs to be maintained to run shortlog,
giving uncleaned names in blame output is not helpful at all
either.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We can't unconditionally assign revision 1.1 to
newly added files. In case the file did exist in the
past and was deleted we need to honor the old
revision number.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For example Mac OS X lacks the seq command. So we cannot use it
there. A good old while loop works just as good.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that fast-import is using a "library function" to handle
correcting its packfile's object count and trailing SHA-1 we
should reuse the same function in index-pack, to reduce the
size of the code we must maintain.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Include a generalized fixup_pack_header_footer() in this new file.
Needed by git-repack --max-pack-size feature in a later patchset.
[sp: Moved close(pack_fd) to callers, to support index-pack, and
changed name to better indicate it is for packfiles.]
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This extension allows GNU tar to process file names in excess of the 100
characters defined by the original tar standard. It does this by faking a
file, named '././@LongLink' containing the true file name, and then adding
the file with a truncated name. The idea is that tar without this
extension will write out a file with the long file name, and write the
contents into a file with truncated name.
Unfortunately, GNU tar does a lousy job at times. When truncating results
in a _directory_ name, it will happily use _that_ as a truncated name for
the file.
An example where this actually happens is gcc-4.1.2, where the full path
of the file WeThrowThisExceptionHelper.java truncates _exactly_ before the
basename. So, we have to support that ad-hoc extension.
This bug was noticed by Chris Riddoch on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like core-Git we now track the values that we embed into our shell
script wrapper, and we "recompile" that wrapper if they are changed.
This concept was lifted from git.git's Makefile, where a similar
thing was done by Eygene Ryabinkin. Too bad it wasn't just done
here in git-gui from the beginning, as the git.git Makefile support
for GIT-GUI-VARS was really just because git-gui doesn't do it on
its own.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Whenever we want to execute a git subcommand from the plumbing
layer (and on rare occasion, the more porcelain-ish layer) we
tend to use our proc wrapper, just to make the code slightly
cleaner at the call sites. I wasn't doing that in a couple of
places, so this is a simple cleanup to correct that.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than passing "-font font_ui" to every widget that we
create we can instead reconfigure the option database for
all widget classes to use our font_ui as the default widget
font. This way Tk will automatically setup their defaults
for us, and we can reduce the size of the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
An earlier change tossed these optionMenu font configurations
all over the code, when really we can just rename the proc to
a hidden internal name and provide our own wrapper to install
the font configuration we really want.
We also don't need to set these option database entries in all
of the procedures that open dialogs; instead we should just set
one time, them after we have the font configuration ready for use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since Tk automatically wraps lines for us in tk_messageBox
widgets we don't need to try to wrap them ourselves. Its
actually worse that we linewrapped this here in the script,
as not all fonts will render this dialog nicely.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A coworker who was new to git-gui recently tried to make an octopus
merge when he did not quite mean to. Unfortunately in his case the
branches had file level conflicts and failed to merge with the octopus
strategy, and he didn't quite know why this happened. Since most users
really don't want to perform an octopus merge this additional safety
valve in front of the merge process is a good thing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that the command line git-commit has made displaying
the subject (first line) of the newly created commit popular
we can easily do the same thing here in git-gui, without the
ugly part of forking off a child process to obtain that first
line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the path of our wish executable that are running under
contains spaces we need to make sure they are escaped in
a proper Tcl list, otherwise we are unable to start gitk.
Reported by Randal L. Schwartz on #git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The code used write_in_full() without pulling its declarations from the
header file. When header is included, usage[] collides with usage()
function.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
read_mailmap already returns not 0 in case of error, and nothing
seem to be interested in it. It also is silent about the fact
(read_mailmap being to chatty would justify the call to access,
but there is no point for it to be and it isn't).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The only such a caller builtin-blame.c would pass NULL as the place
where to store the abbreviation.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
strncpy does not NUL-terminate output in case of output buffer too short,
and map_email prototype (and usage) does not allow for figuring out
what the length of the name is.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It can be either hostname/address, or a full path to a
local executable.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Separate things to be checked when making commits, and things
to be checked when sending patches.
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds a new 'find-rev' command to git-svn that lets you easily
translate between SVN revision numbers and git tree-ish.
Signed-off-by: Adam Roben <aroben@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After reading the leading contents from a symlink data obtained
from subversion, which we expect to begin with 'link ', the code
forked to hash the remainder (which should match readlink()
result) using git-hash-objects, by redirecting its STDIN from
the filehandle we read that 'link ' from. This was Ok with Perl
on modern Linux, but on Mac OS, the read in the parent process
slurped more than we asked for in stdio buffer, and the child
did not correctly see the "remainder".
This attempts to fix the issue by using lower level sysseek and
sysread instead of seek and read to bypass the stdio buffer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Eric Wong <normalperson@yhbt.net>
Acked-by: Seth Falcon <sethfalcon@gmail.com>
This splits out a few functions to deal with mailmap from
shortlog and makes it a bit more usable from other programs.
Most notably, it does not clobber input e-mail address anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this "git blame -b -s HEAD~n..HEAD" becomes a nicer way to
review the result of recent changes in context.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some other programs get the user's email address from $EMAIL, so fall back to
that if we don't have a Git-specific email address.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
http.c: Fix problem with repeated calls of http_init
Add missing reference to GIT_COMMITTER_DATE in git-commit-tree documentation
Fix import-tars fix.
Update .mailmap with "Michael"
Do not barf on too long action description
Catch empty pathnames in trees during fsck
Don't allow empty pathnames in fast-import
import-tars: be nice to wrong directory modes
git-svn: Added 'find-rev' command
git shortlog documentation: add long options and fix a typo
Calling http_init after calling http_cleanup causes a segfault. This
is due to the pragma_header curl_slist being freed but not being set
to NULL. The subsequent call to http_init tries to setup the slist
again, but it now points to an invalid memory location.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This heeds advice from our resident Perl expert to make sure
the script is not confused with a string that ends with /\n
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reflog message is primarily about easier identification, and
leaving truncated entry is much better than dying.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Released versions of fast-import have been able to create a tree that
contains files or subtrees that contain no name. Unfortunately these
trees aren't valid, but people may have actually tried to create them
due to bugs in import-tars.perl or their own fast-import frontend.
We now look for this unusual condition and warn the user if at
least one of their tree objects contains the problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* commit 'jc/maint': (35 commits)
Update git-http-fetch documentation
Update git-local-fetch documentation
Update git-http-push documentation
Update -L documentation for git-blame/git-annotate
Update git-grep documentation
Update git-fmt-merge documentation
Document additional options for git-fetch
Removing -n option from git-diff-files documentation
Start preparing for 1.5.1.3
Sanitize @to recipients.
git-svn: Ignore usernames in URLs in find_by_url
Document --dry-run and envelope-sender for git-send-email.
Allow users to optionally specify their envelope sender.
Ensure clean addresses are always used with Net::SMTP
Validate @recipients before using it for sendmail and Net::SMTP.
Perform correct quoting of recipient names.
Change the scope of the $cc variable as it is not needed outside of send_message.
Debugging cleanup improvements
Prefix Dry- to the message status to denote dry-runs.
Document --dry-run parameter to send-email.
...
riddochc on #git noticed corruption caused by import-tars. This
was fixed in the prior commit by Dscho, but fast-import was wrong
to have allowed a tree to be created with an empty string as the
filename. No operating system allows this, and Git itself doesn't
accept this into the index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some tars seem to have modes 0755 for directories, not 01000755. Do
not generate an empty object for them, but ignore them.
Noticed by riddochc on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch adds a new 'find-rev' command to git-svn that lets you easily
translate between SVN revision numbers and git tree-ish.
Signed-off-by: Adam Roben <aroben@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-http-fetch.txt: --recover to resume a failed fetch
operation.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-local-fetch.txt: -s to use
symbolic links instead of file-to-file copy, -l
to use hardlinks, -n to never use file-to-file
copies, --recover to resume a failed fetch.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-http-push.txt: Changing --complete to --all. Added
documentation for -d and -D to remote remote refs.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documenting alternate ways to use -L:
-L /regex/,end
-L start,+offset
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-grep.txt: Document -F/--fixed-strings to
search for non-regexp patterns. Document -I to not search
binary files. Document -<num> as a shortcut for -C<num>.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-fmt-merge-msg.txt:
--summary to list commit summaries on merge
--no-summary
--file to take merged objects from a file.
Configuration option merge.summary
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document --quiet/-q and --verbose/-v
Add -n as an alternate for --no-tags
Fix some whitespace issues
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
-n is not a short form of --no-index as the documentation
suggests. Removing it from the documentation and command
usage string.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The sed command that extracted the first line of the project description
didn't include the -n switch and hence the project name was being
printed twice. This was ruining the email header generation because it
was assumed that the description was only one line and was included in
the subject. This turned the subject into a two line item and
prematurely finished the header.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes a non-fast-forward update doesn't add new commits, it merely
removes old commits. This patch adds support for detecting that and
outputting a more correct message.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
as it is not relevant for whether the result should be written.
Even if no real merge happened, there might be _no_ reason to
rewrite the working tree file. Maybe even more so.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also leave a warning for future merge-recursive explorers.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a file is changed in one branch, and renamed and changed to the
same content in another branch than we can skip the rewrite of this
file in the working directory, as the content does not change.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Start preparing for 1.5.1.3
Sanitize @to recipients.
git-svn: Ignore usernames in URLs in find_by_url
Document --dry-run and envelope-sender for git-send-email.
Allow users to optionally specify their envelope sender.
Ensure clean addresses are always used with Net::SMTP
Validate @recipients before using it for sendmail and Net::SMTP.
Perform correct quoting of recipient names.
Change the scope of the $cc variable as it is not needed outside of send_message.
Debugging cleanup improvements
Prefix Dry- to the message status to denote dry-runs.
Document --dry-run parameter to send-email.
git-svn: Don't rely on $_ after making a function call
Fix handle leak in write_tree
Actually handle some-low memory conditions
Conflicts:
RelNotes
git-send-email.perl
We need to sanitize @to as well to ensure that names are properly quoted.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Usernames don't matter for the purposes of find_by_url, so always remove them
before doing any comparisons.
Signed-off-by: Adam Roben <aroben@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --date={local,relative,default} option to log family of commands,
to allow displaying timestamps in user's local timezone, relative time, or
the default format.
Existing --relative-date option is a synonym of --date=relative; we could
probably deprecate it in the long run.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Catch the documentation up with the rest of this patchset.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If your normal user is not the same user you are subscribed to a list with,
then the default envelope sender used will cause your messages to bounce or
silently vanish into the ether.
This patch provides an optional parameter to set the envelope sender.
To use it with the sendmail binary, you must have privileges to use the -f
parameter!
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Always pass in clean addresses to Net::SMTP for the MAIL FROM, and use them on
the SMTP non-quiet output as well.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ensure that @recipients is only raw addresses when it is handed to the sendmail
binary OR Net::SMTP, otherwise BCC cases might get an extra <, or wierd stuff
might be passed to the exec.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Always perform quoting of the recipient names if they contain periods,
previously only the author's address was treated this way. This stops sendmail
binaries from exploding the name into bad addresses.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$cc is only used inside the send_message scope, so lets clean it out of the global scope.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The debug output is much more helpful if it has the parameters that were used.
Pull the sendmail parameters into a seperate array for that, and also include
similar data during the Net::SMTP case.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While doing testing, it's useful to see that a dry run was actually done,
instead of a real one.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Looks like --dry-run was added to the code, but never to the --help output.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Many functions and operators in perl set $_, so its value cannot be relied upon
after calling arbitrary functions. The solution is simply to copy the value of
$_ into a local variable that will not get overwritten.
Signed-off-by: Adam Roben <aroben@apple.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a quick and dirty fix for the broken "git cherry-pick -n" on
some broken OS, which does not remove the directory entry after unlink
succeeded(!) if the file is still open somewher.
The entry is left but "protected": no open, no unlink, no stat.
Very annoying.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Tim Ansell discovered his Debian server didn't permit git-daemon to
use as much memory as it needed to handle cloning a project with
a 128 MiB packfile. Filtering the strace provided by Tim of the
rev-list child showed this gem of a sequence:
open("./objects/pack/pack-*.pack", O_RDONLY|O_LARGEFILE <unfinished ...>
<... open resumed> ) = 5
OK, so the packfile is fd 5...
mmap2(NULL, 33554432, PROT_READ, MAP_PRIVATE, 5, 0 <unfinished ...>
<... mmap2 resumed> ) = 0xb5e2d000
and we mapped one 32 MiB window from it at position 0...
mmap2(NULL, 31020635, PROT_READ, MAP_PRIVATE, 5, 0x6000 <unfinished ...>
<... mmap2 resumed> ) = -1 ENOMEM (Cannot allocate memory)
And we asked for another window further into the file. But got
denied. In Tim's case this was due to a resource limit on the
git-daemon process, and its children.
Now where are we in the code? We're down inside use_pack(),
after we have called unuse_one_window() enough times to make sure
we stay within our allowed maximum window size. However since we
didn't unmap the prior window at 0xb5e2d000 we aren't exceeding
the current limit (which probably was just the defaults).
But we're actually down inside xmmap()...
So we release the window we do have (by calling release_pack_memory),
assuming there is some memory pressure...
munmap(0xb5e2d000, 33554432 <unfinished ...>
<... munmap resumed> ) = 0
close(5 <unfinished ...>
<... close resumed> ) = 0
And that was the last window in this packfile. So we closed it.
Way to go us. Our xmmap did not expect release_pack_memory to
close the fd its about to map...
mmap2(NULL, 31020635, PROT_READ, MAP_PRIVATE, 5, 0x6000 <unfinished ...>
<... mmap2 resumed> ) = -1 EBADF (Bad file descriptor)
And so the Linux kernel happily tells us f' off.
write(2, "fatal: ", 7 <unfinished ...>
<... write resumed> ) = 7
write(2, "Out of memory? mmap failed: Bad "..., 47 <unfinished ...>
<... write resumed> ) = 47
And we report the bad file descriptor error, and not the ENOMEM,
and die, claiming we are out of memory. But actually that mmap
should have succeeded, as we had enough memory for that window,
seeing as how we released the prior one.
Originally when I developed the sliding window mmap feature I had
this exact same bug in fast-import, and I dealt with it by handing
in the struct packed_git* we want to open the new window for, as the
caller wasn't prepared to reopen the packfile if unuse_one_window
closed it. The same is true here from xmmap, but the caller doesn't
have the struct packed_git* handy. So I'm using the file descriptor
instead to perform the same test.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't need it, it's possible to assign the block of memory to bufp
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- Do not break the line when it's not needed
- s/Your/You
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This change 'opens' the code block which maps the index file into
memory, making the code clearer and easier to read.
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The interface is similar to the custom low-level merge drivers.
First you configure your filter driver by defining 'filter.<name>.*'
variables in the configuration.
filter.<name>.clean filter command to run upon checkin
filter.<name>.smudge filter command to run upon checkout
Then you assign filter attribute to each path, whose name
matches the custom filter driver's name.
Example:
(in .gitattributes)
*.c filter=indent
(in config)
[filter "indent"]
clean = indent
smudge = cat
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'ident' attribute set to path squashes "$ident:<any bytes
except dollor sign>$" to "$ident$" upon checkin, and expands it
to "$ident: <blob SHA-1> $" upon checkout.
As we have two conversions that affect checkin/checkout paths,
clarify how they interact with each other.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* mk/diff:
Diff between two blobs should take mode changes into account now.
use mode of the tree in git-diff, if <tree>:<file> syntax is used
store mode in rev_list, if <tree>:<filename> syntax is used
add add_object_array_with_mode
add get_sha1_with_mode
Add S_IFINVALID mode
* maint:
Remove usernames from all commit messages, not just when using svmprops
applymbox & quiltimport: typofix.
Create a sysconfdir variable, and use it for ETC_GITCONFIG
* 'master' of git://repo.or.cz/git/fastimport:
fast-import: size_t vs ssize_t
fix importing of subversion tars
Don't repack existing objects in fast-import
6777c380 fixed only one of three typos introduced in an earlier
patch 87ab7992. This fixes the other two.
Signed-off-by: Junio C Hamano <junkio@cox.net>
ETC_GITCONFIG defaults to $(prefix)/etc/gitconfig, so if you just set
prefix=/usr, you end up with a git that looks in /usr/etc/gitconfig, rather
than /etc/gitconfig as specified by the FHS. Furthermore, setting
ETC_GITCONFIG does not fix the paths to any future system-wide configuration
files.
Factor out the path to the system-wide configuration directory into a variable
sysconfdir, normally set to $(prefix)/etc, but set to /etc when prefix=/usr .
This fixes the prefix=/usr problem for ETC_GITCONFIG, and allows centralized
configuration of any future system-wide configuration files without requiring
further action from package maintainers or other people building and
installing git.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Each object in struct object_array is extended with the mode.
If not specified, S_IFINVALID is used. An object with an mode value
can be added with add_object_array_with_mode.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
get_sha1_with_mode basically behaves as get_sha1. It has an additional
parameter for storing the mode of the object.
If the mode can not be determined, it stores S_IFINVALID.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
S_IFINVALID is used to signal, that no mode information is available.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Documentation/git-reset.txt: suggest git commit --amend in example.
Build RPM with ETC_GITCONFIG=/etc/gitconfig
Ignore all man sections as they are generated files.
Fix typo in git-am: s/Was is/Was it/
Reverse the order of -b and --track in the man page.
dir.c(common_prefix): Fix two bugs
Conflicts:
git.spec.in
If $ls_remote_result was too long,
git-fetch--tool -s pick-rref "$rref" "$ls_remote_result"
in git-fetch will fail with "argument list too long".
This patch fixes git-fetch--tool and git-fetch by passing
$ls_remote_result via stdin.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Uwe Kleine-König discovered git-gui mangled his surname and did
not send the proper UTF-8 byte sequence to git-commit-tree when
his name appeared in the commit message (e.g. Signed-Off-By line).
Turns out this was related to other trouble that I had in the past
with trying to use "fconfigure $fd -encoding $enc" to select the
stream encoding and let Tcl's IO engine do all of the encoding work
for us. Other parts of git-gui were just always setting the file
channels to "-encoding binary" and then performing the encoding
work themselves using "encoding convertfrom" and "convertto", as
that was the only way I could make UTF-8 filenames work properly.
I found this same bug in the amend code path, and in the blame
display. So its fixed in all three locations (commit creation,
reloading message for amend, viewing message in blame).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a new configuration option clean.requireForce. If set, git-clean will
refuse to run, unless forced with the new -f option, or not acting due to -n.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of running rev-list and picking earlier lines using head/tail pipeline,
grab commit object name as we build commits. This also removes a non POSIX
use of tail with -linenum (more posixly-correct way to say it is "-n linenum")
Signed-off-by: Junio C Hamano <junkio@cox.net>
A Large Angry SCM (gitzilla) noticed that on an unnamed platform, tail -c
wants its byte count as part of the option, not as a separate argument.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-commit got chatty, we have to shut it up again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is nice to see what is happening when checking out large amount of
files, either with git-checkout or git-reset. The new progress code
already decides what is a "significant amount" and displays progress
only in that case..
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using "-b --track newbranch oldbranch" gives the error:
git checkout: updating paths is incompatible with switching
branches/forcing
However, "--track -b ..." works just fine.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function common_prefix() is used to find the common subdirectory of
a couple of pathnames. When checking if the next pathname matches up with
the prefix, it incorrectly checked the whole path, not just the prefix
(including the slash). Thus, the expensive part of the loop was executed
always.
The other bug is more serious: if the first and the last pathname in the
list have a longer common prefix than the common prefix for _all_ pathnames
in the list, the longer one would be chosen. This bug was probably hidden
by the fact that bash's wildcard expansion sorts the results, and the code
just so happens to work with sorted input.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes all low-level functions defined in read-cache.c to
take an explicit index_state structure as their first parameter,
to specify which index to work on. These functions
traditionally operated on "the_index" and were named foo_cache();
the counterparts this patch introduces are called foo_index().
The traditional foo_cache() functions are made into macros that
give "the_index" to their corresponding foo_index() functions.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This defines a index_state structure and moves index-related
global variables into it. Currently there is one instance of
it, the_index, and everybody accesses it, so there is no code
change.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, gitweb shows only header and footer, if no differences are
found. This patch adds a "No differences found" message for the html
output.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let's start displaying progress only if more than 50% of total number
of files remains to be checked out after 2 seconds.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows for progress to be displayed only if the progress has not
reached a specified percentage treshold within a given delay in seconds.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the progress bar ends up in a box, better provide a title for it too.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of having this code duplicated in multiple places, let's have
a common interface for progress display. If someday someone wishes to
display a cheezy progress bar instead then only one file will have to
be changed.
Note: I left merge-recursive.c out since it has a strange notion of
progress as it apparently increase the expected total number as it goes.
Someone with more intimate knowledge of what that is supposed to mean
might look at converting it to the common progress interface.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This enhances the attributes mechanism so that external programs
meant for existing GIT_EXTERNAL_DIFF interface can be specifed
per path.
To configure such a custom diff driver, first define a custom
diff driver in the configuration:
[diff "my-c-diff"]
command = <<your command string comes here>>
Then mark the paths that you want to use this custom driver
using the attribute mechanism.
*.c diff=my-c-diff
The intent of this separation is that the attribute mechanism is
used for specifying the type of the contents, while the
configuration mechanism is used to define what needs to be done
to that type of the contents, which would be specific to both
platform and personal taste.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier quickfix forced world-readable permission bits. This
updates it to honor umask and core.sharedrepository settings.
Signed-off-by: Junio C Hamano <junkio@cox.net>
mkstemp() often creates the file in 0600 which means the
resulting packfile is not readable by anybody other than the
repository owner. Force 0644 for now, even though this is not
strictly correct.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reallocated wrong size.
Noticed on Ubuntu 7.04 probably because it has some malloc diagnostics in libc:
"git-read-tree --reset -u HEAD" aborted in the test. Valgrind sped up the
debugging greatly: took me 10 minutes.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also, noticed by valgrind: the code caused a read out-of-bounds.
Some comments updated as well (they still reflected old calling
conventions).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I want to add new command line options to cat-file, but
to do that we need to change how we handle argv[] first.
This is a simple cleanup that assigns names to the two
arguments we currently care about.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'jc/attr': (28 commits)
lockfile: record the primary process.
convert.c: restructure the attribute checking part.
Fix bogus linked-list management for user defined merge drivers.
Simplify calling of CR/LF conversion routines
Document gitattributes(5)
Update 'crlf' attribute semantics.
Documentation: support manual section (5) - file formats.
Simplify code to find recursive merge driver.
Counto-fix in merge-recursive
Fix funny types used in attribute value representation
Allow low-level driver to specify different behaviour during internal merge.
Custom low-level merge driver: change the configuration scheme.
Allow the default low-level merge driver to be configured.
Custom low-level merge driver support.
Add a demonstration/test of customized merge.
Allow specifying specialized merge-backend per path.
merge-recursive: separate out xdl_merge() interface.
Allow more than true/false to attributes.
Document git-check-attr
Change attribute negation marker from '!' to '-'.
...
* lt/gitlink:
Tests for core subproject support
Expose subprojects as special files to "git diff" machinery
Fix some "git ls-files -o" fallout from gitlinks
Teach "git-read-tree -u" to check out submodules as a directory
Teach git list-objects logic to not follow gitlinks
Fix gitlink index entry filesystem matching
Teach "git-read-tree -u" to check out submodules as a directory
Teach git list-objects logic not to follow gitlinks
Don't show gitlink directories when we want "other" files
Teach git-update-index about gitlinks
Teach directory traversal about subprojects
Fix thinko in subproject entry sorting
Teach core object handling functions about gitlinks
Teach "fsck" not to follow subproject links
Add "S_IFDIRLNK" file mode infrastructure for git links
Add 'resolve_gitlink_ref()' helper function
Avoid overflowing name buffer in deep directory structures
diff-lib: use ce_mode_from_stat() rather than messing with modes manually
* np/pack: (27 commits)
document --index-version for index-pack and pack-objects
pack-objects: remove obsolete comments
pack-objects: better check_object() performances
add get_size_from_delta()
pack-objects: make in_pack_header_size a variable of its own
pack-objects: get rid of create_final_object_list()
pack-objects: get rid of reuse_cached_pack
pack-objects: clean up list sorting
pack-objects: rework check_delta_limit usage
pack-objects: equal objects in size should delta against newer objects
pack-objects: optimize preferred base handling a bit
clean up add_object_entry()
tests for various pack index features
use test-genrandom in tests instead of /dev/urandom
simple random data generator for tests
validate reused pack data with CRC when possible
allow forcing index v2 and 64-bit offset treshold
pack-redundant.c: learn about index v2
show-index.c: learn about index v2
sha1_file.c: learn about index version 2
...
* jc/quickfetch:
Make sure quickfetch is not fooled with a previous, incomplete fetch.
git-fetch: use fetch--tool pick-rref to avoid local fetch from alternate
git-fetch--tool pick-rref
* maint:
GIT 1.5.1.2
perl: install private Error.pm if the site version is older than our own
git-clone: fix dumb protocol transport to clone from pack-pruned ref
bdash (on IRC) had a problem with Git.pm (via git-svn) when his
site installation of Error.pm was older than the version we
package.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The usual process flow is the main process opens and holds the lock to
the index, does its thing, perhaps spawning children during the course,
and then writes the resulting index out by releaseing the lock.
However, the lockfile interface uses atexit(3) to clean it up, without
regard to who actually created the lock. This typically leads to a
confusing behaviour of lock being released too early when the child
exits, and then the parent process when it calls commit_lockfile()
finds that it cannot unlock it.
This fixes the problem by recording who created and holds the lock, and
upon atexit(3) handler, child simply ignores the lockfile the parent
created.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This separates the checkattr() call and interpretation of the
returned value specific to the 'crlf' attribute into separate
routines, so that we can run a single call to checkattr() to
check for more than one attributes, and then interprete what
the returned settings mean separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Duh.
When I did the object decorator thing, I made the "loop over the hash"
function use the same logic for updating the hash, ie made them use
if (++j >= size)
j = 0;
for both the hash update for both "insert" and "lookup"
HOWEVER.
For some inexplicable reason I had an extraneous
j++;
in the insert path (probably just from the fact that the old code there
used
j++;
if (j >= size)
j = 0;
and when I made them use the same logic I just didn't remove the old
extraneous line properly.
This fixes it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some users of fast-import have been trying to use it to rewrite
commits and trees, an activity where the all of the relevant blobs
are already available from the existing packfiles. In such a case
we don't want to repack a blob, even if the frontend application
has supplied us the raw data rather than a mark or a SHA-1 name.
I'm intentionally only checking the packfiles that existed when
fast-import started and am always ignoring all loose object files.
We ignore loose objects because fast-import tends to operate on a
very large number of objects in a very short timespan, and it is
usually creating new objects, not reusing existing ones. In such
a situtation the majority of the objects will not be found in the
existing packfiles, nor will they be loose object files. If the
frontend application really wants us to look at loose object files,
then they can just repack the repository before running fast-import.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a shorthand of what "git commit -a" does in preparation
for making a commit, which is:
git diff-files --name-only -z | git update-index --remove -z --stdin
Signed-off-by: Junio C Hamano <junkio@cox.net>
List files modifed as a part of the commit in the diff window
Support annotation of the file listed in the diff window
Support history browsing in the annotation window.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The mess known as the progress meter in merge-recursive was my own
fault; I put it in thinking that we might be spending a lot of time
resolving unmerged entries in the index that were not handled by
the simple 3-way index merge code.
Turns out we don't really spend that much time there, so the progress
meter was pretty much always jumping to "(n/n) 100%" as soon as
the program started. That isn't a very good indication of progress.
Since I don't have a great solution for how a progress meter should
work here, I'm proposing we back it out entirely.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a description of the commit to the reflog using the first line of
the log message, the same way the git-commit script does it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm using a variant of this update hook in a corporate environment
where we perform some validations of the commits and tags that
are being pushed. The model is a "central repository" type setup,
where users are given access to push to specific branches within
the shared central repository. In this particular installation we
run a specially patched git-receive-pack in setuid mode via SSH,
allowing all writes into the repository as the repository owner,
but only if this hook blesses it.
One of the major checks we perform with this hook is that the
'committer' line of a commit, or the 'tagger' line of a new annotated
tag actually correlates to the UNIX user who is performing the push.
Users can falsify these lines on their local repositories, but
the central repository that management trusts will reject all such
forgery attempts. Of course 'author' lines are still allowed to
be any value, as sometimes changes do come from other individuals.
Another nice feature of this hook is the access control lists for
all repositories on the system can also be stored and tracked in
a supporting Git repository, which can also be access controlled
by itself. This allows full auditing of who-had-what-when-and-why,
thanks to git-blame's data mining capabilities.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Alex Riesen noticed that the case where a file replaced a directory entry
in the working tree was broken on cygwin. It turns out that the code made
some Linux-specific assumptions, and also ignored errors entirely for the
case where the entry was a symlink rather than a file.
This cleans it up by separating out the common case into a function of its
own, so that both regular files and symlinks can share it, and by making
the error handling more obvious (and not depend on any Linux-specific
behaviour).
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the semantics of 'crlf' so that .gitattributes file
can say "this is text, even though it may look funny".
Setting the `crlf` attribute on a path is meant to mark the path
as a "text" file. 'core.autocrlf' conversion takes place
without guessing the content type by inspection.
Unsetting the `crlf` attribute on a path is meant to mark the
path as a "binary" file. The path never goes through line
endings conversion upon checkin/checkout.
Unspecified `crlf` attribute tells git to apply the
`core.autocrlf` conversion when the file content looks like
text.
Setting the `crlf` attribut to string value "input" is similar
to setting the attribute to `true`, but also forces git to act
as if `core.autocrlf` is set to `input` for the path.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-config.txt: Added documentation for --system
Documentation/builtin-config.c: Added --system to the short usage
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In asciidoc 7.1.2 and prior there is no obvious way to get:
'add'ing
to emphasize only the "add", instead it treats the first apostrophe as the
beginning of an emphasis, and the second apostrophe as a regular
apostrophe and makes the rest of the line an emphasis since there is no
closing apostrophe. In the newer asciidoc you can do it pretty easily
with __add__ing but I'm not sure it would be best to make that a prereq
for something as silly as this.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-cherry-pick.txt: Remove --replay as it is not
handled by the code (-r is however).
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-archive.txt: Document -v/--verbose option.
Add -l as short form of --list.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Two scanf() calls were converted to strtoul_ui() but the return
values were not updated to match. scanf() returns the number of
matched "values" which for this usage is 1 on success. strtoul_ui()
return 0 on success. Update these call sites to match.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is no need to intern the string to git_attr, as we are already
dealing with the name of the driver there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the configuration has variables unrelated to low-level
merge drivers (e.g. merge.summary), the code failed to ignore
them but did something totally senseless.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a set of radiobuttons that select between displaying the full
diff (both - and + lines), the old file (suppressing the + lines) and the
new file (suppressing the - lines) in the diff display window.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The following tests available:
- create subprojects: create a directory in the superproject,
initialize a git repo in it, and try adding it in super project.
Make a commit in superproject
- check if fsck ignores the subprojects: it just should give no errors
- check if commit in a subproject detected: make a commit in
subproject, git-diff-files in superproject should detect it
- check if a changed subproject HEAD can be committed: try
"git-commit -a" in superproject. It should commit changed
HEAD of a subproject
- check if diff-index works for subproject elements: compare the index
(changed by previuos tests) with the initial commit (which created
two subprojects). Should show a change for the recently changed subproject
- check if diff-tree works for subproject elements: do the same, just use
git-diff-tree. This test is somewhat redundant, I just added it for
completeness (diff, diff-files, and diff-index are already used)
- check if git diff works for subproject elements: try to limit
the diff for the name of a subproject in superproject:
git diff HEAD^ HEAD -- subproject
- check if clone works: try a clone of superproject and compare
"git ls-files -s" output in superproject and cloned repo
- removing and adding subproject: rename test. Currently implemented
as "git-update-index --force-remove", "mv" and "git-add".
- checkout in superproject: try to checkout the initial commit
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than sorting the refs list while building it, sort in one
go after it is built using a merge sort. This has a large
performance boost with large numbers of refs.
It shouldn't happen that we read duplicate entries into the same
list, but just in case sort_ref_list drops them if the SHA1s are
the same, or dies, as we have no way of knowing which one is the
correct one.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-shortlog: Fix two formatting errors in asciidoc documentation
Fix overwriting of files when applying contextually independent diffs
git-svn: don't allow globs to match regular files
It was bothering me a lot that I abused small integer values
casted to (void *) to represent non string values in
gitattributes. This corrects it by making the type of attribute
values (const char *), and using the address of a few statically
allocated character buffer to denote true/false. Unset attributes
are represented as having NULLs as their values.
Added in-header documentation to explain how git_checkattr()
routine should be called.
Signed-off-by: Junio C Hamano <junkio@cox.net>
First use [verse] in the SYNOPSIS so that the line break actually
shows.
Secondly drop the quotes around '.mailmap' since this exposes
a bug in our toolchain (didn't bother enough yet to find out wether
it is asciidoc's fault or that of the XSL templates) that leads to
the dot not getting escaped correctly in the roff output and thereby
swallowing the line.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed by applying two diffs of different contexts to the same file.
The check for existence of a file was wrong: the test assumed it was
a directory and reset the errno (twice: directly and by calling
lstat). So if an entry existed and was _not_ a directory no attempt
was made to rename into it, because the errno (expected by renaming
code) was already reset to 0. This resulted in error:
fatal: unable to write file file mode 100644
For Linux, removing "errno = 0" is enough, as lstat wont modify errno
if it was successful. The behavior should not be depended upon,
though, so modify the "if" as well.
The test simulates this situation.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git only tracks the histories of full directories, not
that of individual files. Sometimes, SVN users will
place[1] a regular file in the directory designated
for subdirectories of branches or tags.
Thanks to jrockway on #git for pointing this out.
[1] mistakenly or otherwise, such as a README
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows [merge "drivername"] to have a variable "recursive"
that names a different low-level merge driver to be used when
merging common ancestors to come up with a virtual ancestor.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the configuration syntax for defining a low-level
merge driver to be:
[merge "<<drivername>>"]
driver = "<<command line>>"
name = "<<driver description>>"
which is much nicer to read and is extensible. Credit goes to
Martin Waitz and Linus.
In addition, when we use an external low-level merge driver, it
is reported as an extra output from merge-recursive, using the
value of merge.<<drivername>.name variable.
The demonstration in t6026 has also been updated.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When no 'merge' attribute is given to a path, merge-recursive
uses the built-in xdl-merge as the low-level merge driver.
A new configuration item 'merge.default' can name a low-level
merge driver of user's choice to be used instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows users to specify custom low-level merge driver per
path, using the attributes mechanism. Just like you can specify
one of built-in "text", "binary", "union" low-level merge
drivers by saying:
* merge=text
.gitignore merge=union
*.jpg merge=binary
pick a name of your favorite merge driver, and assign it as the
value of the 'merge' attribute.
A custom low-level merge driver is defined via the config
mechanism. This patch introduces 'merge.driver', a multi-valued
configuration. Its value is the name (i.e. the one you use as
the value of 'merge' attribute) followed by a command line
specification. The command line can contain %O, %A, and %B to
be interpolated with the names of temporary files that hold the
common ancestor version, the version from your branch, and the
version from the other branch, and the resulting command is
spawned.
The low-level merge driver is expected to update the temporary
file for your branch (i.e. %A) with the result and exit with
status 0 for a clean merge, and non-zero status for a conflicted
merge.
A new test in t6026 demonstrates a sample usage.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* fl/cvsserver:
config.txt: Add gitcvs.db* variables
cvsserver: Document the GIT branches -> CVS modules mapping more prominently
cvsserver: Reword documentation on necessity of write access
cvsserver: Allow to "add" a removed file
cvsserver: Add asciidoc documentation for new database backend configuration
cvsserver: Corrections to the database backend configuration
cvsserver: Use DBI->table_info instead of DBI->tables
cvsserver: Abort if connect to database fails
cvsserver: Make the database backend configurable
cvsserver: Allow to override the configuration per access method
cvsserver: Handle three part keys in git config correctly
cvsserver: Introduce new state variable 'method'
Conflicts:
Documentation/config.txt
delete_ref function does not change the 'sha1' parameter. Non-const pointer
causes a compiler warning if you call to the function using a const argument.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Start preparing for 1.5.1.2
git-svn: quiet some warnings when run only with --version/--help
git-svn: respect lower bound of -r/--revision when following parent
Conflicts:
RelNotes
* 'master' of git://repo.or.cz/git-gui:
git-gui: Honor TCLTK_PATH if supplied
Revert "Allow wish interpreter to be defined with TCLTK_PATH"
git-gui: Display the directory basename in the title
git-gui: Brown paper bag fix division by 0 in blame
Always bind the return key to the default button
Do not break git-gui messages into multiple lines.
Improve look-and-feel of the git-gui tool.
Teach git-gui to use the user-defined UI font everywhere.
Allow wish interpreter to be defined with TCLTK_PATH
* jc/read-tree-df:
t3030: merge-recursive backend test.
merge-recursive: handle D/F conflict case more carefully.
merge-recursive: do not barf on "to be removed" entries.
Treat D/F conflict entry more carefully in unpack-trees.c::threeway_merge()
t1000: fix case table.
This demonstrates how the new low-level per-path merge backends,
union and ours, work, and shows how they are controlled by the
gitattribute mechanism.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows 'merge' attribute to control how the file-level
three-way merge is done per path.
- If you set 'merge' to true, leave it unspecified, or set it
to "text", we use the built-in 3-way xdl-merge.
- If you set 'merge' to false, or set it to "binary, the
"binary" merge is done. The merge result is the blob from
'our' tree, but this still leaves the path conflicted, so
that the mess can be sorted out by the user. This is
obviously meant to be useful for binary files.
- 'merge=union' (this is the first example of a string valued
attribute, introduced in the previous one) uses the "union"
merge. The "union" merge takes lines in conflicted hunks
from both sides, which is useful for line-oriented files such
as .gitignore.
Instead fo setting merge to 'true' or 'false' by using 'merge'
or '-merge', setting it explicitly to "text" or "binary" will
become useful once we start allowing custom per-path backends to
be added, and allow them to be activated for the default
(i.e. 'merge' attribute specified to 'true' or 'false') case,
using some other mechanisms. Setting merge attribute to "text"
or "binary" will be a way to explicitly request to override such
a custom default for selected paths.
Currently there is no way to specify random programs but it
should be trivial for motivated contributors to add later.
There is one caveat, though. ll_merge() is called for both
internal ancestor merge and the outer "final" merge. I think an
interactive custom per-path merge backend should refrain from
going interactive when performing an internal merge (you can
tell it by checking call_depth) and instead just call either
ll_xdl_merge() if the content is text, or call ll_binary_merge()
otherwise.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mimick what we do for gitk. Since you do have a source file,
git-gui.sh, which is separate from the target, it should be much
easier in git-gui's Makefile.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit e2a1bc67d3.
Junio rightly pointed out this patch doesn't handle the
`make install` target very well:
Junio C Hamano <junkio@cox.net> writes:
> You should never generate new files in the source tree from
> 'install' target. Otherwise, the usual pattern of "make" as
> yourself and then "make install" as root would not work from a
> "root-to-nobody-squashing" NFS mounted source tree to local
> filesystem. You should know better than accepting such a patch.
When an explicit --revision argument is specified, do not fetch
past the specified range into the beginning of history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to define three values (and possibly more) to
each attribute: true, false, and unset.
Typically the handlers that notice and act on attribute values
treat "unset" attribute to mean "do your default thing"
(e.g. crlf that is unset would trigger "guess from contents"),
so being able to override a setting to an unset state is
actually useful.
- If you want to set the attribute value to true, have an entry
in .gitattributes file that mentions the attribute name; e.g.
*.o binary
- If you want to set the attribute value explicitly to false,
use '-'; e.g.
*.a -diff
- If you want to make the attribute value _unset_, perhaps to
override an earlier entry, use '!'; e.g.
*.a -diff
c.i.a !diff
This also allows string values to attributes, with the natural
syntax:
attrname=attrvalue
but you cannot use it, as nobody takes notice and acts on
it yet.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates git-rev-list --objects to be a bit more careful
when listing a blob object to make sure the blob actually
exists, and uses it to make sure the quick-fetch optimization we
introduced earlier is not fooled by a previous incomplete fetch.
The quick-fetch optimization works by running this command:
git rev-list --objects <<commit-list>> --not --all
where <<commit-list>> is a list of commits that we are going to
fetch from the other side. If there is any object missing to
complete the <<commit-list>>, the rev-list would fail and die
(say, the commit was in our repository, but its tree wasn't --
then it will barf while trying to list the blobs the tree
contains because it cannot read that tree).
Usually we do not have the objects (otherwise why would we
fetching?), but in one important special case we do: when the
remote repository is used as an alternate object store
(i.e. pointed by .git/objects/info/alternates). We could check
.git/objects/info/alternates to see if the remote we are
interacting with is one of them (or is used as an alternate,
recursively, by one of them), but that check is more cumbersome
than it is worth.
The above check however did not catch missing blob, because
object listing code did not read nor check blob objects, knowing
that blobs do not contain any further references to other
objects. This commit fixes it with practically unmeasurable
overhead.
I've benched this with
git rev-list --objects --all >/dev/null
in the kernel repository, with three different implementations
of the "check-blob".
- Checking with has_sha1_file() has negligible (unmeasurable)
performance penalty.
- Checking with sha1_object_info() makes it somewhat slower,
perhaps by 5%.
- Checking with read_sha1_file() to cause a fully re-validation
is prohibitively expensive (about 4 times as much runtime).
In my original patch, I had this as a command line option, but
the overhead is small enough that it is not really worth it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This replaces the fairly odd "created_object()" function that did _most_
of the object setup with a more complete "create_object()" function that
also has a more natural calling convention.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to use a different allocator scheme for when we didn't know the
object type. That meant that objects that were created without any
up-front knowledge of the type would not go through the same allocation
paths as normal object allocations, and would miss out on the statistics.
But perhaps more importantly than the statistics (that are useful when
looking at memory usage but not much else), if we want to make the
object hash tables use a denser object pointer representation, we need
to make sure that they all go through the same blocking allocator.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With large amount of objects, check_object() is really trashing the pack
sliding map and the filesystem cache. It has a completely random access
pattern especially with old objects where delta replay jumps back and
forth all over the pack.
This patch improves things by:
1) sorting objects by their offset in pack before calling check_object()
so the pack access pattern is linear;
2) recording the object type at add_object_entry() time since it is
already known in most cases;
3) recording the pack offset even for preferred_base objects;
4) avoid calling sha1_object_info() if all possible.
This limits pack accesses to the bare minimum and makes them perfectly
linear.
In the process check_object() was made more clear (to me at least).
Note: I thought about walking the sorted_by_offset list backward in
get_object_details() so if a pack happens to be larger than the available
file cache, then the cache would have been populated with useful data from
the beginning of the pack already when find_deltas() is called. Strangely,
testing (on Linux) showed absolutely no performance difference.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... which consists of existing code split out of packed_delta_info()
for other callers to use it as well.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It currently aliases delta_size on the principle that reused deltas won't
go through the whole delta matching loop hence delta_size was unused.
This is not true if given delta doesn't find its base in the pack though.
But we need that information even for whole object data reuse.
Well in short the current state looks awful and is prone to bugs. It just
works fine now because try_delta() tests trg_entry->delta before using
trg_entry->delta_size, but that is a bit subtle and I was wondering for a
while why things just worked fine... even if I'm guilty of having
introduced this abomination myself in the first place.
Let's do the sensible thing instead with no ambiguity, which is to have
a separate variable for in_pack_header_size. This might even help future
optimizations.
While at it, let's reorder some struct object_entry members so they all
align well with their own width, regardless of the architecture or the
size of off_t. Some memory saving is to be expected with this alone.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we don't have to know the SHA1 h(hence the name) of the pack
up front anymore, let's get rid of yet another global sorted object list
and sort them only in write_index_file(), then compute the object list
SHA1 on the fly.
This has the advantage of saving another chunk of memory, and the sorted
list SHA1 won't be computed needlessly on servers during a fetch.
Of course the cunning plan is also to make write_index_file() much like
the function with the same name in index-pack.c for an eventual easy
sharing.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This capability is practically never useful, and therefore never tested,
because it is fairly unlikely that the requested pack will be already
available. Furthermore it is of little gain over the ability to reuse
existing pack data.
In fact the ability to change delta type on the fly when reusing delta
data is a nice thing that has almost no cost and allows greater backward
compatibility with a client's capabilities than if the client is blindly
sent a whole pack without any discrimination.
And this "feature" is simply in the way of other cleanups.
Let's get rid of it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Get rid of sort_comparator() as it impose a run time double indirect
function call for little compile time type checking gain.
Also get rid of create_sorted_list() as it only has one user which would
as well be just fine doing its sorting locally. Eventually the list of
deltifiable objects might be shorter than the whole object list.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Objects that have delta "children" from pack data reuse must consider the
depth of their deepest child when they try to deltify themselves for those
children not to become too deep.
However, in the context of a "thin" pack, the delta children depth was
skipped entirely on the presumption that the pack was always going to be
exploded on the receiving end, hence the delta length wasn't an issue.
Now that we keep received packs as is and reuse pack data when repacking,
those packs do contain delta chains that are longer than expected. Worse,
those delta chain may even grow longer when the pack is further repacked
into another thin pack for a subsequent transmission.
So this patch restores strict delta length even for thin packs, and it
moves check_delta_limit() usage directly in the delta loop where it is
needed. This way the delta_limit can be removed from struct object_entry
as well. Oh and the initial value was wrong too.
The progress_interval() function was moved to a more logical location in
the process.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Before finding best delta combinations, we sort objects by name hash,
then by size, then by their position in memory. Then we walk the list
backwards to test delta candidates.
We hope that a bigger size usually means a newer objects. But a bigger
address in memory does not mean a newer object. So the last comparison
must be reversed.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let's avoid some cycles when there is no base to test against, and avoid
unnecessary object lookups.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/wrap-log:
Fix permissions on test scripts
Fix t4201: accidental arithmetic expansion
shortlog -w: make wrap-line behaviour optional.
Use print_wrapped_text() in shortlog
Make every test executable. Remove exec-attribute from included shell files,
they can't used standalone anyway.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
instead of embedded subshell. It actually breaks here (dash as /bin/sh):
t4201-shortlog.sh: 27: Syntax error: Missing '))'
FATAL: Unexpected exit with code 2
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "--decorate" as a log option, which prints out the ref names
of any commits that are shown.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to add an arbitrary "decoration" of your choice to any
object. It's a space- and time-efficient way to add information to
arbitrary objects, especially if most objects probably do not have the
decoration.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Have sample update hook not refuse deleting a branch through push.
variable $projectdesc needs to be set before checking against unchanged default.
Update git-annotate/git-blame documentation
Update git-apply documentation
Update git-applymbox documentation
Update git-am documentation
user-manual: use detached head when rewriting history
user-manual: start revising "internals" chapter
user-manual: detached HEAD
user-manual: fix discussion of default clone
Documentation: clarify track/no-track option.
Documentation: clarify git-checkout -f, minor editing
Documentation: minor edits of git-lost-found manpage
source ref might be 0000...0000 to delete a branch through git-push,
'git <remote> push :<branch>'. The update hook should not decline this.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Moved options that pertained to both git-blame and git-annotate to a
common file blame-options.txt.
builtin-blame.c: Removed --compatibility, --long, --time from the
short usage as they are not handled in the code.
Documentation/git-blame.txt: Removed common options to git-annotate.
Added documentation for --score-debug. Removed --compatibility.
Adjusted usage at top to not wrap on 80 columns.
Documentation/git-annotate.txt: Using common options blame-options.txt.
Documentation/blame-options.txt: Added -b note about associated config
option, added --root note about associated config option, added
documentation for --show-stats. Removed --long, --time, --rev-file as
those options do not really exist. Added documentation for -M/-C taking
an optional score argument for detection of moved lines.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document -v (short form of --verbose). Redo usage
to not wrap on 80 column terminal with typical
settings.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-applymbox.txt: updating -u documentation to include
fact that it encodes to the i18n.commitencoding setting, not just utf-8.
Added documentation of -n option to pass -n to git-mailinfo.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-am.txt missing several short versions
of options. Added documentation for --resolvemsg=<msg>
command-line option.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is slightly simpler if we use a detached head. And it's probably
good to have another example that uses this feature.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a brief mention of detached HEADs and .git/HEAD.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The name "master" isn't actually quite so special. Also, fix some bad
grammar.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix the description of the --no-track option so it no longer says the
opposite of what was intended. Also mention branch.autosetupmerge
explicitly.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"Force a re-read of everything" doesn't mean much to me.
Also some minor grammar fixes.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Minor improvements to grammar and clarity of lost-found manpage.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Useful e.g. to figure out what I did from screen history,
or to make sure subject line is short enough and makes sense
on its own.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/SubmittingPatches: Add note that all user interface changes
should include associated documentation updates.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Document -g (--walk-reflogs) option of git-log
sscanf/strtoul: parse integers robustly
git-blame: Fix overrun in fake_working_tree_commit()
[PATCH] Improve look-and-feel of the gitk tool.
[PATCH] Teach gitk to use the user-defined UI font everywhere.
At the same time, we do not want to allow arbitrary strings for
attribute names, as we are likely to want to extend the syntax
later. Allow only alnum, dash, underscore and dot for now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "attribute macros" (for lack of better name). So far,
we have low-level attributes such as crlf and diff, which are
defined in operational terms --- setting or unsetting them on a
particular path directly affects what is done to the path. For
example, in order to decline diffs or crlf conversions on a
binary blob, no diffs on PostScript files, and treat all other
files normally, you would have something like these:
* diff crlf
*.ps !diff
proprietary.o !diff !crlf
That is fine as the operation goes, but gets unwieldy rather
rapidly, when we start adding more low-level attributes that are
defined in operational terms. A near-term example of such an
attribute would be 'merge-3way' which would control if git
should attempt the usual 3-way file-level merge internally, or
leave merging to a specialized external program of user's
choice. When it is added, we do _not_ want to force the users
to update the above to:
* diff crlf merge-3way
*.ps !diff
proprietary.o !diff !crlf !merge-3way
The way this patch solves this issue is to realize that the
attributes the user is assigning to paths are not defined in
terms of operations but in terms of what they are.
All of the three low-level attributes usually make sense for
most of the files that sane SCM users have git operate on (these
files are typically called "text'). Only a few cases, such as
binary blob, need exception to decline the "usual treatment
given to text files" -- and people mark them as "binary".
So this allows the $GIT_DIR/info/alternates and .gitattributes
at the toplevel of the project to also specify attributes that
assigns other attributes. The syntax is '[attr]' followed by an
attribute name followed by a list of attribute names:
[attr] binary !diff !crlf !merge-3way
When "binary" attribute is set to a path, if the path has not
got diff/crlf/merge-3way attribute set or unset by other rules,
this rule unsets the three low-level attributes.
It is expected that the user level .gitattributes will be
expressed mostly in terms of attributes based on what the files
are, and the above sample would become like this:
(built-in attribute configuration)
[attr] binary !diff !crlf !merge-3way
* diff crlf merge-3way
(project specific .gitattributes)
proprietary.o binary
(user preference $GIT_DIR/info/attributes)
*.ps !diff
There are a few caveats.
* As described above, you can define these macros only in
$GIT_DIR/info/attributes and toplevel .gitattributes.
* There is no attempt to detect circular definition of macro
attributes, and definitions are evaluated from bottom to top
as usual to fill in other attributes that have not yet got
values. The following would work as expected:
[attr] text diff crlf
[attr] ps text !diff
*.ps ps
while this would most likely not (I haven't tried):
[attr] ps text !diff
[attr] text diff crlf
*.ps ps
* When a macro says "[attr] A B !C", saying that a path does
not have attribute A does not let you tell anything about
attributes B or C. That is, given this:
[attr] text diff crlf
[attr] ps text !diff
*.txt !ps
path hello.txt, which would match "*.txt" pattern, would have
"ps" attribute set to zero, but that does not make text
attribute of hello.txt set to false (nor diff attribute set to
true).
Signed-off-by: Junio C Hamano <junkio@cox.net>
I lost it by mistake while shuffling the gitattributes series which
originally was on top of the subproject topic onto the master branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is in the same spirit as the previous one. Earlier 'diff'
meant 'do the built-in binary heuristics and disable patch text
generation based on it' while '!diff' meant 'do not guess, do
not generate patch text'. There was no way to say 'do generate
patch text even when the heuristics says it has NUL in it'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we said 'crlf lets the path go through core.autocrlf
process while !crlf disables it altogether'. This fixes the
semantics to:
- Lack of 'crlf' attribute makes core.autocrlf to apply
(i.e. we guess based on the contents and if platform
expresses its desire to have CRLF line endings via
core.autocrlf, we do so).
- Setting 'crlf' attribute to true forces CRLF line endings in
working tree files, even if blob does not look like text
(e.g. contains NUL or other bytes we consider binary).
- Setting 'crlf' attribute to false disables conversion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The same way we generate diffs on symlinks as the the diff of text of the
symlink, we can generate subproject diffs (when not recursing into them!)
as the diff of the text that describes the subproject.
Of course, since what descibes a subproject is just the SHA1, that's what
we'll use. Add some pretty-printing to make it a bit more obvious what is
going on, and we're done.
So with this, we can get both raw diffs and "textual" diffs of subproject
changes:
- git diff --raw:
:160000 160000 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5 0000000... M sub-A
- git diff:
diff --git a/sub-A b/sub-A
index 2de597b..e8f11a4 160000
--- a/sub-A
+++ b/sub-A
@@ -1 +1 @@
-Subproject commit 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5
+Subproject commit e8f11a45c5c6b9e2fec6d136d3fb5aff75393d42
NOTE! We'll also want to have the ability to recurse into the subproject
and actually diff it recursively, but that will involve a new command line
option (I'd suggest "--subproject" and "-S", but the latter is in use by
pickaxe), and some very different code.
But regardless of ay future recursive behaviour, we need the non-recursive
version too (and it should be the default, at least in the absense of
config options, so that large superprojects don't default to something
extremely expensive).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
By showing the basename of the directory very early in the
title bar I can more easily locate a particular git-gui
session when I have 8 open at once and my Windows taskbar
is overflowing with items.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* er/ui:
Always bind the return key to the default button
Do not break git-gui messages into multiple lines.
Improve look-and-feel of the git-gui tool.
Teach git-gui to use the user-defined UI font everywhere.
Allow wish interpreter to be defined with TCLTK_PATH
* builtin-grep.c (strtoul_ui): Move function definition from here, to...
* git-compat-util.h (strtoul_ui): ...here, with an added "base" parameter.
* builtin-grep.c (cmd_grep): Update use of strtoul_ui to include base, "10".
* builtin-update-index.c (read_index_info): Diagnose an invalid mode integer
that is out of range or merely larger than INT_MAX.
(cmd_update_index): Use strtoul_ui, not sscanf.
* convert-objects.c (write_subdirectory): Likewise.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* git://git2.kernel.org/pub/scm/gitk/gitk:
[PATCH] Improve look-and-feel of the gitk tool.
[PATCH] Teach gitk to use the user-defined UI font everywhere.
Since "git ls-files" doesn't really pass down any details on what it
really wants done to the directory walking code, the directory walking
code doesn't really know whether the caller wants to know about gitlink
directories, or whether it wants to just know about ignored files.
So the directory walking code will return those gitlink directories unless
the caller has explicitly told it not to ("dir->show_other_directories"
tells the directory walker to only show "other" directories).
This kind of confuses "git ls-files -o", because
- it didn't really expect to see entries listed that were already in the
index, unless they were unmerged, and would die on that unexpected
setup, rather than just "continue".
- it didn't know how to match directory entries with the final "/"
This trivial change updates the "show_other_files()" function to handle
both of these issues gracefully. There really was no reason to die, when
the obviously correct thing for the function was to just ignore files it
already knew about (that's what "other" means here!).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-blame would overflow commit->buffer when annotating files with long paths.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes paths that explicitly unset 'diff' attribute not to
produce "textual" diffs from 'git-diff' family.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This defines the semantics of 'crlf' attribute as an example.
When a path has this attribute unset (i.e. '!crlf'), autocrlf
line-end conversion is not applied.
Eventually we would want to let users to build a pipeline of
processing to munge blob data to filesystem format (and in the
other direction) based on combination of attributes, and at that
point the mechanism in convert_to_{git,working_tree}() that
looks at 'crlf' attribute needs to be enhanced. Perhaps the
existing 'crlf' would become the first step in the input chain,
and the last step in the output chain.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the basic infrastructure to assign attributes to
paths, in a way similar to what the exclusion mechanism does
based on $GIT_DIR/info/exclude and .gitignore files.
An attribute is just a simple string that does not contain any
whitespace. They can be specified in $GIT_DIR/info/attributes
file, and .gitattributes file in each directory.
Each line in these files defines a pattern matching rule.
Similar to the exclusion mechanism, a later match overrides an
earlier match in the same file, and entries from .gitattributes
file in the same directory takes precedence over the ones from
parent directories. Lines in $GIT_DIR/info/attributes file are
used as the lowest precedence default rules.
A line is either a comment (an empty line, or a line that begins
with a '#'), or a rule, which is a whitespace separated list of
tokens. The first token on the line is a shell glob pattern.
The rest are names of attributes, each of which can optionally
be prefixed with '!'. Such a line means "if a path matches this
glob, this attribute is set (or unset -- if the attribute name
is prefixed with '!'). For glob matching, the same "if the
pattern does not have a slash in it, the basename of the path is
matched with fnmatch(3) against the pattern, otherwise, the path
is matched with the pattern with FNM_PATHNAME" rule as the
exclusion mechanism is used.
This does not define what an attribute means. Tying an
attribute to various effects it has on git operation for paths
that have it will be specified separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-quiltimport complaining yet still working
config.txt: Fix grammatical error in description of http.noEPSV
config.txt: Change pserver to server in description of gitcvs.*
config.txt: Document core.autocrlf
config.txt: Document gitcvs.allbinary
Do not default to --no-index when given two directories.
Use rev-list --reverse in git-rebase.sh
There were two bugs: "stop_here" doesn't exist, but the bug that causes
this code to trigger in the *first* place is the wrong use of "$dotest".
It should be ".dotest"
This is essentially the same bug introduced by 87ab7992, one was
fixed with 0d38ab25 but this was somehow left behind.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This series of three patches is a *replacement* for the patch series of
two patches (plus one-liner fixup) I sent yesterday.
It fixes the issue I noted with "git status" incorrectly
claiming that a non-checked out subproject wasn't clean - that
was just a total thinko in the code (we were checking the
filesystem mode against S_IFDIRLNK, which obviously cannot work,
since S_IFDIRLINK is a git-internal state, not a filesystem
state).
It then re-sends the two patches on top of that, with the fix
for checking out superprojects (we should *not* mess up any
existing subproject directories, certainly not remove them - if
we already have a directory in the place where we now want a
subproject, we should leave it well alone!)
The first one really is a fix, and it makes the commit
commentary about a remaining bug in the patch I sent out
yesterday go away.
This actually allows us to check out a supermodule after cloning, although
the submodules themselves will obviously not be checked out, and will just
be empty directories.
Checking out the submodules will be up to higher levels - we may not even
want to!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows us to pack superprojects and thus clone them (but not yet
check them out on the receiving side.. That's the next patch)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code to match up index entries with the filesystem was stupidly
broken. We shouldn't compare the filesystem stat() information with
S_IFDIRLNK, since that's purely a git-internal value, and not what the
filesystem uses (on the filesystem, it's just a regular directory).
Also, don't bother to make the stat() time comparisons etc for DIRLNK
entries in ce_match_stat_basic(), since we do an exact match for these
things, and the hints in the stat data simply doesn't matter.
This fixes "git status" with submodules that haven't been checked out in
the supermodule.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Adds documentation for gitcvs.{dbname,dbdriver,dbuser,dbpass}
Texts are mostly taken from git-cvsserver.txt whith some
adaptions so that they make more sense out of the context
of the original man page.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
These variables apply to the SSH access as well, so don't use
pserver here which might confuse users.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Text shamelessly stolen from the 1.5.1 release notes.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-diff -- a/ b/ always defaulted to --no-index, primarily
because the function is_in_index() was implemented quite
incorrectly.
Noticed by Patrick Maaß and Simon Schubert independently,
initial patch was provided by Patrick but I fixed it
differently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This actually allows us to check out a supermodule after cloning, although
the submodules will obviously not be checked out, and will just be an
empty subdirectory.
[ Side note: this also shows that we currently don't correctly handle
such subprojects that aren't checked out correctly yet. They should
always show up as not being modified, but failing to resolve the
gitlink HEAD does not properly trigger the "not modified" logic in all
places it needs to..
So more work to be done, but that's a separate issue, unrelated to
the action of checking out the superproject. ]
The bulk of this patch is simply because we need to check the type of the
index entry *before* we try to read the object it points to, and that
meant that the code needed some re-organization. So I moved some of the
code in common to both symlinks and files to be a trivial helper function.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows us to pack superprojects and thus clone them (but not yet
check them out on the receiving side - that's the next patch)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/cherry:
Documentation: --cherry-pick
git-log --cherry-pick A...B
Refactor patch-id filtering out of git-cherry and git-format-patch.
Add %m to '--pretty=format:'
handle_options did not count the number of used arguments
correctly. When --git-dir was used the extra argument was
not added to the number of handled arguments.
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier --subject-prefix patch forgot that format-patch is
not the only codepath that adds the "[PATCH]" prefix, and broke
everybody else in the log family.
Signed-off-by: Junio C Hamano <junkio@cox.net>
By default we are pretty quiet about the actual commands that
we are running. So we should continue to be quiet about the new
merge-subtree hardlink to merge-recursive. Technically this is not
a builtin, but it is close because subtree is actually builtin to
a non-builtin. So lets just make things easy and call it a builtin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When "show_other_directories" is set, that implies that we are looking
for untracked files, which obviously means that we should ignore
directories that are marked as gitlinks in the index.
This fixes "git status" in a superproject, that would otherwise always
report that subprojects were "Untracked files:"
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a note about the branches -> modules mapping to LIMITATIONS because
I really think it should be noted there and not just at the end of
the installation step-by-step HOWTO.
I used "git branches" there and changed "heads" to "branches" in
my section about database configuration. I'm reluctant to replace
all occourences of "head" with "branch" though because you always
have to say "git branch" because CVS also has the concept of
branches. You can say "head" though, because there is no such
concept in CVS. In all the existing occourences of head other than
the one I changed I think "head" flows better in the text.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I finally got around to looking at Alex' patch to teach update-index about
gitlinks too, so that "git commit -a" along with any other explicit
update-index scripts can work.
I don't think there was anything wrong with Alex' patch, but the code he
patched I felt was just so ugly that the added cases just pushed it over
the edge. Especially as I don't think that patch necessarily did the right
thing for a gitlink entry that already existed in the index, but that
wasn't actually a real git repository in the working tree (just an empty
subdirectory or a non-git snapshot because it hadn't wanted to track that
particular subproject).
So I ended up deciding to clean up the git-update-index handling the same
way I tackled the directory traversal used by git-add earlier: by
splitting the different cases up into multiple smaller functions, and just
making the code easier to read (and adding more comments about the
different cases).
So this replaces the old "process_file()" with a new "process_path()"
function that then just calls out to different helper functions depending
on what kind of path it is. Processing a nondirectory ends up being just
one of the simpler cases.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reworded the section about git-cvsserver needing to update the
database.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
CVS allows you to add a removed file (where the
removal is not yet committed) which will
cause the server to send the latest revision of the
file and to delete the "removed" status.
Copy this behaviour.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is meant to be a saner replacement for "git-cherry".
When used with "A...B", this filters out commits whose patch
text has the same patch-id as a commit on the other side. It
would probably most useful to use with --left-right.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This implements the patch-id computation and recording library,
patch-ids.c, and rewrites the get_patch_ids() function used in
cherry and format-patch to use it, so that they do not pollute
the object namespace. Earlier code threw non-objects into the
in-core object database, and hoped for not getting bitten by
SHA-1 collisions. While it may be practically Ok, it still was
an ugly hack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When used with '--boundary A...B', this shows the -/</> marker
you would get with --left-right option to 'git-log' family.
When symmetric diff is not used, everybody is shown to be on the
"right" branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This function used to call locate_object_entry_hash() _twice_ per added
object while only once should suffice. Let's reorganize that code a bit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a fairly complete list of tests for various aspects of pack
index versions 1 and 2.
Tests on index v2 include 32-bit and 64-bit offsets, as well as a nice
demonstration of the flawed repacking integrity checks that index
version 2 intend to solve over index version 1 with the per object CRC.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reliance on /dev/urandom produces test vectors that are, well, random.
This can cause problems impossible to track down when the data is
different from one test invokation to another.
The goal is not to have random data to test, but rather to have a
convenient way to create sets of large files with non compressible and
non deltifiable data in a reproducible way.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* builtin-grep.c (strtoul_ui): Move function definition from here, to...
* git-compat-util.h (strtoul_ui): ...here, with an added "base" parameter.
* builtin-grep.c (cmd_grep): Update use of strtoul_ui to include base, "10".
* builtin-update-index.c (read_index_info): Diagnose an invalid mode integer
that is out of range or merely larger than INT_MAX.
(cmd_update_index): Use strtoul_ui, not sscanf.
* convert-objects.c (write_subdirectory): Likewise.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is the promised cleaned-up version of teaching directory traversal
(ie the "read_directory()" logic) about subprojects. That makes "git add"
understand to add/update subprojects.
It now knows to look at the index file to see if a directory is marked as
a subproject, and use that as information as whether it should be recursed
into or not.
It also generally cleans up the handling of directory entries when
traversing the working tree, by splitting up the decision-making process
into small functions of their own, and adding a fair number of comments.
Finally, it teaches "add_file_to_cache()" that directory names can have
slashes at the end, since the directory traversal adds them to make the
difference between a file and a directory clear (it always did that, but
my previous too-ugly-to-apply subproject patch had a totally different
path for subproject directories and avoided the slash for that case).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add testcase for format-patch --subject-prefix support.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a new option to git-format-patch, entitled --subject-prefix that allows
control of the subject prefix '[PATCH]'. Using this option, the text 'PATCH' is
replaced with whatever input is provided to the option. This allows easily
generating patches like '[PATCH 2.6.21-rc3]' or properly numbered series like
'[-mm3 PATCH N/M]'. This patch provides the implementation and documentation.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
GIT 1.5.1.1
cvsserver: Fix handling of diappeared files on update
fsck: do not complain on detached HEAD.
(encode_85, decode_85): Mark source buffer pointer as "const".
This fixes a total thinko in my original series: subprojects do *not* sort
like directories, because the index is sorted purely by full pathname, and
since a subproject shows up in the index as a normal NUL-terminated
string, it never has the issues with sorting with the '/' at the end.
So if you have a subproject "proj" and a file "proj.c", the subproject
sorts alphabetically before the file in the index (and must thus also sort
that way in a tree object, since trees sort as the index).
In contrast, it you have two files "proj/file" and "proj.c", the "proj.c"
will sort alphabetically before "proj/file" in the index. The index
itself, of course, does not actually contain an entry "proj/", but in the
*tree* that gets written out, the tree entry "proj" will sort after the
file entry "proj.c", which is the only real magic sorting rule.
In other words: the magic sorting rule only affects tree entries, and
*only* affects tree entries that point to other trees (ie are of the type
S_IFDIR).
Anyway, that thinko just means that we should remove the special case to
make S_ISDIRLNK entries sort like S_ISDIR entries. They don't. They sort
like normal files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only send a modified response if the client sent a
"Modified" entry. This fixes the case where the
file was locally deleted on the client without
being removed from CVS. In this case the client
will only have sent the Entry for the file but nothing
else.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Martin Langhoff <martin@catalyst.net.nz>
Acked-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Detached HEAD is just a normal state of a repository. Do not
say anything about it.
Do not give worrying "error:" messages when we let the user know
that the HEAD points at nothing (i.e. yet to be born branch),
nor we do not have any default refs to start following the
objects chain. Reword them as "notice:".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduce new configuration variable $default_projects_order
that can be used to specify the default order of projects on
the index page if no 'o' parameter is given.
Allow a new value 'none' for order that will cause the projects
to be in the order we learned about them. In case of reading the
list of projects from a file, this should be the order as they are
listed in the file. In case of reading the list of projects from
a directory this will probably give random results depending on the
filesystem in use.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make it possible to use the forks feature even when
reading the list of projects from a file, by creating
a list of known prefixes as we go. Forks have to be
listed after the main project in order to be recognised
as such.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches the really fundamental core SHA1 object handling routines
about gitlinks. We can compare trees with gitlinks in them (although we
can not actually generate patches for them yet - just raw git diffs),
and they show up as commits in "git ls-tree".
We also know to compare gitlinks as if they were directories (ie the
normal "sort as trees" rules apply).
[jc: amended a cut&paste error]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since the subprojects don't necessarily even exist in the current tree,
much less in the current git repository (they are totally independent
repositories), we do not want to try to follow the chain from one git
repository to another through a gitlink.
This involves teaching fsck to ignore references to gitlink objects from
a tree and from the current index.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This just adds the basic helper functions to recognize and work with git
tree entries that are links to other git repositories ("subprojects").
They still aren't actually connected up to any of the code-paths, but
now all the infrastructure is in place.
The next commit will start actually adding actual subproject support.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This new function resolves a ref in *another* git repository. It's
named for its intended use: to look up the git link to a subproject.
It's not actually wired up to anything yet, but we're getting closer to
having fundamental plumbing support for "links" from one git directory
to another, which is the basis of subproject support.
[jc: amended a FILE* leak]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we are fetching from a repository that is on a local
filesystem, first check if we have all the objects that we are
going to fetch available locally, by not just checking the tips
of what we are fetching, but with a full reachability analysis
to our existing refs. In such a case, we do not have to run
git-fetch-pack which would send many needless objects. This is
especially true when the other repository is an alternate of the
current repository (e.g. perhaps the repository was created by
running "git clone -l -s" from there).
The useless objects transferred used to be discarded when they
were expanded by git-unpack-objects called from git-fetch-pack,
but recent git-fetch-pack prefers to keep the data it receives
from the other end without exploding them into loose objects,
resulting in a pack full of duplicated data when fetching from
your own alternate.
This also uses fetch--tool pick-rref on dumb transport side to
remove a shell loop to do the same.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This script helper takes list of fully qualified refnames and
results from ls-remote and grabs only the lines for the named
refs from the latter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have fairly extensive coverage of read-tree 3-way machinery,
and many Porcelain-ish tests use git-merge front-end tests, but
we did not have good basic test for merge-recursive, which made
it very hard to hack on it.
I used this during the recent work to teach D/F conflicts to
merge-recursive.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a path D that originally was blob in the ancestor was
modified on our branch while it was removed on the other branch,
we keep stages 1 and 2, and leave our version in the working
tree. If the other branch created a path D/F, however, that
path can cleanly be resolved in the index (after all, the
ancestor nor we do not have it and only the other side added),
but it cannot be checked out. The issue is the same when the
other branch had D and we had renamed it to D/F, or the ancestor
had D/F instead of D (so there are four combinations).
Do not stop the merge, but leave both D and D/F paths in the
index so that the user can clear things up.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When update-trees::threeway_merge() decides that a path that
exists in the current index (and HEAD) is to be removed, it
leaves a stage 0 entry whose mode bits are set to 0. The code
mistook it as "this stage wants the blob here", and proceeded
to call update_file_flags() which ended up trying to put the
mode=0 entry in the index, got very confused, and ended up
barfing with "do not know what to do with 000000".
Since threeway_merge() does not handle case #10 (one side
removes while the other side does not do anything), this is not
a problem while we refuse to merge branches that have D/F
conflicts, but when we start resolving them, we would need to be
able to remove cache entries, and at that point it starts to
matter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes three buglets in threeway_merge() regarding D/F
conflict entries.
* After finishing with path D and handling path D/F, some stages
have D/F conflict entry which are obviously non-NULL. For the
purpose of determining if the path D/F is missing in the
ancestor, they should not be taken into account.
* D/F conflict entry is a marker to say "this stage does _not_
have the path", so do not send them to keep_entry().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Case #10 is not handled with unpack-trees.c:threeway_merge()
internally, unless under the agressive rule, and it is not a
bug. As the test expects, ND (one side did not do anything,
other side deleted) case was meant to be handled by the caller's
policy (e.g. git-merge-one-file or git-merge-recursive).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some oneline descriptions are just too long. In shortlog, it looks much
nicer when they are wrapped. Since print_wrapped_text() is UTF-8 aware,
it also works with those descriptions.
[jc: with minimum fixes]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This replaces the inflate validation with a CRC validation when reusing
data from a pack which uses index version 2. That makes repacking much
safer against corruptions, and it should be a bit faster too.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is necessary for testing the new capabilities in some automated
way without having an actual 4GB+ pack.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Initially the conversion was made using nth_packed_object_sha1() which
made this file completely index version agnostic. Unfortunately the
overhead was quite significant so I went back to raw index walking but
with selectable base and step values which brought back similar
performances as the original.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When index v2 is encountered, the CRC32 of each object is also displayed
in parenthesis at the end of the line.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch, packs larger than 4GB are usable, even on a 32-bit machine
(at least on Linux). If off_t is not large enough to deal with a large
pack then die() is called instead of attempting to use the pack and
producing garbage.
This was tested with a 8GB pack specially created for the occasion on
a 32-bit machine.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Like previous patch but for index-pack.
[ There is quite some code duplication between pack-objects and index-pack
for generating a pack index (and fast-import as well I suppose). This
should be reworked into a common function eventually. But not now. ]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Pack index version 2 goes as follows:
- 8 bytes of header with signature and version.
- 256 entries of 4-byte first-level fan-out table.
- Table of sorted 20-byte SHA1 records for each object in pack.
- Table of 4-byte CRC32 entries for raw pack object data.
- Table of 4-byte offset entries for objects in the pack if offset is
representable with 31 bits or less, otherwise it is an index in the next
table with top bit set.
- Table of 8-byte offset entries indexed from previous table for offsets
which are 32 bits or more (optional).
- 20-byte SHA1 checksum of sorted object names.
- 20-byte SHA1 checksum of the above.
The object SHA1 table is all contiguous so future pack format that would
contain this table directly won't require big changes to the code. It is
also tighter for slightly better cache locality when looking up entries.
Support for large packs exceeding 31 bits in size won't impose an index
size bloat for packs within that range that don't need a 64-bit offset.
And because newer objects which are likely to be the most frequently used
are located at the beginning of the pack, they won't pay the 64-bit offset
lookup at run time either even if the pack is large.
Right now an index version 2 is created only when the biggest offset in a
pack reaches 31 bits. It might be a good idea to always use index version
2 eventually to benefit from the CRC32 it contains when reusing pack data
while repacking.
[jc: with the "oops" fix to keep track of the last offset correctly]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The most important optimization for performance when repacking is the
ability to reuse data from a previous pack as is and bypass any delta
or even SHA1 computation by simply copying the raw data from one pack
to another directly.
The problem with this is that any data corruption within a copied object
would go unnoticed and the new (repacked) pack would be self-consistent
with its own checksum despite containing a corrupted object. This is a
real issue that already happened at least once in the past.
In some attempt to prevent this, we validate the copied data by inflating
it and making sure no error is signaled by zlib. But this is still not
perfect as a significant portion of a pack content is made of object
headers and references to delta base objects which are not deflated and
therefore not validated when repacking actually making the pack data reuse
still not as safe as it could be.
Of course a full SHA1 validation could be performed, but that implies
full data inflating and delta replaying which is extremely costly, which
cost the data reuse optimization was designed to avoid in the first place.
So the best solution to this is simply to store a CRC32 of the raw pack
data for each object in the pack index. This way any object in a pack can
be validated before being copied as is in another pack, including header
and any other non deflated data.
Why CRC32 instead of a faster checksum like Adler32? Quoting Wikipedia:
Jonathan Stone discovered in 2001 that Adler-32 has a weakness for very
short messages. He wrote "Briefly, the problem is that, for very short
packets, Adler32 is guaranteed to give poor coverage of the available
bits. Don't take my word for it, ask Mark Adler. :-)" The problem is
that sum A does not wrap for short messages. The maximum value of A for
a 128-byte message is 32640, which is below the value 65521 used by the
modulo operation. An extended explanation can be found in RFC 3309,
which mandates the use of CRC32 instead of Adler-32 for SCTP, the
Stream Control Transmission Protocol.
In the context of a GIT pack, we have lots of small objects, especially
deltas, which are likely to be quite small and in a size range for which
Adler32 is dimed not to be sufficient. Another advantage of CRC32 is the
possibility for recovery from certain types of small corruptions like
single bit errors which are the most probable type of corruptions.
OK what this patch does is to compute the CRC32 of each object written to
a pack within pack-objects. It is not written to the index yet and it is
obviously not validated when reusing pack data yet either.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change a few size and offset variables to more appropriate type, then
add overflow tests on those offsets. This prevents any bad data to be
generated/processed if off_t happens to not be large enough to handle
some big packs.
Better be safe than sorry.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch introduces the MSB() macro to obtain the desired number of
most significant bits from a given variable independently of the variable
type.
It is then used to better implement the overflow test on the OBJ_OFS_DELTA
base offset variable with the property of always working correctly
regardless of the type/size of that variable.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The coming index format change doesn't allow for the number of objects
to be determined from the size of the index file directly. Instead, Let's
initialize a field in the packed_git structure with the object count when
the index is validated since the count is always known at that point.
While at it let's reorder some struct packed_git fields to avoid padding
due to needed 64-bit alignment for some of them.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This just makes sure that when we do a read_directory(), we check
that the filename fits in the buffer we allocated (with a bit of
slop)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The diff helpers used to do the magic mode canonicalization and all the
other special mode handling by hand ("trust executable bit" and "has
symlink support" handling).
That's bogus. Use "ce_mode_from_stat()" that does this all for us.
This is also going to be required when we add support for links to other
git repositories.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use the comment in the code to document the --exclude-existing
function to git-show-ref.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unlike 'patch --fuzz=NUM', which specifies the number of lines allowed
to mismatch, 'git-apply -CNUM' requests the match of NUM lines of
context. Omitting -C requests full context match, and that's what
should be used for cvsexportcommit -p.
Signed-off-by: Junio C Hamano <junkio@cox.net>
As noted by Junio, --format=tar should be assumed if no format
was specified.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/merge-subtree:
A new merge stragety 'subtree'.
It is safe to merge this early as this is a feature that user
explicitly needs to ask for and would not trigger otherwise. A
known issue with the current implementation is that the subtree
matching heuristics is very stupid. It could run ls-tree twice
and try to count intersection.
Giving it wider audience would help it to get improved by
motivated volunteers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Add Documentation/cmd-list.made to .gitignore
git-svn: fix log command to avoid infinite loop on long commit messages
git-svn: dcommit/rebase confused by patches with git-svn-id: lines
git-svn: bail out on incorrect command-line options
This bug has been around since the the conversion to use the
Git.pm library back in October or November. Eventually I'd like
"git rev-list/log" to have the option to not truncate overly
long messages.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When patches are merged from another git-svn managed branch,
they will have the git-svn-id: metadata line in them (generated
by git-format-patch).
When doing rebase or dcommit via git-svn, this would cause
git-svn to find the wrong upstream branch. We now verify
that the commit is consistent with the value in the .rev_db
file.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git svn log" is the only command that needs the pass-through
option in Getopt::Long; otherwise we will bail out and let the
user know something is wrong.
Also, avoid printing out unaccepted mixed-case options (that
are reserved for the command-line) such as --useSvmProps
in the usage() function.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documents the new configuration variables and the variable
substitution mechanism.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'jc/read-tree-df' (early part):
Fix switching to a branch with D/F when current branch has file D.
Fix twoway_merge that passed d/f conflict marker to merged_entry().
Fix read-tree --prefix=dir/.
unpack-trees: get rid of *indpos parameter.
unpack_trees.c: pass unpack_trees_options structure to keep_entry() as well.
add_cache_entry(): removal of file foo does not conflict with foo/bar
Don't include the scheme name in gitcvs.dbdriver, it is
always 'dbi' anyway.
Don't allow ':' in driver names nor ';' in database names for
sanity reasons.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix a typo: s/Not/Note/
Some formating fixes: Use ` ` syntax for all filenames and
' ' syntax for all commandline switches.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This merge strategy largely piggy-backs on git-merge-recursive.
When merging trees A and B, if B corresponds to a subtree of A,
B is first adjusted to match the tree structure of A, instead of
reading the trees at the same level. This adjustment is also
done to the common ancestor tree.
If you are pulling updates from git-gui repository into git.git
repository, the root level of the former corresponds to git-gui/
subdirectory of the latter. The tree object of git-gui's toplevel
is wrapped in a fake tree object, whose sole entry has name 'git-gui'
and records object name of the true tree, before being used by
the 3-way merge code.
If you are merging the other way, only the git-gui/ subtree of
git.git is extracted and merged into git-gui's toplevel.
The detection of corresponding subtree is done by comparing the
pathnames and types in the toplevel of the tree.
Heuristics galore! That's the git way ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
When pushing into multiple repositories with git push, via
multiple URL in .git/remotes/$shorthand or multiple url
variables in [remote "$shorthand"] section, we used to stop upon
the first failure. Continue the operation and report the
failure at the end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This came up on #git when somebody was getting 'unable to create
./objects/tmp_oXXXX' but sweared he had write permission to that
directory. It turned out that the repository URL was changed
and he was accessing a repository he does not have a write
permission anymore.
I am not sure how much this would have helped somebody who
believed he was accessing location when the permission of that
location was changed while he was looking the other way, though.
But giving more information on the error path would be better,
and the next change would be helped with this as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/index-output:
git-read-tree --index-output=<file>
_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.
Conflicts:
builtin-apply.c
* cc/bisect:
git-bisect: allow bisecting with only one bad commit.
t6030: add a bit more tests to git-bisect
git-bisect: modernization
Documentation: bisect: "start" accepts one bad and many good commits
Bisect: teach "bisect start" to optionally use one bad and many good revs.
* maint:
Documentation: tighten dependency for git.{html,txt}
Makefile: iconv() on Darwin has the old interface
t5300-pack-object.sh: portability issue using /usr/bin/stat
t3200-branch.sh: small language nit
usermanual.txt: some capitalization nits
Make builtin-branch.c handle the git config file
rename_ref(): only print a warning when config-file update fails
Distinguish branches by more than case in tests.
Avoid composing too long "References" header.
cvsimport: Improve formating consistency
cvsimport: Reorder options in documentation for better understanding
cvsimport: Improve usage error reporting
cvsimport: Improve documentation of CVSROOT and CVS module determination
cvsimport: sync usage lines with existing options
Conflicts:
Documentation/Makefile
Every time _any_ documentation page changed, cmds-*.txt files
were regenerated, which caused git.{html,txt} to be remade. Try
not to update cmds-*.txt files if their new contents match the
old ones.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The libiconv on Darwin uses the old iconv() interface (2nd argument is a
const char **, instead of a char **). Add OLD_ICONV to the Darwin
variable definitions to handle this.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Acked-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In the test 'compare delta flavors', /usr/bin/stat is used to get file size.
This isn't portable. There already is a dependency on Perl, use its '-s'
operator to get the file size.
Signed-off-by: Arjen Laarhoven <arjen@yaph.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to say:
git bisect start
git bisect bad $bad
git bisect next
to start bisection without knowing a good commit. This would
have you try a commit that is half-way since the beginning of
the history, which is rather wasteful if you already know a good
commit, but if you don't (or your history is short enough that
you do not care), there is no reason not to allow this.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the knowledge about .git/config usage out of refs.c and into
builtin-branch.c instead, which allows git-branch to update HEAD to point
at the moved branch before attempting to update the config file. It also
allows git-branch to exit with an error code if updating the config file
should fail.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If git_config_rename_section() fails, rename_ref() used to return 1, which
left HEAD pointing to an absent refs/heads file (since the actual renaming
had already occurred).
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The renaming without config test changed a branch from q to Q, which
fails on non-case sensitive file systems. Change the test to use q
and q2.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The number of characters in a line MUST be no more than 998 characters,
and SHOULD be no more than 78 characters (RFC2822).
It is much safer to fold the header by ourselves.
Signed-off-by: YOSHIFUJI Hideaki <yoshfuji@linux-ipv6.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use ' ' syntax for all commandline options mentioned in text.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The current order the options are documented in makes no sense
at all to me. Reorder them so that similar options are grouped
together and also order them somehwhat by importance.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Actually tell the user what he did wrong in case of usage errors
instead of only printing the general usage information.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document the fact that git-cvsimport tries to find out CVSROOT from
CVS/Root and $ENV{CVSROOT} and CVS_module from CVS/Repository.
Also use ` ` syntax for all filenames for consistency.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sync both the usage lines in the code and the asciidoc
documentation with the real list of options. While
all options seems to be documented in the asciidoc
document, not all of them were listed in the usage line.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This slightly modernizes the bisect script to use show-ref/for-each-ref
instead of looking into $GIT_DIR/refs files directly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Fix lseek(2) calls with args 2 and 3 swapped
Honor -p<n> when applying git diffs
Fix dependency of common-cmds.h
Fix renaming branch without config file
DESTDIR support for git/contrib/emacs
gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches
Document --left-right option to rev-list.
Revert "builtin-archive: use RUN_SETUP"
rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.
rerere: make sorting really stable.
Fix t4200-rerere for white-space from "wc -l"
One bad commit is fundamentally needed for bisect to run,
and if we beforehand know more good commits, we can narrow
the bisect space down without doing the whole tree checkout
every time we give good commits.
This patch implements:
git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
as a short-hand for this command sequence:
git bisect start
git bisect bad $bad
git bisect good $good1 $good2...
On the other hand, there may be some confusion between revs
(<bad> and <good>...) and <pathspec>... if -- is not used
and if an invalid rev or a pathspec that looks like a rev is
given.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
GNU make does not include environment variables by default
in its namespace. Just pass them in make command line.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This function was not called "add_file_to_cache()" only because
an ancient program, update-cache, used that name as an internal
function name that does something slightly different. Now that
is gone, we can take over the better name.
The plan is to name all functions that operate on the default
index xxx_cache(). Later patches create a variant of them that
take an explicit parameter xxx_index(), and then turn
xxx_cache() functions into macros that use "the_index".
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is an internal variable used to tell if we need to write
out the resulting index.
I'll be introducing write_index() function which would collide
with it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'd like to consistently name all index-layer functions that
operate on the default index xxx_cache(), and this application
specific function interferes with the plan.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function refresh_cache() is the only user of cache_errno
that switches its behaviour based on what internal function
refresh_cache_entry() finds; pass the error status back in a
parameter passed down to it, to get rid of the global variable
cache_errno.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This error message should not usually trigger, but the function
make_cache_entry() called by add_cacheinfo() can return early
without calling into refresh_cache_entry() that sets cache_errno.
Also the error message had a wrong function name reported, and
it did not say anything about which path failed either.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously, a binary file in the diffstat would show as:
some-binary-file.bin | Bin
The space after the "Bin" was never used. This patch changes binary
lines in the diffstat to be:
some-binary-file.bin | Bin 12345 -> 123456 bytes
The very nice "->" notation was suggested by Johannes Schindelin, and
shows the before and after sizes more clearly than "+" and "-" would.
If a size is 0 it's not shown (although it would probably be better to
treat no-file differently from zero-byte-file).
The user can see what changed in the binary file, and how big the new
file is. This is in keeping with the information in the rest of the
diffstat.
The diffstat_t members "added" and "deleted" were unused when the file
was binary, so this patch loads them with the file sizes in
builtin_diffstat(). These figures are then read in show_stats() when
the file is marked binary.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user is trying to apply a Git generated diff file and they
have specified a -p<n> option, where <n> is not 1, the user probably
has a good reason for doing this. Such as they are me, trying to
apply a patch generated in git.git for the git-gui subdirectory to
the git-gui.git repository, where there is no git-gui subdirectory
present.
Users shouldn't supply -p2 unless they mean it. But if they are
supplying it, they probably have thought about how to make this
patch apply to their working directory, and want to risk whatever
results may come from that.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Prior to 1.5.0 the git-lost-found utility was useful to locate
commits that were not referenced by any ref. These were often
amends, or resets, or tips of branches that had been deleted.
Being able to locate a 'lost' commit and recover it by creating a
new branch was a useful feature in those days.
Unfortunately 1.5.0 added the reflogs to the reachability analysis
performed by git-fsck, which means that most commits users would
consider to be lost are still reachable through a reflog. So most
(or all!) commits are reachable, and nothing gets output from
git-lost-found.
Now git-fsck can be told to ignore reflogs during its reachability
analysis, making git-lost-found useful again to locate commits
that are no longer referenced by a ref itself, but may still be
referenced by a reflog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let's avoid the open coded pack index reference in pack-object and use
nth_packed_object_sha1() instead. This will help encapsulating index
format differences in one place.
And while at it there is no reason to copy SHA1's over and over while a
direct pointer to it in the index will do just fine.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make git_config_rename_section return success if no config file
exists. Otherwise, renaming a branch would abort, leaving the
repository in an inconsistent state.
[jc: test]
Signed-off-by: Geert Bosch <bosch@gnat.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git_patchset_body needs patch generated with --full-index option to
detect split patches, meaning two patches which corresponds to single
difftree (raw diff) entry. An example of such situation is changing
type (mode) of a file, e.g. from plain file to symbolic link.
Add, in git_blobdiff, --full-index option to patch generating git diff
invocation, for the 'html' format output ("blobdiff" view).
"blobdiff_plain" still uses shortened sha1 in the extended git diff
header "index <hash>..<hash>[ <mode>]" line.
Noticed-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 64edf4b2 cleaned up the initialization of git-archive,
at the cost of 'git-archive --list' now requiring a git repo.
This patch reverts the cleanup and documents the requirement
for this particular dirtyness in a test.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier code does not swap hunks when the beginning of the
first side is identical to the whole of the second side. In
such a case, the first one should sort later.
Signed-off-by: Junio C Hamano <junkio@cox.net>
On OS X, wc outputs 6 spaces before the number of lines, so the test
expecting the string "10" failed. Do not quote $cmd to strip away
the problematic whitespace as other tests do.
Also fix the grammar of the test name while making changes to it.
There's only one preimage, so it's "has", not "have".
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we generate a blame status string before we have obtained
any annotation data at all from the input file, or if the input
file is empty, our total_lines will be 0. This causes a division
by 0 error when we blindly divide by the 0 to compute the total
percentage of lines loaded. Instead we should report 0% done.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a dialog/window has a default button registered not every
platform associates the return key with that button, but all
users do. We have to register the binding of the return key
ourselves to make sure the user's expectations of pressing
return will activate the default button are met.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Many git-gui messages were broken into a multiple lines to make
good paragraph width. Unfortunately in reality it breaks the paragraph
width completely, because the dialog window width does not coincide
with the paragraph width created by the current font.
Tcl/Tk's standard dialog boxes are breaking the long lines
automatically, so it is better to make long lines and let the
interpreter do the job.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Made the default buttons on the dialog active and focused upon the
dialog appearence.
Bound 'Escape' and 'Return' keys to the dialog dismissal where it
was appropriate: mainly for dialogs with only one button and no
editable fields, but on console output dialogs as well.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some parts of git-gui were not respecting the default GUI font.
Most of them were catched and fixed.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Makefile got one external option:
- TCLTK_PATH: the path to the Tcl/Tk interpreter.
Users (or build wrappers) may set this variable to the
location of the wish executable.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"git svn log" is the only command that needs the pass-through
option in Getopt::Long; otherwise we will bail out and let the
user know something is wrong.
Also, avoid printing out unaccepted mixed-case options (that
are reserved for the command-line) such as --useSvmProps
in the usage() function.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ensure that in all references to an element of a hash, the
key is singlequoted, instead of using bareword: use $hash{'key'}
instead of $hash{key}
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Code should be look the same way, regardless of tab size.
Use tabs for indent, but spaces for align.
Indent continued part of command spanning multiple lines, but only once.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This loosens the over-eager verify_absent() check that gets
upset to find directory D in the current working tree when
switching to a branch that has a file there. The check needs to
make sure that we do not lose precious working tree files as a
result of removing directory D and replacing it with the file
from the other branch, which is a tad expensive but this is a
less common case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching from one tree to another, we should not send a
marker that says "this file does not exist in the new tree -- I
am a placeholder to tell you that, and not a real blob" down to
merged_entry() as the result of the merge.
The existing code is not wrong per-se, but it started scanning the index
from a location that does not match the tree being read, and wasted
cycles.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This variable keeps track of which entry in the original index
the traversal is looking at, and belongs to the unpack_trees_options
structure along with other traversal status information.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Other decision functions, deleted_entry() and merged_entry() take one as
their parameter, and this function should. I'll be introducing a separate
index to build the result in, and am planning to pass it as the part of the
structure.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/bisect:
make the previous optimization work also on path-limited rev-list --bisect
rev-list --bisect: Fix "halfway" optimization.
t6004: add a bit more path optimization test.
git-rev-list --bisect: optimization
git-rev-list: add --bisect-vars option.
t6002: minor spelling fix.
* fl/doc:
Documentation: unbreak user-manual.
Documentation: Add version information to man pages
Documentation: Replace @@GIT_VERSION@@ in documentation
* post1.5.1/p4:
Added correct Python path to the RPM specfile.
Remove unused WITH_OWN_SUBPROCESS_PY from RPM spec
Added git-p4 package to the list of git RPMs.
Add the WITH_P4IMPORT knob to the Makefile.
This corrects the interface mistake of the previous one, and
gives a command line parameter to the only plumbing command that
currently needs it: "git-read-tree".
We can add the calls to set_alternate_index_output() to other
plumbing commands that update the index if/when needed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When defined, this allows plumbing commands that update the
index (add, apply, checkout-index, merge-recursive, mv,
read-tree, rm, update-index, and write-tree) to write their
resulting index to an alternative index file while holding a
lock to the original index file. With this, git-commit that
jumps the index does not have to make an extra copy of the index
file, and more importantly, it can do the update while holding
the lock on the index.
However, I think the interface to let an environment variable
specify the output is a mistake, as shown in the documentation.
If a curious user has the environment variable set to something
other than the file GIT_INDEX_FILE points at, almost everything
will break. This should instead be a command line parameter to
tell these plumbing commands to write the result in the named
file, to prevent stupid mistakes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
You cannot currently checkout the tip of an existing branch
without moving to the branch.
This allows you to detach your HEAD and place it at such a
commit, with:
$ git checkout master^0
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not that this release really matters, as we will be doing
1.5.1 tomorrow. This commit is to tie the loose ends and
merge all of "maint" branch into "master" in preparation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mainly consistent usage of "git command" and not "git-command" syntax
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Acked-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a file has more then one conflicting hunks, it repeated the
contents of previous hunks in output for later ones.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not make the checks on the Tcl/Tk interpreter passed by
'--with-tcltk=/path/to/wish' configure option: user is free to pass
anything.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
--with-tcltk=/path/to/wish sets the TCLTK_PATH variable that is
used to substitute the location of the wish interpreter in the
Tcl/Tk programs.
New tracking file, GIT-GUI-VARS, was introduced: it tracks the
location of the Tcl/Tk interpreter and activates the GUI tools
rebuild if the interpreter path was changed. The separate tracker
is better than the GIT-CFLAGS: there is no need to rebuild the whole
git if the interpreter path was changed.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
--with-tcltk enables the search of the Tcl/Tk interpreter. If no
interpreter is found then Tcl/Tk dependend parts are disabled.
--without-tcltk unconditionally disables Tcl/Tk dependent parts.
The original behaviour is not changed: bare './configure' just
installs the Tcl/Tk part doing no checks for the interpreter.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Makefile knob named NO_TCLTK was introduced. It prevents the build
and installation of the Tcl/Tk dependent parts.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
We don't have a copy of subprocess.py anymore, so we removed that
option from the Makefile. Let's not leave that cruft around the RPM
spec file either.
Signed-off-by: Junio C Hamano <junkio@cox.net>
WITH_P4IMPORT: enables the installation of the Perforce import
script.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I thought it would be cool to have different set of colors for each
git-blame-mode. Function `git-blame-new-commit' does this for us
picking when possible, a random colors based on the set we build on
startup. When it fails, `git-blame-ancient-color' will be used. We
also take care not to use the same color more than once (thank you
David Kågedal, really).
* Prevent (future possible) namespace clash by renaming `color-scale'
into `git-blame-color-scale'. Definition has been changed to be more
in the "lisp" way (thanks for help to #emacs). Also added a small
description of what it does.
* Added docstrings at some point and instructed defvar when a variable
was candidate to customisation by users.
* Added missing defvar to silent byte-compilers (git-blame-file,
git-blame-current)
* Do not require 'cl at startup
* Added more informations on compatibility
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Acked-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-blame-mode has been splitted into git-blame-mode-on and
git-blame-mode-off; it now conditionnaly calls one of them depending
of how we call it. Code is now easier to maintain and to understand.
Fixed `git-reblame' function: interactive form was at the wrong
place.
String displayed on the mode line is now configurable through
`git-blame-mode-line-string` (default to " blame").
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Made the default buttons on the dialog active and focused upon the
dialog appearence.
Bound 'Escape' and 'Return' keys to the dialog dismissal where it
was appropriate: mainly for dialogs with only one button and no
editable fields.
Unified the look of the "About gitk" and "Key bindings" dialogs.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Some parts of gitk were not respecting the default GUI font. Most
of them were catched and fixed.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Paul Mackerras <paulus@samba.org>
The way things are set up, you can now pass a "pathspec" to the
"read_directory()" function. If you pass NULL, it acts exactly
like it used to do (read everything). If you pass a non-NULL
pointer, it will simplify it into a "these are the prefixes
without any special characters", and stop any readdir() early if
the path in question doesn't match any of the prefixes.
NOTE! This does *not* obviate the need for the caller to do the *exact*
pathspec match later. It's a first-level filter on "read_directory()", but
it does not do the full pathspec thing. Maybe it should. But in the
meantime, builtin-add.c really does need to do first
read_directory(dir, .., pathspec);
if (pathspec)
prune_directory(dir, pathspec, baselen);
ie the "prune_directory()" part will do the *exact* pathspec pruning,
while the "read_directory()" will use the pathspec just to do some quick
high-level pruning of the directories it will recurse into.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
DBI->table_info is portable across different DBD backends,
DBI->tables is not.
Limit the output to objects of type TABLE.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
The git-cvsserver documentation claims that the server will set
-k modes if appropriate which is not really the case. On the other
hand the available gitcvs.allbinary variable is not documented at
all. Fix both these issues by rewording the related paragraph.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we're on an invalid HEAD, we should detect this and avoid
attempting to continue.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch leaves the base name in the resulting intermediate tree, to
propagate the conflict from intermediate merges up to the top-level merge.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a simple script to create a working directory that uses symlinks
to point at an exisiting repository. This allows having different
branches in different working directories but all from the same
repository.
Based on a description from Junio of how he creates multiple working
directories[1]. With the following caveat:
"This risks confusion for an uninitiated if you update a ref that
is checked out in another working tree, but modulo that caveat
it works reasonably well."
[1] http://article.gmane.org/gmane.comp.version-control.git/41513/
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The update hook is no longer the correct place to generate emails; there
is now the hooks/post-receive script which is run automatically after a
ref has been updated.
This patch is to make use of that new location, and to address some
faults in the old update hook.
The primary problem in the conversion was that in the update hook, the
ref has not actually been changed, but is about to be. In the
post-receive hook the ref has already been updated. That meant that
where we previously had lines like:
git rev-list --not --all
would now give the wrong list because "--all" in the post-receive hook
includes the ref that we are making the email for. This made it more
difficult to show only the new revisions added by this update.
The solution is not pretty; however it does work and doesn't need any
changes to git-rev-list itself. It also fixes (more accurately: reduces
the likelihood of) a nasty race when another update occurs while this
script is running. The solution, in short, looks like this (see the
source code for a longer explanation)
git rev-parse --not --all | grep -v $(git rev-parse $refname) |
git rev-list --pretty --stdin $oldrev..$newrev
This uses git-rev-parse followed by grep to filter out the revision of
the ref in question before it gets to rev-list and inhibits the output
of itself. By using $(git rev-parse $revname) rather than $newrev as the
filter, it also takes care of the situation where another update to the
same ref has been made since $refname was $newrev.
The second problem that is addressed is that of tags inhibiting the
correct output of an update email. Consider this, with somebranch and
sometag pointing at the same revision:
git push origin somebranch
git push origin sometag
That would work fine; the push of the branch would generate an email
containing all the new commits introduced by the update, then the push
of the tag would generate the shortlog formatted tag email. Now
consider:
git push origin sometag
git push origin somebranch
When some branch comes to run its "--not --all" line, it will find
sometag, and filter those commits from the email - leaving nothing.
That meant that those commits would not show (in full) on any email.
The fix is to not use "--all", and instead use "--branches" in the
git-rev-parse command.
Other changes
* Lose the monstrous one-giant-script layout and put things in easy to
digest functions. This makes it much easier to find the place you
need to change if you wanted to customise the output. I've also
tried to write more verbose comments for the same reason. The hook
script is big, mainly because of all the different cases that it has
to handle, so being easy to navigate is important.
* All uses of "git-command" changed to "git command", to cope better
if a user decided not to install all the hard links to git;
* Cleaned up some of the English in the email
* The fact that the receive hook makes the ref available also allows me
to use Shawn Pearce's fantastic suggestion that an annotated tag can
be parsed with git-for-each-ref. This removes the potentially
non-portable use of "<<<" heredocs and the nasty messing around with
"date" to convert numbers of seconds UTC to a real date
* Deletions are now caught and notified (briefly)
* To help with debugging, I've retained the command line mode from the
update hook; but made it so that the output is not emailed, it's just
printed to the screen. This could then be redirected if the user
wanted
* Removed the "Hello" from the beginning of the email - it's just
noise, and no one seriously has their day made happier by "friendly"
programs
* The fact that it doesn't rely on repository state as an indicator any
more means that it's far more stable in its output; hopefully the
same arguments will always generate the same email - even if the
repository changes in the future. This means you can easily recreate
an email should you want to.
* Included Jim Meyering's envelope sender option for the sendmail call
* The hook is now so big that it was inappropriate to copy it
to every repository by keeping it in the templates directory.
Instead, I've put a comment saying to look in contrib/hooks, and
given an example of calling the script from that template hook. The
advantage of calling the script residing at some fixed location is
that if a future package of git included a bug fixed version of the
script, that would be picked up automatically, and the user would not
have to notice and manually copy the new hook to every repository
that uses it.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We ignore errors if the path we're tracking did not exist for
a particular revision range, but we still print out warnings
telling the user about that.
As pointed out by Seth Falcon, this amounts to a lot of warnings
that could confuse and worry users. I'm not entirely comfortable
completely silencing the warnings, but showing one warning per
path that we track should be reasonable.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes a problem reported by Randal Schwartz:
>I finally tracked down all the (albeit inconsequential) errors I was getting
>on both OpenBSD and OSX. It's the warn() function in usage.c. There's
>warn(3) in BSD-style distros. It'd take a "great rename" to change it, but if
>someone with better C skills than I have could do that, my linker and I would
>appreciate it.
It was annoying to me, too, when I was doing some mergetool testing on
Mac OS X, so here's a fix.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Cc: "Randal L. Schwartz" <merlyn@stonehenge.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't translate the patch to UTF-8, instead preserve the data as
is. This also reverts a test case that was included in the
original patch series.
Also allow overwriting the authorship and title information we
gather from RFC2822 mail headers with additional in-body
headers, which was pointed out by Linus.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix the bug that caused "blobdiff" view called with new style URI
for a rename with change diff to be show as new (added) file diff.
New style URI for "blobdiff" for rename means with $hash_base ('hb') and
$hash_parent_base ('hpb') paramaters denoting tree-ish (usually commit)
of a blobs being compared, together with both $file_name ('f') and
$file_parent ('fp') parameters.
It is done by adding $file_parent ('fp') to the path limiter, meaning
that diff command becomes:
git diff-tree [options] hpb hb -- fp f
Other option would be finding hash of a blob using git_get_hash_by_path
subroutine and comparing blobs using git-diff, or using extended SHA-1
syntax and compare blobs using git-diff:
git diff [options] hpb:fp hp:f
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-upload-pack: make sure we close unused pipe ends
Documentation/git-rev-parse.txt: fix example in SPECIFYING RANGES.
Documentation/git-svnimport.txt: fix typo.
Bryan Wu reported
/usr/local/bin/git-quiltimport: 114: Syntax error: Missing '))'
Most bourne-ish shells I have here accept
x=$((echo x)|cat)
but all bourne-ish shells I have here accept
x=$( (echo x)|cat)
because $(( might mean arithmetic expansion.
Signed-off-by: Francis Daly <francis@daoine.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
So we can remove the specific message in "bisect_run".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/mergetool.git:
mergetool: Clean up description of files and prompts for merge resolutions
mergetool: Make git-rm quiet when resolving a deleted file conflict
mergetool: Add support for Apple Mac OS X's opendiff command
mergetool: Fix abort command when resolving symlinks and deleted files
mergetool: Remove spurious error message if merge.tool config option not set
mergetool: factor out common code
mergetool: portability fix: don't use reserved word function
mergetool: portability fix: don't assume true is in /bin
mergetool: Don't error out in the merge case where the local file is deleted
mergetool: Replace use of "echo -n" with printf(1) to be more portable
Fix minor formatting issue in man page for git-mergetool
This fixes complaints from Junio for how messages and prompts are
printed when resolving symlink and deleted file merges.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Create common function check_unchanged(), save_backup() and
remove_backup().
Also fix some minor whitespace issues while we're at it.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
If the file we are trying to merge resolve is in git-ls-files -u, then
skip the file existence test. If the file isn't reported in
git-ls-files, then check to see if the file exists or not to give an
appropriate error message.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Right now, we don't close the read end of the pipe when git-upload-pack
runs git-pack-object, so we hang forever (why don't we get SIGALRM?)
instead of dying with SIGPIPE if the latter dies, which seems to be the
norm if the client disconnects.
Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
pointing out where this close() needed to go.
This patch has been tested on kernel.org for several weeks and appear
to resolve the problem of git-upload-pack processes hanging around
forever.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from commit 465b3518a9)
Please see http://bugs.debian.org/404795:
In git-rev-parse(1), there is an example commit tree, which is used twice.
The explanation for this tree is very clear: B and C are commit *parents* to
A.
However, when the tree is reused as an example in the SPECIFYING RANGES, the
manpage author screws up and uses A as a commit *parent* to B and C! I.e.,
he inverts the tree.
And the fact that for this example you need to read the tree backwards is
not explained anywhere (and it would be confusing even if it was).
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was noticed by Frederik Schwarzer. SVN's repository by default has
trunk, tags/, and branch_es_/.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The previous one broke generated xml files for anything but manpages,
as it took the header for manpage unconditionally. This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Override the [header] macro of asciidoc's docbook
backend to add version information to the generated
man pages.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Include GIT-VERSION-FILE and replace @@GIT_VERSION@@ in
the HTML and XML asciidoc output. The documentation
doesn't depend on GIT-VERSION-FILE so it will not be
automatically rebuild if nothing else changed.
[jc: fixing the case for interrupted build]
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function replace_encoding_header is given the whole
commit buffer, including the commit message. When looking
for the encoding header, if none was found in the header, it
would locate any line in the commit message matching
"\nencoding " and remove it.
Instead, we now make sure to search only to the end of the
header.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Elias Pipping:
> I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes
> t4118 fail.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ack'd-by: Elias Pipping <pipping@macports.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It printed the header "encoding " instead of just showing
the encoding, as all other items do.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There are two breakages in the %P/%p interpolation. It appended
an excess SP at the end of the list, and it gave uninitialized
contents of a buffer on the stack for root commits.
This fixes it, while updating the t6006 test which expected the
wrong output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Please see http://bugs.debian.org/409887
http-fetch expected the URL given at the command line to have a trailing
slash anyway, and then added '/objects...' when requesting objects files
from the http server.
Now it doesn't require the trailing slash in <url> anymore, and strips
trailing slashes if given nonetheless.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It still looks at the working tree and checks for locally
modified paths. When are preparing a temporary index from HEAD,
we do not want any of that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
These could stand to be a little more complex, but it should
at least catch obvious problems (like the recently fixed %ct
bug).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Right now, we don't close the read end of the pipe when git-upload-pack
runs git-pack-object, so we hang forever (why don't we get SIGALRM?)
instead of dying with SIGPIPE if the latter dies, which seems to be the
norm if the client disconnects.
Thanks to Johannes Schindelin <Johannes.Schindelin@gmx.de> for
pointing out where this close() needed to go.
This patch has been tested on kernel.org for several weeks and appear
to resolve the problem of git-upload-pack processes hanging around
forever.
Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A pointer arithmetic error in fill_person caused random data
from the commit object to be included with the timestamp,
which looked something like:
$ git-rev-list --pretty=format:%ct origin/next | head
commit 98453bdb3db10db26099749bc4f2dc029bed9aa9
1174977948 -0700
Merge branch 'master' into next
* master:
Bisect: Use
commit c0ce981f5e
1174889646 -0700
Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At least in Linux glibc, "getaddrinfo()" has a very irritating feature (or
bug, who knows..).
Namely if you pass it in an empty string for the service name, it will
happily and quietly consider it identical to a NULL port pointer, and
return port number zero and no errors. Which obviously will not work.
Maybe that's what it's really expected to do, although the man-page for
getaddrinfo() certainly implies that it's a bug.
So when somebody passes me a "please pull" request pointing to something
like the following
git://git.kernel.org:/pub/scm/linux/kernel/git/mchehab/v4l-dvb.git
(note the extraneous colon at the end of the host name), git would happily
try to connect to port 0, which would generally just cause the remote to
not even answer, and the "connect()" will take a long time to time out.
So to work around the glibc feature/bug, just notice this empty port case
automatically. Also, add the port information to the error information
when it fails to look up (maybe it's the host-name that fails, maybe it's
the port-name - we should print out both).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While running 'make test', the test-chmtime program is created, and should
be cleaned up on 'make clean'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use git-log --pretty=oneline to print a short description of the
current HEAD (and merge heads if any) in the buffer header.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We may be able to "run" with only one good revision given
and then verify that the result of the first run is bad.
And perhaps also the other way around.
But for now let's check that we have at least one bad and
one good revision before we start to run.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I stumbled across this in the context of the fchmod 0444 patch.
At first, I was going to unlink and call error like the two subsequent
tests do, but a failed write (above) provokes a "die", so I made
this do the same. This is testing for a write failure, after all.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Given this set of commands:
$ echo "newly added file" >new
$ git add new
$ git rm new
the file "new" was previously removed from the working
directory and the index. Because it was not in HEAD, it is
available only by searching for unreachable objects.
Instead, we now err on the safe side and refuse to remove
a file which is not referenced by HEAD.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add simple example of config file (turning on and allowing override of
a few %features). Also example config file and script to generate list
of projects in a format that can be used as GITWEB_LIST / $projects_list.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This should fix fetching for people who did not use
"git svn --minimize" or cannot connect to the repository root
due to the lack of permissions.
I'm not sure what I was on when I made the change to the
rel_path() function in 4e9f6cc78e
that made it die() when we weren't connected to the repository
root :x
Thanks to Sven Verdoolaege for reporting this bug.
Signed-off-by: Junio C Hamano <junkio@cox.net>
They give a good starting point to new people who want to get
involved. This owes suggestions by Martin Langhoff and Steven
Grimm.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
user-manual: introduce "branch" and "branch head" differently
glossary: clean up cross-references
glossary: stop generating automatically
user-manual: Use def_ instead of ref_ for glossary references.
user-manual.txt: fix a tiny typo.
user-manual: run xsltproc without --nonet option
* 'maint' of git://linux-nfs.org/~bfields/git:
user-manual: introduce "branch" and "branch head" differently
glossary: clean up cross-references
glossary: stop generating automatically
user-manual: Use def_ instead of ref_ for glossary references.
user-manual.txt: fix a tiny typo.
user-manual: run xsltproc without --nonet option
* maint:
gitweb: Add some installation notes in gitweb/INSTALL
gitweb: Fix not marking signoff lines in "log" view
gitweb: Don't escape attributes in CGI.pm HTML methods
gitweb: Change to use explicitly function call cgi->escapHTML()
This simplifies the shell code, reduces its memory footprint, and
speeds things up. The performance improvements should be noticable
when git-rebase works on big commits.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When some operations are interrupted (or "die()'d" or crashed) then the
partial object/pack/index file may remain around. Make it more obvious
in their name that those files are temporary stuff and can be cleaned up
if no operation is in progress.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The update hook's only job is to decide is a particular update
is allowed or not. It was not the right place to send out
update notification e-mails from to begin with, as the final
stage of updating refs can fail after this hook runs.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add some installation and configuration notes for gitweb in
gitweb/INSTALL. Make use of filling gitweb configuration by
Makefile.
It does not cover (yet?) all the configuration variables and
options.
Some of contents duplicates information in gitweb/README file
(it is referred from gitweb/INSTALL).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The CSS selector for signoff lines style was too strict: in the "log"
view the commit message is not encompassed in container "page_body"
div.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is no need to escape HTML tag's attributes in CGI.pm
HTML methods (like CGI::a()), because CGI.pm does attribute
escaping automatically.
$cgi->a({ ... -attribute => atribute_value }, tag_contents)
is translated to
<a ... attribute="attribute_value">tag_contents</a>
The rules for escaping attribute values (which are string contents) are
different. For example you have to take care about escaping embedded '"'
and "'" characters; CGI::a() does that for us automatically.
CGI::a() does not HTML escape tag_contents; we would need to write
<a href="URL">some <b>bold</b> text</a>
for example. So we use esc_html (or esc_path) to escape tag_contents
as needed.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change to use explicitly function call cgi->escapHTML().
This fix the problem on some systems that escapeHTML() is not
functioning, as default CGI is not setting 'escape' parameter.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When converting from the shell script, based on a misreading of the
sed invocation, the builtin included the abbreviated commit name,
and did _not_ include the quotes around the oneline message.
This fixes it.
[jc: with a fix for the typo/thinko spotted by Linus, and also
removing the unwanted abbrev at the beginning.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The trick is to give a child commit that is not tree-changing
the same depth as its parent, so that the depth is propagated
properly along strand of pearls.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you have 5 commits in the set, commits that reach 2 or 3
commits are at halfway. If you have 6 commits, only commits
that reach exactly 3 commits are at halfway. The earlier one is
completely botched the math.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a path-limited bisection, when the $bad commit is not
changing the limited path, and the number of suspects is 1, the
code miscounted and returned $bad from find_bisection(), which
is not marked with TREECHANGE. This is of course filtered by
the output routine, resulting in an empty output, in turn
causing git-bisect driver to say "$bad was both good and bad".
Illustration. Suppose you have these four commits, and only C
changes path P. You know D is bad and A is good.
A---B---C*--D
git-bisect driver runs this to find a bisection point:
$ git rev-list --bisect A..D -- P
which calls find_bisection() with B, C and D. The set of
commits that is given to this function is the same set of
commits as rev-list without --bisect option and pathspec
returns. Among them, only C is marked with TREECHANGE. Let's
call the set of commits given to find_bisection() that are
marked with TREECHANGE (or all of them if no path limiter is in
effect) "the bisect set". In the above example, the size of the
bisect set is 1 (contains only "C").
For each commit in its input, find_bisection() computes the
number of commits it can reach in the bisect set. For a commit
in the bisect set, this number includes itself, so the number is
1 or more. This number is called "depth", and computed by
count_distance() function.
When you have a bisect set of N commits, and a commit has depth
D, how good is your bisection if you returned that commit? How
good this bisection is can be measured by how many commits are
effectively tested "together" by testing one commit.
Currently you have (N-1) untested commits (the tip of the bisect
set, although it is included in the bisect set, is already known
to be bad). If the commit with depth D turns out to be bad,
then your next bisect set will have D commits and you will have
(D-1) untested commits left, which means you tested (N-1)-(D-1)
= (N-D) commits with this bisection. If it turns out to be good, then
your next bisect set will have (N-D) commits, and you will have
(N-D-1) untested commits left, which means you tested
(N-1)-(N-D-1) = D commits with this bisection.
Therefore, the goodness of this bisection is is min(N-D, D), and
find_bisection() function tries to find a commit that maximizes
this, by initializing "closest" variable to 0 and whenever a
commit with the goodness that is larger than the current
"closest" is found, that commit and its goodness are remembered
by updating "closest" variable. The "the commit with the best
goodness so far" is kept in "best" variable, and is initialized
to a commit that happens to be at the beginning of the list of
commits given to this function (which may or may not be in the
bisect set when path-limit is in use).
However, when N is 1, then the sole tree-changing commit has
depth of 1, and min(N-D, D) evaluates to 0. This is not larger
than the initial value of "closest", and the "so far the best
one" commit is never replaced in the loop.
When path-limit is not in use, this is not a problem, as any
commit in the input set is tree-changing. But when path-limit
is in use, and when the starting "bad" commit does not change
the specified path, it is not correct to return it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix copy'n'paste error in commit c9d193df which caused that "next"
link for merge commits in "commit" view
(merge: _commit_ _commit_ ...)
was to "commitdiff" view instead of being to "commit" view.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The branch you are on while bisecting is always "bisect", and
checking for "refs/heads/bisect*" is wrong. Only check if it is
exactly "refs/heads/bisect".
Signed-off-by: Junio C Hamano <junkio@cox.net>
After "git reset" moves the HEAD around, it reports which commit
you are on, which gives the user a warm fuzzy feeling of
assurance. Give the same assurance from git-checkout when
moving the detached HEAD around.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This idea was suggested by Bill Lear
(Message-ID: <17920.38942.364466.642979@lisa.zopyra.com>)
and I think it is a very good one.
This patch adds a new test file for "git bisect run", but there
is currently only one basic test.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this the rev could be (e.g.) a tag and then the condition to end the
bisect might fail and you have to check the already known to be bad revision
once more.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Elias Pipping:
> I'm on a mac, hence /usr/bin/sed is not gnu sed, which makes
> t4118 fail.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Ack'd-by: Elias Pipping <pipping@macports.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we write out the result of patch application, we sometimes
need to munge the data (e.g. under core.autocrlf). After doing
so, what we should free is the temporary buffer that holds the
converted data returned from convert_to_working_tree(), not the
original one.
This patch also moves the call to open() up in the function, as
the caller expects us to fail cheaply if leading directories
need to be created (and then the caller creates them and calls
us again). For that calling pattern, attempting conversion
before opening the file adds unnecessary overhead.
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The HEAD reflog is updated as well as the reflog for the branch pointed
to by HEAD whenever it is referenced with "HEAD".
There are some cases where a specific branch may be modified directly.
In those cases, the HEAD reflog should be updated as well if it is a
symref to that branch in order to be consistent.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was annoying to always have the first email from a project be from
the "Unnamed repository; edit this file to name it for gitweb project";
just because it's so easy to forget to set it.
This patch checks to see if the description file is still default (or
empty) and aborts if so - allowing you to fix the problem before sending
out silly looking emails to every developer.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-fetch <URL> && git-merge FETCH_HEAD produce the
same merge message as git-pull <URL>.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When you want to amend the commit message of 3 commits before
the tip of the current branch, say 'master',
A--B--C--D--E(master)
it is sometimes handy to make your head detached at that commit
with:
$ git checkout HEAD~3 ;# check out B
$ git commit --amend ;# without modifying contents...
to create:
.B'(HEAD)
/
A--B--C--D--E(master)
and then rebase 'master' branch onto HEAD with this:
$ git rebase HEAD master
to result in:
.B'-C'-D'-E(master=HEAD)
/
A--B--C--D--E
However, the current code interprets HEAD after it switches to
the branch 'master', which means the rebase will not do
anything. You have to say something unwieldly like this
instead:
$ git rebase $(git rev-parse HEAD) master
This fixes it by expanding the $onto commit name before
switching to the target branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This improves the performance of revision bisection.
The idea is to avoid rather expensive count_distance() function,
which counts the number of commits that are reachable from any
given commit (including itself) in the set. When a commit has
only one relevant parent commit, the number of commits the
commit can reach is exactly the number of commits that the
parent can reach plus one; instead of running count_distance()
on commits that are on straight single strand of pearls, we can
just add one to the parents' count.
On the other hand, for a merge commit, because the commits
reachable from one parent can be reachable from another parent,
you cannot just add the parents' counts up plus one for the
commit itself; that would overcount ancestors that are reachable
from more than one parents.
The algorithm used in the patch runs count_distance() on merge
commits, and uses the util field of commit objects to remember
them. After that, the number of commits reachable from each of
the remaining commits is counted by finding a commit whose count
is not yet known but the count for its (sole) parent is known,
and adding one to the parent's count, until we assign numbers to
everybody.
Another small optimization is whenever we find a half-way commit
(that is, a commit that can reach exactly half of the commits),
we stop giving counts to remaining commits, as we will not find
any better commit than we just found.
The performance to bisect between v1.0.0 and v1.5.0 in git.git
repository was improved by saying good and bad in turns from
3.68 seconds down to 1.26 seconds. Bisecting the kernel between
v2.6.18 and v2.6.20 was sped up from 21.84 seconds down to 4.22
seconds.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --bisect-vars option to rev-list. The output is suitable
for `eval` in shell and defines five variables:
- bisect_rev is the next revision to test.
- bisect_nr is the expected number of commits to test after
bisect_rev is tested.
- bisect_good is the expected number of commits to test
if bisect_rev turns out to be good.
- bisect_bad is the expected number of commits to test
if bisect_rev turns out to be bad.
- bisect_all is the number of commits we are bisecting right now.
The documentation text was partly stolen from Johannes
Schindelin's patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently all calls to the database backend make no
error checking or handling at all. At least abort
if the connection to the database failed since
there is really no way we could do anything useful
after that.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make all the different parts of the database backend connection
configurable. This adds the following string configuration variables:
- gitcvs.dbdriver
- gitcvs.dbname
- gitcvs.dbuser
- gitcvs.dbpass
The default values emulate the current behavior exactly for
backwards compatibility.
All configuration variables can also be specified for a specific
access method (i.e. in the form gitcvs.<method>.<var>)
The dbdriver/dbuser/dbpass variables are added for completness.
No other backend than SQLite is tested yet.
The dbname variable on the other hand is useful with this backend
already (to not discriminate against other possible backends
it was not splitted in dbdir and dbfile).
Both dbname and dbuser support dynamic variable substitution where
the available variables are:
%m -- the CVS 'module' (i.e. GIT 'head') worked on
%a -- CVS access method used (i.e. 'ext' or 'pserver')
%u -- User name of the user invoking git-cvsserver
%G -- .git directory name
%g -- .git directory name, mangled to be used in a filename,
currently this substitutes all chars except for [\w.-]
with '_'
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow to override the gitcvs.enabled and gitcvs.logfile configuration
variables for each access method (i.e. "ext" or "pserver") in the
form gitcvs.<method>.<var>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is intended to be used in the form gitcvs.<method>.<var>
but this patch doesn't introduce any users yet.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$state->{method} contains the CVS access method used,
either 'ext' or 'pserver'
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The test expects --bisect option can be configured with by setting
$_bisect_option. So let's allow that uniformly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In addition to optimizing pathspecs that would never match,
which was done earlier, this optimizes pathspecs that would
always match (e.g. "arch/" while the traversal is already in
"arch/i386/" hierarchy).
This patch makes the worst case slightly more palatable, while
improving average case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we already know that some of the pathspecs can match later
entries in the tree we are looking at, we do not have to do more
expensive strncmp() upfront before comparing the length of the
match pattern and the path, as a path longer than the match
pattern will not match it, and a path shorter than the match
pattern will match only if the path is a directory-component
wise prefix of the match pattern.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we are looking at a tree entry with pathspecs, if all the
pathspecs sort strictly earlier than the entry we are currently
looking at, there is no way later entries in the same tree would
match our pathspecs, because the entries are sorted.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes the tree descriptor contain a "struct name_entry" as part of
it, and it gets filled in so that it always contains a valid entry. On
some benchmarks, it improves performance by up to 15%.
That makes tree entry "extract" trivial, and means that we only actually
need to decode each tree entry just once: we decode the first one when
we initialize the tree descriptor, and each subsequent one when doing
"update_tree_entry()". In particular, this means that we don't need to
do strlen() both at extract time _and_ at update time.
Finally, it also allows more sharing of code (entry_extract(), that
wanted a "struct name_entry", just got totally trivial, along with the
"tree_entry()" function).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This removes slightly more lines than it adds, but the real reason for
doing this is that future optimizations will require more setup of the
tree descriptor, and so we want to do it in one place.
Also renamed the "desc.buf" field to "desc.buffer" just to trigger
compiler errors for old-style manual initializations, making sure I
didn't miss anything.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we have the "tree_entry_len()" helper function these days, and
don't need to do a full strlen(), there's no point in saving the path
length - it's just redundant information.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Preferring git _space_ COMMAND over git _dash_ COMMAND allows the
user to have only git and gitk in their path. e.g. when git and gitk
are symbolic links in a personal bin directory to the real git and gitk.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The earlier round makes the function return "is it different"
and it does not return a value suitable for sorting anymore. Reverse
the logic to return "are they the same suspect" instead, and rename
it to "same_suspect()".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't try to remove the containing directory for every pruned object but
try only once after the directory has been scanned instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change the feedback message if doing 'git checkout foo' when already on
branch "foo".
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When creating a new object, we use "deflate(stream, Z_FINISH)" in a loop
until it no longer returns Z_OK, and then we do "deflateEnd()" to finish
up business.
That should all work, but the fact is, it's not how you're _supposed_ to
use the zlib return values properly:
- deflate() should never return Z_OK in the first place, except if we
need to increase the output buffer size (which we're not doing, and
should never need to do, since we pre-allocated a buffer that is
supposed to be able to hold the output in full). So the "while()" loop
was incorrect: Z_OK doesn't actually mean "ok, continue", it means "ok,
allocate more memory for me and continue"!
- if we got an error return, we would consider it to be end-of-stream,
but it could be some internal zlib error. In short, we should check
for Z_STREAM_END explicitly, since that's the only valid return value
anyway for the Z_FINISH case.
- we never checked deflateEnd() return codes at all.
Now, admittedly, none of these issues should ever happen, unless there is
some internal bug in zlib. So this patch should make zero difference, but
it seems to be the right thing to do.
We should probablybe anal and check the return value of "deflateInit()"
too!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Looking at the SHA1 validation code due to the corruption that Alexander
Litvinov is seeing under Cygwin, I notice that one of the most central
places where we read objects, we actually do end up verifying the SHA1 of
the result, but then we happily parse it anyway.
And using "printf" to write the error message means that it not only can
get lost, but will actually mess up stdout, and cause other strange and
hard-to-debug failures downstream.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When appending objects to a pack, make sure the appended data is really
what we expect instead of simply loading potentially corrupted objects
and legitimating them by computing a SHA1 of that corrupt data.
With this the sha1_object() can lose its test_for_collision parameter
which is now redundent.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use hash_sha1_file() instead of duplicating code to compute object SHA1.
While at it make it accept a const pointer.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Waaaaaaay back Git was considered to be secure as it never overwrote
an object it already had. This was ensured by always unpacking the
packfile received over the network (both in fetch and receive-pack)
and our already existing logic to not create a loose object for an
object we already have.
Lately however we keep "large-ish" packfiles on both fetch and push
by running them through index-pack instead of unpack-objects. This
would let an attacker perform a birthday attack.
How? Assume the attacker knows a SHA-1 that has two different
data streams. He knows the client is likely to have the "good"
one. So he sends the "evil" variant to the other end as part of
a "large-ish" packfile. The recipient keeps that packfile, and
indexes it. Now since this is a birthday attack there is a SHA-1
collision; two objects exist in the repository with the same SHA-1.
They have *very* different data streams. One of them is "evil".
Currently the poor recipient cannot tell the two objects apart,
short of by examining the timestamp of the packfiles. But lets
say the recipient repacks before he realizes he's been attacked.
We may wind up packing the "evil" version of the object, and deleting
the "good" one. This is made *even more likely* by Junio's recent
rearrange_packed_git patch (b867092f).
It is extremely unlikely for a SHA1 collisions to occur, but if it
ever happens with a remote (hence untrusted) object we simply must
not let the fetch succeed.
Normally received packs should not contain objects we already have.
But when they do we must ensure duplicated objects with the same SHA1
actually contain the same data.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The configured refspecs are printed almost verbatim, i.e. both the local
and the remote branch name separated by a colon are printed; only the
prefix 'refs/heads/' is removed, like this:
Local branch(es) pushed with 'git push'
master refs/tags/*:refs/tags/* next:next
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the single force (+) when fetched with fetch_per_ref.
Also use $LF as separator because IFS is $LF.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We already have -q in git clone. So for those who care to suppress
the noise during an http based clone, make -q actually do a quiet
http fetch.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Cc: Fernando Herrera <fherrera@onirica.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The thing is, if the output buffer is empty, we should *still* actually
use the zlib routines to *unpack* that empty output buffer.
But we had a test that said "only unpack if we still expect more output".
So we wouldn't use up all the zlib stream, because we felt that we didn't
need it, because we already had all the bytes we wanted. And it was
"true": we did have all the output data. We just needed to also eat all
the input data!
We've had this bug before - thinking that we don't need to inflate()
anything because we already had it all..
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a simple but powerful continuous integration build system
for Git. It works by receiving push events from repositories
through the post-receive hook, aggregates them on a per-branch
basis into a first-come-first-serve build queue, and lets a
background build daemon perform builds one at a time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There has not been any work on the shallow stuff lately, so it is hard
to find out what it does, and how. This document describes the ideas
as well as the current problems, and can serve as a starting point for
shallow people.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Setting up a git-daemon came up the other day on IRC, and it is slightly
non trivial for the uninitiated.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since in at least one use case, xdl_hash_record() takes over 15% of the
CPU time, it makes sense to even micro-optimize it. For many cases, no
whitespace special handling is needed, and in these cases we should not
even bother to check for whitespace in _every_ iteration of the loop.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commit structures are guaranteed their uniqueness by the object
layer, so we can check their address and see if they are the same
without going down to the object sha1 level.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This provides a smoother degradation in performance when the cache
gets trashed due to the delta_base_cache_limit being reached. Limited
testing with really small delta_base_cache_limit values appears to confirm
this.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently there are 3 different ways to deal with the cache size.
Let's stick to only one. The compiler is smart enough to produce the exact
same code in those cases anyway.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I think we can start to slow down, as we now have covered
everything I listed earlier in the short-term release plan.
The last release 1.5.0 took painfully too long.
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier conversion to run_command() from execlp() forgot that
run_command() takes an array that is terminated with NULL.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is mainly just a cleanup patch, and sets up for later changes where
the tree-diff.c "interesting()" function can return more than just a
yes/no value.
In particular, it should be quite possible to say "no subsequent entries
in this tree can possibly be interesting any more", and thus allow the
callers to short-circuit the tree entirely.
In fact, changing the callers to do so is trivial, and is really all this
patch really does, because changing "interesting()" itself to say that
nothing further is going to be interesting is definitely more complicated,
considering that we may have arbitrary pathspecs.
But in cleaning up the callers, this actually fixes a potential small
performance issue in diff_tree(): if the second tree has a lot of
uninterestign crud in it, we would keep on doing the "is it interesting?"
check on the first tree for each uninteresting entry in the second one.
The answer is obviously not going to change, so that was just not helping.
The new code is clearer and simpler and avoids this issue entirely.
I also renamed "interesting()" to "tree_entry_interesting()", because I
got frustrated by the fact that
- we actually had *another* function called "interesting()" in another
file, and I couldn't tell from the profiles which one was the one that
mattered more.
- when rewriting it to return a ternary value, you can't just do
if (interesting(...))
...
any more, but want to assign the return value to a local variable. The
name of choice for that variable would normally be "interesting", so
I just wanted to make the function name be more specific, and avoid
that whole issue (even though I then didn't choose that name for either
of the users, just to avoid confusion in the patch itself ;)
In other words, this doesn't really change anything, but I think it's a
good thing to do, and if somebody comes along and writes the logic for
"yeah, none of the pathspecs you have are interesting", we now support
that trivially.
It could easily be a meaningful optimization for things like "blame",
where there's just one pathspec, and stopping when you've seen it would
allow you to avoid about 50% of the tree traversals on average.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "track_tree_refs()" use the same "tree_entry()" function for
counting the entries as it does for actually traversing them a few lines
later.
Not a biggie, but the reason I care was that this was the only user of
"update_tree_entry()" that didn't actually *extract* the tree entry first.
It doesn't matter as things stand now, but it meant that a separate
test-patch I had that avoided a few more "strlen()" calls by just saving
the entry length in the entry descriptor and using it directly when
updating wouldn't work without this patch.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Run the pre-commit and post-commit hooks at appropriate places, and
display their output if any.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new configuration variable core.deltaBaseCacheLimit allows the
user to control how much memory they are willing to give to Git for
caching base objects of deltas. This is not normally meant to be
a user tweakable knob; the "out of the box" settings are meant to
be suitable for almost all workloads.
We default to 16 MiB under the assumption that the cache is not
meant to consume all of the user's available memory, and that the
cache's main purpose was to cache trees, for faster path limiters
during revision traversal. Since trees tend to be relatively small
objects, this relatively small limit should still allow a large
number of objects.
On the other hand we don't want the cache to start storing 200
different versions of a 200 MiB blob, as this could easily blow
the entire address space of a 32 bit process.
We evict OBJ_BLOB from the cache first (credit goes to Junio) as
we want to favor OBJ_TREE within the cache. These are the objects
that have the highest inflate() startup penalty, as they tend to
be small and thus don't have that much of a chance to ammortize
that penalty over the entire data.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* sp/run-command:
Use run_command within send-pack
Use run_command within receive-pack to invoke index-pack
Use run_command within merge-index
Use run_command for proxy connections
Use RUN_GIT_CMD to run push backends
Correct new compiler warnings in builtin-revert
Replace fork_with_pipe in bundle with run_command
Teach run-command to redirect stdout to /dev/null
Teach run-command about stdout redirection
In the Linux kernel, for example, it's common to include Cc: lines
for cases when you want to remember to cc someone on a patch without
necessarily claiming they signed off on it. Make git-send-email
aware of these.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I was using "branch" to mean "head", but that's perhaps a little
sloppy; so instead start by using the terms "branch head" and "head",
while still quickly falling back on "branch", since that's what
people actually say more frequently.
Also include glossary references on the first uses of "head" and "tag".
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The sort_glossary.pl script sorts the glossary, checks for duplicates,
and automatically adds cross-references.
But it's not so hard to do all that by hand, and sometimes the automatic
cross-references are a little wrong; so let's run the script one last
time and check in its output.
Note: to make the output fit better into the user manual I also deleted
the acknowledgements at the end, which was maybe a little rude; feel
free to object and I can find a different solution.
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I'd like to start using references to the glossary in the user manual.
The "ref_" prefix for these references seems a little generic; so
replace with "def_".
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
"file patch" was doubtless intended to be "file path",
but "directory name" is clearer.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The --nonet option prevents xsltproc from going to the network to find
anything. But it always tries to find them locally first, so for a
user with the necessary docbook stylesheets installed the build will
work just fine without xsltproc attempting to use the network; all
--nonet does is make it fail rather than falling back on that. That
doesn't seem particularly helpful.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
* ar/diff:
Add tests for --quiet option of diff programs
try-to-simplify-commit: use diff-tree --quiet machinery.
revision.c: explain what tree_difference does
Teach --quiet to diff backends.
diff --quiet
Remove unused diffcore_std_no_resolve
Allow git-diff exit with codes similar to diff(1)
This is a micro-optimization that grew out of the mailing list discussion
about "strlen()" showing up in profiles.
We used to pass regular C strings around to the low-level tree walking
routines, and while this worked fine, it meant that we needed to call
strlen() on strings that the caller always actually knew the size of
anyway.
So pass the length of the string down wih the string, and avoid
unnecessary calls to strlen(). Also, when extracting a pathname from a
tree entry, use "tree_entry_len()" instead of strlen(), since the length
of the pathname is directly calculable from the decoded tree entry itself
without having to actually do another strlen().
This shaves off another ~5-10% from some loads that are very tree
intensive (notably doing commit filtering by a pathspec).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>"
Signed-off-by: Junio C Hamano <junkio@cox.net>
A malloc() + memcpy() will always be faster than mmap() +
malloc() + inflate(). If the data is already there it is
certainly better to copy it straight away.
With this patch below I can do 'git log drivers/scsi/ >
/dev/null' about 7% faster. I bet it might be even more on
those platforms with bad mmap() support.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This trivial 256-entry delta_base cache improves performance for some
loads by a factor of 2.5 or so.
Instead of always re-generating the delta bases (possibly over and over
and over again), just cache the last few ones. They often can get re-used.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This doesn't change any code, it just creates a point for where we'd
actually do the caching of delta bases that have been generated.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Especially with the new index format to come, it is more appropriate
to encapsulate more into check_packed_git_idx() and assume less of the
index format in struct packed_git.
To that effect, the index_base is renamed to index_data with void * type
so it is not used directly but other pointers initialized with it. This
allows for a couple pointer cast removal, as well as providing a better
generic name to grep for when adding support for new index versions or
formats.
And index_data is declared const too while at it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make sure pack-objects with --delta-base-offset works fine, and that
it actually produces smaller packs as expected.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'use packed deltified objects' test was flawed as it failed to
remove the pack and index from the previous test, effectively preventing
the desired pack from being exercised as objects could be found in that
other pack instead.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier patch 87ab7992 broke applymbox by blindly copying piece
from git-am, causing a harmless but annoying series of error messages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The message formating (commit v1.5.0.3-28-gbe242d5) broke the && chain.
Noticed by Dmitry Torokhov.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We generally prefer xstrdup to just plain strdup.
Make it so.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds support for a dummy remote '.' to avoid having
to declare a fake remote like
[remote "local"]
url = .
fetch = refs/heads/*:refs/heads/*
Such a builtin remote simplifies the operation of "git-fetch",
which will populate FETCH_HEAD but will not pretend that two
repositories are in use, will not create a thin pack, and will
not perform any useless remapping of names. The speed
improvement is around 20%, and it should improve more if
"git-fetch" is converted to a builtin.
To this end, git-parse-remote is grown with a new kind of
remote, 'builtin'. In git-fetch.sh, we treat the builtin remote
specially in that it needs no pack/store operations. In fact,
doing git-fetch on a builtin remote will simply populate
FETCH_HEAD appropriately.
The patch also improves of the --track/--no-track support,
extending it so that branch.<name>.remote items referring '.'
can be created. Finally, it fixes a typo in git-checkout.sh.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If your development history does not have fast-forward merges,
i.e. the "first parent" of commits in your history are special
than other parents, this option gives a better overview of the
evolution of a particular branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses diff-tree --quiet machinery to terminate the internal
diff-tree between a commit and its parents via revs.pruning (not
revs.diffopt) as soon as we find enough about the tree change.
With respect to the optionally given pathspec, we are interested
if the tree of commit is identical to the parent's, only adds
new paths to the parent's, or there are other differences. As
soon as we find out that there is one such other kind of
difference, we do not have to compare the rest of the tree.
Because we do not call standard diff_addremove/diff_change, we
instruct the diff-tree machinery to stop early by setting
has_changes when we say we found the trees to be different.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This explains how tree_difference variable is used, and updates two
places where the code knows symbolic constant REV_TREE_SAME is 0.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches git-diff-files, git-diff-index and git-diff-tree
backends to exit early under --quiet option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the command line option 'quiet' to tell 'git diff-*'
that we are not interested in the actual diff contents but only
want to know if there is any change. This option automatically
turns --exit-code on, and turns off output formatting, as it
does not make much sense to show the first hit we happened to
have found.
The --quiet option is silently turned off (but --exit-code is
still in effect, so is silent output) if postprocessing filters
such as pickaxe and diff-filter are used. For all practical
purposes I do not think of a reason to want to use these filters
and not viewing the diff output.
The backends have not been taught about the option with this patch.
That is a topic for later rounds.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This introduces a new command-line option: --exit-code. The diff
programs will return 1 for differences, return 0 for equality, and
something else for errors.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previous formulation could make it appear as removing all lines
matching a regexp (at least, I was looking for such a flag, and
confused this flag for what I was looking for).
Signed-off-by: Yann Dirson <ydirson@altern.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The symbolic notation of the fork point can contain whitespaces (e.g.
"git checkout -m 'HEAD@{9 hours ago}'"). Quote strings properly
when using eval to prepare GITHEAD_$new
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously git-describe would output lines of the form
v1.1.1-gf509d56
The update hook found the dash and stripped it off using
sed 's/-g.*//'
The remainder was then used as the previous tag name.
However, git-describe has changed format. The output is now of the form
v1.1.1-23-gf509d56
The above sed fragment doesn't strip the middle "-23", and so the
previous tag name used would be "v1.1.1-23". This is incorrect.
Since the hook script was written, git-describe now gained support for
"--abbrev=0", which it uses as a special flag to tell it not to output
anything other than the nearest tag name. This patch fixes the problem,
and prevents any future recurrence by using this new flag rather than
sed to find the previous tag.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit: Also print the old revision similar to how cvs does it and
prepend a line stating the filename so that one can actually
understand what happened when commiting more than one file.
status: Fix the RCS filename displayed. The directory was
printed twice.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Submit some additional messages to the client on commit and update.
Inspired by the standard CVS server though a little more terse.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/fetch:
.gitignore: add git-fetch--tool
builtin-fetch--tool: fix reflog notes.
git-fetch: retire update-local-ref which is not used anymore.
builtin-fetch--tool: make sure not to overstep ls-remote-result buffer.
fetch--tool: fix uninitialized buffer when reading from stdin
builtin-fetch--tool: adjust to updated sha1_object_info().
git-fetch--tool takes flags before the subcommand.
Use stdin reflist passing in git-fetch.sh
Use stdin reflist passing in parse-remote
Allow fetch--tool to read from stdin
git-fetch: rewrite expand_ref_wildcard in C
git-fetch: rewrite another shell loop in C
git-fetch: move more code into C.
git-fetch--tool: start rewriting parts of git-fetch in C.
git-fetch: split fetch_main into fetch_dumb and fetch_native
If you use scanf or sscanf to parse integers, your code probably
accepts bogus inputs. For example, builtin-grep (aka git-grep) uses
sscanf(scan, "%u", &num) to parse the integer argument to -A, -B, -C.
Currently, "-C 1,000" and "-C 4294967297" are both treated just like
"-C 1":
$ git-grep -h -C 4294967297 juggle
out and you may find it easier to switch back and forth if you
juggle multiple lines of development simultaneously. Of
course, you will pay the price of more disk usage to hold
The obvious fix is to use strtoul instead. But using a bare strtoul is
too messy, at least when done properly, so I've added a wrapper function.
The new function in the patch below belongs elsewhere if it would be
useful in replacing any of the four remaining uses of sscanf.
One final note: With this change, I get a slightly different
diagnostic depending on the context size:
$ ./git-grep -h -C 4294967296 juggle
fatal: 4294967296: invalid context length argument
[Exit 128]
$ ./git-grep -h -C 4294967295 juggle
grep: 4294967295: invalid context length argument
[Exit 1]
A common convention that makes it easy to identify the source
of a diagnostic is to include the program name before the first ":".
Whether that should be "git" or "git-grep" is another question.
Using "grep" or "fatal" is misleading.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the same issue as 8bef6204, which became an issue again
after 31d0399c.
Besides, it is not really helpful to print just "GEN " (_without_
"perl.mak").
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I was trying to see who have been active recently to find GSoC
mentor candidates by running:
$ git shortlog -s -n --since=4.months | head -n 20
After waiting for about 20 seconds, I started getting worried,
thinking that the recent revision traversal updates might have
had an unintended side effect.
Not so. "git shortlog" acts as a filter when no revs are given,
unlike "git log" which defaults to HEAD. It was reading from
its standard input.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This avoids fetching new revisions remotely, and is usefuly
versus plain "git rebase" because the user does not have to
specify which remote head to rebase against.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Format some lists really as lists. Improves both html and man
output.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The git-mergetool program can be used to automatically run an appropriate
merge resolution program to resolve merge conflicts. It will automatically
run one of kdiff3, tkdiff, meld, xxdiff, or emacs emerge programs.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Maybe unnecessary as the merge-index utility may go away in the
future, but its currently here, its shorter to use run_command,
and probably will help the MinGW port out.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we hand run_command RUN_GIT_CMD rather than 0 it will use
the execv_git_cmd path rather than execvp at the OS level.
This is typically the preferred way of running another Git
utility.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new builtin-revert code introduces a few new compiler errors
when I'm building with my stricter set of checks enabled in CFLAGS.
These all just stem from trying to store a constant string into
a non-const char*. Simple fix, make the variables const char*.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that the run_command family supports all of the redirection
modes needed by builtin-bundle, we can use those functions rather
than the underlying POSIX primitives. This should help to make the
bundle command slightly more portable to other systems, like Windows.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some run-command callers may wish to just discard any data that
is sent to stdout from the child. This is a lot like our existing
no_stdin support, we just open /dev/null and duplicate the descriptor
into position.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some potential callers of the run_command family of functions need
to control not only the stdin redirection of the child, but also
the stdout redirection of the child. This can now be setup much
like the already existing stdin redirection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I have come across many emails that use long strings of '-'s as separators
for ideas. This patch below limits the separator to only 3 '-', with the
intent that long string of '-'s will stay in the commit msg and not in the
patch file.
Signed-off-by: Don Zickus <dzickus@redhat.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I am working on a project that required parsing through regular
mboxes that didn't necessarily have patches embedded in them. I
started by creating my own modified copy of git-am and working
from there. Very quickly, I noticed git-mailinfo wasn't able to
handle a big chunk of my email.
After hacking up numerous solutions and running into more
limitations, I decided it was just easier to rewrite a big chunk
of it. The following patch has a bunch of fixes and features
that I needed in order for me do what I wanted.
Note: I'm didn't follow any email rfc papers but I don't think
any of the changes I did required much knowledge (besides the
boundary stuff).
List of major changes/fixes:
- can't create empty patch files fix
- empty patch files don't fail, this failure will come inside git-am
- multipart boundaries are now handled
- only output inbody headers if a patch exists otherwise assume those
headers are part of the reply and instead output the original headers
- decode and filter base64 patches correctly
- various other accidental fixes
I believe I didn't break any existing functionality or
compatibility (other than what I describe above, which is really
only the empty patch file).
I tested this through various mailing list archives and
everything seemed to parse correctly (a couple thousand emails).
[jc: squashed in another patch from Don's five patch series to
fix the test case, as this patch exposes the bug in the test.]
Signed-off-by: Don Zickus <dzickus@redhat.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
Remove unnecessary casts from fast-import
New fast-import test case for valid tree sorting
fast-import: grow tree storage more aggressively
POSIX says sed may add a trailing LF if there isn't already
one there. We shouldn't rely on it not adding that LF, as
some systems (Mac OS X for example) will add it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I started hacking on a change to add stdout redirection support to
the run_command family, but found I was using a lot of close calls
on two pipes in an array (such as for pipe). So I'm doing a tiny
bit of refactoring first to make the next set of changes clearer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Jeff King pointed out that these casts are quite unnecessary, as
the compiler should be doing them anyway, and may cause problems
in the future if the size of the argument for to_atom were to ever
be increased.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Git tree sorting convention is more complex than just the name,
it needs to include the mode too to make sure trees sort as though
their name ends with "/".
This is a simple test case that verifies fast-import keeps the tree
ordering correct after editing the same tree twice in a single
input stream. A recent proposed patch series (that has not yet
been applied) will cause this test to fail, due to a bug in the
way the series handles sorting within the trees.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When building up a tree for a commit, fast-import
dynamically allocates memory for the tree entries. When more
space is needed, the allocated memory is increased by a
constant amount. For very large trees, this means
re-allocating and memcpy()ing the memory O(n) times.
To compound this problem, releasing the previous tree
resource does not free the memory; it is kept in a pool
for future trees. This means that each of the O(n)
allocations will consume increasing amounts of memory,
giving O(n^2) memory consumption.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since git-gui 0.6.4 the credits file is no longer produced.
This file was removed from git-gui due to build issues that
a lot of users and Git developers have reported running into.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Allow 'git gui version' outside of a repository
git-gui: Revert "git-gui: Display all authors of git-gui."
git-gui: Revert "Don't modify CREDITS-FILE if it hasn't changed."
git-gui: Allow committing empty merges
What the function wants to return is not if we saw any return
from pop_most_recent_commit(), but if we found what was asked
for.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I got a little surprise one day when I tried to run 'git gui version'
outside of a Git repository to determine what version of git-gui was
installed on that system. Turns out we were doing the repository
check long before we got around to command line argument handling.
We now look to see if the only argument we have been given is
'version' or '--version', and if so, print out the version and
exit immediately; long before we consider looking at the Git
version or working directory. This way users can still get to
the git-gui version number even if Git's version cannot be read.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit 871f4c97ad.
Too many users have complained about the credits generator in
git-gui, so I'm backing the entire thing out. This revert will
finish that series.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit 92446aba47.
Too many users have complained about the credits generator in
git-gui, so I'm backing the entire thing out.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt noticed that git-gui would not let the user commit
a merge created by `git merge -s ours` as the ours strategy does
not alter the tree (that is HEAD^1^{tree} = HEAD^{tree} after the
merge). The same issue arises from amending such a merge commit.
We now permit an empty commit (no changed files) if we are doing
a merge commit. Core Git does this with its command line based
git-commit tool, so it makes sense for the GUI to do the same.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I chose <F5> because it's also the key to reload the current
page in web browsers such as Konqueror and Firefox, so users
are more likely to be familiar with it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
A use case for git-bundle expected to be quite common is this:
$ git bundle create daily.bundle --since=10.days.ago --all
The expected outcome is _not_ to error out if only a couple of the
refs were not changed during the last 10 days.
This patch complains loudly about refs which are skipped due to the
pack not containing the corresponding objects, but dies only if
no objects would be in the pack _at all_.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Chain-reply-to is a personal perference, and is unlikely to change from
patchset to patchset. Similarly, bcc is likely to have the same values
every invocation is one likes to bcc oneself.
So, allow both to be set via configuration variables.
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Wishing to implement an email aliases file, I found that they were already
implmented. Document them for the next user.
Signed-off-by: Avi Kivity <avi@qumranet.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Warn the user that the "-m" option is ignored in the case of a fast
forward. That may save some confusion in the case where the user
doesn't know about fast forwards yet and may not realize that the
behavior here is intentional.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/boundary:
git-bundle: prevent overwriting existing bundles
git-bundle: die if a given ref is not included in bundle
git-bundle: handle thin packs in subcommand "unbundle"
git-bundle: Make thin packs
git-bundle: avoid packing objects which are in the prerequisites
bundle: fix wrong check of read_header()'s return value & add tests
revision --boundary: fix uncounted case.
revision --boundary: fix stupid typo
git-bundle: make verify a bit more chatty.
revision traversal: SHOWN means shown
git-bundle: various fixups
revision traversal: retire BOUNDARY_SHOW
revision walker: Fix --boundary when limited
Sergey Vlasov, Andy Parkins and Alex Riesen all pointed out that it
is possible for a single invocation of receive-pack to be given more
refs than the OS might allow us to pass as command line parameters
to a single hook invocation.
We don't want to break these up into multiple invocations (like
xargs might do) as that makes it impossible for the pre-receive
hook to verify multiple related ref updates occur at the same time,
and it makes it harder for post-receive to send out a single batch
notification.
Instead we pass the reference data on a pipe connected to the
hook's stdin, supplying one ref per line to the hook. This way a
single hook invocation can obtain an infinite amount of ref data,
without bumping into any operating system limits.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since we have decided to change the calling conventions for the
pre-receive and post-receive hooks to take the ref data on stdin
rather than on the command line we cannot use the same logic to
invoke the update hook anymore.
So we take a small step backwards towards what we used to have,
and create a specialized function for executing just the update
hook.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm pulling the error handling used to decode the result of
run_command up into a new function so that I can reuse it.
No changes, just a simple code movement.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes callers trying to use run_command to execute a child
process will want to setup a pipe or file descriptor to redirect
into the child's stdin.
This idea is completely stolen from builtin-bundle's fork_with_pipe,
written by Johannes Schindelin. All credit (and blame) should lie
with Dscho. ;-)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the calling process wants to send data to stdin of a
child process it will need to arrange for a pipe and get
the child process running, feed data to it, then wait
for the child process to finish. So we split the run
function into two halves, allowing callers to first
start the child then later finish it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There are a number of places where we do some variation of
fork()+exec() but we also need to setup redirection in the process,
much like what run_command does for us already with its option flags.
It would be nice to reuse more of the run_command logic, especially
as that non-fork API helps us to port to odd platforms like Win32.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't actually use these va_list based variants of run_command
anymore. I'm removing them before I make further improvements.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Another change by me is removing the va_list variants of run_command,
one of which is used by builtin-revert.c. To avoid compile errors
I'm refactoring builtin-revert to use the char** variant instead,
as that variant is staying.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using Update-existing leads to the client forgetting about the "locally
modified" status of the file which can lead to loss of local changes on
later updates.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Martin Langhoff <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
a try, but all I could get was a segfault. It was dereferencing a NULL
commit list. Fix below. With it, this example now works:
$ mkdir .j; cd .j; touch f
$ git-init; git-add f; git-commit -mc f; echo x >f; git-commit -md f
$ git-diff -p :/c :/d
diff --git a/f b/f
index e69de29..587be6b 100644
--- a/f
+++ b/f
@@ -0,0 +1 @@
+x
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When accessing objects, we first look for them in packs that
are linked together in the reverse order of discovery.
Since younger packs tend to contain more recent objects, which
are more likely to be accessed often, and local packs tend to
contain objects more relevant to our specific projects, sort the
list of packs before starting to access them. In addition,
favoring local packs over the ones borrowed from alternates can
be a win when alternates are mounted on network file systems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In order to track and build on top of a branch 'topic' you track from
your upstream repository, you often would end up doing this sequence:
git checkout -b mytopic origin/topic
git config --add branch.mytopic.remote origin
git config --add branch.mytopic.merge refs/heads/topic
This would first fork your own 'mytopic' branch from the 'topic'
branch you track from the 'origin' repository; then it would set up two
configuration variables so that 'git pull' without parameters does the
right thing while you are on your own 'mytopic' branch.
This commit adds a --track option to git-branch, so that "git
branch --track mytopic origin/topic" performs the latter two actions
when creating your 'mytopic' branch.
If the configuration variable branch.autosetupmerge is set to true, you
do not have to pass the --track option explicitly; further patches in
this series allow setting the variable with a "git remote add" option.
The configuration variable is off by default, and there is a --no-track
option to countermand it even if the variable is set.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/diff-ni:
Get rid of the dependency to GNU diff in the tests
diff --no-index: support /dev/null as filename
diff-ni: fix the diff with standard input
diff: support reading a file from stdin via "-"
* sp/make:
Allow "make -w" generate its usual output
Support of "make -s": do not output anything of the build itself
More build output cleaning up
Make 'make' quiet by default
Make 'make' quieter while building git
* maint:
git.el: Retrieve commit log information from .dotest directory.
git.el: Avoid appending a signoff line that is already present.
setup_git_directory_gently: fix off-by-one error
user-manual: install user manual stylesheet with other web documents
user-manual: fix rendering of history diagrams
user-manual: fix missing colon in git-show example
user-manual: fix inconsistent use of pull and merge
user-manual: fix inconsistent example
glossary: fix overoptimistic automatic linking of defined terms
Documentation: s/seperator/separator/
Adjust reflog filemode in shared repository
If a git-am or git-rebase is in progress, fill the commit log buffer
from the commit information found in the various files in the .dotest
directory.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also avoid inserting an extra newline if other signoff lines are
present.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
don't tell getcwd that the buffer has one spare byte for an extra /
Signed-off-by: Matthias Lederhofer <matled@gmx.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'maint' of git://linux-nfs.org/~bfields/git:
user-manual: install user manual stylesheet with other web documents
user-manual: fix rendering of history diagrams
user-manual: fix missing colon in git-show example
user-manual: fix inconsistent use of pull and merge
user-manual: fix inconsistent example
glossary: fix overoptimistic automatic linking of defined terms
Asciidoc appears to interpret a backslash at the end of a line as
escaping the end-of-line character, which screws up the display of
history diagrams like
o--o--o
\
o--...
The obvious fix (replacing "\" by "\\") doesn't work. The only
workaround I've found is to include all such diagrams in a LiteralBlock.
Asciidoc claims that should be equivalent to a literal paragraph, so I
don't understand why the difference--perhaps it's an asciidoc bug.
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I used "git pull ." instead of "git merge" here without any explanation.
Stick instead to "git merge" for now (the equivalent pull syntax is
still covered in a later chapter).
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The configuration file fragment here is inconsistent with the text
above. Thanks to Ramsay Jones for the correction.
Cc: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The script sort_glossary.pl turns each use of "term" into a link to the
definition of "term". To avoid mangling links like
gitlink:git-term[1]
it doesn't replace any occurence of "term" preceded by "link:git-".
This fails for gitlink:git-symbolic-ref[1] when substituting for "ref".
So instead just refuse to replace anything preceded by a "-".
That could result in missing some opportunities, but that's a less
annoying error.
Actually I find the automatic substitution a little distracting; some
day maybe we should just run it once and commit the result, so it can
be hand-tuned.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Without this, committing in a group-shared repository would not work
even though all developers are in the same group.
Signed-off-by: Matthias Kestenholz <matthias@spinlock.ch>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the 'core.excludesfile' configuration variable. This variable can
hold a path to a file containing patterns of file names to exclude from
git-add, like $GIT_DIR/info/exclude. Patterns in the excludes file are used
in addition to those in info/exclude.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The --interactive option behaves like "git commit", except that
"git add --interactive" is executed before committing. It is
incompatible with -a and -i.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not only does it prevent accidentally losing older bundles, but it
also fixes a subtle bug: when writing into an existing bundle,
git-pack-objects would not truncate the bundle. Therefore,
fetching from the bundle would trigger an error in unpack-objects:
"fatal: pack has junk at the end".
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier patch tried to be nice by just warning, but it seems
more likely that the user wants to adjust the parameters.
Also, it prevents a bundle containing _all_ revisions in the case
when the user only gave one ref, but also rev-list options which
excluded the ref.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The patch to make the packs in a bundle thin forgot the receiving side.
D'oh.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added a disk-cache p4 output so debugging imports is faster.
Added --known-branches commandline option for pre-defining branches.
Various other fixes...
Signed-off-by: Simon Hausmann <hausmann@kde.org>
* 'master' of git://repo.or.cz/git/fastimport:
Allow fast-import frontends to reload the marks table
Use atomic updates to the fast-import mark file
Preallocate memory earlier in fast-import
Thin packs are way smaller, but they rely on the receiving end to have the
base objects. However, Git's pack protocol also uses thin packs by
default. So make the packs contained in bundles thin, since bundles are
just another transport.
The patch looks a bit bigger than intended, mainly because --thin
_implies_ that pack-objects should run its own rev-list. Therefore, this
patch removes all the stuff we used to roll rev-list ourselves.
This commit also changes behaviour slightly: since we now know early
enough if a specified ref is _not_ contained in the pack, we can avoid
putting that ref into the pack. So, we don't die() here, but warn()
instead, and skip that ref.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When saying something like "--since=1.day.ago" or "--max-count=5",
git-bundle finds the boundary commits which are recorded as
prerequisites. However, it failed to tell pack-objects _not_ to
pack the objects which are in these.
Fix that. And add a test for that.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm giving fast-import a lesson on how to reload the marks table
using the same format it outputs with --export-marks. This way
a frontend can reload the marks table from a prior import, making
incremental imports less painful.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we allow fast-import frontends to reload a mark file from a
prior session we want to let them use the same file as they exported
the marks to. This makes it very simple for the frontend to save
state across incremental imports.
But we don't want to lose the old marks table if anything goes wrong
while writing our current marks table. So instead of truncating and
overwriting the path specified to --export-marks we use the standard
lockfile code to write the current marks out to a temporary file,
then rename it over the old marks table.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Bill Lear pointed out that it is easy to send out notifications of
changes with the update hook, but successful execution of the update
hook does not necessarily mean that the ref was actually updated.
Lock contention on the ref or being unable to append to the reflog
may prevent the ref from being changed. Sending out notifications
prior to the ref actually changing is very misleading.
To help this situation I am introducing two new hooks to the
receive-pack flow: pre-receive and post-receive. These new hooks
are invoked only once per receive-pack execution and are passed
three arguments per ref (refname, old-sha1, new-sha1).
The new post-receive hook is ideal for sending out notifications,
as it has the complete list of all refnames that were successfully
updated as well as the old and new SHA-1 values. This allows more
interesting notifications to be sent. Multiple ref updates could
be easily summarized into one email, for example.
The new pre-receive hook is ideal for logging update attempts, as it
is run only once for the entire receive-pack operation. It can also
be used to verify multiple updates happen at once, e.g. an update
to the `maint` head must also be accompained by a new annotated tag.
Lots of documentation improvements for receive-pack are included
in this change, as we want to make sure the new hooks are clearly
explained.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I discovered we did not send an ng line in the report-status feedback
if the ref was not updated because the repository has the config
option receive.denyNonFastForwards enabled. I think the reason this
happened is that it is simply too easy to forget to set error_string
when returning back a failure from update()
We now return an ng line for a non-fastforward update, which in
turn will cause send-pack to exit with a non-zero exit status.
Hence the modified test.
This refactoring changes update to return a const char* describing
the error, which execute_commands always loads into error_string.
The result is what I think is cleaner code, and allows us to
initialize the error_string member to NULL when we read_head_info.
I want error_string to be NULL in all commands before we call
execute_commands, so that we can reuse the run_hook function to
execute a new pre-receive hook.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a simple refactoring of run_update_hook to allow the function
to be passed the name of the hook it runs and also to build the
argument list from a list of struct commands, rather than just one
struct command.
The refactoring is to support new pre-receive and post-receive
hooks that will be given the entire list of struct commands,
rather than just one struct command. These new hooks will follow
in another patch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is little point in executing the post-update hook if all refs
had an error and were unable to be updated. In this case nothing
new is reachable within the repository, and there is no state change
for the post-update hook to be interested in.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As the post-update hook is meant to run after we have completed the
receipt of the pushed changes, and it might actually try to kick off
a `repack -a -d`, we should delay on invoking it until after we have
removed the *.keep file on the uploaded pack (if we kept the pack).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm about to teach fast-import how to reload the marks file created
by a prior session. The general approach that I want to use is to
immediately parse the marks file when the specific argument is found
in argv, thereby allowing the caller to supply multiple marks files,
as the mark space can be sparsely populated.
To make that work out we need to allocate our object tables before
we parse the command line options. Since none of these tables
depend on the command line options, we can easily relocate them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some systems have sizeof(off_t) == 8 while sizeof(size_t) == 4.
This implies that we are able to access and work on files whose
maximum length is around 2^63-1 bytes, but we can only malloc or
mmap somewhat less than 2^32-1 bytes of memory.
On such a system an implicit conversion of off_t to size_t can cause
the size_t to wrap, resulting in unexpected and exciting behavior.
Right now we are working around all gcc warnings generated by the
-Wshorten-64-to-32 option by passing the off_t through xsize_t().
In the future we should make xsize_t on such problematic platforms
detect the wrapping and die if such a file is accessed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Always use an off_t value in pack-objects anytime we are dealing
with an offset to some data within a packfile.
Also fixed a minor uintmax_t that was incorrectly defined before.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not all platforms have declared 'unsigned long' to be a 64 bit value,
but we want to support a 64 bit packfile (or close enough anyway)
in the near future as some projects are getting large enough that
their packed size exceeds 4 GiB.
By using off_t, the POSIX type that is declared to mean an offset
within a file, we support whatever maximum file size the underlying
operating system will handle. For most modern systems this is up
around 2^60 or higher.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As we technically try to support up to a maximum of 2**32-1 objects
in a single packfile we should act like it and use unsigned 32 bit
integers for all of our object counts and progress output.
This change does not modify everything in pack-objects that probably
needs to change to fully support the maximum of 2**32-1 objects.
I'm intentionally breaking the improvements into slightly smaller
commits to make them easier to follow.
No logic change should be occuring here, with the exception that
some comparsions will now work properly when the number of objects
exceeds 2**31-1.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As we permit up to 2^32-1 objects in a single packfile we cannot
use a signed int to represent the object offset within a packfile,
after 2^31-1 objects we will start seeing negative indexes and
error out or compute bad addresses within the mmap'd index.
This is a minor cleanup that does not introduce any significant
logic changes. It is roach free.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We shouldn't attempt to assign constant strings into char*, as the
string is not writable at runtime. Likewise we should always be
treating unsigned values as unsigned values, not as signed values.
Most of these are very straightforward. The only exception is the
(unnecessary) xstrdup/free in builtin-branch.c for the detached
head case. Since this is a user-level interactive type program
and that particular code path is executed no more than once, I feel
that the extra xstrdup call is well worth the easy elimination of
this warning.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If an index is corrupt, or is simply too new for us to understand,
we were leaking the mmap that held the entire content of the index.
This could be a considerable size on large projects, given that
the index is at least 24 bytes * nr_objects.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we are currently cheating and never supplying the delta base
for an OBJ_OFS_DELTA we get a random SHA-1 in the delta base field.
Instead lets clear the hash out so its at least all 0's. This is
somewhat more obvious that something fishy is going on, like we
don't actually have the SHA-1 of the base handy. :)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds support to archimport for remapping the branch
names to match those used in git more closely. This is useful
for projects that migrate to git (as opposed to users that want
to use git on Arch-based projects). For example, one can choose
an Arch branch name and call it "master".
The new command-line syntax works even if there is a colon in
a branch name, since only the part after the last colon is taken
to be the git name (git does not allow colons in branch names).
The new feature is implemented so that archives rotated every
year can also be remapped into a single git archive.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
They test the behaviour with just a URL in the command line.
Signed-off-by: Santi B,Ai(Bjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This failure to catch the failure of write_ref_sha1 was noticed
by Bill Lear. The ref will not update if the log file could not
be appended to (due to file permissions problems). Such a failure
should be flagged as a failure to update the ref, so that the client
knows the push did not succeed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If read_header() fails, it returns <0, not 0. Further, an open(/dev/null)
was not checked for errors.
Also, this adds two tests to make sure that the bundle file looks
correct, by checking if it has the header has the expected form, and that
the pack contains the right amount of objects.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is no need to escape HTML tag's attributes in CGI.pm
HTML methods (like CGI::a()), because CGI.pm does attribute
escaping automatically.
$cgi->a({ ... -attribute => atribute_value }, tag_contents)
is translated to
<a ... attribute="attribute_value">tag_contents</a>
The rules for escaping attribute values (which are string contents) are
different. For example you have to take care about escaping embedded '"'
and "'" characters; CGI::a() does that for us automatically.
CGI::a() does not HTML escape tag_contents; we would need to write
<a href="URL">some <b>bold</b> text</a>
for example. So we use esc_html (or esc_path) to escape tag_contents
as needed.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- print output file name for .c files
- suppress output of the names of subdirectories when make changes into them
- use GEN prefix for makefile generation in perl/
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The test was recently broken to expect sed to leave the
incomplete line at the end without newline.
POSIX says that output of the pattern space is to be followed by
a newline, while GNU adds the newline back only when it was
stripped when input. GNU behaviour is arguably more intuitive
and nicer, but we should not depend on it.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the list is truly limited and get_revision_1() returned NULL,
the code incorrectly returned it without switching to boundary emiting
mode. Silly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change to use explicitly function call cgi->escapHTML().
This fix the problem on some systems that escapeHTML() is not
functioning, as default CGI is not setting 'escape' parameter.
Signed-off-by: Li Yang <leoli@freescale.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This moves the code to set SHOWN on the commit from get_revision_1()
back to get_revision(), so that the bit means what it originally
meant: this commit has been given back to the caller.
Also it fixes the --reverse breakage Dscho pointed out.
Signed-off-by: Junio C Hamano <junkio@cox.net>
verify_bundle() returned with an error early only when all
prerequisite commits were missing. It should error out much
earlier when some are missing.
When the rev-list is limited in ways other than revision range
(e.g. --max-count or --max-age), create_bundle() listed all
positive refs given from the command line as if they are
available, but resulting pack may not have some of them. Add a
logic to make sure all of them are included, and error out
otherwise.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This removes the flag internally used by revision traversal to
decide which commits are indeed boundaries and renames it to
CHILD_SHOWN. builtin-bundle uses the symbol for its
verification, but I think the logic it uses it is wrong. The
flag is still useful but it is local to the git-bundle, so it is
renamed to PREREQ_MARK.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This cleans up the boundary processing in the commit walker. It
- rips out the boundary logic from the commit walker. Placing
"negative" commits in the revs->commits list was Ok if all we
cared about "boundary" was the UNINTERESTING limiting case,
but conceptually it was wrong.
- makes get_revision_1() function to walk the commits and return
the results as if there is no funny postprocessing flags such
as --reverse, --skip nor --max-count.
- makes get_revision() function the postprocessing phase:
If reverse is given, wait for get_revision_1() to give
everything that it would normally give, and then reverse it
before consuming.
If skip is given, skip that many before going further.
If max is given, stop when we gave out that many.
Now that we are about to return one positive commit, mark
the parents of that commit to be potential boundaries
before returning, iff we are doing the boundary processing.
Return the commit.
- After get_revision() finishes giving out all the positive
commits, if we are doing the boundary processing, we look at
the parents that we marked as potential boundaries earlier,
see if they are really boundaries, and give them out.
It loses more code than it adds, even when the new gc_boundary()
function, which is purely for early optimization, is counted.
Note that this patch is purely for eyeballing and discussion
only. It breaks git-bundle's verify logic because the logic
does not use BOUNDARY_SHOW flag for its internal computation
anymore. After we correct it not to attempt to affect the
boundary processing by setting the BOUNDARY_SHOW flag, we can
remove BOUNDARY_SHOW from revision.h and use that bit assignment
for the new CHILD_SHOWN flag.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Per Junio's suggestion we are setting 'make' to be quiet by default,
with `make V=1` available to force GNU make back to its default
behavior of showing each command it is running.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I find it difficult to see compiler warnings amongst the massive
spewing produced by GNU make as it works through our productions.
This is especially true if CFLAGS winds up being rather long, due
to a large number of -W options being enabled and due to a number
of -D options being configured/required by my platform.
By defining QUIET_MAKE (e.g. make QUIET_MAKE=YesPlease) during
compilation users will get a less verbose output, such as:
...
CC builtin-grep.c
builtin-grep.c:187: warning: 'external_grep' defined but not used
CC builtin-init-db.c
CC builtin-log.c
CC builtin-ls-files.c
CC builtin-ls-tree.c
...
The verbose (normal make) output is still the default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-gui: Make 'make' quieter by default
git-gui: Remove unnecessary /dev/null redirection.
git-gui: Don't create empty (same tree as parent) commits.
git-gui: Add Reset to the Branch menu.
git-gui: Relocate the menu/transport menu code.
* 'master' of git://repo.or.cz/git-gui:
git-gui: Make 'make' quieter by default
git-gui: Remove unnecessary /dev/null redirection.
git-gui: Don't create empty (same tree as parent) commits.
git-gui: Add Reset to the Branch menu.
git-gui: Relocate the menu/transport menu code.
The handcrafted built-in rev-list lookalike forgot to mark the trees
and blobs contained in the boundary commits uninteresting, resulting
in unnecessary objects in the pack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
To fit nicely into the output of the git.git project's own quieter
Makefile, we want to make the git-gui Makefile nice and quiet too.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Somewhere along the line (in abd6970a) git-revert.sh learned to
omit the private object name from the new commit message *unless*
-x was supplied on the command line by the user.
The way this was implemented is really non-obvious in the original
script. Setting replay=t (the default) means we don't include the
the private object name, while setting reply='' (the -x flag) means
we should include the private object name. These two settings now
relate to the replay=1 and replay=0 cases in the C version, so we
need to negate replay to test it is 0.
I also noticed the C version was adding an extra LF in the -x case,
where the older git-revert.sh was not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master-for-junio' of git://repo.or.cz/git/fastimport:
fast-import: Fail if a non-existant commit is used for merge
fast-import: Avoid infinite loop after reset
* maint:
Fix diff-options references in git-diff and git-format-patch
Add definition of <commit-ish> to the main git man page.
Begin SubmittingPatches with a check list
fast-import: Fail if a non-existant commit is used for merge
fast-import: Avoid infinite loop after reset
Most of the git-diff-* documentation used [<common diff options>]
instead of [--diff-options], so make that change in git-diff and
git-format-patch.
In addition, git-format-patch didn't include the meanings of the diff
options.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'maint-for-junio' of git://repo.or.cz/git/fastimport:
fast-import: Fail if a non-existant commit is used for merge
fast-import: Avoid infinite loop after reset
It seems that some people prefer a short list to a long text. But even for
the latter group, a quick reminder list is useful. So, add a check list to
Documentation/SubmittingPatches of what to do to get your patch accepted.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
fast-import: Fail if a non-existant commit is used for merge
fast-import: Avoid infinite loop after reset
[sp: Minor evil merge to deal with type_names array moving
to be private in 'master'.]
Johannes Sixt noticed during one of his own imports that fast-import
did not fail if a non-existant commit is referenced by SHA-1 value
as an argument to the 'merge' command. This allowed the user to
unknowingly create commits that would fail in fsck, as the commit
contents would not be completely reachable.
A side effect of this bug was that a frontend process could mark
any SHA-1 object (blob, tree, tag) as a parent of a merge commit.
This should also fail in fsck, as the commit is not a valid commit.
We now use the same rule as the 'from' command. If a commit is
referenced in the 'merge' command by hex formatted SHA-1 then the
SHA-1 must be a commit or a tag that can be peeled back to a commit,
the commit must already exist, and must be readable by the core Git
infrastructure code. This requirement means that the commit must
have existed prior to fast-import starting, or the commit must have
been flushed out by a prior 'checkpoint' command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt noticed that a 'reset' command applied to a branch that
is already active in the branch LRU cache can cause fast-import to
relink the same branch into the LRU cache twice. This will cause
the LRU cache to contain a cycle, making unload_one_branch run in an
infinite loop as it tries to select the oldest branch for eviction.
I have trivially fixed the problem by adding an active bit to
each branch object; this bit indicates if the branch is already
in the LRU and allows us to avoid trying to add it a second time.
Converting the pack_id field into a bitfield makes this change take
up no additional memory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-fsck always exited with status 0, which was a bit sloppy.
This makes it exit with a non-zero status when errors are
found. The error code is an OR'ed result of:
1 if corrupted objects are found.
2 if objects that are ought to be reachable are missing or corrupt.
For example, it would exit with 1 in a repository with an
unreachable corrupt object. If a tree object of the HEAD commit
is corrupt, you would get 3.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We did not detect broken loose object files, either when
underlying inflate() signalled the breakage, nor inflate()
finished and we had garbage trailing at the end. We do better
now.
We also make unpack_sha1_file() a static function to
sha1_file.c, since it is not used by anybody outside.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When "git fsck" without --full found a loose object missing
because it was broken, it mistakenly thought it was not parsed
because we found it in one of the packs. Back when this code
was written, we did not have a way to explicitly check if we
have the object in pack, but we do now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add git-blame as a candidate to the byte-compilation.
batch-byte-compile is the prefered way to byte-compile files in
batch mode. Use it instead of the interactive function.
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update the main git.html page to point at 1.5.0.3 documentation.
Update draft 1.5.1 release notes with what we have so far.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Panagiotis Issaris reports that some MUAs seem not to like
folded "content-type" and "content-disposition" headers, so this
makes format-patch --attach output to avoid them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The existing --attach option did not create a true "attachment"
but multipart/mixed with Content-Disposition: inline. It should
have been with Content-Disposition: attachment.
Introduce --inline to add multipart/mixed that is inlined, and
make --attach to create an attachement.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'js/fetch-progress' (early part):
Fixup no-progress for fetch & clone
fetch & clone: do not output progress when not on a tty
Conflicts:
git-fetch.sh
* js/symlink:
Tell multi-parent diff about core.symlinks.
Handle core.symlinks=false case in merge-recursive.
Add core.symlinks to mark filesystems that do not support symbolic links.
* maint:
GIT 1.5.0.3
glossary: Add definitions for dangling and unreachable objects
user-manual: more detailed merge discussion
user-manual: how to replace commits older than most recent
user-manual: insert earlier of mention content-addressable architecture
user-manual: ensure generated manual references stylesheet
user-manual: reset to ORIG_HEAD not HEAD to undo merge
Documentation: mention module option to git-cvsimport
Define "dangling" and "unreachable" objects. Modified from original
text proposed by Yasushi Shoji.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add more details on conflict, including brief discussion of file stages.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"Modifying" an old commit by checking it out, --amend'ing it, then
rebasing on top of it, is a slightly cumbersome technique, but I've
found it useful frequently enough to make it seem worth documenting.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The content-addressable design is too important not to be worth at least
a brief mention a little earlier on.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The generated user manual is rather hard to read thanks to the lack of
the css that's supposed to be included from docbook-xsl.css.
I'm totally ignorant of the toolchain; grubbing through xmlto and
related scripts, the easiest way I could find to ensure that the
generated html links to the stylesheet is by calling xsltproc directly.
Maybe there's some better way.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As Linus pointed out recently on the mailing list,
git reset --hard HEAD^
doesn't undo a merge in the case where the merge did a fast-forward. So
the rcommendation here is a little dangerous.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The git-cvsimport argument that specifies a cvs module to import should
probably be included in the default example.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a cherry-pick failed, we used to recommend setting environment
variables to retain the authorship. It is much easier, though, to use
the "-c" flag of git-commit.
Print this message also when merge-recursive fails (the code used to
exit(1) in that case, never reaching the proper failure path).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that "git diff" handles stdin and relative paths outside the
working tree correctly, we can convert all instances of "diff -u"
to "git diff".
This commit is really the result of
$ perl -pi.bak -e 's/diff -u/git diff/' $(git grep -l "diff -u" t/)
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from commit c699a40d68215c7e44a5b26117a35c8a56fbd387)
This allows us to create "new file" and "delete file" patches.
It also cleans up the code.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier commit to read from stdin was full of problems, and
this corrects them.
- The mode bits should have been set to satisify S_ISREG(); we
forgot to the S_IFREG bits and hardcoded 0644;
- We did not give escape hatch to name a path whose name is
really "-". Allow users to say "./-" for that;
- Use of xread() was not prepared to see short read (e.g. reading
from tty) nor handing read errors.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to say
echo Hello World | git diff x -
to compare the contents of file "x" with the line "Hello World".
This automatically switches to --no-index mode.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When run from a subdirectory of a repository, the command forgot
to adjust paths given to it with prefix.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch documents the previously undocumented option --rename-section
and adds a new option to zap an entire section.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Unset NO_C99_FORMAT on Cygwin.
Fix a "pointer type missmatch" warning.
Fix some "comparison is always true/false" warnings.
Fix an "implicit function definition" warning.
Fix a "label defined but unreferenced" warning.
Document the config variable format.suffix
git-merge: fail correctly when we cannot fast forward.
builtin-archive: use RUN_SETUP
Fix git-gc usage note
This should only be set based on the capability of your
compiler/library to support c99 format specifiers. In this
case the version of gcc/newlib and indirectly the version
of Cygwin. It should probably only be set in your config.mak
file.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When core.symlinks is false, and a merge of symbolic links had conflicts,
the merge result is left as a file in the working directory. A decision
must be made whether the file is treated as a regular file or as a
symbolic link. This patch treats the file as a symbolic link only if
all merge parents were also symbolic links.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the file system does not support symbolic links (core.symlinks=false),
merge-recursive must write the merged symbolic link text into a regular
file.
While we are here, fix a tiny memory leak in the if-branch that writes
real symbolic links.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In particular, the second parameter in the call to iconv() will
cause this warning if your library declares iconv() with the
second (input buffer pointer) parameter of type const char **.
This is the old prototype, which is none-the-less used by the
current version of newlib on Cygwin. (It appears in old versions
of glibc too).
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On Cygwin the wchar_t type is an unsigned short (16-bit) int.
This results in the above warnings from the return statement in
the wcwidth() function (in particular, the expressions involving
constants with values larger than 0xffff). Simply replace the
use of wchar_t with an unsigned int, typedef-ed as ucs_char_t.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function at issue being initgroups() from the <grp.h> header
file. On Cygwin, setting _XOPEN_SOURCE suppresses the definition
of initgroups(), which causes the warning while compiling daemon.c.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we cannot fast forward the working tree and the current
branch, git-merge did not exit with non-zero status.
Noticed by Larry Streepy, the section to be fixed identfied by
Johannes Schindelin.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some file systems that can host git repositories and their working copies
do not support symbolic links. But then if the repository contains a symbolic
link, it is impossible to check out the working copy.
This patch enables partial support of symbolic links so that it is possible
to check out a working copy on such a file system. A new flag
core.symlinks (which is true by default) can be set to false to indicate
that the filesystem does not support symbolic links. In this case, symbolic
links that exist in the trees are checked out as small plain files, and
checking in modifications of these files preserve the symlink property in
the database (as long as an entry exists in the index).
Of course, this does not magically make symbolic links work on such defective
file systems; hence, this solution does not help if the working copy relies
on that an entry is a real symbolic link.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add the new --no-abbrev option to the man page for the git-branch command.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-branch has an --abbrev= command line option, but it does
no checking of the input. Take the argument parsing code from
setup_revisions in revisions.c, and also the code for parsing
the --no-abbrev option.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When providing a negative indent, it means that -indent columns were
already printed. Fix a bug where the function ate the first character
if already the first word did not fit into the first line.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
By default allowunannotated is unset in the repo config, hence
$allowunannotated is empty, and must be quoted to not break the syntax.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of using antiquated "git-rev-parse | git-rev-list"
pipeline, it is easier to use "git-rev-list" or "git-log" these
days, as Linus points out.
While we are at it, fix the typo on variable name $newref that
should be $newrev.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Another memory overrun in http-push.c
fetch.o depends on the headers, too.
Documentation: Correct minor typo in git-add documentation.
Documentation/git-send-email.txt: Fix labeled list formatting
Documentation/git-quiltimport.txt: Fix labeled list formatting
Documentation/build-docdep.perl: Fix dependencies for included asciidoc files
Fix some formatting problems:
- Some list labels were missing their "::" characters.
- Some of continuation paragraphs in labeled lists were incorrectly
formatted as literal paragraphs.
- In one case "[verse]" was missing before the config key list.
- The "Basic Examples" section was incorrectly nested inside the
"Config File-Only Options" section.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mark continuation paragraphs of list entries as such to avoid
getting literal paragraphs instead.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mark the continuation paragraph of a list entry as such to avoid
getting a literal paragraph instead.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Adding dependencies on included files to the generated man pages is
wrong - includes are processed by asciidoc, therefore the intermediate
Docbook XML files really depend on included files. Because of these
wrong dependencies the man pages were not rebuilt properly if the
intermediate XML files were left in the tree.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Git 1.5.0 and later no longer output useless messages to standard
error when making the initial (or what looks to be) commit of a
repository. Since /dev/null does not exist on Windows in the
MinGW environment we can't redirect there anyway. Since Git
does not output anymore, I'm removing the redirection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Also the verbose output had unnecessary SHA1 and not-for-merge markers
leaked because append_fetch_head() cheated
Signed-off-by: Junio C Hamano <junkio@cox.net>
When specifying an absolute path, or a relative path pointing outside
the working tree, do not fail, but roll your own diffopt parsing,
and execute a --no-index diff.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Start preparing Release Notes for 1.5.0.3
Documentation: git-remote add [-t <branch>] [-m <branch>] [-f] name url
Include config.mak in doc/Makefile
git.el: Set the default commit coding system from the repository config.
git-archimport: support empty summaries, put summary on a single line.
http-push.c::lock_remote(): validate all remote refs.
git-cvsexportcommit: don't cleanup .msg if not yet committed to cvs.
config.mak.autogen is already there. Without this change it is not
possible to override mandir in config.mak.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If not otherwise specified, take the default coding system for commits
from the 'i18n.commitencoding' repository configuration value.
Also set the buffer-file-coding-system variable in the log buffer to
make the selected coding system visible on the modeline.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't fail if the summary line in an arch commit is empty. In this case,
try to use the first line in the commit message followed by an ellipsis.
In addition, if the summary is multi-line, it is joined on a single line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Starting from offset 11 might have been good back when it was
only used for updating "refs/heads/*", but it is used to update
"info/refs" and "refs/tags/*" as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/types:
Cleanup check_valid in commit-tree.
make sure enum object_type is signed
get rid of lookup_object_type()
convert object type handling from a string to a number
formalize typename(), and add its reverse type_from_string()
sha1_file.c: don't ignore an error condition in sha1_loose_object_info()
sha1_file.c: cleanup "offset" usage
sha1_file.c: cleanup hdr usage
Unless the -c option is given, and the commit to cvs was successful,
.msg shouldn't be deleted to be able to run the command suggested by
git-cvsexportcommit.
See http://bugs.debian.org/412732
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'js/diff-ni' (early part):
diff --no-index: also imitate the exit status of diff(1)
Fix typo: do not show name1 when name2 fails
Teach git-diff-files the new option `--no-index`
run_diff_{files,index}(): update calling convention.
update-index: do not die too early in a read-only repository.
git-status: do not be totally useless in a read-only repository.
* maint:
builtin-fmt-merge-msg: fix bugs in --file option
index-pack: Loop over pread until data loading is complete.
blameview: Fix the browse behavior in blameview
Fix minor typos/grammar in user-manual.txt
Correct ordering in git-cvsimport's option documentation
git-show: Reject native ref
Fix git-show man page formatting in the EXAMPLES section
A filesystem might not be able to completely supply our pread
request in one system call, such as if we are reading data from a
network file system and the requested length is just simply huge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This routine should be using the object_type enum rather than a
string comparsion, as the expected type is always supplied and is
known at compile time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows for keeping the common idiom which consists of using
negative values to signal error conditions by ensuring that the enum
will be a signed type.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A pair of commits on January 8th added option documentation (for -a,
-S and -L) in the middle of the documentation for the -A option. This
makes -A's documentation contiguous again.
Signed-off-by: Michael Poole <mdpoole@troilus.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, show_date() can print three different kinds of dates: normal,
relative and short (%Y-%m-%s) dates.
To achieve this, the "int relative" was changed to "enum date_mode
mode", which has three states: DATE_NORMAL, DATE_RELATIVE and
DATE_SHORT.
Since existing users of show_date() only call it with relative_date
being either 0 or 1, and DATE_NORMAL and DATE_RELATIVE having these
values, no behaviour is changed.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, it returns the current column, does not add a newline, and you can
pass a negative indent, to indicate that the indent was already printed.
With this, you can actually continue in the middle of a paragraph, not
having to print everything into a buffer first.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
So when we do
git show v1.4.4..v1.5.0
that's an illogical thing to do, since "git show" is defined to be a
non-revision-walking action, which means the range operator be pointless
and wrong. The fact that we happily accept it (and then _only_ show
v1.5.0, which is the positive end of the range) is quite arguably not very
logical.
We should complain, and say that you can only do "no_walk" with positive
refs. Negative object refs really don't make any sense unless you walk
the obejct list (or you're "git diff" and know about ranges explicitly).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The config option gitcvs.allbinary may be set to force all entries to
get the -kb flag.
In the future the gitattributes system will probably be a more
appropriate way of doing this, but that will easily slot in as the
entries lines sent to the CVS client now have their kopts set via the
function kopts_from_path().
In the interim it might be better to not just have a all-or-nothing
approach, but rather detect based on file extension (or file contents?).
That would slot in easily here as well. However, I personally prefer
everything to be binary-safe, so I just switch the switch.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The commithash for updating the ref is obtained from a call to
git-commit-tree. However, it was returned (and stored) with the
trailing newline. This meant that the later call to git-update-ref that
was trying to update to $commithash was including the newline in the
parameter - obviously that hash would never exist, and so git-update-ref
would always fail.
The solution is to chomp() the commithash as soon as it is returned by
git-commit-tree.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "ci" codepath lockless by following the usual
"remember the tip, do your thing, then compare and swap at the
end" update pattern using update-ref. Incidentally, by updating
the code that reads where the tip of the head is to use
show-ref, it makes it safe to use in a repository whose refs are
pack-pruned.
I noticed that other parts of the program are not yet pack-refs
safe, but tried to keep the changes to the minimum.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix asciidoc markup so that the man page is properly formatted in the
EXAMPLES section.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* np/types: (253 commits)
get rid of lookup_object_type()
convert object type handling from a string to a number
formalize typename(), and add its reverse type_from_string()
sha1_file.c: don't ignore an error condition in sha1_loose_object_info()
sha1_file.c: cleanup "offset" usage
sha1_file.c: cleanup hdr usage
git-apply: do not fix whitespaces on context lines.
diff --cc: integer overflow given a 2GB-or-larger file
mailinfo: do not get confused with logical lines that are too long.
Documentation: link in 1.5.0.2 material to the top documentation page.
Documentation: document remote.<name>.tagopt
GIT 1.5.0.2
git-remote: support remotes with a dot in the name
Documentation: describe "-f/-t/-m" options to "git-remote add"
diff --cc: fix display of symlink conflicts during a merge.
merge-recursive: fix longstanding bug in merging symlinks
merge-index: fix longstanding bug in merging symlinks
diff --cached: give more sensible error message when HEAD is yet to be created.
Update tests to use test-chmtime
Add test-chmtime: a utility to change mtime on files
...
This function is called only once in the whole source tree. Let's move
its code inline instead, which is also in the spirit of removing as much
object type char arrays as possible (not that this patch does anything for
that but at least it is now a local matter).
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We currently have two parallel notation for dealing with object types
in the code: a string and a numerical value. One of them is obviously
redundent, and the most used one requires more stack space and a bunch
of strcmp() all over the place.
This is an initial step for the removal of the version using a char array
found in object reading code paths. The patch is unfortunately large but
there is no sane way to split it in smaller parts without breaking the
system.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometime typename() is used, sometimes type_names[] is accessed directly.
Let's enforce typename() all the time which allows for validating the
type.
Also let's add a function to go from a name to a type and use it instead
of manual memcpy() when appropriate.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
First there are too many offsets there and it is getting confusing.
So 'offset' is now 'curpos' to distinguish from other offsets like
'obj_offset'.
Then structures like x = foo(x, &y) are now done as y = foo(&x).
It looks more natural that the result y be returned directly and
x be passed as reference to be updated in place. This has the effect
of reducing some line length and removing a few, needing a bit less
stack space, and it even reduces the compiled code size.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let's have hdr be a simple char pointer/array when possible, and let's
reduce its storage to 32 bytes. Especially for sha1_loose_object_info()
where 128 bytes is way excessive and wastes extra CPU cycles inflating.
The object type is already restricted to 10 bytes in parse_sha1_header()
and the size, even if it is 64 bits, will fit in 20 decimal numbers. So
32 bytes is plenty.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-apply: do not fix whitespaces on context lines.
diff --cc: integer overflow given a 2GB-or-larger file
mailinfo: do not get confused with logical lines that are too long.
Internal function apply_line() is called to copy both context lines
and added lines to the output buffer, while possibly fixing the
whitespace breakages depending on --whitespace=strip settings.
However, it did its fix-up on both context lines and added lines.
This resulted in two symptoms:
(1) The number of lines reported to have been fixed up included
these context lines.
(2) However, the lines actually shown were limited to the added
lines that had whitespace breakages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Few of us use git to compare or even version-control 2GB files,
but when we do, we'll want it to work.
Reading a recent patch, I noticed two lines like this:
int len = st.st_size;
Instead of "int", that should be "size_t". Otherwise, in the
non-symlink case, with 64-bit size_t, if the file's size is 2GB,
the following xmalloc will fail:
result = xmalloc(len + 1);
trying to allocate 2^64 - 2^31 + 1 bytes (assuming sign-extension
in the int-to-size_t promotion). And even if it didn't fail, the
subsequent "result[len] = 0;" would be equivalent to an unpleasant
"result[-2147483648] = 0;"
The other nearby "int"-declared size variable, sz, should also be of
type size_t, for the same reason. If sz ever wraps around and becomes
negative, xread will corrupt memory _before_ the "result" buffer.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It basically considers all the continuation lines to be lines of their
own, and if the total line is bigger than what we can fit in it, we just
truncate the result rather than stop in the middle and then get confused
when we try to parse the "next" line (which is just the remainder of the
first line).
[jc: added test, and tightened boundary a bit per list discussion.]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mark Levedahl noticed that git-gui will let you create an empty
normal (non-merge) commit if the file state in the index is out
of whack. The case Mark was looking at was with the new autoCRLF
feature in git enabled and is actually somewhat difficult to create.
I found a different way to create an empty commit: turn on the
Trust File Modifications flag, touch a file, rescan, then move
the file into the "Changes To Be Committed" list without looking
at the file's diff. This makes git-gui think there are files
staged for commit, yet the update-index call did nothing other
than refresh the stat information for the affected file. In
this case git-gui allowed the user to make a commit that did
not actually change anything in the repository.
Creating empty commits is usually a pointless operation; rarely
does it record useful information. More often than not an empty
commit is actually an indication that the user did not properly
update their index prior to commit. We should help the user out
by detecting this possible mistake and guiding them through it,
rather than blindly recording it.
After we get the new tree name back from write-tree we compare
it to the parent commit's tree; if they are the same string and
this is a normal (non-merge, non-amend) commit then something
fishy is going on. The user is making an empty commit, but they
most likely don't want to do that. We now pop an informational
dialog and start a rescan, aborting the commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
cehteh on #git noticed that there was no way to perform a reset --hard
from within git-gui. When I pointed out this was Merge->Abort Merge
cehteh said this is not very understandable, and that most users would
never guess to try that option unless they were actually in a merge.
So Branch->Reset is now also a way to cause a reset --hard from within
the UI. Right now the confirmation dialog is the same as the one used
in Merge->Abort Merge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This code doesn't belong down in the main window UI creation,
its really part of the menu system and probably should be
located with it. I'm moving it because I could not find
the code when I was looking for it earlier today, as it was
not where I expected it to be found.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
diff sets the exit status to 0 when no changes were found, to 1
when changes were found, and 2 means error.
We imitate this to be able to use "git diff" in the test scripts.
(Actually, keeping in line with the rest of git, -1 is returned
on error, which corresponds to an exit status 255).
To find out if the diff is not empty, a member called
"found_changes" was introduced in struct diff_options, which is
set in builtin_diff() and fn_out_consume().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (201 commits)
Documentation: link in 1.5.0.2 material to the top documentation page.
Documentation: document remote.<name>.tagopt
GIT 1.5.0.2
git-remote: support remotes with a dot in the name
Documentation: describe "-f/-t/-m" options to "git-remote add"
diff --cc: fix display of symlink conflicts during a merge.
merge-recursive: fix longstanding bug in merging symlinks
merge-index: fix longstanding bug in merging symlinks
diff --cached: give more sensible error message when HEAD is yet to be created.
Update tests to use test-chmtime
Add test-chmtime: a utility to change mtime on files
Add Release Notes to prepare for 1.5.0.2
Allow arbitrary number of arguments to git-pack-objects
rerere: do not deal with symlinks.
rerere: do not skip two conflicted paths next to each other.
Don't modify CREDITS-FILE if it hasn't changed.
diff-patch: Avoid emitting double-slashes in textual patch.
Reword git-am 3-way fallback failure message.
Limit filename for format-patch
core.legacyheaders: Use the description used in RelNotes-1.5.0
...
Update config.txt with info regarding tagopt option
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
GIT 1.5.0.2
git-remote: support remotes with a dot in the name
Documentation: describe "-f/-t/-m" options to "git-remote add"
diff --cc: fix display of symlink conflicts during a merge.
[jc: the original from Pavel was limiting the variable names to only
fetch and url, but I loosened it to take valid variable names.]
[jc: cherry-picked from 'master', since people seem to be reinventing
this many times.]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git-diff-files --cc" to show conflicts during merge did not pass
the correct mode information for the working tree down, and showed
bogus combined diff.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 3af244ca added unlink(2) before running symlink(2) to
update the working tree with the merge result, but it was
unlinking a wrong path. This resulted in loss of the path
pointed by a symlink.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ancient commit e2b6a9d0 added code to pass "file modes" from
merge-index to merge-one-file, and then later commit 54dd99a1
wanted to make sure we do not end up creating a nonsense symlink
that points at a path whose name contains conflict markers.
However, nobody noticed that the code in merge-index added by
e2b6a9d0 were stripping the S_IFMT bits and the code in 54dd99a1
was meaningless. This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is not like the user said 'diff --cached HEAD', so complaining about
HEAD not being a valid commit, while technically might be correct, is
not very helpful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
test-lib:
Make sure test-chmtime has been built before starting.
t4200-rerere:
Removed non-portable date dependency and avoid touch
Avoid "test -a" which isn't portable, either
lib-git-svn:
Use test-chmtime instead of Perl one-liner to poke
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is intended to be a portable replacement for our usage
of date(1), touch(1), and Perl one-liners in tests.
Usage: test-chtime (+|=|-|=+|=-)<seconds> <file>..."
'+' increments the mtime on the files by <seconds>
'-' decrements the mtime on the files by <seconds>
'=' sets the mtime on the file to exactly <seconds>
'=+' and '=-' sets the mtime on the file to <seconds> after or
before the current time.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Add Release Notes to prepare for 1.5.0.2
Allow arbitrary number of arguments to git-pack-objects
rerere: do not deal with symlinks.
rerere: do not skip two conflicted paths next to each other.
Don't modify CREDITS-FILE if it hasn't changed.
If a repository ever gets in a situation where there are too many
packs (more than 60 or so), perhaps because of frequent use of
git-fetch -k or incremental git-repack, then it becomes impossible to
fully repack the repository with git-repack -a. That command just
dies with the cryptic message
fatal: too many internal rev-list options
This message comes from git-pack-objects, which is passed one command
line option like --unpacked=pack-<SHA1>.pack for each pack file to be
repacked. However, the current code has a static limit of 64 command
line arguments and just aborts if more arguments are passed to it.
Fix this by dynamically allocating the array of command line
arguments, and doubling the size each time it overflows.
Signed-off-by: Roland Dreier <roland@digitalvampire.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We should always avoid rewriting a built file during `make install`
if nothing has changed since `make all`. This is to help support
the typical installation process of compiling a package as yourself,
then installing it as root.
Forcing CREDITS-FILE to be always be rebuilt in the Makefile means
that CREDITS-GEN needs to check for a change and only update
CREDITS-FILE if the file content actually differs. After all,
content is king in Git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'jc/status' (early part):
run_diff_{files,index}(): update calling convention.
update-index: do not die too early in a read-only repository.
git-status: do not be totally useless in a read-only repository.
This is to resolve semantic conflict (which is not textual) that
changes the calling convention of run_diff_files() early.
To name a commit, you can now say
$ git rev-parse ':/Initial revision of "git"'
and it will return the hash of the youngest commit whose
commit message (the oneline) begins with the given prefix.
For future extension, a leading exclamation mark is treated
specially: if you want to match a commit message starting with
a '!', just repeat the exclamation mark. So, to match a commit
which starts with '!Hello World', use
$ git show ':/!!Hello World'
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
diff-patch: Avoid emitting double-slashes in textual patch.
Reword git-am 3-way fallback failure message.
Limit filename for format-patch
core.legacyheaders: Use the description used in RelNotes-1.5.0
git-show-ref --verify: Fail if called without a reference
Conflicts:
builtin-show-ref.c
diff.c
When the blobs recorded on the index lines in the patch as pre-image
blobs are not found in the repository, "git-am" punted saying
that the index line does not record anything useful. This was not
clear enough -- the index line does have something useful but the
problem was that it was not useful in _that_ repository.
Reword the message as Francis Moreau suggests.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Badly formatted commits may have very long comments. This causes
git-format-patch to fail. To avoid that, truncate the filename
to a value we believe will always work.
Err out if the patch file cannot be created.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The intent of the commit 'fetch & clone: do not output progress when
not on a tty' was to make fetching and cloning less chatty when
output was not redirected (such as in a cron job).
However, there was a serious thinko in that commit. It assumed that
the client _and_ the server got this update at the same time. But
this is obviously not the case, and therefore upload-pack died on
seeing the option "--no-progress".
This patch fixes that issue by making it a protocol option. So, until
your server is updated, you still see the progress, but once the
server has this patch, it will be quiet.
A minor issue was also fixed: when cloning, the checkout did not
heed no_progress.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It explains what it does and why, and says how to use the new format.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
builtin-show-ref.c (cmd_show_ref): Fail if called with --verify option but
without a reference.
Signed-off-by: Dmitry V. Levin <ldv@altlinux.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using do_switch:
We only need to ensure the index is clean and set to that of the
parent tree) we rely on being able to reconstruct full files
with deltas transferred over the network.
When using do_update:
We may safely unlink the index if we are fetching an entire
new tree with do_update. Having an old index (from a
previously deleted/abandoned directory) around can cause
irrelevant files to be mistakenly kept.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Clearing the pool of the previous SVN::Ra connection we have
seems to to fix mysterious connection dropping errors when
reconnecting to different paths of svn:// repositories hosted by
rubyforge.org.
Note: I'm not sure *why* this fixes things things,
but it does for me.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Several bugs caused this to fail:
* GIT_DIR was set incorrectly after entering the target directory
* Avoid double chdir-ing when clone is called with an explicit path
* create target subdirectory *before* running git-init when using
the multi-init path
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, it turns out that SVN::Ra doesn't attempt to deal with
authentication or pass the username to ssh when doing svn+ssh://
URLs
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If we are run inside a subdirectory of a working tree, we'll
chdir to the top first before touching anything. This also
prevents the accidental creation of .git directories inside
subdirectories since they need metadata.
Noticed by maio on #git
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows the user to run git-svn show-ignore on there
current HEAD without needing to remember which branch/ref they
branched from with -i. Also, find_by_url should correctly
handle cases where the URL passed to it is not valid.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since the options that affect the way metadata is handled in
git-svn, should be consistently set/unset throughout history
imported by git-svn; it makes sense to allow the user to set
certain options from the command-line that will write to the
config file when initially creating the repository.
Also, fix some formatting issues while we're updating
documentation.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This documents the 'clone' and 'rebase' commands
of git-svn. Additionaly, examples are updated
to use them instead of the lower-level 'init' and
'fetch' commands.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
These tests are very similar as the ones I used for useSvmProps
and expect the same results because both dumps were generated
from the same original repo.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svm:mirror is not useful at all for us. Parts of the old unit
test were broken and based on my misunderstanding of the
svm:mirror property.
When we read svm:source; make sure we correctly handle the '!'
in it: it is used to separate the path of the repository root
from the virtual path within the repository. We don't need
to make that distinction, honestly!
We also ensure that subdirectories are also mirrored with the
correct URL if we're using useSvmProps.
We have a new test that uses dumped repo that was really
created using SVN::Mirror to avoid ambiguities and
mis-understandings about the svm: properties.
Note: trailing whitespace in the svm.dump file is unfortunately
a reality and required by SVN; so please ignore it when applying
this patch.
Also, ensure that the -R/--remote/--svn-remote flag is always
in effect if explicitly passed via the command-line. This
allows us to track logically different mirrors sharing the
same URL (probably common with SVN::Mirror/SVK users).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is similar to useSvmProps, but far simpler in
implementation because svnsync retains a 1:1
between revision numbers and relative paths within
the repository
Config keys: svn.useSvnsyncProps
svn-remote.<repo>.useSvnsyncProps
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This feature allows users to create repositories from alternate
URLs. For example, an administrator could run git-svn on the
server locally (accessing via file://) but wish to distribute
the repository with a public http:// or svn:// URL in the
metadata so users of it will see the public URL.
Config key: svn-remote.<remote>.rewriteRoot
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having it named as 'config' prevents us from tracking a
ref named 'config', which is a huge mistake.
On the non-technical side, the word 'config' implies that
a user can freely modify it; but that's not the case
here.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* Fixed logic for renaming old .rev_db -> .rev_db.$uuid
* correctly handle manual migrations for those who decide to
start use globbing to handle branches/tags over individual
'fetch' keys
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This works similarly to 'svn update' or 'git pull' except that
it preserves linear history with 'git rebase' instead of 'git
merge' for ease of dcommit-ing with git-svn.
While we're at it, put the working_head_info() logic
into its own function and allow --fetch-all/--all for
dcommit and rebase (which will fetch all refs in the
current [svn-remote] instead of just the working one).
Note that the '-a' switch (short for --fetch-all/--all) has been
removed as it conflicts with the non-svn 'git fetch'
Signed-off-by: Eric Wong <normalperson@yhbt.net>
On newly-created repositories, 'refs/heads/master' does not
point to anything. This can be confusing to new users; so we
update 'master' to point to the last imported ref after fetching
is done.
Once 'master' is valid; we assume HEAD points to it; and if
the repository is not bare, then checkout the files if the
working tree is clean and unused.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Force the showing of the --minimize flag as an option in the
'migrate' help.
Also, fix the usage function to correctly filter out
the deprecated aliases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows users to use SVM (SVN::Mirror) to mirror a remote
repository to use dcommit to commit to the repository that SVM
was mirroring. When dcommit is used in this manner, the automatic
fetch + rebase/reset does not happen; in which case the user will
have to manually invoke svm/svk, run 'git svn fetch', and finally
'git rebase'.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The newer default value should should lower memory usage for
large fetches and also help with fetching from less reliable
servers. Previously the value was 1000 and memory usage
got a bit high on some repositories and fetching became
less reliable in some cases.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, some changes to avoid creating dead dirs under
.git/svn/. We now create all directories as late as
possible.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* avoid skipping modification-only changes in fetch
* correctly fetch when we only have branches and tags
to glob from (no fetch keys defined)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-init is now just an alias that requires -T/-t/-b;
all options that 'init' can now accept.
This will hopefully simplify usage and reduce typing.
Also, allow the --shared option in 'init' to take an optional
argument now that 'git-init --shared' supports an optional
argument.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-fetch is deprecated, "fetch -a" is easier to type
By default, fetch will fetch everything from its default
[svn-remote]; if fetch [--all|-a] is specified, then it will
fetch from all svn remotes. Refspecs on the command-line
(like git-fetch) are not supported.
Also, enable -r/--revision arguments for fetch so
users can shoot themselves in the foot^W^W^W^W^W
skip some history and do the equivalent of a shallow
clone/fetch they're not interested in.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Some of the repo-config => config renaming missed the git-svn
tests; so I'm just renaming them to be consisten with the
rest of the modern git.
Also, some of the newer tests didn't have 'poke' in them
to workaround race conditions on fast machines. This adds
places where they can _possibly_ occur; but I don't have
fast enough hardware to trigger them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Similar in spirit to the recent dcommit change, we now
look at 'HEAD' by default to look for a GIT_SVN_ID
so the user won't have to pass -i <GIT_SVN_ID> argument.
We are also more tolerant of of people passing bare remote names
as a result (just $GIT_SVN_ID without the -i)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Merge commits can be created when following certain parents,
(most notably 'R' cases) and we definitely don't want to exclude
them.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
* dcommit no longer requires the correct -i/GIT_SVN_ID option
passed to it. Since you're committing from HEAD (or another
commit that is a parent of HEAD), you'll be able to find
a commit with metadata information containing the SVN URL
that your HEAD was descended from anyways.
* I don't think dcommit ever worked for people using the
noMetadata option; so I don't think relying on metadata
is an issue.
* useSvmProps users shouldn't commit to SVN::Mirror created
repositories anyways, right?
* Users of globbing should automatically be able to commit
to paths that are not explicitly set in .git/config
Signed-off-by: Eric Wong <normalperson@yhbt.net>
A manual test that sets up a repository that looks like an SVK depot,
and then imports it to check that it looks like we mirrored the
'original' source.
There is also a minor modification to the git-svn test library shell
file which sets a variable for the subversion repository's filesystem
path.
[ew: made some of the tests stricter and more thorough]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
multi-init did not write a svn-remote.<remote>.url config
entry without a --trunk argument.
Also, The svm:mirror property is used by SVN::Mirror to track
the path of the repository that we are mirroring. We need to
append that to the source (which is (presumably) just the URL of
the repository root).
Lastly, we now look harder for svm:(source|mirror|uuid) properties
in sub and parent directories. Since our relative path could
be tweaked.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Even if nothing touched paths we care about in a fetch;
increment the maxRev like we do with rev_db since
we don't like having to run get_log on revisions we've
seen before.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We need a separate .rev_db file for each repository we're
tracking. This allows us to track the same logical path off
multiple mirrors. We preserve a symlink to the old .rev_db
(no-UUID) if we're (auto-)migrating from an old version to
preserve backwards compatibility.
Also, get rid of the uuid() wrapper since we cache UUID in our
private config, and the SVN::Ra::get_uuid() function memoizes
the return value per-connection.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Make sure we flush our userspace buffers and and fsync(2)
.rev_db information to disk if we use these options because
we really don't want to lose this information.
Also, disallow --use-svm-props and --no-metadata from the
command-line because history will be inconsistent if they're
only used occasionally. If a user wants to use these options,
they must be set in the config so they're always on.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Available options are currently:
svn-remote.<remote>.{noMetadata,useSvmProps,followParent}
These boolean switches will override options set globally in
[svn], and even override options set on the command-line (this
should probably change in the future, however).
Note that the noMetadata and useSvmProps options conflict. It's
both technically and logically impossible to use them together.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Pass --use-svm-props or set the svn.usesvmprops key with git-config
to enable using properties set by SVN::Mirror when it mirrored the
upstream URL.
This is heavily based on work from Sam Vilain:
> From: Sam Vilain <sam@vilain.net>
> Date: Sun, 11 Feb 2007 12:34:45 +1300
> Subject: [PATCH] git-svn: re-map repository URLs and UUIDs on SVK mirror paths
>
> If an SVN revision has a property, "svm:headrev", it is likely that
> the revision was created by SVN::Mirror (a part of SVK). The property
> contains a repository UUID and a revision. We want to make it look
> like we are mirroring the original URL, so introduce a helper function
> that returns the original identity URL and UUID, and use it when
> generating commit messages.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I may resurrect it for dcommit at some point, but nobody really
uses set-tree anymore and I don't feel like introducing more
complexity into the code at this point.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Several bugs were found and fixed while getting this to work:
* Remember the 'R'(eplace) case of actions and treat it like we
would an 'A'(dd) case.
* Fix a small case of follow-parent missing a parent if a
subdirectory was modified in the revision where the parent was
copied.
* dirents returned by get_dir sometimes expire if the data
structure is too big and the pool is destroyed, so we
cache get_dir (along with check_path and get_revprops)
temporarily along with its pool.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I incorrectly used $path/? and $path/* to strip off leading
directories, but places where $path = 'branches/0.17' would
incorrectly strip changes to 'branches/0.17.1' as well.
For globs, we require that our '*' is its own path component
(surrounded by '/' or nothing). Enforce this when --prefix= is
passed to us, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--no-follow-parent disables and reverts it back to the old
default behavior of not following parents (if you don't care for
full history).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We don't need them anymore, all the rough points of
the --follow-parent implementation have been worked out.
The only improvement in the future will probably be
--follow-parent-harder, which will track subdirectories and
follow individual file history (so annotate/blame can be
complete); but that is still a ways off.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
These checks were needed before git-svn got smarter about
match_paths() and using path information returned by get_log().
We also have extra checking against fetching revisions
out-of-order these days; so we don't have to worry about that as
much. We also check for tree deletions in match_paths() and
skip those as well.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We can have a branch that was deleted, then re-added under the
same name but copied from another path, in which case we'll have
multiple parents (we don't want to break the original ref, nor
lose copypath info).
Add a test for this, too, of course.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is similar to the way git proper handles refs, except we
use the keys 'branches' and 'tags' to distinguish when we want
to use wildcards.
The left-hand side of the ':' contains the remote path, and must
have one asterisk ('*') in it for the branch name. The asterisk
may be in any component of the path as long as is it on its own
directory level.
The right-hand side contains the refname and must have the
asterisk as the last path component.
branches = branches/*:refs/remotes/*
tags = tags/*:refs/remotes/tags/*
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This is an optimization that should conserve network
bandwidth on certain repositories and configurations.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It can be confusing and redundant, since historically the
default remote ref (not remote itself) has been "git-svn", too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since fetch_loop_common starts from the lowest revision number
in a group of Git::SVN objects; we want to avoid refetching
get_log for current users for things we've already cut it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This was originally needed before we used the delta fetcher and
had a less-clean follow-parent implementation that could leave
holes in the history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It looks better (like [remote "origin"]) instead of whatever
refname came up first in our directory traversal. Of course
--remote= overrides this.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having 'fetch' entries in the config file created from
--follow-parent is wasteful because it can cause *future* of
invocations to follow revisions we were never interested in
in the first place.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Using buffered IO for reading 40-41 bytes at a time isn't very
efficient. Buffering writes for a short duration is alright
since we close() right away and buffers will be flushed.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Prefill .rev_db to the maximum revision we tried to fetch;
and take advantage of that so we can avoid using get_log()
on ranges we've already seen (and have deemed uninteresting).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Defer any signals that cause termination while they are
updating; and put the update-ref call as close to the rename()
as possible. Also, make things extra-safe (but slower) for
people using --no-metadata since they can't rely on .rev_db
being rebuilt if it's clobbered (well, I'm calling update-ref
with the -m flag for reflogs, we don't yet have a way to rebuild
.rev_db from reflogs.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Passing very large strings as arguments is bad for memory usage
as it never seems to get freed in Perl. The .rev_db format is
already not optimized for projects with sparse history.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
get_log with explicit paths is the safest way to get revisions
that change a particular path we're interested in.
Unfortunately that means we still have to run get_log multiple
times for each path we're interested in, and even more if
a path gets deleted.
The first argument of get_log() is an array reference, but we
shouldn't use more than one element in that array ref because
the non-existence of _one_ of those paths for a particular range
would cause an error for all paths in that range, so yes, we
need multiple get_log calls to be on the safe side...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--svn-remote allows the default remote name to be overridden (useful
for tracking multiple SVN repositories).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We no longer delete the top-level directory even if it got
deleted from the upstream repository. In gs_do_update; we
double-check that the path we're tracking exists at both
endpoints before proceeding. We have also added additional
protection against fetching revisions out-of-order.
To simplify our internal interfaces, I've disabled passing the
'recursive' flag to the gs_do_{switch,update} wrapper functions
since we always want it in git-svn. We also pass the
entire Git::SVN object rather than just the path because it
helped me debug.
When printing progress, the refname is printed out to make
it less confusing when multi-fetch is running.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since refs/remotes/* are not automatically cloned, we expect the
user to be capable of copying those references themselves
anyways.
Also removed the documentation for --ignore-nodate while we're
at it; it has also been made automatic.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We were still skipping path information from get_log if we are
tracking /r9270/drunk/subversion/bindings/..., but got something
like this in the log:
A /r9270/drunk (from /r9270/trunk:14)
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I can't seem to figure out what I or the SVN libraries are doing
wrong, but it appears to be related to reparent and probably
some global structure that gets reset if multiple SVN
connections are being used.
So now, in order to use do_switch; we'll open a new connection
to the repository with the complete URL; but we can't seem to
ever use an existing Ra object after another one has been
created...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We don't need our own error handler for other operations. Also
add a message about the successfully do_switch or do_update in
follow-parent for debugging do_switch failures with svn:// and
svn+ssh:// connections.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Historically, git-svn did not always use Digest::MD5 because
it did not use the SVN::Delta::Editor interfaces. Nowadays
it does, and the requires make strace more noisy.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Using path names as refnames breaks horribly if a user is
tracking one large, toplevel directory, and a lower-level
directory is followed from another project is a parent
of another ref, as it will cause refnames such as:
'refs/remotes/trunk/path/to/stuff', which will conflict
with a refname of 'refs/remotes/trunk'.
Now we just append @$revno to the end of it the current
refname. And if we have followed back to a grandparent, then
we'll strip any existing '@$parent_revno' strings before
appending our own '@$revno' string to it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The do_update or do_switch functions in SVN only allow for a
single path component; so 'path/to/deep/dir' would be
interpreted as 'path'.
SVN 1.4.x has a reparent function that can let us change the
session to use a higher-level root of the repository, so we can
use that for do_switch (which still doesn't seem to work in SVN
1.4.3 (a fix was attempted, but they missed the rest of the
typemap changes needed in trunk...)).
On the do_update side, we can use set_path on higher level
directories and set them to a newer revision so they don't get
updated. We can't do this with do_switch, either, because the
relative path we're tracking can change (directory moving into
a child of itself).
Because of these changes, we need to double check that our Fetch
editor is correctly performing stripping on any prefixed paths
from update, otherwise we'll just die() because that would be
a bug.
Added a test case which helped me notice and fix problems with
do_switch, too.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, this should allow for the tracking of new, but empty
directories where we would want to see the log message.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Since single fetching is a special case of multi-fetch,
share code with it and the fetch loop into Git::SVN::Ra
since it uses a single Ra connection and multiple
Git::SVN objects.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Before, we needed a separate svn_ra instance to run
our check_path calls once the editor was active; but
we can avoid that by running all the check_path calls
before our editor is active.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I broke this part with the URL minimization; since
git-svn will now try to connect to the root of
the repository and will end up writing files
there if it can...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
svn_log_changed_path_t structs were being used out of scope
outside of svn_ra_get_log (because I wanted to eventually be
able to use git-svn with only a single connection to the
repository). So now we dup them into a hash.
This was fixed while making --follow-parent fetches more
efficient. I've moved parsing of the command-line --revision
argument outside of the Git::SVN module so Git::SVN::fetch() can
be used in more places (such as find_parent_branch).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
git-svn has never been able to handle deleted branches very well
because svn_ra_get_log() is all-or-nothing, meaning that if the
max revision passed to it does not contain the path we're
tracking, we miss all the revisions in the repository.
Branches fetched using --follow-parent still do this
sub-optimally (will be fixed soon). --follow-parent will soon
become the default, so we will assume that when using get_log();
We will also avoid tracking revprops for revisions with no
path-related changes since otherwise we just end up pulling
logs to paths we don't care about.
Also added a test for this to t9104-git-svn-follow-parent.sh and
correctly commit the log message in the preceeding test (which
conflicted with a filename).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
They simply aren't interesting to track, and this will allow
us to avoid get_log().
Since r0 is covered by this, we need to update the tests to not
rely on r0 (which is always empty).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Introducing Git::IndexInfo. This module will probably be useful
outside of git-svn, so I'm not putting it in the Git::SVN
namespace.
This will allow me to more easily avoid the use of get_log() in
the future and simply run do_update in incrementing ranges.
get_log() should be avoided because there are cases where
moved/deleted directories do not track correctly (until
--follow-parent is run on a new branch).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This means that tracking the path of:
/another-larger/trunk/thunk/bump/thud inside a repository
would follow:
/larger-parent/trunk/thunk/bump/thud
even if the svn log output looks like this:
--------------------------------------------
Changed paths:
A /another-larger (from /larger-parent:5)
--------------------------------------------
Note: the usage of get_log() in git-svn still makes a
an assumption that shouldn't be made with regard to
revisions existing for a particular path.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This allows connections to be used more efficiently and not require
users to run 'git-svn migrate --minimize' for new repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Tests always ran 'git init' before we ran so that repo-config
would always have something to read. However that does not work
in real-world situations where the user expects 'git svn init'
to work without running 'git init' first.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It's not really useful anymore now that we have a better
--follow-parent for the valid cases. Any other use
of it is not valid.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Having multiple fetch refspecs pointing to the same local ref
would be a very bad thing. Start avoiding the use of fatal() or
exit() inside the modules so we can libify more easily.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Bugs fixed:
* We didn't allow manually (not using git-svn) init-ed
remotes/fetch refspecs to be used before. It works now
because that's what I did in this test. git-svn init should
offer more control in the future.
* correctly strip paths in the delta editor when using
do_switch().
* Make the -i / GIT_SVN_ID option work correctly when doing
fetch on a multi-ref svn-remote
Signed-off-by: Eric Wong <normalperson@yhbt.net>
--minimize will update the git-svn configuration to attempt to
connect to the repository root (instead of directly to the
path(s) we are tracking) in order to allow more efficient reuse
of connections (for multi-fetch and follow-parent).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Note: this can cause problems with Perl's reference counting GC,
so I'm disabling Git::SVN::Ra::DESTROY. If we notice more
problems down the line, we can disable this enhancement.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Of course, we handle metadata migrations from previous versions
and we have added unit tests.
The new .git/config remotes resemble non-SVN remotes. Below
is an example with comments:
[svn-remote "git-svn"]
; like non-svn remotes, we have one URL per-remote
url = http://foo.bar.org/svn
; 'fetch' keys are done in the same way as non-svn
; remotes, too. With the left-hand-side of the ':'
; being the remote (SVN) repository path relative to the
; above 'url' key; and the right-hand-side being a
; remote ref in git (refs/remotes/*).
; An empty left-hand-side means that it will fetch
; the entire contents of the 'url' key.
; old-style (migrated from previous versions of git-svn)
; are like this:
fetch = :refs/remotes/git-svn
; this is created by a current version of git-svn
; using the multi-init command with an explicit
; url (specified above). This allows multi-init
; to reuse SVN::Ra connections.
fetch = trunk:refs/remotes/trunk
fetch = branches/a:refs/remotes/a
fetch = branches/b:refs/remotes/b
fetch = tags/0.1:refs/remotes/tags/0.1
fetch = tags/0.2:refs/remotes/tags/0.2
fetch = tags/0.3:refs/remotes/tags/0.3
[svn-remote "alt"]
; this is another old-style remote migrated over
; to the new config format
url = http://foo.bar.org/alt
fetch = :refs/remotes/alt
Signed-off-by: Eric Wong <normalperson@yhbt.net>
It's becoming a maintenance burden. I've never found it
particularly useful myself, nor have I heard much feedback about
it; so I'm assuming it's just as useless to everyone else.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Also, convert all usage of 'log_msg' to 'log_entry' for
consistency's sake
SVN::Git::Editor::apply_diff now drives the rest of the
editor.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
More cleanup to separate out functionality and make things
nicer to hack on.
While we're at it, centralize loading of the authors into
one place and correctly handle '(no author)' cases in
when showing logs after-the-fact; and not just at commit
time.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
If a user specified a seperate URL and --tags/--branches as
a sepearte URL, allow the Ra object (and therefore the connection)
to be reused.
We'll get rid of libsvn_ls_fullurl() since it was only used
in one place.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
I will be using functions from Git.pm in more modules, so I
want to avoid re-importing the long argument list everywhere
it's used.
Also removed an unused command-line switch
(--no-ignore-externals) and some variables.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Force some svn_ra functions to use a temporary pool via wrapper
This cleans up the code a bit by removing explicit instances of
pool allocation and deallocation and providing wrapper functions
that make use of temporary pools.
I've also added an explicit pool usage when creating the commit
editor for commit-diff where get_commit_editor can be called
multiple times with the same pool previously.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We can use the revision walker easily for checking if the
prerequisites are met, instead of fork()ing off a rev-list,
which would list only the first unmet prerequisite.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch fixes issues mentioned by Junio, Nico and Simon:
- I forgot to convert the usage string when removing the "--" from
the subcommands,
- a style fix in the bundle_header,
- use xread() instead of read(),
- use write_or_die() instead of write(),
- make the bundle header extensible,
- fail if the whitespace after a sha1 of a reference is missing,
- close() the fds passed to a subprocess,
- in verify_bundle(), do not use "rev-list --stdin", but rather
pass the revs directly (avoiding a fork()),
- fix a corrupted comment in show_object(), and
- fix the size check in index_pack.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some workflows require use of repositories on machines that cannot be
connected, preventing use of git-fetch / git-push to transport objects and
references between the repositories.
git-bundle provides an alternate transport mechanism, effectively allowing
git-fetch and git-pull to operate using sneakernet transport. `git-bundle
create` allows the user to create a bundle containing one or more branches
or tags, but with specified basis assumed to exist on the target
repository. At the receiving end, git-bundle acts like git-fetch-pack,
allowing the user to invoke git-fetch or git-pull using the bundle file as
the URL. git-fetch and git-ls-remote determine they have a bundle URL by
checking that the URL points to a file, but are otherwise unchanged in
operation with bundles.
The original patch was done by Mark Levedahl <mdl123@verizon.net>.
It was updated to make git-bundle a builtin, and get rid of the tar
format: now, the first line is supposed to say "# v2 git bundle", the next
lines either contain a prerequisite ("-" followed by the hash of the
needed commit), or a ref (the hash of a commit, followed by the name of
the ref), and finally the pack. As a result, the bundle argument can be
"-" now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was done by setting $HOME to somewhere bogus. A better method is
to reuse $GIT_CONFIG, which was invented for ignoring the global
config file explicitely.
Technically, setting GIT_CONFIG=.git/config could be wrong, but it
passes all the tests, and we can keep the tests that way.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* lt/crlf:
Teach core.autocrlf to 'git apply'
t0020: add test for auto-crlf
Make AutoCRLF ternary variable.
Lazy man's auto-CRLF
* jc/apply-config:
t4119: test autocomputing -p<n> for traditional diff input.
git-apply: guess correct -p<n> value for non-git patches.
git-apply: notice "diff --git" patch again
Fix botched "leak fix"
t4119: add test for traditional patch and different p_value
apply: fix memory leak in prefix_one()
git-apply: require -p<n> when working in a subdirectory.
git-apply: do not lose cwd when run from a subdirectory.
Teach 'git apply' to look at $HOME/.gitconfig even outside of a repository
Teach 'git apply' to look at $GIT_DIR/config
* maint:
git-diff: fix combined diff
Fix 'git commit -a' in a newly initialized repository
Include git-gui credits file in dist.
Document the new core.bare configuration option.
The code forgets that typecast binds tighter than addition, in
other words:
(cast *)array + i === ((cast *)array) + i
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch,
$ git show -s \
--pretty=format:' Ze komit %h woss%n dunn buy ze great %an'
shows something like
Ze komit 04c5c88 woss
dunn buy ze great Junio C Hamano
The supported placeholders are:
'%H': commit hash
'%h': abbreviated commit hash
'%T': tree hash
'%t': abbreviated tree hash
'%P': parent hashes
'%p': abbreviated parent hashes
'%an': author name
'%ae': author email
'%ad': author date
'%aD': author date, RFC2822 style
'%ar': author date, relative
'%at': author date, UNIX timestamp
'%cn': committer name
'%ce': committer email
'%cd': committer date
'%cD': committer date, RFC2822 style
'%cr': committer date, relative
'%ct': committer date, UNIX timestamp
'%e': encoding
'%s': subject
'%b': body
'%Cred': switch color to red
'%Cgreen': switch color to green
'%Cblue': switch color to blue
'%Creset': reset color
'%n': newline
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With current git:
$ git init
$ git commit -a
cp: cannot stat `.git/index': No such file or directory
Output a nice error message instead.
Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this flag and given two paths, git-diff-files behaves as a GNU diff
lookalike (plus the git goodies like --check, colour, etc.). This flag
is also available in git-diff. It also works outside of a git repository.
In addition, if git-diff{,-files} is called without revision or stage
parameter, and with exactly two paths at least one of which is not tracked,
the default is --no-index.
So, you can now say
git diff /etc/inittab /etc/fstab
and it actually works!
This also unifies the duplicated argument parsing between cmd_diff_files()
and builtin_diff_files().
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a patch fails, I automatically add '-v' to the command line
to see what fails.
This patch makes -v a synonym to --verbose, and actually tells
the user which text was not found.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This delays the error exit from hold_lock_file_for_update() in
update-index, so that "update-index --refresh" in a read-only
repository can still report what paths are stat-dirty before
exiting.
Also it makes -q to squelch the error message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-status work semi-decently in a read-only
repository. Earlier, the command simply died with "cannot lock
the index file" before giving any useful information to the
user.
Because index won't be updated in a read-only repository,
stat-dirty paths appear in the "Changed but not updated" list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The Makefile for the git-gui subproject will fail to execute if run
outside of a git.git directory, such as when building from a .tar.gz
or .tar.bz2. This is because it is looking for the credits file,
which was created but omitted from the tarball by the toplevel
Makefile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This enhances the third point in the previous commit. When
applying a non-git patch that begins like this:
--- 2.6.orig/mm/slab.c
+++ 2.6/mm/slab.c
@@ -N,M +L,K @@@
...
and if you are in 'mm' subdirectory, we notice that -p2 is the
right option to use to apply the patch in file slab.c in the
current directory (i.e. mm/slab.c)
The guess function also knows about this pattern, where you
would need to use -p0 if applying from the top-level:
--- mm/slab.c
+++ mm/slab.c
@@ -N,M +L,K @@@
...
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier one that tried to be too consistent with GNU patch by
not stripping the leading path when we _know_ we are in a
subdirectory and the patch is relative to the toplevel was a
mistake. This fixes it.
- No change to behaviour when it is run from the toplevel of
the repository.
- When run from a subdirectory to apply a git-generated patch,
it uses the right -p<n> value automatically, with or without
--index nor --cached option.
- When run from a subdirectory to apply a randomly generated
patch, it wants the right -p<n> value to be given by the
user.
The second one is a pure improvement to correct inconsistency
between --index and non --index case, compared with 1.5.0. The
third point could be further improved to guess what the right
value for -p<n> should be by looking at the patch, but should be
a topic of a separate patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Use gunzip -c over gzcat in import-tars example.
git-gui: Don't crash in citool mode on initial commit.
git-gui: Remove TODO list.
git-gui: Include browser in our usage message.
git-gui: Change summary of git-gui.
git-gui: Display all authors of git-gui.
git-gui: Use mixed path for docs on Cygwin.
git-gui: Correct crash when saving options in blame mode.
git-gui: Expose the browser as a subcommand.
git-gui: Create new branches from a tag.
git-gui: Prefer version file over git-describe.
git-gui: Print version on the console.
git-gui: More consistently display the application name.
git-gui: Permit merging tags into the current branch.
git-gui: Basic version check to ensure git 1.5.0 or later is used.
git-gui: Refactor 'exec git subcmd' idiom.
* 'master' of git://repo.or.cz/git-gui:
git-gui: Don't crash in citool mode on initial commit.
git-gui: Remove TODO list.
git-gui: Include browser in our usage message.
git-gui: Change summary of git-gui.
git-gui: Display all authors of git-gui.
git-gui: Use mixed path for docs on Cygwin.
git-gui: Correct crash when saving options in blame mode.
git-gui: Expose the browser as a subcommand.
git-gui: Create new branches from a tag.
git-gui: Prefer version file over git-describe.
git-gui: Print version on the console.
git-gui: More consistently display the application name.
git-gui: Permit merging tags into the current branch.
git-gui: Basic version check to ensure git 1.5.0 or later is used.
git-gui: Refactor 'exec git subcmd' idiom.
Not everyone has gzcat or bzcat installed on their system, but
gunzip -c and bunzip2 -c perform the same task and are available
if the user has installed gzip support or bzip2 support.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When (new_name == old_name), the previous one prefixed old_name
alone, leaving new_name untouched, and worse yet, left it
dangling pointing at an already freed memory location.
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: the original from Pavel was limiting the variable names to only
fetch and url, but I loosened it to take valid variable names.]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Matthias Lederhofer noticed that `diff -B` did not pick up on diff
colournig.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In response to a feature request from Shawn Pearce, this patch allows
a user to update a named group of remotes by using "git remote update
<group>", where the group is defined in the config file by
remotes.<group>. The default if the named group is not specified is
now fetched group remotes.default, instead of remote.fetch, which is
what had been previously used.
In addition, if remotes.default is not defined, all remotes defined in
the config file will be used, as before, but there is now also
possible to request that a particular repository to be skipped by
default by using the boolean configuration parameter
remote.<name>.skipDefaultUpdate.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is necessary if using CVS in an asymmetric fashion, i.e. when the
CVSROOT you are checking out from differs from the CVSROOT you have to
commit to.
Signed-off-by: Simon 'corecode' Schubert <corecode@fs.ei.tum.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Glibc uses the same size for int and off_t by default.
In order to support large pack sizes (>2GB) we force Glibc to a 64bit off_t.
Signed-off-by: Martin Waitz <tali@admingilde.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Attempting to use `git citool` to create an initial commit caused
git-gui to crash with a Tcl error as it tried to add the newly
born branch to the non-existant branch menu. Moving this code
to after the normal commit cleanup logic resolves the issue, as
we only have a branch menu if we are not in singlecommit mode.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm apparently not very good at keeping my own TODO file current.
I its also somewhat strange to keep the TODO list as part of the
software branch, as its meta-information that is not directly
related to the code. I'm pulling the TODO list from git-gui and
moving it into a seperate branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that the 'browser' subcommand can be used to startup the tree
browser, it should be listed as a possible subcommand option in
our usage message.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There were instances of strncmp() that were formatted improperly
(e.g. whitespace around parameter before closing parenthesis)
that caused the earlier mechanical conversion step to miss
them. This step cleans them up.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previous step converted use of strncmp() with literal string
mechanically even when the result is only used as a boolean:
if (!strncmp("foo", arg, 3)) ==> if (!(-prefixcmp(arg, "foo")))
This step manually cleans them up to read:
if (!prefixcmp(arg, "foo"))
Signed-off-by: Junio C Hamano <junkio@cox.net>
This mechanically converts strncmp() to use prefixcmp(), but only when
the parameters match specific patterns, so that they can be verified
easily. Leftover from this will be fixed in a separate step, including
idiotic conversions like
if (!strncmp("foo", arg, 3))
=>
if (!(-prefixcmp(arg, "foo")))
This was done by using this script in px.perl
#!/usr/bin/perl -i.bak -p
if (/strncmp\(([^,]+), "([^\\"]*)", (\d+)\)/ && (length($2) == $3)) {
s|strncmp\(([^,]+), "([^\\"]*)", (\d+)\)|prefixcmp($1, "$2")|;
}
if (/strncmp\("([^\\"]*)", ([^,]+), (\d+)\)/ && (length($1) == $3)) {
s|strncmp\("([^\\"]*)", ([^,]+), (\d+)\)|(-prefixcmp($2, "$1"))|;
}
and running:
$ git grep -l strncmp -- '*.c' | xargs perl px.perl
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since git-gui does more than create commits, it is unfair to call
it "a commit creation tool". Instead lets just call it a graphical
user interface.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that git-gui has been released to the public as part of Git 1.5.0
I am starting to see some work from other people beyond myself and
Paul. Consequently the copyright for git-gui is not strictly the
two of us anymore, and these others deserve to have some credit
given to them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Firefox browser requires that a URL use / to delimit directories.
This is instead of \, as \ gets escaped by the browser into its hex
escape code and then relative URLs are incorrectly resolved, Firefox
no longer sees the directories for what they are. Since we are
handing the browser a true URL, we better use the standard / for
directories.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Thanks to Simon 'corecode' Schubert <corecode@fs.ei.tum.de> for
the clean-up. Defining the C99 standard PRIuMAX when necessary
replaces UM_FMT and the awkward UM10_FMT. There are no direct
C99 translations for other uses of NO_C99_FORMAT in git, alas.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The settings in /etc/gitconfig can be overridden in ~/.gitconfig,
which in turn can be overridden in .git/config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the option "--no-progress" to fetch-pack and upload-pack,
and makes fetch and clone pass this option when stdout is not a tty.
While at documenting that option, also document --strict and --timeout
options for upload-pack.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, when saying --max-age=<timestamp>, or --max-count=<n>, together
with --boundary, rev-list prints the boundary commits, i.e. the
commits which are _just_ not shown without --boundary, i.e. their
children are, but they aren't.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When naming by a tag, we used to add "^0" even if this was not really
necessary. For example, `git name-rev de6f0def` now outputs
de6f0def tags/v1.5.0.1~9
instead of
de6f0def tags/v1.5.0.1^0~9
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-apply running inside a subdirectory, with or without --index,
used to always assume that the patch is formatted in such a way
to apply with -p1 from the toplevel, but it is more useful and
consistent with the use of "GNU patch -p1" if it defaulted to
assume that its input is meant to apply at the level it is
invoked in.
This changes the behaviour. It used to be that the patch
generated this way would apply without any trick:
edit Documentation/Makefile
git diff >patch.file
cd Documentation
git apply ../patch.file
You need to give an explicit -p2 to git-apply now. On the other
hand, if you got a patch from somebody else who did not follow
"patch is to apply from the top with -p1" convention, the input
patch would start with:
diff -u Makefile.old Makefile
--- Makefile.old
+++ Makefile
and in such a case, you can apply it with:
git apply -p0 patch.file
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a patch modifies (not deletes) the last file in a
directory, because we treat a modification just as deletion
followed by creation, and deleting the last file in a directory
automatically rmdir(2)'s that directory, we ended up removing
the directory, which can potentially be the cwd, and then
recreating the same directory to create the patch result.
Avoid the rmdir step when remove_file() is called only because
we are replacing it with the result by later calling
create_file().
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows users to use the command "git remote update" to update all
remotes that are being tracked in the repository.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Define UM_FMT and UM10_FMT and use in place of %ju and %10ju,
respectively. Both format as unsigned long long, so this
assumes the compiler supports long long.
Signed-off-by: Jason Riedy <jason@acm.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Solaris 8 was pre-c99, and they weren't willing to commit to
the strtoumax definition according to /usr/include/inttypes.h.
This adds NO_STRTOUMAX and NO_STRTOULL for ancient systems.
If NO_STRTOUMAX is defined, the routine in compat/strtoumax.c
will be used instead. That routine passes its arguments to
strtoull unless NO_STRTOULL is defined. If NO_STRTOULL, then
the routine uses strtoul (unsigned long).
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu>
Acked-by: Shawn O Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation advertises the new `--depth <n>' parameter with an equal
sign, while the usage notes (shown after `git-clone --help') do not. If I
understood git-clone's source code correctly, the version without the
equal sign is correct, which is why this patch syncs documentation to the
usage note.
Signed-off-by: Christian Schlotter <schlotter@users.sourceforge.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise "git rev-list --header HEAD" will not do the right
thing if i18n.commitencoding is set.
Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On a Solaris machine I have access to libc contains the symbol
"iconv" but, when compiling with gcc and including iconv.h we get
iconv.h from GNU libiconv. This header file define (among other
things) "iconv" to "libiconv" and so on.
In order to link with GNU libiconv we need -liconv. Currently we
test if the symbol "iconv" is in libc (which is true), then we get
a undefined reference error because we don't have libiconv_open.
The solution this patch implements is to compile and link a
small test program, instead of just checking if the libraries
(libc and libiconv) contains the symbol "iconv".
Signed-off-by: Fredrik Kuivinen <frekui@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Martin Waitz noticed that git-gui crashed while saving the user's
options out if the application was started in blame mode. This
was caused by the do_save_config procedure invoking reshow_diff
incase the number of context lines was modified by the user.
Because we bypassed main window UI setup to enter blame mode we
did not set many of the globals which were accessed by reshow_diff,
and reading unset variables is an error in Tcl.
Aside from moving the globals to be set earlier, I also modified
reshow_diff to not invoke clear_diff if there is no path currently
in the diff viewer. This way reshow_diff does not crash when in
blame mode due to the $ui_diff command not being defined.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Update draft release notes for 1.5.0.1
Convert update-index references in docs to add.
Attempt to improve git-rebase lead-in description.
Do not take mode bits from index after type change.
git-blame: prevent argument parsing segfault
Make gitk save and restore window pane position on Linux and Cygwin.
Make gitk save and restore the user set window position.
[PATCH] gitk: Use show-ref instead of ls-remote
[PATCH] Make gitk work reasonably well on Cygwin.
[PATCH] gitk - remove trailing whitespace from a few lines.
Change git repo-config to git config
* git://git.kernel.org/pub/scm/gitk/gitk:
Make gitk save and restore window pane position on Linux and Cygwin.
Make gitk save and restore the user set window position.
[PATCH] gitk: Use show-ref instead of ls-remote
[PATCH] Make gitk work reasonably well on Cygwin.
[PATCH] gitk - remove trailing whitespace from a few lines.
Change git repo-config to git config
This teaches git-apply that the data read from and written to
the filesystem might need to get converted to adjust for local
line-ending convention.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When neither --index nor --cached was used, git-apply did not
try calling setup_git_directory(), which means it did not look
at configuration files at all. This fixes it to call the setup
function but still allow the command to be run in a directory
not controlled by git.
The bug probably meant that 'git apply', not moving up to the
toplevel, did not apply properly formatted diffs from the
toplevel when you are inside a subdirectory, even though 'git
apply --index' would. As a side effect, this patch fixes it as
well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of (or, in addition to) --tags, to use only tags for naming,
you can now use --refs=<pattern> to specify a shell glob pattern
which the refs must match to be used for naming.
Example:
$ git name-rev --refs=*v1* 33db5f4d33db5f4d tags/v1.0rc1^0~1593
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since `git add` is the approved porcelain for an end-user to invoke
when they want to manipulate the index, porcelain documentation
should steer the user to this command rather than the pure plumbing
update-index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was mentioned on #git this morning that the lead-in description
of git-rebase is very confusing. Too many branch this and branch
that in a very short run of text.
This new description attempts to walk the user through the command
syntax, while also describing exactly what git-rebase is doing to
their repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we do not trust executable bit from lstat(2), we copied
existing ce_mode bits without checking if the filesystem object
is a regular file (which is the only thing we apply the "trust
executable bit" business) nor if the blob in the index is a
regular file (otherwise, we should do the same as registering a
new regular file, which is to default non-executable).
Noticed by Johannes Sixt.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 3rd branch in builtin-blame.c should also check for lacking
arguments. Running that in top dir does not trigger the problem
because the 'prefix' is NULL.
Signed-off-by: Tommi Kyntola <tommi.kyntola@ray.fi>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The shell loop to determine if we should skip the trivial
in-index merge stage based on what strategy is given was not
prepared to have more than one strategy listed in the variable
$no_trivial_merge_strategies.
This does not trigger unless you use a modified git but the fix
is simple and straightforward, so let's fix it before 1.5.0.1.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some users may find being able to browse around an arbitrary
branch to be handy, so we now expose our graphical browser
through `git gui browse <committish>`.
Yes, I'm being somewhat lazy and making the user give us
the name of the branch to browse. They can always enter
HEAD.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
With a configuration entry like this:
[remote "alt-git"]
url = git://repo.or.cz/alt.git/git/
fetch = +refs/heads/*:refs/remotes/alt-git/*
tagopt = --no-tags
you do not have to say "git pull --no-tags alt-git". Just
saying "git pull alt-git" would suffice.
Obviously, if you want to get the tag from such an alternate
remote in a separate namespace, you could also do something like:
[remote "alt-git"]
url = git://repo.or.cz/alt.git/git/
fetch = +refs/heads/*:refs/remotes/alt-git/*
fetch = +refs/tags/*:refs/remote-tags/alt-git/*
tagopt = --no-tags
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm missing the possibility to base a new branch on a tag.
The following adds a tag drop down to the new branch dialog.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
GIT-VERSION-FILE: check ./version first.
sha1_file.c: Round the mmap offset to half the window size.
Make sure packedgitwindowsize is multiple of (pagesize * 2)
Add RelNotes 1.5.0.1
Still updating 1.5.0 release notes.
git-daemon: Avoid leaking the listening sockets into child processes.
Clarify two backward incompatible repository options.
When somebody else extracts git tarball inside a larger project,
'git describe' would reported the version number of that upper
level project.
Sometimes, using the consistent versioning across subdirectories
of a larger project is useful, but it may not always be the
right thing to do.
This changes the script to check ./vertion file first, and then
fall back to "git describe". This way, by default, tarball
distribution will get our own version. If the upper level wants
to use consistent versioning across its subdirectories, its
Makefile can overwrite ./version file to force whatever version
number they want to give us before descending into us.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This ensures that a given area is mapped at most twice, and greatly
reduces the virtual address space usage.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This tests lowlevel of update/checkout codepaths and some patch
application. Currently, variants of "git apply" that look at
the working tree files does not work, so it does not test the
patch application without parameter and with --index parameter
when autocrlf is set to produce CRLF files.
We should add test for diff generation too.
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>
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>
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>
Signed-off-by: Paul Mackerras <paulus@samba.org>
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>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This allows you to do:
[core]
AutoCRLF = input
and it should do only the CRLF->LF translation (ie it simplifies CRLF only
when reading working tree files, but when checking out files, it leaves
the LF alone, and doesn't turn it into a CRLF).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It currently does NOT know about file attributes, so it does its
conversion purely based on content. Maybe that is more in the "git
philosophy" anyway, since content is king, but I think we should try to do
the file attributes to turn it off on demand.
Anyway, BY DEFAULT it is off regardless, because it requires a
[core]
AutoCRLF = true
in your config file to be enabled. We could make that the default for
Windows, of course, the same way we do some other things (filemode etc).
But you can actually enable it on UNIX, and it will cause:
- "git update-index" will write blobs without CRLF
- "git diff" will diff working tree files without CRLF
- "git checkout" will write files to the working tree _with_ CRLF
and things work fine.
Funnily, it actually shows an odd file in git itself:
git clone -n git test-crlf
cd test-crlf
git config core.autocrlf true
git checkout
git diff
shows a diff for "Documentation/docbook-xsl.css". Why? Because we have
actually checked in that file *with* CRLF! So when "core.autocrlf" is
true, we'll always generate a *different* hash for it in the index,
because the index hash will be for the content _without_ CRLF.
Is this complete? I dunno. It seems to work for me. It doesn't use the
filename at all right now, and that's probably a deficiency (we could
certainly make the "is_binary()" heuristics also take standard filename
heuristics into account).
I don't pass in the filename at all for the "index_fd()" case
(git-update-index), so that would need to be passed around, but this
actually works fine.
NOTE NOTE NOTE! The "is_binary()" heuristics are totally made-up by yours
truly. I will not guarantee that they work at all reasonable. Caveat
emptor. But it _is_ simple, and it _is_ safe, since it's all off by
default.
The patch is pretty simple - the biggest part is the new "convert.c" file,
but even that is really just basic stuff that anybody can write in
"Teaching C 101" as a final project for their first class in programming.
Not to say that it's bug-free, of course - but at least we're not talking
about rocket surgery here.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes it possible to restart git-daemon even if some children are
still running.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
44478d99ee introduced a filter using "git-rev-parse --not --all" to the
log display to prevent the display of revisions already in the
repository. However, the table of contents generation didn't get that
same update.
This patch fixes that. The table of contents before the log and the log
now both display the same list of revisions.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver is analogous to git-receive-pack; a checking from a cvs
client to a central server is like a git-push from a working repository.
Therefore it's nice to use the same access control (and email sending)
that a receive-pack would perform.
This patch tests for an executable update hook; if it is it is run with
the ref being updated and the old and new hashes as normal. If the
update hook returns an error code the update is aborted and the ref is
never updated. The cvsserver returns "error 1" to the client to signal
there was an EPERM error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was unclear if the backward compatible features were disabled
or the configuration variables that controls them were set to
false by default from the description. Obviously we meant the
former, but the problem was made worse by the fact that one
configuration variable breaks compatibility when set to true and
the other one breaks it when set to false.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of running around listing the changes near the release,
let's keep things nicely organized by summarizing the changes as
we merge things to the 'master' branch.
I haven't decided how well this will go with people's patch
submission procedure yet --- we'll play it by the ear and see
what happens.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some distributions are using Git for part of their package
management system, but unpack Git's own source code for
delivery from the .tar.gz. This means that when we walk
up the directory tree with git-describe to locate a Git
repository, the repository we find is for the distribution
and *not* for git-gui. Consequently any tag we might find
there is bogus and does not apply to us.
In this case the version file should always exist and be
readable, as the packager is working from the released
.tar.gz sources. So we should always favor the version
file over anything git-describe guess for us.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Makefile: update check-docs target
cmd-list: add git-remote
Documentation: Drop full-stop from git-fast-import title.
Minor corrections to release notes
Old aliases are not linked to the main command list. Also the internal
git-add--interactive does not need to be on the list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use the new stdin reflist passing mechanism for the call to
fetch--tool parse-reflist, allowing passing of more than ~128K
of reflist data.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use the new stdin reflist passing mechanism for the call to
fetch--tool expand-refs-wildcard, allowing passing of more
than ~128K of reflist data.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the reflist is "-" then read the reflist data from stdin instead,
this will allow the passing of more than 128K of reflist data - which
won't fit in the environment passed by execve.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This does not seem to make measurable improvement when dealing
with 1000 unpacked refs, but we would need something like it
if we were to do a full rewrite in C somedaoy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Move another shell loop that canonicalizes the list of refs for
underlying git-fetch-pack and fetch-native-store into C.
This seems to shave the runtime for the same 1000 branch
repository from 30 seconds down to 15 seconds (it used to be 2
and half minutes with the original version).
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "native-store" subcommand to git-fetch--tool to
move a huge loop implemented in shell into C. This shaves about
70% of the runtime to fetch and update 1000 tracking branches
with a single fetch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
`git diff --ignore-space-at-eol` will ignore whitespace at the
line ends.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you were issuing emails for two branches, and one merged the other,
you would get the same log messages appearing in two separate emails.
e.g. A working repository, where the last push to central was done at
the revision marked "B", after which two branches were developed
further.
* -- B -- 1 -- 1 -- M (branch1)
\ /
2 -- 2 -- 2 (branch2)
Now imagine that branch2 is pushed to the email-generating repository;
an email containing all the "2" revisions would be sent. Now, let's say
branch1 is pushed, the old update hook would run
git-rev-list $newrev ^$baserev
Where $newrev would be "M" and $baserev would be "B". This list
includes all the "2" revisions as well as all the "1" revisions.
This patch addresses this problem by using
git-rev-parse --not --all | git-rev-list --stdin $newrev ^$baserev
To inhibit the display of all revisions that are already in the
repository.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Like `git version`, `git gui version` (or `git gui --version`) shows
the version of git-gui, in case the user needs to know this, without
looking at it in the GUI about dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I started to find it confusing that git-gui would refer to itself
as git-citool when it was started through the citool hardlink, or
with the citool subcommand. What was especially confusing was the
options dialog and the about dialog, as both seemed to imply they
were somehow different from the git-gui versions. In actuality
there is no difference at all.
Now we just call our options menu item 'Options...' (skipping the
application name) and our About dialog now always shows git-gui
within the short description (above the copyleft notice) and in
the version field.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Update section about warning when leaving a detached head.
Also fix a few indentations that weren't like the rest of the file.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was pointed out on the git mailing list by Martin Koegler that
we did not show tags as possible things to merge into the current
branch. They actually are, and core Git's Grand Unified Merge
Driver will accept them just like any other commit.
So our merge dialog now requests all refs/heads, refs/remotes and
refs/tags named refs and attempts to match them against the commits
not in HEAD. One complicating factor here is that we must use the
%(*objectname) field when talking about an annotated tag, as they
will not appear in the output of rev-list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a very crude (but hopefully effective) check against the
`git` executable found in our PATH. Some of the subcommands and
options that git-gui requires to be present to operate were created
during the 1.5.0 development cycle, so 1.5 is the minimum version
of git that we can expect to support.
There actually are early releases of 1.5 (e.g. 1.5.0-rc0) that
don't have everything we expect (like `blame --incremental`) but
these are purely academic at this point. 1.5.0 final was tagged
and released just a few hours ago. The release candidates will
(hopefully) fade into the dark quickly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As we frequently need to execute a Git subcommand and obtain
its returned output we are making heavy use of [exec git foo]
to run foo. As I'm concerned about possibly needing to carry
environment data through a shell on Cygwin for at least some
subcommands, I'm migrating all current calls to a new git
proc. This actually makes the code look cleaner too, as
we aren't saying 'exec git' everywhere.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
Added support for @all as revision range specifier to import all changes to a given depot path.
Also default to an import of #head if no revrange is specified.
Signed-off-by: Simon Hausmann <hausmann@kde.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>
Use p4 files //depot/path/...@revision to determine the state of the project and create a "fake" git commit from it.
Signed-off-by: Simon Hausmann <hausmann@kde.org>
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>
Try to find the last imported p4 change number from the git tags and try to pass the right parent for commits to git fast-import.
Signed-off-by: Simon Hausmann <hausmann@kde.org>
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>
The option --reverse reverses the order of the commits.
[jc: with comments on rev_info.reverse from Simon 'corecode' Schubert.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
The internal function in_merge_bases(A, B) is used to make sure
that commit A is an ancestor of commit B. This changes the
signature of it to take an array of B's and updates its current
callers.
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>
This is not yet -rc1 where all new topics closes, but I think it
is getting pretty closer. I'd still want to merge updates to
fsck/prune to honor reflog entries before -rc1.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* rf/web:
gitweb: Use rev-list --skip option.
gitweb: Change history action to use parse_commits.
gitweb: Change atom, rss actions to use parse_commits.
gitweb: Change header search action to use parse_commits.
gitweb: Change log action to use parse_commits.
gitweb: Change summary, shortlog actions to use parse_commits.
gitweb: We do longer need the --parents flag in rev-list.
gitweb: Add parse_commits, used to bulk load commit objects.
Instead of just warning, refuse to add otherwise ignored files
by default, and allow it with an -f option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We only want to know the direct parents of a given commit object,
these parents are available in the --header output of rev-list. If
--parents is supplied with --full-history the output includes merge
commits that aren't relevant.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a new method parse_commits which is able to parse multiple commit
objects at once. Reworked parse_commit to share the commit object
parsing logic.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We allow otherwise ignored paths to be added to the index by
spelling its path out on the command line, but we would warn the
user about them when we do so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
One thing many people found confusing about git-add was that a
file whose name matches an ignored pattern could not be added to
the index. With this, such a file can be added by explicitly
spelling its name to git-add.
Fileglobs and recursive behaviour do not add ignored files to
the index. That is, if a pattern '*.o' is in .gitignore, and
two files foo.o, bar/baz.o are in the working tree:
$ git add foo.o
$ git add '*.o'
$ git add bar
Only the first form adds foo.o to the index.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the "git rm" command with saner semantics suggested
on the list earlier with:
Message-ID: <Pine.LNX.4.64.0612020919400.3476@woody.osdl.org>
Message-ID: <Pine.LNX.4.64.0612040737120.3476@woody.osdl.org>
The command still validates that the given paths all talk about
sensible paths to avoid mistakes (e.g. "git rm fiel" when file
"fiel" does not exist would error out -- user meant to remove
"file"), and it has further safety checks described next. The
biggest difference is that the paths are removed from both index
and from the working tree (if you have an exotic need to remove
paths only from the index, you can use the --cached option).
The command refuses to remove if the copy on the working tree
does not match the index, or if the index and the HEAD does not
match. You can defeat this check with -f option.
This safety check has two exceptions: if the working tree file
does not exist to begin with, that technically does not match
the index but it is allowed. This is to allow this CVS style
command sequence:
rm <path> && git rm <path>
Also if the index is unmerged at the <path>, you can use "git rm
<path>" to declare that the result of the merge loses that path,
and the above safety check does not trigger; requiring the file
to match the index in this case forces the user to do "git
update-index file && git rm file", which is just crazy.
To recursively remove all contents from a directory, you need to
pass -r option, not just the directory name as the <path>.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the return value from match_pathspec() so that the
caller can tell cases between exact match, leading pathname
match (i.e. file "foo/bar" matches a pathspec "foo"), or
filename glob match. This can be used to prevent "rm dir" from
removing "dir/file" without explicitly asking for recursive
behaviour with -r flag, for example.
Signed-off-by: Junio C Hamano <junkio@cox.net>
People often get confused if the value of branch.*.merge should
be the remote branch name they are fetching from, or the
tracking branch they locally have. So this allows either.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduce is_utf() to check if a text looks like it is encoded
in UTF-8, utf8_width() to count display width, and implements
print_wrapped_text() using them.
git-commit-tree warns if the commit message does not minimally
conform to the UTF-8 encoding when i18n.commitencoding is either
unset, or set to "utf-8".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that Git depends on pread in index-pack its safe to say we can
also depend on it within the git_mmap emulation we activate when
NO_MMAP is set. On most systems pread should be slightly faster
than an lseek/read/lseek sequence as its one system call vs. three
system calls.
We also now honor EAGAIN and EINTR error codes from pread and
restart the prior read.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This minor cleanup was suggested by Johannes Schindelin.
The mmap is still fake in the sense that we don't support PROT_WRITE
or MAP_SHARED with external modification at all, but that hasn't
stopped us from using mmap() thoughout the Git code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Paginate commit/author/committer search output to only show 100 commits
at a time, added appropriate nav links.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds and uses the install-doc-quick.sh file to
Documentation/, which is usable for people who track either the
'html' or 'man' heads in Junio's repository (prefixed with
'origin/' if cloned locally). You may override this by
specifying DOC_REF in the make environment or in config.mak.
GZ may also be set in the environment (or config.mak) if you
wish to gzip the documentation after installing it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Displaying the SHA1 of 'their' branch (the branch being merged into
the current branch) is not nearly as friendly as just displaying
the name of that branch, especially if that branch is already local
to this repository.
git-merge now sets the environment variable 'GITHEAD_%(sha1)=%(name)'
for each argument it gets passed, making the actual input name that
resolved to the commit '%(sha1)' easily available to the invoked
merge strategy.
git-merge-recursive makes use of these environment variables when
they are available by using '%(name)' whenever it outputs the commit
identification rather than '%(sha1)'. This is most obvious in the
conflict hunks created by xdl_merge:
$ git mege sideb~1
<<<<<<< HEAD:INSTALL
Good!
=======
Oops.
>>>>>>> sideb~1:INSTALL
[jc: adjusted a test script and a minor constness glitch.]
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we get a line-level conflict in merge-recursive and print out
the two sides in the conflict hunk header and footer we should use
the standard extended SHA1 syntax to specify the specific blob,
as this allows the user to copy and paste the line right into
'git show' to view the complete version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
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>
Use rev-list pattern search options instead of hand coded perl.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't need to call git_get_head_hash at all just pass in "HEAD" and
use the return id field.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't call gitweb_have_snapshot from within the loop.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only return one line of output and we don't need the refname value.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Part of the patch for "gitweb: Show '...' links in "summary" view only
if there are more items" (313ce8cee6) is
missing. Add it back in.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Branch has "-r" for remote branches and "-a" for local and remote.
It seems logical to mirror that in show-branch. Also removes the
dubiously useful "--tags" option (as part of changing the meaning
for "--all").
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The option checking code for --git-dir had an off by 1 error that
would cause it to access uninitialized memory if it was the last
argument. This causes it to display an error and display the usage
string instead.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
dcommit does commits and fetches, so all options used for those
should work, too, including --authors-file.
Reported missing by Nicolas Vilz.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code no longer uses it, as we have --inaccurate-eof in
git-apply.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to support specifying the top part of remote URL in
remotes and use that as a short-hand for the URL.
$ cat .git/remotes/jgarzik
URL: git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/
$ git pull jgarzik/misc-2.6
This is confusing when somebody attempts to do this:
$ git pull origin/foo
which is not syntactically correct (unless you have origin/foo.git
repository) and should fail, but it resulted in a mysterious
access to the 'foo' subdirectory of the origin repository.
Which was what it was designed to do, but because this is an
oddball "feature" I suspect nobody uses, let's remove it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This will not be backward compatible no matter how you cut it.
Shelve it for now until somebody comes up with a better way to
determine when we can safely refuse to use the first set of
branchse for merging without upsetting valid workflows.
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit made "reset --hard" chattier but leaking its
message from "git rebase" (which calls it when first rewinding
the current branch to prepare replaying our own changes) without
explanation was confusing, so add an extra message to mention
it. Inside restorestate in merge (which is rarely exercised
codepath, where more than one strategies are attempted),
resetting to the original state uses "reset --hard" -- this can
be squelched entirely.
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>
We have a static allocation of MAXPARENT, but that limit was not
enforced, other than by a lucky invocation of the program segfaulting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The perl version used modules which are non-standard in some setups.
This patch brings the full power of rerere to a wider audience.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
read_file() was a useful function if you want to work with the xdiff stuff,
so it was renamed and put into a more central place.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
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
Like the existing error() function the new warn() function can be
used to describe a situation that probably should not be occuring,
but which the user (and Git) can continue to work around without
running into too many problems.
An example situation is a bad commit SHA1 found in a reflog.
Attempting to read this record out of the reflog isn't really an
error as we have skipped over it in the past.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because I am about to introduce a global warn() function (much
like the global error function) this global declaration would
conflict with the one supplied by imap-send. Further since
imap-send's warn function output depends on its Quiet setting
we cannot simply remove its internal definition and use the
forthcoming global one.
So refactor warn() -> imap_warn() and info() -> imap_info()
(the latter was done just to be consistent in naming).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit a71fb0a1 implemented much requested safety
valve to refuse "git pull" or "git pull origin" without explicit
refspecs from using the first set of remote refs obtained by
reading .git/remotes/origin file or branch.*.fetch configuration
variables to create a merge. The argument was that while on a
branch different from the default branch, it is often wrong to
merge the default remote ref suitable for merging into the master.
That is fine as a theory. But many repositories already in use
by people in the real world do not have any of the per branch
configuration crap. They did not need it, and they do not need
it now. Merging with the first remote ref listed was just fine,
because they had only one ref (e.g. 'master' from linux-2.6.git)
anyway.
So this changes the safety valve to be a lot looser. When "git
fetch" gets only one remote branch, the irritating warning would
not trigger anymore.
I think we could also make the warning trigger when branch.*.merge
is not specified for the current branch, but is for some other
branch. That is for another commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This imitates the behaviour of git-commit.
Noticed by Han-Wen Nienhuys.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit a71fb0a141.
The logic to decide when to refuse to use the default "first set of
refs fetched" for merge was utterly bogus.
In a repository that happily worked correctly without any of the
per-branch configuration crap did not have (and did not have to
have) any branch.<current>.merge. With that broken commit, pulling
from origin no longer would work.
Now that we have decided to make 'add' behave like 'update-index'
(and therefore fully classify update-index as strictly plumbing)
the am/revert/cherry-pick family of commands should not steer the
user towards update-index. Instead send them to the command they
probably already know, 'add'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Would you believe? I edited git-merge-one-file (note the missing ".sh"!)
when I submitted the patch which became commit e2b7008752...
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When parsing the diff line starting with '@@', the line number of the
'+' file is parsed. For the subsequent line parses, the line number
should therefore be incremented after the parse, not before it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For Mac OS X 10.4, _XOPEN_SOURCE defines _POSIX_C_SOURCE which
hides many symbols from the program.
Breakage noticed and initial analysis provided by Randal
L. Schwartz.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
This corrects minor remaining bits that still talked about <tree-ish>;
the Porcelain users (as opposed to plumbers) are mostly interested in
commits so use <commit> consistently and keep a sentence that mentions
that <tree-ish> can be used in place of them.
* jc/clone:
Move "no merge candidate" warning into git-pull
Use preprocessor constants for environment variable names.
Do not create $GIT_DIR/remotes/ directory anymore.
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
git-clone: lose the traditional 'no-separate-remote' layout
git-clone: lose the artificial "first" fetch refspec
git-pull: refuse default merge without branch.*.merge
git-clone: use wildcard specification for tracking branches
This adds --skip=<n> option to revision traversal machinery.
Documentation and test were added by Robert Fitzsimons.
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If ever new object types are added for future extensions then better
have current git version report them as "unknown" instead of
"corrupted".
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a mechanical clean-up of the way *.c files include
system header files.
(1) sources under compat/, platform sha-1 implementations, and
xdelta code are exempt from the following rules;
(2) the first #include must be "git-compat-util.h" or one of
our own header file that includes it first (e.g. config.h,
builtin.h, pkt-line.h);
(3) system headers that are included in "git-compat-util.h"
need not be included in individual C source files.
(4) "git-compat-util.h" does not have to include subsystem
specific header files (e.g. expat.h).
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was reported by Randal L. Schwartz <merlyn@stonehenge.com> that
indexing the Linux repository ~150MB pack takes about an hour on OS x
while it's a minute on Linux. It seems that the OS X mmap()
implementation is more than 2 orders of magnitude slower than the Linux
one.
Linus proposed a patch replacing mmap() with pread() bringing index-pack
performance on OS X in line with the Linux one. The performances on
Linux also improved by a small margin.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Show "..." links in "summary" view to shortlog, heads (if there are
any), and tags (if there are any) only if there are more items to show
than shown already.
This means that "..." link is shown below shortened shortlog if there
are more than 16 commits, "..." link below shortened heads list if
there are more than 16 heads refs (16 branches), "..." link below
shortened tags list if there are more than 16 tags.
Modified patch from Jakub to to apply cleanly to master, also preform
the same "..." link logic to the forks list.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Robert Fitzsimons <robfitz@273k.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It's rather misleading to have configuration options that don't do
anything. If someone adds collision checking they might also want to
restore this option.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 5761231975.
Feeding symmetric difference to gitk is so useful, and it is the
same for other graphical Porcelains. Rather than forcing them
to pass --no-left-right, making it optional.
Noticed and reported by Jeff King.
The warning triggered even when running "git fetch" only
when resulting .git/FETCH_HEAD only contained
branches marked as 'not-for-merge'.
Signed-off-by: Josef Weidendorfer <weidendo@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We broke the discipline Linus set up to allow compiler help us
avoid typos in environment names in the early days of git over
time. This defines a handful preprocessor constants for
environment variable names used in relatively core parts of the
system.
I've left out variable names specific to subsystems such as HTTP
and SSL as I do not think they are big problems.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we do not use --no-separate-remote anymore, there is no
reason to create that directory from the template.
t5510 test is updated to test both $GIT_DIR/remotes/ based
configuration and $GIT_DIR/config variable (credits to
Johannes).
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/test-clone: (35 commits)
Introduce GIT_TEMPLATE_DIR
Revert "fix testsuite: make sure they use templates freshly built from the source"
fix testsuite: make sure they use templates freshly built from the source
rerere: fix breakage of resolving.
Add config example with respect to branch
Add documentation for show-branch --topics
make git a bit less cryptic on fetch errors
make patch_delta() error cases a bit more verbose
racy-git: documentation updates.
show-ref: fix --exclude-existing
parse-remote::expand_refs_wildcard()
vim syntax: follow recent changes to commit template
show-ref: fix --verify --hash=length
show-ref: fix --quiet --verify
avoid accessing _all_ loose refs in git-show-ref --verify
git-fetch: Avoid reading packed refs over and over again
Teach show-branch how to show ref-log data.
markup fix in svnimport documentation.
Documentation: new option -P for git-svnimport
Fix mis-mark-up in git-merge-file.txt documentation
...
Instead of passing --template explicitely to init-db and clone, you can
just set the environment variable GIT_TEMPLATE_DIR.
Also make use of it in the tests, to make sure that the templates are
copied.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 74d20040ca.
Version from Johannes to introduce GIT_TEMPLATE_DIR is simpler,
although I unconsciously stayed away from introducing yet another
environment variable.
This adds hunk splitting and recounting the patch lines. The
'patch' subcommand now allows you to split a large hunk at
context lines in the middle.
Signed-off-by: Junio C Hamano <junkio@cox.net>
A script to be driven when the user says "git add --interactive"
is introduced.
When it is run, first it runs its internal 'status' command to
show the current status, and then goes into its internactive
command loop.
The command loop shows the list of subcommands available, and
gives a prompt "What now> ". In general, when the prompt ends
with a single '>', you can pick only one of the choices given
and type return, like this:
*** Commands ***
1: status 2: update 3: revert 4: add untracked
5: patch 6: diff 7: quit 8: help
What now> 1
You also could say "s" or "sta" or "status" above as long as the
choice is unique.
The main command loop has 6 subcommands (plus help and quit).
* 'status' shows the change between HEAD and index (i.e. what
will be committed if you say "git commit"), and between index
and working tree files (i.e. what you could stage further
before "git commit" using "git-add") for each path. A sample
output looks like this:
staged unstaged path
1: binary nothing foo.png
2: +403/-35 +1/-1 git-add--interactive.perl
It shows that foo.png has differences from HEAD (but that is
binary so line count cannot be shown) and there is no
difference between indexed copy and the working tree
version (if the working tree version were also different,
'binary' would have been shown in place of 'nothing'). The
other file, git-add--interactive.perl, has 403 lines added
and 35 lines deleted if you commit what is in the index, but
working tree file has further modifications (one addition and
one deletion).
* 'update' shows the status information and gives prompt
"Update>>". When the prompt ends with double '>>', you can
make more than one selection, concatenated with whitespace or
comma. Also you can say ranges. E.g. "2-5 7,9" to choose
2,3,4,5,7,9 from the list. You can say '*' to choose
everything.
What you chose are then highlighted with '*', like this:
staged unstaged path
1: binary nothing foo.png
* 2: +403/-35 +1/-1 git-add--interactive.perl
To remove selection, prefix the input with - like this:
Update>> -2
After making the selection, answer with an empty line to
stage the contents of working tree files for selected paths
in the index.
* 'revert' has a very similar UI to 'update', and the staged
information for selected paths are reverted to that of the
HEAD version. Reverting new paths makes them untracked.
* 'add untracked' has a very similar UI to 'update' and
'revert', and lets you add untracked paths to the index.
* 'patch' lets you choose one path out of 'status' like
selection. After choosing the path, it presents diff between
the index and the working tree file and asks you if you want
to stage the change of each hunk. You can say:
y - add the change from that hunk to index
n - do not add the change from that hunk to index
a - add the change from that hunk and all the rest to index
d - do not the change from that hunk nor any of the rest to index
j - do not decide on this hunk now, and view the next
undecided hunk
J - do not decide on this hunk now, and view the next hunk
k - do not decide on this hunk now, and view the previous
undecided hunk
K - do not decide on this hunk now, and view the previous hunk
After deciding the fate for all hunks, if there is any hunk
that was chosen, the index is updated with the selected hunks.
* 'diff' lets you review what will be committed (i.e. between
HEAD and index).
This is still rough, but does everything except a few things I
think are needed.
* 'patch' should be able to allow splitting a hunk into
multiple hunks.
* 'patch' does not adjust the line offsets @@ -k,l +m,n @@
in the hunk header. This does not have major problem in
practice, but it _should_ do the adjustment.
* It does not have any explicit support for a merge in
progress; it may not work at all.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When blame.blankboundary is set (or -b option is given), commit
object names are blanked out in the "human readable" output
format for boundary commits.
When blame.showroot is not set (or --root is not given), the
root commits are treated as boundary commits. The code still
attributes the lines to them, but with -b their object names are
not shown.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If there are more than one branches to be deleted, failure on
one will no longer stop git-branch to process the next ones.
The command still reports failures by exitting non-zero status.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because -r already means "remote" when listing, you can say:
$ git branch -d -r origin/todo origin/html origin/man
I just twisted it not to check fast-forwardness with the current
branch when you are removing a tracking branch. Most likely,
removal of a tracking branch is not because you are "done with"
it (for a local branch, it usually means "you merged it up"),
but because you are not even interested in it. In other words,
remote tracking branches are more like tags than branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The initial t/trash repository for testing was created properly
but over time we gained many tests that create secondary test
repositories with init-db or clone and they were not careful
enough.
This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
commit e2b70087 botched the RCS merge to git-merge-file conversion.
There is no command called "git merge-file" (yes, we are using safer
variant of Perl's system(3)).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update config.txt with example with respect to branch
config variable. This give a better idea regarding
how branch names are expected.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a quick paragraph explaining the --topics option for show-branch.
The explanation is an abbreviated version of the commit message from
d320a5437f.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The remote server might not want to tell why it doesn't like us for
security reasons, but let's make the client report such error in a bit
less confusing way. The remote failure remains a mystery, but the local
message might be a bit less so.
[jc: with a gentle wording updates from Andy Parkins]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is especially important to distinguish between a malloc() failure
from all the other cases. An out of memory condition is much less
worrisome than a compatibility/corruption problem.
Also make test-delta compilable again.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've removed the workaround for runtime penalty that did not
exist in practice some time ago, but the technical paper that
proposed that change still said "we probably should do so".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not falsely document --filter-invalid which does not even exist.
Also make sure the line is long enough to have ^{} suffix before
checking for it.
Pointed out by Dscho.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Work around dash incompatibility by not using "${name%'^{}'}".
Noticed by Jeff King; dash seems to mistake the closing brace
inside the single quote as the terminating brace for parameter
expansion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch changes the syntax highlighting to correctly match the new
text of the commit message introduced by
82dca84871
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier optimization for --verify broke a lot of stuff
because it did not take interaction with other flags into
account.
This also fixes an unrelated argument parsing error; --hash=8
should mean the same as "--hash --abbrev=8".
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'jn/web' (early part):
gitweb: Add "next" link to commit view
gitweb: Add title attribute to ref marker with full ref name
gitweb: Do not show difftree for merges in "commit" view
gitweb: SHA-1 in commit log message links to "object" view
gitweb: Hyperlink target of symbolic link in "tree" view (if possible)
gitweb: Add generic git_object subroutine to display object of any type
gitweb: Show target of symbolic link in "tree" view
gitweb: Don't use Content-Encoding: header in git_snapshot
If you want to verify a ref, it is overkill to first read all loose refs
into a linked list, and then check if the desired ref is there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
When checking which tags to fetch, the old code used to call
git-show-ref --verify for each remote tag. Since reading even
packed refs is not a cheap operation when there are a lot of
local refs, the code became quite slow.
This fixes it by teaching git-show-ref to filter out existing
refs using a new mode of operation of git-show-ref.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using symmetric differences, I think the user almost always
would want to know which side of the symmetry each commit came
from. So this removes --left-right option from the command
line, and turns it on automatically when a symmetric difference
is used ("git log --merge" counts as a symmetric difference
between HEAD and MERGE_HEAD).
Just in case, a new option --no-left-right is provided to defeat
this, but I do not know if it would be useful.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The output from "symmetric diff", i.e. A...B, does not
distinguish between commits that are reachable from A and the
ones that are reachable from B. In this picture, such a
symmetric diff includes commits marked with a and b.
x---b---b branch B
/ \ /
/ .
/ / \
o---x---a---a branch A
However, you cannot tell which ones are 'a' and which ones are
'b' from the output. Sometimes this is frustrating. This adds
an output option, --left-right, to rev-list.
rev-list --left-right A...B
would show ones reachable from A prefixed with '<' and the ones
reachable from B prefixed with '>'.
When combined with --boundary, boundary commits (the ones marked
with 'x' in the above picture) are shown with prefix '-', so you
would see list that looks like this:
git rev-list --left-right --boundary --pretty=oneline A...B
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 3rd on b
>bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb 2nd on b
<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 3rd on a
<aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 2nd on a
-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on b
-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 1st on a
Signed-off-by: Junio C Hamano <junkio@cox.net>
If GIT_COMMITTER_NAME is not available in receive-pack but reflogs
are enabled we would normally die out with an error message asking
the user to correct their environment settings.
Now that reflogs are enabled by default in (what we guessed to be)
non-bare Git repositories this may cause problems for some users
who don't have their full name in the gecos field and who don't
have access to the remote system to correct the problem.
So rather than die()'ing out in receive-pack when we try to log a
ref change and have no committer name we default to the username,
as obtained from the host's password database.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'update-index --replace --add A/B'
did not properly remove the file to make room for the new
directory.
There was a trivial logic error, most likely a cut & paste one,
dating back to quite early days of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When replacing an existing file A with a directory A that has a
file A/B in it in the index, 'git add' did not succeed because
it forgot to pass the allow-replace flag to add_cache_entry().
It might be safer to leave this as an error and require the user
to explicitly remove the existing A first before adding A/B
since it is an unusual case, but doing that automatically is
much easier to use.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When you remove a directory D that has a tracked file D/F out of the
way to create a file D and try to "git update-index --add D", it used
to say "cannot add" which was not very helpful. This issues an extra
error message to explain the situation before the final "fatal" message.
Since D/F conflicts are relatively rare event, extra verbosity would
not make things too noisy.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When renaming a branch, the corresponding config section should
be renamed, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Given a config like this:
# A config
[very.interesting.section]
not
The command
$ git repo-config --rename-section very.interesting.section bla.1
will lead to this config:
# A config
[bla "1"]
not
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Finally.
The separate-remote layout is so much more organized than
traditional and easier to work with especially when you need to
deal with remote repositories with multiple branches and/or you
need to deal with more than one remote repositories, and using
traditional layout for new repositories simply does not make
much sense.
Internally we still have code for 1:1 mappings to create a bare
clone; that is a good thing and will not go away.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now we lost the "first refspec is the one that is merged by default"
rule, there is no reason for clone to list the remote primary branch
in the config file explicitly anymore.
We still need it for the traditional layout for other reasons,
though.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Everybody hated the pull behaviour of merging the first branch
listed on remotes/* file (or remote.*.fetch config) into the
current branch. This finally corrects that UI wart by
forbidding "git pull" without an explicit branch name on the
command line or branch.$current.merge for the current branch.
The matching change to git-clone was made to prepare the default
branch.*.merge entry for the primary branch some time ago.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This stops enumerating the set of branches found on the remote
side when a clone was made in the configuration file. Instead,
a single entry that maps each remote branch to the local
tracking branch for the remote under the same name is created.
Doing it this way not only shortens the configuration file, but
automatically adjusts to a new branch added on the remote side
after the clone is made.
Unfortunately this cannot be done for the traditional layout,
where we always need to special case the 'master' to 'origin'
mapping within the local branch namespace. But that is Ok; it
will be going away before v1.5.0.
We could also lose the "primary branch" mapping at the
beginning, but that has to wait until we implement the "forbid
'git pull' when we do not have branch.$current.merge for the
current branch" policy we earlier discussed. That should also
be in v1.5.0
Signed-off-by: Junio C Hamano <junkio@cox.net>
This hacks the input to fmt-merge-msg to make the message for
merging early part of a branch a little easier to read.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a kind of "next" view in the bottom part of navigation bar for
"commit" view, similar to what was added for "commitdiff" view in
commit 151602df00
'gitweb: Add "next" link to commitdiff view'
For "commit" view for single parent commit:
(parent: _commit_)
For "commit" view for merge (multi-parent) commit:
(merge: _commit_ _commit_ ...)
For "commit" view for root (parentless) commit
(initial)
where _link_ denotes hyperlink. SHA1 of commit is shortened
to 7 characters on display.
While at it, remove leftovers from commit cae1862a by Petr Baudis:
'gitweb: More per-view navigation bar links'
namely the "blame" link if there exist $file_name and commit has a
parent; it was added in git_commit probably by mistake. The rest
of what mentioned commit added for git_commit was removed in
commit 6e0e92fda8 by Luben Tuikov:
'gitweb: Do not print "log" and "shortlog" redundantly in commit view'
(which should have probably removed also this "blame" link removed now).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add title attribute, which will be shown as popup on mouseover in
graphical web browsers, with full name of ref, including part (type)
removed from the name of ref itself. This is useful to see that this
strange ref is StGIT ref, or it is remote branch, or it is lightweigh
tag (with branch-like name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not show difftree against first parent for merges (commits with
more than one parent) in "commit" view, because it usually is
misleading. git-show and git-whatchanged doesn't show diff for merges
either.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
'set-tree' probably accurately describes what the command
formerly known as 'commit' does.
I'm not entirely sure that 'dcommit' should be renamed to 'commit'
just yet... Perhaps 'push' or 'push-changes'?
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using the command-line client was great for prototyping and
getting something working quickly. Eventually I found time
to study the library documentation and add support for using
the libraries which are much faster and more flexible when
it comes to supporting new features.
Note that we require version 1.1 of the SVN libraries, whereas
we supported the command-line svn client down to version 1.0.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most of this is derived from the documentation of RCS merge.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When --use-separate-remote is used on git-clone, the remote
heads are saved under $GIT_DIR/refs/remotes/origin/, not
"$GIT_DIR/remotes/origin/"
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the current branch was "master" then git-status wouldn't say
# On branch XXXX
In its output. This patch makes it so that this message is always
output; regardless of branch name.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Thanks to Git.pm, I've been able to greatly reduce the amount
of extra work that needs to be done to manage input/output
pipes in Perl.
chomp usage has also been greatly reduced, too.
All tests (including full-svn-test) still pass, but this has
not been tested extensively in the real-world.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that 'git add' is considered a first-class UI for 'update-index'
and that the 'git add' documentation states "Even modified files
must be added to the set of changes about to be committed" we should
make the output of 'git status' align with that documentation and
common usage.
So now we see a status output such as:
# Added but not yet committed:
# (will commit)
#
# new file: x
#
# Changed but not added:
# (use "git add file1 file2" to include for commit)
#
# modified: x
#
# Untracked files:
# (use "git add" on files to include for commit)
#
# y
which just reads better in the context of using 'git add' to
manipulate a commit (and not a checkin, whatever the heck that is).
We also now support 'color.status.added' as an alias for the existing
'color.status.updated', as this alias more closely aligns with the
current output and documentation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a user modifies files and runs 'git commit' (without the very
useful -a option) and they have not yet updated the index they
are probably coming from another SCM-like tool which would perform
the same as 'git commit -a' in this case. Showing the user their
current status and a final line of "nothing to commit" is not very
reassuring, as the user might believe that Git did not recognize
their files were modified.
Instead we can suggest as part of the 'nothing to commit' message
that the user invoke 'git add' to add files to their next commit.
Suggested by Andy Parkins' Git 'niggles' list
(<200612132237.10051.andyparkins@gmail.com>).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Two of the cases has "[--] [<path>...]" and two had "-- [<path>...]".
Not terribly consistent and potentially confusing. Also add "[--]" to
the synopsis so that it's obvious you can use it from the very
beginning.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For multivars, the "git-repo-config name value ^$" is useful but
nonintuitive and troublesome to do repeatedly (since the value is not
at the end of the command line). This commit simply adds an --add
option that adds a new value to a multivar. Particularly useful for
tracking a new branch on a remote:
git-repo-config --add remote.origin.fetch +next:origin/next
Includes documentation and test.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that 'git show' accepts ref:path as an argument to specify a
tree or blob we should use the same completion logic as we support
for cat-file's object identifier.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
New and experienced Git users alike are finding out too late that
they forgot to enable reflogs in the current repository, and cannot
use the information stored within it to recover from an incorrectly
entered command such as `git reset --hard HEAD^^^` when they really
meant HEAD^^ (aka HEAD~2).
So enable reflogs by default in all future versions of Git, unless
the user specifically disables it with:
[core]
logAllRefUpdates = false
in their .git/config or ~/.gitconfig.
We only enable reflogs in repositories that have a working directory
associated with them, as shared/bare repositories do not have
an easy means to prune away old log entries, or may fail logging
entirely if the user's gecos information is not valid during a push.
This heuristic was suggested on the mailing list by Junio.
Documentation was also updated to indicate the new default behavior.
We probably should start to teach usuing the reflog to recover
from mistakes in some of the tutorial material, as new users are
likely to make a few along the way and will feel better knowing
they can recover from them quickly and easily, without fsck-objects'
lost+found features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Back in the old days of Git when people messed around with their
GIT_DIR environment variable more often it was nice to know whether
or not git-init-db created a .git directory or used GIT_DIR.
As most users at that time were rather technical UNIXy folk the
message "defaulting to local storage area" made sense to some and
seemed reasonable.
But it doesn't really convey any meaning to the new Git user,
as they don't know what a 'local storage area is' nor do they
know enough about Git to care. It also really doesn't tell the
experienced Git user a whole lot about the command they just ran,
especially if they might be reinitializing an existing repository
(e.g. to update hooks).
So now we print out what we did ("Initialized empty" or
"Reinitialized existing"), what type of repository ("" or "shared"),
and what location the repository will be in ("$GIT_DIR").
Suggested in part by Andy Parkins in his Git 'niggles' list
(<200612132237.10051.andyparkins@gmail.com>).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is nicer to let the user know when a commit succeeded all the time,
not only the first time. Also the commit sha1 is much more useful than
the tree sha1 in this case.
This patch also introduces a -q switch to supress this message as well
as the summary of created/deleted files.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The Cygwin folks have done a fine job at creating a POSIX layer
on Windows That Just Works(tm). However it comes with a penalty;
accessing files in the working tree by way of stat/open/mmap can
be slower for diffcore than inflating the data from a blob which
is stored in a packfile.
This performance problem is especially an issue in merge-recursive
when dealing with nearly 7000 added files, as we are loading
each file's content from the working directory to perform rename
detection. I have literally seen (and sadly watched) paint dry in
less time than it takes for merge-recursive to finish such a merge.
On the other hand this very same merge runs very fast on Solaris.
If Git is compiled with NO_FAST_WORKING_DIRECTORY set then we will
avoid looking at the working directory when the blob in question
is available within a packfile and the caller doesn't need the data
unpacked into a temporary file.
We don't use loose objects as they have the same open/mmap/close
costs as the working directory file access, but have the additional
CPU overhead of needing to inflate the content before use. So it
is still faster to use the working tree file over the loose object.
If the caller needs the file data unpacked into a temporary file
its likely because they are going to call an external diff program,
passing the file as a parameter. In this case reusing the working
tree file will be faster as we don't need to inflate the data and
write it out to a temporary file.
The NO_FAST_WORKING_DIRECTORY feature is enabled by default on
Cygwin, as that is the platform which currently appears to benefit
the most from this option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since git-show is pure Porcelain, it is the ideal candidate to
pretty print other things than commits, too.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes it is asked on the list how to revert selected path in
the index from a tree, most often HEAD, without affecting the
files in the working tree. A similar operation that also
affects the working tree files has been available in the form of
"git checkout <tree> -- <paths>...".
By definition --soft would never affect either the index nor the
working tree files, and --hard is the way to make the working
tree files as close to pristine, so this new option is available
only for the default --mixed case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you typically sit in, say "src/", it's annoying to have to
change directory to do a reset.
This may need to be reworked when we add "git reset -- paths..."
to encapsulate the "ls-tree $tree | update-index --index-info"
pattern.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since a long time, we have inbuilt diff generation.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When comparing file contents during the second loop through a rename
detection attempt we can skip the expensive byte-by-byte comparsion
if both source and destination files have valid SHA1 values. This
improves performance by avoiding either an expensive open/mmap to
read the working tree copy, or an expensive inflate of a blob object.
Unfortunately we still have to at least initialize the sizes of the
source and destination files even if the SHA1 values don't match.
Failing to initialize the sizes causes a number of test cases to fail
and start reporting different copy/rename behavior than was expected.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Porcelain documentation should talk in terms of end-user workflow, not
in terms of implementation details. Do not suggest update-index, but
git-add instead. Explain differences among 0-, 1- and 2-tree cases
not as differences of number of trees given to the command, but say
why user would want to give these number of trees to the command in
what situation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The list concensus is to group color related configuration under
"color.*" so let's be consistent.
Inspired by Andy Parkins's patch to do the same for diff/log
family. With fixes from Eric Wong.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The low-level parts of the SVN library return NULL/undef for
author-less revisions, whereas "(no author)" is a (svn) client
convention.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When blaming with revision ranges, often many lines are attributed
to different commits at the boundary, but they are not interesting
for the purpose of finding project history during that revision range.
This outputs the lines blamed on boundary commits differently. When
showing "human format" output, their SHA-1 are shown with '^' prefixed.
In "porcelain format", the commit will be shown with an extra attribute
line "boundary".
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/read-tree-ignore:
read-tree: document --exclude-per-directory
Loosen "working file will be lost" check in Porcelain-ish
read-tree: further loosen "working file will be lost" check.
* np/addcommit:
git-commit: allow --only to lose what was staged earlier.
Documentation/git-commit: rewrite to make it more end-user friendly.
make 'git add' a first class user friendly interface to the index
* lh/branch-rename:
git-branch: let caller specify logmsg
rename_ref: use lstat(2) when testing for symlink
git-branch: add options and tests for branch renaming
Conflicts:
builtin-branch.c
Showing local and remote branches in green and red was simply
overkill, as all we wanted was to make it easy to tell them
apart (local ones can be built on top by committing, but the
remote tracking ones can't).
Use plain coloring for local branches and paint remotes in red.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/merge:
merge-recursive: add/add really is modify/modify with an empty base
Get rid of the dependency on RCS' merge program
merge-file: support -p and -q; fix compile warnings
Add builtin merge-file, a minimal replacement for RCS merge
xdl_merge(): fix and simplify conflict handling
xdl_merge(): fix thinko
xdl_merge(): fix an off-by-one bug
merge-recursive: use xdl_merge().
xmerge: make return value from xdl_merge() more usable.
xdiff: add xdl_merge()
"git push $URL HEAD~6" created a bogus ref HEAD~6 immediately
under $GIT_DIR of the remote repository. While we should keep
refspecs that have arbitrary extended SHA-1 expression on the
source side working (e.g. "HEAD~6:refs/tags/yesterday"), we
should not create bogus ref on the other end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The documentation talked about "git push $URL tag <tag>" as a short-hand
for refs/tags/<tag>:refs/tags/<tag> for a long time but that was never
the case (the short-hand was for "git fetch"). Instead of fixing the
documentation, just add a bit of code to match it since it is easy to do
and would make it more consistent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is just a random hack to work around problems people seem
to be seeing in manpage backend of xmlto (it appears we are
getting ".sp" at the end of line without line break).
Could people test this out?
Signed-off-by: Junio C Hamano <junkio@cox.net>
99.9999% of the time, the command is used with a single
strategy; after a merge failure, saying "No strategy handled the
merge" is technically correct, but there is no point stressing
we tried and failed all the possibilities the user has given.
Just say that it failed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Prior to 65ac6e9c3f we deleted a file
from the working directory during a merge if the file existed before
the merge started but was renamed by the branch being merged in.
This broke in 65ac6e as git-merge-recursive did not actually update
the working directory on an uncontested rename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reverts commit 4c81c213a4.
Although --cached and --index are confusing wording, the use of
word --cached for git-diff is consistent with git-apply. It means
"work with index without looking at the working tree".
We should probably come up with better wording for --cached, if
somebody wants to deprecate it. But making --index and --cached
synonyms for diff while leaving them mean different things for
apply is no good.
If I wanted to print $@, I'd pass $@ to fatal(). This looks like
a stupid typo on my part.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some versions of the SVN libraries cause die() to exit with 255,
and 40cf043389 tightened up
test_expect_failure to reject return values >128.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While adding colour to the branch command it was pointed out that a
config option like "branch.color" conflicts with the pre-existing
"branch.something" namespace used for specifying default merge urls and
branches. The suggested solution was to flip the order of the
components to "color.branch", which I did for colourising branch.
This patch does the same thing for
- git-log (color.diff)
- git-status (color.status)
- git-diff (color.diff)
- pager (color.pager)
I haven't removed the old config options; but they should probably be
deprecated and eventually removed to prevent future namespace
collisions. I've done this deprecation by changing the documentation
for the config file to match the new names; and adding the "color.XXX"
options to contrib/completion/git-completion.bash.
Unfortunately git-svn reads "diff.color" and "pager.color"; which I
don't like to change unilaterally.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unify the handling for cases C (add/add) and D (modify/modify).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (42 commits)
git-svn: correctly handle packed-refs in refs/remotes/
add test case for recursive merge
git-svn: correctly display fatal() error messages
git-svn: allow dcommit to take an alternate head
git-svn: enable logging of information not supported by git
Clarify fetch error for missing objects.
Move Fink and Ports check to after config file
shortlog: fix segfault on empty authorname
shortlog: remove "[PATCH]" prefix from shortlog output
Make sure the empty tree exists when needed in merge-recursive.
Don't use memcpy when source and dest. buffers may overlap
no need to install manpages as executable
Documentation: simpler shared repository creation
shortlog: fix segfault on empty authorname
Add branch.*.merge warning and documentation update
Fix perl/ build.
git-svn: use do_switch for --follow-parent if the SVN library supports it
Fix documentation copy&paste typo
git-svn: extra error check to ensure we open a file correctly
Documentation: update git-clone man page with new behavior
...
Now that we have git-merge-file, an RCS merge lookalike, we no longer
need it. So long, merge, and thanks for all the fish!
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now use git-rev-parse universally to read refs, instead
of our own file_to_s function (which I plan on removing).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test case is based on the bug report by Shawn Pearce.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If I wanted to print $@, I'd pass $@ to fatal(). This looks like
a stupid typo on my part.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously dcommit would unconditionally commit all patches
up-to and including the current HEAD. Now if an optional
command-line argument is specified, it will only commit
up to the specified revision.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The changes are now tracked in
$GIT_DIR/svn/$GIT_SVN_ID/untracked.log
Information in the untracked.log include:
* the addition and removal of empty directories
(changes of these will also warn the user)
* file and directory property changes, including (but not
limited to) svk:merge and svn:externals
* revision properties (revprops) are also tracked
* users will be warned of 'absent' file and directories
(if users are forbidden access)
Fields in entries are separated by spaces; "unsafe" characters
are URI-encoded so that each entry takes exactly one line.
There is currently no automated parser for dealing with the data
in untracked.log, but it should be possible to write one to
create empty directories on checkout and manage
externals/subprojects.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise there're such things like:
Cannot obtain needed none 9a6e87b60dbd2305c95cecce7d9d60f849a0658d
while processing commit 0000000000000000000000000000000000000000.
which while looks weird. What is the none needed for?
Signed-off-by: Junio C Hamano <junkio@cox.net>
Putting NO_FINK or NO_DARWIN_PORTS in config.mak is ignored because the
checks are done before the config is included.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I wanted to have a visual indication of which branches are local and
which are remote in git-branch -a output; however Junio was concerned
that someone might be using the output in a script. This patch
addresses the problem by colouring the git-branch output - which in
"auto" mode won't be activated.
I've based it off the colouring code for builtin-diff.c; which means
there is a branch color configuration variable that needs setting to
something before the color will appear.
The colour parameter is "color.branch" rather than "branch.color" to
avoid clashing with the default namespace for default branch merge
definitions.
This patch chooses green for local, red for remote and bold green for
current.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of checking if explicit SHA-1 in commit log message is sha1 of
commit and making link to "commit" view, make [fragment of] explicit
SHA-1 in commit log message link to "object" view. While at it allow
to hyperlink also shortened SHA-1, from 8 characters up to full SHA-1,
instead of requiring full 40 characters of SHA-1.
This makes the following changes:
* SHA-1 of objects which no longer exists, for example in commit
cherry-picked from no longer existing temporary branch, or revert
of commit in rebased branch, are no longer marked as such by not
being made into hyperlink (and not having default hyperlink view:
being underlined among others). On the other hand it makes gitweb
to not write error messages when object is not found to web serwer
log; it also moves cost of getting type and SHA-1 validation to
when link is clicked, and not only viewed.
* SHA-1 of other objects: blobs, trees, tags are also hyperlinked
and lead to appropriate view (although in the case of tags it is
more natural to just use tag name).
* You can put shortened SHA-1 of commit in the commit message, and it
would be hyperlinked; it would be checked on clicking if abbrev is
unique.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make symbolic link target in "tree" view into hyperlink to generic
"object" view (as we don't know if the link target is file (blob) or
directory (tree), and if it exist at all).
Target of link is made into hyperlink when:
* hash_base is provided (otherwise we cannot find hash
of link target)
* link is relative
* in no place link goes out of root tree (top dir)
Full path of symlink target from the root dir is provided in the title
attribute of hyperlink.
Currently symbolic link name uses ordinary file style (hidden
hyperlink), while the hyperlink to symlink target uses default
hyperlink style, so it is underlined while link target which is not
made into hyperlink is not underlined.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add generic "object" view implemented in git_object subroutine, which is
used to display object of any type; to be more exact it redirects to the
view of correct type: "blob", "tree", "commit" or "tag". To identify object
you have to provide either hash (identifier of an object), or (in the case of
tree and blob objects) hash of commit object (hash_base) and path (file_name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In "tree" view (git_print_tree_entry subroutine), for entries which are
symbolic links, add " -> link_target" after file name (a la "ls -l").
Link target is _not_ hyperlinked.
While at it, correct whitespaces (tabs are for aling, spaces are for indent)
in modified git_print_tree_entry subroutine.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not use Content-Encoding: HTTP header in git_snapshot, using
instead type according to the snapshot type (compression type).
Some of web browser take Content-Encoding: to be _transparent_
also for downloading, and store decompressed file (with incorrect
compression suffix) on download.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the --numstat output for binary files from "0 0" to
"- -" to match what "apply --numstat" does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch uses git-apply to do the patching which simplifies the code a lot
and also uses one pass to git-diff. git-apply gives information on added,
removed files as well as which files are binary.
Removed the test for checking for matching binary files when deleting them
since git-apply happily deletes the file. This is matter of taste since we
allow some fuzz for text patches also.
Error handling was cleaned up, but not much tested.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The old code looked backwards from the email address to parse
the name, allowing an arbitrary number of spaces between the
two. However, in the case of no name, we looked back too far to
the 'author' (or 'Author:') header.
The bug was triggered by commit febf7ea4bed from linux-2.6.
Jeff King originally fixed it by looking back only one
character; Johannes Schindelin pointed out that we could try
harder while at it to cope with commits with broken headers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Originally noticed by Nicolas Pitre; the real cause was the code
was prepared to deal with [PATCH] (and [PATCH n/m whatever])
prefixes but forgot that the string can be indented while acting
as a filter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Make sure the empty tree exists when needed in merge-recursive.
Don't use memcpy when source and dest. buffers may overlap
no need to install manpages as executable
There are some baseless merge cases where git-merge-recursive will
try to compare one of the branches against the empty tree. However
most projects won't have the empty tree object in their object database
as Git does not normally create empty tree objects. If the empty tree
object is missing then the merge process will die, as it cannot load the
object from the database. The error message may make the user think that
their database is corrupt when its actually not.
So instead we should just create the empty tree object whenever it is
needed. If the object already exists as a loose object then no harm
done. Otherwise that loose object will be pruned away later by either
git-prune or git-prune-packed.
Thanks goes to Junio for suggesting this fix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-index-pack can call memcpy with overlapping source and destination
buffers. The patch below makes it use memmove instead.
If you want to demonstrate a failure, add the following two lines
+ if (input_offset < input_len)
+ abort ();
before the existing memcpy call (shown in the patch below),
and then run this:
(cd t; sh ./t5500-fetch-pack.sh)
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
No need to install manpages as executable. Noticed by Ville Skytt,Ad(B.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The command used to have a safety valve to prevent this sequence:
edit foo
git update-index foo
edit foo
git diff foo
git commit --only foo
The reason for this was because an inexperienced user might
mistakenly think what is shown with the last-minute diff
contains all the change that is being committed (instead, what
the user asked to check was an incremental diff since what has
been staged so far). However, this turns out to only annoy
people who know what they are doing. Inexperienced people
would not be using the first "update-index" anyway, in which
case they would see the full changes in the "git diff".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Data in rr-cache isn't valid after a patch application is
skipped or and aborted, so our next commit could be misrecorded
as a resolution of that skipped/failed commit, which is wrong.
git-am --skip, git-rebase --skip/--abort will automatically
invoke git-rerere clear to avoid this.
Also, since git-am --resolved indicates a resolution was
succesful, remember to run git-rerere to record the resolution
(and not surprise the user when the next commit is made).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Over time, unresolved rr-cache entries are accumulated and they
tend to get less and less likely to be useful as the tips of
branches advance.
Reorder documentation page to show the subcommand section earlier
than the discussion section.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-am and git-rebase will be updated to use 'clear', and
diff/status can be used to aid the user in tracking progress in
the resolution process.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Take Johannes Schindelin's suggestions for a further simplification of
the shared repository creation using git --bare init-db --shared, and
for a simplified cvsimport using an existing CVS working directory.
Also insert more man page references.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
cvs-migration.txt | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
The old code looked backwards from the email address to parse the name,
allowing an arbitrary number of spaces between the two. However, in the case
of no name, we looked back too far to the 'author' (or 'Author:') header.
Instead, remove at most one space between name and address.
The bug was triggered by commit febf7ea4bed from linux-2.6.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch clarifies the meaning of the branch.*.merge option.
Previously, if branch.*.merge was specified but did not match any
ref, the message "No changes." was not really helpful regarding
the misconfiguration. This patch adds a warning for this.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit f848718a broke the build in perl/ directory by
allowing the Makefile.PL to overwrite the now-tracked Makefile.
Fix this by forcing Makefile.PL to produce its output in
perl.mak as the broken commit originally intended.
Signed-off-by: Junio C Hamano <junkio@cox.net>
do_switch works with the SVN Perl bindings after r22312 in the
Subversion trunk. Since no released version of SVN currently
supports it; we'll just autodetect it and enable its usage
when a user has a recent-enough version of SVN.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update git-clone man page to reflect recent changes
(--use-separate-remote default and use of .git/config instead of
remotes files), and rewrite introduction.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At some point between v5.6 and 5.8 Perl started to assume its input,
output and filehandles are UTF-8. This breaks the counting of bytes
for the CVS protocol, resulting in the client expecting less data
than we actually send, and storing truncated files.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently the treshold is 5000. The likelihood of this value to ever be
crossed for a single push is really small making it not really useful.
The optimal treshold for a pure space saving on a filesystem with 4kb
blocks is 3. However this is likely to create many small packs
concentrating a large number of files in a single directory compared to
the same objects which are spread over 256 directories when loose. This
means we would need 512 objects per pack on average to approximagte the
same directory cost (a pack has 2 files because of the index).
But 512 is a really high value just like 5000 since most pushes are
unlikely to have that many objects. So let's try with a value of 100
which should have a good balance between small pushes going to be
exploded into loose objects and large pushes kept as whole packs.
This is not a replacement for periodic repacks of course.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Modify cvs-migration.txt so it explains first how to develop against a
shared repository, then how to set up a shared repository, then how to
import a repository from cvs. Though this seems chronologically
backwards, it's still readable in this order, and it puts the more
commonly needed material closer to the front.
Remove the annotate/pickaxe section; perhaps it can find a place elsewhere
in the future. Remove most of the "why git is better than cvs" stuff from
the introduction.
Add some minor clarifications, including two that have come up several
times on the mailing list:
1. Recommend committing any changes before running pull.
2. Note that changes must be commited before they can be pushed.
Update the clone discussion to reflect the new --use-separate-remotes
default, and add a brief mention of git-cvsserver.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without any specification in the .git/config file, git-pull will execute
"git-pull origin"; which in turn defaults to pull from the first "pull"
definition for the remote, "origin".
This is a difficult set of defaults to track for a new user, and it's
difficult to see what tells git to do this (especially when it is
actually hard-coded behaviour). To ameliorate this slightly, this patch
explicitly specifies the default behaviour during a clone using the
"branch" section of the config.
For example, a clone of a typical repository would create a .git/config
containing:
[remote "origin"]
url = proto://host/repo.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = origin
merge = refs/heads/master
The [branch "master"] section is such that there is no change to the
functionality of git-pull, but that functionality is now explicitly
documented.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
An earlier commit 3683dc5a broke the merge message generation with
a careless use of && where it was not needed, breaking the merge
message for cases where non branches are given.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Long-running fetches run inside children to avoid memory leaks.
When we refork, the connection in the parent can be idle for a
long time; attempting to reuse it in the next child can result
in timeouts.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow images in one of web formats (PNG, GIF, JPEG) - actually files
with mimetype of image/png, image/git, image/jpeg - to be displayed in
"blob" view using <img /> element, instead of using "blob_plain" view
for them, like for all other files except also text/* mimetype files.
This makes possible to easily go to file history, to HEAD version of
the file, to appropriate commit etc; all of those are not available
in "blob_plain" (raw) view.
Only text files can have "blame" view link in the formats part of
navbar.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While deciding if the new style command line argument is a tag
or a branch, we checked it with "git show-ref -s --verify" to
see if results in an error, but when it is not a branch, the
check leaked the error message out, which was not needed to be
shown to the end user.
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit a9cb3c6e changed git-commit to use the
contents of MERGE_MSG even when we do not have MERGE_HEAD (the
rationale is in its log message).
However, the change tricks the following sequence to include a
merge message in a completely unrelated commit:
$ git pull somewhere
: oops, the conflicts are too much. forget it.
$ git reset --hard
: work work work
$ git commit
To fix this confusion, this patch makes "git reset" to remove
the leftover MERGE_MSG that was prepared when the user abandoned
the merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Acked-by: Luben Tuikov <ltuikov@yahoo.com
Now merge-file also understands --stdout and --quiet options. While
at it, two compile warnings were fixed.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
merge-file has the same syntax as RCS merge, but supports only the
"-L" option.
For good measure, a test is added, which is quite minimal, though.
[jc: further fix for compliation errors included.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rename the section titles to make the "how-to" content of the section
obvious. Also clarify that changes have to be commited before they can
be pushed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It really is an important concept to grasp for people coming
from CVS. Even if it is briefly mentioned, it is not obvious
enough to sink in.
[jc: with wording updates from J. Bruce Fields]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the signature of rename_ref() in refs.[hc] to include a
logmessage for the reflogs.
Also, builtin-branch.c is modified to provide a proper logmessage + call
setup_ident() before any logmessages are written.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The current check for symlinked reflogs was based on stat(2), which is
utterly embarrassing.
Fix it, and add a matching testcase.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Extend git-branch with the following options:
git-branch -m|-M [<oldbranch>] newbranch
The -M variation is required to force renaming over an exsisting
branchname.
This also indroduces $GIT_DIR/RENAME_REF which is a "metabranch"
used when renaming branches. It will always hold the original sha1
for the latest renamed branch.
Additionally, if $GIT_DIR/logs/RENAME_REF exists, all branch rename
events are logged there.
Finally, some testcases are added to verify the new options.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses the previous update to read-tree in Porcelain-ish
commands "git checkout" and "git merge" to loosen the check
when switching branches.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This follows up commit ed93b449 where we removed overcautious
"working file will be lost" check.
A new option "--exclude-per-directory=.gitignore" can be used to
tell the "git-read-tree" command that the user does not mind
losing contents in untracked files in the working tree, if they
need to be overwritten by a merge (either a two-way "switch
branches" merge, or a three-way merge).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Suppose you have changes in new1 to the original lines 10-20,
and changes in new2 to the original lines 15-25, then the
changes to 10-25 conflict. But it is possible that the next
changes in new1 still overlap with this change to new2.
So, in the next iteration we have to look at the same change
to new2 again.
The old code tried to be a bit too clever. The new code is
shorter and more to the point: do not fiddle with the ranges
at all.
Also, xdl_append_merge() tries harder to combine conflicts.
This is necessary, because with the above simplification,
some conflicts would not be recognized as conflicts otherwise:
In the above scenario, it is possible that there is no other
change to new1. Absent the combine logic, the change in new2
would be recorded _again_, but as a non-conflict.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
This brings the power of the index up front using a proper mental model
without talking about the index at all. See for example how all the
technical discussion has been evacuated from the git-add man page.
Any content to be committed must be added together. Whether that
content comes from new files or modified files doesn't matter. You
just need to "add" it, either with git-add, or by providing
git-commit with -a (for already known files only of course).
No need for a separate command to distinguish new vs modified files
please. That would only screw the mental model everybody should have
when using GIT.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document git diff options -b / --ignore-space-change and
-w / --ignore-all-space, introduced by Johannes Schindelin
in commit 0d21efa5, "Teach diff about -b and -w flags".
The description of options is taken from GNU diff man page and
GNU Diffutils info documentation.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is _not_ the same as "treat eol as whitespace", since that would mean
that multiple empty lines would be treated as equal to e.g. a space.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
receive-pack: do not insist on fast-forward outside refs/heads/
git-mv: search more precisely for source directory in index
Conflicts:
receive-pack.c
The structure that ends with a flexible array member (or 0
length array with older GCC) "char name[FLEX_ARRAY]" is
allocated on the stack and we use it after clearing its entire
size with memset. That does not guarantee that "name" is
properly NUL terminated as we intended on platforms with more
forgiving structure alignment requirements.
Reported breakage on m68k by Roman Zippel.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There was a little bug in the brace expansion which should remove
the ^{} from the tagname. It used ${name#'^{}'} instead of $(name%'^{}'},
the difference is that '#' will remove the given pattern only from the
beginning of a string and '%' only from the end of a string.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With making --use-separate-remote default when creating non-bare
clone, there was need for the flag which would turn off this behavior.
It was called --use-immingled-remote.
Immingle means to blend, to combine into one, to intermingle, but it
is a bit obscure word. I think it would be better to use simply
--no-separate-remote as the opposite to --use-separate-remote
option to git clone.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix contents of Atom feed <logo> element; it should be URL
of $logo, not URL pointed by logo link.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On Cygwin + ActivateState Perl, Makefile generated with
MakeMaker is not usable because of line-endings and
back-slashes.
This teaches perl/Makefile to write a handcrafted equivalent
perl.mak file with 'make NO_PERL_MAKEMAKER=NoThanks'.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Linus recommended this, otherwise any renames cause the
diffstat output to be ridiculous in some circumstances.
Because the corresponding "git-pull" done when the requestee
actually makes pull shows the stat with rename detection
enabled, it makes sense to match what the request message
includes to that output, to make the result easier to verify.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise, an executable script in git would end up being
checked into the CVS repository without the execute bit.
[jc: with an additional test script from Robin Rosenberg.]
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A move of a directory should find the entries in the index by
searching for the name _including_ the slash. Otherwise, the
directory can be shadowed by a file when it matches the prefix
and is lexicographically smaller, e.g. "ab.c" shadows "ab/".
Noticed by Sergey Vlasov.
[jc: added Sergey's original reproduction recipe as a test case
at the end of t7001.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If one side's block (of changed lines) ends later than the other
side's block, the former should be tested against the next block
of the other side, not vice versa.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The line range is i1 .. (i1 + chg1 - 1), not i1 .. (i1 + chg1).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The callers would want to know if the resulting merge is clean;
do not discard that information away after calling xdl_do_merge().
Signed-off-by: Junio C Hamano <junkio@cox.net>
This new function implements the functionality of RCS merge, but
in-memory. It returns < 0 on error, otherwise the number of conflicts.
Finding the conflicting lines can be a very expensive task. You can
control the eagerness of this algorithm:
- a level value of 0 means that all overlapping changes are treated
as conflicts,
- a value of 1 means that if the overlapping changes are identical,
it is not treated as a conflict.
- If you set level to 2, overlapping changes will be analyzed, so that
almost identical changes will not result in huge conflicts. Rather,
only the conflicting lines will be shown inside conflict markers.
With each increasing level, the algorithm gets slower, but more accurate.
Note that the code for level 2 depends on the simple definition of
mmfile_t specific to git, and therefore it will be harder to port that
to LibXDiff.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
SVN is not entirely consistent in returning log information and
sometimes returns file information when adding subdirectories,
and sometimes it does not (only returning information about the
directory that was added). This caused git-svn to occasionally
add a file to the list of files to be fetched twice. Now we
change the data structure to be hash to avoid repeated fetches.
As of now (in master), this only affects repositories fetched
without deltas enabled (file://, and when manually overriden
with GIT_SVN_DELTA_FETCH=0); so this bug mainly affects users of
1.4.4.1 and maint.
Thanks to Florian Weimer for reporting this bug.
[jc: backported for maint]
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a repository with core.warnambiguousrefs turned off, and with
a branch and a tag that have the same name 'frotz',
git merge frotz
would merge the commit pointed at by the tag 'frotz' but
incorrectly would identify what was merged as 'branch frotz' in
the merge message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The fact that git has previously used symbolic links for representing
symbolic refs doesn't seem relevant to the current function of
git-symbolic-ref. This patch makes less of a big deal about the
symbolic link history and instead focuses on what git does now.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
'git diff --cached' still works, but its use is discouraged
in the documentation. 'git diff --index' does the same thing
and is consistent with how 'git apply --index' works.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without this patch "git commit file.c file2.c" produces the not
so stellar output:
error: pathspec 'file.c' did not match any.
error: pathspec 'file2.c' did not match any.
With this patch, the output is changed to:
error: pathspec 'file.c' did not match any file(s) known to git.
error: pathspec 'file2.c' did not match any file(s) known to git.
Did you forget to 'git add'?
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The final 'nr_result' and 'written' values must always be the same
otherwise we're in deep trouble. So let's remove a redundent report.
And for paranoia sake let's make sure those two variables are actually
equal after all objects are written (one never knows).
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* branch 'maint':
Document git-repo-config --bool/--int options.
tutorial: talk about user.name early and don't start with commit -a
git-blame: fix rev parameter handling.
Introducing yourself to git early would be a good idea; otherwise
the user may not find the mistake until much later when "git log"
is learned.
Teaching "commit -a" without saying that it is a shortcut for
listing the paths to commit leaves the user puzzled. Teach the
form with explicit paths first.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We lacked "--" termination in the underlying init_revisions() call
which made it impossible to specify a revision that happens to
have the same name as an existing file.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/globfetch:
fetch-pack: do not barf when duplicate re patterns are given
git-fetch: allow forcing glob pattern in refspec
git-fetch: allow glob pattern in refspec
git-fetch: fix dumb protocol transport to fetch from pack-pruned ref
git-fetch: reuse ls-remote result.
We used to get the case that more than two paths came from the
same commit wrong when computing the output width and deciding
to turn on --show-name option automatically. When we find that
lines that came from a path that is different from what we
started digging from, we should always turn --show-name on, and
we should count the name length for all files involved.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After the bugfix to connect to repositories where the user has
limited read permissions, multi-init was broken due to our
SVN::Ra connection being limited to working in a subdirectory;
so we now create a new Ra connection for init-ing branches
and another for tags
Along with that fix, allow the user to use the command-line
option flags for multi-init (--revision being the most notable;
but also --no-auth-cache, --config-dir, --username (for passing
to SVN), and --shared/--template for passing to git-init-db
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Eliminate 'commit' from some places and plug 'dcommit' more.
Also update the section --id (GIT_SVN_ID) usage since we
have multi-init/multi-fetch now.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* match LESS environment settings to those in pager.c
* parse diff.color and pager.color settings in the
config file, and pass --color to git-log
* --color and --pager= settings are supported
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also remove asterisks for readability, and suggest use of
git-config for easy cut & pasting.
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 35e65ecc broke completion of local refs, e.g. "git pull . fo<tab>"
no longer would complete to "foo". Instead it printed out an internal
git error ("fatal: Not a git repository: '.'").
The break occurred when I tried to improve performance by switching from
git-peek-remote to git-for-each-ref. Apparently git-peek-remote will
drop into directory "$1/.git" (where $1 is its first parameter) if it
is given a repository with a working directory. This allowed the bash
completion code to work properly even though it was not handing over
the true repository directory.
So now we do a stat in bash to see if we need to add "/.git" to the
path string before running any command with --git-dir.
I also tried to optimize away two "git rev-parse --git-dir" invocations
in common cases like "git log fo<tab>" as typically the user is in the
top level directory of their project and therefore the .git subdirectory
is in the current working directory. This should make a difference on
systems where fork+exec might take a little while.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There was nothing printed in the code originally because I left
out a pair of parentheses. Nevertheless, the affected code has
been replaced with a more efficient version that respects the -q
flag as well as requiring less bandwidth.
We save some bandwidth by not requesting changed paths
information when calling get_log() since we're using the delta
fetcher.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
finish_report does seem to return a useful value indicating success
or failure, so we'll just set a flag when close_edit is called
(it is not called on failures, nor is abort_edit) and check
the flag before proceeding.
Thanks to Pazu for pointing this out.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't force the user to specify more than one revision parameter,
thus making git-shortlog behave more like git-log.
'git-shortlog master' will now produce the expected results; the
other end of the range simply is the (oldest) root commit.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* Enable test for delta transfers in full-svn-test.
* Run tests against the root of the repository so we won't have
to revisit 308906fa6e and
efe4631def again.
The graft-branches test still runs as before.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This should drastically reduce bandwidth used for network
transfers. This is not enabled for file:// repositories by
default because of the increased CPU usage and I/O needed.
GIT_SVN_DELTA_FETCH may be set to a true value to enable or
false (0) to disable delta transfers regardless of the
repository type.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than use a separate config .git/remotes/ for remote shortcuts, this
patch adds the analagous definitions to .git/config using git-repo-config
calls.
For example what was previously .git/remotes/origin
URL: proto://host/path
Pull: refs/heads/master:refs/heads/origin
Is now added to .git/config as
[remote "origin"]
url = proto://host/path
fetch = refs/heads/master:refs/heads/origin
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to try loose objects first with sha1_object_info(), but packed
objects first with read_sha1_file(). Now, prefer packed objects over loose
ones with sha1_object_info(), too.
Usually the old behaviour would pose no problem, but when you tried to fix
a fscked up repository by inserting a known-good pack,
git cat-file $(git cat-file -t <sha1>) <sha1>
could fail, even when
git cat-file blob <sha1>
would _not_ fail. Worse, a repack would fail, too.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On request of the kingpenguin, shortlog now uses the pager if output
goes to a tty.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This should not change any functionality, but just makes it readable by
having a space between syntactic construct keyword and open parenthesis
(e.g. "if (expr", not "if(expr") and between close parenthesis and open
brace (e.g. "if (expr) {" not "if (expr){").
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows users to use HTTP proxy information (among other settings)
from ~/.subversion/servers and ~/.subversion/config
--config-dir (as before) may be passed to git-svn to override the
default choice of '~/.subversion' for the configuration directory.
Thanks to tko on #git for pointing this out.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since the user's git installation is not likely to grow a new command
or merge strategy in the lifespan of the current shell process we can
save time during completion operations by caching these lists during
sourcing of the completion support.
If the git executable is not available or we run into errors while
caching at load time then we defer these to runtime and generate
the list on the fly. This might happen if the user doesn't put git
into their PATH until after the completion script gets sourced.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because git-merge and git-rebase both accept -s, --strategy or --strategy=
we should recognize all three formats in the bash completion functions and
issue back all merge strategies on demand.
I also moved the prior word testing to be before the current word testing,
as the current word cannot be completed with -- if the prior word was an
option which requires a parameter, such as -s or --strategy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a really ugly completion script for git-repo-config, but it has
some nice properties. I've added all of the documented configuration
parameters from Documentation/config.txt to the script, allowing the
user to complete any standard configuration parameter name.
We also have some intelligence for the remote.*.* and branch.*.* keys
by completing not only the key name (e.g. remote.origin) but also the
values (e.g. remote.*.fetch completes to the branches available on the
corresponding remote).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that people are really likely to start using separate remotes
(due to the default in git-clone changing) we should support ref
completion for these refs in as many commands as possible.
While we are working on this routine we should use for-each-ref
to obtain a list of local refs, as this should run faster than
peek-remote as it does not need to dereference tag objects in
order to produce the list of refs back to us. It should also
be more friendly to users of StGIT as we won't generate a list
of the StGIT metadata refs.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Typing out options to git log/show/whatchanged can take a while, but
we can easily complete them with bash. So list the most common ones,
especially --pretty=online|short|medium|... so that users don't need
to type everything out.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As git-rebase is a popular command bash should know how to complete
reference names and its long options. We only support completions
which make sense given the current state of the repository, that
way users don't get shown --continue/--skip/--abort on the first
execution.
Also added support for long option --strategy to git-merge, as I
missed that option earlier and just noticed it while implementing
git-rebase.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Provide completion for currently known long options supported by
git-format-patch as well as the revision list specification argument,
which is generally either a refname or in the form a..b.
Since _git_log was the only code that knew how to complete a..b, but
we want to start adding option support to _git_log also refactor the
a..b completion logic out into its own function.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Many users want to display the current branch name of the current git
repository as part of their PS1 prompt, much as their PS1 prompt might
also display the current working directory name.
We don't force our own PS1 onto the user. Instead we let them craft
their own PS1 string and offer them the function __git_ps1 which they
can invoke to obtain either "" (when not in a git repository) or
"(%s)" where %s is the name of the current branch, as read from HEAD,
with the leading refs/heads/ removed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Users generally are not going to need to invoke plumbing-level commands
from within one line shell commands. If they are invoking these commands
then it is likely that they are glueing them together into a shell script
to perform an action, in which case bash completion for these commands is
of relatively little use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-merge is high-level Porcelain users are going to expect
to be able to use it from the command line, in which case we really
should also be able to complete ref names as parameters.
I'm also including completion support for the merge strategies
that are supported by git-merge.sh, should the user wish to use a
different strategy than their default.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Git no longer calls an external diff program to generate patches.
Remove the documentation which suggests that you can pass
arbitrary diff options via the GIT_DIFF_OPTS environment variable.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/shortlog:
git-shortlog: make common repository prefix configurable with .mailmap
git-shortlog: fix common repository prefix abbreviation.
builtin git-shortlog is broken
shortlog: fix "-n"
shortlog: handle email addresses case-insensitively
shortlog: read mailmap from ./.mailmap again
shortlog: do not crash on parsing "[PATCH"
Build in shortlog
* branch 'jc/merge':
git-merge: do not leak rev-parse output used for checking internally.
git-merge: tighten error checking.
merge: allow merging into a yet-to-be-born branch.
git-merge: make it usable as the first class UI
remove merge-recursive-old
If a branch name to be merged is misspelled, the command leaked error
messages from underlying plumbing commands, which were helpful only
to people who know how the command are implemented to diagnose the
breakage, but simply puzzling and unhelpful for the end users.
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>
We used to skip unmerged entries, which made sense for grepping
in the cached copies, but not for grepping in the working tree.
Noticed by Johannes Sixt.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jn/web:
gitweb: Make project description in projects list link to summary view
gitweb: Use author_epoch for pubdate in gitweb feeds
gitweb: Add author and contributor email to Atom feed
gitweb: Add author and committer email extraction to parse_commit
gitweb: Use git-show-ref instead of git-peek-remote
gitweb: Do not use esc_html in esc_path
Attempt to clarify somewhat the difference between pull and merge,
and give a little more details on the pull syntax.
I'm still not happy with this section: the explanation of the origin
branch isn't great, but maybe that should be left alone pending the
use-separate-remotes change; and we need to explain how to set up a
public repository and push to it.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make (shortened) project description in the "projects list" view
hyperlink to the "summary" view of the project. Project names are
sometimes short; having project description be hyperling gives larger
are to click. While at it, display full description on mouseover via
'title' attribute to introduced link.
Additionally, fix whitespace usage in modified git_project_list_body
subroutine: tabs are for indent, spaces are for align.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I broke this again in 747fa12cef.
Thanks to merlyn for pointing this out to me on IRC.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use creation date (author_epoch) instead of former commit date
(committer_epoch) as publish date in gitweb feeds (RSS, Atom).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add author email (from 'author_email') and contributor email (from
'committer_email') to items in the Atom format gitweb feed.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Extract author email to 'author_email' key, and comitter mail to
'committer_mail' key; uniquify committer and author lines handling
by the way.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use "git show-ref --dereference" instead of "git peek-remote
$projectroot/project" in git_get_references. git-show-ref is faster
than git-peek-remote (40ms vs 56ms user+sys for git.git repository);
even faster is reading info/refs file (if it exists), but the
information in info/refs can be stale; that and the fact that
info/refs is meant for dumb protocol transports, not for gitweb.
git-show-ref is available since v1.4.4; the output format is slightly
different than git-peek-remote output format, but we accept both.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not use esc_html in esc_path subroutine to avoid double quoting;
expand esc_html body (except quoting) in esc_path.
Move esc_path before quot_cec and quot_upr. Add some comments.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Building on top of the earlier refspec glob pattern enhancement,
this allows a glob pattern to say the updates should be forced
by prefixing it with '+' as usual, like this:
Pull: +refs/heads/*:refs/remotes/origin/*
Signed-off-by: Junio C Hamano <junkio@cox.net>
When update_local_ref() refuses to update a branch head due to
fast-forward check, it was not propagated properly in the call
chain and the command did not exit with non-zero status as a
result.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
Sometimes people accidentally commit files in wrong mode bits.
Show --summary output for the HEAD commit after successful commit
as a final sanity check.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code had "/pub/scm/linux/kernel/git/" hardcoded which was
too specific to the kernel project.
With this, a line in the .mailmap file:
# repo-abbrev: /pub/scm/linux/kernel/git/
can be used to cause the substring to be abbreviated to /.../
on the title line of the commit message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
Some versions of the SVN libraries cause die() to exit with 255,
and 40cf043389 tightened up
test_expect_failure to reject return values >128.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes users are given only read access to a subtree inside a
repository, and git-svn could not read log information (and thus
fetch commits) when connecting a session to the root of the
repository. We now start an SVN::Ra session with the full URL
of what we're tracking, and not the repository root as before.
This change was made much easier with a cleanup of
repo_path_split() usage as well as improving the accounting of
authentication batons.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "git branch -D other_branch" work even when HEAD
points at a yet-to-be-born branch.
Earlier, we checked the HEAD ref for the purpose of "subset"
check even when the deletion was forced (i.e. not -d but -D).
Because of this, you cannot delete a branch even with -D while
on a yet-to-be-born branch.
With this change, the following sequence that now works:
mkdir newdir && cd newdir
git init-db
git fetch -k $other_repo refs/heads/master:refs/heads/othre
# oops, typo
git branch other othre
git branch -D othre
Signed-off-by: Junio C Hamano <junkio@cox.net>
The new -v option makes git-branch show the abbreviated sha1 + subjectline
for each branch.
Additionally, minimum abbreviation length can be specified with
--abbrev=<length>
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most notably, the original code first copied refs/remotes/ that
remote side had to local, and overwrote them by mapping refs/heads/
from the remote when a dumb protocol transport was used.
This makes the clone behaviour by dumb protocol in line with the
git native and rsync transports.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
It seems that gitweb tries to consistently use chomp without parentheses
around its operands, but there were two places that said "chomp($var);".
Let's be consistent.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit messages had SPC replaced with entity;
make it so also in tag message (tag comment).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
This allows you to say
git send-pack $URL :refs/heads/$branch
to delete the named remote branch. The refspec $src:$dst means
replace the destination ref with the object known as $src on the
local side, so this is a natural extension to make an empty $src
mean "No object" to delete the target.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jn/web:
gitweb: Finish restoring "blob" links in git_difftree_body
gitweb: Refactor feed generation, make output prettier, add Atom feed
gitweb: Add an option to href() to return full URL
gitweb: New improved formatting of chunk header in diff
gitweb: Default to $hash_base or HEAD for $hash in "commit" and "commitdiff"
gitweb: Buffer diff header to deal with split patches + git_patchset_body refactoring
gitweb: Protect against possible warning in git_commitdiff
It passed (const char*) to a function that took a (char *); the
buffer itself was of course writable, so pass the buffer itself.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is mostly gleaned off SVN::Mirror, with added support for
--no-auth-cache and --config-dir.
Even with this patch, git-svn does not yet support repositories
where the user only has partial read permissions.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch adds support for 'proxy' and 'proxyport' connection options
when using the pserver method for the CVS Root.
It has been tested with a Squid 2.5.x proxy server.
Quoting from the CVS info manual:
The `gserver' and `pserver' connection methods all accept optional
method options, specified as part of the METHOD string, like so:
:METHOD[;OPTION=ARG...]:
Currently, the only two valid connection options are `proxy', which
takes a hostname as an argument, and `proxyport', which takes a port
number as an argument. These options can be used to connect via an HTTP
tunnel style web proxy. For example, to connect pserver via a web proxy
at www.myproxy.net and port 8000, you would use a method of:
:pserver;proxy=www.myproxy.net;proxyport=8000:
*NOTE: The rest of the connection string is required to connect to
the server as noted in the upcoming sections on password authentication,
gserver and kserver. The example above would only modify the METHOD
portion of the repository name.*
PROXY must be supplied to connect to a CVS server via a proxy
server, but PROXYPORT will default to port 8080 if not supplied.
PROXYPORT may also be set via the CVS_PROXY_PORT environment variable.
Signed-off-by: Iñaki Arenaza <iarenuno@eteo.mondragon.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We've talked about this for quite some time on the list, and it
is a sane thing to do for a repository with an associcated
working tree.
For somebody who wants to use the traditional layout, there is a
backward compatibility option --use-immingled-remote, but it is
expected to be removed before the next major release.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the refname matching logic used to decide which ref
is updated with git-send-pack. We used to error out when
pushing 'master' when the other end has both 'master' branch and
a tracking branch 'remotes/$name/master' but with this, 'master'
matches only 'refs/heads/master' when both and no other 'master'
exist.
Pushing 'foo' when both heads/foo and tags/foo exist at the
remote end is still considered an error and you would need to
disambiguate between them by being more explicit.
When neither heads/foo nor tags/foo exists at the remote,
pushing 'foo' when there is only remotes/origin/foo is not
ambiguous, while it still is ambiguous when there are more than
one such weaker match (remotes/origin/foo and remotes/alt/foo,
for example).
Signed-off-by: Junio C Hamano <junkio@cox.net>
In xemit.c:xdl_emit_diff() a buffer for showing the function name as
commentary is allocated; this buffer was 40 characters. This is a bit
small; particularly for C++ function names where there is often an
identical prefix (like void LongNamespace::LongClassName) on multiple
functions, which makes the context the same everywhere. In other words
the context is useless. This patch increases that buffer to 80
characters - which may still not be enough, but is better
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
This adds Andy's refspec glob. You can have a single line:
Pull: refs/heads/*:refs/remotes/origin/*
in your ".git/remotes/origin" and say "git fetch" to retrieve
all refs under heads/ at the remote side to remotes/origin/ in
the local repository.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, commit walkers downloaded loose refs from refs/ hierarchy
of the remote side to find where to start walking; this would
not work for a repository whose refs are packed and then pruned.
With the previous change, we have ls-remote output from the
remote in-core; we can use the value from there without
requiring loose refs anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This will become necessary to update the dumb protocol
transports to fetch from a repository with packed and then
pruned tags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using dcommit could cause the user to lose uncommitted changes
during the reset --hard operation, so change it to reset --mixed.
If dcommit chooses the rebase path, then git-rebase will already
error out when local changes are made.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
some SVN repositories have a revision 0 (committed by no author
and no date) when created; so when we need to ensure that we
check any revision variables are defined, and not just
non-zero.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
dcommit would unconditionally append "~1" to a commit in order
to generate a diff. Now we generate a meaningful error message
if we try to generate an impossible diff.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We can't rely on sizeof(struct zip_*) returning the sum of
all struct members. At least on ARM padding is added at the
end, as Gerrit Pape reported. This fixes the problem but
still lets the compiler do the summing by introducing
explicit padding at the end of the structs and then taking
its offset as the combined size of the preceding members.
As Junio correctly notes, the _end[] marker array's size
must be greater than zero for compatibility with compilers
other than gcc. The space wasted by the markers can safely
be neglected because we only have one instance of each
struct, i.e. in sum 3 wasted bytes on i386, and 0 on ARM. :)
We still rely on the compiler to not add padding between the
struct members, but that's reasonable given that all of them
are unsigned char arrays.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It seems that under Mac OS X, the menus get some extra entries (or
possibly fewer entries), leading to references to entries by an
absolute number being off. This leads to an error when invoking
gitk --all under Mac OS X, because the "Edit view" and "Delete view"
entries aren't were gitk expects them, and so enabling them gives an
error.
This changes the code so it refers to menu entries by their content,
which should solve the problem.
Signed-off-by: Paul Mackerras <paulus@samba.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>
This fixes the previous implementation which failed to optimize
repositories with tons of lightweight tags. The updated
packed-refs format begins with "# packed-refs with:" line that
lists the kind of extended data the file records. Currently,
there is only one such extension defined, "peeled". This stores
the "peeled tag" on a line that immediately follows a line for a
tag object itself in the format "^<sha-1>".
The header line itself and any extended data are ignored by
older implementation, so packed-refs file generated with this
version can still be used by older git. packed-refs made by
older git can of course be used with this version.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somebody was wondering on #git channel why a git generated diff
does not apply with GNU patch when the filename contains a SP.
It is because GNU patch expects to find TAB (and trailing timestamp)
on ---/+++ (old_name and new_name) lines after the filenames.
The "diff --git" output format was carefully designed to be
compatible with GNU patch where it can, but whitespace
characters were always a pain.
This adds an extra TAB (but not trailing timestamp) to old_name
and new_name lines of git-diff output when the filename has a SP
in it. An earlier patch updated git-apply to prepare for this.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of storing a list of refnames in append_ref, a list of
structures is created. Each of these stores the refname and a
symbolic constant representing its type.
The creation of the list is filtered based on a command line
switch; no switch means "local branches only", "-r" means "remote
branches only" (as they always did); but now "-a" means "local
branches or remote branches".
As a side effect, the list is now not global, but allocated in
print_ref_list() where it used.
Also a memory leak is plugged, the memory allocated during the
list creation was never freed.
It lays a groundwork to also display tags, but the command being
'git branch' it is not currently used.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches the oft-requested syntax
git merge $commit
to implement merging the named commit to the current branch.
This hopefully would make "git merge" usable as the first class
UI instead of being a mere backend for "git pull".
Most notably, $commit above can be any committish, so you can
say for example:
git merge js/shortlog~2
to merge early part of a topic branch without merging the rest
of it.
A custom merge message can be given with the new --message=<msg>
parameter. The message is prepended in front of the usual
"Merge ..." message autogenerated with fmt-merge-message.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
prune_object() in show_only mode would previously just show the path to the
object that would be deleted. The path the object is stored in shouldn't be
shown to users, they only know about sha1 identifiers so show that instead.
Further, the sha1 alone isn't that useful for examining what is going to be
deleted. This patch also adds the object type to the output, which makes it
easy to pick out, say, the commits and use git-show to display them.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This finishes work started by commit 4777b0141a
"gitweb: Restore object-named links in item lists"
by Petr Baudis. It brings back rest of "blob" links in difftree-raw
like part of "commit" and "commitdiff" views, namely in
git_difftree_body subroutine.
Now the td.link table cell has the following links:
* link to diff ("blobdiff" view) in "commit" view, if applicable
(there is no link to uninteresting creation/deletion diff), or
link to patch anchor in "commitdiff" view.
* link to current version of file ("blob" view), with the obvious
exception of file deletion, where it is link to the parent
version.
* link to "blame" view, if it is enabled, and file was not just
created (i.e. it has any history).
* link to history of the file ("history" view), again with sole
exception of the case of new file.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add support for more modern Atom web feed format. Both RSS and Atom
feeds are generated by git_feed subroutine to avoid code duplication;
git_rss and git_atom are thin wrappers around git_feed. Add links to
Atom feed in HTML header and in page footer (but not in OPML; we
should use APP, Atom Publishing Proptocol instead).
Allow for feed generation for branches other than current (HEAD)
branch, and for generation of feeds for file or directory history.
Do not use "pre ${\sub_returning_scalar(...)} post" trick, but join
strings instead: "pre " . sub_returning_scalar(...) . " post".
Use href(-full=>1, ...) instead of hand-crafting gitweb urls.
Make output prettier:
* Use title similar to the title of web page
* Use project description (if exists) for description/subtitle
* Do not add anything (committer name, commit date) to feed entry title
* Wrap the commit message in <pre>
* Make file names into an unordered list
* Add links (diff, conditional blame, history) to the file list.
In addition to the above points, the attached patch emits a
Last-Changed: HTTP response header field, and doesn't compute the feed
body if the HTTP request type was HEAD. This helps keep the web server
load down for well-behaved feed readers that check if the feed needs
updating.
If browser (feed reader) sent Accept: header, and it prefers 'text/xml' type
to 'application/rss+xml' (in the case of RSS feed) or 'application/atom+xml'
(in the case of Atom feed), then use 'text/xml' as content type.
Both RSS and Atom feeds validate at http://feedvalidator.org
and at http://validator.w3.org/feed/
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Andreas Fuchs <asf@boinkor.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
href subroutine by default generates absolute URL (generated using
CGI::url(-absolute=>1), and saved in $my_uri) using $my_uri as base;
add an option to generate full URL using $my_url as base.
New feature usage: href(..., -full=>1)
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we have provided enough info, and diff is not combined diff,
and if provided diff line is chunk header, then:
* split chunk header into .chunk_info and .section span elements,
first containing proper chunk header, second section heading
(aka. which function), for separate styling: the proper chunk
header is on non-white background, section heading part uses
slightly lighter color.
* hyperlink from-file-range to starting line of from-file, if file
was not created.
* hyperlink to-file-range to starting line of to-file, if file
was not deleted.
Links are of invisible variety (and "list" class).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Set $hash parameter to $hash_base || "HEAD" if it is not set (if it is
not true to be more exact). This allows [hand-edited] URLs with 'action'
"commit" or "commitdiff" but without 'hash' parameter.
If there is 'h' (hash) parameter provided, then gitweb tries
to use this. HEAD is used _only_ if nether hash, nor hash_base
are provided, i.e. for URL like below
URL?p=project.git;a=commit
i.e. without neither 'h' nor 'hb'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There are some cases when one line from "raw" git-diff output (raw format)
corresponds to more than one patch in the patchset git-diff output. To deal
with this buffer git diff header and extended diff header (everything up to
actual patch) to check from information from "index <hash>..<hash>" extended
header line if the patch corresponds to the same or next difftree raw line.
This could also be used to gather information needed for hyperlinking, and
used for printing gitweb quoted filenames, from extended diff header instead
of raw git-diff output.
While at it, refactor git_patchset_body subroutine from the event-driven,
AWK-like state-machine parsing to sequential parsing: for each patch
parse (and output) git diff header, parse extended diff header, parse two-line
from-file/to-file diff header, parse patch itself; patch ends with the end
of input [file] or the line matching m/^diff /.
For better understanding the code, there were added assertions in the
comments a la Carp::Assert module. Just in case there is commented out code
dealing with unexpected end of input (should not happen, hence commented
out).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We may read an undef from <$fd> and unconditionally chomping it
would result in a warning.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Another small patch to fix the output result to be conform with the
perl version.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since it is now a builtin optionally taking a range, we have to parse
the options before the rev machinery, to be able to shadow the short
hand "-n" for "--max-count".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
While at it, remove the linux specific mailmap into
contrib/mailmap.linux.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Annoyingly, it looked for the closing bracket in the author name
instead of in the message, and then accessed the NULL pointer.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: with minimum squelching of compiler warning under "-pedantic"
compilation options.]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
The heuristics to give up deltification when both the source and the
target are both in the same pack affects negatively when we are
repacking the subset of objects in the existing pack. This caused
any incremental updates to use suboptimal packs. Tweak the heuristics
to avoid this problem.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
We do not even know number of lines so showing it as 0 0 is
lying. This would also help Porcelains like cvsexportcommit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
When the downloader has more roots than we do, we will see many
"have" that leads to the root we do not have and let the other
side walk all the way to that root. Tell them to stop sending the
branch'es ancestors by sending a fake "ACK" when we already have
common ancestor for the wanted refs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
2006-08-12 22:51:53 -07:00
880 changed files with 94021 additions and 25106 deletions
Specify that the git repository is to be shared amongst several users. This
allows users belonging to the same group to push into that
repository. When specified, the config variable "core.sharedRepository" is
set so that files and directories under `$GIT_DIR` are created with the
requested permissions. When not specified, git will use permissions reported
by umask(2).
The option can have the following values, defaulting to 'group' if no value
is given:
- 'umask' (or 'false'): Use permissions reported by umask(2). The default,
when `--shared` is not specified.
- 'group' (or 'true'): Make the repository group-writable, (and g+sx, since
the git group may be not the primary group of all users).
- 'all' (or 'world' or 'everybody'): Same as 'group', but make the repository
readable by all users.
By default, the configuration flag receive.denyNonFastforward is enabled
in shared repositories, so that you cannot force a non fast-forwarding push
into it.
--
DESCRIPTION
-----------
This command creates an empty git repository - basically a `.git` directory
with subdirectories for `objects`, `refs/heads`, `refs/tags`, and
template files.
An initial `HEAD` file that references the HEAD of the master branch
is also created.
If the `$GIT_DIR` environment variable is set then it specifies a path
to use instead of `./.git` for the base of the repository.
If the object storage directory is specified via the `$GIT_OBJECT_DIRECTORY`
environment variable then the sha1 directories are created underneath -
otherwise the default `$GIT_DIR/objects` directory is used.
Running `git-init` in an existing repository is safe. It will not overwrite
things that are already there. The primary reason for rerunning `git-init`
is to pick up newly added templates.
Note that `git-init` is the same as `git-init-db`. The command
was primarily meant to initialize the object database, but over
time it has become responsible for setting up the other aspects
of the repository, such as installing the default hooks and
setting the configuration variables. The old name is retained
for backward compatibility reasons.
EXAMPLES
--------
Start a new git repository for an existing code base::
+
----------------
$ cd /path/to/my/codebase
$ git-init <1>
$ git-add . <2>
----------------
+
<1> prepare /path/to/my/codebase/.git directory
<2> add all existing file to the index
Author
------
Written by Linus Torvalds <torvalds@osdl.org>
Documentation
--------------
Documentation by David Greaves, Junio C Hamano and the git-list <git@vger.kernel.org>.
GIT
---
Part of the gitlink:git[7] suite
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.
