* Re: [RFC] git rm -u
From: Matthieu Moy @ 2013-02-25 19:39 UTC (permalink / raw)
To: Antoine Pelisse
Cc: Junio C Hamano, Eric James Michael Ritz, Tomas Carnecky, git
In-Reply-To: <CALWbr2y-CN9A346avc4AG+FN9NHgPXKvWuU-nbcyjt08DavVjw@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
>> "git rm" really seems to be a better place for removing files from the
>> index.
>
> Then, I don't exactly understand the meaning of git-rm but being a
> _shortcut_ for "remove and stage".
"git rm --cached" is exactly "remove from index".
And even without --cached, as you notice yourself, it does a "remove and
stage [removal]", so why would it be inappropriate to stage a removal?
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Junio C Hamano @ 2013-02-25 19:37 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <CAHXAxrOjSS5jGLcCw4KTxP_F_uRQhi0cPSvzbx58jx9dP25XPA@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
> if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_sec < 0)
> return -1;
>
> So is_date() always return negative result for the text string where
> date is placed before time like '2008-02-14 20:30:45'.
Yes, it returns this -1 on other platforms, but...
> It must fail on
> other platforms as well.
... the input '2008-02-14 20:30:45' still parses fine for others
(including me). That is what is puzzling.
A shot in the dark: perhaps your time_t is unsigned?
^ permalink raw reply
* Re: [PATCH 4/4] cat-file: print tags raw for "cat-file -p"
From: Mantas Mikulėnas @ 2013-02-25 19:33 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20130225185058.GD14438@sigill.intra.peff.net>
On Mon, Feb 25, 2013 at 8:50 PM, Jeff King <peff@peff.net> wrote:
> Note that "git verify-tag" and "git tag -v" depend on
> "cat-file -p" to show the tag. This means they will start
> showing the raw timestamp. We may want to adjust them to
> use the pretty-printing code from "git show".
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> I don't use "git tag -v" much, so I'm not sure what is sane there. But
> this seems like it would be a regression for people who want to check
> the human-readable date given by GPG against the date in the tag object.
Personally, I've found it quite confusing that commits (incl. merged
tags) can be verified with `git show --show-signature`, but for tags I
must use `git tag -v`... took me a while to find the latter.
(`git show --verify` might be even better, but that's just me.)
--
Mantas Mikulėnas <grawity@gmail.com>
^ permalink raw reply
* Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Mike Gorchak @ 2013-02-25 19:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr4k4xlie.fsf@alter.siamese.dyndns.org>
> The thing that puzzles me is that nobody reported that the following
> fail on their platforms (and they do not fail for me on platforms I
> have to test in my real/virtual boxes).
Ok, check_parse calls function parse_date(), it calls
parse_date_basic(), where following code is present:
memset(&tm, 0, sizeof(tm));
tm.tm_year = -1;
tm.tm_mon = -1;
tm.tm_mday = -1;
tm.tm_isdst = -1;
tm.tm_hour = -1;
tm.tm_min = -1;
tm.tm_sec = -1;
Almost all fields are set to -1. A bit later match_multi_number() is
called. It parses the date and calls is_date() with partially filled
tm structure, where all time fields: tm_hour, tm_min, tm_sec are set
to -1. tm_to_time_t() function is called by is_date() and has special
check:
if (tm->tm_hour < 0 || tm->tm_min < 0 || tm->tm_sec < 0)
return -1;
So is_date() always return negative result for the text string where
date is placed before time like '2008-02-14 20:30:45'. It must fail on
other platforms as well.
^ permalink raw reply
* [PATCH] git-compat-util.h: Provide missing netdb.h definitions
From: David Michael @ 2013-02-25 19:30 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Junio C Hamano
Some platforms may lack the NI_MAXHOST and NI_MAXSERV values in their
system headers, so ensure they are available.
Signed-off-by: David Michael <fedora.dm0@gmail.com>
---
NI_MAXHOST is missing from my platform, and it has no compatibility
definition anywhere.
$ grep -FIR NI_MAXHOST
imap-send.c: char addr[NI_MAXHOST];
connect.c: static char addr[NI_MAXHOST];
I've been defining it in CFLAGS, but I noticed there is precedence for
this type of definition in git-compat-util.h. This patch adds a
definition for compatibility.
In addition, all the documentation I've seen mentions NI_MAXHOST and
NI_MAXSERV together, so this also moves the NI_MAXSERV definition to
git-compat-util.h for consistency.
daemon.c | 4 ----
git-compat-util.h | 11 +++++++++++
2 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/daemon.c b/daemon.c
index 4602b46..df8c0ab 100644
--- a/daemon.c
+++ b/daemon.c
@@ -9,10 +9,6 @@
#define HOST_NAME_MAX 256
#endif
-#ifndef NI_MAXSERV
-#define NI_MAXSERV 32
-#endif
-
#ifdef NO_INITGROUPS
#define initgroups(x, y) (0) /* nothing */
#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index b7eaaa9..2580c6b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -213,6 +213,17 @@ extern char *gitbasename(char *);
#include <openssl/err.h>
#endif
+/* On most systems <netdb.h> would have given us this, but
+ * not on some systems (e.g. z/OS).
+ */
+#ifndef NI_MAXHOST
+#define NI_MAXHOST 1025
+#endif
+
+#ifndef NI_MAXSERV
+#define NI_MAXSERV 32
+#endif
+
/* On most systems <limits.h> would have given us this, but
* not on some systems (e.g. GNU/Hurd).
*/
--
1.8.1.2
^ permalink raw reply related
* [ANNOUNCE] Git v1.8.2-rc1
From: Junio C Hamano @ 2013-02-25 19:28 UTC (permalink / raw)
To: git; +Cc: Linux Kernel
The first release candidate Git v1.8.2-rc1 is now available for
testing at the usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
44172a71a711b83b4cfaa8e41dd24d05068b0887 git-1.8.2.rc1.tar.gz
fd23a6fd099bf13f897675f727a91633537eaa29 git-htmldocs-1.8.2.rc1.tar.gz
f10f04741401e273ac6a8c7e54c96e1d915f6486 git-manpages-1.8.2.rc1.tar.gz
Also the following public repositories all have a copy of the v1.8.2-rc1
tag and the master branch that the tag points at:
url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
Git v1.8.2 Release Notes (draft)
========================
Backward compatibility notes
----------------------------
In the next major release Git 2.0 (not *this* one), we will change the
behavior of the "git push" command.
When "git push [$there]" does not say what to push, we have used the
traditional "matching" semantics so far (all your branches were sent
to the remote as long as there already are branches of the same name
over there). We will use the "simple" semantics that pushes the
current branch to the branch with the same name, only when the current
branch is set to integrate with that remote branch. There is a user
preference configuration variable "push.default" to change this.
"git push $there tag v1.2.3" used to allow replacing a tag v1.2.3
that already exists in the repository $there, if the rewritten tag
you are pushing points at a commit that is a descendant of a commit
that the old tag v1.2.3 points at. This was found to be error prone
and starting with this release, any attempt to update an existing
ref under refs/tags/ hierarchy will fail, without "--force".
When "git add -u" and "git add -A", that does not specify what paths
to add on the command line, is run from inside a subdirectory, the
scope of the operation has always been limited to the subdirectory.
Many users found this counter-intuitive, given that "git commit -a"
and other commands operate on the entire tree regardless of where you
are. In this release, these commands give warning in such a case and
encourage the user to say "git add -u/-A ." instead when restricting
the scope to the current directory. At Git 2.0 (not *this* one), we
plan to change these commands without pathspec to operate on the
entire tree, and training your fingers to type "." will protect you
against the future change.
Updates since v1.8.1
--------------------
UI, Workflows & Features
* Initial ports to QNX and z/OS UNIX System Services have started.
* Output from the tests is coloured using "green is okay, yellow is
questionable, red is bad and blue is informative" scheme.
* Mention of "GIT/Git/git" in the documentation have been updated to
be more uniform and consistent. The name of the system and the
concept it embodies is "Git"; the command the users type is "git".
All-caps "GIT" was merely a way to imitate "Git" typeset in small
caps in our ASCII text only documentation and to be avoided.
* The completion script (in contrib/completion) used to let the
default completer to suggest pathnames, which gave too many
irrelevant choices (e.g. "git add" would not want to add an
unmodified path). It learnt to use a more git-aware logic to
enumerate only relevant ones.
* In bare repositories, "git shortlog" and other commands now read
mailmap files from the tip of the history, to help running these
tools in server settings.
* Color specifiers, e.g. "%C(blue)Hello%C(reset)", used in the
"--format=" option of "git log" and friends can be disabled when
the output is not sent to a terminal by prefixing them with
"auto,", e.g. "%C(auto,blue)Hello%C(auto,reset)".
* Scripts can ask Git that wildcard patterns in pathspecs they give do
not have any significance, i.e. take them as literal strings.
* The patterns in .gitignore and .gitattributes files can have **/,
as a pattern that matches 0 or more levels of subdirectory.
E.g. "foo/**/bar" matches "bar" in "foo" itself or in a
subdirectory of "foo".
* When giving arguments without "--" disambiguation, object names
that come earlier on the command line must not be interpretable as
pathspecs and pathspecs that come later on the command line must
not be interpretable as object names. This disambiguation rule has
been tweaked so that ":/" (no other string before or after) is
always interpreted as a pathspec; "git cmd -- :/" is no longer
needed, you can just say "git cmd :/".
* Various "hint" lines Git gives when it asks the user to edit
messages in the editor are commented out with '#' by default. The
core.commentchar configuration variable can be used to customize
this '#' to a different character.
* "git add -u" and "git add -A" without pathspec issues warning to
make users aware that they are only operating on paths inside the
subdirectory they are in. Use ":/" (everything from the top) or
"." (everything from the $cwd) to disambiguate.
* "git blame" (and "git diff") learned the "--no-follow" option.
* "git branch" now rejects some nonsense combinations of command line
arguments (e.g. giving more than one branch name to rename) with
more case-specific error messages.
* "git check-ignore" command to help debugging .gitignore files has
been added.
* "git cherry-pick" can be used to replay a root commit to an unborn
branch.
* "git commit" can be told to use --cleanup=whitespace by setting the
configuration variable commit.cleanup to 'whitespace'.
* "git diff" and other Porcelain commands can be told to use a
non-standard algorithm by setting diff.algorithm configuration
variable.
* "git fetch --mirror" and fetch that uses other forms of refspec
with wildcard used to attempt to update a symbolic ref that match
the wildcard on the receiving end, which made little sense (the
real ref that is pointed at by the symbolic ref would be updated
anyway). Symbolic refs no longer are affected by such a fetch.
* "git format-patch" now detects more cases in which a whole branch
is being exported, and uses the description for the branch, when
asked to write a cover letter for the series.
* "git format-patch" learned "-v $count" option, and prepends a
string "v$count-" to the names of its output files, and also
automatically sets the subject prefix to "PATCH v$count". This
allows patches from rerolled series to be stored under different
names and makes it easier to reuse cover letter messages.
* "git log" and friends can be told with --use-mailmap option to
rewrite the names and email addresses of people using the mailmap
mechanism.
* "git log --cc --graph" now shows the combined diff output with the
ancestry graph.
* "git log --grep=<pattern>" honors i18n.logoutputencoding to look
for the pattern after fixing the log message to the specified
encoding.
* "git mergetool" and "git difftool" learned to list the available
tool backends in a more consistent manner.
* "git mergetool" is aware of TortoiseGitMerge now and uses it over
TortoiseMerge when available.
* "git push" now requires "-f" to update a tag, even if it is a
fast-forward, as tags are meant to be fixed points.
* Error messages from "git push" when it stops to prevent remote refs
from getting overwritten by mistake have been improved to explain
various situations separately.
* "git push" will stop without doing anything if the new "pre-push"
hook exists and exits with a failure.
* When "git rebase" fails to generate patches to be applied (e.g. due
to oom), it failed to detect the failure and instead behaved as if
there were nothing to do. A workaround to use a temporary file has
been applied, but we probably would want to revisit this later, as
it hurts the common case of not failing at all.
* Input and preconditions to "git reset" has been loosened where
appropriate. "git reset $fromtree Makefile" requires $fromtree to
be any tree (it used to require it to be a commit), for example.
"git reset" (without options or parameters) used to error out when
you do not have any commits in your history, but it now gives you
an empty index (to match non-existent commit you are not even on).
* "git status" says what branch is being bisected or rebased when
able, not just "bisecting" or "rebasing".
* "git submodule" started learning a new mode to integrate with the
tip of the remote branch (as opposed to integrating with the commit
recorded in the superproject's gitlink).
* "git upload-pack" which implements the service "ls-remote" and
"fetch" talk to can be told to hide ref hierarchies the server
side internally uses (and that clients have no business learning
about) with transfer.hiderefs configuration.
Foreign Interface
* "git fast-export" has been updated for its use in the context of
the remote helper interface.
* A new remote helper to interact with bzr has been added to contrib/.
* "git p4" got various bugfixes around its branch handling. It is
also made usable with Python 2.4/2.5. In addition, its various
portability issues for Cygwin have been addressed.
* The remote helper to interact with Hg in contrib/ has seen a few
fixes.
Performance, Internal Implementation, etc.
* "git fsck" has been taught to be pickier about entries in tree
objects that should not be there, e.g. ".", ".git", and "..".
* Matching paths with common forms of pathspecs that contain wildcard
characters has been optimized further.
* We stopped paying attention to $GIT_CONFIG environment that points
at a single configuration file from any command other than "git config"
quite a while ago, but "git clone" internally set, exported, and
then unexported the variable during its operation unnecessarily.
* "git reset" internals has been reworked and should be faster in
general. We tried to be careful not to break any behaviour but
there could be corner cases, especially when running the command
from a conflicted state, that we may have missed.
* The implementation of "imap-send" has been updated to reuse xml
quoting code from http-push codepath, and lost a lot of unused
code.
* There is a simple-minded checker for the test scripts in t/
directory to catch most common mistakes (it is not enabled by
default).
* You can build with USE_WILDMATCH=YesPlease to use a replacement
implementation of pattern matching logic used for pathname-like
things, e.g. refnames and paths in the repository. This new
implementation is not expected change the existing behaviour of Git
in this release, except for "git for-each-ref" where you can now
say "refs/**/master" and match with both refs/heads/master and
refs/remotes/origin/master. We plan to use this new implementation
in wider places (e.g. "git ls-files '**/Makefile' may find Makefile
at the top-level, and "git log '**/t*.sh'" may find commits that
touch a shell script whose name begins with "t" at any level) in
future versions of Git, but we are not there yet. By building with
USE_WILDMATCH, using the resulting Git daily and reporting when you
find breakages, you can help us get closer to that goal.
* Some reimplementations of Git do not write all the stat info back
to the index due to their implementation limitations (e.g. jgit).
A configuration option can tell Git to ignore changes to most of
the stat fields and only pay attention to mtime and size, which
these implementations can reliably update. This can be used to
avoid excessive revalidation of contents.
* Some platforms ship with old version of expat where xmlparse.h
needs to be included instead of expat.h; the build procedure has
been taught about this.
* "make clean" on platforms that cannot compute header dependencies
on the fly did not work with implementations of "rm" that do not
like an empty argument list.
Also contains minor documentation updates and code clean-ups.
Fixes since v1.8.1
------------------
Unless otherwise noted, all the fixes since v1.8.1 in the maintenance
track are contained in this release (see release notes to them for
details).
* An element on GIT_CEILING_DIRECTORIES list that does not name the
real path to a directory (i.e. a symbolic link) could have caused
the GIT_DIR discovery logic to escape the ceiling.
* When attempting to read the XDG-style $HOME/.config/git/config and
finding that $HOME/.config/git is a file, we gave a wrong error
message, instead of treating the case as "a custom config file does
not exist there" and moving on.
* The behaviour visible to the end users was confusing, when they
attempt to kill a process spawned in the editor that was in turn
launched by Git with SIGINT (or SIGQUIT), as Git would catch that
signal and die. We ignore these signals now.
(merge 0398fc34 pf/editor-ignore-sigint later to maint).
* A child process that was killed by a signal (e.g. SIGINT) was
reported in an inconsistent way depending on how the process was
spawned by us, with or without a shell in between.
* After failing to create a temporary file using mkstemp(), failing
pathname was not reported correctly on some platforms.
* We used to stuff "user@" and then append what we read from
/etc/mailname to come up with a default e-mail ident, but a bug
lost the "user@" part.
* The attribute mechanism didn't allow limiting attributes to be
applied to only a single directory itself with "path/" like the
exclude mechanism does. The initial implementation of this that
was merged to 'maint' and 1.8.1.2 was with a severe performance
degradations and needs to merge a fix-up topic.
* The smart HTTP clients forgot to verify the content-type that comes
back from the server side to make sure that the request is being
handled properly.
* "git am" did not parse datestamp correctly from Hg generated patch,
when it is run in a locale outside C (or en).
* "git apply" misbehaved when fixing whitespace breakages by removing
excess trailing blank lines.
* "git apply --summary" has been taught to make sure the similarity
value shown in its output is sensible, even when the input had a
bogus value.
* A tar archive created by "git archive" recorded a directory in a
way that made NetBSD's implementation of "tar" sometimes unhappy.
* "git archive" did not record uncompressed size in the header when
streaming a zip archive, which confused some implementations of unzip.
* "git archive" did not parse configuration values in tar.* namespace
correctly.
(merge b3873c3 jk/config-parsing-cleanup later to maint).
* Attempt to "branch --edit-description" an existing branch, while
being on a detached HEAD, errored out.
* "git clean" showed what it was going to do, but sometimes end up
finding that it was not allowed to do so, which resulted in a
confusing output (e.g. after saying that it will remove an
untracked directory, it found an embedded git repository there
which it is not allowed to remove). It now performs the actions
and then reports the outcome more faithfully.
* When "git clone --separate-git-dir=$over_there" is interrupted, it
failed to remove the real location of the $GIT_DIR it created.
This was most visible when interrupting a submodule update.
* "git cvsimport" mishandled timestamps at DST boundary.
* We used to have an arbitrary 32 limit for combined diff input,
resulting in incorrect number of leading colons shown when showing
the "--raw --cc" output.
* "git fetch --depth" was broken in at least three ways. The
resulting history was deeper than specified by one commit, it was
unclear how to wipe the shallowness of the repository with the
command, and documentation was misleading.
(merge cfb70e1 nd/fetch-depth-is-broken later to maint).
* "git log --all -p" that walked refs/notes/textconv/ ref can later
try to use the textconv data incorrectly after it gets freed.
* We forgot to close the file descriptor reading from "gpg" output,
killing "git log --show-signature" on a long history.
* The way "git svn" asked for password using SSH_ASKPASS and
GIT_ASKPASS was not in line with the rest of the system.
* The --graph code fell into infinite loop when asked to do what the
code did not expect.
* http transport was wrong to ask for the username when the
authentication is done by certificate identity.
* "git pack-refs" that ran in parallel to another process that
created new refs had a nasty race.
* Rebasing the history of superproject with change in the submodule
has been broken since v1.7.12.
* After "git add -N" and then writing a tree object out of the
index, the cache-tree data structure got corrupted.
* "git clone" used to allow --bare and --separate-git-dir=$there
options at the same time, which was nonsensical.
* "git rebase --preserve-merges" lost empty merges in recent versions
of Git.
* "git merge --no-edit" computed who were involved in the work done
on the side branch, even though that information is to be discarded
without getting seen in the editor.
* "git merge" started calling prepare-commit-msg hook like "git
commit" does some time ago, but forgot to pay attention to the exit
status of the hook.
* A failure to push due to non-ff while on an unborn branch
dereferenced a NULL pointer when showing an error message.
* When users spell "cc:" in lowercase in the fake "header" in the
trailer part, "git send-email" failed to pick up the addresses from
there. As e-mail headers field names are case insensitive, this
script should follow suit and treat "cc:" and "Cc:" the same way.
* Output from "git status --ignored" showed an unexpected interaction
with "--untracked".
* "gitweb", when sorting by age to show repositories with new
activities first, used to sort repositories with absolutely
nothing in it early, which was not very useful.
* "gitweb"'s code to sanitize control characters before passing it to
"highlight" filter lost known-to-be-safe control characters by
mistake.
* "gitweb" pages served over HTTPS, when configured to show picon or
gravatar, referred to these external resources to be fetched via
HTTP, resulting in mixed contents warning in browsers.
* When a line to be wrapped has a solid run of non space characters
whose length exactly is the wrap width, "git shortlog -w" failed
to add a newline after such a line.
* Command line completion leaked an unnecessary error message while
looking for possible matches with paths in <tree-ish>.
* Command line completion for "tcsh" emitted an unwanted space
after completing a single directory name.
* Command line completion code was inadvertently made incompatible with
older versions of bash by using a newer array notation.
* "git push" was taught to refuse updating the branch that is
currently checked out long time ago, but the user manual was left
stale.
(merge 50995ed wk/man-deny-current-branch-is-default-these-days later to maint).
* Some shells do not behave correctly when IFS is unset; work it
around by explicitly setting it to the default value.
* Some scripted programs written in Python did not get updated when
PYTHON_PATH changed.
(cherry-pick 96a4647fca54031974cd6ad1 later to maint).
* When autoconf is used, any build on a different commit always ran
"config.status --recheck" even when unnecessary.
* A fix was added to the build procedure to work around buggy
versions of ccache broke the auto-generation of dependencies, which
unfortunately is still relevant because some people use ancient
distros.
* The autoconf subsystem passed --mandir down to generated
config.mak.autogen but forgot to do the same for --htmldir.
(merge 55d9bf0 ct/autoconf-htmldir later to maint).
* A change made on v1.8.1.x maintenance track had a nasty regression
to break the build when autoconf is used.
(merge 7f1b697 jn/less-reconfigure later to maint).
* We have been carrying a translated and long-unmaintained copy of an
old version of the tutorial; removed.
* t0050 had tests expecting failures from a bug that was fixed some
time ago.
* t4014, t9502 and t0200 tests had various portability issues that
broke on OpenBSD.
* t9020 and t3600 tests had various portability issues.
* t9200 runs "cvs init" on a directory that already exists, but a
platform can configure this fail for the current user (e.g. you
need to be in the cvsadmin group on NetBSD 6.0).
* t9020 and t9810 had a few non-portable shell script construct.
* Scripts to test bash completion was inherently flaky as it was
affected by whatever random things the user may have on $PATH.
----------------------------------------------------------------
Changes since v1.8.2-rc0 (preview) are as follows:
Adam Spiers (1):
t0008: document test_expect_success_multi
Greg Price (1):
Documentation: "advice" is uncountable
Jeff King (1):
Makefile: avoid infinite loop on configure.ac change
Jiang Xin (5):
l10n: Update git.pot (35 new, 14 removed messages)
l10n: zh_CN.po: translate 35 new messages
l10n: git.pot: v1.8.2 round 3 (5 new)
l10n: zh_CN.po: translate 5 new messages
Bugfix: undefined htmldir in config.mak.autogen
Junio C Hamano (8):
doc: mention tracking for pull.default
user-manual: typofix (ofthe->of the)
RelNotes 1.8.2: push-simple will not be in effect in this release
imap-send: move #ifdef around
name-hash: allow hashing an empty string
Git 1.8.1.4
Prepare for 1.8.1.5
Git 1.8.2-rc1
Martin Erik Werner (1):
shell-prompt: clean up nested if-then
Matthieu Moy (1):
git.txt: update description of the configuration mechanism
Oswald Buddenhagen (2):
imap-send: the subject of SSL certificate must match the host
imap-send: support subjectAltName as well
Peter Krefting (2):
l10n: Update Swedish translation (2004t0f0u)
l10n: Update Swedish translation (2009t0f0u)
Tran Ngoc Quan (2):
l10n: vi.po: update new strings (2004t0u0f)
l10n: vi.po: Updated 5 new messages (2009t0f0u)
W. Trevor King (8):
user-manual: use 'remote add' to setup push URLs
user-manual: give 'git push -f' as an alternative to +master
user-manual: mention 'git remote add' for remote branch config
user-manual: use 'git config --global user.*' for setup
user-manual: use -o latest.tar.gz to create a gzipped tarball
user-manual: Reorganize the reroll sections, adding 'git rebase -i'
user-manual: Use request-pull to generate "please pull" text
user-manual: Flesh out uncommitted changes and submodule updates
^ permalink raw reply
* Re: [RFC] git rm -u
From: Antoine Pelisse @ 2013-02-25 19:21 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, Eric James Michael Ritz, Tomas Carnecky, git
In-Reply-To: <vpq7glw5i20.fsf@grenoble-inp.fr>
On Mon, Feb 25, 2013 at 8:07 PM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Antoine Pelisse <apelisse@gmail.com> writes:
>
>> I must say that I'm not very interested in the feature. In my opinion,
>> there are already many different ways to stage changes.
>> Assuming that the feature would be needed, I would keep it under the
>> scope of git-add, as it's the reference for staging. I would suggest
>> something like:
>>
>> git add -r "Stage removal of deleted files."
>
> Would "add -r" stand for "add --remove"? That would be weird ...
Yes (for --remove),
It would not be weird if you consider the opposite of add to be reset
(and not rm).
> "git rm" really seems to be a better place for removing files from the
> index.
Then, I don't exactly understand the meaning of git-rm but being a
_shortcut_ for "remove and stage". Here the files are already removed,
we only need to stage and the best command to stage changes is add.
^ permalink raw reply
* Re: Possible regression in ref advertisement
From: Junio C Hamano @ 2013-02-25 19:27 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git, peff
In-Reply-To: <1361819916.24515.5.camel@centaur.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote:
> ...
>> Interesting. "git ls-remote . | grep 1.8.0-" for maint, master,
>> next and pu produce identical results for me, all showing peeled
>> ones correctly.
>
> Bisection leads me to Peff's 435c8332 (2012-10-04; upload-pack: use
> peel_ref for ref advertisements) and reverting that commit brings the
> -rc3^{} back.
A shot in the dark, as I do not seem to be able to reproduce the issue
with anything that contains the commit. Perhaps your .git/packed-refs
is corrupt?
^ permalink raw reply
* Re: Possible regression in ref advertisement
From: Carlos Martín Nieto @ 2013-02-25 19:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, peff
In-Reply-To: <7vvc9gxn2y.fsf@alter.siamese.dyndns.org>
On Mon, 2013-02-25 at 10:31 -0800, Junio C Hamano wrote:
> Carlos Martín Nieto <cmn@elego.de> writes:
>
> > Hi all,
> >
> > When testing to see if a different implementation was in shape, I came
> > across something odd where newer git doesn't advertise one of the refs
> > in the git repo.
> >
> > Running `git ls-remote .` or `git-upload-pack` in my git repo, newer git
> > versions omit peeling the v1.8.0-rc3 tag.
> >
> > The diff between the command above when ran with 1.7.10.4 (from Debian)
> > and current 'master'
> >
> > --- old 2013-02-25 17:31:29.583526606 +0100
> > +++ new 2013-02-25 17:31:36.783526559 +0100
> > @@ -1379,7 +1379,6 @@
> > c15295d7477ccec489953299bd03a8e62f86e611 refs/tags/v1.8.0-rc2
> > cd46259ebf2e624bcee2aaae05c36663d414e1a2 refs/tags/v1.8.0-rc2^{}
> > 22ed067acc84eac8a0a72d20478a18aee4e25571 refs/tags/v1.8.0-rc3
> > -87a5461fa7b30f7b7baf27204f10219d61500fbf refs/tags/v1.8.0-rc3^{}
> > bfeb8b9ae0012cb61e026cbcd29664876abf5389 refs/tags/v1.8.0.1
> > ed9fe755130891fc878bb2433204faffb534697b refs/tags/v1.8.0.1^{}
> > 63add1fb45e1ab7a76bb38bbb9467c91fdfaaa7e refs/tags/v1.8.0.2
> >
> > Diffing with the output from next, diff tells me it's binary for some
> > reason, but looking manually, the peeled v1.8.0-rc3 tag isn't there
> > either. I haven't had time to bisect this, so I'm putting it out there
> > in case anybody wants to investigate before I have time to dig into it.
>
> Interesting. "git ls-remote . | grep 1.8.0-" for maint, master,
> next and pu produce identical results for me, all showing peeled
> ones correctly.
Bisection leads me to Peff's 435c8332 (2012-10-04; upload-pack: use
peel_ref for ref advertisements) and reverting that commit brings the
-rc3^{} back.
cmn
^ permalink raw reply
* Re: [RFC] git rm -u
From: Matthieu Moy @ 2013-02-25 19:07 UTC (permalink / raw)
To: Antoine Pelisse
Cc: Junio C Hamano, Eric James Michael Ritz, Tomas Carnecky, git
In-Reply-To: <CALWbr2x9=+PEaGTpGWoqGiiupGsPhLoPcGknPb1WtSgxdpBkdQ@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
> I must say that I'm not very interested in the feature. In my opinion,
> there are already many different ways to stage changes.
> Assuming that the feature would be needed, I would keep it under the
> scope of git-add, as it's the reference for staging. I would suggest
> something like:
>
> git add -r "Stage removal of deleted files."
Would "add -r" stand for "add --remove"? That would be weird ...
"git rm" really seems to be a better place for removing files from the
index.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly
From: Junio C Hamano @ 2013-02-25 19:06 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Sixt, Thomas Haller, Git List
In-Reply-To: <20130225151916.GA7725@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> ... I think the simplest thing would just be:
>
> diff --git a/utf8.c b/utf8.c
> index 1087870..8d42b50 100644
> --- a/utf8.c
> +++ b/utf8.c
> @@ -507,6 +507,17 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
>
> if (!in_encoding)
> return NULL;
> +
> + /*
> + * Some platforms do not have the variously spelled variants of
> + * UTF-8, so let us feed iconv the most official spelling, which
> + * should hopefully be accepted everywhere.
> + */
> + if (is_encoding_utf8(in_encoding))
> + in_encoding = "UTF-8";
> + if (is_encoding_utf8(out_encoding))
> + out_encoding = "UTF-8";
> +
> conv = iconv_open(out_encoding, in_encoding);
> if (conv == (iconv_t) -1)
> return NULL;
>
> Does that fix the tests for you? It's a larger change, but I think it
> makes git friendlier all around for people on Windows.
Yeah, if this is confirmed to work OK (from eyeballing I do not see
a reason why not...) I agree this is the cleanest way forward.
^ permalink raw reply
* Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Junio C Hamano @ 2013-02-25 19:04 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <CAHXAxrMaQRdBxSvNO+no_9d==v0tVnkpXtguTKyfvnm-VfR_xA@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
>>> Fix is_date() function failings in detection of correct date in case
>>> if time was not properly initialized.
>>
>> Please explain why this patch is needed and what problem this patch
>> is trying to fix (if any) a bit better in the proposed log message.
>> For example, on what input do we call this function with partially
>> filled *r, and is that an error in the code, or is it an indication
>> that the input has only been consumed partially?
>
> function is_date() must not fail if time fields are not set.
> Currently is_date() invokes tm_to_time_t() which perform check of
> time fields. With these fixes t0006-date.sh test is no longer
> fail on these tests:
The thing that puzzles me is that nobody reported that the following
fail on their platforms (and they do not fail for me on platforms I
have to test in my real/virtual boxes).
> check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
> check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
> check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015'
> check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 +0000'
> check_parse '2008-02-14 20:30:45 -5:' '2008-02-14 20:30:45 +0000'
> check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
> check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +0000'
> check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
So there must be something _else_ going on, and I cannot tell what
that something else is from your code change nor from the log
message. I'd like to see that explained.
Still puzzled...
^ permalink raw reply
* Re: [PATCH 0/5] Fix msvc build
From: Johannes Schindelin @ 2013-02-25 19:01 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, GIT Mailing-list, Ramsay Jones, Erik Faye-Lund,
Jonathan Nieder, msysgit
In-Reply-To: <512B2003.804@viscovery.net>
Hi Hannes,
On Mon, 25 Feb 2013, Johannes Sixt wrote:
> Am 2/25/2013 7:54, schrieb Junio C Hamano:
> > Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> >
> >> As I mentioned recently, while discussing a cygwin specific patch
> >> (see "Version 1.8.1 does not compile on Cygwin 1.7.14" thread), the
> >> MSVC build is broken for me.
> >>
> >> The first 4 patches fix the MSVC build for me. The final patch is
> >> not really related to fixing the build, but it removed some make
> >> warnings which were quite irritating ...
> >>
> >> Note that I used the Makefile, with the Visual C++ 2008 command
> >> line compiler on Windows XP (SP3), to build a vanilla git on MinGW.
> >> I'm not subscribed to the msysgit mailing list, nor do I follow the
> >> msysgit fork of git, so these patches may conflict with commits in
> >> their repository.
> >
> > Did anything further happen to this topic in the Windows land?
>
> I successfully built with MSVC with these patches (but I am not using the
> result anywhere nor did I attempt to run the test suite).
>
> More importantly, I'm using git on Windows ("MinGW flavor") with these
> patches in production, so there are no obvious regressions.
>
> Feel free to add my
>
> Tested-by: Johannes Sixt <j6t@kdbg.org>
>
> but if you don't have the patches around, I can resend them.
Can you please send a pull request on GitHub?
Thanks,
Johannes
--
--
*** Please reply-to-all at all times ***
*** (do not pretend to know who is subscribed and who is not) ***
*** Please avoid top-posting. ***
The msysGit Wiki is here: https://github.com/msysgit/msysgit/wiki - Github accounts are free.
You received this message because you are subscribed to the Google
Groups "msysGit" group.
To post to this group, send email to msysgit@googlegroups.com
To unsubscribe from this group, send email to
msysgit+unsubscribe@googlegroups.com
For more options, and view previous threads, visit this group at
http://groups.google.com/group/msysgit?hl=en_US?hl=en
---
You received this message because you are subscribed to the Google Groups "msysGit" group.
To unsubscribe from this group and stop receiving emails from it, send an email to msysgit+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
^ permalink raw reply
* Re: [PATCH ] t4210-log-i18n: spell encoding name "UTF-8" correctly
From: Torsten Bögershausen @ 2013-02-25 18:54 UTC (permalink / raw)
To: Johannes Sixt
Cc: Jeff King, Junio C Hamano, Thomas Haller, Git List,
Torsten Bögershausen
In-Reply-To: <512B22DE.9070603@viscovery.net>
On 25.02.13 09:37, Johannes Sixt wrote:
> From: Johannes Sixt <j6t@kdbg.org>
>
> iconv on Windows does not know the encoding name "utf8", and does not
> re-encode log messages when this name is given. Request "UTF-8" encoding.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> I'm not sure whether I'm right to say that "UTF-8" is the correct
> spelling. Anyway, 'iconv -l' on my old Linux box lists "UTF8", but on
> Windows it does not.
>
> A more correct fix would probably be to use is_encoding_utf8() in more
> places, but it's outside my time budget look after it.
>
> -- Hannes
>
> t/t4210-log-i18n.sh | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/t/t4210-log-i18n.sh b/t/t4210-log-i18n.sh
> index 52a7472..b1956e2 100755
> --- a/t/t4210-log-i18n.sh
> +++ b/t/t4210-log-i18n.sh
> @@ -15,7 +15,7 @@ test_expect_success 'create commits in different encodings' '
> t${utf8_e}st
> EOF
> git add msg &&
> - git -c i18n.commitencoding=utf8 commit -F msg &&
> + git -c i18n.commitencoding=UTF-8 commit -F msg &&
> cat >msg <<-EOF &&
> latin1
>
> @@ -30,7 +30,7 @@ test_expect_success 'log --grep searches in log output encoding (utf8)' '
> latin1
> utf8
> EOF
> - git log --encoding=utf8 --format=%s --grep=$utf8_e >actual &&
> + git log --encoding=UTF-8 --format=%s --grep=$utf8_e >actual &&
> test_cmp expect actual
> '
>
> @@ -45,7 +45,7 @@ test_expect_success 'log --grep searches in log output encoding (latin1)' '
>
> test_expect_success 'log --grep does not find non-reencoded values (utf8)' '
> >expect &&
> - git log --encoding=utf8 --format=%s --grep=$latin1_e >actual &&
> + git log --encoding=UTF-8 --format=%s --grep=$latin1_e >actual &&
> test_cmp expect actual
> '
>
>
Hej,
(beside that I couldn't find t4210 somewhere),
is it something like the following you are tinking of?
(Not sure if my cut-and-paste stuff applies, its's rather for review)
-- >8 --
[PATCH] iconv_open(): Use UTF-8 if UTF8 failes
When iconv_open() failes with EINVAL, it may be that "UTF-8"
is spelled wrong by mistake.
For example, "UTF8" is used instead of "UTF-8".
Some iconv implementations tolerate "UTF8" or "utf8".
If not, iconv_open() fails.
If is_encoding_utf8() is true change the string to the
offical string "UTF-8" with uppercase letters.
Reported-By: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
utf8.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/utf8.c b/utf8.c
index a4ee665..e9850d0 100644
--- a/utf8.c
+++ b/utf8.c
@@ -487,6 +487,10 @@ char *reencode_string(const char *in, const char *out_encoding, const char *in_e
if (!in_encoding)
return NULL;
conv = iconv_open(out_encoding, in_encoding);
+ if (conv == (iconv_t) -1 && errno == EINVAL) {
+ conv = iconv_open(is_encoding_utf8(out_encoding) ? "UTF-8" : out_encoding,
+ is_encoding_utf8(in_encoding) ? "UTF-8" : in_encoding);
+ }
if (conv == (iconv_t) -1)
return NULL;
out = reencode_string_iconv(in, strlen(in), conv);
--
1.8.1.1
^ permalink raw reply related
* Re: [RFC] git rm -u
From: Antoine Pelisse @ 2013-02-25 18:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric James Michael Ritz, Tomas Carnecky, git
In-Reply-To: <7vzjys28a0.fsf@alter.siamese.dyndns.org>
I must say that I'm not very interested in the feature. In my opinion,
there are already many different ways to stage changes.
Assuming that the feature would be needed, I would keep it under the
scope of git-add, as it's the reference for staging. I would suggest
something like:
git add -r "Stage removal of deleted files."
On Mon, Feb 25, 2013 at 7:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Eric James Michael Ritz <lobbyjones@gmail.com> writes:
>
>> On 01/19/2013 04:49 PM, Antoine Pelisse wrote:
>>> I think `git add -u` would be closer. It would stage removal of
>>> files, but would not stage untracked files. It would stage other
>>> type of changes though.
>>
>> On Sat, Jan 19, 2013 at 10:47 PM, Tomas Carnecky
>>> Does `git add -A` do what you want?
>>
>> Thank you Tomas and Antoine. Both of these commands do what I want:
>> stage deleted files on the index. But does the idea of a `git rm -u`
>> still sound useful since these commands also stage changes besides
>> deleted files?
>
> Even though I am not sure how often I would use it myself, "reflect
> only the removals in the working tree to the index, but exclude any
> other kind of changes" might turn out to be a useful addition to the
> toolchest in certain cases.
>
> I however am not yet convinced that "git rm -u" is a good way to
> express the feature at the UI. "git add -u" is "update the index
> with modification and removal but ignore new files because we won't
> know if they are garbage or assets". What the same "-u" option
> means in the context of "git rm" is not very clear, at least to me.
>
>
^ permalink raw reply
* [PATCH 4/4] cat-file: print tags raw for "cat-file -p"
From: Jeff King @ 2013-02-25 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mantas Mikulėnas, git
In-Reply-To: <20130225183009.GB13912@sigill.intra.peff.net>
When "cat-file -p" prints commits, it shows them in their
raw format, since git's format is already human-readable.
For tags, however, we print the whole thing raw except for
one thing: we convert the timestamp on the tagger line into a
human-readable date.
This dates all the way back to a0f15fa (Pretty-print tagger
dates, 2006-03-01). At that time there was no way to
pretty-print a tag. These days "git show" does this already,
and is the normal tool for showing a pretty-printed output
("cat-file tag $tag" remains the preferred method for
showing porcelain output).
Let's drop this. It makes us more consistent with cat-file's
commit pretty-printer, and it means we can drop a whole
bunch of hand-rolled tag parsing code (which happened to
behave inconsistently with the tag pretty-printing code
elsewhere).
Note that "git verify-tag" and "git tag -v" depend on
"cat-file -p" to show the tag. This means they will start
showing the raw timestamp. We may want to adjust them to
use the pretty-printing code from "git show".
Signed-off-by: Jeff King <peff@peff.net>
---
I don't use "git tag -v" much, so I'm not sure what is sane there. But
this seems like it would be a regression for people who want to check
the human-readable date given by GPG against the date in the tag object.
I still think dropping this hand-rolled parsing is a good thing. The
most sane thing to me would be to move the parsing from "git show" into
the pretty-print code, then have both it and "verify-tag" use it.
Probably "for-each-ref" could stand to use it as well, as it has its own
home-grown parser.
builtin/cat-file.c | 71 -----------------------------------------------------
t/t1006-cat-file.sh | 5 +---
2 files changed, 1 insertion(+), 75 deletions(-)
diff --git a/builtin/cat-file.c b/builtin/cat-file.c
index 00528dd..b195edf 100644
--- a/builtin/cat-file.c
+++ b/builtin/cat-file.c
@@ -16,73 +16,6 @@
#define BATCH 1
#define BATCH_CHECK 2
-static void pprint_tag(const unsigned char *sha1, const char *buf, unsigned long size)
-{
- /* the parser in tag.c is useless here. */
- const char *endp = buf + size;
- const char *cp = buf;
-
- while (cp < endp) {
- char c = *cp++;
- if (c != '\n')
- continue;
- if (7 <= endp - cp && !memcmp("tagger ", cp, 7)) {
- const char *tagger = cp;
-
- /* Found the tagger line. Copy out the contents
- * of the buffer so far.
- */
- write_or_die(1, buf, cp - buf);
-
- /*
- * Do something intelligent, like pretty-printing
- * the date.
- */
- while (cp < endp) {
- if (*cp++ == '\n') {
- /* tagger to cp is a line
- * that has ident and time.
- */
- const char *sp = tagger;
- char *ep;
- unsigned long date;
- long tz;
- while (sp < cp && *sp != '>')
- sp++;
- if (sp == cp) {
- /* give up */
- write_or_die(1, tagger,
- cp - tagger);
- break;
- }
- while (sp < cp &&
- !('0' <= *sp && *sp <= '9'))
- sp++;
- write_or_die(1, tagger, sp - tagger);
- date = strtoul(sp, &ep, 10);
- tz = strtol(ep, NULL, 10);
- sp = show_date(date, tz, 0);
- write_or_die(1, sp, strlen(sp));
- xwrite(1, "\n", 1);
- break;
- }
- }
- break;
- }
- if (cp < endp && *cp == '\n')
- /* end of header */
- break;
- }
- /* At this point, we have copied out the header up to the end of
- * the tagger line and cp points at one past \n. It could be the
- * next header line after the tagger line, or it could be another
- * \n that marks the end of the headers. We need to copy out the
- * remainder as is.
- */
- if (cp < endp)
- write_or_die(1, cp, endp - cp);
-}
-
static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
{
unsigned char sha1[20];
@@ -133,10 +66,6 @@ static int cat_one_file(int opt, const char *exp_type, const char *obj_name)
buf = read_sha1_file(sha1, &type, &size);
if (!buf)
die("Cannot read object %s", obj_name);
- if (type == OBJ_TAG) {
- pprint_tag(sha1, buf, size);
- return 0;
- }
/* otherwise just spit out the data */
break;
diff --git a/t/t1006-cat-file.sh b/t/t1006-cat-file.sh
index d8b7f2f..da4ffbb 100755
--- a/t/t1006-cat-file.sh
+++ b/t/t1006-cat-file.sh
@@ -135,14 +135,11 @@ tag_size=$(strlen "$tag_content")
tag_content="$tag_header_without_timestamp 0000000000 +0000
$tag_description"
-tag_pretty_content="$tag_header_without_timestamp Thu Jan 1 00:00:00 1970 +0000
-
-$tag_description"
tag_sha1=$(echo_without_newline "$tag_content" | git mktag)
tag_size=$(strlen "$tag_content")
-run_tests 'tag' $tag_sha1 $tag_size "$tag_content" "$tag_pretty_content" 1
+run_tests 'tag' $tag_sha1 $tag_size "$tag_content" "$tag_content" 1
test_expect_success \
"Reach a blob from a tag pointing to it" \
--
1.8.1.4.4.g265d2fa
^ permalink raw reply related
* [PATCH 3/4] fsck: check "tagger" lines
From: Jeff King @ 2013-02-25 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mantas Mikulėnas, git
In-Reply-To: <20130225183009.GB13912@sigill.intra.peff.net>
The fsck_tag function does not check very much about tags at
all; it just makes sure that we were able to load the
pointed-to object during the parse_tag phase. This does
check some basic things (the "object" line is OK, and the
pointed-to object exists with the expected type).
We did not, however, check the "tagger" line at all; if they
exist, we should feed them to fsck_ident (and it is OK if
they do not, as early versions of git did not include them).
This patch runs through the whole tag object during
fsck_tag, similar to what we do in fsck_commit. Some of
these checks are technically redundant with just checking
that parse_tag filled in the "tag->tagged" field. However:
1. We have to parse through those lines anyway to get to
the tagger line, so we need to sanity check our
parsing.
2. We can give more specific errors (e.g., report a
malformed "object" line).
3. Previously we depended on implementation details of
parse_tag for our fsck (e.g., that it would never fill
in "tagged" if the types did not match). Now our
exhaustive checks are in one place, which makes it
easier to verify exactly what fsck is checking.
Signed-off-by: Jeff King <peff@peff.net>
---
Unfortunately, this causes t1050 to fail in an interesting way. It runs
"index-pack --strict" while setting GIT_DIR=nonexistent. As a result,
when we try to read the tag object from disk, we can't find it. We
don't run into the same problem verifying commits and trees, because
those objects leave the raw object data in their "buffer" field.
I'm tempted to call what that test is doing insane, but I wonder if
there is another corner case with running "index-pack --strict" as part
of an incoming push or fetch. I haven't investigated that yet.
fsck.c | 62 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++-
t/t1450-fsck.sh | 43 +++++++++++++++++++++++++++++++++++++++
2 files changed, 104 insertions(+), 1 deletion(-)
diff --git a/fsck.c b/fsck.c
index 99c0497..20d55c4 100644
--- a/fsck.c
+++ b/fsck.c
@@ -340,15 +340,75 @@ static int fsck_tag(struct tag *tag, fsck_error error_func)
return 0;
}
-static int fsck_tag(struct tag *tag, fsck_error error_func)
+static int fsck_tag_buffer(char *buf, struct tag *tag, fsck_error error_func)
{
struct object *tagged = tag->tagged;
+ unsigned char sha1[20];
+ char *eol;
+
+ buf = skip_prefix(buf, "object ");
+ if (!buf)
+ return error_func(&tag->object, FSCK_ERROR, "invalid format - expected 'object' line");
+ if (get_sha1_hex(buf, sha1) || buf[40] != '\n')
+ return error_func(&tag->object, FSCK_ERROR, "invalid 'object' line format - bad sha1");
+ buf += 41;
+ /*
+ * We already called parse_tag, so we don't have to bother looking up
+ * the sha1 again.
+ */
if (!tagged)
return error_func(&tag->object, FSCK_ERROR, "could not load tagged object");
+
+ buf = skip_prefix(buf, "type ");
+ if (!buf)
+ return error_func(&tag->object, FSCK_ERROR, "invalid format - expected 'type' line");
+ eol = strchr(buf, '\n');
+ if (!eol)
+ return error_func(&tag->object, FSCK_ERROR, "invalid format - truncation at 'type' line");
+ *eol = '\0';
+ if (type_from_string(buf) != tagged->type)
+ return error_func(&tag->object, FSCK_ERROR, "'type' line does not match type of tagged object");
+ *eol = '\n';
+
+ buf = skip_prefix(eol + 1, "tag ");
+ if (!buf)
+ return error_func(&tag->object, FSCK_ERROR, "invalid format - expected 'tag' line");
+ eol = strchr(buf, '\n');
+ if (!eol)
+ return error_func(&tag->object, FSCK_ERROR, "invalid format - truncation at 'tag' line");
+
+ /*
+ * A missing tagger is OK, as very old versions of git did not produce
+ * such a line. But if we do have it, we should verify its contents.
+ */
+ buf = skip_prefix(eol + 1, "tagger ");
+ if (buf) {
+ int err = fsck_ident(&buf, &tag->object, error_func);
+ if (err)
+ return err;
+ }
+
return 0;
}
+static int fsck_tag(struct tag *tag, fsck_error error_func)
+{
+ char *buf;
+ unsigned long size;
+ enum object_type type;
+ int err;
+
+ buf = read_sha1_file(tag->object.sha1, &type, &size);
+ if (!buf)
+ return error_func(&tag->object, FSCK_ERROR, "could not read tag object");
+
+ err = fsck_tag_buffer(buf, tag, error_func);
+
+ free(buf);
+ return err;
+}
+
int fsck_object(struct object *obj, int strict, fsck_error error_func)
{
if (!obj)
diff --git a/t/t1450-fsck.sh b/t/t1450-fsck.sh
index d730734..3a3bce6 100755
--- a/t/t1450-fsck.sh
+++ b/t/t1450-fsck.sh
@@ -180,6 +180,49 @@ test_expect_success 'tag pointing to something else than its type' '
test_must_fail git fsck --tags
'
+test_expect_success 'tag with missing tagger is OK' '
+ sha=$(echo blob | git hash-object -w --stdin) &&
+ test_when_finished "remove_object $sha" &&
+ cat >good-tag <<-EOF &&
+ object $sha
+ type blob
+ tag missing-tagger-ok
+
+ This is totally fine.
+ EOF
+
+ tag=$(git hash-object -t tag -w --stdin <good-tag) &&
+ test_when_finished "remove_object $tag" &&
+ git update-ref refs/tags/good $tag &&
+ test_when_finished "git update-ref -d refs/tags/good" &&
+ git fsck >out 2>&1 &&
+ >expect &&
+ test_cmp expect out
+'
+
+test_expect_success 'tag with bogus tagger is not OK' '
+ sha=$(echo blob | git hash-object -w --stdin) &&
+ test_when_finished "remove_object $sha" &&
+ cat >wrong-tag <<-EOF &&
+ object $sha
+ type blob
+ tag bogus-tagger
+ tagger T A Gger <tagger@example.com> Mon Feb 25 12:32:51 2013 -0500
+
+ That date is bogus (it should be an epoch + timezone). Any bogus ident
+ line should trigger, but this was chosen to match a breakage seen in
+ the wild.
+ EOF
+
+ tag=$(git hash-object -t tag -w --stdin <wrong-tag) &&
+ test_when_finished "remove_object $tag" &&
+ git update-ref refs/tags/wrong $tag &&
+ test_when_finished "git update-ref -d refs/tags/wrong" &&
+ git fsck --tags >out 2>&1 &&
+ cat out &&
+ grep "error in tag $tag.* - bad date" out
+'
+
test_expect_success 'cleaned up' '
git fsck >actual 2>&1 &&
test_cmp empty actual
--
1.8.1.4.4.g265d2fa
^ permalink raw reply related
* Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Mike Gorchak @ 2013-02-25 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzjysxnb1.fsf@alter.siamese.dyndns.org>
>> Fix is_date() function failings in detection of correct date in case
>> if time was not properly initialized.
>
> Please explain why this patch is needed and what problem this patch
> is trying to fix (if any) a bit better in the proposed log message.
> For example, on what input do we call this function with partially
> filled *r, and is that an error in the code, or is it an indication
> that the input has only been consumed partially?
function is_date() must not fail if time fields are not set. Currently
is_date() invokes tm_to_time_t() which perform check of time fields.
With these fixes t0006-date.sh test is no longer fail on these tests:
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -0500' '2008-02-14 20:30:45 -0500'
check_parse '2008-02-14 20:30:45 -0015' '2008-02-14 20:30:45 -0015'
check_parse '2008-02-14 20:30:45 -5' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -5:' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -05' '2008-02-14 20:30:45 -0500'
check_parse '2008-02-14 20:30:45 -:30' '2008-02-14 20:30:45 +0000'
check_parse '2008-02-14 20:30:45 -05:00' '2008-02-14 20:30:45 -0500'
By the way following test is always fails due to absence of EST5
timezone in timezones array in date.c module.
check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 -0500' EST5
> tm_to_time_t() is designed to reject underspecified date input, and
> its callers call is_date() starting with partially filled tm on
> purpose to reject such input. Doesn't "fixing" partially filled tm
> before calling tm_to_time_t() inside is_date() break that logic?
According to logic is_date() have no any relations with time
(hours/mins/secs). In the tests described above date is defined first,
before time, so at the point when date is checked for correctness time
is not defined yet.
Thanks.
^ permalink raw reply
* [PATCH/RFC 2/4] skip_prefix: return a non-const pointer
From: Jeff King @ 2013-02-25 18:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mantas Mikulėnas, git
In-Reply-To: <20130225183009.GB13912@sigill.intra.peff.net>
The const rules in C are such that one cannot write a
function that takes a const or non-const pointer and returns
a pointer that matches the input in const-ness. Instead, you
must take a const pointer (because you are promising not to
modify it), and then either return a const pointer (which is
safer, but annoying to callers who originally had a
non-const pointer) or a non-const pointer (less safe, as you
may accidentally drop constness, but less annoying).
This is a well-known problem, and the standard string
functions like strchr take the "less annoying" approach.
Let's mimic them. Even though this is technically less safe,
skip_prefix tends to be used alongside standard string
manipulation functions already, so it is not really
introducing a new problem.
Signed-off-by: Jeff King <peff@peff.net>
---
I have mixed feelings on this. It _is_ less safe, and this is a known
bug in the C standard. Still, it seems like the more idiomatic C thing
to do.
My main motivation is to avoid a bunch of casts in the next patch.
builtin/commit.c | 2 +-
git-compat-util.h | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/builtin/commit.c b/builtin/commit.c
index 3348aa1..bb6890b 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -895,7 +895,7 @@ static int template_untouched(struct strbuf *sb)
return 0;
stripspace(&tmpl, cleanup_mode == CLEANUP_ALL);
- start = (char *)skip_prefix(sb->buf, tmpl.buf);
+ start = skip_prefix(sb->buf, tmpl.buf);
if (!start)
start = sb->buf;
strbuf_release(&tmpl);
diff --git a/git-compat-util.h b/git-compat-util.h
index b7eaaa9..56c066b 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -320,10 +320,10 @@ static inline const char *skip_prefix(const char *str, const char *prefix)
extern int prefixcmp(const char *str, const char *prefix);
extern int suffixcmp(const char *str, const char *suffix);
-static inline const char *skip_prefix(const char *str, const char *prefix)
+static inline char *skip_prefix(const char *str, const char *prefix)
{
size_t len = strlen(prefix);
- return strncmp(str, prefix, len) ? NULL : str + len;
+ return strncmp(str, prefix, len) ? NULL : (char *)(str + len);
}
#if defined(NO_MMAP) || defined(USE_WIN32_MMAP)
--
1.8.1.4.4.g265d2fa
^ permalink raw reply related
* [PATCH 1/4] handle malformed dates in ident lines
From: Jeff King @ 2013-02-25 18:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mantas Mikulėnas, git
In-Reply-To: <20130225183009.GB13912@sigill.intra.peff.net>
The split_ident_line function is used by many code paths to
find the name, mail, and date fields of an identity line.
It will return failure when the output is completely
unparseable, but may return success (along with a NULL date
field) if the date is empty or malformed. Callers that care
about the date need to handle this situation explicitly, or
they will end up segfaulting as they feed the NULL date to
strtoul or similar.
There are basically three options:
1. Reject the ident line entirely (i.e., do the same thing
we would do if the name or email were missing). We
already use this strategy in git-commit's
determine_author_info.
2. Process the name and email, but refuse to work on any
date portions. format_person_part does this, and a
commit with such an ident would yield an empty string
for "--format=%at".
3. Proceed with some obviously bogus sentinel value for
the time (e.g., the start of the epoch).
Only two of the existing callers read the date but do not
handle this case at all: pp_user_info and git-blame's
get_ac_line. This patch modifies both to use option (3). The
hope is that this is friendly (we still produce some output)
but the epoch start date will give the user a clue that the
date is not valid.
Signed-off-by: Jeff King <peff@peff.net>
---
Having written that, I feel like the case for doing (3) is somewhat
flimsy. I don't know that it really matters that much either way, but
I'd be just as happy to do any of the others.
In fact, I really wonder if split_ident_line shouldn't simply be
returning error in such a case. The comment above it claims that reflogs
do not have such a timestamp, but they do. I suspect it is a weird
interaction of the reflog walker on format_person_part, but I haven't
checked. I wonder if we can simply fix the reflog code to pass a string
with the date in the usual way (since we _should_ have it at some
point). If not, then we can perhaps make things safer for other callers
with a wrapper like:
/* safe default version */
int split_ident_line(...)
{
/* calls less safe but more flexible version; i.e., the
* existing one */
if (split_ident_line_date_optional(...) < 0)
return -1;
if (!ident.date_begin)
return -1;
return 0;
}
builtin/blame.c | 13 +++++++++----
pretty.c | 15 ++++++++++++---
2 files changed, 21 insertions(+), 7 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 86100e9..2edff25 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -1375,10 +1375,15 @@ static void get_ac_line(const char *inbuf, const char *what,
maillen = ident.mail_end - ident.mail_begin;
mailbuf = ident.mail_begin;
- *time = strtoul(ident.date_begin, NULL, 10);
-
- len = ident.tz_end - ident.tz_begin;
- strbuf_add(tz, ident.tz_begin, len);
+ if (ident.date_begin) {
+ *time = strtoul(ident.date_begin, NULL, 10);
+ len = ident.tz_end - ident.tz_begin;
+ strbuf_add(tz, ident.tz_begin, len);
+ }
+ else {
+ *time = 0;
+ strbuf_addstr(tz, "-0000");
+ }
/*
* Now, convert both name and e-mail using mailmap
diff --git a/pretty.c b/pretty.c
index eae57ad..4b19908 100644
--- a/pretty.c
+++ b/pretty.c
@@ -391,7 +391,7 @@ void pp_user_info(const struct pretty_print_context *pp,
struct strbuf mail;
struct ident_split ident;
int linelen;
- char *line_end, *date;
+ char *line_end;
const char *mailbuf, *namebuf;
size_t namelen, maillen;
int max_length = 78; /* per rfc2822 */
@@ -428,8 +428,17 @@ void pp_user_info(const struct pretty_print_context *pp,
strbuf_add(&name, namebuf, namelen);
namelen = name.len + mail.len + 3; /* ' ' + '<' + '>' */
- time = strtoul(ident.date_begin, &date, 10);
- tz = strtol(date, NULL, 10);
+
+ if (ident.date_begin) {
+ char *date;
+ time = strtoul(ident.date_begin, &date, 10);
+ tz = strtol(date, NULL, 10);
+ }
+ else {
+ /* ident has missing or malformed date */
+ time = 0;
+ tz = 0;
+ }
if (pp->fmt == CMIT_FMT_EMAIL) {
strbuf_addstr(sb, "From: ");
--
1.8.1.4.4.g265d2fa
^ permalink raw reply related
* [PATCH 1/1] Add getpagesize() function detection to configure script
From: Mike Gorchak @ 2013-02-25 18:34 UTC (permalink / raw)
To: git
Add detection of getpagesize() function in libc. Declare
empty "NO_GETPAGESIZE" macro in case if getpagesize()
exists and "NO_GETPAGESIZE=YesPlease" if no.
Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
---
configure.ac | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/configure.ac b/configure.ac
index d0e82c1..3963429 100644
--- a/configure.ac
+++ b/configure.ac
@@ -993,6 +993,11 @@ GIT_CHECK_FUNC(initgroups,
[NO_INITGROUPS=YesPlease])
GIT_CONF_SUBST([NO_INITGROUPS])
#
+# Define NO_GETPAGESIZE if you don't have getpagesize in the C library.
+GIT_CHECK_FUNC(getpagesize,
+[NO_GETPAGESIZE=],
+[NO_GETPAGESIZE=YesPlease])
+GIT_CONF_SUBST([NO_GETPAGESIZE])
#
# Define NO_MMAP if you want to avoid mmap.
#
--
1.8.2-rc0
^ permalink raw reply related
* Re: Possible regression in ref advertisement
From: Junio C Hamano @ 2013-02-25 18:31 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1361811516.3212.14.camel@centaur.cmartin.tk>
Carlos Martín Nieto <cmn@elego.de> writes:
> Hi all,
>
> When testing to see if a different implementation was in shape, I came
> across something odd where newer git doesn't advertise one of the refs
> in the git repo.
>
> Running `git ls-remote .` or `git-upload-pack` in my git repo, newer git
> versions omit peeling the v1.8.0-rc3 tag.
>
> The diff between the command above when ran with 1.7.10.4 (from Debian)
> and current 'master'
>
> --- old 2013-02-25 17:31:29.583526606 +0100
> +++ new 2013-02-25 17:31:36.783526559 +0100
> @@ -1379,7 +1379,6 @@
> c15295d7477ccec489953299bd03a8e62f86e611 refs/tags/v1.8.0-rc2
> cd46259ebf2e624bcee2aaae05c36663d414e1a2 refs/tags/v1.8.0-rc2^{}
> 22ed067acc84eac8a0a72d20478a18aee4e25571 refs/tags/v1.8.0-rc3
> -87a5461fa7b30f7b7baf27204f10219d61500fbf refs/tags/v1.8.0-rc3^{}
> bfeb8b9ae0012cb61e026cbcd29664876abf5389 refs/tags/v1.8.0.1
> ed9fe755130891fc878bb2433204faffb534697b refs/tags/v1.8.0.1^{}
> 63add1fb45e1ab7a76bb38bbb9467c91fdfaaa7e refs/tags/v1.8.0.2
>
> Diffing with the output from next, diff tells me it's binary for some
> reason, but looking manually, the peeled v1.8.0-rc3 tag isn't there
> either. I haven't had time to bisect this, so I'm putting it out there
> in case anybody wants to investigate before I have time to dig into it.
Interesting. "git ls-remote . | grep 1.8.0-" for maint, master,
next and pu produce identical results for me, all showing peeled
ones correctly.
^ permalink raw reply
* Re: Crashes while trying to show tag objects with bad timestamps
From: Jeff King @ 2013-02-25 18:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Mantas Mikulėnas, git
In-Reply-To: <7vppzsaqc5.fsf@alter.siamese.dyndns.org>
On Fri, Feb 22, 2013 at 03:20:10PM -0800, Junio C Hamano wrote:
> As pp_user_info() is called from very few places, I do not think it
> is unreasonable to add an output parameter (i.e. "unsigned *") to
> let the caller know that we made a best guess given malformed input
> and handle the error in the caller. The make_cover_letter() caller
> may look like:
>
> pp_user_info(&pp, NULL, &sb, committer, encoding, &errors);
> if (errors & PP_CORRUPT_DATE)
> warning("unparsable datestamp in '%s'", committer);
>
> although it is unlikely to see this error in practice, given that
> committer is coming from git_committer_info(0) and would have the
> current timestamp.
Sadly that is not quite enough for the object-parsing cases (which are
the ones we _really_ want to add context to, because they are buried
inside other pp_* calls. Probably adding an object context field (or an
error return) to the pretty-print context would make sense. But I don't
relish the thought of annotating each pretty-print caller.
I think we're OK to be silent and just react in an appropriate way;
having looked over the other callers of split_ident_line, we already do
so in some places. See my patch 1 below for details.
Once fsck is taught to note this, then the warning is a lot less
important (my patch 3 below).
> The whole "cat-file -p" is a historical wart, aka poor-man's
> "show". I do not even consider it a part of the plumbing. It is a
> fair game for Porcelainisque improvement ;-)
Good, that's how I feel, too. See my patch 4. :)
Here are the patches I'd like to do:
[1/4]: handle malformed dates in ident lines
[2/4]: skip_prefix: return a non-const pointer
[3/4]: fsck: check "tagger" lines
[4/4]: cat-file: print tags raw for "cat-file -p"
The first one is solid, and should probably go to maint and/or the -rc
track, as it fixes a segfault on bogus input. It's hopefully a
no-brainer, as the existing behavior is obviously unacceptable. We may
change our mind later about exactly what to print for such bogus input,
but whatever we print in such a case is just trying to be nice to the
user, and anybody who depends on our particular handling of malformed
objects is crazy.
The rest can wait, as they are about improving output when fed bogus
input, or tightening fsck. Moreover, they have some problems which make
them not suitable for applying yet. I'll give details in each patch.
-Peff
^ permalink raw reply
* Re: [PATCH 1/1] Fix date checking in case if time was not initialized.
From: Junio C Hamano @ 2013-02-25 18:26 UTC (permalink / raw)
To: Mike Gorchak; +Cc: git
In-Reply-To: <CAHXAxrOOqn6ZSVT1AFyO3a3paD1tokBtcnaX68a+ddhodOvZ6Q@mail.gmail.com>
Mike Gorchak <mike.gorchak.qnx@gmail.com> writes:
> Fix is_date() function failings in detection of correct date in case
> if time was not properly initialized.
Please explain why this patch is needed and what problem this patch
is trying to fix (if any) a bit better in the proposed log message.
For example, on what input do we call this function with partially
filled *r, and is that an error in the code, or is it an indication
that the input has only been consumed partially?
tm_to_time_t() is designed to reject underspecified date input, and
its callers call is_date() starting with partially filled tm on
purpose to reject such input. Doesn't "fixing" partially filled tm
before calling tm_to_time_t() inside is_date() break that logic?
> From: Mike Gorchak <mike.gorchak.qnx@gmail.com>
> Signed-off-by: Mike Gorchak <mike.gorchak.qnx@gmail.com>
> ---
> date.c | 12 +++++++++++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/date.c b/date.c
> index 57331ed..ec758f4 100644
> --- a/date.c
> +++ b/date.c
> @@ -357,6 +357,7 @@ static int is_date(int year, int month, int day,
> struct tm *now_tm, time_t now,
> if (month > 0 && month < 13 && day > 0 && day < 32) {
> struct tm check = *tm;
> struct tm *r = (now_tm ? &check : tm);
> + struct tm fixed_r;
> time_t specified;
>
> r->tm_mon = month - 1;
> @@ -377,7 +378,16 @@ static int is_date(int year, int month, int day,
> struct tm *now_tm, time_t now,
> if (!now_tm)
> return 1;
>
> - specified = tm_to_time_t(r);
> + /* Fix tm structure in case if time was not initialized */
> + fixed_r = *r;
> + if (fixed_r.tm_hour==-1)
> + fixed_r.tm_hour=0;
> + if (fixed_r.tm_min==-1)
> + fixed_r.tm_min=0;
> + if (fixed_r.tm_sec==-1)
> + fixed_r.tm_sec=0;
> +
> + specified = tm_to_time_t(&fixed_r);
>
> /* Be it commit time or author time, it does not make
> * sense to specify timestamp way into the future. Make
^ permalink raw reply
* Re: Crashes while trying to show tag objects with bad timestamps
From: Jeff King @ 2013-02-25 18:21 UTC (permalink / raw)
To: Mantas Mikulėnas; +Cc: Junio C Hamano, git
In-Reply-To: <CAPWNY8UMkxvLPk2TxCz+BAat1sNXitjhv=yqcdY0yZ1OLjgd0w@mail.gmail.com>
On Sat, Feb 23, 2013 at 01:14:40AM +0200, Mantas Mikulėnas wrote:
> > Then I think it would make sense to allow the very specific no-date tag,
> > but not allow arbitrary crud. I wonder if there's an example in the
> > kernel or in git.git.
>
> I couldn't find any such examples. However, I did find several tags
> with no "tagger" line at all: git.git has "v0.99" and linux.git has
> many such tags starting with "v2.6.11" ending with "v2.6.13-rc3".
Yes, I think Junio was mis-remembering the exact condition. It looks
like we added tagger lines in c818566 ([PATCH] Update tags to record who
made them, 2005-07-14), which pulls the identity straight from "git var
GIT_COMMITTER_IDENT". I double-checked to be sure that we included the
date stamp at that time, and we did.
When parsing such a tag, we put a "0" in the date field of the "struct
tag", and I suspect that is what caused the memory confusion.
So I think we are fine to fsck tagger lines as we do ordinary
author/committer ident lines; the only exception is that we should not
complain if they do not exist.
> It seems that `git cat-file -p` doesn't like such tags too – if there
> is no "tagger", it doesn't display *any* header lines. More bugs?
Yeah, I think we should just rid of that parser entirely. It is very
inconsistent with the pretty-printer used by "git show", as well as the
one used by "git for-each-ref", not to mention parse_tag (ugh, how many
tag parsers do we have?).
-Peff
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox