Added simple descriptions of these options (based on description of --all).
Signed-off-by: Mark Burton <markb@ordern.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In case the length of branch name is greather then PATH_MAX-11, we write
to unallocated memory otherwise.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This is just about using the API, though in case of ~ 10^100 commits,
this would fix the problem of writing to unallocated memory as well. ;-)
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In case the length of branch name is greather then PATH_MAX-7, we write
to unallocated memory otherwise.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pass the verbose mode parameter to the underlying fetch command.
$ ./git remote -v update
Updating origin
From git://git.kernel.org/pub/scm/git/git
= [up to date] html -> origin/html
= [up to date] maint -> origin/maint
= [up to date] man -> origin/man
= [up to date] master -> origin/master
= [up to date] next -> origin/next
= [up to date] pu -> origin/pu
= [up to date] todo -> origin/todo
Signed-off-by: Cheng Renquan <crquan@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Currently, if you invoke the "diff this -> selected" or "diff selected
-> this" and gitk is in "Tree" mode rather than "Patch" mode, the
diff display pane will just show the header but not the actual diff,
unless gitk has done the diff before and thus has the list of files
that differ. This was because the logic in gettreediffline that
checked whether we had moved on to doing something else checked the
mode (Tree or Patch) before checking whether the ids we're diffing
had changed.
This fixes it. The new logic in gettreediffline is slightly hacky
and relies on the fact that the Tree/Patch mode only applies when
we're looking at a single commit, not at the diff between two commits.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This reverts commit 63767d5fb8.
A similar change was made as part of commit 76f15947af, that added
bindings to all dialogs, and this duplication causes mkbrgo to be
called twice, the second time after the window has been destroyed.
As a result, an error window appears when the code tries to access
widgets.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Since gitk looks for the HEAD commit to attach the fake commits for
local changes to, we can miss out on seeing the fake commits if we
have a path limit and the HEAD commit doesn't alter any of the files
in the path limit.
This fixes it by running
git rev-list -1 $head -- $paths
if we have a path limit, and taking the result of that as the commit
to attach the fake commits to. This means that we can be attaching
the fake commits to a different commit in each view, so we use a new
$viewmainhead($view) for that.
This also fixes a buglet where updatecommits would only fix up the
fake commits if the HEAD changed since the last call to updatecommits,
whereas it should fix them up if the HEAD has changed since this view
was last created or updated.
Signed-off-by: Paul Mackerras <paulus@samba.org>
In Tcl, a comment in a switch command where a pattern would be expected
doesn't do what one would expect, so this moves the comments inside the
actions. Doing that shows up an extra "-" which this also removes.
With this, --merge is now handled properly.
Signed-off-by: Paul Mackerras <paulus@samba.org>
In the threaded index preloading case, we must be sure to always use the
CE_MATCH_RACY_IS_DIRTY flag when calling ie_match_stat(), in order to make
sure that we only ever look at the stat() data, and don't try to do
anything fancy.
Because most of git internals are not thread-safe, and must not be called
in parallel.
Otherwise, what happens is that if the timestamps indicate that an entry
_might_ be dirty, we might start actually comparing filesystem data with
the object database. And we mustn't do that, because that would involve
looking up and creating the object structure, and that whole code sequence
with read_sha1_file() where we look up and add objects to the hashes is
definitely not thread-safe.
Nor do we want to add locking, because the whole point of the preload was
to be simple and not affect anything else. With CE_MATCH_RACY_IS_DIRTY, we
get what we wanted, and we'll just leave the hard cases well alone, to be
done later in the much simpler serial case.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Also add a few links to git-help(1) in "See also" sections.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Talking about "git help" is useful because it has a few more
features (like when using it without arguments or with "-a") and
it may work on non unix like platforms.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We know that the string pointed at by remote->name won't change. It can
be borrowed as the key in the string_list without copying. Other parts of
existing code such as get_one_entry() already rely on this fact.
Noticed by Cheng Renquan.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The usage string of 'git request-pull' differs from he manpage
which gives the correct 'synopsis'.
Signed-off-by: Stefan Naewe <stefan.naewe@atlas-elektronik.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://repo.or.cz/git-gui:
git-gui: Fix the search bar destruction handler.
Update the po template
git-gui: Implement automatic rescan after Tool execution.
git-gui: Allow Tools request arguments from the user.
git-gui: Add a Tools menu for arbitrary commands.
git-gui: Fix the after callback execution in rescan.
git-gui: Implement system-wide configuration handling.
git-gui: try to provide a window icon under X
Since delete_this is an ordinary function, it
should not be passed to cb; otherwise it produces
errors when blame windows are closed. Unfortunately,
it is not noticeable when blame is shown in the
master window, so I missed this bug.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Tools menu is generally intended for commands that
affect the working directory or repository state. Thus,
the user would usually want to initiate rescan after
execution of a tool. This commit implements it.
In case somebody would want to avoid rescanning after
certain tools, it also adds an option that controls it,
although it is not made available through the Add dialog.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
While static commands are already useful, some tools need
additional parameters to reach maximum usability. This
commit adds support for passing them one revision name
parameter, and one arbitrary string. With this addition,
the tools menu becomes flexible enough to implement basic
rebase support:
[core]
editor = kwrite
[guitool "Rebase/Abort"]
cmd = git rebase --abort
confirm = yes
[guitool "Rebase/Continue"]
cmd = git rebase --continue
[guitool "Rebase/Skip Commit"]
cmd = git rebase --skip
confirm = yes
[guitool "Rebase/Start..."]
cmd = git rebase $ARGS $REVISION $CUR_BRANCH
title = Start Rebase
prompt = Rebase Current Branch
argprompt = Flags
revprompt = New Base
revunmerged = yes
Some of the options, like title or prompt, are intentionally
not included in the Add dialog to avoid clutter. Also, the
dialog handles argprompt and revprompt as boolean vars.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Due to the emphasis on scriptability in the git
design, it is impossible to provide 100% complete
GUI. Currently unaccounted areas include git-svn
and other source control system interfaces, TopGit,
all custom scripts.
This problem can be mitigated by providing basic
customization capabilities in Git Gui. This commit
adds a new Tools menu, which can be configured
to contain items invoking arbitrary shell commands.
The interface is powerful enough to allow calling
both batch text programs like git-svn, and GUI editors.
To support the latter use, the commands have access
to the name of the currently selected file through
the environment.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The rescan function receives a callback command
as its parameter, which is supposed to be executed
after the scan finishes. It is generally used to
update status. However, rescan may initiate a
loading of a diff, which always calls ui_ready after
completion. If the after handler is called before
that, ui_ready will override the new status.
This commit ensures that the after callback is
properly threaded through the diff machinery.
Since it uncovered the fact that force_first_diff
actually didn't work due to an undeclared global
variable, and the desired effects appeared only
because of the race condition between the diff
system and the rescan callback, I also reimplement
this function to make it behave as originally
intended.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
With the old implementation any system-wide options appear
to be set locally in the current repository. This commit
adds explicit handling of system options, essentially
interpreting them as customized default_config.
The difficulty in interpreting system options stems from
the fact that simple 'git config' lists all values, while
'git config --global' only values set in ~/.gitconfig,
excluding both local and system options.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When running under X, we try to set up a window icon by providing a
hand-crafted 16x16 Tk photo image equivalent to the .ico. Wrap in a
catch because the earlier Tcl/Tk 8.4 releases didn't provide the 'wm
iconphoto' command.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The space between the commit and the source attribute is not easily
machine-parseable: if we combine --source with --parents and give a SHA1
as a starting point, it's unnecessarily hard to see where the list of
parents ends and the source decoration begins.
Example:
git show --parents --source $(git rev-list HEAD)
which is admittedly contrived, but can easily happen in scripting.
So use a <tab> instead of a space as the source separator.
The other decorations didn't have this issue, because they were surrounded
by parenthesis, so it's obvious that they aren't parent SHA1's.
It so happens that _visually_ this makes no difference for "git log
--source", since "commit <40-char SHA1>" is 47 characters, so both a space
and a <tab> will end up showing as a single commit. Of course, with
'--pretty=oneline' or '--parents' or '--abbrev-commit' you'll see the
difference.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally --with-tree=<tree> was designed for the sole purpose of
checking if a given pathspec makes sense as a parameter to git-commit
using it in conjunction with --error-unmatch. It had logic to avoid
showing the same entry (one came from the original index, another from the
overlayed tree) twice so that it works with -c (i.e. "show-cached"), but
otherwise it was not designed to work with the flags such as -m, -d, etc.
This teaches the same logic to cover the codepath for -m and -d.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Documentation: git-svn: fix example for centralized SVN clone
Documentation: fix links to "everyday.html"
revision.c: use proper data type in call to sizeof() within xrealloc
The example that tells users how to centralize the effort of the initial
git svn clone operation doesn't work properly. It uses rebase but that
only works if HEAD exists. This adds one extra command to create a
somewhat sensible HEAD that should work in all cases.
Signed-off-by: Jan Krüger <jk@jk.gs>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In some places the links are wrong. They should be:
"link:everyday.html", instead of: "linkgit:everyday[7]".
This patch fixes that.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The -A option calls pack-objects with the --unpack-unreachable option so
that the unreachable objects in local packs are left in the local object
store loose. But if the -d option to repack was _not_ used, then these
unpacked loose objects are redundant and unnecessary.
Update tests in t7701.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add information on new git-gui and gitk command-line options,
configuration variables, and the encoding attribute.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This simplifies things a bit and is better because ids are stable
but row numbers aren't. It also means we can avoid one [rowofcommit]
call.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This can do the lstat() storm in parallel, giving potentially much
improved performance for cold-cache cases or things like NFS that have
weak metadata caching.
Just use "read_cache_preload()" instead of "read_cache()" to force an
optimistic preload of the index stat data. The function takes a
pathspec as its argument, allowing us to preload only the relevant
portion of the index.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Implement git-pull --quiet and git-pull --verbose by
adding the options to git-pull and fixing verbosity
handling in git-fetch.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git://git.bogomips.org/git-svn:
git-svn: Update git-svn to use the ability to place temporary files within repository directory
Git.pm: Make _temp_cache use the repository directory
git-svn: proper detection of bare repositories
git-svn: respect i18n.commitencoding config
git-svn: don't escape tilde ('~') for http(s) URLs
This fixes git-svn within msys where Perl will provide temporary files with path
such as /tmp while the git suit expects native Windows paths.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
Update the usage of File::Temp->tempfile to place the temporary files
within the repository directory instead of just letting Perl decide what
directory to use, given there is a repository specified when requesting
the temporary file.
This is needed to be able to fix git-svn on msys as msysperl generates
paths with UNIX-style paths (/tmp/xxx) while the git tools expect natvie
path format (c:/..). The repository dir is stored in native format so by
using it as the base directory for temporary files we always get a
usable native full path.
Signed-off-by: Marten Svanfeldt <developer@svanfeldt.com>
Acked-by: Eric Wong <normalperson@yhbt.net>
When in a bare repository (or .git, for that matter), git-svn would fail
to initialise properly, since git rev-parse --show-cdup would not output
anything. However, git rev-parse --show-cdup actually returns an error
code if it's really not in a git directory.
Fix the issue by checking for an explicit error from git rev-parse, and
setting $git_dir appropriately if instead it just does not output.
Signed-off-by: Deskin Miller <deskinm@umich.edu>
Acked-by: Eric Wong <normalperson@yhbt.net>
SVN itself always stores log messages in the repository as
UTF-8. git always stores/retrieves everything as raw binary
data with no transformations whatsoever.
To interact with SVN, we need to encode log messages as UTF-8
before sending them to SVN, as SVN cannot do it for us. When
retrieving log messages from SVN, we also need to (attempt to)
reencode the UTF-8 log message back to the user-specified commit
encoding.
Note, handling i18n.logoutputencoding for "git svn log" also
needs to be done in a future change.
Also, this change only deals with the encoding of commit
messages and nothing else (path names, blob content, ...).
In-Reply-To: <8b168cfb0810282014r789ac01dnec51824de1078f0@mail.gmail.com>
James North <tocapicha@gmail.com> wrote:
> Hi,
>
> I'm using git-svn on a system with ISO-8859-1 encoding. The problem is
> when I try to use "git svn dcommit" to send changes to a remote svn
> (also ISO-8859-1).
>
> Seems like git-svn is sending commit messages with utf-8 (just a
> guessing...) and they look bad on the remote svn log. E.g. "Ca?\241a
> de cami?\243n"
>
> I have tried using i18n.commitencoding=ISO-8859-1 as suggested by the
> warning when doing "git svn dcommit" but messages still are sent with
> wrong encoding.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Thanks to Jose Carlos Garcia Sogo and Björn Steinbrink for the
bug report.
On 2008.10.18 23:39:19 +0200, Björn Steinbrink wrote:
> Hi,
>
> Jose Carlos Garcia Sogo reported on #git that a git-svn clone of this
> svn repo fails for him:
> https://sucs.org/~welshbyte/svn/backuptool/trunk
>
> I can reproduce that here with:
> git-svn version 1.6.0.2.541.g46dc1.dirty (svn 1.5.1)
>
> The error message I get is:
> Apache got a malformed URI: Unusable URI: it does not refer to this
> repository at /usr/local/libexec/git-core/git-svn line 4057
>
> strace revealed that git-svn url-encodes ~ while svn does not do that.
>
> For svn we have:
> write(5, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/~welshbyte/svn/backuptool/trunk</S:src-path>...
>
> While git-svn shows:
> write(7, "<S:update-report send-all=\"true\" xmlns:S=\"svn:\">
> <S:src-path>https://sucs.org/%7Ewelshbyte/svn/backuptool/trunk</S:src-path>...
Signed-off-by: Eric Wong <normalperson@yhbt.net>
The date/time parsing code was confused if the input time HH:MM:SS is
followed by fractional seconds. Since we do not record anything finer
grained than seconds, we could just drop fractional part, but there is a
twist.
We have taught people that not just spaces but dot can be used as word
separators when spelling things like:
$ git log --since 2.days
$ git show @{12:34:56.7.days.ago}
and we shouldn't mistake "7" in the latter example as a fraction and
discard it.
The rules are:
- valid days of month/mday are always single or double digits.
- valid years are either two or four digits
No, we don't support the year 600 _anyway_, since our encoding is based
on the UNIX epoch, and the day we worry about the year 10,000 is far
away and we can raise the limit to five digits when we get closer.
- Other numbers (eg "600 days ago") can have any number of digits, but
they cannot start with a zero. Again, the only exception is for
two-digit numbers, since that is fairly common for dates ("Dec 01" is
not unheard of)
So that means that any milli- or micro-second would be thrown out just
because the number of digits shows that it cannot be an interesting date.
A milli- or micro-second can obviously be a perfectly fine number
according to the rules above, as long as it doesn't start with a '0'. So
if we have
12:34:56.123
then that '123' gets parsed as a number, and we remember it. But because
it's bigger than 31, we'll never use it as such _unless_ there is
something after it to trigger that use.
So you can say "12:34:56.123.days.ago", and because of the "days", that
123 will actually be meaninful now.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
