git-add -u also takes the path limiters, but unlike the
command without the -u option, the code forgot that it
could be invoked from a subdirectory, and did not correctly
handle the prefix.
Signed-off-by: Salikh Zakirov <salikh@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This applies to 'maint' to fix a rather serious data corruption
issue. When "git add -u" affects a subdirectory in such a way
that the only changes to its contents are path removals, the
next tree object written out of that index was bogus, as the
remove codepath forgot to invalidate the cache-tree entry.
Reported by Salikh Zakirov.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We attempt to remove directory that becomes empty after removal
of a file. We should do the same when we rename an existing
file away.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you have a working tree _file_ "foo", attempt to refer to a
branch "foo/bar" without -- to disambiguate, like this:
$ git log foo/bar
tried to make sure that foo/bar cannot be naming a working tree
file "foo/bar" (in which case we would say "which one do you
want? A rev or a working tree file? clarify with -- please").
We run lstat("foo/bar") to check that. If it does not succeed,
there is no ambiguity.
That is good. But we also checked the error status for the
lstat() and expected it to fail with ENOENT. In this particular
case, however, it fails with ENOTDIR. That should be treated as
"expected error" as well.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For the html output we can use a stylesheet to make sure that the
listingblocks are presented in a monospaced font. For the manpages do
it manually by inserting a ".ft C" before and ".ft" after the block in
question.
In order for these roff commands to get through to the manpage they
have to be element encoded to prevent quoting.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When "git checkout-index" checks out path A/B/C, it makes sure A
and A/B are truly directories; if there is a regular file or
symlink at A, we prefer to remove it.
We used to do this by catching an error return from mkdir(2),
and on EEXIST did unlink(2), and when it succeeded, tried
another mkdir(2).
Thomas Glanzmann found out the above does not work on Solaris
for a root user, as unlink(2) was so old fashioned there that it
allowed to unlink a directory.
As pointed out, this still doesn't guarantee that git won't call
"unlink()" on a directory (race conditions etc), but that's
fundamentally true (there is no "funlink()" like there is
"fstat()"), and besides, that is in no way git-specific (ie it's
true of any application that gets run as root).
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier in 16a4c61, we taught "read-tree -m -u" not to be
confused when switching from a branch that has a path frotz/filfre
to another branch that has a symlink frotz that points at xyzzy/
directory. The fix was incomplete in that it was still confused
when coming back (i.e. switching from a branch with frotz -> xyzzy/
to another branch with frotz/filfre).
This fix is rather expensive in that for a path that is created
we would need to see if any of the leading component of that
path exists as a symbolic link in the filesystem (in which case,
we know that path itself does not exist, and the fact we already
decided to check it out tells us that in the index we already
know that symbolic link is going away as there is no D/F
conflict).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Work around bad interaction between Tcl and cmd.exe on ^{tree}
git-gui: Don't linewrap within console windows
git-gui: Correct ls-tree buffering problem in browser
git-gui: Skip nicknames when selecting author initials
git-gui: Ensure windows shortcuts always have .bat extension
git-gui: Include a Push action on the left toolbar
git-gui: Bind M1-P to push action
git-gui: Don't bind F5/M1-R in all windows
git-gui: Unlock the index when cancelling merge dialog
git-gui: properly popup error if gitk should be started but is not installed
From Johannes Sixt <J.Sixt@eudaptics.com>:
> It seems that MSYS's wish does some quoting for Bourne shells,
> in particular, escape the first '{' of the "^{tree}" suffix, but
> then it uses cmd.exe to run "git rev-parse". However, cmd.exe does
> not remove the backslash, so that the resulting rev expression
> ends up in git's guts as unrecognizable garbage: rev-parse fails,
> and git-gui hickups in a way that it must be restarted.
Johannes originally submitted a patch to this section of commit.tcl
to use `git rev-parse $PARENT:`, but not all versions of Git will
accept that format. So I'm just taking the really simple approach
here of scanning the first line of the commit to grab its tree.
About the same cost, but works everywhere.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The 'D' subcommand within a commit can also delete a directory
recursively. This wasn't clear in the prior version of the
documentation, leading to a question on the mailing list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we get more than 80 characters of text in a single line odds
are it is output from git-fetch or git-push and its showing a
lot of detail off to the right edge that is not so important to
the average user. We still want to make sure we show everything
we need, but we can get away with that information being off to
the side with a horizontal scrollbar.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our file browser was showing bad output as it did not properly buffer
a partial record when read from `ls-tree -z`. This did not show up on
my Mac OS X system as most trees are small, the pipe buffers generally
big and `ls-tree -z` was generally fast enough that all data was ready
before Tcl started to read. However on my Cygwin system one of my
production repositories had a large enough tree and packfile that it
took a couple of pipe buffers for `ls-tree -z` to complete its dump.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our blame viewer only grabbed the first initial of the git.git
author string "Simon 'corecode' Schubert". Here the problem was we
looked at Simon, pulled the S into the author initials, then saw
the single quote as the start of the next name and did not like
this character as it was not an uppercase letter.
We now skip over single quoted nicknames placed within the author
name field and grab the initials following it. So the above name
will get the initials SS, rather than just S.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently a user on the mailing list complained that they'd read the
manual but couldn't figure out how to keep a couple private repositories
in sync. They'd tried using push, and were surprised by the effect.
Add a little text in an attempt to make it clear that:
- Pushing to a branch that is checked out will have odd results.
- It's OK to synchronize just using pull if that's simpler.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
- "method of" is vulgar, "method for" is nicer
- "recovery" becomes "recovering" from Steve Hoelzer's original version
of this patch
- "if you want" is nicer as "if you wish"
- "you may" should be "you can"; "you may" is "you have permission to"
rather than "you can"'s "it is possible to"
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
"git apply" used to take check the whitespace in the wrong
direction.
Noticed by Daniel Barkalow.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Apparently under some setups on Windows Tk is hiding our file
extension recommendation of ".bat" from the user and that is
allowing the user to create a shortcut file which has no file
extension. Double clicking on such a file in Windows Explorer
brings up the associate file dialog, as Windows does not know
what application to launch.
We now append the file extension ".bat" to the filename of the
shortcut file if it has no extension or if it has one but it is
not ".bat".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Pushing changes to a remote system is a very common action for
many users of git-gui, so much so that in some workflows a user
is supposed to push immediately after they make a local commit
so that their change(s) are immediately available for their
teammates to view and build on top of.
Including the push button right below the commit button on the
left toolbar indicates that users should probably perform this
action after they have performed the commit action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users often need to be able to push the current branch so that they
can publish their recent changes to anyone they are collaborating
with on the project. Associating a keyboard action with this will
make it easier for keyboard-oriented users to quickly activate the
push features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We actually only want our F5/M1-R keystroke bound in the main window.
Within a browser/blame/console window pressing these keys should not
execute the rescan action.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Pressing the escape key while in the merge dialog cancels the merge
and correctly unlocks the index. Unfortunately this is not true of
the Cancel button, using it closes the dialog but does not release
the index lock, rendering git-gui frozen until you restart it. We
now properly release the index lock when the Cancel button is used.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The -<n> option was not mentioned in git-format-patch's manpage till
now. Fix this.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch, an added file would be reported as /dev/null.
Noticed by David Kastrup.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There is no restriction on the length of the name returned by
get_object_directory, other than the fact that it must be a stat'able
git object directory. That means its name may have length up to
PATH_MAX-1 (i.e., often 4095) not counting the trailing NUL.
Combine that with the assumption that the concatenation of that name and
suffixes like "/info/alternates" and "/pack/---long-name---.idx" will fit
in a buffer of length PATH_MAX, and you see the problem. Here's a fix:
sha1_file.c (prepare_packed_git_one): Lengthen "path" buffer
so we are guaranteed to be able to append "/pack/" without checking.
Skip any directory entry that is too long to be appended.
(read_info_alternates): Protect against a similar buffer overrun.
Before this change, using the following admittedly contrived environment
setting would cause many git commands to clobber their stack and segfault
on a system with PATH_MAX == 4096:
t=$(perl -e '$s=".git/objects";$n=(4096-6-length($s))/2;print "./"x$n . $s')
export GIT_ALTERNATE_OBJECT_DIRECTORIES=$t
touch g
./git-update-index --add g
If you run the above commands, you'll soon notice that many
git commands now segfault, so you'll want to do this:
unset GIT_ALTERNATE_OBJECT_DIRECTORIES
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
I ran git-prune on a repository and got this:
$ git-prune
error: Object 228f8065b930120e35fc0c154c237487ab02d64a is a blob, not a commit
Segmentation fault (core dumped)
This repository was a strange one in that it was being used to provide
its own submodule. That is, the repository was cloned into a
subdirectory, an independent branch checked out in that subdirectory,
and then it was marked as a submodule. git-prune then failed in the
above manner.
The problem was that git-prune was not submodule aware in two areas.
Linus said:
> So what happens is that something traverses a tree object, looks at each
> entry, sees that it's not a tree, and tries to look it up as a blob. But
> subprojects are commits, not blobs, and then when you look at the object
> more closely, you get the above kind of object type confusion.
and included a patch to add an S_ISGITLINK() test to reachable.c's
process_tree() function. That fixed the first git-prune error, and
stopped it from trying to process the gitlink entries in trees as if
they were pointers to other trees (and of course failing, because
gitlinks _aren't_ trees). That part of this patch is his.
The second area is add_cache_refs(). This is called before starting the
reachability analysis, and was calling lookup_blob() on every object
hash found in the index. However, it is no longer true that every hash
in the index is a pointer to a blob, some of them are gitlinks, and are
not backed by any object at all, they are commits in another repository.
Normally this bug was not causing any problems, but in the case of the
self-referencing repository described above, it meant that the gitlink
hash was being marked as being of type OBJ_BLOB by add_cache_refs() call
to lookup_blob(). Then later, because that hash was also pointed to by
a ref, add_one_ref() would treat it as a commit; lookup_commit() would
return a NULL because that object was already noted as being an
OBJ_BLOB, not an OBJ_COMMIT; and parse_commit_buffer() would SEGFAULT on
that NULL pointer.
The fix made by this patch is to not blindly call lookup_blob() in
reachable.c's add_cache_refs(), and instead skip any index entries that
are S_ISGITLINK().
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'show' and 'prune' commands accept an option '-n'; document what
it does.
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
On 'Visualize ...', a gitk process is started. Since it is run in the
background, catching a possible startup error doesn't work, and the error
output goes to the console git-gui is started from. The most probable
startup error is that gitk is not installed; so before trying to start,
check for the existence of the gitk program, and popup an error message
unless it's found.
This was noticed and reported by Paul Wise through
http://bugs.debian.org/429810
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Don't require a .pvcsrc to create Tools/Migrate menu hack
git-gui: Don't nice git blame on MSYS as nice is not supported
git-gui: Don't require $DISPLAY just to get --version
git-gui: Bind Tab/Shift-Tab to cycle between panes in blame
git-gui: Correctly install to /usr/bin on Cygwin
The Tools/Migrate menu option is a hack just for me. Yes, that's
right, git-gui has a hidden feature that really only works for me,
and the users that I support within my day-job's great firewall.
The menu option is not supported outside of that environment.
In the past we only enabled Tools/Migrate if our special local
script 'gui-miga' existed in the proper location, and if there
was a special '.pvcsrc' in the top level of the working directory.
This latter test for the '.pvcsrc' file is now failing, as the file
was removed from all Git repositories due to changes made to other
tooling within the great firewall's realm.
I have changed the test to only work on Cygwin, and only if the
special 'gui-miga' is present. This works around the configuration
changes made recently within the great firewall's realm, but really
this entire Tools/Migrate thing should be abstracted out into some
sort of plugin system so other users can extend git-gui as they need.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt reported that MinGW/MSYS does not have a nice.exe to
drop the priority of a child process when it gets spawned. So we
have to avoid trying to start `git blame` through nice when we are
on Windows and do not have Cygwin available to us.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Print no space after the name of a key without value.
Otherwise keys without values are printed exactly the
same as keys with empty values.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The asciidoc documentation of the --get-regexp option was
incomplete. Add some missing pieces:
- List the option in SYNOPSIS
- Mention that key names are printed
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
A pack-file can get created without any objects in it (to transfer "no
data" - which can happen if you use a reference git repo, for example,
or just otherwise just end up transferring only branch head information
and already have all the objects themselves).
And while we probably should never create an index for such a pack, if we
do (and we do), the index file size sanity checking was incorrect.
This fixes it.
Reported-and-tested-by: Jocke Tjernlund <tjernlund@tjernlund.se>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Without this patch, the code would look for the submodule
commits in the superproject and (needlessly) fail when it
couldn't find them.
Signed-off-by: Sven Verdoolaege <skimo@liacs.nl>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio asked that we don't force the user to have a valid X11 server
configured in $DISPLAY just to obtain the output of `git gui version`.
This makes sense, the user may be an automated tool that is running
without an X server available to it, such as a build script or other
sort of package management system. Or it might just be a user working
in a non-GUI environment and wondering "what version of git-gui do I
have installed?".
Tcl has a lot of warts, but one of its better ones is that a comment
can be continued to the next line by escaping the LF that would have
ended the comment using a backslash-LF sequence. In the past we have
used this trick to escape away the 'exec wish' that is actually a Bourne
shell script and keep Tcl from executing it.
I'm using that feature here to comment out the Bourne shell script and
hide it from the Tcl engine. Except now our Bourne shell script is a
few lines long and checks to see if it should print the version, or not.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The blame viewer is composed of two different areas, the file
area on top and the commit area on the bottom. If users are
trying to shift the focus it is probably because they want to
shift from one area to the other, so we just setup Tab and
Shift-Tab to jump from the one half to the other in a cycle.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Mark Levedahl <mlevedahl@gmail.com> noted that installation on Cygwin
to /usr/bin can cause problems with the automatic guessing of our
library location. The problem is that installation to /usr/bin
means we actually have:
/usr/bin = c:\cygwin\bin
/usr/share = c:\cygwin\usr\share
So git-gui guesses that its library should be found within the
c:\cygwin\share directory, as that is where it should be relative
to the script itself in c:\cygwin\bin.
In my first version of this patch I tried to use `cygpath` to resolve
/usr/bin and /usr/share to test that they were in the same relative
locations, but that didn't work out correctly as we were actually
testing /usr/share against itself, so it always was equal, and we
always used relative paths. So my original solution was quite wrong.
Mark suggested we just always disable relative behavior on Cygwin,
because of the complexity of the mount mapping problem, so that's
all I'm doing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It turns out that the attribute definition we have had for a
long time to hide "^" character from AsciiDoc 7 was not honored
by AsciiDoc 8 even under "-a asciidoc7compatible" mode. There is
a similar breakage with the "compatible" mode with + characters.
The double colon at the end of definition list term needs
to be attached to the term, without a whitespace. After this
minimum fixups, AsciiDoc 8 (I used 8.2.1 on Debian) with
compatibility mode seems to produce reasonably good results.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Johannes and Marco discovered that "git log -z" spent cycles in diff even
though there is no need to actually compute diffs.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The original code did not take hierarchical branch names into account at all.
[jc: cherry-picked 11f68d9 from 'master']
Tested-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
$EMAIL is a system-wide setup that is used for many many many
applications. If the git user chose a specific user.email setup,
then _this_ should be honoured rather than $EMAIL.
[jc: cherry-picked ec563e8 from 'master']
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We already have two instances where we want to determine if a buffer
contains binary data as opposed to text.
[jc: cherry-picked 6bfce93e from 'master']
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The function converts the value of h_errno (last error of name
resolver library, see netdb.h).
One of systems which supposedly do not have the function is SunOS.
POSIX does not mandate its presence.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes --suppress-from actually work when you're unfortunate enough
to have non-ASCII in your name. Also, if there's a match use the optionally
RFC2047 quoted version from the email.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Save geometry before the window layout is damaged
git-gui: Give amend precedence to HEAD over MERGE_MSG
git-gui: Include 'war on whitespace' fixes from git.git
Because Tk does not assure us the order that it will process
children in before it destroys the main toplevel we cannot safely
save our geometry data during a "bind . <Destroy>" event binding.
The geometry may have already changed as a result of a one or
more children being removed from the layout. This was pointed
out in gitk by Mark Levedahl, and patched over there by commit
b6047c5a81.
So we now also use "wm protocol . WM_DELETE_WINDOW" to detect when
the window is closed by the user, and forward that close event to
our main do_quit routine.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently git-commit.sh (the command line commit user interface in
core Git) always gives precedence to the prior commit's message if
`commit --amend` is used and a $GIT_DIR/MERGE_MSG file also exists.
We actually were doing the same here in git-gui, but the amended
message got lost if $GIT_DIR/MERGE_MSG already existed because
we started a rescan immediately after loading the prior commit's
body into the edit buffer. When that happened the rescan found
MERGE_MSG existed and replaced the commit message buffer with the
contents of that file. This meant the user never saw us pick up
the commit message of the prior commit we are about to replace.
Johannes Sixt <J.Sixt@eudaptics.com> found this bug in git-gui by
running `git cherry-pick -n $someid` and then trying to amend the
prior commit in git-gui, thus combining the contents of $someid
with the contents of HEAD, and reusing the commit message of HEAD,
not $someid. With the recent changes to make cherry-pick use the
$GIT_DIR/MERGE_MSG file Johannes saw git-gui pick up the message
of $someid, not HEAD. Now we always use HEAD if we are amending.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Earlier git.git applied a large "war on whitespace" patch that was
created using 'apply --whitespace=strip'. Unfortunately a few of
git-gui's own files got caught in the mix and were also cleaned up.
That was a6080a0a44.
This patch is needed in git-gui.git to reapply those exact same
changes here, otherwise our version generator script is unable to
obtain our version number from git-describe when we are hosted in
the git.git repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'maint' of git://repo.or.cz/git-gui: (46 commits)
git-gui: Changed blame header bar background to match main window
git-gui: Favor the original annotations over the recent ones
git-gui: Improve our labeling of blame annotation types
git-gui: Use three colors for the blame viewer background
git-gui: Jump to original line in blame viewer
git-gui: Display both commits in our tooltips
git-gui: Run blame twice on the same file and display both outputs
git-gui: Display the "Loading annotation..." message in italic
git-gui: Rename fields in blame viewer to better descriptions
git-gui: Label the uncommitted blame history entry
git-gui: Switch internal blame structure to Tcl lists
git-gui: Cleanup redundant column management in blame viewer
git-gui: Better document our blame variables
git-gui: Remove unused commit_list from blame viewer
git-gui: Automatically expand the line number column as needed
git-gui: Make the line number column slightly wider in blame
git-gui: Use lighter colors in blame view
git-gui: Remove unnecessary space between columns in blame viewer
git-gui: Remove the loaded column from the blame viewer
git-gui: Clip the commit summaries in the blame history menu
...
The word "changelog" seems a little too much like jargon to me, and beginners
must understand section headers so they know where to look for help.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
In Documentation/user-manual.txt the example
$ git checkout --track -b origin/maint maint
under "Getting updates with git pull", should read
$ git checkout --track -b maint origin/maint
This was noticed by Ron, and reported through
http://bugs.debian.org/427502
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Update text to reflect new position in appendix.
Update the name to reflect the fact that this is closer to reference
than tutorial documentation (as suggested by Jonas Fonseca).
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
In several of the text messages, the tense of the verb is inconsistent.
For example, "Add" vs "Creates". It is customary to use imperative for
command description.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Although it is not advisable, we have always allowed a branch
and a tag to have the same basename (i.e. it is not illegal to
have refs/heads/frotz and refs/tags/frotz at the same time).
When talking about a specific commit, the interpretation of
'frotz' has always been "use tag and then check branch",
although we warn when ambiguities exist.
However "git checkout $name" is defined to (1) first see if it
matches the branch name, and if so switch to that branch; (2)
otherwise it is an instruction to detach HEAD to point at the
commit named by $name. We did not follow this definition when
$name appeared under both refs/heads/ and refs/tags/ -- we
switched to the branch but read the tree from the tagged commit,
which was utterly bogus.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The main window's diff header bar background switched from orange
to gold recently, and I liked the effect it had on readability of
the text. Since I wanted the blame viewer to match, here it is.
Though this probably should be a user defined color, or at least
a constant somewhere that everyone can reference.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The problem is visible when cloning a local repo. The cloned
repository will have the origin url setup incorrectly: the origin name
will be copied verbatim in origin url of the cloned repository.
Normally, the name is to be expanded into absolute path.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When scanning the trees in track_tree_refs() there is a "lazy" test
that assumes that entries are either directories or files. Don't do
that.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
CVS import was failing on a couple repos I was trying to import.
I was setting GIT_DIR=newproj.git and using the -i flag, but this bug
was thwarting the effort... evil CVS.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
unpack-objects -n didn't print the object list as promised on the
manual page, so alter the documentation to reflect the behaviour
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Tests with git-filter-branch on a repository that was converted from
CVS and that has commits reaching back to 1999 revealed that it is
necessary to parse dates before 2000/01/01 when they are specified
as seconds since 1970/01/01. There is now still a limit, 100000000,
which is 1973/03/03 09:46:40 UTC, in order to allow that dates are
represented as 8 digits.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Usually when you are looking at blame annotations for a region of
a file you are more interested in why something was originally
done then why it is here now. This is because most of the time
when we get original annotation data we are looking at a simple
refactoring performed to better organize code, not to change its
semantic meaning or function. Reorganizations are sometimes of
interest, but not usually.
We now show the original commit data first in the tooltip. This
actually looks quite nice as the original commit will usually have an
author date prior to the current (aka move/copy) annotation's commit,
so the two commits will now tend to appear in chronological order.
I also found myself to always be clicking on the line of interest
in the file column but I always wanted the original tracking data
and not the move/copy data. So I changed our default commit from
$asim_data (the simple move/copy annotation) to the more complex
$amov_data (the -M -C -C original annotation).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It feels wrong to call the -M -C -C annotations "move/copy tracking"
as they are actually the original locations. So I'm relabeling
the status bar to show "copy/move tracking annotations" for the
current file (no -M -C -C) as that set of annotations tells us who
put the hunk here (who moved/copied it). I'm now calling the -M
-C -C pass "original location annotations" as that's what we're
really digging for.
I also tried to clarify some of the text in the hover tooltip.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To prevent neighboring lines that are different commits from using
the same background color we now use 3 colors and assign them
by selecting the color that is not used before or after the line
in question. We still color "on the fly" as we receive hunks from
git-blame, but we delay our color decisions until we are getting
the original location data (the slower -M -C -C pass) as that is
usually more fine-grained than the current location data.
Credit goes to Martin Waitz for the tri-coloring concept.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the user clicks on a commit link within one of the columns
in the blame viewer we now jump them not just to that commit/file
pair but also to the line of the original file. This saves the
user a lot of time, as they don't need to search through the new
file data for the chunk they were previously looking at.
We also restore the prior view when the user clicks the back button
to return to a pior commit/file pair that they were looking at.
Turned out this was quite tricky to get working in Tk. Every time
I tried to jump the text widgets to the correct locations by way
of the "yview moveto" or "see" subcommands Tk performed the change
until the current event finished dispatching, and then reset the
views back to 0, making the change never take place. Forcing Tk
to run the pending events before we jump the UI resolves the issue.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have commit data from both the simple blame and the
rename/move tracking blame and they differ than there is a
bigger story to tell. We now include data from both commits
so that the user can see that this link as moved, who moved
it, and where it originated from.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now perform two passes over any input file given to the blame
viewer. Our first pass is a quick "git-blame" with no options,
getting the details of how each line arrived into this file. We
are specifically ignoring/omitting the rename detection logic as
this first pass is to determine why things got into the state they
are in.
Once the first pass is complete and is displayed in the UI we run
a second pass, using the much more CPU intensive "-M -C -C" options
to perform extensive rename/movement detection. The output of this
second pass is shown in a different column, allowing the user to see
for any given line how it got to be, and if it came from somewhere
else, where that is.
This is actually very instructive when run on our own lib/branch.tcl
script. That file grew recently out of a very large block of code
in git-gui.sh. The first pass shows when I created that file, while
the second pass shows the original commit information.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user clicks on a line region that we haven't yet received
an annotation for from git-blame we show them "Loading annotation".
But I don't want the user to confuse this loading message with a
commit whose first line is "Loading annotation" and think we messed
up our display somehow. Since we never use italics for anything
else, I'm going with the idea that italic slant can be used to show
data is missing/elided out at the time being.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Calling the commit message pane $w_cmit is a tad confusing when
we also have the $w_cgrp column that shows the abbreviated SHA-1s.
So w_cmit -> w_cviewer, as it is the "commit viewer"; and
w_cgrp -> w_amov as it is the "annotated commit + move tracking"
column. Also changed line_data -> amov_data, as that list is
exactly the results shown in w_amov.
Why call the column "move tracking"? Because this column holds
data from "git blame -M -C". I'm considering adding an additional
column that holds the data from "git blame" without -M/-C, showing
who did the copy/move, and when they did it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user runs the blame viewer on a working directory file
instead of a specific commit-ish then we have no value for the
commit SHA1 or the summary line; this causes the history menu
to get an empty entry at the very bottom. We now look for this
odd case and call the meny entry "Working Directory".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tcl list datatype is significantly faster to work with than
the array type, especially if our indexes are a consecutive set
of numbers, like say line numbers in a file.
This rather large change reorganizes the internal data structure
of the blame viewer to use a proper Tcl list for the annotation
information about a line. Each line is given its own list within
the larger line_data list, where the indexes correspond to various
facts about that particular line.
The interface does seem to be more responsive this way, with less
time required by Tcl to process blame, and to switch to another
version of the same file. It could just be a placebo effect, but
either way most Tcl experts perfer lists for this type of work over
arrays.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The code to handle our three different text widgets is a bit
on the messy side as we issue the same command on all three
widgets one at a time. Adding (or removing) columns from the
viewer is messy, as a lot of locations need to have the new
column added into the sequence, or removed from it.
We also now delete the tags we create for each commit when
we switch to display another "commit:path" pair. This way the
text viewer doesn't get bogged down with a massive number of tags
as we traverse through history.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The array variable "order" used to be used to tell us in what
order each commit was received in. Recent changes have removed
that need for an ordering and the "order" array is now just a
boolean 'do we have that commit yet' flag.
The colors were moved to fields, so they appear inside of the
blame viewer instance. This keeps two different concurrently
running blame viewers from stepping on each other's ordering
of the colors in group_colors.
Most of the other fields were moved around a little bit so
that they are organized by major category and value lifespan.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This list used to store the commits in the order we received
them in. I originally was using it to update the colors of
the commit before and the commit after the current commit,
but since that interface concept turned out to be horribly
ugly and has been removed we no longer need this list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
After we finish reading a chunk of data from the file stream
we know how many digits we need in the line number column to
show the current maximum line number. If our line number column
isn't wide enough, we should expand it out to the correct width.
Any file over our default allowance of 5 digits (99,999 lines)
is so large that the slight UI "glitch" when we widen the column
out is trivial compared to the time it will take Git to fully do
the annotations.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most source code files are under 9,999 lines of text, so using a
field width of 5 characters meant that we should have had one char
padding on the left edge (because we right-justify the line number).
Unfortunately when I added the right margin earlier (when I removed
the padding) I ate into the extra character's space, losing the left
margin. This put the line numbers too close to the commit column in
any file with more than 999 lines in it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The colors I originally picked out on a Mac OS X system look a
tad too dark on a Windows 2000 system; the greys are dark enough
to make it difficult to read some lines of text and the green used
to highlight the current commit was also difficult to read text on.
I also added a third grey to the mix, to try and help some files
that wind up with a number of neighboring chunks getting the same
colors.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
On Mac OS X the OS has "features" that like to draw thick black
borders around the text field that has focus. This is nice if
you want to know where your text is going and are blind as a bat,
but it isn't the best thing to have in a table that is being
faked through the abuse of Tk text widgets.
By setting our takefocus, highlightthickness and padx/y we can
get rid of this border and get our text widgets packed right next
to each other, with no padding between them. This makes the blame
background color smoothly run across the entire line of commit data,
line number and file content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Originally I had placed this loaded column between the line number
and the file line data to help users know if a particular line has
received annotation data or not yet. This way users would know if
the line(s) they were interested in were ready for viewing, or if
they still had to wait. It also was an entertaining way for the
user to spend their time waiting for git-blame --incremental to
compute the complete set of annotations.
However it is completely useless now that we show the abbreviated
commit SHA-1 and author initials in the leftmost column. That area
is empty until we get the annotation data, and as soon as we get it
in we display something there, indicating to the user that there is
now blame data ready. Further with the tooltips the user is likely
to see the data as soon as it comes in, as they are probably not
keeping their mouse perfectly still. So I'm removing the field to
save screen space for more useful things, like file content.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some commit lines can get really long when users enter a lot of
text without linewrapping (for example). Rather than letting the
menu get out of control in terms of width we clip the summary to
the first 50+ characters.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Apparently Tk on Mac OS X won't draw a button with an image using a
transparent background. Instead it draws the button using some sort
of 3D effect, even though I asked for no relief and no border. The
background is also not our orange that we expected it to be.
Earlier I had tried this same trick on Windows and it draws the same
way as the button did, so I'm going to switch to the label as that
seems to be more portable.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we have two commits right next to each other in the final
file and they were kept as different blocks in the leftmost
column then its probably because the original filename was
different. To help the user know where they are digging into
when they click on that link we now show the original file in
the tooltip, but to save space we do so only if the original
file is not the same as the file we are currently viewing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Consecutive chunks of a file could come from the same commit, but
have different original file names. Previously we would have put
them into a single group, but then the hyperlink would jump to only
one of the files, and the other would not be accessible. Now we can
get to the other file too.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
gitweb has long had a feature where the user can click on any
commit the blame display and go visit that commit's information
page. From the user could go get the blame display for the file
they are tracking, and try to digg through the history of any
part of the code they are interested in seeing.
We now offer somewhat similiar functionality in git-gui. The 4
digit commit abreviation in the first column of our blame view is
now offered as a hyperlink if the commit isn't the one we are now
viewing the blame output for (as there is no point in linking back
to yourself). Clicking on that link will stop the current blame
engine (if still running), push the new target commit onto the
history stack, and restart the blame viewer at that commit, using
the "original file name" as supplied by git-blame for that chunk
of the output.
Users can navigate back to a version they had been viewing before
by way of a back button, which offers the prior commits in a popup
menu displayed right below the back button. I'm always showing the
menu here as the cost of switching between views is very high; you
don't want to jump to a commit you are not interested in looking at
again.
During switches we throw away all data except the cached commit data,
as that is relatively small compared to most source files and their
annotation marks. Unfortunately throwing this per-file data away in
Tcl seems to take some time; I probably should move the line indexed
arrays to proper lists and use [lindex] rather than the array lookup
(usually lists are faster).
We now start the git-blame process using "nice", so that its priority
will drop hopefully below our own. If I don't do this the blame engine
gets a lot of CPU under Windows 2000 and the git-gui user interface is
almost non-responsive, even though Tcl is just sitting there waiting
for events.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Computing the blame records for a large file with a long project
history can take git a while to run; traditionally we have shown
a little meter in the status area of our blame viewer that lets
the user know how many lines have been finished, and how far we
are through the process.
Usually such progress indicators are drawn with a little progress
bar in the window, where the bar shows how much has been completed
and hides itself when the process is complete. I'm using a very
simple hack to do that: draw a canvas with a filled rectangle.
Of course the time remaining has absolutely no relationship to the
progress meter. It could take very little time for git-blame to get
the first 90% of the file, and then it could take many times that to
get the remaining 10%. So the progress meter doesn't really have any
sort of assurances that it relates to the true progress of the work.
But in practice on some ugly history it does seem to hold a reasonable
indicator to the completion status. Besides, its amusing to watch and
that keeps the user from realizing git is being somewhat slow.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
At one point I tried to present the blame viewer to an audience of
people on a 640 by 480 pixel LCD projector. This did not work at
all as the top area (the file data) was taking up all of the screen
realestate and the split point was not adjustable by the user. In
general locking the user into a specific ratio of display is just
not user friendly.
So we now place a split pane control into the middle of our blame
window, so the user can adjust it to their current needs. If the
window increases (or decreases) in height we assign the difference
to the file data area, as that is generally the area of the window
that users are trying to see more of when they grow the window.
Unfortunately there appears to be a bug in the "pack" layout manager
in Tcl/Tk 8.4.1. The status bar and the lower commit pane was being
squashed if the window decreased in height. I think the pack manager
was just not decreasing the size of the panedwindow slave properly if
the main window shrank. Switching to the "grid" layout manager fixes
the problem, but is slightly uglier setup code.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Frequently when I'm looking at blocks of code in the blame
viewer I want to know who is the culprit, or who I should
be praising for a job well done. The tooltips nicely show
this if I mouse over a block, but it doesn't work to get
this detail at a glance.
Since we don't use the leftmost commit column for anything
after the first line within a commit group I'm now tossing
the author's initials into that field, right justified. It
is quite clearly not a SHA-1 number as we always show the
SHA-1 in lowercase, while we explicitly select only the
uppercase characters from an author's name field, and only
those that are following whitespace.
I'm using initials here over anything else as they are quite
commonly unique within small development teams. The leading
part of the email address field was out for some of the teams
I work with, as there the email addresses are all of the form
"Givenname.Surname@initech.com". That will never fit into the
4 characters available.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The | in the continued lines of the same commit group as not
easily seen on the left edge; putting a single space in front
of the pipe makes it slightly more visually appealing to me as
I can follow the line down through the group to the next commit
marker.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we no longer redraw colors every time we select a particular
commit there is no need to redraw the screen after we get a new commit
in from blame --incremental.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The selected commit's blame header is now drawn in green, using
the same background color that is shown in the main file content
viewer. The result is a much better looking commit pane, as we
use bold for header "keys" and proportional width fonts for the
stuff that doesn't need to be fixed width to maintain its formatting.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the mouse is over a particular line and we have blame data
for that line, but its not the active commit, we should show the
user information about that commit like who the author was and
what the subject (first line) was.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we don't allow the user to select text from the file
viewer right now I'm disabling the normal text cursor and
putting in a plain arror instead. This way users don't
think they can select and copy text, because they can't.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If two consecutive lines in the final file came from the same commit
then we store a "|" in the first column rather than the commit id,
for the second and subsequent lines in that block. This cleans up
the interface so runs associated with the same commit can be more
easily seen visually.
We also now use the abbreviation "work" for the uncommitted stuff in
your working directory, rather than "0000". This looks nicer to the
eyes and explains pretty quickly what is going on.
There was also a minor bug in the commit abbreviation column for the
last line of the file. This is now also fixed.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The git-gui blame viewer has always been ugly as s**t. Linus Torvalds
suggested the coloring scheme I'm using here, which is two different
shades of grey for the background colors, and black text on a pale green
background for the currently selected/focused commit.
The difference is a massive improvement. The interface no longer will
cause seizures in people who are prone to that sort of thing. It no
longer uses a very offensive hot pink. The green being current actually
makes sense. And not having the background of the other non-current
lines change when you change the current commit is really a big deal.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The blame viewer has this silly blank line at the bottom of it;
we really don't want to see it displayed as we will never get
any blame data for that line (it doesn't exist in the source).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A lot of this code was pre-class, which meant that I just sort of
copied and pasted my way through it, rather than being really smart
and using a variable for each widget's path name. Since we have a
field for each path, we can use those throughout the constructor
and make things a lot neater.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We now show the first 4 digits of each commit in the left most
column of our blame viewer, before the line numbers. These are
drawn as the data becomes available from git-blame --incremental,
and helps the user to visually group lines together.
I'm using only the first 4 digits because within a given cluster
of lines its unlikely that two neighboring commits will have the
same 4 digit prefix.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The default font was already bold, so marking the selected file with bold
font did not work. Change that to lightgray background.
Also, the header colors are now softer, giving better readability.
Signed-off-by: Matthijs Melchior <mmelchior@xs4all.nl>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit c289f6fa1f.
Junio pointed out that Alex's change breaks in some cases, like
when V=1, and is more verbose than it should be even if that worked.
I'm backing it out and redoing it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For quite a while we have been assuming the user is running on
a Tcl/Tk 8.4 or later platform. This may not be the case on
some very old systems. Unfortunately I am pretty far down the
path of using the Tcl/Tk 8.4 commands and options and cannot
easily work around them to support earlier versions of Tcl/Tk.
So we'll check that we are using the correct version up front,
and if not we'll stop with a related error message.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Earlier I missed making sure our spinbox widgets used the same font
as the other widgets around them. This meant that using a main font
with a size of 20 would make every widget in the options dialog huge,
but the spinboxes would be left with whatever the OS native font is.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Encode ' ' using '=20' even though rfc2047 allows using '_' for
readability. Unfortunately, many programs do not understand this and
just leave the underscore in place. Using '=20' seems to work better.
[jc: with adjustment to t3901]
Signed-off-by: Kristian Høgsberg <hoegsberg@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Only git-ls-files(1) describes the gitignore format in detail, and it does so
with reference to git-ls-files options. Most users don't use the plumbing
command git-ls-files directly, and shouldn't have to look in its manpage for
information on the gitignore format.
Create a new manpage gitignore(5) (Documentation/gitignore.txt), and factor
out the gitignore documentation into that file, changing it to refer to
.gitignore and $GIT_DIR/info/exclude as used by porcelain commands. Reference
gitignore(5) from other relevant manpages and documentation. Remove
now-redundant information on exclude patterns from git-ls-files(1), leaving
only information on how git-ls-files options specify exclude patterns and what
precedence they have.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of using sed on the resulting file, we now have a
git_version asciidoc attribute. This means that we don't
pipe the output of asciidoc, which means we can detect build
failures.
Problem reported by Scott Lamb, solution suggested by Jonas Fonseca.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Its wrong to exit the application if we destroy a random widget
contained withing something else; especially if its some small
trivial thing that has no impact on the overall operation.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt pointed out that dropping to 0 lines of context
does allow the user to get more fine-grained hunk selection,
especially since we don't currently support "highlight and
apply (or revert)".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint-1.5.1:
git-config: Improve documentation of git-config file handling
git-config: Various small fixes to asciidoc documentation
decode_85(): fix missing return.
fix signed range problems with hex conversions
The description which files git-config uses and how the various
command line options and environment variables affect its
behaviour was incomplete, outdated and confusing.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add '' around the only mentioned commandline option that didn't
have it.
Make reference to section EXAMPLE a link and rename it to
EXAMPLES because it actually contains a lot of examples.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the user has no branches at all (their refs/heads/ is empty)
and they are on a detached HEAD we have a valid repository but
there are no branches to populate into the branch pulldown in
the create branch dialog. Instead of erroring out we can skip
that part of the dialog, much like we do with tracking branches
or tags when the user doesn't have any.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the function detected an invalid base85 sequence, it issued
an error message but forgot to return error status at that point
and kept going.
Signed-off-by: Jerald Fitzjerald <jfj@freemail.gr>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make hexval_table[] "const". Also make sure that the accessor
function hexval() does not access the table with out-of-range
values by declaring its parameter "unsigned char", instead of
"unsigned int".
With this, gcc can just generate:
movzbl (%rdi), %eax
movsbl hexval_table(%rax),%edx
movzbl 1(%rdi), %eax
movsbl hexval_table(%rax),%eax
sall $4, %edx
orl %eax, %edx
for the code to generate a byte from two hex characters.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reasonably new versions of the cvs CLI client allow one to
specifiy CVS_SERVER as a method variable directly in
CVSROOT. This is way more convinient than using an
environment variable since it gets saved in CVS/Root.
Since I only discovered this by accident I guess there
might be others out there that learnt CVS on the 1.11
series (or even earlier) and profit from such a note
about cvs improvements in the last couple years.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
While the given example worked, it made us look rather
incompetent. Give the correct reason why one needs the
more complex syntax and change the example to reflect
that.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This test case would have caught the bug fixed by revision
c23290d5.
It puts various forms of $Id$ into a file in the repository,
without allowing git to collapse them to uniformity. Then enables the
$Id$ expansion on checkout, and checks that what is checked out has
coped with the various forms.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There's no point in calculating an MD5 if we're not going to use
it. We'll also avoid the possibility of there being a bug in the
Perl MD5 library not being able to handle zero-sized files.
This is a followup to 20b3d206ac,
which allows us to track repositories that do not provide MD5
checksums.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Guess our share/git-gui/lib path at runtime if possible
Correct key bindings to Control-<foo>
git-gui: Tighten internal pattern match for lib/ directory
Those are builtins. Remove them from PROGRAMS variable
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Johannes Sixt asked me to try to avoid embedding the runtime location
of git-gui's library directory in the executable script. Not embedding
it helps the MinGW to be relocatable to another directory should a user
wish to install the programs in a directory other than the location the
packager wanted them to be installed into.
Most of this is a hack. We try to determine if the path of our master
git-gui script will be able to locate the lib by ../share/git-gui/lib.
This should be true if $(gitexecdir) and $(libdir) have the same prefix.
If they do then we defer the assignment of $(libdir) until runtime, and
we get it from $argv0 rather than embedding it into the script itself.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint-1.5.1:
Fix git-svn to handle svn not reporting the md5sum of a file, and test.
More echo "$user_message" fixes.
Add tests for the last two fixes.
git-commit: use printf '%s\n' instead of echo on user-supplied strings
git-am: use printf instead of echo on user-supplied strings
Documentation: Add definition of "evil merge" to GIT Glossary
Replace the last 'dircache's by 'index'
Documentation: Clean up links in GIT Glossary
If the repository contained an expanded ident keyword (i.e. $Id:XXXX$),
then the wrong bytes were discarded, and the Id keyword was not
expanded. The fault was in convert.c:ident_to_worktree().
Previously, when a "$Id:" was found in the repository version,
ident_to_worktree() would search for the next "$" after this, and
discarded everything it found until then. That was done with the loop:
do {
ch = *cp++;
if (ch == '$')
break;
rem--;
} while (rem);
The above loop left cp pointing one character _after_ the final "$"
(because of ch = *cp++). This was different from the non-expanded case,
were cp is left pointing at the "$", and was different from the comment
which stated "discard up to but not including the closing $". This
patch fixes that by making the loop:
do {
ch = *cp;
if (ch == '$')
break;
cp++;
rem--;
} while (rem);
That is, cp is tested _then_ incremented.
This loop exits if it finds a "$" or if it runs out of bytes in the
source. After this loop, if there was no closing "$" the expansion is
skipped, and the outer loop is allowed to continue leaving this
non-keyword as it was. However, when the "$" is found, size is
corrected, before running the expansion:
size -= (cp - src);
This is wrong; size is going to be corrected anyway after the expansion,
so there is no need to do it here. This patch removes that redundant
correction.
To help find this bug, I heavily commented the routine; those comments
are included here as a bonus.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates t4014 to check the two fixes for git-am and git-commit
we observed with "echo" that does backslash interpolation by default
without being asked with -e option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the same issue git-am had, which was fixed by Jeff
King in the previous commit. Cleverly enough, this commit's log
message is a good test case at the same time.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Under some implementations of echo (such as that provided by
dash), backslash escapes are recognized without any other
options. This means that echo-ing user-supplied strings may
cause any backslash sequences in them to be converted. Using
printf resolves the ambiguity.
This bug can be seen when using git-am to apply a patch
whose subject contains the character sequence "\n"; the
characters are converted to a literal newline. Noticed by
Szekeres Istvan.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ensure that the same link is not repeated in single glossary entry,
and that there is no self-link i.e. link to current entry.
Add links to other definitions in git glossary.
Remove inappropriate (nonsense) links, or change link to link to
correct definition (to correct term).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git/fastimport:
Update bash completion for git-config options
Teach bash completion about recent log long options
Teach bash completion about 'git remote update'
Update bash completion header documentation
Remove a duplicate --not option in bash completion
Teach bash completion about git-shortlog
Hide the plumbing diff-{files,index,tree} from bash completion
Update bash completion to ignore some more plumbing commands
When check_sha1_signature fails, program is not terminated:
it prints an error message and returns NULL, so the
buffer returned by read_sha1_file should be freed before.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In git.git repository, "git-name-rev v1.3.0~158" cannot name the
rev, while adjacent revs can be named.
This was because it gives up traversal from the tips of existing
refs as soon as it sees a commit that has older commit timestamp
than what is being named. This is usually a good heuristics,
but v1.3.0~158 has a slightly older commit timestamp than
v1.3.0~157 (i.e. it's child), as these two were made in a
separate repostiory (in fact, in a different continent).
This adds a hardcoded slop value (1 day) to the cut-off
heuristics to work this kind of problem around. The current
algorithm essentially runs around from the available tips down
to ancient commits and names every single rev available that are
newer than cut-off date, so a single day slop would not add that
much overhead in repositories with long enough history where the
performance of name-rev matters.
I think the algorithm could be made a bit smarter by deepening
the graph on demand as a new commit is asked to be named (this
would require rewriting of name_rev() function not to recurse
itself but use a traversal list like revision.c traverser does),
but that would be a separate issue.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Alberto Bertogli reported on #git that git-gui was exiting with
alt-q, while gitk on the same system was exiting with ctrl-q.
That was not what I wanted. I really wanted M1B to be bound to
the Control key on most non-Mac OS X platforms, but according to
Sam Vilain M1 on most systems means alt. Since gitk always does
control, I'm doing the same thing for all non-Mac OS X systems.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A few new configuration options grew out of the woodwork during the
1.5.2 series. Most of these are pretty easy to support a completion
of, so we do so.
I wanted to also add completion support for the <driver> part of
merge.<driver>.name but to do that we have to look at all of the
.gitattributes files and guess what the unique set of <driver>
strings would be. Since this appears to be non-trivial I'm punting
on it at this time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
(Somewhat) recently git-log learned about --reverse (to show commits
in the opposite order) and a looong time ago I think it learned
about --raw (to show the raw diff, rather than a unified diff).
These are both useful options, so we should make them easy for the
user to complete.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently the git-remote command grew an update subcommand, which
can be used to execute git-fetch across multiple repositories
in a single step. These can be configured with the 'remotes.*'
configuration options, so we can offer completion for any name that
matches and appears to be useful to git-remote update.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
1) Added a note about supporting the long options for most commands,
as we have been doing so for quite some time.
2) Include a notice that these routines are covered by the GPL,
as that may not be obvious, even though they are distributed
as part of the core Git distribution.
3) Added a short section on how to send patches to the routines,
and to whom they should get sent to. Currently that is me,
as I am the active maintainer.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This was just me being silly; I put the --not option into the
completion list twice. There's no duplicates shown in the shell
as the shell removes them before showing them to the user. But we
really don't need the duplicates in the source script either.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We've had completion for git-log for quite some time, but just
today I noticed we don't have it for the new builtin shortlog
that runs git-log internally. This is indeed a handy thing to
have completion for, especially when your branch names are of
the Very-Very-Long-and-Hard/To-Type/Variety/That-Some-Use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The diff-* programs are meant to be plumbing for the diff frontend;
most end users aren't invoking these commands directly. Consequently
we should avoid showing them as possible completions.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When e8438420bb allowed us to reload
the marks table on subsequent runs of fast-import we really broke
things, as we set pack_id to MAX_PACK_ID for any objects we imported
into the marks table. Creating a branch from that mark should fail
as we attempt to read the object through a non-existant packed_git
pointer. Instead we have to use the normal Git object system to
locate the older commit, as we ourselves do not have a reference
to the packed_git it resides in.
This bug only occurred because t9300 was not complete enough.
When we added the --import-marks feature we didn't actually test
its implementation enough to verify the function worked as intended.
I have corrected that, and included the changes as part of this fix.
Prior versions of fast-import fail the new test(s); this commit
allows them to pass.
Credit for this bug find goes to Simon Hausmann <simon@lst.de> as
he recently identified a similiar bug in the tree lazy-loading path.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To resolve a corner case uncovered by Simon Hausmann I need to
reuse the logic for the SHA-1 expression version of the 'from '
command within the mark version of the 'from ' command. This change
doesn't alter any functionality, but is merely breaking the common
code out to a function that I can reuse.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Commit a5c1780a03 sets the pack_id of existing
objects to MAX_PACK_ID. When the same object is referenced later again it is
found in the local object hash. With such a pack_id fast-import should not try
to locate that object in the newly created pack(s).
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Fix uninitialized last_object->no_free variable that is accessed in
store_object.
Signed-off-by: Simon Hausmann <simon@lst.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This works in repositories that have their refs packed by
"git-pack-refs --all --prune" whereas testing the file
$git_dir/refs/heads/$opt_o does not.
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch documents the branch.autosetupmerge config option, added
by commit 0746d19a.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Our GITGUI_LIBDIR macro was testing only for @@ at the start of
the path, assuming nobody would ever find that to be a reasonable
prefix for a directory to install our library into. That is most
likely a valid assumption, but its even more unlikely they would
have the start be @@GITGUI_ and the end be @@. Note that we
cannot use the full string here because that would get expanded
by the sed replacement in our Makefile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When the per-method enable logic disables the access, we should
not even look at the global one.
git-cvsserver.perl | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-add reads this variable, and honours the contents of that file if that
exists. Match this behaviour in git-status, too.
Noticed by Evan Carroll on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We do not appreciate C99 initializers, declarations after statements,
or "0" instead of "NULL".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Note: since the consequence of failure is to call die,
I don't bother to close "f".
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
[sp: Modified Jonas' original patch to keep checkout-index
as a a valid completion.]
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint-1.5.1:
annotate: make it work from subdirectories.
git-config: Correct asciidoc documentation for --int/--bool
t1300: Add tests for git-config --bool --get
unpack-trees.c: verify_uptodate: remove dead code
Use PATH_MAX instead of TEMPFILE_PATH_LEN
branch: fix segfault when resolving an invalid HEAD
The asciidoc documentation seemed to indicate that type specifiers
are honoured on writing operations which they aren't. Make this
more clear.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Noticed that there were only tests for --int, but not
for --bool. Add some.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Caused by return value of resolve_ref being passed directly
to xstrdup whereby the sanity checking was never reached.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I didn't have a chance to test the off-by-default minimize-url
stuff enough before, but it's quite broken for people passing
the --trunk/-T, --tags/-t, --branches/-b switches to "init" or
"clone" commands.
Additionally, follow-parent functionality seems broken when we're
not connected to the root of the repository.
Default behavior for "traditional" git-svn users who only track
one directory (without needing follow-parent) should be
reasonable, as those users started using things before
minimize-url functionality existed.
Behavior for users more used to the git-svnimport-like command
line will also benefit from a more-flexible command-line than
svnimport given the assumption they're working with
non-restrictive read permissions on the repository.
I hope to properly fix these bugs when I get a chance to in the
next week or so, but I would like to get this stopgap measure of
reverting to the old behavior as soon as possible.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When sorting directory names by depth (slash ("/") count) and
closing the deepest directories first (as the protocol
requires), we failed to put the root baton (with an empty string
as its key "") after top-level directories (which did not have
any slashes).
This resulted in svnserve being in a situation it couldn't
handle and caused a segmentation fault on the remote server.
This bug did not affect users of DAV and filesystem repositories.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Confirmed-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The todo list at the end of the user manual says that something must be
said about .gitignore. Also, there seems to be a lack of documentation
on how to choose between the various types of ignore files (.gitignore
vs. .git/info/exclude, etc.).
This patch adds a section on ignoring files which try to introduce how
to tell git about ignored files, and how the different strategies
complement eachother.
The syntax of exclude patterns is explained in a simplified manner, with
a reference to git-ls-files(1) which already contains a more thorough
explanation.
Signed-off-by: Johan Herland <johan@herland.net>
Another amusing git exploration example brought up in irc. (Credit to
aeruder for the complete solution.)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I don't really want to look like we're encouraging the shared repository
thing. Take down some of the argument for using purely
single-developer-owned repositories and collaborating using patches and
pulls instead.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The embarassing history of this tutorial is that I started it without
really understanding the index well, so I avoided mentioning it.
And we all got the idea that "index" was a word to avoid using around
newbies, but it was reluctantly mentioned that *something* had to be
said. The result is a little awkward: the discussion of the index never
actually uses that word, and isn't well-integrated into the surrounding
material.
Let's just go ahead and use the word "index" from the very start, and
try to demonstrate its use with a minimum of lecturing.
Also, remove discussion of using git-commit with explicit filenames.
We're already a bit slow here to get people to their first commit, and
I'm not convinced this is really so important.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Mention the user manual, especially as an alternative introduction for
user's mainly interested in read-only operations.
And fix a typo while we're there.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Initial (root) commit has no parents, and $co{'parent'} is
undefined. Use '--root' for initial commit.
This fixes "Use of uninitialized value in open at gitweb/gitweb.perl
line 4925." warning.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'maint' of git://linux-nfs.org/~bfields/git:
user-manual: reorganize public git repo discussion
user-manual: listing commits reachable from some refs not others
user-manual: introduce git
user-manual: add a "counting commits" example
user-manual: move howto/using-topic-branches into manual
user-manual: move howto/make-dist.txt into user manual
Documentation: remove howto's now incorporated into manual
user-manual: move quick-start to an appendix
glossary: expand and clarify some definitions, prune cross-references
user-manual: revise birdseye-view chapter
Add a birdview-on-the-source-code section to the user manual
Sorry, this was inadverently introduced by my grep search patch. It causes
annoying "redefined" warnings.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-rev-list(1) talks about patterns as values for the
--grep, --committed etc. parameters, without going into detail.
This patch mentions that these patterns are actually regexps.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitattributes.txt says, of the crlf attribute:
Set::
Setting the `crlf` attribute on a path is meant to mark
the path as a "text" file. 'core.autocrlf' conversion
takes place without guessing the content type by
inspection.
That is to say that the crlf attribute does not force the file to have
CRLF line endings, instead it removes the autocrlf guesswork and forces
the file to be treated as text. Then, whatever line ending is defined
by the autocrlf setting is applied.
However, that is not what convert.c was doing. The conversion to CRLF
was being skipped in crlf_to_worktree() when the following condition was
true:
action == CRLF_GUESS && auto_crlf <= 0
That is to say conversion took place when not in guess mode (crlf attribute
not specified) or core.autocrlf set to true. This was wrong. It meant
that the crlf attribute being on for a given file _forced_ CRLF
conversion, when actually it should force the file to be treated as
text, and converted accordingly. The real test should simply be
auto_crlf <= 0
That is to say, if core.autocrlf is falsei (or input), conversion from
LF to CRLF is never done. When core.autocrlf is true, conversion from
LF to CRLF is done only when in CRLF_GUESS (and the guess is "text"), or
CRLF_TEXT mode.
Similarly for crlf_to_worktree(), if core.autocrlf is false, no conversion
should _ever_ take place. In reality it was only not taking place if
core.autocrlf was false _and_ the crlf attribute was unspecified.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As noted by Johan Herland, git-archive is a kind of checkout and needs
to apply any checkout filters that might be configured.
This patch adds the convenience function convert_sha1_file which returns
a buffer containing the object's contents, after converting, if necessary
(i.e. it's a combination of read_sha1_file and convert_to_working_tree).
Direct calls to read_sha1_file in git-archive are then replaced by calls
to convert_sha1_file.
Since convert_sha1_file expects its path argument to be NUL-terminated --
a convention it inherits from convert_to_working_tree -- the patch also
changes the path handling in archive-tar.c to always NUL-terminate the
string. It used to solely rely on the len field of struct strbuf before.
archive-zip.c already NUL-terminates the path and thus needs no such
change.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Helping a couple people set up public repos recently, I wanted to point
them at this piece of the user manual, but found it wasn't as helpful as
it could be:
- It starts with a big explanation of why you'd want a public
repository, not necessary in their case since they already knew
why they wanted that. So, separate that out.
- It skimps on some of the git-daemon details, and puts the http
export information first. Fix that.
Also group all the public repo subsections into a single section, and do
some miscellaneous related editing.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Move howto/using-topic-branches into the user manual as an example for
the "sharing development" chapter. While we're at it, remove some
discussion that's covered in earlier chapters, modernize somewhat (use
separate-heads setup, remotes, replace "whatchanged" by "log", etc.),
and replace syntax we'd need to explain by syntax we've already covered
(e.g. old..new instead of new ^old).
The result may not really describe what Tony Luck does any more.... Hope
that's not annoying.
Cc: Tony Luck <tony.luck@intel.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
There seems to be a perception that the howto's are bit-rotting a
little. The manual might be a more visible location for some of them,
and make-dist.txt seems like a good candidate to include as an example
in the manual.
For now, incorporate much of it verbatim. Later we may want to update
the example a bit.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
These two howto's have both been copied into the manual. I'd rather not
maintain both versions if possible, and I think the user-manual will be
more visible than the howto directory. (Though I wouldn't mind some
duplication if people really like having them here.)
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The quick start interrupts the flow of the manual a bit. Move it to
"appendix A" but add a reference to it in the preface. Also rename the
todo chapter to "appendix B", and revise the preface a little.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Revise and expand some of the definitions in the glossary, based in part
on a recent thread started by a user looking for help with some of the
jargon. I've borrowed some of the language from Linus's email on that
thread. (I'm assuming standing permission to plagiarize Linus's
email....)
Also start making a few changes to mitigate the appearance of
"circularity" mentioned in that thread:
- feel free to use somewhat longer definitions and to explain
some things more than once instead of relying purely on
cross-references
- don't use cross-references when they're redundant: eliminate
self-references and repeated references to the same entry.
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Some revisions suggested by Junio along with some minor style fixes and
one compile fix (asterisks need escaping).
Cc: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Currently, there are rather draconian restrictions on the strings accepted
by the pickaxe search, which degrades its usefulness for digging in code
significantly. This patch remedies mentioned limitation.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'grep' type of search greps the currently selected tree for given
regexp and shows the results in a fancy table with links into blob view.
The number of shown matches is limited to 1000 and the whole feature
can be turned off (grepping linux-2.6.git already makes repo.or.cz a bit
unhappy).
This second revision makes it in documentation explicit that grep accepts
regexps, and makes grep accept extended regexps instead of basic regexps.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, searchbar font was as big as the page heading font, because
font-size was made relative - but to the parent element, which was for some
reason indeed page_header. Since that seems to be illogical to me, I just
moved the div.search outside of div.page_header. I'm no CSS/DOM expert but
no adverse effects were observed by me.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
During the discussion of core.excludesfile in the user-manual, I realized
that the configuration wasn't mentioned in the man pages.
Signed-off-by: Michael Hendricks <michael@ndrix.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Checking if $diffinfo->{'status'} is equal 'D' is no longer the way to
check if the file was deleted in result. For merge commits
$diffinfo->{'status'} is reference to array of statuses for each
parent. Use the fact that $diffinfo->{'to_id'} is all zeros as sign
that file was deleted in result.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Petr Baudis pointed out the main git.git repository's Makefile dies
now if git-gui 0.7.0-rc1 or later is being used and TCL_PATH was not
set to a working tclsh program path. This breaks people who may have
a working build configuration today and suddenly upgrade to the latest
git release.
The tclIndex is required for git-gui to load its associated lib files,
but using the Tcl auto_load procedure to source only the files we need
is a performance optimization. We can emulate the auto_load by just
source'ing every file in that directory, assuming we source class.tcl
first to initialize our crude class system.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
mutt version 1.5.14 (perhaps earlier versions too) permits alias files to have
white space before the 'alias' keyword.
Signed-off-by: Michael Hendricks <michael@ndrix.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In http://thread.gmane.org/gmane.comp.version-control.git/42479,
a birdview on the source code was requested.
J. Bruce Fields suggested that my reply should be included in the
user manual, and there was nothing of an outcry, so here it is,
not 2 months later.
It includes modifications as suggested by J. Bruce Fields, Karl
Hasselström and Daniel Barkalow.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Earlier commit 4280cde95f made gitweb
show "No differences found" message for empty diff, for the HTML
output. But for merge commits, either -c format we use or --cc format,
empty diff doesn't mean no differences, but trivial merge.
Show "Trivial merge" message instead of "No differences found" for
merges.
While at it reword conditional in the code for easier reading.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
format-patch: add MIME-Version header when we add content-type.
Fixed link in user-manual
import-tars: Use the "Link indicator" to identify directories
git name-rev writes beyond the end of malloc() with large generations
Documentation/branch: fix small typo in -D example
Separate search text, which is saved in $searchtext global variable,
and is used in links, as default value for the textfield in search
form, and for pickaxe search, from search regexp, which is saved in
$search_regexp global variable, and is used as parameter to --grep,
--committer or --author options to git-rev-list, and for searching
commit body in gitweb. For now $search_regexp is unconditionallt
equal to quotemeta($searchtext), meaning that we always search for
fixed string.
This fixes bug where 'next page' links for 'search' view didn't work
for searchtext containing quotable characters, like `@'.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
David Kågedal proposed that gitweb should explicitely request
being somewhat smaller than normal, because it has good use for
long lines. However gitweb presents a table with several
columns, so having wider line is OK for it. Therefore explicit
'font-size: small' would make sense. Apparently many people on
the list seem to agree with him.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, we used the mode to determine if a name was associated with
a directory. This fails, since some tar programs do not set the mode
correctly. However, the link indicator _has_ to be set correctly.
Noticed by Chris Riddoch.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Acked-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch fixes all calls to xread() where the return value is not
stored into an ssize_t. The patch should not have any effect whatsoever,
other than putting better/more appropriate type names on variables.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The return value from xread() is ssize_t.
Paolo Teti <paolo.teti@gmail.com> pointed out that in this case, the
signed return value was assigned to an unsigned type (size_t). This patch
fixes that.
Signed-off-by: Johan Herland <johan@herland.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When using git name-rev on my kernel tree I triggered a malloc()
corruption warning from glibc.
apw@pinky$ git log --pretty=one $N/base.. | git name-rev --stdin
*** glibc detected *** malloc(): memory corruption: 0x0bff8950 ***
Aborted
This comes from name_rev() which is building the name of the revision
in a malloc'd string, which it sprintf's into:
char *new_name = xmalloc(len + 8);
[...]
sprintf(new_name, "%.*s~%d^%d", len, tip_name,
generation, parent_number);
This allocation is only sufficient if the generation number is
less than 5 digits, in my case generation was 13432. In reality
parent_number can be up to 16 so that also can require two digits,
reducing us to 3 digits before we are at risk of blowing this
allocation.
This patch introduces a decimal_length() which approximates the
number of digits a type may hold, it produces the following:
Type Longest Value Len Est
---- ------------- --- ---
unsigned char 256 3 4
unsigned short 65536 5 6
unsigned long 4294967296 10 11
unsigned long long 18446744073709551616 20 21
char -128 4 4
short -32768 6 6
long -2147483648 11 11
long long -9223372036854775808 20 21
This is then used to size the new_name.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Runtime is now independent of the number of modified files.
The old implementation executed 'cvs status' for each file touched by the patch
to be applied. The new code calls 'cvs status' only once with all touched files
and parses cvs's output to collect all available status information.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$Id$ is present already in SVN and CVS; it would mean that people
converting their existing repositories won't have to make any changes to
the source files should they want to make use of the ident attribute.
Given that it's a feature that's meant to calm those very people, it
seems obtuse to make them edit every file just to make use of it.
I think that bzr uses $Id$; Mercurial has examples hooks for $Id$;
monotone has $Id$ on its wishlist. I can't think of a good reason not
to stick with the de-facto standard and call ours $Id$ instead of
$ident$.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Prepare for 1.5.1.5 Release Notes
gitweb: Add a few comments about %feature hash
git-am: Clean up the asciidoc documentation
Documentation: format-patch has no --mbox option
builtin-log.c: Fix typo in comment
Fix git-clone buglet for remote case.
Hopefully we will have 1.5.2 soonish, to contain all of these,
but we should summarize what we have done regardless.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add --keep to synopsis.
The synopsys used a mix of tabs and spaces, unify to use only
spaces.
Shuffle options around in synopsys and description for grouping
them logically.
Add more gitlink references to other commands.
Various grammatical fixes and improvements.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-applymbox and git-mailinfo refer to a --mbox option of
git-format-patch when talking about their -k options. But there
is no such option. What -k does to the former two commands is
to keep the Subject: lines unmunged, meant to be used on output
generated with format-patch -k.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
c2f599e09f introduced a buglet while
cloning from a remote URL; we forgot to squelch the unnecessary
error message when we try to cd to the given "remote" name,
in order to see if it is a local directory.
Signed-off-by: Junio C Hamano <junkio@cox.net>
After we send I HATE YOU we should probably exit and not happily
continue with I LOVE YOU and further communication.
Most clients will probably just exit and ignore everything we
send after the I HATE YOU and it is not a security problem
either because we don't really care about the user name anyway.
But it is still the right thing to do.
[jc: with a minor fixup to its exit code...]
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: "Martin Langhoff" <martin.langhoff@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Split description of pretty formats into list of pretty options
(--pretty and --encoding) in new file Documentation/pretty-options.txt
and description of formats itself as a separate "PRETTY FORMATS"
section in pretty-formats.txt
While at it correct formatting a bit, to be better laid out in the
resulting manpages: git-rev-list(1), git-show(1), git-log(1) and
git-diff-tree(1). Those manpages now include pretty options in the
same place as it was before, and description of formats just after
all options.
Inspired by the split into two filesdocumentation for merge strategies:
Documentation/merge-options.txt and Documentation/merge-strategies.txt
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix it so gitweb doesn't write "Use of unitialized value..." warnings
(which gets written in web server logs) for empty (no commits)
repository.
In empty repository "last change" (last activity) doesn't make sense;
also there is no sense in parsing commits which aren't there.
In projects list for empty repositories gitweb now writes "No commits"
using "noage" class, instead of leaving cell empty, in the last change
column.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-svn: don't attempt to minimize URLs by default
git-svn: fix segfaults due to initial SVN pool being cleared
git-svn: clean up caching of SVN::Ra functions
git-svn: don't drop the username from URLs when dcommit is run
RPM spec: include files in technical/ to package.
Remove stale non-static-inline prototype for tree_entry_extract()
git-config: test for 'do not forget "a.b.var" ends "a.var" section'.
git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.
Change the configuration parser so that it ignores
everything except for ^gitcvs.((ext|pserver).)?
This greatly reduces the risk of failing while
parsing some unknown and irrelevant config option.
The bug that triggered this change was that the
parsing doesn't handle sections that have a
subsection and a variable with the same name.
While this bug still remains, all remaining
causes can be attributed to user error, since
there are no defined variables gitcvs.ext and
gitcvs.pserver.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Try to avoid "Use of uninitialized value ..." errors caused by bad
revision, incorrect filename, wrong object id, bad file etc. (wrong
value of 'h', 'hb', 'f', etc. parameters). This avoids polluting web
server errors log.
Correct git_get_hash_by_path and parse_commit_text (and, in turn,
parse_commit) to return undef if object does not exist. Check in
git_tag if requested tag exists.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently
$ git grep '\([^t]\|^\)'link: user-manual.txt
gives four hits that refer to .txt version of the documentation
set, but at least "hooks" and "cvs-migration" have HTML variants
installed, so refer to them instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
For tracking branches and tags, git-svn prefers to connect
to the root of the repository or at least the level that
houses branches and tags as well as trunk. However, users
that are accustomed to tracking a single directory have
no use for this feature.
As pointed out by Junio, users may not have permissions to
connect to connect to a higher-level path in the repository.
While the current minimize_url() function detects lack of
permissions to certain paths _after_ successful logins, it
cannot effectively determine if it is trying to access a
login-only portion of a repo when the user expects to
connect to a part where anonymous access is allowed.
For people used to the git-svnimport switches of
--trunk, --tags, --branches, they'll already pass the
repository root (or root+subdirectory), so minimize URL
isn't of too much use to them, either.
For people *not* used to git-svnimport, git-svn also
supports:
git svn init --minimize-url \
--trunk http://repository-root/foo/trunk \
--branches http://repository-root/foo/branches \
--tags http://repository-root/foo/tags
And this is where the new --minimize-url command-line switch
comes in to allow for this behavior to continue working.
Some parts of SVN always seem to use it, even if the SVN::Ra
object we're using is no longer used and we've created a new one
in its place. It's also true that only one SVN::Ra connection
can exist at once... Using SVN::Pool->new_default when the
SVN::Ra object is created doesn't seem to help very much,
either...
Hopefully this fixes all segfault problems users have been
experiencing over the past few months.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
This patch was originally intended to make the Perl GC more
sensitive to the SVN::Pool objects and not accidentally clean
them up when they shouldn't be (causing segfaults). That didn't
work, but this patch makes the code a bit cleaner regardless
Put our caches for get_dir and check_path calls directly into
the SVN::Ra object so they auto-expire when it is destroyed.
dirents returned by get_dir() no longer needs the pool object
stored persistently along with the cache data, as they'll be
converted to native Perl hash references.
Since calling rev_proplist repeatedly per-revision is no longer
needed in git-svn, we do not cache calls to it.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
We no longer store usernames in URLs stored in git-svn-id lines
for dcommit, so we shouldn't rely on those URLs when connecting
to the remote repository to commit.
Not only that they are interesting to users, some of the
files are linked to by the included "Git User's Manual"
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When 4651ece8 made the function a "static inline", it should
have removd the stale prototype but everybody missed that.
Thomas Glanzmann noticed this broke compilation with Forte12
compiler on his Sun boxes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier code tried to be half-careful and knew the logic that
seeing "a.var" after seeing "a.b.var" is a sign of the previous
"a.b." section has ended, but forgot it has to handle the other
way. Seeing "a.b.var" after seeing "a.var" is a sign that "a."
section has ended, so a new "a.var2" variable should be added
before the location "a.b.var" appears.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Small additional changes to the cbb84e5d17
commit, which introduced documentation to pre-receive and post-receive:
- Mention that stdout and stderr are equivalent.
- Add one cross-section link and fix one other.
- Fix information on advantages of post-receive over post-update.
Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
checkout: allow detaching to HEAD even when switching to the tip of a branch
Updated documentation of hooks in git-receive-pack.
Allow fetching references from any namespace
tiny fix in documentation of git-clone
Fix an unmatched comment end in arm/sha1_arm.S
You cannot currently checkout the tip of an existing branch
without moving to the branch.
This allows you to detach your HEAD and place it at such a
commit, with:
$ git checkout master^0
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added documentation of pre-receive and post-receive hooks and updated
documentation of update and post-update hooks.
[jc: with minor copy-editing]
Signed-off-by: Jan Hudec <bulb@ucw.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver has a bug in its configuration file output parser
that makes it choke if the configuration has these:
[diff]
color = auto
[diff.color]
whitespace = blue reverse
This needs to be fixed, but thanks to that bug, a separate bug
in t9400 test script was discovered. The test discarded
GIT_CONFIG instead of pointing at the proper one to be used in
the exoprted repository. This allowed user's .gitconfig and (if
exists) systemwide /etc/gitconfig to affect the outcome of the
test, which is a big no-no.
The patch fixes the problem in the test. Fixing the
git-cvsserver's configuration parser is left as an exercise to
motivated volunteers ;-)
Signed-off-by: Junio C Hamano <junkio@cox.net>
not only from the three defined: heads, tags and remotes.
Noticed when I tried to fetch the references created by git-p4-import.bat:
they are placed into separate namespace (refs/p4import/, to avoid showing
them in git-branch output). As canon_refs_list_for_fetch always prepended
refs/heads/ it was impossible, and annoying: it worked before. Normally,
the p4import references are useless anywhere but in the directory managed
by perforce, but in this special case the cloned directory was supposed
to be a backup, including the p4import branch: it keeps information about
where the imported perforce state came from.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Both archive-tar and archive-zip needed to be taught about subprojects.
The tar function died when trying to read the subproject commit object,
while the zip function reported "unsupported file mode".
This fixes both by representing the subproject as an empty directory.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Get rid of "Use of uninitialized value in string eq at
gitweb/gitweb.perl line 2320" warning caused by the fact that "empty"
patches, consisting only of extended git diff header and with patch
body empty, such as patch for pure rename, does not have "index" line
in extended diff header. For such patches $from_id and $to_id, filled
from parsing extended diff header, are undefined. But such patches
cannot be continuation patches.
Test if $from_id and $to_id are defined before comparing them with
$diffinfo.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than updating all working tree paths, we limit
ourselves to paths listed on the command line.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching from a branch with both x86_64/boot/Makefile and
i386/boot/Makefile to another branch that has x86_64/boot as a
symlink pointing at ../i386/boot, the code incorrectly removed
i386/boot/Makefile.
This was because we first removed everything under x86_64/boot
to make room to create a symbolic link x86_64/boot, then removed
x86_64/boot/Makefile which no longer exists but now is pointing
at i386/boot/Makefile, thanks to the symlink we just created.
This fixes it by using the has_symlink_leading_path() function
introduced previously for git-apply in the checkout codepath.
Earlier, "git checkout" was broken in t4122 test due to this
bug, and the test had an extra "git reset --hard" as a
workaround, which is removed because it is not needed anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
HPA noticed that git-rebase fails when changes involve symlinks
in the middle of the hierarchy. Consider:
* The tree state before the patch is applied has arch/x86_64/boot
as a symlink pointing at ../i386/boot/
* The patch tries to remove arch/x86_64/boot symlink, and
create bunch of files there: .gitignore, Makefile, etc.
git-apply tries to be careful while applying patches; it never
touches the working tree until it is convinced that the patch
would apply cleanly. One of the check it does is that when it
knows a path is going to be created by the patch, it runs
lstat() on the path to make sure it does not exist.
This leads to a false alarm. Because we do not touch the
working tree before all the check passes, when we try to make
sure that arch/x86_64/boot/.gitignore does not exist yet, we
haven't removed the arch/x86_64/boot symlink. The lstat() check
ends up seeing arch/i386/boot/.gitignore through the
yet-to-be-removed symlink, and says "Hey, you already have a
file there, but what you fed me is a patch to create a new
file. I am not going to clobber what you have in the working
tree."
We have similar checks to see a file we are going to modify does
exist and match the preimage of the diff, which is done by
directly opening and reading the file.
For a file we are going to delete, we make sure that it does
exist and matches what is going to be removed (a removal patch
records the full preimage, so we check what you have in your
working tree matches it in full -- otherwise we would risk
losing your local changes), which again is done by directly
opening and reading the file.
These checks need to be adjusted so that they are not fooled by
symlinks in the middle.
- To make sure something does not exist, first lstat(). If it
does not exist, it does not, so be happy. If it _does_, we
might be getting fooled by a symlink in the middle, so break
leading paths and see if there are symlinks involved. When
we are checking for a path a/b/c/d, if any of a, a/b, a/b/c
is a symlink, then a/b/c/d does _NOT_ exist, for the purpose
of our test.
This would fix this particular case you saw, and would not
add extra overhead in the usual case.
- To make sure something already exists, first lstat(). If it
does not exist, barf (up to this, we already do). Even if it
does seem to exist, we might be getting fooled by a symlink
in the middle, so make sure leading paths are not symlinks.
This would make the normal codepath much more expensive for
deep trees, which is a bit worrisome.
This patch implements the first side of the check "making sure
it does not exist". The latter "making sure it exists" check is
not done yet, so applying the patch in reverse would still
fail, but we have to start from somewhere.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we are applying a patch that creates a blob at a path, or
when we are switching from a branch that does not have a blob at
the path to another branch that has one, we need to make sure
that there is nothing at the path in the working tree, as such a
file is a local modification made by the user that would be lost
by the operation.
Normally, lstat() on the path and making sure ENOENT is returned
is good enough for that purpose. However there is a twist. We
may be creating a regular file arch/x86_64/boot/Makefile, while
removing an existing symbolic link at arch/x86_64/boot that
points at existing ../i386/boot directory that has Makefile in
it. We always first check without touching filesystem and then
perform the actual operation, so when we verify the new file,
arch/x86_64/boot/Makefile, does not exist, we haven't removed
the symbolic link arc/x86_64/boot symbolic link yet. lstat() on
the file sees through the symbolic link and reports the file is
there, which is not what we want.
The function has_symlink_leading_path() function takes a path,
and sees if any of the leading directory component is a symbolic
link.
When files in a new directory are created, we tend to process
them together because both index and tree are sorted. The
function takes advantage of this and allows the caller to cache
and reuse which symbolic link on the filesystem caused the
function to return true.
The calling sequence would be:
char last_symlink[PATH_MAX];
*last_symlink = '\0';
for each index entry {
if (!lose)
continue;
if (lstat(it))
if (errno == ENOENT)
; /* happy */
else
error;
else if (has_symlink_leading_path(it, last_symlink))
; /* happy */
else
error; /* would lose local changes */
unlink_entry(it, last_symlink);
}
Signed-off-by: Junio C Hamano <junkio@cox.net>
We now write to MERGE_MSG, not .msg. I missed this earlier
when I changed the target we write to.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git-gui:
git gui 0.7.0
git-gui: Paperbag fix blame in subdirectory
git-gui: Format author/committer times in ISO format
git-gui: Cleanup minor nits in blame code
git-gui: Generate blame on uncommitted working tree file
git-gui: Smarter command line parsing for browser, blame
git-gui: Use prefix if blame is run in a subdirectory
git-gui: Convert blame to the "class" way of doing things
git-gui: Don't attempt to inline array reads in methods
git-gui: Convert browser, console to "class" format
git-gui: Define a simple class/method system
git-gui: Allow shift-{k,j} to select a range of branches to merge
git-gui: Call changes "Staged" and "Unstaged" in file list titles.
Avoid specifying font sizes in pixels, since that is just pure evil.
Pointed out by Chris Riddoch.
Note that this is pretty much just a proposal; I didn't test if everything
fits perfectly right, but things seem to be pretty much okay. repo.or.cz
uses it now as a test drive - if you find any visual quirks, please point
them out, with a patch if possible since I'm total CSS noob and debugging
CSS is an extremely painful experience for me.
Note that this patch actually does change visual look of gitweb in Firefox
with my resolution and default settings - everything is bigger and I can't
explain the joy of actually seeing gitweb text that is in _readable_ size;
also, my horizontal screen real estate feels better used now. But judging
from the look of most modern webpages on the 'net, most people prefer
reading the web with strained eyes and/or a magnifying glass (I wonder what
species of scientists should look into this mystifying phenomenon) - so,
please tell us what you think.
Maybe we might want to get rid of absolute sizes other than font sizes in
the CSS file too in the long term.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch renames config_boolean() to config_bool() for consistency with
the commandline interface and because it is shorter but still obvious. ;-)
It also changes the return value from some obscure string to real Perl
boolean, allowing for clean user code.
Signed-off-by: Petr Baudis <pasky@suse.cz>
* maint:
.mailmap: add some aliases
SPECIFYING RANGES typo fix: it it => it is
git-clone: don't get fooled by $PWD
Fix documentation of tag in git-fast-import.txt
If you have /home/me/git symlink pointing at /pub/git/mine,
trying to clone from /pub/git/his/ using relative path would not
work as expected:
$ cd /home/me
$ cd git
$ ls ../
his mine
$ git clone -l -s -n ../his/stuff.git
This is because "cd ../his/stuff.git" done inside git-clone to
check if the repository is local is confused by $PWD, which is
set to /home/me, and tries to go to /home/his/stuff.git which is
different from /pub/git/his/stuff.git.
We could probably say "set -P" (or "cd -P") instead, if we know
the shell is POSIX, but the way the patch is coded is probably
more portable.
[jc: this is updated with Andy Whitcroft's improvements]
Signed-off-by: Junio C Hamano <junkio@cox.net>
gitweb URLs use the a= parameter for the view to use on the given path, such
as "blob" or "tree". Currently, if a gitweb URL omits the a= parameter,
gitweb just shows the top-level repository summary, regardless of the path
given. gitweb could instead choose an appropriate view based on the file
type: blob for blobs (files), tree for trees (directories), and summary if
no path given (the URL included no f= parameter, or an empty f= parameter).
Apart from making gitweb more robust and supporting URL editing more easily,
this change would aid the creation of shortcuts to git repositories using
simple substitution, such as:
http://example.org/git/?p=path/to/repo.git;hb=HEAD;f=%s
With this patch, if given the hash through the h= parameter, or the hash
base (hb=) and a filename (f=), gitweb uses cat-file -t to automatically set
the a= parameter.
This feature was requested by Josh Triplett through
http://bugs.debian.org/410465
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/diffopt:
diff -S: release the image after looking for needle in it
diff -M: release the preimage candidate blobs after rename detection.
diff.c: do not use a separate "size cache".
diff: release blobs after generating textual diff.
* jn/gitweb:
gitweb: Show combined diff for merge commits in 'commit' view
gitweb: Show combined diff for merge commits in 'commitdiff' view
gitweb: Make it possible to use pre-parsed info in git_difftree_body
gitweb: Add combined diff support to git_patchset_body
gitweb: Add combined diff support to git_difftree_body
gitweb: Add parsing of raw combined diff format to parse_difftree_raw_line
Use the :fork: access method to force cvs to
call "$CVS_SERVER server" even when accessing a local
repository.
Add a basic test for checkout and some tests for update.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than storing the temporary commit message data in .msg (in
the working tree) we now store the message data in .git/MERGE_MSG.
By storing the message in the .git/ directory we are sure we will
never have a collision with a user file, should a project actually
have a ".msg" file in their top level tree. We also don't need to
worry about leaving this stale file behind during a `reset --hard`
and have it show up in the output of status.
We are using .git/MERGE_MSG here to store the temporary message as
it is an already established convention between git-merge, git-am
and git-rebase that git-commit will default the user's edit buffer
to the contents of .git/MERGE_MSG. If the user is going to need
to resolve this commit or wants to edit the message on their own
prepping that file with the desired message "just works".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
RPM packages did not include howto files which causes broken
links in howto-index.html
Signed-off-by: Quy Tonthat <qtonthat@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a simple change to match what gitk does when it shows
a commit; we format using ISO dates (yyyy-mm-dd HH:MM:SS).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We can use [list ...] rather than "", especially when we are talking
about values as then they are properly escaped if necessary. Small
nit, but probably not a huge deal as the only data being inlined here
is Tk paths.
Some of the lines in the parser code were longer than 80 characters
wide, and they actually were all the same value on the end part of
the line. Rather than keeping the mess copied-and-pasted around we
can set the last argument into a local variable and reuse it many
times.
The commit display code was also rather difficult to read on an 80
character wide terminal, so I'm moving it all into a double quoted
string that is easier to read.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the user doesn't give us a revision parameter to our blame
subcommand then we can generate blame against the working tree
file by passing the file path off to blame with the --contents
argument. In this case we cannot obtain the contents of the
file from the ODB; instead we must obtain the contents by
reading the working directory file as-is.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The browser subcommand now optionally accepts a single revision
argument; if no revision argument is supplied then we use the
current branch as the tree to browse. This is very common, so
its a nice option.
Our blame subcommand now tries to perform the same assumptions
as the command line git-blame; both the revision and the file
are optional. We assume the argument is a filename if the file
exists in the working directory, otherwise we assume the argument
is a revision name. A -- can be supplied between the two to force
parsing, or before the filename to force it to be a filename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I think it was Andy Parkins who pointed out that git gui blame HEAD f
does not work if f is in a subdirectory and we are currently running
git-gui within that subdirectory. This is happening because we did
not take the user's prefix into account when we computed the file
path in the repository.
We now assume the prefix as returned by rev-parse --show-prefix is
valid and we use that during the command line blame subcommand when
we apply the parameters.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Our blame viewer code has historically been a mess simply
because the data for multiple viewers was all crammed into
a single pair of Tcl arrays. This made the code hard to
read and even harder to maintain.
Now that we have a slightly better way of tracking the data
for our "meta-widgets" we can make use of it here in the
blame viewer to cleanup the code and make it easier to work
with long term.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If a variable reference to a field is to an array, and it is
the only reference to that field in that method we cannot make
it an inlined [set foo] call as the regexp was converting the
Tcl code wrong. We were producing "[set foo](x)" for "$foo(x)",
and that isn't valid Tcl when foo is an array. So we just punt
if the only occurance has a ( after it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that we have a slightly easier method of working with per-widget
data we should make use of that technique in our browser and console
meta-widgets, as both have a decent amount of information that they
store on a per-widget basis and our current approach of handling
it is difficult to follow.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As most of the git-gui interface is based upon "meta-widgets"
that need to carry around a good deal of state (e.g. console
windows, browser windows, blame viewer) we have a good deal
of messy code that tries to store this meta-widget state in
global arrays, where keys into the array are formed from a
union of a unique "object instance id" and the field name.
This is a simple class system for Tcl that allows us to
hide much of that mess by making Tcl do what it does best;
process strings to manipulate its own code during startup.
Each object instance is placed into its own namespace. The
namespace is created when the object instance is created and
the namespace is destroyed when the object instance is removed
from the system. Within that namespace we place variables for
each field within the class; these variables can themselves be
scalar values or full-blown Tcl arrays.
A simple class might be defined as:
class map {
field data
field size 0
constructor {} {
return $this
}
method set {name value} {
set data($name) $value
incr size
}
method size {} {
return $size
} ifdeleted { return 0 }
}
All fields must be declared before any constructors or methods. This
allows our class to generate a list of the fields so it can properly
alter the definition of the constructor and method bodies prior to
passing them off to Tcl for definition with proc. A field may optionally
be given a default/initial value. This can only be done for non-array
type fields.
Constructors are given full access to all fields of the class, so they
can initialize the data values. The default values of fields (if any)
are set before the constructor runs, and the implicit local variable
$this is initialized to the instance identifier.
Methods are given access to fields they actually use in their body.
Every method has an implicit "this" argument inserted as its first
parameter; callers of methods must be sure they supply this value.
Some basic optimization tricks are performed (but not much). We
try to only upvar (locally bind) fields that are accessed within a
method, but we err on the side of caution and may upvar more than
we need to. If a variable is accessed only once within a method
and that access is by $foo (read) we avoid the upvar and instead
use [set foo] to obtain the value. This is slightly faster as Tcl
does not need to lookup the variable twice.
We also offer some small syntatic sugar for interacting with Tk and
the fileevent callback system in Tcl. If a field (say "foo") is used
as "@foo" we insert instead the true global variable name of that
variable into the body of the constructor or method. This allows easy
binding to Tk textvariable options, e.g.:
label $w.title -textvariable @title
Proper namespace callbacks can also be setup with the special cb proc
that is defined in each namespace. [cb _foo a] will invoke the method
_foo in the current namespace, passing it $this as the first (implied)
parameter and a as the second parameter. This makes it very simple to
connect an object instance to a -command option for a Tk widget or to
a fileevent readable or writable for a file channel.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I found it useful to be able to use j/k (vi-like keys) to move
up and down the list of branches to merge and shift-j/k to do
the selection, much as shift-up/down (arrow keys) would alter
the selection.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
All menu entries talk about "staging" and "unstaging" changes, but the
titles of the file lists use different wording, which may confuse
newcomers.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Build fails for git 1.5.1.3 on AIX, with the message:
utf8.c:66: error: conflicting types for 'wcwidth'
/.../lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.3/include/string.h:266: error: previous declaration of 'wcwidth' was here
Fix this by renaming our static variant to our own name.
Signed-off-by: Amos Waterland <apw@us.ibm.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
More typo fixes from Santi Béjar, plus a couple other mistakes I noticed
along the way.
Cc: Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We already export these variables earlier in the Makefile, right
after they were 'declared'. There is no point in doing so again.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Use vi-like keys in merge dialog
git-gui: Include commit id/subject in merge choices
git-gui: Show all possible branches for merge
git-gui: Move merge support into a namespace
git-gui: Allow vi keys to scroll the diff/blame regions
git-gui: Move console procs into their own namespace
git-gui: Refactor into multiple files to save my sanity
git-gui: Track our own embedded values and rebuild when they change
git-gui: Refactor to use our git proc more often
git-gui: Use option database defaults to set the font
git-gui: Cleanup common font handling for font_ui
git-gui: Correct line wrapping for too many branch message
git-gui: Warn users before making an octopus merge
git-gui: Include the subject in the status bar after commit
Also perform an evil merge change to update Git's main Makefile to
pass the proper options down into git-gui now that it depends on
reasonable values for 'sharedir' and 'TCL_PATH'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since we support vi-like keys for scrolling in other UI contexts
we can easily do so here too. Tk's handy little `event generate'
makes this a lot easier than I thought it would be. We may want
to go back and fix some of the other vi-like bindings to redirect
to the arrow and pageup/pagedown keys, rather than running the
view changes directly.
I've bound 'v' to visualize, as this is a somewhat common thing
to want to do in the merge dialog. Control (or Command) Return
is also bound to start the merge, much as it is bound in the
main window to activate the commit.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When merging branches using our local merge feature it can be
handy to know the first few digits of the commit the ref points
at as well as the short description of the branch name.
Unfortunately I'm unable to use three listboxes in a row, as Tcl
freaks out and refuses to let me have a selection in more than
one of them at any given point in time. So instead we use a
fixed width font in the existing listbox and organize the data
into three columns. Not nearly as nice looking, but users can
continue to use the listbox's features.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt pointed out that git-gui was randomly selecting
which branch (or tag!) it will show in the merge dialog when
more than one ref points at the same commit. This can be a
problem for the user if they want to merge a branch, but the
ref that git-gui selected to display was actually a tag that
points at the commit at the tip of that branch. Since the
user is looking for the branch, and not the tag, its confusing
to not find it, and worse, merging the tag causes git-merge to
generate a different message than if the branch was selected.
While I am in here and am messing around I have changed the
for-each-ref usage to take advantage of its --tcl formatting,
and to fetch the subject line of the commit (or tag) we are
looking at. This way we could present the subject line in the
UI to the user, given them an even better chance to select
the correct branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like the console procs I have moved the code related to merge
support into their own namespace, so that they are isolated
from the rest of the world.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Users who are used to vi and recent versions of gitk may want
to scroll the diff region using vi style keybindings. Since
these aren't bound to anything else and that widget does not
accept focus for data input, we can easily support that too.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
To help modularize git-gui better I'm isolating the code and
variables required to handle our little console windows into
their own namespace. This way we can say console::new rather
than new_console, and the hidden internal procs to create the
window and read data from our filehandle are off in their own
private little land, where most users don't see them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm finding it difficult to work with a 6,000+ line Tcl script
and not go insane while looking for a particular block of code.
Since most of the program is organized into different units of
functionality and not all users will need all units immediately
on startup we can improve things by splitting procs out into
multiple files and let auto_load handle things for us.
This should help not only to better organize the source, but
it may also improve startup times for some users as the Tcl
parser does not need to read as much script before it can show
the UI. In many cases the user can avoid reading at least half
of git-gui now.
Unfortunately we now need a library directory in our runtime
location. This is currently assumed to be $(sharedir)/git-gui/lib
and its expected that the Makefile invoker will setup some sort of
reasonable sharedir value for us, or let us assume its going to be
$(gitexecdir)/../share.
We now also require a tclsh (in TCL_PATH) to just run the Makefile,
as we use tclsh to generate the tclIndex for our lib directory. I'm
hoping this is not an unncessary burden on end-users who are building
from source.
I haven't really made any functionality changes here, this is just a
huge migration of code from one file to many smaller files. All of
the new changes are to setup the library path and install the library
files.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When commit shown is a merge commit (has more than one parent),
display combined difftree output (result of git-diff-tree -c).
Earlier (since commit 549ab4a307)
difftree output (against first parent) was not printed for merges.
Examples of non-trivial merges:
5bac4a6719 (includes rename)
addafaf92e (five parents)
95f97567c1887d77f3a46b42d8622c76414d964d (evil merge)
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When 'commitdiff' action is requested without 'hp' (hash parent)
parameter, and commit given by 'h' (hash) parameter is merge commit,
show merge as combined diff.
Earlier for merge commits without 'hp' parameter diff to first parent
was shown.
Note that in compact combined (--cc) format 'uninteresting' hunks
omission mechanism can make that there is no patch corresponding to
line in raw format (difftree) output. That is why (at least for now)
we use --combined and not --cc format for showing commitdiff for merge
commits.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make it possible to use pre-parsed, or generated by hand, difftree
info in git_difftree_body, similarly to how was and is it done in
git_patchset_body.
Use just introduced feature in git_commitdiff to parse difftree info
(raw diff output) only once: difftree info is now parsed in
git_commitdiff directly, and parsed information is passed to both
git_difftree_body and git_patchset_body. (Till now only git_blobdiff
made use of git_patchset_body ability to use pre-parsed or hand
generated info.) Additionally this makes rename info for combined diff
with renames (or copies) calculated only once in git_difftree_body;
the $difftree is modified and git_patchset_body makes use of added
info.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Calling convention for combined diff similar to the one for
git_difftree_body subroutine: difftree info (first parameter) must be
result of calling git-diff-tree with -c/--cc option, and all parents
of a commit must be passed as last parameters. See also description in
"gitweb: Add combined diff support to git_difftree_body"
This ability is not used yet.
Generating "src" file name for renames in combined diff was separated
into fill_from_file_info subroutine; git_difftree_body was modified to
use it. Currently git_difftree_body and git_patchset_body fills this
info separately.
The from-file line in two-line from-file/to-file header is not
hyperlinked: there can be more than one "from"/"src" file. This
differs from HTML output of ordinary (not combined) diff.
format_diff_line subroutine needs extra $from/$to parameters to format
combined diff patch line correctly.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
You have to pass all parents as final parameters of git_difftree_body
subroutine; the number of parents of a diff must be equal to the
number derived from parsing git-diff-tree output, raw combined diff
for git_difftree_body to display combined diff correctly (but it is
not checked).
Currently the possibility of displaying diffree of combined diff is
not used in gitweb code; git_difftree_body is always caled for
ordinary diff, and with only one parent.
Description of output for combined diff:
----------------------------------------
The difftree table for combined diff starts with a cell with pathname
of changed blob (changed file), which if possible is hidden link
(class="list") to the 'blob' view of final version (if it exists),
like for difftree for ordinary diff. If file was deleted in the final
commit then filename is not hyperlinked.
There is no cell with single file status (new, deleted, mode change,
rename), as for combined diff as there is no single status: different
parents might have different status.
If git_difftree_body was called from git_commitdiff (for 'commitdiff'
action) there is inner link to anchor to appropriate fragment (patch)
in patchset body; the "patch" link does not replace "diff" link like
for ordinary diff.
Each of "diff" links is in separate cell, contrary to output for
ordinary diff in which all links are (at least for now) in a single
cell.
For each parent, if file was not present we leave cell empty. If file
was deleted in the result, we provide link to 'blob' view. Otherwise
we provide link to 'commitdiff' view, even if patch (diff) consist
only of extended diff header, and contents is not changed (pure
rename, pure mode change). The only difference is that link to
"blobdiff" view with no contents change is with 'nochange' class.
At last, there is provided link to current version of file as "blob"
link, if the file was not deleted in the result, and lik to history of
a file, if there exists one. (The link to file history might be
confused, at least for now, by renames.)
Note that git-diff-tree raw output dor combined diff does not provide
filename before change for renames and copies; we use
git_get_path_by_hash to get "src" filename for renames (this means
additional call to git-ls-tree for a _whole_ tree).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add parsing line of raw combined diff ("git diff-tree -c/-cc" output)
as described in section "diff format for merges" in diff-format.txt
to parse_difftree_raw_line subroutine.
Returned hash (or hashref) has for combined diff 'nparents' key which
holds number of parents in a merge. At keys 'from_mode' and 'from_id'
there are arrayrefs holding modes and ids, respectively. There is no
'similarity' value, and there is only 'to_file' value and no
'from_file' value.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Randal L. Schwartz pointed out multiple times that we should be
testing the length of the name string here, not if it is "true".
The problem is the string '0' is actually false in Perl when we
try to evaluate it in this context, as '0' is 0 numerically and
the number 0 is treated as a false value. This would cause us
to break out of the import loop early if anyone had a file or
directory named "0".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We released the postimage candidate blobs after we are done to reduce
memory pressure. Do the same for preimage candidate blobs.
Signed-off-by: Junio C Hamano <junkio@cox.net>
diff_filespec has a slot to record the size of the data already,
so make use of it instead of a separate size cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This reduces the memory pressure when dealing with many paths.
An unscientific test of running "diff-tree --stat --summary -M"
between v2.6.19 and v2.6.20-rc1 in the linux kernel repository
indicates that the number of minor faults are reduced by 2/3.
Signed-off-by: Junio C Hamano <junkio@cox.net>
- git-ls-files.txt: typo in description of --ignored
- git-clean.txt: s/forceRequire/requireForce/
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This tests the -d, -n, -f, -x, and -X options to git-clean.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes "git-ls-files --others --directory --ignored" behave
as documented and consequently also fixes "git-clean -d -X".
Previously, git-clean would remove non-excluded directories
even when using the -X option.
Signed-off-by: Michael Spang <mspang@uwaterloo.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Documentation: don't reference non-existent 'git-cvsapplycommit'
user-manual: stop deprecating the manual
user-manual: miscellaneous editing
user-manual: fix .gitconfig editing examples
user-manual: clean up fast-forward and dangling-objects sections
user-manual: add section ID's
user-manual: more discussion of detached heads, fix typos
git-gui: Allow spaces in path to 'wish'
gitk: Allow user to choose whether to see the diff, old file, or new file
It's just as much a work-in-progress, but at least now it's gotten
enough technical review to shake out most of the really bad lies, so
hopefully it doesn't do any actual damage. And if we encourage people
to read it, they'll be more likely to whine about it, which will help
get it fixed faster.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I cherry-picked some additional miscellaneous fixes from those suggested
by Santi Béjar, including fixes to:
- correct discussion of repository/HEAD->repository shortcut
- add mention of git-mergetool
- add mention of --track
- mention "-f" as well as "+" for fetch
Cc: Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Santi Béjar points out that when telling people how to "introduce
themselves" to git we're advising them to replace their entire
.gitconfig file. Fix that.
Cc: "Santi Béjar <sbejar@gmail.com>
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
The previous commit calls attention to the fact that we have two
sections each devoted to fast-forwards and to dangling objects. Revise
and attempt to differentiate them a bit. Some more reorganization may
be required later....
Signed-off-by: J. Bruce Fields
Any section lacking an id gets an annoying warning when you build
the manual. More seriously, the table of contents then generates
volatile id's which change with every build, with the effect that
we get URL's that change all the time.
The ID's are manually generated and sometimes inconsistent, but
that's OK.
XXX: what to do about the preface?
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Nicolas Pitre pointed out a couple typos and some room for improvement
in the discussion of detached heads.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Cc: Nicolas Pitre <nico@cam.org>
* maint:
Small correction in reading of commit headers
Documentation: fix typo in git-remote.txt
Add test for blame corner cases.
blame: -C -C -C
blame: Notice a wholesale incorporation of an existing file.
Fix --boundary output
diff format documentation: describe raw combined diff format
Mention version 1.5.1 in tutorial and user-manual
Add --no-rebase option to git-svn dcommit
Fix markup in git-svn man page
This fixes a crash in broken repositories where random commits
suddenly disappear.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Check if a line of the header has enough characters to possibly
contain the requested prefix.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When you do this, existing "blame -C -C" would not find that the
latter half of the file2 came from the existing file1:
... both file1 and file2 are tracked ...
$ cat file1 >>file2
$ git add file1 file2
$ git commit
This is because we avoid the expensive find-copies-harder code
that makes unchanged file (in this case, file1) as a candidate
for copy & paste source when annotating an existing file
(file2). The third -C now allows it. However, this obviously
makes the process very expensive. We've actually seen this
patch before, but I dismissed it because it covers such a narrow
(and arguably stupid) corner case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The -C option to blame tries to find a section of a preimage
file by running diff against the lines whose origin is still
unknown, and excluding the different parts. The code however
did not cover the case where the tail part of the section
matched, which we handle for the normal non-move/copy codepath.
This breakage was most visible when preimage file matches in its
entirety and failed to pass blame in such a case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git log --boundary" incorrectly honoured the option only when
"left-right" was enabled.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add description of raw combined diff format to diff-formats.txt,
as "diff format for merges" section, before "Generating patches..."
section.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Most other documentation will frequently be read from an installation
of git so will naturally be associated with the installed version.
But these two documents in particular are often read from web pages
while users are still exploring git. It's important to mention
version 1.5.1 since these documents provide example commands that
won't work with previous versions of git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn dcommit exports commits to Subversion, then imports them back
to git again, and last but not least rebases or resets HEAD to the
last of the new commits. I guess this rebasing is convenient when
using just git, but when the commits to be exported are managed by
StGIT, it's really annoying. So add an option to disable this
behavior. And document it, too!
Signed-off-by: Karl Hasselström <kha@treskal.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some of the existing markup was just plain broken, and some subcommand
options weren't indented properly.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the -v is passed, git-tag will exit after it is processed like it
does with the -d and -l options. Additionally, missing code block caused
wrong rendering of an option example.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is actually a few different changes to request-pull,
making it slightly smarter:
1) Minor cleanup of revision->base variable names, making it
follow the head/headrev naming convention that is already
in use.
2) Compute the merge-base between the two revisions upfront
and reuse that selected merge-base to create the diffstat.
3) Refuse to generate a pull request for branches that have no
existing relationship. These aren't very common and would mess
up our diffstat generation.
4) Disable the PAGER when running shortlog and diff, as these
would otherwise activate the pager for each command when
git-request-pull is run on a tty. Instead users can get the
entire output paged (if desired) using `git -p request-pull`.
5) Use shortlog rather than `git log | git shortlog` now that
recent shortlog versions are able to run the revision listing
internally.
6) Attempt to resolve the input URL using the user's configured
remotes. This is useful if the URL you want the recipient to
see is also the one you used to push your changes. If not a
config-file remote could easily be setup for the public URL
and request-pull could be passed that name instead.
7) Automatically guess and include the remote branch name in the
body of the message. We list the branch name immediately after
the URL, making it easy for the recipient to copy and paste
the entire line onto a `git pull` command line. Rumor has it
Linus likes this format, for exactly that reason.
If multiple branches at the remote match $headrev we take the
first one returned by peek-remote and assume it is suitable.
If no branches are available we warn the user about the problem,
but insert a static string that is not a valid branch name
and would be obvious to anyone reading the message as being
totally incorrect. This allows users to still generate a
template message without network access (for example) and
hand-correct the bits that cannot be verified.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
gitweb: use decode_utf8 directly
posix compatibility for t4200
Document 'opendiff' value in config.txt and git-mergetool.txt
Allow PERL_PATH="/usr/bin/env perl"
Make xstrndup common
diff.c: fix "size cache" handling.
http-fetch: Disable use of curl multi support for libcurl < 7.16.
Using decode() tries to decode data that is already UTF-8 and
borks, but decode_utf8 from Encode.pm has a built-in safety
against that.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix t4200 so that it also works on OS X by not relying on gnu
extensions to sed.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is a mechanism PERL_PATH in the Makefile to specify path to
Perl binary, but sometimes it is convenient to let 'env' figure
out where Perl comes from, with PERL_PATH="/usr/bin/env perl".
Allowing this would make things easier to MacPorts, where we wish
to work with the MacPorts perl if it is installed, but fall back
to the system perl if it isn't.
Signed-off-by: Bryan Larsen <bryan@larsen.st>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This also improves the implementation to match how strndup is
specified (by GNU): if the length given is longer than the string,
only the string's length is allocated and copied, but the string need
not be null-terminated if it is at least as long as the given length.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We broke the size-cache handling when we changed the function
signature of sha1_object_info() in 21666f1a. We obviously
wanted to cache the size we obtained when sha1_object_info()
succeeded, not when it failed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
curl_multi_remove_handle() is broken in libcurl < 7.16, in that it
doesn't correctly update the active handles count when a request is
aborted. This causes the transfer to hang forever waiting for the
handle count to become less than the number of active requests.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There really isn't any point in turning off .mailmap. The
number of mailmap lookups are bounded by number of lines in the
target file, and the real blame processing is much more
expensive. If it turns out to be too costly, we should optimize
the mailmap lookup itself, instead of avoiding the call.
If the author information of commits of the project are
relatively clean, .mailmap would have only small number of
entries, and the overhead of looking it up will not be high. On
the other hand, if the author information is really screwed up
that a good .mailmap needs to be maintained to run shortlog,
giving uncleaned names in blame output is not helpful at all
either.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We can't unconditionally assign revision 1.1 to
newly added files. In case the file did exist in the
past and was deleted we need to honor the old
revision number.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
For example Mac OS X lacks the seq command. So we cannot use it
there. A good old while loop works just as good.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that fast-import is using a "library function" to handle
correcting its packfile's object count and trailing SHA-1 we
should reuse the same function in index-pack, to reduce the
size of the code we must maintain.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Include a generalized fixup_pack_header_footer() in this new file.
Needed by git-repack --max-pack-size feature in a later patchset.
[sp: Moved close(pack_fd) to callers, to support index-pack, and
changed name to better indicate it is for packfiles.]
Signed-off-by: Dana L. How <danahow@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This extension allows GNU tar to process file names in excess of the 100
characters defined by the original tar standard. It does this by faking a
file, named '././@LongLink' containing the true file name, and then adding
the file with a truncated name. The idea is that tar without this
extension will write out a file with the long file name, and write the
contents into a file with truncated name.
Unfortunately, GNU tar does a lousy job at times. When truncating results
in a _directory_ name, it will happily use _that_ as a truncated name for
the file.
An example where this actually happens is gcc-4.1.2, where the full path
of the file WeThrowThisExceptionHelper.java truncates _exactly_ before the
basename. So, we have to support that ad-hoc extension.
This bug was noticed by Chris Riddoch on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like core-Git we now track the values that we embed into our shell
script wrapper, and we "recompile" that wrapper if they are changed.
This concept was lifted from git.git's Makefile, where a similar
thing was done by Eygene Ryabinkin. Too bad it wasn't just done
here in git-gui from the beginning, as the git.git Makefile support
for GIT-GUI-VARS was really just because git-gui doesn't do it on
its own.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Whenever we want to execute a git subcommand from the plumbing
layer (and on rare occasion, the more porcelain-ish layer) we
tend to use our proc wrapper, just to make the code slightly
cleaner at the call sites. I wasn't doing that in a couple of
places, so this is a simple cleanup to correct that.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than passing "-font font_ui" to every widget that we
create we can instead reconfigure the option database for
all widget classes to use our font_ui as the default widget
font. This way Tk will automatically setup their defaults
for us, and we can reduce the size of the application.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
An earlier change tossed these optionMenu font configurations
all over the code, when really we can just rename the proc to
a hidden internal name and provide our own wrapper to install
the font configuration we really want.
We also don't need to set these option database entries in all
of the procedures that open dialogs; instead we should just set
one time, them after we have the font configuration ready for use.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Since Tk automatically wraps lines for us in tk_messageBox
widgets we don't need to try to wrap them ourselves. Its
actually worse that we linewrapped this here in the script,
as not all fonts will render this dialog nicely.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A coworker who was new to git-gui recently tried to make an octopus
merge when he did not quite mean to. Unfortunately in his case the
branches had file level conflicts and failed to merge with the octopus
strategy, and he didn't quite know why this happened. Since most users
really don't want to perform an octopus merge this additional safety
valve in front of the merge process is a good thing.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that the command line git-commit has made displaying
the subject (first line) of the newly created commit popular
we can easily do the same thing here in git-gui, without the
ugly part of forking off a child process to obtain that first
line.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the path of our wish executable that are running under
contains spaces we need to make sure they are escaped in
a proper Tcl list, otherwise we are unable to start gitk.
Reported by Randal L. Schwartz on #git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The code used write_in_full() without pulling its declarations from the
header file. When header is included, usage[] collides with usage()
function.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
read_mailmap already returns not 0 in case of error, and nothing
seem to be interested in it. It also is silent about the fact
(read_mailmap being to chatty would justify the call to access,
but there is no point for it to be and it isn't).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The only such a caller builtin-blame.c would pass NULL as the place
where to store the abbreviation.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
strncpy does not NUL-terminate output in case of output buffer too short,
and map_email prototype (and usage) does not allow for figuring out
what the length of the name is.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This splits out a few functions to deal with mailmap from
shortlog and makes it a bit more usable from other programs.
Most notably, it does not clobber input e-mail address anymore.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this "git blame -b -s HEAD~n..HEAD" becomes a nicer way to
review the result of recent changes in context.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some other programs get the user's email address from $EMAIL, so fall back to
that if we don't have a Git-specific email address.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
http.c: Fix problem with repeated calls of http_init
Add missing reference to GIT_COMMITTER_DATE in git-commit-tree documentation
Fix import-tars fix.
Update .mailmap with "Michael"
Do not barf on too long action description
Catch empty pathnames in trees during fsck
Don't allow empty pathnames in fast-import
import-tars: be nice to wrong directory modes
git-svn: Added 'find-rev' command
git shortlog documentation: add long options and fix a typo
The sed command that extracted the first line of the project description
didn't include the -n switch and hence the project name was being
printed twice. This was ruining the email header generation because it
was assumed that the description was only one line and was included in
the subject. This turned the subject into a two line item and
prematurely finished the header.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes a non-fast-forward update doesn't add new commits, it merely
removes old commits. This patch adds support for detecting that and
outputting a more correct message.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
as it is not relevant for whether the result should be written.
Even if no real merge happened, there might be _no_ reason to
rewrite the working tree file. Maybe even more so.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also leave a warning for future merge-recursive explorers.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a file is changed in one branch, and renamed and changed to the
same content in another branch than we can skip the rewrite of this
file in the working directory, as the content does not change.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Start preparing for 1.5.1.3
Sanitize @to recipients.
git-svn: Ignore usernames in URLs in find_by_url
Document --dry-run and envelope-sender for git-send-email.
Allow users to optionally specify their envelope sender.
Ensure clean addresses are always used with Net::SMTP
Validate @recipients before using it for sendmail and Net::SMTP.
Perform correct quoting of recipient names.
Change the scope of the $cc variable as it is not needed outside of send_message.
Debugging cleanup improvements
Prefix Dry- to the message status to denote dry-runs.
Document --dry-run parameter to send-email.
git-svn: Don't rely on $_ after making a function call
Fix handle leak in write_tree
Actually handle some-low memory conditions
Conflicts:
RelNotes
git-send-email.perl
This adds --date={local,relative,default} option to log family of commands,
to allow displaying timestamps in user's local timezone, relative time, or
the default format.
Existing --relative-date option is a synonym of --date=relative; we could
probably deprecate it in the long run.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We don't need it, it's possible to assign the block of memory to bufp
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- Do not break the line when it's not needed
- s/Your/You
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This change 'opens' the code block which maps the index file into
memory, making the code clearer and easier to read.
Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The interface is similar to the custom low-level merge drivers.
First you configure your filter driver by defining 'filter.<name>.*'
variables in the configuration.
filter.<name>.clean filter command to run upon checkin
filter.<name>.smudge filter command to run upon checkout
Then you assign filter attribute to each path, whose name
matches the custom filter driver's name.
Example:
(in .gitattributes)
*.c filter=indent
(in config)
[filter "indent"]
clean = indent
smudge = cat
Signed-off-by: Junio C Hamano <junkio@cox.net>
The 'ident' attribute set to path squashes "$ident:<any bytes
except dollor sign>$" to "$ident$" upon checkin, and expands it
to "$ident: <blob SHA-1> $" upon checkout.
As we have two conversions that affect checkin/checkout paths,
clarify how they interact with each other.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* mk/diff:
Diff between two blobs should take mode changes into account now.
use mode of the tree in git-diff, if <tree>:<file> syntax is used
store mode in rev_list, if <tree>:<filename> syntax is used
add add_object_array_with_mode
add get_sha1_with_mode
Add S_IFINVALID mode
* maint:
Remove usernames from all commit messages, not just when using svmprops
applymbox & quiltimport: typofix.
Create a sysconfdir variable, and use it for ETC_GITCONFIG
* 'master' of git://repo.or.cz/git/fastimport:
fast-import: size_t vs ssize_t
fix importing of subversion tars
Don't repack existing objects in fast-import
Each object in struct object_array is extended with the mode.
If not specified, S_IFINVALID is used. An object with an mode value
can be added with add_object_array_with_mode.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
get_sha1_with_mode basically behaves as get_sha1. It has an additional
parameter for storing the mode of the object.
If the mode can not be determined, it stores S_IFINVALID.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
S_IFINVALID is used to signal, that no mode information is available.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Documentation/git-reset.txt: suggest git commit --amend in example.
Build RPM with ETC_GITCONFIG=/etc/gitconfig
Ignore all man sections as they are generated files.
Fix typo in git-am: s/Was is/Was it/
Reverse the order of -b and --track in the man page.
dir.c(common_prefix): Fix two bugs
Conflicts:
git.spec.in
If $ls_remote_result was too long,
git-fetch--tool -s pick-rref "$rref" "$ls_remote_result"
in git-fetch will fail with "argument list too long".
This patch fixes git-fetch--tool and git-fetch by passing
$ls_remote_result via stdin.
Signed-off-by: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Uwe Kleine-König discovered git-gui mangled his surname and did
not send the proper UTF-8 byte sequence to git-commit-tree when
his name appeared in the commit message (e.g. Signed-Off-By line).
Turns out this was related to other trouble that I had in the past
with trying to use "fconfigure $fd -encoding $enc" to select the
stream encoding and let Tcl's IO engine do all of the encoding work
for us. Other parts of git-gui were just always setting the file
channels to "-encoding binary" and then performing the encoding
work themselves using "encoding convertfrom" and "convertto", as
that was the only way I could make UTF-8 filenames work properly.
I found this same bug in the amend code path, and in the blame
display. So its fixed in all three locations (commit creation,
reloading message for amend, viewing message in blame).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Add a new configuration option clean.requireForce. If set, git-clean will
refuse to run, unless forced with the new -f option, or not acting due to -n.
Signed-off-by: Josh Triplett <josh@freedesktop.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of running rev-list and picking earlier lines using head/tail pipeline,
grab commit object name as we build commits. This also removes a non POSIX
use of tail with -linenum (more posixly-correct way to say it is "-n linenum")
Signed-off-by: Junio C Hamano <junkio@cox.net>
A Large Angry SCM (gitzilla) noticed that on an unnamed platform, tail -c
wants its byte count as part of the option, not as a separate argument.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that git-commit got chatty, we have to shut it up again.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It is nice to see what is happening when checking out large amount of
files, either with git-checkout or git-reset. The new progress code
already decides what is a "significant amount" and displays progress
only in that case..
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes all low-level functions defined in read-cache.c to
take an explicit index_state structure as their first parameter,
to specify which index to work on. These functions
traditionally operated on "the_index" and were named foo_cache();
the counterparts this patch introduces are called foo_index().
The traditional foo_cache() functions are made into macros that
give "the_index" to their corresponding foo_index() functions.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This defines a index_state structure and moves index-related
global variables into it. Currently there is one instance of
it, the_index, and everybody accesses it, so there is no code
change.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, gitweb shows only header and footer, if no differences are
found. This patch adds a "No differences found" message for the html
output.
Signed-off-by: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let's start displaying progress only if more than 50% of total number
of files remains to be checked out after 2 seconds.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows for progress to be displayed only if the progress has not
reached a specified percentage treshold within a given delay in seconds.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the progress bar ends up in a box, better provide a title for it too.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of having this code duplicated in multiple places, let's have
a common interface for progress display. If someday someone wishes to
display a cheezy progress bar instead then only one file will have to
be changed.
Note: I left merge-recursive.c out since it has a strange notion of
progress as it apparently increase the expected total number as it goes.
Someone with more intimate knowledge of what that is supposed to mean
might look at converting it to the common progress interface.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This enhances the attributes mechanism so that external programs
meant for existing GIT_EXTERNAL_DIFF interface can be specifed
per path.
To configure such a custom diff driver, first define a custom
diff driver in the configuration:
[diff "my-c-diff"]
command = <<your command string comes here>>
Then mark the paths that you want to use this custom driver
using the attribute mechanism.
*.c diff=my-c-diff
The intent of this separation is that the attribute mechanism is
used for specifying the type of the contents, while the
configuration mechanism is used to define what needs to be done
to that type of the contents, which would be specific to both
platform and personal taste.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The earlier quickfix forced world-readable permission bits. This
updates it to honor umask and core.sharedrepository settings.
Signed-off-by: Junio C Hamano <junkio@cox.net>
mkstemp() often creates the file in 0600 which means the
resulting packfile is not readable by anybody other than the
repository owner. Force 0644 for now, even though this is not
strictly correct.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reallocated wrong size.
Noticed on Ubuntu 7.04 probably because it has some malloc diagnostics in libc:
"git-read-tree --reset -u HEAD" aborted in the test. Valgrind sped up the
debugging greatly: took me 10 minutes.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also, noticed by valgrind: the code caused a read out-of-bounds.
Some comments updated as well (they still reflected old calling
conventions).
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I want to add new command line options to cat-file, but
to do that we need to change how we handle argv[] first.
This is a simple cleanup that assigns names to the two
arguments we currently care about.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'jc/attr': (28 commits)
lockfile: record the primary process.
convert.c: restructure the attribute checking part.
Fix bogus linked-list management for user defined merge drivers.
Simplify calling of CR/LF conversion routines
Document gitattributes(5)
Update 'crlf' attribute semantics.
Documentation: support manual section (5) - file formats.
Simplify code to find recursive merge driver.
Counto-fix in merge-recursive
Fix funny types used in attribute value representation
Allow low-level driver to specify different behaviour during internal merge.
Custom low-level merge driver: change the configuration scheme.
Allow the default low-level merge driver to be configured.
Custom low-level merge driver support.
Add a demonstration/test of customized merge.
Allow specifying specialized merge-backend per path.
merge-recursive: separate out xdl_merge() interface.
Allow more than true/false to attributes.
Document git-check-attr
Change attribute negation marker from '!' to '-'.
...
* lt/gitlink:
Tests for core subproject support
Expose subprojects as special files to "git diff" machinery
Fix some "git ls-files -o" fallout from gitlinks
Teach "git-read-tree -u" to check out submodules as a directory
Teach git list-objects logic to not follow gitlinks
Fix gitlink index entry filesystem matching
Teach "git-read-tree -u" to check out submodules as a directory
Teach git list-objects logic not to follow gitlinks
Don't show gitlink directories when we want "other" files
Teach git-update-index about gitlinks
Teach directory traversal about subprojects
Fix thinko in subproject entry sorting
Teach core object handling functions about gitlinks
Teach "fsck" not to follow subproject links
Add "S_IFDIRLNK" file mode infrastructure for git links
Add 'resolve_gitlink_ref()' helper function
Avoid overflowing name buffer in deep directory structures
diff-lib: use ce_mode_from_stat() rather than messing with modes manually
* np/pack: (27 commits)
document --index-version for index-pack and pack-objects
pack-objects: remove obsolete comments
pack-objects: better check_object() performances
add get_size_from_delta()
pack-objects: make in_pack_header_size a variable of its own
pack-objects: get rid of create_final_object_list()
pack-objects: get rid of reuse_cached_pack
pack-objects: clean up list sorting
pack-objects: rework check_delta_limit usage
pack-objects: equal objects in size should delta against newer objects
pack-objects: optimize preferred base handling a bit
clean up add_object_entry()
tests for various pack index features
use test-genrandom in tests instead of /dev/urandom
simple random data generator for tests
validate reused pack data with CRC when possible
allow forcing index v2 and 64-bit offset treshold
pack-redundant.c: learn about index v2
show-index.c: learn about index v2
sha1_file.c: learn about index version 2
...
* jc/quickfetch:
Make sure quickfetch is not fooled with a previous, incomplete fetch.
git-fetch: use fetch--tool pick-rref to avoid local fetch from alternate
git-fetch--tool pick-rref
* maint:
GIT 1.5.1.2
perl: install private Error.pm if the site version is older than our own
git-clone: fix dumb protocol transport to clone from pack-pruned ref
The usual process flow is the main process opens and holds the lock to
the index, does its thing, perhaps spawning children during the course,
and then writes the resulting index out by releaseing the lock.
However, the lockfile interface uses atexit(3) to clean it up, without
regard to who actually created the lock. This typically leads to a
confusing behaviour of lock being released too early when the child
exits, and then the parent process when it calls commit_lockfile()
finds that it cannot unlock it.
This fixes the problem by recording who created and holds the lock, and
upon atexit(3) handler, child simply ignores the lockfile the parent
created.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This separates the checkattr() call and interpretation of the
returned value specific to the 'crlf' attribute into separate
routines, so that we can run a single call to checkattr() to
check for more than one attributes, and then interprete what
the returned settings mean separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Duh.
When I did the object decorator thing, I made the "loop over the hash"
function use the same logic for updating the hash, ie made them use
if (++j >= size)
j = 0;
for both the hash update for both "insert" and "lookup"
HOWEVER.
For some inexplicable reason I had an extraneous
j++;
in the insert path (probably just from the fact that the old code there
used
j++;
if (j >= size)
j = 0;
and when I made them use the same logic I just didn't remove the old
extraneous line properly.
This fixes it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some users of fast-import have been trying to use it to rewrite
commits and trees, an activity where the all of the relevant blobs
are already available from the existing packfiles. In such a case
we don't want to repack a blob, even if the frontend application
has supplied us the raw data rather than a mark or a SHA-1 name.
I'm intentionally only checking the packfiles that existed when
fast-import started and am always ignoring all loose object files.
We ignore loose objects because fast-import tends to operate on a
very large number of objects in a very short timespan, and it is
usually creating new objects, not reusing existing ones. In such
a situtation the majority of the objects will not be found in the
existing packfiles, nor will they be loose object files. If the
frontend application really wants us to look at loose object files,
then they can just repack the repository before running fast-import.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This is a shorthand of what "git commit -a" does in preparation
for making a commit, which is:
git diff-files --name-only -z | git update-index --remove -z --stdin
Signed-off-by: Junio C Hamano <junkio@cox.net>
List files modifed as a part of the commit in the diff window
Support annotation of the file listed in the diff window
Support history browsing in the annotation window.
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The mess known as the progress meter in merge-recursive was my own
fault; I put it in thinking that we might be spending a lot of time
resolving unmerged entries in the index that were not handled by
the simple 3-way index merge code.
Turns out we don't really spend that much time there, so the progress
meter was pretty much always jumping to "(n/n) 100%" as soon as
the program started. That isn't a very good indication of progress.
Since I don't have a great solution for how a progress meter should
work here, I'm proposing we back it out entirely.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a description of the commit to the reflog using the first line of
the log message, the same way the git-commit script does it.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm using a variant of this update hook in a corporate environment
where we perform some validations of the commits and tags that
are being pushed. The model is a "central repository" type setup,
where users are given access to push to specific branches within
the shared central repository. In this particular installation we
run a specially patched git-receive-pack in setuid mode via SSH,
allowing all writes into the repository as the repository owner,
but only if this hook blesses it.
One of the major checks we perform with this hook is that the
'committer' line of a commit, or the 'tagger' line of a new annotated
tag actually correlates to the UNIX user who is performing the push.
Users can falsify these lines on their local repositories, but
the central repository that management trusts will reject all such
forgery attempts. Of course 'author' lines are still allowed to
be any value, as sometimes changes do come from other individuals.
Another nice feature of this hook is the access control lists for
all repositories on the system can also be stored and tracked in
a supporting Git repository, which can also be access controlled
by itself. This allows full auditing of who-had-what-when-and-why,
thanks to git-blame's data mining capabilities.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Alex Riesen noticed that the case where a file replaced a directory entry
in the working tree was broken on cygwin. It turns out that the code made
some Linux-specific assumptions, and also ignored errors entirely for the
case where the entry was a symlink rather than a file.
This cleans it up by separating out the common case into a function of its
own, so that both regular files and symlinks can share it, and by making
the error handling more obvious (and not depend on any Linux-specific
behaviour).
Acked-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates the semantics of 'crlf' so that .gitattributes file
can say "this is text, even though it may look funny".
Setting the `crlf` attribute on a path is meant to mark the path
as a "text" file. 'core.autocrlf' conversion takes place
without guessing the content type by inspection.
Unsetting the `crlf` attribute on a path is meant to mark the
path as a "binary" file. The path never goes through line
endings conversion upon checkin/checkout.
Unspecified `crlf` attribute tells git to apply the
`core.autocrlf` conversion when the file content looks like
text.
Setting the `crlf` attribut to string value "input" is similar
to setting the attribute to `true`, but also forces git to act
as if `core.autocrlf` is set to `input` for the path.
Signed-off-by: Junio C Hamano <junkio@cox.net>
There is no need to intern the string to git_attr, as we are already
dealing with the name of the driver there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the configuration has variables unrelated to low-level
merge drivers (e.g. merge.summary), the code failed to ignore
them but did something totally senseless.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a set of radiobuttons that select between displaying the full
diff (both - and + lines), the old file (suppressing the + lines) and the
new file (suppressing the - lines) in the diff display window.
Signed-off-by: Paul Mackerras <paulus@samba.org>
The following tests available:
- create subprojects: create a directory in the superproject,
initialize a git repo in it, and try adding it in super project.
Make a commit in superproject
- check if fsck ignores the subprojects: it just should give no errors
- check if commit in a subproject detected: make a commit in
subproject, git-diff-files in superproject should detect it
- check if a changed subproject HEAD can be committed: try
"git-commit -a" in superproject. It should commit changed
HEAD of a subproject
- check if diff-index works for subproject elements: compare the index
(changed by previuos tests) with the initial commit (which created
two subprojects). Should show a change for the recently changed subproject
- check if diff-tree works for subproject elements: do the same, just use
git-diff-tree. This test is somewhat redundant, I just added it for
completeness (diff, diff-files, and diff-index are already used)
- check if git diff works for subproject elements: try to limit
the diff for the name of a subproject in superproject:
git diff HEAD^ HEAD -- subproject
- check if clone works: try a clone of superproject and compare
"git ls-files -s" output in superproject and cloned repo
- removing and adding subproject: rename test. Currently implemented
as "git-update-index --force-remove", "mv" and "git-add".
- checkout in superproject: try to checkout the initial commit
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Rather than sorting the refs list while building it, sort in one
go after it is built using a merge sort. This has a large
performance boost with large numbers of refs.
It shouldn't happen that we read duplicate entries into the same
list, but just in case sort_ref_list drops them if the SHA1s are
the same, or dies, as we have no way of knowing which one is the
correct one.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-shortlog: Fix two formatting errors in asciidoc documentation
Fix overwriting of files when applying contextually independent diffs
git-svn: don't allow globs to match regular files
It was bothering me a lot that I abused small integer values
casted to (void *) to represent non string values in
gitattributes. This corrects it by making the type of attribute
values (const char *), and using the address of a few statically
allocated character buffer to denote true/false. Unset attributes
are represented as having NULLs as their values.
Added in-header documentation to explain how git_checkattr()
routine should be called.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows [merge "drivername"] to have a variable "recursive"
that names a different low-level merge driver to be used when
merging common ancestors to come up with a virtual ancestor.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the configuration syntax for defining a low-level
merge driver to be:
[merge "<<drivername>>"]
driver = "<<command line>>"
name = "<<driver description>>"
which is much nicer to read and is extensible. Credit goes to
Martin Waitz and Linus.
In addition, when we use an external low-level merge driver, it
is reported as an extra output from merge-recursive, using the
value of merge.<<drivername>.name variable.
The demonstration in t6026 has also been updated.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When no 'merge' attribute is given to a path, merge-recursive
uses the built-in xdl-merge as the low-level merge driver.
A new configuration item 'merge.default' can name a low-level
merge driver of user's choice to be used instead.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows users to specify custom low-level merge driver per
path, using the attributes mechanism. Just like you can specify
one of built-in "text", "binary", "union" low-level merge
drivers by saying:
* merge=text
.gitignore merge=union
*.jpg merge=binary
pick a name of your favorite merge driver, and assign it as the
value of the 'merge' attribute.
A custom low-level merge driver is defined via the config
mechanism. This patch introduces 'merge.driver', a multi-valued
configuration. Its value is the name (i.e. the one you use as
the value of 'merge' attribute) followed by a command line
specification. The command line can contain %O, %A, and %B to
be interpolated with the names of temporary files that hold the
common ancestor version, the version from your branch, and the
version from the other branch, and the resulting command is
spawned.
The low-level merge driver is expected to update the temporary
file for your branch (i.e. %A) with the result and exit with
status 0 for a clean merge, and non-zero status for a conflicted
merge.
A new test in t6026 demonstrates a sample usage.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* fl/cvsserver:
config.txt: Add gitcvs.db* variables
cvsserver: Document the GIT branches -> CVS modules mapping more prominently
cvsserver: Reword documentation on necessity of write access
cvsserver: Allow to "add" a removed file
cvsserver: Add asciidoc documentation for new database backend configuration
cvsserver: Corrections to the database backend configuration
cvsserver: Use DBI->table_info instead of DBI->tables
cvsserver: Abort if connect to database fails
cvsserver: Make the database backend configurable
cvsserver: Allow to override the configuration per access method
cvsserver: Handle three part keys in git config correctly
cvsserver: Introduce new state variable 'method'
Conflicts:
Documentation/config.txt
* maint:
Start preparing for 1.5.1.2
git-svn: quiet some warnings when run only with --version/--help
git-svn: respect lower bound of -r/--revision when following parent
Conflicts:
RelNotes
* 'master' of git://repo.or.cz/git-gui:
git-gui: Honor TCLTK_PATH if supplied
Revert "Allow wish interpreter to be defined with TCLTK_PATH"
git-gui: Display the directory basename in the title
git-gui: Brown paper bag fix division by 0 in blame
Always bind the return key to the default button
Do not break git-gui messages into multiple lines.
Improve look-and-feel of the git-gui tool.
Teach git-gui to use the user-defined UI font everywhere.
Allow wish interpreter to be defined with TCLTK_PATH
* jc/read-tree-df:
t3030: merge-recursive backend test.
merge-recursive: handle D/F conflict case more carefully.
merge-recursive: do not barf on "to be removed" entries.
Treat D/F conflict entry more carefully in unpack-trees.c::threeway_merge()
t1000: fix case table.
This demonstrates how the new low-level per-path merge backends,
union and ours, work, and shows how they are controlled by the
gitattribute mechanism.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows 'merge' attribute to control how the file-level
three-way merge is done per path.
- If you set 'merge' to true, leave it unspecified, or set it
to "text", we use the built-in 3-way xdl-merge.
- If you set 'merge' to false, or set it to "binary, the
"binary" merge is done. The merge result is the blob from
'our' tree, but this still leaves the path conflicted, so
that the mess can be sorted out by the user. This is
obviously meant to be useful for binary files.
- 'merge=union' (this is the first example of a string valued
attribute, introduced in the previous one) uses the "union"
merge. The "union" merge takes lines in conflicted hunks
from both sides, which is useful for line-oriented files such
as .gitignore.
Instead fo setting merge to 'true' or 'false' by using 'merge'
or '-merge', setting it explicitly to "text" or "binary" will
become useful once we start allowing custom per-path backends to
be added, and allow them to be activated for the default
(i.e. 'merge' attribute specified to 'true' or 'false') case,
using some other mechanisms. Setting merge attribute to "text"
or "binary" will be a way to explicitly request to override such
a custom default for selected paths.
Currently there is no way to specify random programs but it
should be trivial for motivated contributors to add later.
There is one caveat, though. ll_merge() is called for both
internal ancestor merge and the outer "final" merge. I think an
interactive custom per-path merge backend should refrain from
going interactive when performing an internal merge (you can
tell it by checking call_depth) and instead just call either
ll_xdl_merge() if the content is text, or call ll_binary_merge()
otherwise.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mimick what we do for gitk. Since you do have a source file,
git-gui.sh, which is separate from the target, it should be much
easier in git-gui's Makefile.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This reverts commit e2a1bc67d3.
Junio rightly pointed out this patch doesn't handle the
`make install` target very well:
Junio C Hamano <junkio@cox.net> writes:
> You should never generate new files in the source tree from
> 'install' target. Otherwise, the usual pattern of "make" as
> yourself and then "make install" as root would not work from a
> "root-to-nobody-squashing" NFS mounted source tree to local
> filesystem. You should know better than accepting such a patch.
This allows you to define three values (and possibly more) to
each attribute: true, false, and unset.
Typically the handlers that notice and act on attribute values
treat "unset" attribute to mean "do your default thing"
(e.g. crlf that is unset would trigger "guess from contents"),
so being able to override a setting to an unset state is
actually useful.
- If you want to set the attribute value to true, have an entry
in .gitattributes file that mentions the attribute name; e.g.
*.o binary
- If you want to set the attribute value explicitly to false,
use '-'; e.g.
*.a -diff
- If you want to make the attribute value _unset_, perhaps to
override an earlier entry, use '!'; e.g.
*.a -diff
c.i.a !diff
This also allows string values to attributes, with the natural
syntax:
attrname=attrvalue
but you cannot use it, as nobody takes notice and acts on
it yet.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates git-rev-list --objects to be a bit more careful
when listing a blob object to make sure the blob actually
exists, and uses it to make sure the quick-fetch optimization we
introduced earlier is not fooled by a previous incomplete fetch.
The quick-fetch optimization works by running this command:
git rev-list --objects <<commit-list>> --not --all
where <<commit-list>> is a list of commits that we are going to
fetch from the other side. If there is any object missing to
complete the <<commit-list>>, the rev-list would fail and die
(say, the commit was in our repository, but its tree wasn't --
then it will barf while trying to list the blobs the tree
contains because it cannot read that tree).
Usually we do not have the objects (otherwise why would we
fetching?), but in one important special case we do: when the
remote repository is used as an alternate object store
(i.e. pointed by .git/objects/info/alternates). We could check
.git/objects/info/alternates to see if the remote we are
interacting with is one of them (or is used as an alternate,
recursively, by one of them), but that check is more cumbersome
than it is worth.
The above check however did not catch missing blob, because
object listing code did not read nor check blob objects, knowing
that blobs do not contain any further references to other
objects. This commit fixes it with practically unmeasurable
overhead.
I've benched this with
git rev-list --objects --all >/dev/null
in the kernel repository, with three different implementations
of the "check-blob".
- Checking with has_sha1_file() has negligible (unmeasurable)
performance penalty.
- Checking with sha1_object_info() makes it somewhat slower,
perhaps by 5%.
- Checking with read_sha1_file() to cause a fully re-validation
is prohibitively expensive (about 4 times as much runtime).
In my original patch, I had this as a command line option, but
the overhead is small enough that it is not really worth it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This replaces the fairly odd "created_object()" function that did _most_
of the object setup with a more complete "create_object()" function that
also has a more natural calling convention.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We used to use a different allocator scheme for when we didn't know the
object type. That meant that objects that were created without any
up-front knowledge of the type would not go through the same allocation
paths as normal object allocations, and would miss out on the statistics.
But perhaps more importantly than the statistics (that are useful when
looking at memory usage but not much else), if we want to make the
object hash tables use a denser object pointer representation, we need
to make sure that they all go through the same blocking allocator.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With large amount of objects, check_object() is really trashing the pack
sliding map and the filesystem cache. It has a completely random access
pattern especially with old objects where delta replay jumps back and
forth all over the pack.
This patch improves things by:
1) sorting objects by their offset in pack before calling check_object()
so the pack access pattern is linear;
2) recording the object type at add_object_entry() time since it is
already known in most cases;
3) recording the pack offset even for preferred_base objects;
4) avoid calling sha1_object_info() if all possible.
This limits pack accesses to the bare minimum and makes them perfectly
linear.
In the process check_object() was made more clear (to me at least).
Note: I thought about walking the sorted_by_offset list backward in
get_object_details() so if a pack happens to be larger than the available
file cache, then the cache would have been populated with useful data from
the beginning of the pack already when find_deltas() is called. Strangely,
testing (on Linux) showed absolutely no performance difference.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... which consists of existing code split out of packed_delta_info()
for other callers to use it as well.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It currently aliases delta_size on the principle that reused deltas won't
go through the whole delta matching loop hence delta_size was unused.
This is not true if given delta doesn't find its base in the pack though.
But we need that information even for whole object data reuse.
Well in short the current state looks awful and is prone to bugs. It just
works fine now because try_delta() tests trg_entry->delta before using
trg_entry->delta_size, but that is a bit subtle and I was wondering for a
while why things just worked fine... even if I'm guilty of having
introduced this abomination myself in the first place.
Let's do the sensible thing instead with no ambiguity, which is to have
a separate variable for in_pack_header_size. This might even help future
optimizations.
While at it, let's reorder some struct object_entry members so they all
align well with their own width, regardless of the architecture or the
size of off_t. Some memory saving is to be expected with this alone.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Because we don't have to know the SHA1 h(hence the name) of the pack
up front anymore, let's get rid of yet another global sorted object list
and sort them only in write_index_file(), then compute the object list
SHA1 on the fly.
This has the advantage of saving another chunk of memory, and the sorted
list SHA1 won't be computed needlessly on servers during a fetch.
Of course the cunning plan is also to make write_index_file() much like
the function with the same name in index-pack.c for an eventual easy
sharing.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This capability is practically never useful, and therefore never tested,
because it is fairly unlikely that the requested pack will be already
available. Furthermore it is of little gain over the ability to reuse
existing pack data.
In fact the ability to change delta type on the fly when reusing delta
data is a nice thing that has almost no cost and allows greater backward
compatibility with a client's capabilities than if the client is blindly
sent a whole pack without any discrimination.
And this "feature" is simply in the way of other cleanups.
Let's get rid of it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Get rid of sort_comparator() as it impose a run time double indirect
function call for little compile time type checking gain.
Also get rid of create_sorted_list() as it only has one user which would
as well be just fine doing its sorting locally. Eventually the list of
deltifiable objects might be shorter than the whole object list.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Objects that have delta "children" from pack data reuse must consider the
depth of their deepest child when they try to deltify themselves for those
children not to become too deep.
However, in the context of a "thin" pack, the delta children depth was
skipped entirely on the presumption that the pack was always going to be
exploded on the receiving end, hence the delta length wasn't an issue.
Now that we keep received packs as is and reuse pack data when repacking,
those packs do contain delta chains that are longer than expected. Worse,
those delta chain may even grow longer when the pack is further repacked
into another thin pack for a subsequent transmission.
So this patch restores strict delta length even for thin packs, and it
moves check_delta_limit() usage directly in the delta loop where it is
needed. This way the delta_limit can be removed from struct object_entry
as well. Oh and the initial value was wrong too.
The progress_interval() function was moved to a more logical location in
the process.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Before finding best delta combinations, we sort objects by name hash,
then by size, then by their position in memory. Then we walk the list
backwards to test delta candidates.
We hope that a bigger size usually means a newer objects. But a bigger
address in memory does not mean a newer object. So the last comparison
must be reversed.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let's avoid some cycles when there is no base to test against, and avoid
unnecessary object lookups.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* js/wrap-log:
Fix permissions on test scripts
Fix t4201: accidental arithmetic expansion
shortlog -w: make wrap-line behaviour optional.
Use print_wrapped_text() in shortlog
Make every test executable. Remove exec-attribute from included shell files,
they can't used standalone anyway.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
instead of embedded subshell. It actually breaks here (dash as /bin/sh):
t4201-shortlog.sh: 27: Syntax error: Missing '))'
FATAL: Unexpected exit with code 2
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "--decorate" as a log option, which prints out the ref names
of any commits that are shown.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows you to add an arbitrary "decoration" of your choice to any
object. It's a space- and time-efficient way to add information to
arbitrary objects, especially if most objects probably do not have the
decoration.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Have sample update hook not refuse deleting a branch through push.
variable $projectdesc needs to be set before checking against unchanged default.
Update git-annotate/git-blame documentation
Update git-apply documentation
Update git-applymbox documentation
Update git-am documentation
user-manual: use detached head when rewriting history
user-manual: start revising "internals" chapter
user-manual: detached HEAD
user-manual: fix discussion of default clone
Documentation: clarify track/no-track option.
Documentation: clarify git-checkout -f, minor editing
Documentation: minor edits of git-lost-found manpage
Useful e.g. to figure out what I did from screen history,
or to make sure subject line is short enough and makes sense
on its own.
Signed-off-by: Michael S. Tsirkin <mst@dev.mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/SubmittingPatches: Add note that all user interface changes
should include associated documentation updates.
Signed-off-by: Andrew Ruder <andy@aeruder.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Document -g (--walk-reflogs) option of git-log
sscanf/strtoul: parse integers robustly
git-blame: Fix overrun in fake_working_tree_commit()
[PATCH] Improve look-and-feel of the gitk tool.
[PATCH] Teach gitk to use the user-defined UI font everywhere.
At the same time, we do not want to allow arbitrary strings for
attribute names, as we are likely to want to extend the syntax
later. Allow only alnum, dash, underscore and dot for now.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds "attribute macros" (for lack of better name). So far,
we have low-level attributes such as crlf and diff, which are
defined in operational terms --- setting or unsetting them on a
particular path directly affects what is done to the path. For
example, in order to decline diffs or crlf conversions on a
binary blob, no diffs on PostScript files, and treat all other
files normally, you would have something like these:
* diff crlf
*.ps !diff
proprietary.o !diff !crlf
That is fine as the operation goes, but gets unwieldy rather
rapidly, when we start adding more low-level attributes that are
defined in operational terms. A near-term example of such an
attribute would be 'merge-3way' which would control if git
should attempt the usual 3-way file-level merge internally, or
leave merging to a specialized external program of user's
choice. When it is added, we do _not_ want to force the users
to update the above to:
* diff crlf merge-3way
*.ps !diff
proprietary.o !diff !crlf !merge-3way
The way this patch solves this issue is to realize that the
attributes the user is assigning to paths are not defined in
terms of operations but in terms of what they are.
All of the three low-level attributes usually make sense for
most of the files that sane SCM users have git operate on (these
files are typically called "text'). Only a few cases, such as
binary blob, need exception to decline the "usual treatment
given to text files" -- and people mark them as "binary".
So this allows the $GIT_DIR/info/alternates and .gitattributes
at the toplevel of the project to also specify attributes that
assigns other attributes. The syntax is '[attr]' followed by an
attribute name followed by a list of attribute names:
[attr] binary !diff !crlf !merge-3way
When "binary" attribute is set to a path, if the path has not
got diff/crlf/merge-3way attribute set or unset by other rules,
this rule unsets the three low-level attributes.
It is expected that the user level .gitattributes will be
expressed mostly in terms of attributes based on what the files
are, and the above sample would become like this:
(built-in attribute configuration)
[attr] binary !diff !crlf !merge-3way
* diff crlf merge-3way
(project specific .gitattributes)
proprietary.o binary
(user preference $GIT_DIR/info/attributes)
*.ps !diff
There are a few caveats.
* As described above, you can define these macros only in
$GIT_DIR/info/attributes and toplevel .gitattributes.
* There is no attempt to detect circular definition of macro
attributes, and definitions are evaluated from bottom to top
as usual to fill in other attributes that have not yet got
values. The following would work as expected:
[attr] text diff crlf
[attr] ps text !diff
*.ps ps
while this would most likely not (I haven't tried):
[attr] ps text !diff
[attr] text diff crlf
*.ps ps
* When a macro says "[attr] A B !C", saying that a path does
not have attribute A does not let you tell anything about
attributes B or C. That is, given this:
[attr] text diff crlf
[attr] ps text !diff
*.txt !ps
path hello.txt, which would match "*.txt" pattern, would have
"ps" attribute set to zero, but that does not make text
attribute of hello.txt set to false (nor diff attribute set to
true).
Signed-off-by: Junio C Hamano <junkio@cox.net>
I lost it by mistake while shuffling the gitattributes series which
originally was on top of the subproject topic onto the master branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is in the same spirit as the previous one. Earlier 'diff'
meant 'do the built-in binary heuristics and disable patch text
generation based on it' while '!diff' meant 'do not guess, do
not generate patch text'. There was no way to say 'do generate
patch text even when the heuristics says it has NUL in it'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier we said 'crlf lets the path go through core.autocrlf
process while !crlf disables it altogether'. This fixes the
semantics to:
- Lack of 'crlf' attribute makes core.autocrlf to apply
(i.e. we guess based on the contents and if platform
expresses its desire to have CRLF line endings via
core.autocrlf, we do so).
- Setting 'crlf' attribute to true forces CRLF line endings in
working tree files, even if blob does not look like text
(e.g. contains NUL or other bytes we consider binary).
- Setting 'crlf' attribute to false disables conversion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The same way we generate diffs on symlinks as the the diff of text of the
symlink, we can generate subproject diffs (when not recursing into them!)
as the diff of the text that describes the subproject.
Of course, since what descibes a subproject is just the SHA1, that's what
we'll use. Add some pretty-printing to make it a bit more obvious what is
going on, and we're done.
So with this, we can get both raw diffs and "textual" diffs of subproject
changes:
- git diff --raw:
:160000 160000 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5 0000000... M sub-A
- git diff:
diff --git a/sub-A b/sub-A
index 2de597b..e8f11a4 160000
--- a/sub-A
+++ b/sub-A
@@ -1 +1 @@
-Subproject commit 2de597b5ad348b7db04bd10cdd38cd81cbc93ab5
+Subproject commit e8f11a45c5c6b9e2fec6d136d3fb5aff75393d42
NOTE! We'll also want to have the ability to recurse into the subproject
and actually diff it recursively, but that will involve a new command line
option (I'd suggest "--subproject" and "-S", but the latter is in use by
pickaxe), and some very different code.
But regardless of ay future recursive behaviour, we need the non-recursive
version too (and it should be the default, at least in the absense of
config options, so that large superprojects don't default to something
extremely expensive).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
By showing the basename of the directory very early in the
title bar I can more easily locate a particular git-gui
session when I have 8 open at once and my Windows taskbar
is overflowing with items.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* er/ui:
Always bind the return key to the default button
Do not break git-gui messages into multiple lines.
Improve look-and-feel of the git-gui tool.
Teach git-gui to use the user-defined UI font everywhere.
Allow wish interpreter to be defined with TCLTK_PATH
Since "git ls-files" doesn't really pass down any details on what it
really wants done to the directory walking code, the directory walking
code doesn't really know whether the caller wants to know about gitlink
directories, or whether it wants to just know about ignored files.
So the directory walking code will return those gitlink directories unless
the caller has explicitly told it not to ("dir->show_other_directories"
tells the directory walker to only show "other" directories).
This kind of confuses "git ls-files -o", because
- it didn't really expect to see entries listed that were already in the
index, unless they were unmerged, and would die on that unexpected
setup, rather than just "continue".
- it didn't know how to match directory entries with the final "/"
This trivial change updates the "show_other_files()" function to handle
both of these issues gracefully. There really was no reason to die, when
the obviously correct thing for the function was to just ignore files it
already knew about (that's what "other" means here!).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes paths that explicitly unset 'diff' attribute not to
produce "textual" diffs from 'git-diff' family.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This defines the semantics of 'crlf' attribute as an example.
When a path has this attribute unset (i.e. '!crlf'), autocrlf
line-end conversion is not applied.
Eventually we would want to let users to build a pipeline of
processing to munge blob data to filesystem format (and in the
other direction) based on combination of attributes, and at that
point the mechanism in convert_to_{git,working_tree}() that
looks at 'crlf' attribute needs to be enhanced. Perhaps the
existing 'crlf' would become the first step in the input chain,
and the last step in the output chain.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the basic infrastructure to assign attributes to
paths, in a way similar to what the exclusion mechanism does
based on $GIT_DIR/info/exclude and .gitignore files.
An attribute is just a simple string that does not contain any
whitespace. They can be specified in $GIT_DIR/info/attributes
file, and .gitattributes file in each directory.
Each line in these files defines a pattern matching rule.
Similar to the exclusion mechanism, a later match overrides an
earlier match in the same file, and entries from .gitattributes
file in the same directory takes precedence over the ones from
parent directories. Lines in $GIT_DIR/info/attributes file are
used as the lowest precedence default rules.
A line is either a comment (an empty line, or a line that begins
with a '#'), or a rule, which is a whitespace separated list of
tokens. The first token on the line is a shell glob pattern.
The rest are names of attributes, each of which can optionally
be prefixed with '!'. Such a line means "if a path matches this
glob, this attribute is set (or unset -- if the attribute name
is prefixed with '!'). For glob matching, the same "if the
pattern does not have a slash in it, the basename of the path is
matched with fnmatch(3) against the pattern, otherwise, the path
is matched with the pattern with FNM_PATHNAME" rule as the
exclusion mechanism is used.
This does not define what an attribute means. Tying an
attribute to various effects it has on git operation for paths
that have it will be specified separately.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
git-quiltimport complaining yet still working
config.txt: Fix grammatical error in description of http.noEPSV
config.txt: Change pserver to server in description of gitcvs.*
config.txt: Document core.autocrlf
config.txt: Document gitcvs.allbinary
Do not default to --no-index when given two directories.
Use rev-list --reverse in git-rebase.sh
This series of three patches is a *replacement* for the patch series of
two patches (plus one-liner fixup) I sent yesterday.
It fixes the issue I noted with "git status" incorrectly
claiming that a non-checked out subproject wasn't clean - that
was just a total thinko in the code (we were checking the
filesystem mode against S_IFDIRLNK, which obviously cannot work,
since S_IFDIRLINK is a git-internal state, not a filesystem
state).
It then re-sends the two patches on top of that, with the fix
for checking out superprojects (we should *not* mess up any
existing subproject directories, certainly not remove them - if
we already have a directory in the place where we now want a
subproject, we should leave it well alone!)
The first one really is a fix, and it makes the commit
commentary about a remaining bug in the patch I sent out
yesterday go away.
This actually allows us to check out a supermodule after cloning, although
the submodules themselves will obviously not be checked out, and will just
be empty directories.
Checking out the submodules will be up to higher levels - we may not even
want to!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows us to pack superprojects and thus clone them (but not yet
check them out on the receiving side.. That's the next patch)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code to match up index entries with the filesystem was stupidly
broken. We shouldn't compare the filesystem stat() information with
S_IFDIRLNK, since that's purely a git-internal value, and not what the
filesystem uses (on the filesystem, it's just a regular directory).
Also, don't bother to make the stat() time comparisons etc for DIRLNK
entries in ce_match_stat_basic(), since we do an exact match for these
things, and the hints in the stat data simply doesn't matter.
This fixes "git status" with submodules that haven't been checked out in
the supermodule.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Adds documentation for gitcvs.{dbname,dbdriver,dbuser,dbpass}
Texts are mostly taken from git-cvsserver.txt whith some
adaptions so that they make more sense out of the context
of the original man page.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This actually allows us to check out a supermodule after cloning, although
the submodules will obviously not be checked out, and will just be an
empty subdirectory.
[ Side note: this also shows that we currently don't correctly handle
such subprojects that aren't checked out correctly yet. They should
always show up as not being modified, but failing to resolve the
gitlink HEAD does not properly trigger the "not modified" logic in all
places it needs to..
So more work to be done, but that's a separate issue, unrelated to
the action of checking out the superproject. ]
The bulk of this patch is simply because we need to check the type of the
index entry *before* we try to read the object it points to, and that
meant that the code needed some re-organization. So I moved some of the
code in common to both symlinks and files to be a trivial helper function.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows us to pack superprojects and thus clone them (but not yet
check them out on the receiving side - that's the next patch)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/cherry:
Documentation: --cherry-pick
git-log --cherry-pick A...B
Refactor patch-id filtering out of git-cherry and git-format-patch.
Add %m to '--pretty=format:'
An earlier --subject-prefix patch forgot that format-patch is
not the only codepath that adds the "[PATCH]" prefix, and broke
everybody else in the log family.
Signed-off-by: Junio C Hamano <junkio@cox.net>
By default we are pretty quiet about the actual commands that
we are running. So we should continue to be quiet about the new
merge-subtree hardlink to merge-recursive. Technically this is not
a builtin, but it is close because subtree is actually builtin to
a non-builtin. So lets just make things easy and call it a builtin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When "show_other_directories" is set, that implies that we are looking
for untracked files, which obviously means that we should ignore
directories that are marked as gitlinks in the index.
This fixes "git status" in a superproject, that would otherwise always
report that subprojects were "Untracked files:"
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a note about the branches -> modules mapping to LIMITATIONS because
I really think it should be noted there and not just at the end of
the installation step-by-step HOWTO.
I used "git branches" there and changed "heads" to "branches" in
my section about database configuration. I'm reluctant to replace
all occourences of "head" with "branch" though because you always
have to say "git branch" because CVS also has the concept of
branches. You can say "head" though, because there is no such
concept in CVS. In all the existing occourences of head other than
the one I changed I think "head" flows better in the text.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I finally got around to looking at Alex' patch to teach update-index about
gitlinks too, so that "git commit -a" along with any other explicit
update-index scripts can work.
I don't think there was anything wrong with Alex' patch, but the code he
patched I felt was just so ugly that the added cases just pushed it over
the edge. Especially as I don't think that patch necessarily did the right
thing for a gitlink entry that already existed in the index, but that
wasn't actually a real git repository in the working tree (just an empty
subdirectory or a non-git snapshot because it hadn't wanted to track that
particular subproject).
So I ended up deciding to clean up the git-update-index handling the same
way I tackled the directory traversal used by git-add earlier: by
splitting the different cases up into multiple smaller functions, and just
making the code easier to read (and adding more comments about the
different cases).
So this replaces the old "process_file()" with a new "process_path()"
function that then just calls out to different helper functions depending
on what kind of path it is. Processing a nondirectory ends up being just
one of the simpler cases.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reworded the section about git-cvsserver needing to update the
database.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
CVS allows you to add a removed file (where the
removal is not yet committed) which will
cause the server to send the latest revision of the
file and to delete the "removed" status.
Copy this behaviour.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is meant to be a saner replacement for "git-cherry".
When used with "A...B", this filters out commits whose patch
text has the same patch-id as a commit on the other side. It
would probably most useful to use with --left-right.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This implements the patch-id computation and recording library,
patch-ids.c, and rewrites the get_patch_ids() function used in
cherry and format-patch to use it, so that they do not pollute
the object namespace. Earlier code threw non-objects into the
in-core object database, and hoped for not getting bitten by
SHA-1 collisions. While it may be practically Ok, it still was
an ugly hack.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When used with '--boundary A...B', this shows the -/</> marker
you would get with --left-right option to 'git-log' family.
When symmetric diff is not used, everybody is shown to be on the
"right" branch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This function used to call locate_object_entry_hash() _twice_ per added
object while only once should suffice. Let's reorganize that code a bit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a fairly complete list of tests for various aspects of pack
index versions 1 and 2.
Tests on index v2 include 32-bit and 64-bit offsets, as well as a nice
demonstration of the flawed repacking integrity checks that index
version 2 intend to solve over index version 1 with the per object CRC.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Reliance on /dev/urandom produces test vectors that are, well, random.
This can cause problems impossible to track down when the data is
different from one test invokation to another.
The goal is not to have random data to test, but rather to have a
convenient way to create sets of large files with non compressible and
non deltifiable data in a reproducible way.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* builtin-grep.c (strtoul_ui): Move function definition from here, to...
* git-compat-util.h (strtoul_ui): ...here, with an added "base" parameter.
* builtin-grep.c (cmd_grep): Update use of strtoul_ui to include base, "10".
* builtin-update-index.c (read_index_info): Diagnose an invalid mode integer
that is out of range or merely larger than INT_MAX.
(cmd_update_index): Use strtoul_ui, not sscanf.
* convert-objects.c (write_subdirectory): Likewise.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is the promised cleaned-up version of teaching directory traversal
(ie the "read_directory()" logic) about subprojects. That makes "git add"
understand to add/update subprojects.
It now knows to look at the index file to see if a directory is marked as
a subproject, and use that as information as whether it should be recursed
into or not.
It also generally cleans up the handling of directory entries when
traversing the working tree, by splitting up the decision-making process
into small functions of their own, and adding a fair number of comments.
Finally, it teaches "add_file_to_cache()" that directory names can have
slashes at the end, since the directory traversal adds them to make the
difference between a file and a directory clear (it always did that, but
my previous too-ugly-to-apply subproject patch had a totally different
path for subproject directories and avoided the slash for that case).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add testcase for format-patch --subject-prefix support.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add a new option to git-format-patch, entitled --subject-prefix that allows
control of the subject prefix '[PATCH]'. Using this option, the text 'PATCH' is
replaced with whatever input is provided to the option. This allows easily
generating patches like '[PATCH 2.6.21-rc3]' or properly numbered series like
'[-mm3 PATCH N/M]'. This patch provides the implementation and documentation.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
GIT 1.5.1.1
cvsserver: Fix handling of diappeared files on update
fsck: do not complain on detached HEAD.
(encode_85, decode_85): Mark source buffer pointer as "const".
This fixes a total thinko in my original series: subprojects do *not* sort
like directories, because the index is sorted purely by full pathname, and
since a subproject shows up in the index as a normal NUL-terminated
string, it never has the issues with sorting with the '/' at the end.
So if you have a subproject "proj" and a file "proj.c", the subproject
sorts alphabetically before the file in the index (and must thus also sort
that way in a tree object, since trees sort as the index).
In contrast, it you have two files "proj/file" and "proj.c", the "proj.c"
will sort alphabetically before "proj/file" in the index. The index
itself, of course, does not actually contain an entry "proj/", but in the
*tree* that gets written out, the tree entry "proj" will sort after the
file entry "proj.c", which is the only real magic sorting rule.
In other words: the magic sorting rule only affects tree entries, and
*only* affects tree entries that point to other trees (ie are of the type
S_IFDIR).
Anyway, that thinko just means that we should remove the special case to
make S_ISDIRLNK entries sort like S_ISDIR entries. They don't. They sort
like normal files.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Introduce new configuration variable $default_projects_order
that can be used to specify the default order of projects on
the index page if no 'o' parameter is given.
Allow a new value 'none' for order that will cause the projects
to be in the order we learned about them. In case of reading the
list of projects from a file, this should be the order as they are
listed in the file. In case of reading the list of projects from
a directory this will probably give random results depending on the
filesystem in use.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make it possible to use the forks feature even when
reading the list of projects from a file, by creating
a list of known prefixes as we go. Forks have to be
listed after the main project in order to be recognised
as such.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Acked-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This teaches the really fundamental core SHA1 object handling routines
about gitlinks. We can compare trees with gitlinks in them (although we
can not actually generate patches for them yet - just raw git diffs),
and they show up as commits in "git ls-tree".
We also know to compare gitlinks as if they were directories (ie the
normal "sort as trees" rules apply).
[jc: amended a cut&paste error]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since the subprojects don't necessarily even exist in the current tree,
much less in the current git repository (they are totally independent
repositories), we do not want to try to follow the chain from one git
repository to another through a gitlink.
This involves teaching fsck to ignore references to gitlink objects from
a tree and from the current index.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This just adds the basic helper functions to recognize and work with git
tree entries that are links to other git repositories ("subprojects").
They still aren't actually connected up to any of the code-paths, but
now all the infrastructure is in place.
The next commit will start actually adding actual subproject support.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This new function resolves a ref in *another* git repository. It's
named for its intended use: to look up the git link to a subproject.
It's not actually wired up to anything yet, but we're getting closer to
having fundamental plumbing support for "links" from one git directory
to another, which is the basis of subproject support.
[jc: amended a FILE* leak]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we are fetching from a repository that is on a local
filesystem, first check if we have all the objects that we are
going to fetch available locally, by not just checking the tips
of what we are fetching, but with a full reachability analysis
to our existing refs. In such a case, we do not have to run
git-fetch-pack which would send many needless objects. This is
especially true when the other repository is an alternate of the
current repository (e.g. perhaps the repository was created by
running "git clone -l -s" from there).
The useless objects transferred used to be discarded when they
were expanded by git-unpack-objects called from git-fetch-pack,
but recent git-fetch-pack prefers to keep the data it receives
from the other end without exploding them into loose objects,
resulting in a pack full of duplicated data when fetching from
your own alternate.
This also uses fetch--tool pick-rref on dumb transport side to
remove a shell loop to do the same.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This script helper takes list of fully qualified refnames and
results from ls-remote and grabs only the lines for the named
refs from the latter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
We have fairly extensive coverage of read-tree 3-way machinery,
and many Porcelain-ish tests use git-merge front-end tests, but
we did not have good basic test for merge-recursive, which made
it very hard to hack on it.
I used this during the recent work to teach D/F conflicts to
merge-recursive.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When a path D that originally was blob in the ancestor was
modified on our branch while it was removed on the other branch,
we keep stages 1 and 2, and leave our version in the working
tree. If the other branch created a path D/F, however, that
path can cleanly be resolved in the index (after all, the
ancestor nor we do not have it and only the other side added),
but it cannot be checked out. The issue is the same when the
other branch had D and we had renamed it to D/F, or the ancestor
had D/F instead of D (so there are four combinations).
Do not stop the merge, but leave both D and D/F paths in the
index so that the user can clear things up.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When update-trees::threeway_merge() decides that a path that
exists in the current index (and HEAD) is to be removed, it
leaves a stage 0 entry whose mode bits are set to 0. The code
mistook it as "this stage wants the blob here", and proceeded
to call update_file_flags() which ended up trying to put the
mode=0 entry in the index, got very confused, and ended up
barfing with "do not know what to do with 000000".
Since threeway_merge() does not handle case #10 (one side
removes while the other side does not do anything), this is not
a problem while we refuse to merge branches that have D/F
conflicts, but when we start resolving them, we would need to be
able to remove cache entries, and at that point it starts to
matter.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes three buglets in threeway_merge() regarding D/F
conflict entries.
* After finishing with path D and handling path D/F, some stages
have D/F conflict entry which are obviously non-NULL. For the
purpose of determining if the path D/F is missing in the
ancestor, they should not be taken into account.
* D/F conflict entry is a marker to say "this stage does _not_
have the path", so do not send them to keep_entry().
Signed-off-by: Junio C Hamano <junkio@cox.net>
Case #10 is not handled with unpack-trees.c:threeway_merge()
internally, unless under the agressive rule, and it is not a
bug. As the test expects, ND (one side did not do anything,
other side deleted) case was meant to be handled by the caller's
policy (e.g. git-merge-one-file or git-merge-recursive).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some oneline descriptions are just too long. In shortlog, it looks much
nicer when they are wrapped. Since print_wrapped_text() is UTF-8 aware,
it also works with those descriptions.
[jc: with minimum fixes]
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This replaces the inflate validation with a CRC validation when reusing
data from a pack which uses index version 2. That makes repacking much
safer against corruptions, and it should be a bit faster too.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is necessary for testing the new capabilities in some automated
way without having an actual 4GB+ pack.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Initially the conversion was made using nth_packed_object_sha1() which
made this file completely index version agnostic. Unfortunately the
overhead was quite significant so I went back to raw index walking but
with selectable base and step values which brought back similar
performances as the original.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When index v2 is encountered, the CRC32 of each object is also displayed
in parenthesis at the end of the line.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this patch, packs larger than 4GB are usable, even on a 32-bit machine
(at least on Linux). If off_t is not large enough to deal with a large
pack then die() is called instead of attempting to use the pack and
producing garbage.
This was tested with a 8GB pack specially created for the occasion on
a 32-bit machine.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Like previous patch but for index-pack.
[ There is quite some code duplication between pack-objects and index-pack
for generating a pack index (and fast-import as well I suppose). This
should be reworked into a common function eventually. But not now. ]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Pack index version 2 goes as follows:
- 8 bytes of header with signature and version.
- 256 entries of 4-byte first-level fan-out table.
- Table of sorted 20-byte SHA1 records for each object in pack.
- Table of 4-byte CRC32 entries for raw pack object data.
- Table of 4-byte offset entries for objects in the pack if offset is
representable with 31 bits or less, otherwise it is an index in the next
table with top bit set.
- Table of 8-byte offset entries indexed from previous table for offsets
which are 32 bits or more (optional).
- 20-byte SHA1 checksum of sorted object names.
- 20-byte SHA1 checksum of the above.
The object SHA1 table is all contiguous so future pack format that would
contain this table directly won't require big changes to the code. It is
also tighter for slightly better cache locality when looking up entries.
Support for large packs exceeding 31 bits in size won't impose an index
size bloat for packs within that range that don't need a 64-bit offset.
And because newer objects which are likely to be the most frequently used
are located at the beginning of the pack, they won't pay the 64-bit offset
lookup at run time either even if the pack is large.
Right now an index version 2 is created only when the biggest offset in a
pack reaches 31 bits. It might be a good idea to always use index version
2 eventually to benefit from the CRC32 it contains when reusing pack data
while repacking.
[jc: with the "oops" fix to keep track of the last offset correctly]
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The most important optimization for performance when repacking is the
ability to reuse data from a previous pack as is and bypass any delta
or even SHA1 computation by simply copying the raw data from one pack
to another directly.
The problem with this is that any data corruption within a copied object
would go unnoticed and the new (repacked) pack would be self-consistent
with its own checksum despite containing a corrupted object. This is a
real issue that already happened at least once in the past.
In some attempt to prevent this, we validate the copied data by inflating
it and making sure no error is signaled by zlib. But this is still not
perfect as a significant portion of a pack content is made of object
headers and references to delta base objects which are not deflated and
therefore not validated when repacking actually making the pack data reuse
still not as safe as it could be.
Of course a full SHA1 validation could be performed, but that implies
full data inflating and delta replaying which is extremely costly, which
cost the data reuse optimization was designed to avoid in the first place.
So the best solution to this is simply to store a CRC32 of the raw pack
data for each object in the pack index. This way any object in a pack can
be validated before being copied as is in another pack, including header
and any other non deflated data.
Why CRC32 instead of a faster checksum like Adler32? Quoting Wikipedia:
Jonathan Stone discovered in 2001 that Adler-32 has a weakness for very
short messages. He wrote "Briefly, the problem is that, for very short
packets, Adler32 is guaranteed to give poor coverage of the available
bits. Don't take my word for it, ask Mark Adler. :-)" The problem is
that sum A does not wrap for short messages. The maximum value of A for
a 128-byte message is 32640, which is below the value 65521 used by the
modulo operation. An extended explanation can be found in RFC 3309,
which mandates the use of CRC32 instead of Adler-32 for SCTP, the
Stream Control Transmission Protocol.
In the context of a GIT pack, we have lots of small objects, especially
deltas, which are likely to be quite small and in a size range for which
Adler32 is dimed not to be sufficient. Another advantage of CRC32 is the
possibility for recovery from certain types of small corruptions like
single bit errors which are the most probable type of corruptions.
OK what this patch does is to compute the CRC32 of each object written to
a pack within pack-objects. It is not written to the index yet and it is
obviously not validated when reusing pack data yet either.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Change a few size and offset variables to more appropriate type, then
add overflow tests on those offsets. This prevents any bad data to be
generated/processed if off_t happens to not be large enough to handle
some big packs.
Better be safe than sorry.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch introduces the MSB() macro to obtain the desired number of
most significant bits from a given variable independently of the variable
type.
It is then used to better implement the overflow test on the OBJ_OFS_DELTA
base offset variable with the property of always working correctly
regardless of the type/size of that variable.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The coming index format change doesn't allow for the number of objects
to be determined from the size of the index file directly. Instead, Let's
initialize a field in the packed_git structure with the object count when
the index is validated since the count is always known at that point.
While at it let's reorder some struct packed_git fields to avoid padding
due to needed 64-bit alignment for some of them.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This just makes sure that when we do a read_directory(), we check
that the filename fits in the buffer we allocated (with a bit of
slop)
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The diff helpers used to do the magic mode canonicalization and all the
other special mode handling by hand ("trust executable bit" and "has
symlink support" handling).
That's bogus. Use "ce_mode_from_stat()" that does this all for us.
This is also going to be required when we add support for links to other
git repositories.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As noted by Junio, --format=tar should be assumed if no format
was specified.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/merge-subtree:
A new merge stragety 'subtree'.
It is safe to merge this early as this is a feature that user
explicitly needs to ask for and would not trigger otherwise. A
known issue with the current implementation is that the subtree
matching heuristics is very stupid. It could run ls-tree twice
and try to count intersection.
Giving it wider audience would help it to get improved by
motivated volunteers.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Add Documentation/cmd-list.made to .gitignore
git-svn: fix log command to avoid infinite loop on long commit messages
git-svn: dcommit/rebase confused by patches with git-svn-id: lines
git-svn: bail out on incorrect command-line options
Documents the new configuration variables and the variable
substitution mechanism.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'jc/read-tree-df' (early part):
Fix switching to a branch with D/F when current branch has file D.
Fix twoway_merge that passed d/f conflict marker to merged_entry().
Fix read-tree --prefix=dir/.
unpack-trees: get rid of *indpos parameter.
unpack_trees.c: pass unpack_trees_options structure to keep_entry() as well.
add_cache_entry(): removal of file foo does not conflict with foo/bar
Don't include the scheme name in gitcvs.dbdriver, it is
always 'dbi' anyway.
Don't allow ':' in driver names nor ';' in database names for
sanity reasons.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This merge strategy largely piggy-backs on git-merge-recursive.
When merging trees A and B, if B corresponds to a subtree of A,
B is first adjusted to match the tree structure of A, instead of
reading the trees at the same level. This adjustment is also
done to the common ancestor tree.
If you are pulling updates from git-gui repository into git.git
repository, the root level of the former corresponds to git-gui/
subdirectory of the latter. The tree object of git-gui's toplevel
is wrapped in a fake tree object, whose sole entry has name 'git-gui'
and records object name of the true tree, before being used by
the 3-way merge code.
If you are merging the other way, only the git-gui/ subtree of
git.git is extracted and merged into git-gui's toplevel.
The detection of corresponding subtree is done by comparing the
pathnames and types in the toplevel of the tree.
Heuristics galore! That's the git way ;-).
Signed-off-by: Junio C Hamano <junkio@cox.net>
When pushing into multiple repositories with git push, via
multiple URL in .git/remotes/$shorthand or multiple url
variables in [remote "$shorthand"] section, we used to stop upon
the first failure. Continue the operation and report the
failure at the end.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This came up on #git when somebody was getting 'unable to create
./objects/tmp_oXXXX' but sweared he had write permission to that
directory. It turned out that the repository URL was changed
and he was accessing a repository he does not have a write
permission anymore.
I am not sure how much this would have helped somebody who
believed he was accessing location when the permission of that
location was changed while he was looking the other way, though.
But giving more information on the error path would be better,
and the next change would be helped with this as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/index-output:
git-read-tree --index-output=<file>
_GIT_INDEX_OUTPUT: allow plumbing to output to an alternative index file.
Conflicts:
builtin-apply.c
* cc/bisect:
git-bisect: allow bisecting with only one bad commit.
t6030: add a bit more tests to git-bisect
git-bisect: modernization
Documentation: bisect: "start" accepts one bad and many good commits
Bisect: teach "bisect start" to optionally use one bad and many good revs.
* maint:
Documentation: tighten dependency for git.{html,txt}
Makefile: iconv() on Darwin has the old interface
t5300-pack-object.sh: portability issue using /usr/bin/stat
t3200-branch.sh: small language nit
usermanual.txt: some capitalization nits
Make builtin-branch.c handle the git config file
rename_ref(): only print a warning when config-file update fails
Distinguish branches by more than case in tests.
Avoid composing too long "References" header.
cvsimport: Improve formating consistency
cvsimport: Reorder options in documentation for better understanding
cvsimport: Improve usage error reporting
cvsimport: Improve documentation of CVSROOT and CVS module determination
cvsimport: sync usage lines with existing options
Conflicts:
Documentation/Makefile
This allows you to say:
git bisect start
git bisect bad $bad
git bisect next
to start bisection without knowing a good commit. This would
have you try a commit that is half-way since the beginning of
the history, which is rather wasteful if you already know a good
commit, but if you don't (or your history is short enough that
you do not care), there is no reason not to allow this.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This slightly modernizes the bisect script to use show-ref/for-each-ref
instead of looking into $GIT_DIR/refs files directly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Fix lseek(2) calls with args 2 and 3 swapped
Honor -p<n> when applying git diffs
Fix dependency of common-cmds.h
Fix renaming branch without config file
DESTDIR support for git/contrib/emacs
gitweb: Fix bug in "blobdiff" view for split (e.g. file to symlink) patches
Document --left-right option to rev-list.
Revert "builtin-archive: use RUN_SETUP"
rename contrib/hooks/post-receieve-email to contrib/hooks/post-receive-email.
rerere: make sorting really stable.
Fix t4200-rerere for white-space from "wc -l"
One bad commit is fundamentally needed for bisect to run,
and if we beforehand know more good commits, we can narrow
the bisect space down without doing the whole tree checkout
every time we give good commits.
This patch implements:
git bisect start [<bad> [<good>...]] [--] [<pathspec>...]
as a short-hand for this command sequence:
git bisect start
git bisect bad $bad
git bisect good $good1 $good2...
On the other hand, there may be some confusion between revs
(<bad> and <good>...) and <pathspec>... if -- is not used
and if an invalid rev or a pathspec that looks like a rev is
given.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
GNU make does not include environment variables by default
in its namespace. Just pass them in make command line.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This function was not called "add_file_to_cache()" only because
an ancient program, update-cache, used that name as an internal
function name that does something slightly different. Now that
is gone, we can take over the better name.
The plan is to name all functions that operate on the default
index xxx_cache(). Later patches create a variant of them that
take an explicit parameter xxx_index(), and then turn
xxx_cache() functions into macros that use "the_index".
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is an internal variable used to tell if we need to write
out the resulting index.
I'll be introducing write_index() function which would collide
with it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'd like to consistently name all index-layer functions that
operate on the default index xxx_cache(), and this application
specific function interferes with the plan.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function refresh_cache() is the only user of cache_errno
that switches its behaviour based on what internal function
refresh_cache_entry() finds; pass the error status back in a
parameter passed down to it, to get rid of the global variable
cache_errno.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This error message should not usually trigger, but the function
make_cache_entry() called by add_cacheinfo() can return early
without calling into refresh_cache_entry() that sets cache_errno.
Also the error message had a wrong function name reported, and
it did not say anything about which path failed either.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Previously, a binary file in the diffstat would show as:
some-binary-file.bin | Bin
The space after the "Bin" was never used. This patch changes binary
lines in the diffstat to be:
some-binary-file.bin | Bin 12345 -> 123456 bytes
The very nice "->" notation was suggested by Johannes Schindelin, and
shows the before and after sizes more clearly than "+" and "-" would.
If a size is 0 it's not shown (although it would probably be better to
treat no-file differently from zero-byte-file).
The user can see what changed in the binary file, and how big the new
file is. This is in keeping with the information in the rest of the
diffstat.
The diffstat_t members "added" and "deleted" were unused when the file
was binary, so this patch loads them with the file sizes in
builtin_diffstat(). These figures are then read in show_stats() when
the file is marked binary.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Prior to 1.5.0 the git-lost-found utility was useful to locate
commits that were not referenced by any ref. These were often
amends, or resets, or tips of branches that had been deleted.
Being able to locate a 'lost' commit and recover it by creating a
new branch was a useful feature in those days.
Unfortunately 1.5.0 added the reflogs to the reachability analysis
performed by git-fsck, which means that most commits users would
consider to be lost are still reachable through a reflog. So most
(or all!) commits are reachable, and nothing gets output from
git-lost-found.
Now git-fsck can be told to ignore reflogs during its reachability
analysis, making git-lost-found useful again to locate commits
that are no longer referenced by a ref itself, but may still be
referenced by a reflog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Let's avoid the open coded pack index reference in pack-object and use
nth_packed_object_sha1() instead. This will help encapsulating index
format differences in one place.
And while at it there is no reason to copy SHA1's over and over while a
direct pointer to it in the index will do just fine.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a dialog/window has a default button registered not every
platform associates the return key with that button, but all
users do. We have to register the binding of the return key
ourselves to make sure the user's expectations of pressing
return will activate the default button are met.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Many git-gui messages were broken into a multiple lines to make
good paragraph width. Unfortunately in reality it breaks the paragraph
width completely, because the dialog window width does not coincide
with the paragraph width created by the current font.
Tcl/Tk's standard dialog boxes are breaking the long lines
automatically, so it is better to make long lines and let the
interpreter do the job.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Made the default buttons on the dialog active and focused upon the
dialog appearence.
Bound 'Escape' and 'Return' keys to the dialog dismissal where it
was appropriate: mainly for dialogs with only one button and no
editable fields, but on console output dialogs as well.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Some parts of git-gui were not respecting the default GUI font.
Most of them were catched and fixed.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Makefile got one external option:
- TCLTK_PATH: the path to the Tcl/Tk interpreter.
Users (or build wrappers) may set this variable to the
location of the wish executable.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
"git svn log" is the only command that needs the pass-through
option in Getopt::Long; otherwise we will bail out and let the
user know something is wrong.
Also, avoid printing out unaccepted mixed-case options (that
are reserved for the command-line) such as --useSvmProps
in the usage() function.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ensure that in all references to an element of a hash, the
key is singlequoted, instead of using bareword: use $hash{'key'}
instead of $hash{key}
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Code should be look the same way, regardless of tab size.
Use tabs for indent, but spaces for align.
Indent continued part of command spanning multiple lines, but only once.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This loosens the over-eager verify_absent() check that gets
upset to find directory D in the current working tree when
switching to a branch that has a file there. The check needs to
make sure that we do not lose precious working tree files as a
result of removing directory D and replacing it with the file
from the other branch, which is a tad expensive but this is a
less common case.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When switching from one tree to another, we should not send a
marker that says "this file does not exist in the new tree -- I
am a placeholder to tell you that, and not a real blob" down to
merged_entry() as the result of the merge.
The existing code is not wrong per-se, but it started scanning the index
from a location that does not match the tree being read, and wasted
cycles.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This variable keeps track of which entry in the original index
the traversal is looking at, and belongs to the unpack_trees_options
structure along with other traversal status information.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Other decision functions, deleted_entry() and merged_entry() take one as
their parameter, and this function should. I'll be introducing a separate
index to build the result in, and am planning to pass it as the part of the
structure.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/bisect:
make the previous optimization work also on path-limited rev-list --bisect
rev-list --bisect: Fix "halfway" optimization.
t6004: add a bit more path optimization test.
git-rev-list --bisect: optimization
git-rev-list: add --bisect-vars option.
t6002: minor spelling fix.
* fl/doc:
Documentation: unbreak user-manual.
Documentation: Add version information to man pages
Documentation: Replace @@GIT_VERSION@@ in documentation
* post1.5.1/p4:
Added correct Python path to the RPM specfile.
Remove unused WITH_OWN_SUBPROCESS_PY from RPM spec
Added git-p4 package to the list of git RPMs.
Add the WITH_P4IMPORT knob to the Makefile.
This corrects the interface mistake of the previous one, and
gives a command line parameter to the only plumbing command that
currently needs it: "git-read-tree".
We can add the calls to set_alternate_index_output() to other
plumbing commands that update the index if/when needed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When defined, this allows plumbing commands that update the
index (add, apply, checkout-index, merge-recursive, mv,
read-tree, rm, update-index, and write-tree) to write their
resulting index to an alternative index file while holding a
lock to the original index file. With this, git-commit that
jumps the index does not have to make an extra copy of the index
file, and more importantly, it can do the update while holding
the lock on the index.
However, I think the interface to let an environment variable
specify the output is a mistake, as shown in the documentation.
If a curious user has the environment variable set to something
other than the file GIT_INDEX_FILE points at, almost everything
will break. This should instead be a command line parameter to
tell these plumbing commands to write the result in the named
file, to prevent stupid mistakes.
Signed-off-by: Junio C Hamano <junkio@cox.net>
You cannot currently checkout the tip of an existing branch
without moving to the branch.
This allows you to detach your HEAD and place it at such a
commit, with:
$ git checkout master^0
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not make the checks on the Tcl/Tk interpreter passed by
'--with-tcltk=/path/to/wish' configure option: user is free to pass
anything.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
--with-tcltk=/path/to/wish sets the TCLTK_PATH variable that is
used to substitute the location of the wish interpreter in the
Tcl/Tk programs.
New tracking file, GIT-GUI-VARS, was introduced: it tracks the
location of the Tcl/Tk interpreter and activates the GUI tools
rebuild if the interpreter path was changed. The separate tracker
is better than the GIT-CFLAGS: there is no need to rebuild the whole
git if the interpreter path was changed.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
--with-tcltk enables the search of the Tcl/Tk interpreter. If no
interpreter is found then Tcl/Tk dependend parts are disabled.
--without-tcltk unconditionally disables Tcl/Tk dependent parts.
The original behaviour is not changed: bare './configure' just
installs the Tcl/Tk part doing no checks for the interpreter.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Makefile knob named NO_TCLTK was introduced. It prevents the build
and installation of the Tcl/Tk dependent parts.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
We don't have a copy of subprocess.py anymore, so we removed that
option from the Makefile. Let's not leave that cruft around the RPM
spec file either.
Signed-off-by: Junio C Hamano <junkio@cox.net>
WITH_P4IMPORT: enables the installation of the Perforce import
script.
Signed-off-by: Eygene Ryabinkin <rea-git@codelabs.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I thought it would be cool to have different set of colors for each
git-blame-mode. Function `git-blame-new-commit' does this for us
picking when possible, a random colors based on the set we build on
startup. When it fails, `git-blame-ancient-color' will be used. We
also take care not to use the same color more than once (thank you
David Kågedal, really).
* Prevent (future possible) namespace clash by renaming `color-scale'
into `git-blame-color-scale'. Definition has been changed to be more
in the "lisp" way (thanks for help to #emacs). Also added a small
description of what it does.
* Added docstrings at some point and instructed defvar when a variable
was candidate to customisation by users.
* Added missing defvar to silent byte-compilers (git-blame-file,
git-blame-current)
* Do not require 'cl at startup
* Added more informations on compatibility
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Acked-by: David Kågedal <davidk@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-blame-mode has been splitted into git-blame-mode-on and
git-blame-mode-off; it now conditionnaly calls one of them depending
of how we call it. Code is now easier to maintain and to understand.
Fixed `git-reblame' function: interactive form was at the wrong
place.
String displayed on the mode line is now configurable through
`git-blame-mode-line-string` (default to " blame").
Signed-off-by: Xavier Maillard <zedek@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The way things are set up, you can now pass a "pathspec" to the
"read_directory()" function. If you pass NULL, it acts exactly
like it used to do (read everything). If you pass a non-NULL
pointer, it will simplify it into a "these are the prefixes
without any special characters", and stop any readdir() early if
the path in question doesn't match any of the prefixes.
NOTE! This does *not* obviate the need for the caller to do the *exact*
pathspec match later. It's a first-level filter on "read_directory()", but
it does not do the full pathspec thing. Maybe it should. But in the
meantime, builtin-add.c really does need to do first
read_directory(dir, .., pathspec);
if (pathspec)
prune_directory(dir, pathspec, baselen);
ie the "prune_directory()" part will do the *exact* pathspec pruning,
while the "read_directory()" will use the pathspec just to do some quick
high-level pruning of the directories it will recurse into.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
DBI->table_info is portable across different DBD backends,
DBI->tables is not.
Limit the output to objects of type TABLE.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
The previous one broke generated xml files for anything but manpages,
as it took the header for manpage unconditionally. This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Override the [header] macro of asciidoc's docbook
backend to add version information to the generated
man pages.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Include GIT-VERSION-FILE and replace @@GIT_VERSION@@ in
the HTML and XML asciidoc output. The documentation
doesn't depend on GIT-VERSION-FILE so it will not be
automatically rebuild if nothing else changed.
[jc: fixing the case for interrupted build]
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The trick is to give a child commit that is not tree-changing
the same depth as its parent, so that the depth is propagated
properly along strand of pearls.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you have 5 commits in the set, commits that reach 2 or 3
commits are at halfway. If you have 6 commits, only commits
that reach exactly 3 commits are at halfway. The earlier one is
completely botched the math.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This improves the performance of revision bisection.
The idea is to avoid rather expensive count_distance() function,
which counts the number of commits that are reachable from any
given commit (including itself) in the set. When a commit has
only one relevant parent commit, the number of commits the
commit can reach is exactly the number of commits that the
parent can reach plus one; instead of running count_distance()
on commits that are on straight single strand of pearls, we can
just add one to the parents' count.
On the other hand, for a merge commit, because the commits
reachable from one parent can be reachable from another parent,
you cannot just add the parents' counts up plus one for the
commit itself; that would overcount ancestors that are reachable
from more than one parents.
The algorithm used in the patch runs count_distance() on merge
commits, and uses the util field of commit objects to remember
them. After that, the number of commits reachable from each of
the remaining commits is counted by finding a commit whose count
is not yet known but the count for its (sole) parent is known,
and adding one to the parent's count, until we assign numbers to
everybody.
Another small optimization is whenever we find a half-way commit
(that is, a commit that can reach exactly half of the commits),
we stop giving counts to remaining commits, as we will not find
any better commit than we just found.
The performance to bisect between v1.0.0 and v1.5.0 in git.git
repository was improved by saying good and bad in turns from
3.68 seconds down to 1.26 seconds. Bisecting the kernel between
v2.6.18 and v2.6.20 was sped up from 21.84 seconds down to 4.22
seconds.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds --bisect-vars option to rev-list. The output is suitable
for `eval` in shell and defines five variables:
- bisect_rev is the next revision to test.
- bisect_nr is the expected number of commits to test after
bisect_rev is tested.
- bisect_good is the expected number of commits to test
if bisect_rev turns out to be good.
- bisect_bad is the expected number of commits to test
if bisect_rev turns out to be bad.
- bisect_all is the number of commits we are bisecting right now.
The documentation text was partly stolen from Johannes
Schindelin's patch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently all calls to the database backend make no
error checking or handling at all. At least abort
if the connection to the database failed since
there is really no way we could do anything useful
after that.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make all the different parts of the database backend connection
configurable. This adds the following string configuration variables:
- gitcvs.dbdriver
- gitcvs.dbname
- gitcvs.dbuser
- gitcvs.dbpass
The default values emulate the current behavior exactly for
backwards compatibility.
All configuration variables can also be specified for a specific
access method (i.e. in the form gitcvs.<method>.<var>)
The dbdriver/dbuser/dbpass variables are added for completness.
No other backend than SQLite is tested yet.
The dbname variable on the other hand is useful with this backend
already (to not discriminate against other possible backends
it was not splitted in dbdir and dbfile).
Both dbname and dbuser support dynamic variable substitution where
the available variables are:
%m -- the CVS 'module' (i.e. GIT 'head') worked on
%a -- CVS access method used (i.e. 'ext' or 'pserver')
%u -- User name of the user invoking git-cvsserver
%G -- .git directory name
%g -- .git directory name, mangled to be used in a filename,
currently this substitutes all chars except for [\w.-]
with '_'
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow to override the gitcvs.enabled and gitcvs.logfile configuration
variables for each access method (i.e. "ext" or "pserver") in the
form gitcvs.<method>.<var>
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is intended to be used in the form gitcvs.<method>.<var>
but this patch doesn't introduce any users yet.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
$state->{method} contains the CVS access method used,
either 'ext' or 'pserver'
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The test expects --bisect option can be configured with by setting
$_bisect_option. So let's allow that uniformly.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
