* 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>
git-diff: resurrect the traditional empty "diff --git" behaviour
The warning message to suggest "Consider running git-status" from
"git-diff" that we experimented with during the 1.5.3 cycle turns
out to be a bad idea. It robbed cache-dirty information from people
who valued it, while still asking users to run "update-index --refresh".
It was hoped that the new behaviour would at least have some educational
value, but not showing the cache-dirty paths like before meant that the
user would not even know easily which paths were cache-dirty, and it
made the need to refresh the index look like even more unnecessary chore.
This commit reinstates the traditional behaviour, but with a twist.
By default, the empty "diff --git" output is totally squelched out
from "git diff" output. At the end of the command, it automatically
runs "update-index --refresh" as needed, without even bothering the
user. In other words, people who do not care about the cache-dirtyness
do not even have to see the warning.
The traditional behaviour to see the stat-dirty output and to bypassing
the overhead of content comparison can be specified by setting the
configuration variable diff.autorefreshindex to false.
git-tag: Fix -l option to use better shell style globs.
This patch removes certain behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring. The same
thing now could be achieved doing "git tag -l '*foo*'".
This feature was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.
Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substring*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.
Tests for "git tag" were also changed to reflect this.
Signed-off-by: Carlos Rica <jasampler@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-svn: fix dcommit clobbering upstream when committing multiple changes
Although dcommit could detect if the first commit in the series
would conflict with the HEAD revision in SVN, it could not
detect conflicts in further commits it made.
Now we rebase each uncommitted change after each revision is
committed to SVN to ensure that we are up-to-date. git-rebase
will bail out on conflict errors if our next change cannot be
applied and committed to SVN cleanly, preventing accidental
clobbering of changes on the SVN-side.
--no-rebase users will have trouble with this, and are thus
warned if they are committing more than one commit. Fixing this
for (hopefully uncommon) --no-rebase users would be more complex
and will probably happen at a later date.
Thanks to David Watson for finding this and the original test.
If the configuration of the user has "diff.color = true", the
output from "log" we invoke internally added color codes, which
broke the parser.
Signed-off-by: Junio C Hamano <gitster@pobox.com> Tested-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Acked-by: Eric Wong <normalperson@yhbt.net>
filter-branch: introduce convenience function "skip_commit"
With this function, a commit filter can leave out unwanted commits
(such as temporary commits). It does _not_ undo the changeset
corresponding to that commit, but it _skips_ the revision. IOW
no tree object is changed by this.
If you like to commit early and often, but want to filter out all
intermediate commits, marked by "@@@" in the commit message, you can
now do this with
filter-branch: fix remnants of old syntax in documentation
Some time ago, filter-branch's syntax changed so that more than one
ref can be rewritten at the same time. This involved the removal of
the ref name for the result; instead, the refs are rewritten in-place.
This updates the last leftovers in the documentation to reflect the
new behavior.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lately I have been doing a lot of calls to `git tag -d` and also to
`git tag -v`. In both such cases being able to complete the names
of existing tags saves the fingers some typing effort. We now look
for the -d or -v option to git-tag in the bash completion support
and offer up existing tag names as possible choices for these.
When creating a new tag we now also offer bash completion support
for the second argument to git-tag (the object to be tagged) as this
can often be a specific existing branch name and is not necessarily
the current HEAD.
If the -f option is being used to recreate an existing tag we now
also offer completion support on the existing tag names for the
first argument of git-tag, helping to the user to reselect the
prior tag name that they are trying to replace.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Make "git-log --" without paths behave the same as "git-log" without --
"git log" family of commands, even when run from a subdirectory,
do not limit the revision range with the current directory as
the path limiter, but with double-dash without any paths after
it, i.e. "git log --" do so. It was a mistake to have a
difference between "git log --" and "git log" introduced in
commit ae563542bf10fa8c33abd2a354e4b28aca4264d7 (First cut at
libifying revlist generation).
When appending the "git-archimport-id:" line to the end of log entries,
git-archimport would use two blank lines as a separator when there was no
body in the arch log (only a Summary: line), and zero blank lines when there
was a body (making it hard to see the break between the actual log message
and the git-archimport-id: line).
This patch makes git-archimport generate one blank line as a separator in all
cases.
The code favoring shallower deltas when size is equal was triggered
only when previous delta was also cached. There should be no relation
between cached deltas and same sized deltas.
Signed-off-by: Nicolas Pitre <nico@cam.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds code to write out the topology information used to determine
precedes/follows and branch information into a cache file (~3.5MB for
the kernel tree). At startup we read the cache file and then do a
git rev-list to update it, which is fast because we exclude all commits
in the cache that have no children and commits reachable from them
(which amounts to everything in the cache). If one of those commits
without children no longer exists, then git rev-list will give an error,
whereupon we throw away the cache and read in the whole tree again.
This gives a significant speedup in the startup time for gitk.
gitk: Fix bug causing undefined variable error when cherry-picking
When "Show nearby tags" is turned off and the user did a cherry-pick,
we were trying to access variables relating to the descendent/ancestor
tag & head computations in addnewchild though they hadn't been set.
This makes sure we don't do that. Reported by Johannes Sixt.
gitk: Fix bug causing undefined variable error when cherry-picking
When "Show nearby tags" is turned off and the user did a cherry-pick,
we were trying to access variables relating to the descendent/ancestor
tag & head computations in addnewchild though they hadn't been set.
This makes sure we don't do that. Reported by Johannes Sixt.
gitk: Do only the parts of the layout that are needed
This changes layoutrows and optimize_rows to make it possible to lay
out only a little bit more of the graph than is visible, rather than
having to lay out the whole graph from top to bottom. To lay out
some of the graph without starting at the top, we use the new make_idlist
procedure for the first row, then lay it out proceeding downwards
as before. Empty list elements in rowidlist are used to denote rows
that haven't been laid out yet.
Optimizing happens much as before except that we don't try to optimize
unless we have three consecutive rows laid out (or the top 2 rows).
We have a new list, rowisopt, to record which rows have been optimized.
If we change a row that has already been drawn, we set a flag which
causes drawcommits to throw away everything drawn on the canvas and redraw
the visible rows.
git-add: Make the "tried to add ignored file" error message less confusing
Currently the error message seems to imply (at least to me) that only
the listed files were withheld and the rest of the files was added to the
index, even though that's obviously not the case.
Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>
gitweb: Fix escaping HTML of project owner in 'projects_list' and
'summary' views
This for example allows to put email address in the project owner
field in the projects index file (when $projects_list points to
a file, and not to a directory), in the form of:
Noticed-by: Jon Smirl <jonsmirl@gmail.com> Signed-off-by: Jakub Narebski <jnareb@gmail.com> Signed-off-by: Petr Baudis <pasky@suse.cz> Signed-off-by: Junio C Hamano <gitster@pobox.com>