I had to move the command line parsing around a little; setup_revisions()
could mistaken <dir> for a valid ref.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When called with "--stdout", it still writes to standard output.
Notable differences to git-format-patch:
- since fmt-patch uses the standardized logging machinery, it is
no longer "From nobody", but "From <commit_sha1>",
- the empty lines before and after the "---" just before the
diffstat are no longer there,
- git-format-patch outputs the commit_sha1 just before the first
diff, which fmt-patch does not,
- the file names are no longer output to stdout, but to stderr
(since stdout is freopen()ed all the time), and
- "git fmt-patch HEAD^" does not work as expected: it outputs
*all* commits reachable from HEAD^!
The last one is possibly a showstopper. At least I used to call that
command quite often...
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
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/fetchconfig:
Add a conversion tool to migrate remote information into the config
fetch, pull: ask config for remote information
Add a few more words to the glossary.
Added definitions for a few words:
Alphabetize the glossary.
sha1_to_hex() usage cleanup
Use this tool to rewrite the .git/remotes/* files into the config.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now you can say
[remote.junio]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = next:next
in your .git/config.
[jc: fixed up the log message that still said "pull" ]
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>
* master:
fix various typos in documentation
blame: Fix path pruning
cvsserver: use git-rev-list instead of git-log
Fix "git-log --parents" breakage post v1.3.0
add documentation for update-index --unresolve
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>
* jc/cache-tree:
cache-tree: a bit more debugging support.
read-tree: invalidate cache-tree entry when a new index entry is added.
Fix test-dump-cache-tree in one-tree disappeared case.
When doing two-way merge, we failed to invalidate the directory
that a new entry is added (we correctly did so for modified and
deleted entries).
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.
When reconstructing an invalidated subtree for reference purposes by
test-dump-cache-tree, we did not handle the case where we shouldn't
have a cached and invalidated subtree in the result, leading to an
unneeded die().
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
* js/repoconfig:
repo-config: readability fixups.
repo-config: support --get-regexp
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
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>
