David Kågedal [Fri, 9 Feb 2007 08:22:19 +0000 (09:22 +0100)]
git-blame.el: Autoupdate while editing
This adds the support for automatically updating the buffer while editing.
A configuration variable git-blame-autoupdate controls whether this should
be enabled or not.
Signed-off-by: David Kågedal <davidk@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
David Kågedal [Fri, 9 Feb 2007 08:21:32 +0000 (09:21 +0100)]
git-blame.el: blame unsaved changes
Make git-blame use the current buffer contents for the blame, instead of
the saved file. This makes the blame correct even if there are unsaved
changes.
Also added a git-reblame command.
Signed-off-by: David Kågedal <davidk@lysator.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>
Jakub Narebski [Fri, 9 Feb 2007 08:19:59 +0000 (09:19 +0100)]
git-blame: Change installation instructions
Change installation instructions to using either "(require 'git-blame)"
or appropriate autoload instruction in GNU Emacs init file, .emacs
This required adding "(provide 'git-blame)" at the end of git-blame.el
and adding [preliminary] docstring to `git-blame-mode' function for
consistency (to mark function as interactive in `autoload' we have to
provide docstring as DOCSTRING is third arg, and INTERACTIVE fourth,
and both are optional). `git-blame-mode' is marked to autoload.
While at it ensure that we add `git-blame-mode' to `minor-mode-alist'
only once (in a way that does not depend on `cl' package).
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Jakub Narebski [Fri, 9 Feb 2007 08:19:28 +0000 (09:19 +0100)]
git-blame: Add Emacs Lisp file headers and GNU GPL boilerplate
Add Emacs Lisp file headers, according to "Coding Conventions" chapter
in Emacs Lisp Reference Manual and Elisp Area Convetions for
EmacsWiki:
http://www.emacswiki.org/cgi-bin/wiki/ElispAreaConventions
Those include: copyright notice, GNU GPL boilerplate, description and
instalation instructions as provided in email and in commit message
introducing git-blame.el, compatibility notes from another email by
David Kågedal about what to change to use it in GNU Emacs 20, and
"git-blame ends here" to detect if file was truncated. First line
includes setting file encoding via first line local variable values
(file variables).
Added comment to "(require 'cl)" to note why it is needed; "Coding
Conventions" advises to avoid require the `cl' package of Common Lisp
extensions at run time.
Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Fri, 9 Feb 2007 07:24:51 +0000 (23:24 -0800)]
reflog: handle $name => remotes/%s/HEAD mapping consistently for logs
When refs/remotes/gfi/master and refs/remotes/gfi/HEAD exist,
and the latter is a symref that points at the former, dwim_ref()
resolves string "gfi" to "refs/remotes/gfi/master" as expected,
but dwim_log() does not understand "gfi@{1.day}" and needs to be
told "gfi/master@{1.day}". This is confusing.
Junio C Hamano [Thu, 8 Feb 2007 23:47:08 +0000 (15:47 -0800)]
Merge branch 'master' of git://repo.or.cz/git/fastimport
* 'master' of git://repo.or.cz/git/fastimport:
tar archive frontend for fast-import.
Correct spelling of fast-import in docs.
Correct some language in fast-import documentation.
Correct ^0 asciidoc syntax in fast-import docs.
Shawn O. Pearce [Thu, 8 Feb 2007 20:26:01 +0000 (15:26 -0500)]
tar archive frontend for fast-import.
This is an example fast-import frontend, in less than 100 lines
of Perl. It accepts one or more tar archives on the command line,
passes them through gzcat/bzcat/zcat if necessary, parses out the
individual file headers and feeds all contained data to fast-import.
No temporary files are involved.
Each tar is treated as one commit, with the commit timestamp coming
from the oldest file modification date found within the tar.
Each tar is also tagged with an annotated tag, using the basename
of the tar file as the name of the tag.
Currently symbolic links and hard links are not handled by the
importer. The file checksums are also not verified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
James Bowes [Wed, 7 Feb 2007 22:57:43 +0000 (17:57 -0500)]
Read cvsimport options from repo-config
Default values for command line options can be saved in .git/config (or the
global ~/.gitconfig). Config option names match the command line option names,
so cvsimport.d corresponds to git-cvsimport -d. One may also set
cvsimport.module to specify a default cvs module name.
Signed-off-by: James Bowes <jbowes@dangerouslyinc.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Shawn O. Pearce [Thu, 8 Feb 2007 06:35:37 +0000 (01:35 -0500)]
Correct ^0 asciidoc syntax in fast-import docs.
I wrote this documentation with asciidoc 7.1.2, but apparently
asciidoc 8 assumes ^ means superscript. The solution was already
documented in rev-parse's manpage and is to use {caret} instead.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Linus Torvalds [Wed, 7 Feb 2007 19:49:56 +0000 (11:49 -0800)]
Fix "git log -z" behaviour
For commit messages, we should really put the "line_termination" when we
output the character in between different commits, *not* between the
commit and the diff. The diff goes hand-in-hand with the commit, it
shouldn't be separated from it with the termination character.
So this:
- uses the termination character for true inter-commit spacing
- uses a regular newline between the commit log and the diff
We had it the other way around.
For the normal case where the termination character is '\n', this
obviously doesn't change anything at all, since we just switched two
identical characters around. So it's very safe - it doesn't change any
normal usage, but it definitely fixes "git log -z".
By fixing "git log -z", you can now also do insane things like
and you will see only those commits that have the "some patch expression"
in their commit message _or_ their patches.
(This is slightly different from 'git log -S"some patch expression"',
since the latter requires the expression to literally *change* in the
patch, while the "git log -p -z | grep .." approach will see it if it's
just an unchanged _part_ of the patch context)
Of course, if you actually do something like the above, you're probably
insane, but hey, it works!
Try the above command line for a demonstration (of course, you need to
change the "some patch expression" to be something relevant). The old
behaviour of "git log -p -z" was useless (and got things completely wrong
for log entries without patches).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Wed, 7 Feb 2007 18:42:08 +0000 (10:42 -0800)]
t4200: skip gc-rerere test on systems with non GNU date.
Quite nonstandard "date -d @11111111 +%s" does not even fail on
OpenBSD but gives the current date in "seconds since epoch"
format, which is useless for the purpose of this test. We want
to make sure that this returns exactly the same input before
proceeding.
Junio C Hamano [Wed, 7 Feb 2007 17:47:49 +0000 (09:47 -0800)]
Merge branch 'ml/gitk' (early part)
* 'ml/gitk' (early part):
gitk: Use show-ref instead of ls-remote
Make gitk work reasonably well on Cygwin.
gitk - remove trailing whitespace from a few lines.
Not on all platforms are size_t and unsigned long equivalent.
Since I do not know how portable %z is, I play safe, and just
cast the respective variables to unsigned long.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Wed, 7 Feb 2007 17:18:57 +0000 (09:18 -0800)]
for-each-reflog: fix case for empty log directory
When we remove the last reflog in a directory, opendir() would
succeed and we would iterate over its dirents, expecting retval
to be initialized to zero and setting it to non-zero only upon
seeing an error. If the directory is empty, oops!, we do not
have anybody that touches retval.
The problem is because we initialize retval to errno even on
success from opendir(), which would leave the errno unmolested.
Junio C Hamano [Wed, 7 Feb 2007 16:39:16 +0000 (08:39 -0800)]
Merge branch 'master' of git://repo.or.cz/git/fastimport
* 'master' of git://repo.or.cz/git/fastimport:
Add a Tips and Tricks section to fast-import's manual.
Don't crash fast-import if the marks cannot be exported.
Dump all refs and marks during a checkpoint in fast-import.
Teach fast-import how to sit quietly in the corner.
Teach fast-import how to clear the internal branch content.
Minor timestamp related documentation corrections for fast-import.
Junio C Hamano [Wed, 7 Feb 2007 10:10:56 +0000 (02:10 -0800)]
git-clone --reference: work well with pack-ref'ed reference repository
Earlier we only used loose refs to anchor already existing
objects. When cloning from a repository that forked relatively
long time ago from the reference repository, this made the
want/have exchange by fetch-pack to do unnecessary work.
Shawn O. Pearce [Wed, 7 Feb 2007 08:49:08 +0000 (03:49 -0500)]
Add a Tips and Tricks section to fast-import's manual.
There has been some informative lessons learned in the gfi user
community, and these really should be written down and documented
for future generations of frontend developers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Wed, 7 Feb 2007 07:46:35 +0000 (02:46 -0500)]
Don't crash fast-import if the marks cannot be exported.
Apparently fast-import used to die a horrible death if we
were unable to open the marks file for output. This is
slightly less than ideal, especially now that we dump
the marks as part of the `checkpoint` command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Wed, 7 Feb 2007 07:42:44 +0000 (02:42 -0500)]
Dump all refs and marks during a checkpoint in fast-import.
If the frontend asks us to checkpoint (via the explicit checkpoint
command) its probably because they are afraid the current import
will crash/fail/whatever and want to make sure they can pickup from
the last checkpoint. To do that sort of recovery, we will need the
current tip of every branch and tag available at the next startup.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Wed, 7 Feb 2007 07:19:31 +0000 (02:19 -0500)]
Teach fast-import how to sit quietly in the corner.
Often users will be running fast-import from within a larger frontend
process, and this may be a frequent periodic tool such as a future
edition of `git-svn fetch`. We don't want to bombard users with our
large stats output if they won't be interested in it, so `--quiet`
is now an option to make gfi be more silent.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Wed, 7 Feb 2007 07:03:03 +0000 (02:03 -0500)]
Teach fast-import how to clear the internal branch content.
Some frontends may not be able to (easily) keep track of which files
are included in the branch, and which aren't. Performing this
tracking can be tedious and error prone for the frontend to do,
especially if its foreign data source cannot supply the changed
path list on a per-commit basis.
fast-import now allows a frontend to request that a branch's tree
be wiped clean (reset to the empty tree) at the start of a commit,
allowing the frontend to feed in all paths which belong on the branch.
This is ideal for a tar-file importer frontend, for example, as
the frontend just needs to reformat the tar data stream into a gfi
data stream, which may be something a few Perl regexps can take
care of. :)
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio C Hamano [Wed, 7 Feb 2007 03:33:22 +0000 (19:33 -0800)]
Merge branch 'master' of git://repo.or.cz/git/fastimport
* 'master' of git://repo.or.cz/git/fastimport: (81 commits)
S_IFLNK != 0140000
Don't do non-fastforward updates in fast-import.
Support RFC 2822 date parsing in fast-import.
Minor fast-import documentation corrections.
Remove unnecessary null pointer checks in fast-import.
Correct fast-import timezone documentation.
Correct minor style issue in fast-import.
Correct compiler warnings in fast-import.
Remove --branch-log from fast-import.
Initial draft of fast-import documentation.
Don't support shell-quoted refnames in fast-import.
Reduce memory usage of fast-import.
Include checkpoint command in the BNF.
Accept 'inline' file data in fast-import commit structure.
Reduce value duplication in t9300-fast-import.
Create test case for fast-import.
Support delimited data regions in fast-import.
Remove unnecessary options from fast-import.
Use fixed-size integers when writing out the index in fast-import.
Always use struct pack_header for pack header in fast-import.
...
Shawn O. Pearce [Tue, 6 Feb 2007 21:08:06 +0000 (16:08 -0500)]
Don't do non-fastforward updates in fast-import.
If fast-import is being used to update an existing branch of
a repository, the user may not want to lose commits if another
process updates the same ref at the same time. For example, the
user might be using fast-import to make just one or two commits
against a live branch.
We now perform a fast-forward check during the ref updating process.
If updating a branch would cause commits in that branch to be lost,
we skip over it and display the new SHA1 to standard error.
This new default behavior can be overridden with `--force`, like
git-push and git-fetch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Tue, 6 Feb 2007 19:58:30 +0000 (14:58 -0500)]
Support RFC 2822 date parsing in fast-import.
Since some frontends may be working with source material where
the dates are only readily available as RFC 2822 strings, it is
more friendly if fast-import exposes Git's parse_date() function
to handle the conversion. This way the frontend doesn't need
to perform the parsing itself.
The new --date-format option to fast-import can be used by a
frontend to select which format it will supply date strings in.
The default is the standard `raw` Git format, which fast-import
has always supported. Format rfc2822 can be used to activate the
parse_date() function instead.
Because fast-import could also be useful for creating new, current
commits, the format `now` is also supported to generate the current
system timestamp. The implementation of `now` is a trivial call
to datestamp(), but is actually a whole whopping 3 lines so that
fast-import can verify the frontend really meant `now`.
As part of this change I have added validation of the `raw` date
format. Prior to this change fast-import would accept anything
in a `committer` command, even if it was seriously malformed.
Now fast-import requires the '> ' near the end of the string and
verifies the timestamp is formatted properly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Tue, 6 Feb 2007 17:35:02 +0000 (12:35 -0500)]
Minor fast-import documentation corrections.
Corrected a couple of header markup lines which were shorter than the
actual header, and made the `data` commands two formats into a named
list, which matches how we document the two formats of the `M` command
within a commit.
Also tried to simplify the language about our decimal integer format;
Linus pointed out I was probably being too specific at the cost of
reduced readability.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Tue, 6 Feb 2007 17:05:51 +0000 (12:05 -0500)]
Remove unnecessary null pointer checks in fast-import.
There is no need to check for a NULL pointer before invoking free(),
the runtime library automatically performs this check anyway and
does nothing if a NULL pointer is supplied.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Tue, 6 Feb 2007 16:59:11 +0000 (11:59 -0500)]
Correct fast-import timezone documentation.
Andy Parkins and Linus Torvalds both noticed that the description
of the timezone was incorrect. Its not expressed in minutes.
Its more like "hhmm", where "hh" is the number of hours and "mm"
is the number of minutes shifted from GMT/UTC.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio C Hamano [Tue, 6 Feb 2007 07:01:14 +0000 (23:01 -0800)]
git-push: allow globbing wildcard refspec.
This allows you to set up mothership-satellite configuration
more symmetrically and naturally by allowing the globbing
wildcard refspec for git-push. On your satellite machine:
You would say "git fetch mothership" to update your tracking
branches under mothership/ to keep track of the progress on the
mothership side, and when you are done working on the satellite
machine, you would "git push mothership" to update their
tracking branches under satellite/. Corresponding configuration
on the mothership machine can be used to make "git fetch satellite"
update its tracking branch under satellite/. on the mothership.
Shawn O. Pearce [Tue, 6 Feb 2007 05:43:59 +0000 (00:43 -0500)]
Correct minor style issue in fast-import.
Junio noticed that I was using a different style in fast-import
for returned pointers than the rest of Git. Before merging this
code into the main git.git tree I'd like to make it consistent,
as this style variation was not intentional.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Tue, 6 Feb 2007 05:26:49 +0000 (00:26 -0500)]
Correct compiler warnings in fast-import.
Junio noticed these warnings/errors in fast-import when compiling
with `-Werror -ansi -pedantic`. A few changes are to reduce compiler
warnings, while one (in cmd_merge) is a bug fix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Tue, 6 Feb 2007 05:15:37 +0000 (00:15 -0500)]
Remove --branch-log from fast-import.
The --branch-log option and its associated code hasn't been used in
several months, as its not really very useful for debugging fast-import
or a frontend. I don't plan on supporting it in this state long-term,
so I'm killing it now before it gets distributed to a wider audience.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Mon, 5 Feb 2007 04:52:02 +0000 (23:52 -0500)]
bash: Support git-rebase -m continuation completion.
Apparently `git-rebase -m` uses a metadata directory within .git
(.git/.dotest-merge) rather than .dotest used by git-am (and
git-rebase without the -m option). This caused the completion code
to not offer --continue, --skip or --abort when working within a
`git-rebase -m` session.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Shawn O. Pearce [Tue, 6 Feb 2007 02:09:25 +0000 (21:09 -0500)]
Initial draft of fast-import documentation.
This is a first pass at the manpage for git-fast-import.
I have tried to cover the input format in extreme detail, creating a
reference which is more detailed than the BNF grammar appearing in
the header of fast-import.c. I have also covered some details about
gfi's performance and memory utilization, as well as the average
learning curve required to create a gfi frontend application (as it
is far lower than it might appear on first glance).
The documentation still lacks real example input streams, which may
turn out to be difficult to format in asciidoc due to the blank lines
which carry meaning within the format.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Shawn O. Pearce [Tue, 6 Feb 2007 01:30:37 +0000 (20:30 -0500)]
Don't support shell-quoted refnames in fast-import.
The current implementation of shell-style quoted refnames and
SHA-1 expressions within fast-import contains a bad memory leak.
We leak the unquoted strings used by the `from` and `merge`
commands, maybe others. Its also just muddling up the docs.
Since Git refnames cannot contain LF, and that is our delimiter
for the end of the refname, and we accept any other character
as-is, there is no reason for these strings to support quoting,
except to be nice to frontends. But frontends shouldn't be
expecting to use funny refs in Git, and its just as simple to
never quote them as it is to always pass them through the same
quoting filter as pathnames. So frontends should never quote
refs, or ref expressions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Junio C Hamano [Tue, 30 Jan 2007 05:53:28 +0000 (21:53 -0800)]
gitk: Use show-ref instead of ls-remote
It used to be ls-remote on self was the only easy way to grab
the ref information. Now we have show-ref which does not
involve fork and IPC, so use it.
Mark Levedahl [Thu, 1 Feb 2007 13:46:38 +0000 (08:46 -0500)]
Make gitk work reasonably well on Cygwin.
The gitk gui layout was completely broken on Cygwin. If gitk was started
without previous geometry in ~/.gitk, the user could drag the window sashes
to get a useable layout. However, if ~/.gitk existed, this was not possible
at all.
The fix was to rewrite makewindow, changing the toplevel containers and
the particular geometry information saved between sessions. Numerous bugs
in both the Cygwin and the Linux Tk versions make this a delicate
balancing act: the version here works in both but many subtle variants
are competely broken in one or the other environment.
Three user visible changes result:
1 - The viewer is fully functional under Cygwin.
2 - The search bar moves from the bottom to the top of the lower left
pane. This was necessary to get around a layout problem on Cygwin.
3 - The window size and position is saved and restored between sessions.
Again, this is necessary to get around a layout problem on Cygwin.
Junio C Hamano [Tue, 6 Feb 2007 00:53:12 +0000 (16:53 -0800)]
Fix longstanding mismerge of ALL_CFLAGS vs BASIC_CFLAGS
The earlier commit d7b6c3c0 (Aug 15, 2006) introduced this
mismerge when most of the CFLAGS were renamed to BASIC_CFLAGS.
Not that it matters right now, since we do not compile XS
Perl extensions which wanted non GNU subset of ALL_CFLAGS for
compilation, but we should make things consistent.
Linus Torvalds [Wed, 24 Jan 2007 19:21:10 +0000 (11:21 -0800)]
pager: Work around window resizing bug in 'less'
If you resize the terminal while less is waiting for input, less
will exit entirely without even showing the output. This is very
noticeable if you do something like "git diff" on a big and
cold-cache tree and git takes a few seconds to think, and then
you resize the window while it's preparing. Boom. No output AT
ALL.
The way to reproduce the problem is to do some pager operation
that takes a while in git, and resizing the window while git is
thinking about the output. Try
git diff --stat v2.6.12..
in the kernel tree to do something where it takes a while for git to start
outputting information.
(3) set up remotes/jbf-um/HEAD to point at jbf-um/master so
that later I can say "git log jbf-um"
Or I could do
$ git remote add -t 'ap/*' andy /home/andy/git.git
to make Andy's topic branches kept track of under refs/remotes/andy/ap/.
Other possible improvements I considered but haven't implemented
(hint, hint) are:
* reject wildcard letters other than a trailing '*' to the -t
parameter;
* make -m optional and when the first -t parameter does not
have the trailing '*' default to that value (so the above
example does not need to say "-m master");
* if -m is not given, and -t parameter ends with '*' (i.e. the
above defaulting did not tell us where to point HEAD at), and
if we did the fetch with -f, check if 'master' was fetched
and make HEAD point at it.
Junio C Hamano [Mon, 5 Feb 2007 05:49:05 +0000 (21:49 -0800)]
Use pretend_sha1_file() in git-blame and git-merge-recursive.
git-merge-recursive wants an null tree as the fake merge base
while producing the merge result tree. The null tree does not
have to be written out in the object store as it won't be part
of the result, and it is a prime example for using the new
pretend_sha1_file() function.
git-blame needs to register an arbitrary data to in-core index
while annotating a working tree file (or standard input), but
git-blame is a read-only application and the user of it could
even lack the privilege to write into the object store; it is
another good example for pretend_sha1_file().
Junio C Hamano [Mon, 5 Feb 2007 05:42:38 +0000 (21:42 -0800)]
Add pretend_sha1_file() interface.
The new interface allows an application to temporarily hash a
small number of objects and pretend that they are available in
the object store without actually writing them.
Junio C Hamano [Tue, 30 Jan 2007 09:11:08 +0000 (01:11 -0800)]
git-blame: no rev means start from the working tree file.
Warning: this changes the semantics.
This makes "git blame" without any positive rev to start digging
from the working tree copy, which is made into a fake commit
whose sole parent is the HEAD.
It also adds --contents <file> option to pretend as if the
working tree copy has the contents of the named file. You can
use '-' to make the command read from the standard input.
If you want the command to start annotating from the HEAD
commit, you need to explicitly give HEAD parameter.
David Kågedal [Mon, 5 Feb 2007 22:22:28 +0000 (14:22 -0800)]
git-blame: an Emacs minor mode to view file with git-blame output.
Here's another version of git-blame.el that automatically tries to
create a sensible list of colors to use for both light and dark
backgrounds. Plus a few minor fixes.
To use:
1) Load into emacs: M-x load-file RET git-blame.el RET
2) Open a git-controlled file
3) Blame: M-x git-blame-mode
Stelian Pop [Fri, 12 Jan 2007 21:57:03 +0000 (22:57 +0100)]
Add hg-to-git conversion utility.
hg-to-git.py is able to convert a Mercurial repository into a git one,
and preserves the branches in the process (unlike tailor)
hg-to-git.py can probably be greatly improved (it's a rather crude
combination of shell and python) but it does already work quite well for
me. Features:
- supports incremental conversion
(for keeping a git repo in sync with a hg one)
- supports hg branches
- converts hg tags
Signed-off-by: Stelian Pop <stelian@popies.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Yasushi SHOJI [Tue, 30 Jan 2007 10:23:38 +0000 (19:23 +0900)]
gitweb: Convert project name to UTF-8
If the repository directory name is in non-ascii, $project needs to be
converted from perl internal to utf-8 because it will be used as
title, page path, and snapshot filename.
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:37 +0000 (15:44 -0500)]
bash: Support git-bisect and its subcommands.
We now offer completion support for git-bisect's subcommands,
as well as ref name completion on the good/bad/reset subcommands.
This should make interacting with git-bisect slightly easier on
the fingers.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:32 +0000 (15:44 -0500)]
bash: Support --add completion to git-config.
We've recently added --add as an argument to git-config, but I
missed putting it into the earlier round of git-config updates
within the bash completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:30 +0000 (15:44 -0500)]
bash: Hide git-resolve, its deprecated.
Don't offer resolve as a possible subcommand completion. If you
read the top of the script, there is a big warning about how it
will go away soon in the near future. People should not be using it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:24 +0000 (15:44 -0500)]
bash: Hide diff-stages from completion.
Apparently nobody really makes use of git-diff-stages, as nobody
has complained that it is not supported by the git-diff frontend.
Since its likely this will go away in the future, we should not
offer it as a possible subcommand completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Shawn O. Pearce [Mon, 5 Feb 2007 20:44:22 +0000 (15:44 -0500)]
bash: Support completion on git-cherry.
I just realized I did not support ref name completion for git-cherry.
This tool is just too useful to contributors who submit patches
upstream by email; completion support for it is very handy.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Shawn O. Pearce [Mon, 5 Feb 2007 20:21:06 +0000 (15:21 -0500)]
Show an example of deleting commits with git-rebase.
This particular use of git-rebase to remove a single commit or a
range of commits from the history of a branch recently came up on
the mailing list. Documenting the example should help other users
arrive at the same solution on their own.
It also was not obvious to the newcomer that git-rebase is able to
accept any commit for --onto <newbase> and <upstream>. We should
at least minimally document this, as much of the language in
git-rebase's manpage refers to 'branch' rather than 'committish'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio C Hamano [Mon, 5 Feb 2007 01:30:58 +0000 (17:30 -0800)]
t9200: Work around HFS+ issues.
We at least know that the test as written has a problem in an
environment where "touch '$p'; ls | fgrep '$p'" fails, and have
a clear understand why it fails.
This tests if the filesystem has that particular issue we know "git
add" has a problem with, and skips the test in such an environment.
This way, we might catch issues "git add" might have in other environments.
Shawn O. Pearce [Mon, 5 Feb 2007 21:34:56 +0000 (16:34 -0500)]
Reduce memory usage of fast-import.
Some structs are allocated rather frequently, but were using integer
types which were far larger than required to actually store their
full value range.
As packfiles are limited to 4 GiB we don't need more than 32 bits to
store the offset of an object within that packfile, an `unsigned long`
on a 64 bit system is likely a 64 bit unsigned value. Saving 4 bytes
per object on a 64 bit system can add up fast on any sizable import.
As atom strings are strictly single components in a path name these
are probably limited to just 255 bytes by the underlying OS. Going
to that short of a string is probably too restrictive, but certainly
`unsigned int` is far too large for their lengths. `unsigned short`
is a reasonable limit.
Modes within a tree really only need two bytes to store their whole
value; using `unsigned int` here is vast overkill. Saving 4 bytes
per file entry in an active branch can add up quickly on a project
with a large number of files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Back when I committed this, it seemed to be a good idea. People
who always use remote tracking branches can optionally use the
local name they happen to use to specify what to merge, which meant
that I did not have to teach them why we use the name at the remote
side every time they are confused.
But allowing it seems to break other people's scripts. The real
solution is not to allow more ways to express the same thing, but
to educate people to use the right syntax.
Junio C Hamano [Mon, 5 Feb 2007 00:54:47 +0000 (16:54 -0800)]
Merge branch 'np/dreflog'
* np/dreflog:
show-branch -g: default to the current branch.
Let git-checkout always drop any detached head
Enable HEAD@{...} and make it independent from the current branch
scan reflogs independently from refs
add reflog when moving HEAD to a new branch
create_symref(): do not assume pathname from git_path() persists long enough
add logref support to git-symbolic-ref
move create_symref() past log_ref_write()
add reflog entries for HEAD when detached
enable separate reflog for HEAD
lock_ref_sha1_basic(): remember the original name of a ref when resolving it
make reflog filename independent from struct ref_lock
Junio C Hamano [Sun, 4 Feb 2007 11:25:12 +0000 (03:25 -0800)]
git-clone --reference: saner handling of borrowed symrefs.
When using --reference to borrow objects from a neighbouring
repository while cloning, we copy the entire set of refs under
temporary "refs/reference-tmp/refs" space and set up the object
alternates. However, a textual symref copied this way would not
point at the right place, and causes later steps to emit error
messages (which is harmless but still alarming). This is most
visible when using a clone created with the separate-remote
layout as a reference, because such a repository would have
refs/remotes/origin/HEAD with 'ref: refs/remotes/origin/master'
as its contents.
Although we do not create symbolic-link based refs anymore, they
have the same problem because they are always supposed to be
relative to refs/ hierarchy (we dereference by hand, so it only
is good for HEAD and nothing else).
In either case, the solution is simply to remove them after
copying under refs/reference-tmp; if a symref points at a true
ref, that true ref itself is enough to ensure that objects
reachable from it do not needlessly get fetched.