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>
* 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>
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Fix linehtag undefined error with file highlighting
gitk: Fix commit encoding support
gitk: Fix transient windows on Win32 and MacOS
gitk: Add accelerators to frequently used menu commands
gitk: Implement a user-friendly Edit View dialog
gitk: Improve cherry-pick error handling
gitk: Make cherry-pick call git-citool on conflicts
gitk: Make gitk dialog windows transient
gitk: Add Return and Escape bindings to dialogs
gitk: Cope with unmerged files in local changes
gitk: Make "show origin of this line" work on fake commits
gitk: Unify handling of merge diffs with normal 2-way diffs
gitk: Make the background color of marked lines configurable
gitk: Add a menu item to show where a given line comes from
gitk: Fix some off-by-one errors in computing which line to blame
gitk: Allow starting gui blame for a specific line
gitk: Fix file list context menu for merge commits
gitk: Allow forcing branch creation if it already exists
Occasionally gitk will throw a Tcl error complaining that linehtag(n)
is undefined when. It happens when the commit list is still growing
(e.g. when updating the commit list) and gitk is set to highlight
commits that affect certain file(s). What happens is that the changes
to the commit list set need_redisplay to indicate that the display
needs to be redrawn. That causes the next call to drawcommits to call
clear_display, which unsets iddrawn and thus ensures that readfhighlight
won't call bolden on any rows that have moved. However, it is possible
for readfhighlight to be called after the commit list has changed but
before drawcommits has run, meaning that readfhighlight will potentially
think that rows have been drawn when they haven't, because of the
change in the id -> row mapping (and the fact that iddrawn is indexed
by id but line[hnd]tag are indexed by row number).
This fixes it (and also optimizes things a little) by making bolden
and bolden_name check need_redisplay before doing anything. If
need_redisplay is set, then there is no point doing anything because
the whole display is about to get cleared and redrawn, and it avoids
looking up line[hn]tag using stale row numbers.
Signed-off-by: Paul Mackerras <paulus@samba.org>
This commit fixes two problems with commit encodings:
1) git-log actually uses i18n.logoutputencoding to generate
its output, and falls back to i18n.commitencoding only
when that option is not set. Thus, gitk should use its
value to read the results, if available.
2) The readcommit function did not process encodings at all.
This led to randomly appearing misconverted commits if
the commit encoding differed from the current locale.
Now commit messages should be displayed correctly, except
when logoutputencoding is set to an encoding that cannot
represent charecters in the message. For example, it is
impossible to convert Japanese characters from Shift-JIS
to CP-1251 (although the reverse conversion works).
The reason for using git log to read the commit and then getting
Tcl to convert its output is that is essentially what happens in
the normal path through getcommitlines, hence there is less chance
for unintended differences in how commits are processed in
getcommitlines and do_readcommit.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
Transient windows cause problems on these platforms:
- On Win32 the windows appear in the top left corner
of the screen. In order to fix it, this patch causes
them to be explicitly centered on their parents by
an idle handler.
- On MacOS with Tk 8.4 they appear without a title bar.
Since it is clearly unacceptable, this patch disables
transient on that platform.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
This commit documents keyboard accelerators used for menu
commands in the menu, as it is usually done, and adds some
more, e.g. F4 to invoke Edit View (or New View if the current
view is the un-editable "All files" view).
The changes include a workaround for handling Shift-F4 on
systems where XKB binds special XF86_Switch_VT_* symbols
to Ctrl-Alt-F* combinations. Tk often receives these codes
when Shift-F* is pressed, so it is necessary to bind the
relevant actions to them as well.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Signed-off-by: Paul Mackerras <paulus@samba.org>
* gb/gitweb-snapshot-pathinfo:
gitweb: embed snapshot format parameter in PATH_INFO
gitweb: retrieve snapshot format from PATH_INFO
gitweb: make the supported snapshot formats array global
* 'ds/uintmax-config' (early part):
Add autoconf tests for pthreads
Make Pthread link flags configurable
Add Makefile check for FreeBSD 4.9-SECURITY
Build: add NO_UINTMAX_T to support ancient systems
Conflicts:
Makefile
* np/pack-safer:
t5303: fix printf format string for portability
t5303: work around printf breakage in dash
pack-objects: don't leak pack window reference when splitting packs
extend test coverage for latest pack corruption resilience improvements
pack-objects: allow "fixing" a corrupted pack without a full repack
make find_pack_revindex() aware of the nasty world
make check_object() resilient to pack corruptions
make packed_object_info() resilient to pack corruptions
make unpack_object_header() non fatal
better validation on delta base object offsets
close another possibility for propagating pack corruption
* bc/maint-keep-pack:
t7700: test that 'repack -a' packs alternate packed objects
pack-objects: extend --local to mean ignore non-local loose objects too
sha1_file.c: split has_loose_object() into local and non-local counterparts
t7700: demonstrate mishandling of loose objects in an alternate ODB
builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
repack: do not fall back to incremental repacking with [-a|-A]
repack: don't repack local objects in packs with .keep file
pack-objects: new option --honor-pack-keep
packed_git: convert pack_local flag into a bitfield and add pack_keep
t7700: demonstrate mishandling of objects in packs with a .keep file
* mv/remote-rename:
git-remote: document the migration feature of the rename subcommand
git-remote rename: migrate from remotes/ and branches/
remote: add a new 'origin' variable to the struct
Implement git remote rename
* lt/decorate:
rev-list documentation: clarify the two parts of history simplification
Document "git log --simplify-by-decoration"
Document "git log --source"
revision traversal: '--simplify-by-decoration'
Make '--decorate' set an explicit 'show_decorations' flag
revision: make tree comparison functions take commits rather than trees
Add a 'source' decorator for commits
Conflicts:
Documentation/rev-list-options.txt
* git://repo.or.cz/git-gui:
git-gui: Request blame metadata in utf-8.
git-gui: Add the Show SSH Key item to the clone dialog.
git-gui: Fix focus transition in the blame viewer.
Previously, when 'repack -a' was called and there were no packs in the local
repository without a .keep file, the repack would fall back to calling
pack-objects with '--unpacked --incremental'. This resulted in the created
pack file, if any, to be missing the packed objects in the alternate object
store. Test that this specific case has been fixed.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* maint:
Start 1.6.0.5 cycle
Fix pack.packSizeLimit and --max-pack-size handling
checkout: Fix "initial checkout" detection
Remove the period after the git-check-attr summary
Conflicts:
RelNotes
If the limit was sufficiently low, having a single object written
could bust the limit (by design), but caused the remaining allowed
size to go negative for subsequent objects, which for an unsigned
variable is a rather huge limit.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
One set of options and parameters determine what commits are involved in
the simplification process, and another set of options determine how the
simplification is done. Clarify their distinction at the beginning.
Signed-off-by: Santi Béjar <santi@agolina.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Earlier commit 5521883 (checkout: do not lose staged removal, 2008-09-07)
tightened the rule to prevent switching branches from losing local
changes, so that staged removal of paths can be protected, while
attempting to keep a loophole to still allow a special case of switching
out of an un-checked-out state.
However, the loophole was made a bit too tight, and did not allow
switching from one branch (in an un-checked-out state) to check out
another branch.
The change to builtin-checkout.c in this commit loosens it to allow this,
by not insisting the original commit and the new commit to be the same.
It also introduces a new function, is_index_unborn (and an associated
macro, is_cache_unborn), to check if the repository is truly in an
un-checked-out state more reliably, by making sure that $GIT_INDEX_FILE
did not exist when populating the in-core index structure. A few places
the earlier commit 5521883 added the check for the initial checkout
condition are updated to use this function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since we can use the same "diff against empty tree" trick as
we do for the non-initial case, it is trivial to make this
work.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano