Use xmkstemp() instead of mkstemp()
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>
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>
Introduces xmkstemp()
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>
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>
Avoid ambiguous error message if pack.idx header is wrong
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>
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>
merge-recursive: do not rudely die on binary merge
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>
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>
Add --log-size to git log to print message size
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>
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>
git-diff: squelch "empty" diffs
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>
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>
Improved hint on how to set identity
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>
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>
Add a test for git-commit being confused by relative GIT_DIR
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-sh-setup.sh: make GIT_DIR absolute
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>
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>
Allow git-svnimport to take "" as the trunk directory.
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>
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>
Fix t5701-clone-local for white space from wc
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-p4: Fix the sorting of changelists when cloning a Perforce repository.
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>
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>
diff: don't run pager if user asked for a diff style exit code
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>
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>
builtin-bundle create - use lock_file
"git bundle create" left an invalid, partially written bundle if
an error occured during creation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
"git bundle create" left an invalid, partially written bundle if
an error occured during creation.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t3902 - skip test if file system doesn't support HT in names
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>
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>
git-add: Add support for --refresh option.
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>
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>
t3404: fix "fake-editor"
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>
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>
git.el: Always set the current directory in the git-diff buffer.
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>
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>
git.el: Add support for interactive diffs.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'master' of git://git./gitk/gitk
* '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
* '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
gitk: Fix bug causing Tcl error when updating graph
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>
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>
gitk: Fix bug introduced in commit 67a4f1a7
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>
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>
[PATCH] gitk: Show an error and exit if no .git could be found
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>
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>
[PATCH] gitk: Continue and show error message in new repos
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>
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>
[PATCH] gitk: Handle MouseWheel events on Windows
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>
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>
[PATCH] gitk: Enable selected patch text on Windows
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>
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>
gitk: Fix bug causing the "can't unset idinlist(...)" error
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>
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>
Documentation/Makefile: remove cmd-list.made before redirecting to it.
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>
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>
Merge branch 'cr/tag'
* 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.
* 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.
INSTALL: explain info installation and dependencies.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: David Kastrup <dak@gnu.org>
Add support for an info version of the user manual
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>
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>
Merge branch 'jc/clone'
* jc/clone:
git-clone: aggressively optimize local clone behaviour.
connect: accept file:// URL scheme
* jc/clone:
git-clone: aggressively optimize local clone behaviour.
connect: accept file:// URL scheme
Optimize the three-way merge of git-read-tree
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>
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>
Fix filehandle leak in "git branch -D"
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>
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>
builtin-bundle - use buffered reads for bundle header
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>
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>
builtin-bundle.c - use stream buffered input for rev-list
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>
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>
allow git-bundle to create bottomless bundle
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>
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>
allow git-bundle to create bottomless bundle
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>
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>
Optimize the two-way merge of git-read-tree too
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 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>
Optimize the common cases of git-read-tree
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 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>
Move old index entry removal from "unpack_trees()" into the individual functions
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 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>
Merge branch 'lt/readtree'
* lt/readtree:
Start moving unpack-trees to "struct tree_desc"
* lt/readtree:
Start moving unpack-trees to "struct tree_desc"
Fix "git commit directory/" performance anomaly
This trivial patch avoids re-hashing files that are already clean in the
index. This mirrors what commit 0781b8a9b2fe760fc4ed519a3a26e4b9bd6ccffe
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>
This trivial patch avoids re-hashing files that are already clean in the
index. This mirrors what commit 0781b8a9b2fe760fc4ed519a3a26e4b9bd6ccffe
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>
Optimize "diff --cached" performance.
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>
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>
Revert "tweak manpage formatting"
This reverts commit 524e5ffcf41a67ec113a9c3730ddc8fb8d3317f5.
It is reported that this change breaks formatting with docbook
1.69.
This reverts commit 524e5ffcf41a67ec113a9c3730ddc8fb8d3317f5.
It is reported that this change breaks formatting with docbook
1.69.
Start moving unpack-trees to "struct tree_desc"
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>
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>
Reinstate the old behaviour when GIT_DIR is set and GIT_WORK_TREE is unset
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>
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>
tweak manpage formatting
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 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>
Fix an illustration in git-rev-parse.txt
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>
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>
send-email: get all the quoting of realnames right
- 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>
- 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>
send-email: rfc822 forbids using <address@domain> without a non-empty "phrase"
Email::Valid does respect this considering such a mailbox specification
invalid. b06c6bc831cbb9e9eb82fd3ffd5a2b674cd940d0 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>
Email::Valid does respect this considering such a mailbox specification
invalid. b06c6bc831cbb9e9eb82fd3ffd5a2b674cd940d0 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>
Use the empty tree for base diff in paranoid-update on new branches
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>
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>
Teach the update-paranoid to look at file differences
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 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>
Teach update-paranoid how to store ACLs organized by groups
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>
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>
Fix formatting of git-blame documentation.
blame-options.txt did not format multi-paragraph option description
correctly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
blame-options.txt did not format multi-paragraph option description
correctly.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
cvsserver: Fix for work trees
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>
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>
17 years agogit-p4: Fix git-p4 submit to include only changed files in the perforce submit template.
git-p4: Fix git-p4 submit to include only changed files in the perforce submit template.
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>
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>
Reorder the list of commands in the manual.
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>
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>
git-p4: Fix support for symlinks.
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>
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>
git-stash documentation: add missing backtick
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-stash documentation: stash numbering starts at zero, not one
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Steve Hoelzer <shoelzer@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a note about the index being updated by git-status in some cases
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Steven Grimm <koreth@midwinter.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/git-commit.txt: correct bad list formatting.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
send-email: teach sanitize_address to do rfc2047 quoting
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\e,Av\e(Bnig <ukleinek@informatik.uni-freiburg.de>
Cc: Jakub Narebski <jnareb@gmail.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\e,Av\e(Bnig <ukleinek@informatik.uni-freiburg.de>
Cc: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix "make GZ=1 quick-install-doc"
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>
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>
pager: find out pager setting from configuration
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>
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: initialize variable $resume on startup
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>
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>
Documentation/git-svn: how to clone a git-svn-created repository
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>
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>
Merge branch 'maint'
* maint:
apply: remove directory that becomes empty by renaming the last file away
setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
* maint:
apply: remove directory that becomes empty by renaming the last file away
setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
apply: remove directory that becomes empty by renaming the last file away
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>
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>
setup.c:verify_non_filename(): don't die unnecessarily while disambiguating
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>
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>
documentation: use the word "index" in the git-commit man page
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>
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>
Merge branch 'master' of git://linux-nfs.org/~bfields/git
* '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
* '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
Merge branch 'maint'
documentation: use the word "index" in the git-add manual page
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>
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>
user-manual: mention git-gui
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>
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>
user-manual: mention git stash
Mention the git-stash command as a way to temporarily set aside work in
progress.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Mention the git-stash command as a way to temporarily set aside work in
progress.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
user-manual: update for new default --track behavior
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>
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>
Fix install-doc-quick target
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>
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>
unpack-trees.c: assume submodules are clean during check-out
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>
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>
Fixed git-push manpage
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>
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>
checkout-index needs a working tree
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
add "test-absolute-path" to .gitignore
New file requires new ignore.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
New file requires new ignore.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document GIT_SSH environment variable alongside other variables
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 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>
INSTALL: add warning on docbook-xsl 1.72 and 1.73
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Fix handling of $file_name in feed generation
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>
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>
git-completion: add "git stash"
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>
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>
GIT 1.5.3-rc4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix bogus use of printf in t3700 test
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>
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>
gitweb: do not choke on recursive symlink
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 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>
Fix work-tree related breakages
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>
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>
Fix documentation for core.gitproxy to reflect code
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>
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: remove unnecessary call to setup_git_directory()
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>
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>
Support building on GNU/Hurd
GNU/Hurd systems don't have strlcpy.
Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
GNU/Hurd systems don't have strlcpy.
Signed-off-by: Thomas Schwinge <tschwinge@gnu.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix style nit in Python slicing.
Python slices start at 0 by default.
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
Python slices start at 0 by default.
Signed-off-by: Han-Wen Nienhuys <hanwen@google.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
Sort output of "p4 change" in incremental import before further
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>
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>
RelNotes 1.5.3 updates before -rc4
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clone: aggressively optimize local clone behaviour.
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>
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>
connect: accept file:// URL scheme
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>
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>
When generating manpages, delete outdated targets first.
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>
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>