* 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
* 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.
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.
Extended SHA1 -- "rev^@" syntax to mean "all parents"
A short-hand "rev^@" is understood to be "all parents of the
named commit" with this patch. So you can do
git show v1.0.0^@
to view the parents of a merge commit,
gitk ^v1.0.0^@ v1.0.4
to view the log between two revs (including the bottom one), and
git diff --cc v1.1.0 v1.0.0^@
to inspect what got changed from the merge parents of v1.0.0 to v1.1.0.
This might be just my shiny new toy that is not very useful in
practice. I needed it to do the multi-tree diff on Len's
infamous 12-way Octopus; typing "diff --cc funmerge funmerge^1
funmerge^2 funmerge^3 ..." was too painful.
[jc: taking suggestions from Linus and Johannes to match expectations
from shell users who are used to see $@ or $* either of which makes
sense. I tend to write "$@" more often so...]
You can now select whether you want to see the patch for a commit
or the whole tree. If you select the tree, gitk will now display
the commit message plus the contents of one file in the bottom-left
pane, when you click on the name of the file in the bottom-right pane.
This adds a builtin "push" command, which is largely just a C'ification of
the "git-push.sh" script.
Now, the reason I did it as a built-in is partly because it's yet another
step on relying less on shell, but it's actually mostly because I've
wanted to be able to push to _multiple_ repositories, and the most obvious
and simplest interface for that would seem be to just have a "remotes"
file that has multiple URL entries.
(For "pull", having multiple entries should either just select the first
one, or you could fall back on the others on failure - your choice).
And quite frankly, it just became too damn messy to do that in shell.
Besides, we actually have a fair amount of infrastructure in C, so it just
wasn't that hard to do.
Of course, this is almost totally untested. It probably doesn't work for
anything but the one trial I threw at it. "Simple" doesn't necessarily
mean "obviously correct".
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
"git diff(n)" without --base, --ours, etc. defaults to --cc,
which usually is the same as -p unless you are in the middle of
a conflicted merge, just like the shell script version.
"git diff(n) blobA blobB path" complains and dies.
"git diff(n) tree0 tree1 tree2...treeN" does combined diff that
shows a merge of tree1..treeN to result in tree0.
Giving "-c" option to any command that defaults to "--cc" turns
off dense-combined flag.
replace adler32 with Rabin's polynomial in diff-delta
This brings another small repacking speedup for sensibly the same pack
size. On the Linux kernel repo, git-repack -a -f is 3.7% faster for a
0.4% larger pack.
Credits to Geert Bosch who brought the Rabin's polynomial idea to my
attention.
This also eliminate the issue of adler32() reading past the data buffer,
as noticed by Johannes Schindelin.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* master:
Fix trivial typo in git-log man page.
Properly render asciidoc "callouts" in git man pages.
Fix up remaining man pages that use asciidoc "callouts".
Update the git-branch man page to include the "-r" option,
annotate: display usage information if no filename was given
annotate: fix warning about uninitialized scalar
git-am --resolved: more usable error message.
* fix:
Fix trivial typo in git-log man page.
Properly render asciidoc "callouts" in git man pages.
Fix up remaining man pages that use asciidoc "callouts".
Update the git-branch man page to include the "-r" option,
annotate: display usage information if no filename was given
annotate: fix warning about uninitialized scalar
git-am --resolved: more usable error message.
Properly render asciidoc "callouts" in git man pages.
Adds an xsl fragment to render docbook callouts when
converting to man page format. Update the Makefile
to have "xmlto" use it when generating man pages.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Fix up remaining man pages that use asciidoc "callouts".
Unfortunately docbook does not allow a callout to be
referenced from inside a callout list description.
Rewrite one paragraph in git-reset man page to work
around this limitation.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
After doing the hard work of hand resolving the conflicts in the
working tree, if the user forgets to run update-index to mark
the paths that have been resolved, the command gave an
unfriendly "fatal: git-write-tree: not able to write tree" error
message. Catch the situation early and give more meaningful
message and suggestion.
- number of loose objects
- disk occupied by loose objects
- number of objects in local packs
- number of loose objects that are also in pack
- unrecognised garbage in .git/objects/??/.
We used to omit delta base candidates that is much bigger than
the target, but delta size does not grow when we delete more, so
that was not a very good heuristics.
When I split out the builtin commands into their own files, I left the
include of <sys/ioctl.h> in git.c rather than moving it to the file that
needed it (builtin-help.c).
Nobody seems to have noticed, because everything still worked, but because
the TIOCGWINSZ macro was now no longer defined when compiling the
"term_columns()" function, it would no longer automatically notice the
terminal size unless your system used the ancient "COLUMNS" environment
variable approach.
Trivially fixed by just moving the header include to the file that
actually needs it.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This lets us do things like highlighting all the entries for which
the corresponding part of the diff is at least partly visible in the
commit/patch display window, and in future it will let us display
the file list in a hierarchical form rather than as a flat file list.
* jc/cache-tree:
read-tree: teach 1-way merege and plain read to prime cache-tree.
read-tree: teach 1 and 2 way merges about cache-tree.
update-index: when --unresolve, smudge the relevant cache-tree entries.