While adding colour to the branch command it was pointed out that a
config option like "branch.color" conflicts with the pre-existing
"branch.something" namespace used for specifying default merge urls and
branches. The suggested solution was to flip the order of the
components to "color.branch", which I did for colourising branch.
This patch does the same thing for
- git-log (color.diff)
- git-status (color.status)
- git-diff (color.diff)
- pager (color.pager)
I haven't removed the old config options; but they should probably be
deprecated and eventually removed to prevent future namespace
collisions. I've done this deprecation by changing the documentation
for the config file to match the new names; and adding the "color.XXX"
options to contrib/completion/git-completion.bash.
Unfortunately git-svn reads "diff.color" and "pager.color"; which I
don't like to change unilaterally.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unify the handling for cases C (add/add) and D (modify/modify).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (42 commits)
git-svn: correctly handle packed-refs in refs/remotes/
add test case for recursive merge
git-svn: correctly display fatal() error messages
git-svn: allow dcommit to take an alternate head
git-svn: enable logging of information not supported by git
Clarify fetch error for missing objects.
Move Fink and Ports check to after config file
shortlog: fix segfault on empty authorname
shortlog: remove "[PATCH]" prefix from shortlog output
Make sure the empty tree exists when needed in merge-recursive.
Don't use memcpy when source and dest. buffers may overlap
no need to install manpages as executable
Documentation: simpler shared repository creation
shortlog: fix segfault on empty authorname
Add branch.*.merge warning and documentation update
Fix perl/ build.
git-svn: use do_switch for --follow-parent if the SVN library supports it
Fix documentation copy&paste typo
git-svn: extra error check to ensure we open a file correctly
Documentation: update git-clone man page with new behavior
...
Now that we have git-merge-file, an RCS merge lookalike, we no longer
need it. So long, merge, and thanks for all the fish!
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now use git-rev-parse universally to read refs, instead
of our own file_to_s function (which I plan on removing).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test case is based on the bug report by Shawn Pearce.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If I wanted to print $@, I'd pass $@ to fatal(). This looks like
a stupid typo on my part.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously dcommit would unconditionally commit all patches
up-to and including the current HEAD. Now if an optional
command-line argument is specified, it will only commit
up to the specified revision.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The changes are now tracked in
$GIT_DIR/svn/$GIT_SVN_ID/untracked.log
Information in the untracked.log include:
* the addition and removal of empty directories
(changes of these will also warn the user)
* file and directory property changes, including (but not
limited to) svk:merge and svn:externals
* revision properties (revprops) are also tracked
* users will be warned of 'absent' file and directories
(if users are forbidden access)
Fields in entries are separated by spaces; "unsafe" characters
are URI-encoded so that each entry takes exactly one line.
There is currently no automated parser for dealing with the data
in untracked.log, but it should be possible to write one to
create empty directories on checkout and manage
externals/subprojects.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Otherwise there're such things like:
Cannot obtain needed none 9a6e87b60dbd2305c95cecce7d9d60f849a0658d
while processing commit 0000000000000000000000000000000000000000.
which while looks weird. What is the none needed for?
Signed-off-by: Junio C Hamano <junkio@cox.net>
Putting NO_FINK or NO_DARWIN_PORTS in config.mak is ignored because the
checks are done before the config is included.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I wanted to have a visual indication of which branches are local and
which are remote in git-branch -a output; however Junio was concerned
that someone might be using the output in a script. This patch
addresses the problem by colouring the git-branch output - which in
"auto" mode won't be activated.
I've based it off the colouring code for builtin-diff.c; which means
there is a branch color configuration variable that needs setting to
something before the color will appear.
The colour parameter is "color.branch" rather than "branch.color" to
avoid clashing with the default namespace for default branch merge
definitions.
This patch chooses green for local, red for remote and bold green for
current.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of checking if explicit SHA-1 in commit log message is sha1 of
commit and making link to "commit" view, make [fragment of] explicit
SHA-1 in commit log message link to "object" view. While at it allow
to hyperlink also shortened SHA-1, from 8 characters up to full SHA-1,
instead of requiring full 40 characters of SHA-1.
This makes the following changes:
* SHA-1 of objects which no longer exists, for example in commit
cherry-picked from no longer existing temporary branch, or revert
of commit in rebased branch, are no longer marked as such by not
being made into hyperlink (and not having default hyperlink view:
being underlined among others). On the other hand it makes gitweb
to not write error messages when object is not found to web serwer
log; it also moves cost of getting type and SHA-1 validation to
when link is clicked, and not only viewed.
* SHA-1 of other objects: blobs, trees, tags are also hyperlinked
and lead to appropriate view (although in the case of tags it is
more natural to just use tag name).
* You can put shortened SHA-1 of commit in the commit message, and it
would be hyperlinked; it would be checked on clicking if abbrev is
unique.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make symbolic link target in "tree" view into hyperlink to generic
"object" view (as we don't know if the link target is file (blob) or
directory (tree), and if it exist at all).
Target of link is made into hyperlink when:
* hash_base is provided (otherwise we cannot find hash
of link target)
* link is relative
* in no place link goes out of root tree (top dir)
Full path of symlink target from the root dir is provided in the title
attribute of hyperlink.
Currently symbolic link name uses ordinary file style (hidden
hyperlink), while the hyperlink to symlink target uses default
hyperlink style, so it is underlined while link target which is not
made into hyperlink is not underlined.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add generic "object" view implemented in git_object subroutine, which is
used to display object of any type; to be more exact it redirects to the
view of correct type: "blob", "tree", "commit" or "tag". To identify object
you have to provide either hash (identifier of an object), or (in the case of
tree and blob objects) hash of commit object (hash_base) and path (file_name).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In "tree" view (git_print_tree_entry subroutine), for entries which are
symbolic links, add " -> link_target" after file name (a la "ls -l").
Link target is _not_ hyperlinked.
While at it, correct whitespaces (tabs are for aling, spaces are for indent)
in modified git_print_tree_entry subroutine.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not use Content-Encoding: HTTP header in git_snapshot, using
instead type according to the snapshot type (compression type).
Some of web browser take Content-Encoding: to be _transparent_
also for downloading, and store decompressed file (with incorrect
compression suffix) on download.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the --numstat output for binary files from "0 0" to
"- -" to match what "apply --numstat" does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch uses git-apply to do the patching which simplifies the code a lot
and also uses one pass to git-diff. git-apply gives information on added,
removed files as well as which files are binary.
Removed the test for checking for matching binary files when deleting them
since git-apply happily deletes the file. This is matter of taste since we
allow some fuzz for text patches also.
Error handling was cleaned up, but not much tested.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The old code looked backwards from the email address to parse
the name, allowing an arbitrary number of spaces between the
two. However, in the case of no name, we looked back too far to
the 'author' (or 'Author:') header.
The bug was triggered by commit febf7ea4bed from linux-2.6.
Jeff King originally fixed it by looking back only one
character; Johannes Schindelin pointed out that we could try
harder while at it to cope with commits with broken headers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Originally noticed by Nicolas Pitre; the real cause was the code
was prepared to deal with [PATCH] (and [PATCH n/m whatever])
prefixes but forgot that the string can be indented while acting
as a filter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Make sure the empty tree exists when needed in merge-recursive.
Don't use memcpy when source and dest. buffers may overlap
no need to install manpages as executable
There are some baseless merge cases where git-merge-recursive will
try to compare one of the branches against the empty tree. However
most projects won't have the empty tree object in their object database
as Git does not normally create empty tree objects. If the empty tree
object is missing then the merge process will die, as it cannot load the
object from the database. The error message may make the user think that
their database is corrupt when its actually not.
So instead we should just create the empty tree object whenever it is
needed. If the object already exists as a loose object then no harm
done. Otherwise that loose object will be pruned away later by either
git-prune or git-prune-packed.
Thanks goes to Junio for suggesting this fix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-index-pack can call memcpy with overlapping source and destination
buffers. The patch below makes it use memmove instead.
If you want to demonstrate a failure, add the following two lines
+ if (input_offset < input_len)
+ abort ();
before the existing memcpy call (shown in the patch below),
and then run this:
(cd t; sh ./t5500-fetch-pack.sh)
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
No need to install manpages as executable. Noticed by Ville Skytt,Ad(B.
Signed-off-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The command used to have a safety valve to prevent this sequence:
edit foo
git update-index foo
edit foo
git diff foo
git commit --only foo
The reason for this was because an inexperienced user might
mistakenly think what is shown with the last-minute diff
contains all the change that is being committed (instead, what
the user asked to check was an incremental diff since what has
been staged so far). However, this turns out to only annoy
people who know what they are doing. Inexperienced people
would not be using the first "update-index" anyway, in which
case they would see the full changes in the "git diff".
Signed-off-by: Junio C Hamano <junkio@cox.net>
Data in rr-cache isn't valid after a patch application is
skipped or and aborted, so our next commit could be misrecorded
as a resolution of that skipped/failed commit, which is wrong.
git-am --skip, git-rebase --skip/--abort will automatically
invoke git-rerere clear to avoid this.
Also, since git-am --resolved indicates a resolution was
succesful, remember to run git-rerere to record the resolution
(and not surprise the user when the next commit is made).
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Over time, unresolved rr-cache entries are accumulated and they
tend to get less and less likely to be useful as the tips of
branches advance.
Reorder documentation page to show the subcommand section earlier
than the discussion section.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-am and git-rebase will be updated to use 'clear', and
diff/status can be used to aid the user in tracking progress in
the resolution process.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Take Johannes Schindelin's suggestions for a further simplification of
the shared repository creation using git --bare init-db --shared, and
for a simplified cvsimport using an existing CVS working directory.
Also insert more man page references.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
cvs-migration.txt | 27 ++++++++++++++-------------
1 file changed, 14 insertions(+), 13 deletions(-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
The old code looked backwards from the email address to parse the name,
allowing an arbitrary number of spaces between the two. However, in the case
of no name, we looked back too far to the 'author' (or 'Author:') header.
Instead, remove at most one space between name and address.
The bug was triggered by commit febf7ea4bed from linux-2.6.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch clarifies the meaning of the branch.*.merge option.
Previously, if branch.*.merge was specified but did not match any
ref, the message "No changes." was not really helpful regarding
the misconfiguration. This patch adds a warning for this.
Signed-off-by: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
An earlier commit f848718a broke the build in perl/ directory by
allowing the Makefile.PL to overwrite the now-tracked Makefile.
Fix this by forcing Makefile.PL to produce its output in
perl.mak as the broken commit originally intended.
Signed-off-by: Junio C Hamano <junkio@cox.net>
do_switch works with the SVN Perl bindings after r22312 in the
Subversion trunk. Since no released version of SVN currently
supports it; we'll just autodetect it and enable its usage
when a user has a recent-enough version of SVN.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This was introduced in 45a3b12cfd
Signed-off-by: Uwe Kleine-K,AC6(Bnig <zeisberg@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This may be an issue with repositories imported with commit
27a1a8014b or later, but before
commit dad73c0bb9.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update git-clone man page to reflect recent changes
(--use-separate-remote default and use of .git/config instead of
remotes files), and rewrite introduction.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
At some point between v5.6 and 5.8 Perl started to assume its input,
output and filehandles are UTF-8. This breaks the counting of bytes
for the CVS protocol, resulting in the client expecting less data
than we actually send, and storing truncated files.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently the treshold is 5000. The likelihood of this value to ever be
crossed for a single push is really small making it not really useful.
The optimal treshold for a pure space saving on a filesystem with 4kb
blocks is 3. However this is likely to create many small packs
concentrating a large number of files in a single directory compared to
the same objects which are spread over 256 directories when loose. This
means we would need 512 objects per pack on average to approximagte the
same directory cost (a pack has 2 files because of the index).
But 512 is a really high value just like 5000 since most pushes are
unlikely to have that many objects. So let's try with a value of 100
which should have a good balance between small pushes going to be
exploded into loose objects and large pushes kept as whole packs.
This is not a replacement for periodic repacks of course.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Modify cvs-migration.txt so it explains first how to develop against a
shared repository, then how to set up a shared repository, then how to
import a repository from cvs. Though this seems chronologically
backwards, it's still readable in this order, and it puts the more
commonly needed material closer to the front.
Remove the annotate/pickaxe section; perhaps it can find a place elsewhere
in the future. Remove most of the "why git is better than cvs" stuff from
the introduction.
Add some minor clarifications, including two that have come up several
times on the mailing list:
1. Recommend committing any changes before running pull.
2. Note that changes must be commited before they can be pushed.
Update the clone discussion to reflect the new --use-separate-remotes
default, and add a brief mention of git-cvsserver.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Without any specification in the .git/config file, git-pull will execute
"git-pull origin"; which in turn defaults to pull from the first "pull"
definition for the remote, "origin".
This is a difficult set of defaults to track for a new user, and it's
difficult to see what tells git to do this (especially when it is
actually hard-coded behaviour). To ameliorate this slightly, this patch
explicitly specifies the default behaviour during a clone using the
"branch" section of the config.
For example, a clone of a typical repository would create a .git/config
containing:
[remote "origin"]
url = proto://host/repo.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = origin
merge = refs/heads/master
The [branch "master"] section is such that there is no change to the
functionality of git-pull, but that functionality is now explicitly
documented.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
An earlier commit 3683dc5a broke the merge message generation with
a careless use of && where it was not needed, breaking the merge
message for cases where non branches are given.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Long-running fetches run inside children to avoid memory leaks.
When we refork, the connection in the parent can be idle for a
long time; attempting to reuse it in the next child can result
in timeouts.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow images in one of web formats (PNG, GIF, JPEG) - actually files
with mimetype of image/png, image/git, image/jpeg - to be displayed in
"blob" view using <img /> element, instead of using "blob_plain" view
for them, like for all other files except also text/* mimetype files.
This makes possible to easily go to file history, to HEAD version of
the file, to appropriate commit etc; all of those are not available
in "blob_plain" (raw) view.
Only text files can have "blame" view link in the formats part of
navbar.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While deciding if the new style command line argument is a tag
or a branch, we checked it with "git show-ref -s --verify" to
see if results in an error, but when it is not a branch, the
check leaked the error message out, which was not needed to be
shown to the end user.
Signed-off-by: Junio C Hamano <junkio@cox.net>
