After running 'git-update-index' for some paths, you may want to
do the update on the same set of paths again.
The new flag --again checks the paths whose index entries are
are different from the HEAD commit and updates them from the
working tree contents.
This was brought up by Carl Worth on #git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
prefix_path() sometimes allocates new memory and returns it, and
other times returns the incoming path argument intact. The
callers need to be a bit careful not to leak memory.
Signed-off-by: Junio C Hamano <junkio@cox.net>
prefix_path() sometimes allocates new memory and returns it, and
other times returns the incoming path argument intact. The
callers need to be a bit careful not to leak memory.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It completely forgot to take the prefix into account, so you
had to feed the full path even when you start from a
subdirectory, which was nonsensical.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the user interface and generated diff data format.
* "diff --binary" is used to signal that we want an e-mailable
binary patch. It implies --full-index and -p.
* "apply --allow-binary-replacement" acquired a short synonym
"apply --binary".
* After the "GIT binary patch\n" header line there is a token
to record which binary patch mechanism was used, so that we
can extend it later. Currently there are two mechanisms
defined: "literal" and "delta". The former records the
deflated postimage and the latter records the deflated delta
from the preimage to postimage.
For purely implementation convenience, I added the deflated
length after these "literal/delta" tokens (otherwise the
decoding side needs to guess and reallocate the buffer while
inflating). Improvement patches are very welcomed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "binary patch" to the diff output and teaches apply
what to do with them.
On the diff generation side, traditionally, we said "Binary
files differ\n" without giving anything other than the preimage
and postimage object name on the index line. This was good
enough for applying a patch generated from your own repository
(very useful while rebasing), because the postimage would be
available in such a case. However, this was not useful when the
recipient of such a patch via e-mail were to apply it, even if
the preimage was available.
This patch allows the diff to generate "binary" patch when
operating under --full-index option. The binary patch follows
the usual extended git diff headers, and looks like this:
"GIT binary patch\n"
<length byte><data>"\n"
...
"\n"
Each line is prefixed with a "length-byte", whose value is upper
or lowercase alphabet that encodes number of bytes that the data
on the line decodes to (1..52 -- 'A' means 1, 'B' means 2, ...,
'Z' means 26, 'a' means 27, ...). <data> is 1 or more groups of
5-byte sequence, each of which encodes up to 4 bytes in base85
encoding. Because 52 / 4 * 5 = 65 and we have the length byte,
an output line is capped to 66 characters. The payload is the
same diff-delta as we use in the packfiles.
On the consumption side, git-apply now can decode and apply the
binary patch when --allow-binary-replacement is given, the diff
was generated with --full-index, and the receiving repository
has the preimage blob, which is the same condition as it always
required when accepting an "Binary files differ\n" patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
One of my post-update scripts runs a git-fetch into a separate
repository and sends the results back to me (2>&1); I end up
getting this in the mail:
Generating pack...
Done counting 180 objects.
Result has 131 objects.
Deltifying 131 objects.
0% (0/131) done^M 1% (2/131) done^M...
This defaults not to do the progress report when not on a tty.
You could give --progress to force the progress report, but
let's not bother even documenting it nor mentioning it in the
usage string.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When inspecting a project whose build infrastructure used to
assume that .git/HEAD is a symlink ref, core.prefersymlinkrefs
in the config file of such a project would help to bisect its
history.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 9f0bb90d161edf8c43f5261d12bf83f14eb02ff4 commit)
Earlier, calling
git-repo-config core.hello
on a .git/config like this:
[core]
hello = world ; a comment
would yield "world " (i.e. with a trailing space).
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from c1aee1fd8d94da9b3c5d2dc1d4264f7e73a58f80 commit)
Currently, if the target key has a section that matches
the initial substring of another section we mistakenly
believe we've found the correct section. To avoid this
problem, ensure that the section lengths are identical
before comparison.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Document that git-unpack-objects will not produce any
results when used on a pack that exists in a repository;
move it first.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A bare "--" doesn't show up in man or html pages correctly
as two individual dashes unless backslashed as \--
in the asciidoc source. Note, no backslash is needed
inside a literal block.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Move incorrect asciidoc level 2 titles back to level 1.
Show output of git-name-rev in man page example.
Reword sentences that begin with a period (.) in asciidoc
numbered lists to work around conversion to man page bug.
Mention that git-repack now calls git-prune-packed
when the -d option is passed to it.
[imap] section headers in the config file example need to be
contained in a literal block. imap.pass is the proper config
file variable to use, not imap.password.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* Clarify that 'init' requires an argument
* Remove instances of 'SVN_URL' in the manpage, it's not an
environment variable.
* Refer to 'Additional Fetch Arguments' when documenting 'fetch'
* document --authors-file / -A option
Thanks to Pavel Roskin and Seth Falcon for bringing these issues
to my attention.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to depend on bignum from openssl for rev-list to compute
merge-order, but there is no reason to use different build
recipe from other programs anymore. Just build it with git-%$X
rule like everybody else.
Noticed by Alexey Dobriyan.
Signed-off-by: Junio C Hamano <junkio@cox.net>
... so do not get refspecs from remotes/* or the config if one of them
was specified.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/remoteconfig:
Revert "fetch, pull: ask config for remote information"
fetch, pull: ask config for remote information
builtin-push: also ask config for remote information
builtin-push: make it official.
Fix builtin-push to honor Push: lines in remotes file.
builtin-push: resurrect parsing of Push: lines
git builtin "push"
Clean up a few entries and fix typos.
bare repository
cherry-picking
hook
topic branch
[jc: removing questionable "symbolic ref -- see 'ref'" for now.]
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fast forward
pickaxe
refspec
tracking branch
Wild hack allows "link:git-" prefix to reference commands too.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Somebody on the #git channel complained that the sha1_to_hex() thing uses
a static buffer which caused an error message to show the same hex output
twice instead of showing two different ones.
That's pretty easily rectified by making it uses a simple LRU of a few
buffers, which also allows some other users (that were aware of the buffer
re-use) to be written in a more straightforward manner.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-blame useable again, it has been totally broken for
some time on larger repositories.
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was rightly noticed that the logic is quite convoluted. Fix that.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On 5/4/06, Linus Torvalds <torvalds@osdl.org> wrote:
> No it wasn't. "git log --parents" was definitely supposed to still work.
>
> That said, I suspect a git-cvsserver kind of usage is better off using
> "git-rev-list --parents HEAD" instead, which didn't break in the first
> place.
Post 1.3.0 "git log" forgets to list parent commits on the first line
when --parents is given. git-cvsserver relied on it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is useless to preserve multiple hash entries for consecutive blocks
with the same hash. Keeping only the first one will allow for matching
the longest string of identical bytes while subsequent blocks will only
allow for shorter matches. The backward matching code will match the
end of it as necessary.
This improves both performances (no repeated string compare with long
successions of identical bytes, or even small group of bytes), as well
as compression (less likely to need random hash bucket entry culling),
especially with sparse files.
With well behaved data sets this patch doesn't change much.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is my assembly freak side looking at generated code again. And
since create_delta() is certainly pretty high on the radar every bits
count. In this case shorter code is generated if hash_mask is not
copied to a local variable.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When inspecting a project whose build infrastructure used to
assume that .git/HEAD is a symlink ref, core.prefersymlinkrefs
in the config file of such a project would help to bisect its
history.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With --get-regexp, output all key/value pairs where the key matches a
regexp. Example:
git-repo-config --get-regexp remote.*.url
will output something like
remote.junio.url git://git.kernel.org/pub/scm/git/git.git
remote.gitk.url git://git.kernel.org/pub/scm/gitk/gitk.git
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Allow view to specify arbitrary arguments to git-rev-list
gitk: Fix file list display when files are renamed
gitk: Basic support for highlighting one view within another
gitk: Add a tree-browsing mode
gitk: Use a text widget for the file list
gitk: add menu item for editing the current view
gitk: Implement "permanent" views (stored in ~/.gitk)
gitk: Use git-rev-parse only to identify file/dir names on cmd line
gitk: Remember the view in the history list
gitk: Don't reread git-rev-list output from scratch on view switch
gitk: Fix various bugs in the view support
gitk: Make File->Update work properly again
gitk: Implement multiple views
[PATCH] gitk: Add a visual tag for remote refs
The list of arguments to git-rev-list, including arguments that
select the range of commits, is now a part of the view specification.
If any arguments are given to gitk, they become part of the
"Command line" view, and the non-file arguments become the default
for any new views created.
Getting an error from git-rev-list is no longer fatal; instead the
error window pops up, and when you press OK, the main window just
shows "No commits selected".
The git-rev-list arguments are entered in an entry widget in the
view editor window using shell quoting conventions, not Tcl quoting
conventions.
Signed-off-by: Paul Mackerras <paulus@samba.org>
* fix:
git-send-email: fix version string to be valid perl
Give the user a hint for how to continue in the case that git-am fails because it requires user intervention
