When nothing to git-commit, honor the git-status color setting.
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>
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>
gitweb: Fix searchbox positioning
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>
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>
Merge branch 'master' of git://linux-nfs.org/~bfields/git
* '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.
* '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.
Merge branch 'maint'
Conflicts:
Documentation/user-manual.txt
Conflicts:
Documentation/user-manual.txt
Documentation/user-manual.txt: fix a few omissions of gitlink commands.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: David Kastrup <dak@gnu.org>
user-manual: fix incorrect header level
This section is a subsection of the "Examples" section.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
This section is a subsection of the "Examples" section.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
user-manual: use pithier example commit
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>
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>
user-manual: introduce the word "commit" earlier
Use the word "commit" as a synonym for "version" from the start.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Use the word "commit" as a synonym for "version" from the start.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
user-manual: minor editing for conciseness
Just cutting out a few unnecessary words.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Just cutting out a few unnecessary words.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
user-manual: edit "ignoring files" for conciseness
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 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>
Documentation/user-manual.txt: fix a few omissions of gitlink commands.
Signed-off-by: David Kastrup <dak@gnu.org>
Signed-off-by: David Kastrup <dak@gnu.org>
Make usage documentation for git-add consistent.
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 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>
Make usage documentation for git-am consistent.
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>
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>
Don't segfault if we failed to inflate a packed delta
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>
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>
pack-objects: check return value from read_sha1_file()
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
blame: check return value from read_sha1_file()
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-p4: Fix warnings about non-existant refs/remotes/p4/HEAD ref when running git-p4 sync the first time after a git clone.
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>
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>
git-p4: Make 'git-p4 branches' work after an initial clone with git clone from an origin-updated repository.
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>
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>
Documentation: Correct various misspellings and typos.
Fix minor typos throughout the documentation.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix minor typos throughout the documentation.
Signed-off-by: Brian Hetro <whee@smaertness.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation: For consistency, use CVS instead of cvs.
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>
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>
Fix racy-git handling in git-write-tree.
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>
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>
rebase -i: fix squashing corner case
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>
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>
Install man3 manpages to $PREFIX/share/man/man3 even for site installs
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>
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>
git-svn init/clone --stdlayout option to default-init trunk/tags/branches
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>
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>
diff-delta.c: Fix broken skip calculation.
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>
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>
Merge branch 'master' of git://repo.or.cz/git/fastimport
* '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
* '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
git-svn: dcommit prints out the URL to be committed to
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>
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>
Teach bash about git-submodule and its subcommands
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>
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>
Teach bash to complete ref arguments to git-describe
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>
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>
Update bash completion with new 1.5.3 command line options
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>
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>
git-svn: update documentation with CAVEATS section
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Reset terminal attributes when terminating git send-email
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>
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>
Document -u option in git-svnimport man page
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Fix breakage in git-rev-list.txt
Also fix some innocent missing of quotes.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also fix some innocent missing of quotes.
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git.el: Avoid a lisp error when there's no current branch (detached HEAD).
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>
Fix git-remote for ActiveState Perl
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>
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>
Documentation: update tar.umask default
As noted by Mike Hommey, the documentation for the config setting tar.umask
is not up-to-date. Commit f08b3b0e2e9ad87767d80ff03b013c686e08ba4b 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>
As noted by Mike Hommey, the documentation for the config setting tar.umask
is not up-to-date. Commit f08b3b0e2e9ad87767d80ff03b013c686e08ba4b 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>
Suggest unsetting core.bare when using new-workdir on a bare repository
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>
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>
Fix new-workdir (again) to work on bare repositories
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>
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>
GIT 1.5.3-rc6
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>
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>
Merge branch 'master' of git://git./gitk/gitk
* '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
* '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
Avoid using va_copy in fast-import: it seems to be unportable.
[sp: minor change to use fputs, thus reducing the patch size]
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[sp: minor change to use fputs, thus reducing the patch size]
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git clone: do not issue warning while cloning locally across filesystems
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>
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>
gitk: Add a window to list branches, tags and other references
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>
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>
Fix misspelling of 'suppress' in docs
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Document what the stage numbers in the :$n:path syntax mean.
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 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>
Don't allow combination of -g and --reverse as it doesn't work
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>
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>
Add the word reflog to Documentation/config.txt:core.logAllRefUpdates
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>
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>
Add and document a global --no-pager option for git.
To keep the change small, this is done by setting GIT_PAGER to "cat".
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
To keep the change small, this is done by setting GIT_PAGER to "cat".
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Acked-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Take binary diffs into account for "git rebase"
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>
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>
Make thin-pack generation subproject aware.
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>
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>
Correct documentation of 'reflog show' to explain it shows HEAD
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>
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>
Merge branch 'master' of git://repo.or.cz/git-gui
* 'master' of git://repo.or.cz/git-gui:
git-gui: Added support for OS X right click
git-gui: Avoid Tcl error in popup menu on diff viewer
* 'master' of git://repo.or.cz/git-gui:
git-gui: Added support for OS X right click
git-gui: Avoid Tcl error in popup menu on diff viewer
Merge branch 'master' of git://git./gitk/gitk
* '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
* '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
fast-import pull request
* 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>
* 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>
Include recent command history in fast-import crash reports
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>
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>
Generate crash reports on die in fast-import
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>
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>
Allow frontends to bidirectionally communicate with fast-import
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>
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>
Make trailing LF optional for all fast-import commands
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>
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>
Make trailing LF following fast-import `data` commands optional
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>
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>
Teach fast-import to ignore lines starting with '#'
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>
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>
Use handy ALLOC_GROW macro in fast-import when possible
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>
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>
Actually allow TAG_FIXUP branches in fast-import
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>
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>
Fix whitespace in "Format of STDIN stream" of fast-import
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>
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>
git-completion.bash - add support for git-bundle
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Mark Levedahl <mdl123@verizon.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Clarify commit-tree documentation
As per http://marc.info/?l=git&m=118737219702802&w=2 , clarify
git-commit-tree documentation.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As per http://marc.info/?l=git&m=118737219702802&w=2 , clarify
git-commit-tree documentation.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Minor clarifications to git-filter-branch usage and doc
- 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>
- 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>
Fix small typo in git send-email man page.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-submodule: re-enable 'status' as the default subcommand
This was broken as part of ecda072380.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This was broken as part of ecda072380.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Acked-by: Sven Verdoolaege <skimo@kotnet.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
[PATCH] gitk: Handle 'copy from' and 'copy to' in diff headers.
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>
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>
gitk: Fix bug in fix for warning when removing a branch
My fix in commit b1054ac985aebc90c0a78202dab8477b74d7818a 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>
My fix in commit b1054ac985aebc90c0a78202dab8477b74d7818a 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>
Clean-up read-tree error condition.
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>
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>
Clarify actual behavior of 'git add' and ignored files
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Brian Downing <bdowning@lavos.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
t1301-shared-repo.sh: fix 'stat' portability issue
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>
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>
Documentation/git-rebase: fix an example
The example miscounted the commit to rebase from.
Noticed by Cliff Brake.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The example miscounted the commit to rebase from.
Noticed by Cliff Brake.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-clone: allow --bare clone
This is a stop-gap to work around problem with git-init without
intrusive changes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is a stop-gap to work around problem with git-init without
intrusive changes.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pack-objects: remove bogus arguments to delta_cacheable()
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>
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>
git-apply: apply submodule changes
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>
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>
Update documentation links for older releases.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge branch 'maint' to sync with 1.5.2.5
* maint:
GIT 1.5.2.5
git-add -u paths... now works from subdirectory
Fix "git add -u" data corruption.
* maint:
GIT 1.5.2.5
git-add -u paths... now works from subdirectory
Fix "git add -u" data corruption.
Fix read-tree merging more than 3 trees using 3-way merge
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>
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 1.5.2.5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-add -u paths... now works from subdirectory
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>
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>
Fix "git add -u" data corruption.
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>
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>
path-list.c: always free strdup'ed paths
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>
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>
git-svn: fix log with single revision against a non-HEAD branch
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>
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>
GIT 1.5.3-rc5
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
attr.c: read .gitattributes from index as well.
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 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>
attr.c: refactoring
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>
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>
Add read_cache to builtin-check-attr
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>
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>
diff: squelch empty diffs even more
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>
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>
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>
[PATCH] gitk: Make the date/time display configurable
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>
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>
[PATCH] gitk: Let user easily specify lines of context in diff view
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>
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>
gitk: Fix warning when removing a branch
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>
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>
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>