* 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
* 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"
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
* 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.
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.
Fix test-dump-cache-tree in one-tree disappeared case.
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().
* 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
improve diff-delta with sparse and/or repetitive data
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>
core.prefersymlinkrefs: use symlinks for .git/HEAD
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.
* 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
gitk: Allow view to specify arbitrary arguments to git-rev-list
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.
* master:
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
repo-config: trim white-space before comment
repo-config: fix segfault with no argument.
* jc/grep:
builtin-grep: support -w (--word-regexp).
builtin-grep: support -c (--count).
builtin-grep: allow more than one patterns.
builtin-grep: allow -<n> and -[ABC]<n> notation for context lines.
* 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
gitk: Fix file list display when files are renamed
The conversion of the file list to use a text widget assumed incorrectly
that the list of files from git-diff-tree -r would correspond 1-1 with
the diff sections in the output of git-diff-tree -r -p -C, which is
not true when renames are detected. This fixes it by keeping the
elements in the difffilestart list in the order they appear in the
file list window.
Since this means that the elements of difffilestart are no longer
necessarily in ascending order, it's somewhat hard to do the dynamic
highlighting in the file list as the diff window is scrolled, so I
have taken that out for now.
The "bind" commit can express an aggregation of multiple
projects into a single commit.
In such an organization, there would be one project, root of
whose tree object is at the same level of the root of the
aggregated projects, and other projects have their toplevel in
separate subdirectories. Let's call that root level project the
"primary project", and call other ones just "subprojects".
You would first read-tree the primary project, and then graft
the subprojects under their appropriate location using read-tree
--prefix=<subdir>/ repeatedly.
To write out a tree object from such an index for a subproject,
write-tree --prefix=<subdir>/ is used.
With "--prefix=<path>/" option, read-tree keeps the current
index contents, and reads the contents of named tree-ish under
directory at `<prefix>`. The original index file cannot have
anything at the path `<prefix>` itself, and have nothing in
`<prefix>/` directory. This can be used to graft an
independent tree into a subdirectory of the current index.
gitk: Basic support for highlighting one view within another
With this, one view can be used as a highlight for another, so that
the commits that are in the highlight view are displayed in bold.
This required some fairly major changes to how the list of ids,
parents, children, and id to row mapping were stored for each view.
We can now be reading in several views at once; for all except the
current view, we just update the displayorder and the lists of parents
and children for the view.
This also creates a little bit of infrastructure for handling the
watch cursor.
Grep may want to grok multiple revisions, but it does not make
much sense to walk revisions while doing so. This stops calling
the code to parse parameters for the revision walker. The
parameter parsing for the optional "-e" option becomes a lot
simpler with it as well.
Still Work-in-progress git fmt-patch (should it be known as
format-patch-ng?) is matched with the fix made by Huw Davies
in 262a6ef76a1dde97ab50d79fa5cd6d3f9f125765 commit to use
RFC2822 date format.
This attempts to set up built-in "git grep" to further reduce
our dependence on the shell, while at the same time optionally
allowing to run grep against object database. You could do
funky things like these:
git grep --cached -e pattern ;# grep from index
git grep -e pattern master ;# or in a rev
git grep -e pattern master next ;# or in multiple revs
git grep -e pattern pu^@ ;# even like this with an
;# extension from another topic ;-)
git grep -e pattern master..next ;# or even from rev ranges
git grep -e pattern master~20:Documentation
;# or an arbitrary tree
git grep -e pattern next:git-commit.sh
;# or an arbitrary blob
Right now, it does not understand and/or obey many options grep
should accept, and the pattern must be given with -e option due
to the way the parameter parser is structured, both of which
obviously need to be fixed for usability.
But this is going in the right direction. The shell script
version is one of the worst Portability offender in the git
barebone Porcelainish; it uses xargs -0 to pass paths around and
shell arrays to sift flags and parameters.
get_sha1(): :path and :[0-3]:path to extract from index.
Earlier patch to say <ent>:<path> by Linus was very useful, and
this extends the same idea to the current index. An sha1
expression :<path> extracts the object name for the named path
from the current index.