This test uses a rot13 filter, which is its own inverse. It tested only
that the content was the same as the original after both the 'clean' and
the 'smudge' filter were applied. This way it would not detect whether
any filter was run at all. Hence, here we add another test that checks
that the repository contained content that was processed by the 'clean'
filter.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This gets rid of an explicit fork().
Since upload-pack has to coordinate two processes (rev-list and
pack-objects), we cannot use the normal finish_async(), but have to monitor
the process explicitly. Hence, there are no changes at this front.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This allows us later to use start_async() with this function, and at
the same time is a nice cleanup that makes a long function
(create_pack_file()) shorter.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
We run the sideband demultiplexer in an asynchronous function.
Note that earlier there was a check in the child process that closed
xd[1] only if it was different from xd[0]; this test is no longer needed
because git_connect() always returns two different file descriptors
(see ec587fde0a).
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This adds start_async() and finish_async(), which runs a function
asynchronously. Communication with the caller happens only via pipes.
For this reason, this implementation forks off a child process that runs
the function.
[sp: Style nit fixed by removing unnecessary block on if condition
inside of start_async()]
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This gets rid of an explicit fork/exec.
Since upload-pack has to coordinate two processes (rev-list and
pack-objects), we cannot use the normal finish_command(), but have to
monitor the processes explicitly. Hence, the waitpid() call remains.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This adds another stanza that allocates a pipe that is connected to the
child's stderr and that the caller can read from. In order to request this
pipe, the caller sets cmd->err to -1.
The implementation is not exactly modeled after the stdout case: For stdout
the caller can supply an existing file descriptor, but this facility is
nowhere needed in the stderr case. Additionally, the caller is required to
close cmd->err.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The previous code already used finish_command() to wait for the process
to terminate, but did not use start_command() to run it.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The child process handling is delegated to start_command() and
finish_command().
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This prepares the API of git_connect() and finish_connect() to operate on
a struct child_process. Currently, we just use that object as a placeholder
for the pid that we used to return. A follow-up patch will change the
implementation of git_connect() and finish_connect() to make full use
of the object.
Old code had early-return-on-error checks at the calling sites of
git_connect(), but since git_connect() dies on errors anyway, these checks
were removed.
[sp: Corrected style nit of "conn == NULL" to "!conn"]
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix "can't unset prevlines(...)" Tcl error
gitk: Avoid an error when cherry-picking if HEAD has moved on
gitk: Check that we are running on at least Tcl/Tk 8.4
gitk: Do not pick up file names of "copy from" lines
gitk: Add support for OS X mouse wheel
gitk: disable colours when calling git log
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Don't display CR within console windows
git-gui: Handle progress bars from newer gits
git-gui: Correctly report failures from git-write-tree
git-gui: accept versions containing text annotations, like 1.5.3.mingw.1
git-gui: Don't crash when starting gitk from a browser session
git-gui: Allow gitk to be started on Cygwin with native Tcl/Tk
git-gui: Ensure .git/info/exclude is honored in Cygwin workdirs
git-gui: Handle starting on mapped shares under Cygwin
git-gui: Display message box when we cannot find git in $PATH
git-gui: Avoid using bold text in entire gui for some fonts
This fixes the error reported by Michele Ballabio, where gitk will
throw a Tcl error "can't unset prevlines(...)" when displaying a
commit that has a parent commit listed more than once, and the commit
is the first child of that parent.
The problem was basically that we had two variables, prevlines and
lineends, and were relying on the invariant that prevlines($id) was
set iff $id was in the lineends($r) list for some $r. But having
a duplicate parent breaks that invariant since we end up with the
parent listed twice in lineends.
This fixes it by simplifying the logic to use only a single variable,
lineend. It also rearranges things a little so that we don't try to
draw the line for the duplicated parent twice.
Signed-off-by: Paul Mackerras <paulus@samba.org>
Solaris 9 doesn't have mkdtemp() so we need to emulate it for the
rsync transport implementation. Since Solaris 9 is lacking this
function we can also reasonably assume it is not available on
Solaris 8 either. The new Makfile definition NO_MKDTEMP can be
set to enable the git compat version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is already logic in the git wrapper to deduce the exec_path from
argv[0], when the git wrapper was called with an absolute path. Extend
that logic to handle relative paths as well.
For example, when you call "../../hello/world/git", it will not turn
"../../hello/world" into an absolute path, and use that.
Initial implementation by Scott R Parish.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
receive-pack is only executed remotely so when
reporting errors, say so.
Signed-off-by: Joakim Tjernlund <Joakim.Tjernlund@transmode.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The arguments to the "Not a blob" die call in file_change_m were
transposed, so that the command was printed as the type, and the type
as the command. Switch them around so that the error message comes
out correctly.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git progress bars from tools like git-push and git-fetch use CR
to skip back to the start of the current line and redraw it with
an updated progress. We were doing this in our Tk widget but had
failed to skip the CR, which Tk doesn't draw well.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Post Git 1.5.3 a new style progress bar has been introduced that
uses only one line rather than two. The formatting of the completed
and total section is also slightly different so we must adjust our
regexp to match. Unfortunately both styles are in active use by
different versions of Git so we need to look for both.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The current git-p4 implementation does support file renames. However, because
it does not use the "p4 integrate" command, the history for the renamed file is
not linked to the new file.
This changeset adds support for perforce renames with the integrate command.
Currently this feature is only enabled when calling git-p4 submit with the -M
option. This is intended to look and behave similar to the "detect renames"
feature of other git commands.
The following sequence is used for renamed files:
p4 integrate -Dt x x'
p4 edit x'
rm x'
git apply
p4 delete x
By default, perforce will not allow an integration with a target file that has
been deleted. That is, if x' in the example above is the name of a previously
deleted file then perforce will fail the integrate. The -Dt option tells
perforce to allow the target of integrate to be a previously deleted file.
Signed-off-by: Chris Pettitt <cpettitt@gmail.com>
Signed-off-by: Simon Hausmann <simon@lst.de>
This fixes an error reported by Adam Piątyszek: if the current HEAD
is not in the graph that gitk knows about when we do a cherry-pick
using gitk, then gitk hits an error when trying to update its
internal representation of the topology. This avoids the error by
not doing that update if the HEAD before the cherry-pick was a
commit that gitk doesn't know about.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This checks that we have Tcl/Tk 8.4 or later, and puts up an error
message in a window and quits if not.
This was prompted by a patch submitted by Steffen Prohaska, but is
done a bit differently (this uses package require rather than
looking at [info tclversion], and uses show_error to display the
error rather than printing it to stderr).
Signed-off-by: Paul Mackerras <paulus@samba.org>
If git-write-tree fails (such as if the index file is currently
locked and it wants to write to it) we were not getting the error
message as $tree_id was always the empty string so we shortcut
through the catch and never got the output from stderr.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
For the manpage, avoid generating an em dash in code.
Signed-off-by: Ralf Wildenhues <Ralf.Wildenhues@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
A file copy would be detected only if the original file was modified in the
same commit. This implies that there will be a patch listed under the
original file name, and we would expect that clicking the original file
name in the file list warps the patch window to that file's patch. (If the
original file was not modified, the copy would not be detected in the first
place, the copied file would be listed as "new file", and this whole matter
would not apply.)
However, if the name of the copy is sorted after the original file's patch,
then the logic introduced by commit d1cb298b0b (which picks up the link
information from the "copy from" line) would overwrite the link
information that is already present for the original file name, which was
parsed earlier. Hence, this patch reverts part of said commit.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
(Väinö Järvelä supplied this patch a while ago for 1.5.2. It no longer
applied cleanly, so I'm reposting it.)
MacBook doesn't seem to recognize MouseRelease-4 and -5 events, at all.
So i added a support for the MouseWheel event, which i limited to Tcl/tk
aqua, as i couldn't test it neither on Linux or Windows. Tcl/tk needs to
be updated from the version that is shipped with OS X 10.4 Tiger, for
this patch to work.
Signed-off-by: Jonathan del Strother <jon.delStrother@bestbefore.tv>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When matching source and destination refs, we were failing
to pull the 'force' parameter from wildcard refspecs (but
not explicit ones) and attach it to the ref struct.
This adds a test for explicit and wildcard refspecs; the
latter fails without this patch.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The logic in stopfinding assumes that findcurline will be set if
find_dirn is, but findnext and findprev can set find_dirn without
setting findcurline. This makes sure we only set find_dirn in those
places if findcurline is already set.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This is the same bug as 42a32174b6.
The warning "Object $X is a tree, not a commit" is bogus and is
not relevant here. If its not a commit we just need to make sure
we don't mark it for merge as we fill out FETCH_HEAD.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In 89d750bf6f I got a little too
aggressive with changing "git diff" to "git diff-tree". This is
shown to the user, who expects to see a full diff on their console,
and will want to see the output of their custom diff drivers (if
any) as the whole point of this call site is to show the diff to
the end-user.
Noticed by Johannes Sixt <j.sixt@viscovery.net>.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
Further 1.5.3.5 fixes described in release notes
Avoid invoking diff drivers during git-stash
attr: fix segfault in gitattributes parsing code
Define NI_MAXSERV if not defined by operating system
Ensure we add directories in the correct order
Avoid scary errors about tagged trees/blobs during git-fetch
Discussion on the list tonight came to the conclusion that showing
the name of the packfile we just created during git-repack is not
a very useful message for any end-user. For the really technical
folk who need to have the name of the newest packfile they can use
something such as `ls -t .git/objects/pack | head -2` to find the
most recently created packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Rather than reimplementing the progress meter logic and always
showing 100 lines of output while pruning already packed objects
we now use a delayed progress meter and only show it if there are
enough objects to make us take a little while.
Most users won't see the message anymore as it usually doesn't take
very long to delete the already packed loose objects. This neatens
the output of a git-gc or git-repack execution, which is especially
important for a `git gc --auto` triggered from within another
command.
We perform the display_progress() call from within the very innermost
loop in case we spend more than 1 second within any single object
directory. This ensures that a progress_update event from the
timer will still trigger in a timely fashion and allow the user to
see the progress meter.
While I'm in here I changed the message to be more descriptive of
its actual task. "Removing unused objects" is a little scary for
new users as they wonder where these unused objects came from and
how they should avoid them. Truth is these objects aren't unused
in the sense of what git-prune would call a dangling object, these
are used but are just duplicates of things we have already stored
in a packfile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Recently I was referred to the Grammar Police as the git-pack-objects
progress message 'Deltifying %u objects' is considered to be not
proper English to at least some small but vocal segment of the
English speaking population. Techncially we are applying delta
compression to these objects at this stage, so the new term is
slightly more acceptable to the Grammar Police but is also just
as correct.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This patch tries to make the description of --auto a little
more clear for new users, especially those referred by the
"git-gc --auto" notification message.
It also cleans up some grammatical errors and typos in the
original description, as well as rewording for clarity.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that git-gc --auto tells the user to look at the man
page, it makes sense to mention the auto behavior near the
top (since this is likely to be most users' first exposure
to git-gc).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The previous message had too much of a "boy, you should
really turn off this annoying gc" flair to it. Instead,
let's make sure the user understands what is happening, that
they can run it themselves, and where to find more info.
Suggested by Brian Gernhardt.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-stash needs to restrict itself to plumbing when running automated
diffs as part of its operation as the user may have configured a
custom diff driver that opens an interactive UI for certain/all
files. Doing that during scripted actions is very unfriendly to
the end-user and may cause git-stash to fail to work.
Reported by Johannes Sixt
Acked-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git may segfault if gitattributes contains an invalid
entry. A test is added to t0020 that triggers the segfault.
The parsing code is fixed to avoid the crash.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I found I needed NI_MAXSERV as it is defined in netdb.h, which is
not included by daemon.c. Rather than including the whole header
we can define a reasonable fallback value.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
CVS gets understandably upset if you try and add a subdirectory
before it's parent directory. This patch fixes that.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Ok, what is going on is:
- append_fetch_head() looks up the SHA1 for all heads (including tags):
if (get_sha1(head, sha1))
return error("Not a valid object name: %s", head);
- it then wants to check if it's a candidate for merging (because
fetching also does the whole "list which heads to merge" in case
it is going to be part of a "pull"):
commit = lookup_commit_reference(sha1);
if (!commit)
not_for_merge = 1;
- and that "lookup_commit_reference()" is just very vocal about the
case where it fails. It really shouldn't be, and it shouldn't
affect the actual end result, but that basically explains why
you get that scary warning.
In short, the warning is just bogus, and should be harmless, but
I agree that it's ugly. I think the appended patch should fix it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
