git-gui: Mark revision chooser tooltip for translation
Someone on #git today pointed out that the revision chooser's tooltips
are were being drawn with untranslated strings for the fixed labels we
include, such as "updated", "commit" and "remote". These strings are
now passed through mc to allow them to be localized.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Most of this patch code and message was written by Shawn O. Pearce.
I made some tests to know what the problem was, and then I changed
the code related with the SIGPIPE signal.
If the user has misconfigured `user.signingkey` in their .git/config
or just doesn't have any secret keys on their keyring and they ask
for a signed tag with `git tag -s` we better make sure the resulting
tag was actually signed by gpg.
Prior versions of builtin git-tag allowed this failure to slip
by without error as they were not checking the return value of
the finish_command() so they did not notice when gpg exited with
an error exit status. They also did not fail if gpg produced an
empty output or if read_in_full received an error from the read
system call while trying to read the pipe back from gpg.
Finally, we did not actually honor any return value from the do_sign
function as it returns ssize_t but was being stored into an unsigned
long. This caused the compiler to optimize out the die condition,
allowing git-tag to continue along and create the tag object.
However, when gpg gets a wrong username, it exits before any read was done
and then the writing process receives SIGPIPE and program is terminated.
By ignoring this signal, anyway, the function write_or_die gets EPIPE from
write_in_full and exits returning 0 to the system without a message.
Here we better call to write_in_full directly so we can fail
printing a message and return safely to the caller.
With these issues fixed `git-tag -s` will now fail to create the
tag and will report a non-zero exit status to its caller, thereby
allowing automated helper scripts to detect (and recover from)
failure if gpg is not working properly.
Proposed-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-gui: Trim trailing slashes from untracked submodule names
Oddly enough `git ls-files --others` supplies us the name of an
untracked submodule by including the trailing slash but that
same git version will not accept the name with a trailing slash
through `git update-index --stdin`. Stripping off that final
slash character before loading it into our file lists allows
git-gui to stage changes to submodules just like any other file.
This change should give git-gui users some basic submodule support,
but it is strictly at the plumbing level as we do not actually know
about calling the git-submodule porcelain that is a recent addition
to git 1.5.3.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Assume untracked directories are Git submodules
If `git ls-files --others` returned us the name of a directory then
it is because Git has decided that this directory itself contains a
valid Git repository and its files shouldn't be listed as untracked
for this repository.
In such a case we should label the object as a Git repository and
not just as a directory.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In normal use cases, the performance wins are not overly impressive:
we get something like 5-10% due to the slightly better locality of
memory accesses using the packed structure.
However, since the data structure for index entries saves 33% of
memory on 32-bit platforms and 40% on 64-bit platforms, the behavior
when memory gets limited should be nicer.
This is a rather well-contained change. One obvious improvement would
be sorting the elements in one bucket according to their hash, then
using binary probing to find the elements with the right hash value.
As it stands, the output should be strictly the same as previously
unless one uses the option for limiting the amount of used memory, in
which case the created packs might be better.
Signed-off-by: David Kastrup <dak@gnu.org> Acked-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use the rev-list --parents functionality to read the parents
of the commit. cat-file only shows the raw object with the
original parents and doesn't take into account grafts; so
we'll rely on rev-list machinery for the smarts here.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-diff: don't squelch the new SHA1 in submodule diffs
The code to squelch empty diffs introduced by commit fb13227e089f22dc31a3b1624559153821056848 would inadvertently
populate filespec "two" of a submodule change using the uninitialized
(null) SHA1, thereby replacing the submodule SHA1 by 0{40} in the output.
This change teaches diffcore_skip_stat_unmatch to handle
submodule changes correctly.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
git-gui: Avoid use of libdir in Makefile
git-gui: Disable Tk send in all git-gui sessions
git-gui: lib/index.tcl: handle files with % in the filename properly
Dmitry V. Levin pointed out that on GNU linux libdir is often used
in Makefiles to mean "/usr/lib" or "/usr/lib64", a directory that
is meant to hold platform-specific binary files. Using a different
libdir meaning here in git-gui's Makefile breaks idomatic expressions
like rpm specifile "make libdir=%_libdir".
Originally I asked that the git.git Makefile undefine libdir before
it calls git-gui's own Makefile but it turns out this is very hard
to do, if not impossible. Renaming our libdir to gg_libdir resolves
this case with a minimum amount of fuss on our part.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tk designers blessed us with the "send" command, which on X11
will allow anyone who can connect to your X server to evaluate any
Tcl code they desire within any running Tk process. This is just
plain nuts. If git-gui wants someone running Tcl code within it
then would ask someone to supply that Tcl code to it; waiting for
someone to drop any random Tcl code into us is not fantastic idea.
By renaming send to the empty name the procedure will be removed
from the global namespace and Tk will stop responding to random Tcl
evaluation requests sent through the X server. Since there is no
facility to filter these requests it is unlikely that we will ever
consider enabling this command.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-svn: fix "Malformed network data" with svn:// servers
We have a workaround for the reparent function not working
correctly on the SVN native protocol servers. This workaround
opens a new connection (SVN::Ra object) to the new
URL/directory.
Since libsvn appears limited to only supporting one connection
at a time, this workaround invalidates the Git::SVN::Ra object
that is $self inside gs_fetch_loop_common(). So we need to
restart that connection once all the fetching is done for each
loop iteration to be able to run get_log() successfully.
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pass --whitespace=<option> to git-apply. Since git-apply and git-am
expect this, I'm always surprised when I try to give it to git-rebase
and it doesn't work.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
fast-import: Use strbuf API, and simplify cmd_data()
This patch features the use of strbuf_detach, and prevent the programmer
to mess with allocation directly. The code is as efficent as before, just
more concise and more straightforward.
Simplify strbuf uses in archive-tar.c using strbuf API
This is just cleaner way to deal with strbufs, using its API rather than
reinventing it in the module (e.g. strbuf_append_string is just the plain
strbuf_addstr function, and it was used to perform what strbuf_addch does
anyways).
The gory details are explained in strbuf.h. The change of semantics this
patch enforces is that the embeded buffer has always a '\0' character after
its last byte, to always make it a C-string. The offs-by-one changes are all
related to that very change.
A strbuf can be used to store byte arrays, or as an extended string
library. The `buf' member can be passed to any C legacy string function,
because strbuf operations always ensure there is a terminating \0 at the end
of the buffer, not accounted in the `len' field of the structure.
A strbuf can be used to generate a string/buffer whose final size is not
really known, and then "strbuf_detach" can be used to get the built buffer,
and keep the wrapping "strbuf" structure usable for further work again.
Other interesting feature: strbuf_grow(sb, size) ensure that there is
enough allocated space in `sb' to put `size' new octets of data in the
buffer. It helps avoiding reallocating data for nothing when the problem the
strbuf helps to solve has a known typical size.
Signed-off-by: Pierre Habouzit <madcoder@debian.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This makes git-svn unconditionally invoke git-log with --first-parent when
it is trying to discover its upstream subversion branch and collecting the
commit ids which should be pushed to it with dcommit. The reason for always
using --first-parent is to make git-svn behave in a predictable way when the
ancestry chain contains merges with other git-svn branches.
Since git-svn now always uses 'git-log --first-parent' there is no longer
any need for the --first-parent option to git-svn, so this is removed.
Signed-off-by: Lars Hjemli <hjemli@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
archive: rename attribute specfile to export-subst
As suggested by Junio and Johannes, change the name of the former
attribute specfile to export-subst to indicate its function rather
than purpose and to make clear that it is not applied to working tree
files.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
archive: specfile syntax change: "$Format:%PLCHLDR$" instead of just "%PLCHLDR" (take 2)
As suggested by Johannes, --pretty=format: placeholders in specfiles
need to be wrapped in $Format:...$ now. This syntax change restricts
the expansion of placeholders and makes it easier to use with files
that contain non-placeholder percent signs.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
memmem() is a nice GNU extension for searching a length limited string
in another one.
This compat version is based on the version found in glibc 2.2 (GPL 2);
I only removed the optimization of checking the first char by hand, and
generally tried to keep the code simple. We can add it back if memcmp
shows up high in a profile, but for now I prefer to keep it (almost
trivially) simple.
Since I don't really know which platforms beside those with a glibc
have their own memmem(), I used a heuristic: if NO_STRCASESTR is set,
then NO_MEMMEM is set, too.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This implements a new option "git gc --auto". When gc.auto is
set to a positive value, and the object database has accumulated
roughly that many number of loose objects, this runs a
lightweight version of "git gc". The primary difference from
the full "git gc" is that it does not pass "-a" option to "git
repack", which means we do not try to repack _everything_, but
only repack incrementally. We still do "git prune-packed". The
default threshold is arbitrarily set by yours truly to:
- not trigger it for fully unpacked git v0.99 history;
- do trigger it for fully unpacked git v1.0.0 history;
- not trigger it for incremental update to git v1.0.0 starting
from fully packed git v0.99 history.
This patch does not add invocation of the "auto repacking". It
is left to key Porcelain commands that could produce tons of
loose objects to add a call to "git gc --auto" after they are
done their work.
Merge branch 'master' of git://repo.or.cz/git/git-p4
* 'master' of git://repo.or.cz/git/git-p4:
git-p4: Added support for automatically importing newly appearing perforce branches.
git-p4: Cleanup; moved the (duplicated) code for turning a branch into a git ref (for example foo -> refs/remotes/p4/<project>/foo) into a separate method.
git-p4: Cleanup; moved the code for the initial #head or revision import into a separate function, out of P4Sync.run.
git-p4: Cleanup; Turn self.revision into a function local variable (it's not used anywhere outside the function).
git-p4: Cleanup; moved the code to import a list of p4 changes using fast-import into a separate member function of P4Sync.
git-p4: Cleanup; moved the code for getting a sorted list of p4 changes for a list of given depot paths into a standalone method.
git-p4: After submission to p4 always synchronize from p4 again (into refs/remotes). Whether to rebase HEAD or not is still left as question to the end-user.
git-p4: Always call 'p4 sync ...' before submitting to Perforce.
this is still rough, hence it is disabled by default. You need to compile
with "make THREADED_DELTA_SEARCH=1 ..." at the moment.
Threading is done on different portions of the object list to be
deltified. This is currently done by spliting the list into n parts and
then a thread is spawned for each of them. A better method would consist
of spliting the list into more smaller parts and have the n threads
pick the next part available.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Include a git-push example for creating a remote branch
Cleanup unnecessary file modifications in t1400-update-ref
Makefile: Add cache-tree.h to the headers list
Don't allow contrib/workdir/git-new-workdir to trash existing dirs
git-apply: do not read past the end of buffer
Include a git-push example for creating a remote branch
Many users get confused when `git push origin master:foo` works
when foo already exists on the remote repository but are confused
when foo doesn't exist as a branch and this form does not create
the branch foo.
This new example highlights the trick of including refs/heads/
in front of the desired branch name to create a branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Cleanup unnecessary file modifications in t1400-update-ref
Kristian Høgsberg pointed out that the two file modifications
we were doing during the 'creating initial files' step are not even
used within the test suite. This was actually confusing as we do
not even need these changes for the tests to pass. All that really
matters here is the specific commit dates are used so that these
appear in the branch's reflog, and that the dates are different so
that the branch will update when asked and the reflog entry is
also updated. There is no need for the file modification.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't allow contrib/workdir/git-new-workdir to trash existing dirs
Recently I found that doing a sequence like the following:
git-new-workdir a b
...
git-new-workdir a b
by accident will cause a (and now also b) to have an infinite cycle
in its refs directory. This is caused by git-new-workdir trying
to create the "refs" symlink over again, only during the second
time it is being created within a's refs directory and is now also
pointing back at a's refs.
This causes confusion in git as suddenly branches are named things
like "refs/refs/refs/refs/refs/refs/refs/heads/foo" instead of the
more commonly accepted "refs/heads/foo". Plenty of commands start
to see ambiguous ref names and others just take ages to compute.
git-clone has the same safety check, so git-new-workdir should
behave just like it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
When the preimage we are patching is shorter than what the patch
text expects, we tried to match the buffer contents at the
"original" line with the fragment in full, without checking we
have enough data to match in the preimage. This caused the size
of a later memmove() to wrap around and attempt to scribble
almost the entire address space. Not good.
The code that follows the part this patch touches tries to match
the fragment with line offsets. Curiously, that code does not
have the problem --- it guards against reading past the end of
the preimage.
When git-svn uses git-log to find embedded 'git-svn-id'-lines in commit
messages, it can get confused when local history contains merges with
other git-svn branches. But if --first-parent is supplied to git-log,
working_head_info() will only see 'branch-local' commits and thus the
first commit containing a 'git-svn-id' line should refer to the correct
subversion branch.
Signed-off-by: Lars Hjemli <hjemli@gmail.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
A function intended to be called from builtins updating refs
by locking them before write, specially those that came from
scripts using "git update-ref".
[jc: with minor fixups]
Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitk: Make it possible to lay out all the rows we have received so far
This arranges things so that we can do the layout all the way up to
the last commit that we have received from git log. If we get more
commits we re-lay and redisplay (if necessary) the visible rows.
* maint:
git-gui: Properly set the state of "Stage/Unstage Hunk" action
git-gui: Fix detaching current branch during checkout
git-gui: Correct starting of git-remote to handle -w option
If we have a failure executing msgfmt (such as the process just
crashes no matter what arguments you supply it because its own
installation is borked) we should stop the build process rather
than letting it continue along its merry way as if the .msg files
were created.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Properly set the state of "Stage/Unstage Hunk" action
Today I found yet another way for the "Stage Hunk" and "Unstage
Hunk" context menu actions to leave the wrong state enabled in
the UI. The problem this time was that I connected the state
determination to the value of $::current_diff_side (the side the
diff is from). When the user was last looking at a diff from the
index side and unstages everything the diff panel goes empty, but
the action stayed enabled as we always assumed unstaging was a
valid action.
This change moves the logic for determining when the action is
enabled away from the individual side selection, as they really
are two unrelated concepts.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Fix detaching current branch during checkout
If the user tried to detach their HEAD while keeping the working
directory on the same commit we actually did not completely do
a detach operation internally. The problem was caused by git-gui
not forcing the HEAD symbolic ref to be updated to a SHA-1 hash
when we were not switching revisions. Now we update the HEAD ref
if we aren't currently detached or the hashes don't match.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Correct starting of git-remote to handle -w option
Current versions of git-remote apparently are passing the -w option
to Perl as part of the shbang line:
#!/usr/bin/perl -w
this caused a problem in git-gui and gave the user a Tcl error with
the message: "git-remote not supported: #!/usr/bin/perl -w".
The fix for this is to treat the shbang line as a Tcl list and look
at the first element only for guessing the executable name. Once
we know the executable name we use the remaining elements (if any
exist) as arguments to the executable, before the script filename.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
archive: specfile support (--pretty=format: in archive files)
Add support for a new attribute, specfile. Files marked as being
specfiles are expanded by git-archive when they are written to an
archive. It has no effect on worktree files. The same placeholders
as those for the option --pretty=format: of git-log et al. can be
used.
The attribute is useful for creating auto-updating specfiles. It is
limited by the underlying function format_commit_message(), though.
E.g. currently there is no placeholder for git-describe like output,
and expanded specfiles can't contain NUL bytes. That can be fixed
in format_commit_message() later and will then benefit users of
git-log, too.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Drop the parameter "msg" of format_commit_message() (as it can be
inferred from the parameter "commit"), add a parameter "template"
in order to avoid accessing the static variable user_format
directly and export the result.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-p4: Added support for automatically importing newly appearing perforce branches.
If a change in a p4 "branch" appears that hasn't seen any previous commit and
that has a known branch mapping we now try to import it properly. First we
find the p4 change of the source branch that the new p4 branch is based on. Then
we using git rev-list --bisect to locate the corresponding git commit to that change.
Finally we import all changes in the new p4 branch up to the current change and resume
with the regular import.
git-p4: Cleanup; moved the (duplicated) code for turning a branch into a git ref (for example foo -> refs/remotes/p4/<project>/foo) into a separate method.
git-p4: After submission to p4 always synchronize from p4 again (into refs/remotes). Whether to rebase HEAD or not is still left as question to the end-user.
When using the "--mirror" option to "git remote add", the refs will not
be stored in the refs/remotes/ namespace, but in the same location as
on the remote side.
This option probably only makes sense in a bare repository.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allows username and password to be given using --smtp-user
and --smtp-pass. SSL use is flagged by --smtp-ssl. These are
backed by corresponding defaults in the git configuration file.
This implements Junio's 'mail identity' suggestion in a slightly
more generalised manner. --identity=$identity, backed by
sendemail.identity indicates that the configuration subsection
[sendemail "$identity"] should take priority over the [sendemail]
section for all configuration values.
Signed-off-by: Douglas Stockwell <doug@11011.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
HPA noticed that yum does not like the newer git RPM set; it turns out
that we do not ship git-p4 anymore but existing installations do not
realize the package is gone if we do not tell anything about it.
David Kastrup suggests using Obsoletes in the spec file of the new
RPM to replace the old package, so here is a try.
Dots in a UI string usually mean that a dialog box will
appear waiting for further input. So this patch removes
unneeded dots for actions that do not require user's
input.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Quiet the msgfmt part of the make process
I really prefer having a very short and sweet makefile output that
does not flood the user's screen with a ton of commands that they
don't care much about. Traditionally git-gui has hidden away the
actual commands from output by the $(QUIET*) series of macros but
allow them to be seen with either `make QUIET=` or `make V=1`.
This change makes our i18n message generation process to be a lot
shorter and easier to digest at a glance:
git-gui: Correct stock message for 'Invalid font specified in %s'
This particular message is talking about a specific option in the
configuration file named "gui.$name". This option is not localized
so we cannot localize the "gui." that denotes the section the option
$name is found within. Currently there are no plans to localize the
configuration options for git-gui, but if that were to change in the
future then it would be necessary to localize not only the "gui."
section prefix but also the $name (fontui and fontdiff).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Update po/README as symlink process is not necessary
We don't actually need to create the lib/msgs symlink back to our
po directory in the source tree. git-gui.sh is smart enough to
figure out this is where the msg files are and will load them from
the po directory if invoked as git-gui.sh.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Usually, generated files are not part of the tracked content in
a project. However, translators may lack the tools to generate
git-gui.pot. Besides, it is possible that a contributor does
not even check out the repository, but gets this file via gitweb.
Pointed out by Junio.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The procedure [mc ...] will translate the strings through msgcat.
Strings must be enclosed in quotes, not in braces, because otherwise
xgettext cannot extract them properly, although on the Tcl side both
delimiters would work fine.
[jes: I merged the later patches to that end.]
Signed-off-by: Christian Stimming <stimming@tuhh.de> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is based on Martin Koegler's idea to keep the object that
was successfully used as the base of the delta when it is about
to fall off the edge of the window. Instead of doing so only
for the objects at the edge of the window, this makes the window
a lru eviction mechanism. If an entry is used as a base, it is
moved to the last of the queue to be evicted.
This is a quick-and-dirty implementation, as it keeps the original
implementation of the data structure used for the window. This
originally was done as an array, not as an array of pointers,
because it was meant to be used as a cyclic FIFO buffer and a
plain array avoids an extra pointer indirection, while its FIFOness
eant that we are not "moving" the entries like this patch does.
The runtime from three versions were comparable. It seems to
make the resulting chain even shorter, which can only be good.
git-gui: Initialize Tcl's msgcat library for internationalization
Tcl's msgcat library and corresponding mc procedure can locate a
translated string for any user message, provided that it is first
given a directory where the *.msg files are located containing the
translations.
During installation we will place the translations in lib/msgs/,
so we need to inform msgcat of this location once we determine it
during startup. Our source code tree however will store all of
the translations within the po/ directory, so we need to special
case this variant.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Locate the library directory early during startup
To support a localized version of git-gui we need to locate the
library directory early so we can initialize Tcl's msgcat package
to load translated messages from. This needs to occur before we
declare our git-version proc so that errors related to locating
git or assessing its version can be reported to the end-user in
their preferred language. However we have to keep the library
loading until after git-version has been declared, otherwise we
will fail to start git-gui if we are using a fake tclIndex that
was generated by our Makefile.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>