* Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
From: Matthieu Moy @ 2012-11-29 18:47 UTC (permalink / raw)
To: Jeff King; +Cc: git, gitster
In-Reply-To: <20121129181141.GA17309@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> So technically, your modification to the beginning of the sentence is
> not correct.
I'd say the resulting sentence is somehow incorrect, but not more than
the previous one (both say "if ..." without really telling what the
condition was).
>> If an `LF`, backslash or double quote must be encoded
> ^
> missing comma as list delimiter
Google tells me that my version was UK-correct but not US-correct. As
french, I have no opinion on the subject, I take yours ;-).
How about this:
A path can use the C-style string quoting (this is accepted in all
cases and mandatory if the filename starts with double quote or
contains `LF`). In C-style quoting, `LF`, backslash, and double quote
characters must be escaped by preceding them with a backslash. Also,
the complete name should be surrounded with double quotes (e.g.
`"path/with\n, \\ and \" in it"`).
This should be technically correct, and "this is accepted in all cases"
should encourrage people to use it.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: Re: [PATCH v4 0/4] git-submodule add: Add --local-branch option
From: Phil Hord @ 2012-11-29 18:51 UTC (permalink / raw)
To: W. Trevor King
Cc: Heiko Voigt, Junio C Hamano, Git, Jeff King, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <20121128024205.GG15213@odin.tremily.us>
On Tue, Nov 27, 2012 at 6:28 PM, Heiko Voigt <hvoigt@hvoigt.net> wrote:
>
> Hi,
>
> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
> > The v4 series leaves the remote branch amigious, but it helps you
> > point the local branch at the right hash so that future calls to
> >
> > $ git submodule foreach 'git pull'
> >
> > can use the branch's .git/modules/<name>/config settings.
>
> But IMO thats the functionality which should be implemented in submodule
> update and not left to the user.
>
> > > I would think more of some convention like:
> > >
> > > $ git checkout -t origin/$branch
> > >
> > > when first initialising the submodule with e.g.
> > >
> > > $ git submodule update --init --branch
> > >
> > > Then later calls of
> > >
> > > $ git submodule update --branch
> > >
> > > would have a branch configured to pull from. I imagine that results in
> > > a similar behavior gerrit is doing on the server side?
> >
> > That sounds like it's doing pretty much the same thing. Can you think
> > of a test that would distinguish it from my current v4 implementation?
>
> Well the main difference is that gerrit is automatically updating the
> superproject AFAIK. I would like it if we could implement the same
> workflow support in the submodule script. It seems to me that this is
> already proven to be useful workflow.
It is proven in Gerrit, but Gerrit implements a central-server
workflow. That is, only Gerrit ever floats the submodules, and he
pushes the result for everyone else to share. I fear the consequences
of everyone pulling submodules and then later trying to merge
superprojects with someone else's breadcrumbs.
Do you have some idea how this would be handled?
Phil
ps. Apologies for my lateness on this topic. I'm trying to catch up now.
pps. Re-sent since Gmail has hidden the "plain text" option in a
different place, now.
On Tue, Nov 27, 2012 at 9:42 PM, W. Trevor King <wking@tremily.us> wrote:
> On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote:
>> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
>> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
>> > The v4 series leaves the remote branch amigious, but it helps you
>> > point the local branch at the right hash so that future calls to
>> >
>> > $ git submodule foreach 'git pull'
>> >
>> > can use the branch's .git/modules/<name>/config settings.
>>
>> But IMO thats the functionality which should be implemented in submodule
>> update and not left to the user.
>
> Then you might need submodule.<name>.local-branch,
> submodule.<name>.remote-repository, and submodule.<name>.remote-branch
> to configure
>
> $ git checkout submodule.<name>.local-branch
> $ git pull submodule.<name>.remote-repository submodule.<name>.remote-branch
>
> and this would ignore the $sha1 stored in the gitlink (which all of
> the other update commands use). This ignoring-the-$sha1 bit made me
> think that a built-in pull wasn't a good fit for 'submodule update'.
> Maybe if it went into a new 'submodule pull'? Then users have a clear
> distinction:
>
> * 'update' to push superproject $sha1 changes into the submodules
> * 'pull' to push upstream-branch changes into the submodules
>
>> > > I would think more of some convention like:
>> > >
>> > > $ git checkout -t origin/$branch
>> > >
>> > > when first initialising the submodule with e.g.
>> > >
>> > > $ git submodule update --init --branch
>> > >
>> > > Then later calls of
>> > >
>> > > $ git submodule update --branch
>> > >
>> > > would have a branch configured to pull from. I imagine that results in
>> > > a similar behavior gerrit is doing on the server side?
>> >
>> > That sounds like it's doing pretty much the same thing. Can you think
>> > of a test that would distinguish it from my current v4 implementation?
>>
>> Well the main difference is that gerrit is automatically updating the
>> superproject AFAIK. I would like it if we could implement the same
>> workflow support in the submodule script. It seems to me that this is
>> already proven to be useful workflow.
>
> Ah, sorry, I meant the configuring which remote branch you were
> pulling from happens at submodule initialization (via .git/modules/…)
> for both your workflow and my v4.
>
> You're right that having a builtin pull is different from my v4.
>
>> https://github.com/hvoigt/git/commits/hv/floating_submodules_draft
>
> I looked over this before, but maybe not thoroughly enough ;).
>
>> > > How about reusing the -b|--branch option for add? Since we only change
>> > > the behavior when submodule.$name.update is set to branch it seems
>> > > reasonable to me. Opinions?
>> >
>> > That was the approach I used in v1, but people were concerned that we
>> > would be stomping on previously unclaimed config space. Since noone
>> > has pointed out other uses besides Gerrit's very similar case, I'm not
>> > sure if that is still an issue.
>>
>> Could you point me to that mail? I cannot seem to find it in my archive.
>
> Hmm. It seems like Phil's initial response was (accidentally?) off
> list. The relevant portion was:
>
> On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:
>> Some projects now use the 'branch' config value to record the tracking
>> branch for the submodule. Some ascribe different meaning to the
>> configuration if the value is given vs. undefined. For example, see
>> the Gerrit submodule-subscription mechanism. This change will cause
>> those workflows to behave differently than they do now.
>>
>> I do like the idea, but I wish it had a different name for the
>> recording. Maybe --record-branch=${BRANCH} as an extra switch so the
>> action is explicitly requested.
>
> As I said, I'm happy to go back to --branch if opinions have changed.
>
> On Wed, Nov 28, 2012 at 12:28:58AM +0100, Heiko Voigt wrote:
>> On Tue, Nov 27, 2012 at 02:01:05PM -0500, W. Trevor King wrote:
>> > On Tue, Nov 27, 2012 at 07:31:25PM +0100, Heiko Voigt wrote:
>> > > > Because you need to recurse through submodules for `update --branch`
>> > > > even if "$subsha1" == "$sha1", I had to amend the conditional
>> > > > controlling that block. This broke one of the existing tests, which I
>> > > > "fixed" in patch 4. I think a proper fix would involve rewriting
>> > > >
>> > > > (clear_local_git_env; cd "$sm_path" &&
>> > > > ( (rev=$(git rev-list -n 1 $sha1 --not --all 2>/dev/null) &&
>> > > > test -z "$rev") || git-fetch)) ||
>> > > > die "$(eval_gettext "Unable to fetch in submodule path '\$sm_path'")"
>> > > >
>> > > > but I'm not familiar enough with rev-list to want to dig into that
>> > > > yet. If feedback for the earlier three patches is positive, I'll work
>> > > > up a clean fix and resubmit.
>> > >
>> > > You probably need to separate your handling here. The comparison of the
>> > > currently checked out sha1 and the recorded sha1 is an optimization
>> > > which skips unnecessary fetching in case the submodules commits are
>> > > already correct. This code snippet checks whether the to be checked out
>> > > sha1 is already local and also skips the fetch if it is. We should not
>> > > break that.
>> >
>> > Agreed. However, determining if the target $sha1 is local should have
>> > nothing to do with the current checked out $subsha1.
>>
>> See my draft or the diff below for an illustration of the splitup.
>>
>> [snip diff]
>
> This looks fine, but my current --branch implementation (which doesn't
> pull) is only a thin branch-checkout layer on top of the standard
> `update` functionality. I'm still unsure if built-in pulls are worth
> the configuration trouble. I'll sleep on it. Maybe I'll feel better
> about them tomorrow ;).
>
> Cheers,
> Trevor
>
> --
> This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
> For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
^ permalink raw reply
* Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
From: Jeff King @ 2012-11-29 18:54 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, gitster
In-Reply-To: <vpqhao8gsaj.fsf@grenoble-inp.fr>
On Thu, Nov 29, 2012 at 07:47:32PM +0100, Matthieu Moy wrote:
> Jeff King <peff@peff.net> writes:
>
> > So technically, your modification to the beginning of the sentence is
> > not correct.
>
> I'd say the resulting sentence is somehow incorrect, but not more than
> the previous one (both say "if ..." without really telling what the
> condition was).
That's fair. There is a lot left unsaid in the original. :)
> >> If an `LF`, backslash or double quote must be encoded
> > ^
> > missing comma as list delimiter
>
> Google tells me that my version was UK-correct but not US-correct. As
> french, I have no opinion on the subject, I take yours ;-).
Thanks, I had a vague recollection that it might be regional. I probably
should have looked it up myself.
> How about this:
>
> A path can use the C-style string quoting (this is accepted in all
> cases and mandatory if the filename starts with double quote or
> contains `LF`). In C-style quoting, `LF`, backslash, and double quote
> characters must be escaped by preceding them with a backslash. Also,
> the complete name should be surrounded with double quotes (e.g.
> `"path/with\n, \\ and \" in it"`).
>
> This should be technically correct, and "this is accepted in all cases"
> should encourrage people to use it.
I think that is much better, but it reads a little more easily to me if
we rearrange the second sentence. To complete my English bikeshedding,
here is how I would have written the whole paragraph:
A path can use C-style string quoting; this is accepted in all cases
and mandatory if the filename starts with double quote or contains
`LF`. In C-style quoting, the complete name should be surrounded with
double quotes, and any `LF`, backslash, or double quote characters
must be escaped by preceding them with a backslash (e.g.,
`"path/with\n, \\ and \" in it"`).
Feel free to incorporate or ignore any of my tweaks from that version.
-Peff
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Eric S. Raymond @ 2012-11-29 19:02 UTC (permalink / raw)
To: Junio C Hamano
Cc: Felipe Contreras, Steven Michalske, Thomas Berg, Jeff King,
Shawn Pearce, git
In-Reply-To: <7vtxs8qs1r.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com>:
> That is exactly why I said it is all relative. If it helps your
> application, you can weigh the pros-and-cons yourself and choose to
> throw "junk" extended header fields in the commit objects you
> create, using hash-object (or commit-tree). You can read it out
> using cat-file and do whatever you want to do with it, and modern
> Git (v1.5.0 was from early 2007) and tools that are designed to work
> with Git know to ignore such "junk" field.
A good start. But remember that reposurgeon's entire interface to the
git object level is through fast-export/fast-import. I need import-
stream syntax for these.
bzr's syntax would do:
-------------------------------------------
mark :1
committer Eric S. Raymond <esr@thyrsus.com> 1289147634 -0500
data 14
First commit.
property branch-nick 12 bzr-testrepo
M 644 inline README
data 41
This is a test file in a dummy bzr repo.
-------------------------------------------
If we actually care about keys being full utf-8 with embedded whitespace
it should look more like this:
-------------------------------------------
mark :1
committer Eric S. Raymond <esr@thyrsus.com> 1289147634 -0500
data 14
First commit.
property 11
branch-nick
propval 12
bzr-testrepo
M 644 inline README
data 41
This is a test file in a dummy bzr repo.
-------------------------------------------
--
<a href="http://www.catb.org/~esr/">Eric S. Raymond</a>
^ permalink raw reply
* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Martin von Zweigbergk @ 2012-11-29 19:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4nk8qmaj.fsf@alter.siamese.dyndns.org>
On Thu, Nov 29, 2012 at 10:47 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>
>> In cases where HEAD is not supposed to be updated, there is no reason
>> that "git reset" should require a commit, a tree should be enough. So
>> make "git reset $rev^{tree}" work just like "git reset $rev", except
>> that the former will not update HEAD (since there is no commit to
>> point it to).
>
> That is a horrible design I have to nack, unless you require
> pathspec. You cannot tell what "git reset $sha1" would do without
> checking the type of the object $sha1 refers to. If you do this
> only when pathspec is present, then the design is very reasonable.
Very good point. Thanks! I now see that "git checkout" also requires a
path when given a tree.
So then "git reset" on an unborn branch would imply "git reset
$empty_tree -- ." instead. And "git reset --hard $tree" would not be
allowed. And the intersection of these -- "git reset --hard" on and
unborn branch -- would also not work. Would the correct fix be to
first make "git reset --hard -- $path" work (*sigh*)? I have never
understood why that doesn't (shouldn't) work.
^ permalink raw reply
* [PATCH 1/2 v3] git-fast-import.txt: improve documentation for quoted paths
From: Matthieu Moy @ 2012-11-29 19:11 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <20121129185404.GC17309@sigill.intra.peff.net>
The documentation mentionned only newlines and double quotes as
characters needing escaping, but the backslash also needs it. Also, the
documentation was not clearly saying that double quotes around the file
name were required (double quotes in the examples could be interpreted as
part of the sentence, not part of the actual string).
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
cut-and-paste of Peff's version, adapted from mine.
Documentation/git-fast-import.txt | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
index 959e4d3..d1844ea 100644
--- a/Documentation/git-fast-import.txt
+++ b/Documentation/git-fast-import.txt
@@ -562,8 +562,12 @@ A `<path>` string must use UNIX-style directory separators (forward
slash `/`), may contain any byte other than `LF`, and must not
start with double quote (`"`).
-If an `LF` or double quote must be encoded into `<path>` shell-style
-quoting should be used, e.g. `"path/with\n and \" in it"`.
+A path can use C-style string quoting; this is accepted in all cases
+and mandatory if the filename starts with double quote or contains
+`LF`. In C-style quoting, the complete name should be surrounded with
+double quotes, and any `LF`, backslash, or double quote characters
+must be escaped by preceding them with a backslash (e.g.,
+`"path/with\n, \\ and \" in it"`).
The value of `<path>` must be in canonical form. That is it must not:
--
1.8.0.319.g8abfee4
^ permalink raw reply related
* [PATCH 2/2 v3] git-remote-mediawiki: escape ", \, and LF in file names
From: Matthieu Moy @ 2012-11-29 19:11 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1354216293-21921-1-git-send-email-Matthieu.Moy@imag.fr>
A mediawiki page can contain, and even start with a " character, we have
to escape it when generating the fast-export stream, as well as \
character. While we're there, also escape newlines, but I don't think we
can get them from MediaWiki pages.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
contrib/mw-to-git/git-remote-mediawiki | 16 +++++++++++++---
contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh | 26 ++++++++++++++++++++++++++
2 files changed, 39 insertions(+), 3 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki b/contrib/mw-to-git/git-remote-mediawiki
index 68555d4..094129d 100755
--- a/contrib/mw-to-git/git-remote-mediawiki
+++ b/contrib/mw-to-git/git-remote-mediawiki
@@ -711,6 +711,14 @@ sub fetch_mw_revisions {
return ($n, @revisions);
}
+sub fe_escape_path {
+ my $path = shift;
+ $path =~ s/\\/\\\\/g;
+ $path =~ s/"/\\"/g;
+ $path =~ s/\n/\\n/g;
+ return '"' . $path . '"';
+}
+
sub import_file_revision {
my $commit = shift;
my %commit = %{$commit};
@@ -738,15 +746,17 @@ sub import_file_revision {
print STDOUT "from refs/mediawiki/$remotename/master^0\n";
}
if ($content ne DELETED_CONTENT) {
- print STDOUT "M 644 inline $title.mw\n";
+ print STDOUT "M 644 inline " .
+ fe_escape_path($title . ".mw") . "\n";
literal_data($content);
if (%mediafile) {
- print STDOUT "M 644 inline $mediafile{title}\n";
+ print STDOUT "M 644 inline "
+ . fe_escape_path($mediafile{title}) . "\n";
literal_data_raw($mediafile{content});
}
print STDOUT "\n\n";
} else {
- print STDOUT "D $title.mw\n";
+ print STDOUT "D " . fe_escape_path($title . ".mw") . "\n";
}
# mediawiki revision number in the git note
diff --git a/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh b/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
index 246d47d..b6405ce 100755
--- a/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
+++ b/contrib/mw-to-git/t/t9362-mw-to-git-utf8.sh
@@ -318,4 +318,30 @@ test_expect_success 'git push with \ in format control' '
'
+test_expect_success 'fast-import meta-characters in page name (mw -> git)' '
+ wiki_reset &&
+ wiki_editpage \"file\"_\\_foo "expect to be called \"file\"_\\_foo" false &&
+ git clone mediawiki::'"$WIKI_URL"' mw_dir_21 &&
+ test_path_is_file mw_dir_21/\"file\"_\\_foo.mw &&
+ wiki_getallpage ref_page_21 &&
+ test_diff_directories mw_dir_21 ref_page_21
+'
+
+
+test_expect_success 'fast-import meta-characters in page name (git -> mw) ' '
+ wiki_reset &&
+ git clone mediawiki::'"$WIKI_URL"' mw_dir_22 &&
+ (
+ cd mw_dir_22 &&
+ echo "this file is called \"file\"_\\_foo.mw" >\"file\"_\\_foo &&
+ git add . &&
+ git commit -am "file \"file\"_\\_foo" &&
+ git pull &&
+ git push
+ ) &&
+ wiki_getallpage ref_page_22 &&
+ test_diff_directories mw_dir_22 ref_page_22
+'
+
+
test_done
--
1.8.0.319.g8abfee4
^ permalink raw reply related
* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Junio C Hamano @ 2012-11-29 19:13 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <7v4nk8qmaj.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Martin von Zweigbergk <martinvonz@gmail.com> writes:
>
>> In cases where HEAD is not supposed to be updated, there is no reason
>> that "git reset" should require a commit, a tree should be enough. So
>> make "git reset $rev^{tree}" work just like "git reset $rev", except
>> that the former will not update HEAD (since there is no commit to
>> point it to).
>
> That is a horrible design I have to nack, unless you require
> pathspec. You cannot tell what "git reset $sha1" would do without
> checking the type of the object $sha1 refers to. If you do this
> only when pathspec is present, then the design is very reasonable.
The above applies to an _arbitrary_ $sha1.
Allowing "reset $tree -- $pathspec" is a very good addition in the
same sense that "git checkout $tree -- $pathspec" is useful. These
two commands, "reset" and "checkout", share that the source we grab
the blobs out of only need to be a tree and does not have to be a
commit, and the only difference between them is where the blobs we
grabbed out of that tree go, either only to the index or to both the
index and the working tree.
But I do not think it is connected, at least at the level the end
users perceive, to the issue of "reset" issued while on an unborn
branch.
If you limit the scope of the behaviour change exposed to the end
users so that you would make
$ git reset [HEAD]
act as a short-hand for
$ rm -f $GIT_DIR/index
when HEAD points at an unborn branch, and similarly make
$ git reset --hard [HEAD]
act as a short-hand for
$ rm -f $GIT_DIR/index
$ git clean -f -d
in such a case, I do not think it is unreasonable at all.
In such a case,
$ git reset --soft [HEAD]
would become just a no-op. Earlier you were on an unborn branch,
and after "reset --soft", nothing changes.
Hmm?
^ permalink raw reply
* Re: [PATCH v5 0/2] submodule update: add --remote for submodule's upstream changes
From: W. Trevor King @ 2012-11-29 19:13 UTC (permalink / raw)
To: Git, Phil Hord
Cc: Junio C Hamano, Heiko Voigt, Jeff King, Shawn Pearce,
Jens Lehmann, Nahor
In-Reply-To: <cover.1354130656.git.wking@tremily.us>
[-- Attachment #1: Type: text/plain, Size: 1990 bytes --]
On Thu, Nov 29, 2012 at 01:29:12PM -0500, Phil Hord wrote:
> On Fri, Nov 23, 2012 at 12:54 PM, W. Trevor King <wking@tremily.us> wrote:
> > [snip initial thoughts leading to the update --remote v5]
>
> I was thinking the same thing, but reading this whole thread a couple of
> weeks late. Thanks for noticing.
>
> Moreover, I think that 'git submodule update --pull' is also the wrong way
> to spell this action. Maybe you are misled from the outset by your
> current workflow:
Did you see my v5 (add --remote) series?
> For that reason, I don't like the --pull switch since it implies a
> fetch, but I will not always want to do a fetch.
$ git submodule update --remote --no-fetch
will not fetch the submodule remotes.
> I don't know which remote I should be tracking, though. I suppose
> it is 'origin' for now, but maybe it is just whatever
> $superproject's HEAD's remote-tracking branch indicates.
With the --remote series, I always use "origin" because that's what
`submodule add` should be setting up. If people want to change that
up by hand, we may need a submodule.<name>.remote configuration
option.
> I am not sure I want the gitlinks in superproject to update automatically
> in the index, but I definitely do not want to automatically create a commit
> for them.
Commits are dissabled by default (see my recent --commit RFC for how
they would be enabled).
> But I really don't want to figure out how to handle submodule
> collisions during a merge (or rebase!) of my superproject with changes that
> someone else auto-committed in his local $superproject as he and I
> arbitrarily floated up the upstream independently. There is nothing but
> loathing down that path.
This is true. I'm not sure how gitlink collisions are currently
handled…
Trevor
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Phil Hord @ 2012-11-29 19:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Shawn Pearce, Felipe Contreras, Eric Raymond, git
In-Reply-To: <7v7gp6i3rx.fsf@alter.siamese.dyndns.org>
On Wed, Nov 28, 2012 at 2:29 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Jeff King <peff@peff.net> writes:
>
>> There is room for new headers, and older versions of git will ignore
>> them. You could add a new "committer-timestamp" field that elaborates on
>> the timestamp included on the committer line. Newer versions of git
>> would respect it, and older versions would fall back to using the
>> committer timestamp.
>>
>> But I really wonder if anybody actually cares about adding sub-second
>> timestamp support, or if it is merely "because SVN has it".
>
> Roundtrip conversions may benefit from sub-second timestamps, but
> personally I think negative timestamps are more interesting and of
> practical use. Prehistoric projects need them even if they intend
> to switch to Git, never to go back to their original tarballs and
> collection of RCS ,v files.
>
> And if we were to add "committer-timestamp" and friends to support
> negative timestamps anyway (because older tools will not support
> them), supporting sub-second part might be something we want to
> think about at the same time.
Posix-time is signed, but I suppose the git tools do not expect/allow
a '-' character in the stream. Has git considered the year-2038
problem?
No hurry...
Phil
^ permalink raw reply
* Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
From: Junio C Hamano @ 2012-11-29 19:15 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git
In-Reply-To: <20121129181141.GA17309@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Thu, Nov 29, 2012 at 06:00:54PM +0100, Matthieu Moy wrote:
>
>> The documentation mentionned only newlines and double quotes as
>
> s/nn/n/
>
>> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
>> index 6603a7a..35b909c 100644
>> --- a/Documentation/git-fast-import.txt
>> +++ b/Documentation/git-fast-import.txt
>> @@ -558,8 +558,9 @@ A `<path>` string must use UNIX-style directory separators (forward
>> slash `/`), may contain any byte other than `LF`, and must not
>> start with double quote (`"`).
>>
>> -If an `LF` or double quote must be encoded into `<path>` shell-style
>> -quoting should be used, e.g. `"path/with\n and \" in it"`.
>> +If an `LF`, backslash or double quote must be encoded into `<path>`
>> +shell-style quoting should be used, and the complete name should be
>> +surrounded with double quotes e.g. `"path/with\n, \\ and \" in it"`.
That "shell-style" contradicts with what fast-import.c says, though.
It claims to grok \octal and described as C-style.
^ permalink raw reply
* Re: [PATCH 1/2] git-fast-import.txt: improve documentation for quoted paths
From: Jeff King @ 2012-11-29 19:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vvccop6dv.fsf@alter.siamese.dyndns.org>
On Thu, Nov 29, 2012 at 11:15:56AM -0800, Junio C Hamano wrote:
> >> -If an `LF` or double quote must be encoded into `<path>` shell-style
> >> -quoting should be used, e.g. `"path/with\n and \" in it"`.
> >> +If an `LF`, backslash or double quote must be encoded into `<path>`
> >> +shell-style quoting should be used, and the complete name should be
> >> +surrounded with double quotes e.g. `"path/with\n, \\ and \" in it"`.
>
> That "shell-style" contradicts with what fast-import.c says, though.
> It claims to grok \octal and described as C-style.
Yeah, I think it was just laziness by the original author to use
"shell-style" to mean "quotes and backslash escaping" without thinking
too hard about which escape sequences are available. Saying C-style is
more accurate (and Matthieu's more recent update does that).
-Peff
^ permalink raw reply
* Re: [PATCH 1/2 v3] git-fast-import.txt: improve documentation for quoted paths
From: Junio C Hamano @ 2012-11-29 19:33 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1354216293-21921-1-git-send-email-Matthieu.Moy@imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> The documentation mentionned only newlines and double quotes as
> characters needing escaping, but the backslash also needs it. Also, the
> documentation was not clearly saying that double quotes around the file
> name were required (double quotes in the examples could be interpreted as
> part of the sentence, not part of the actual string).
>
> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
> ---
> cut-and-paste of Peff's version, adapted from mine.
>
> Documentation/git-fast-import.txt | 8 ++++++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> index 959e4d3..d1844ea 100644
> --- a/Documentation/git-fast-import.txt
> +++ b/Documentation/git-fast-import.txt
> @@ -562,8 +562,12 @@ A `<path>` string must use UNIX-style directory separators (forward
> slash `/`), may contain any byte other than `LF`, and must not
> start with double quote (`"`).
>
> -If an `LF` or double quote must be encoded into `<path>` shell-style
> -quoting should be used, e.g. `"path/with\n and \" in it"`.
> +A path can use C-style string quoting; this is accepted in all cases
> +and mandatory if the filename starts with double quote or contains
> +`LF`.
... or backslash?
> +In C-style quoting, the complete name should be surrounded with
> +double quotes, and any `LF`, backslash, or double quote characters
> +must be escaped by preceding them with a backslash (e.g.,
> +`"path/with\n, \\ and \" in it"`).
>
> The value of `<path>` must be in canonical form. That is it must not:
^ permalink raw reply
* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Junio C Hamano @ 2012-11-29 19:36 UTC (permalink / raw)
To: Martin von Zweigbergk; +Cc: git
In-Reply-To: <CANiSa6j2sriXaGr0yH9kMrxDEvKHsjNPX_Exbc2_6ecnPYdroQ@mail.gmail.com>
Martin von Zweigbergk <martinvonz@gmail.com> writes:
> Would the correct fix be to
> first make "git reset --hard -- $path" work (*sigh*)? I have never
> understood why that doesn't (shouldn't) work.
What does it even mean, even when you are on an existing commit, to
hard reset partially?
Perhaps you looking for "git checkout $tree -- $path"?
^ permalink raw reply
* Re: [PATCH 1/2 v3] git-fast-import.txt: improve documentation for quoted paths
From: Jeff King @ 2012-11-29 19:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Matthieu Moy, git
In-Reply-To: <7vr4ncp5kw.fsf@alter.siamese.dyndns.org>
On Thu, Nov 29, 2012 at 11:33:19AM -0800, Junio C Hamano wrote:
> > diff --git a/Documentation/git-fast-import.txt b/Documentation/git-fast-import.txt
> > index 959e4d3..d1844ea 100644
> > --- a/Documentation/git-fast-import.txt
> > +++ b/Documentation/git-fast-import.txt
> > @@ -562,8 +562,12 @@ A `<path>` string must use UNIX-style directory separators (forward
> > slash `/`), may contain any byte other than `LF`, and must not
> > start with double quote (`"`).
> >
> > -If an `LF` or double quote must be encoded into `<path>` shell-style
> > -quoting should be used, e.g. `"path/with\n and \" in it"`.
> > +A path can use C-style string quoting; this is accepted in all cases
> > +and mandatory if the filename starts with double quote or contains
> > +`LF`.
>
> ... or backslash?
No, that was what we discussed elsewhere in the thread. It is OK to say:
M 100644 :1 file \with \backslashes
as de-quoting is triggered by the first character being double-quote.
-Peff
^ permalink raw reply
* Re: Millisecond precision in timestamps?
From: Jeff King @ 2012-11-29 20:01 UTC (permalink / raw)
To: Phil Hord
Cc: Junio C Hamano, Shawn Pearce, Felipe Contreras, Eric Raymond, git
In-Reply-To: <CABURp0pnGYykud1xDn5T+eszQGTrzKLTp6J_O7ZrWwVd-zKpkg@mail.gmail.com>
On Thu, Nov 29, 2012 at 02:14:40PM -0500, Phil Hord wrote:
> > And if we were to add "committer-timestamp" and friends to support
> > negative timestamps anyway (because older tools will not support
> > them), supporting sub-second part might be something we want to
> > think about at the same time.
>
> Posix-time is signed, but I suppose the git tools do not expect/allow
> a '-' character in the stream. Has git considered the year-2038
> problem?
Yes. The timestamp is in base-10 ASCII, so there is no Y2038 problem in
the data format (it is up to the implementation to read it into a
sufficiently large time_t internally, of course[1]).
But negative timestamps are a different story. We use "unsigned long"
internally for timestamps, and fsck will complain about it.
-Peff
[1] We use "unsigned long", which means we are Y2038-fine on I32/LP64
systems, but not on 32-bit or IL32/LLP64 systems. I do not use
Windows, but my understanding is that LLP64 is the norm there, so it
would eventually be a problem. But since we are unsigned, it is
actually a Y2106 problem.
^ permalink raw reply
* Re: [PATCH] t4049: avoid test failures on filemode challenged file systems (Windows)
From: Junio C Hamano @ 2012-11-29 20:48 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Antoine Pelisse
In-Reply-To: <7vfw3sqoup.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>> ...
>> The hunks in the patch look fine. The last one that tests unmerged
>> entries do not have to have "chmod" if it gives you trouble (you
>> would need to reduce number of files from 4 to 3 if you go that
>> route, I think).
>
> That is, something like this.
I've tested this with the testpen set on vfat mounted on my Linux
box, i.e.
$ cd t
$ sh t4049-diff-stat-count.sh --root=/media/5599-553B/test -v
and it seems to work OK, so I'll be merging the topic with this
patch to 'master' later today.
Thanks for noticing.
> -- >8 --
> Subject: [PATCH] t4049: refocus tests
>
> The primary thing Linus's patch wanted to change was to make sure
> that 0-line change appears for a mode-only change. Update the
> first test to chmod a file that we can see in the output (limited
> by --stat-count) to demonstrate it. Also make sure to use test_chmod
> and compare the index and the tree, so that we can run this test
> even on a filesystem without permission bits.
>
> Later two tests are about fixes to separate issues that were
> introduced and/or uncovered by Linus's patch as a side effect, but
> the issues are not related to mode-only changes. Remove chmod from
> the tests.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> t/t4049-diff-stat-count.sh | 20 +++++++++-----------
> 1 file changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/t/t4049-diff-stat-count.sh b/t/t4049-diff-stat-count.sh
> index 37f50cd..5b594e8 100755
> --- a/t/t4049-diff-stat-count.sh
> +++ b/t/t4049-diff-stat-count.sh
> @@ -13,32 +13,31 @@ test_expect_success 'setup' '
> git commit -m initial
> '
>
> -test_expect_success 'limit output to 2 (simple)' '
> +test_expect_success 'mode-only change show as a 0-line change' '
> git reset --hard &&
> - chmod +x c d &&
> + test_chmod +x b d &&
> echo a >a &&
> - echo b >b &&
> + echo c >c &&
> cat >expect <<-\EOF
> a | 1 +
> - b | 1 +
> + b | 0
> ...
> 4 files changed, 2 insertions(+)
> EOF
> - git diff --stat --stat-count=2 >actual &&
> + git diff --stat --stat-count=2 HEAD >actual &&
> test_i18ncmp expect actual
> '
>
> test_expect_success 'binary changes do not count in lines' '
> git reset --hard &&
> - chmod +x c d &&
> echo a >a &&
> - echo b >b &&
> + echo c >c &&
> cat "$TEST_DIRECTORY"/test-binary-1.png >d &&
> cat >expect <<-\EOF
> a | 1 +
> - b | 1 +
> + c | 1 +
> ...
> - 4 files changed, 2 insertions(+)
> + 3 files changed, 2 insertions(+)
> EOF
> git diff --stat --stat-count=2 >actual &&
> test_i18ncmp expect actual
> @@ -56,12 +55,11 @@ test_expect_success 'exclude unmerged entries from total file count' '
> done |
> git update-index --index-info &&
> echo d >d &&
> - chmod +x c d &&
> cat >expect <<-\EOF
> a | 1 +
> b | 1 +
> ...
> - 4 files changed, 3 insertions(+)
> + 3 files changed, 3 insertions(+)
> EOF
> git diff --stat --stat-count=2 >actual &&
> test_i18ncmp expect actual
^ permalink raw reply
* Re: [PATCH] gitweb: git_summary - show $project in title
From: Xypron @ 2012-11-29 21:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v625agwiv.fsf@alter.siamese.dyndns.org>
Thank you for your comments. In the appended version of the patch
the project title is escaped:
Subject: [PATCH] gitweb: git_summary - show $project in title
Gitweb pages are structured by divs of class title with grey background.
The shortlog, and the log page show the project name as the first title.
Page summary only shows an empty grey box above the project details.
This provides an inconsistent user experience.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
gitweb/gitweb.perl | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e8812fa..be94b0b 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6450,7 +6450,7 @@ sub git_summary {
git_header_html();
git_print_page_nav('summary','', $head);
- print "<div class=\"title\"> </div>\n";
+ print "<div class=\"title\">" . esc_html($project) . "</div>\n";
print "<table class=\"projects_list\">\n" .
"<tr id=\"metadata_desc\"><td>description</td><td>" . esc_html($descr) . "</td></tr>\n";
unless ($omit_owner) {
--
1.7.10.4
On 13.11.2012 01:46, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
>> On Sun, Nov 11, 2012 at 06:20:58AM +0100, Henrich Schuchardt wrote:
>>
>>> Gitweb pages are structured by divs of class title with grey background.
>>> The shortlog, and the log page show the project name as the first title.
>>> Page summary only shows an empty grey box above the project details.
>>> This provides an inconstent user experience.
>>>
>>> This patch adds the missing project title.
>>>
>>> Signed-off-by: Henrich Schuchardt <xypron.glpk@gmx.de>
>>> ---
>>> gitweb/gitweb.perl | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
>>> index 10ed9e5..3e1c452 100755
>>> --- a/gitweb/gitweb.perl
>>> +++ b/gitweb/gitweb.perl
>>> @@ -6451,7 +6451,7 @@ sub git_summary {
>>> git_header_html();
>>> git_print_page_nav('summary','', $head);
>>>
>>> - print "<div class=\"title\"> </div>\n";
>>> + print "<div class=\"title\">$project</div>\n";
>> I do not have any opinion on whether the intent of the change is good or
>> not, but shouldn't $project be run through esc_html() here?
> I think the answer is yes. And if $project needs to be escaped, the
> git_feed function you fixed today has another codepath that needs to
> be fixed. When git_get_project_description($project) returns undef,
> the description is taken from $project without any escaping.
>
>
>
^ permalink raw reply related
* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Junio C Hamano @ 2012-11-29 21:30 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Jeremy White, Johannes Schindelin
In-Reply-To: <1353841721-16269-7-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> struct msg_data stored (char *, len) of the data to be included in a
That (<type>, <varname>) is a bit funny notation, even though it is
understandable.
> message, kept the character data NUL-terminated, etc., much like a
> strbuf would do. So change it to use a struct strbuf. This makes the
> code clearer and reduces copying a little bit.
>
> A side effect of this change is that the memory for each message is
> freed after it is used rather than leaked, though that detail is
> unimportant given that imap-send is a top-level command.
>
> --
?
> For some reason, there is a bunch of infrastructure in this file for
> dealing with IMAP flags, although there is nothing in the code that
> actually allows any flags to be set. If there is no plan to add
> support for flags in the future, a bunch of code could be ripped out
> and "struct msg_data" could be completely replaced with strbuf.
Yeah, after all these years we have kept the unused flags field
there and nobody needed anything out of it. I am OK with a removal
if it is done at the very end of the series.
Thanks.
^ permalink raw reply
* Re: [PATCH 0/8] Add function strbuf_addstr_xml_quoted() and more
From: Junio C Hamano @ 2012-11-29 21:41 UTC (permalink / raw)
To: Michael Haggerty; +Cc: git, Jeremy White, Johannes Schindelin
In-Reply-To: <1353841721-16269-1-git-send-email-mhagger@alum.mit.edu>
Michael Haggerty <mhagger@alum.mit.edu> writes:
> There were two functions doing almost the same XML quoting of
> character entities, so implement a library function
> strbuf_addstr_xml_quoted() and use that in both places.
>
> Along the way, do a lot of simplification within imap-send.c, which
> was doing a lot of its own string management instead of using strbuf.
Overall the series looked good to me. Thanks; will queue.
^ permalink raw reply
* Re: [RFC/PATCH 1/2] reset: learn to reset to tree
From: Martin von Zweigbergk @ 2012-11-29 22:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzk20p6ik.fsf@alter.siamese.dyndns.org>
On Thu, Nov 29, 2012 at 11:13 AM, Junio C Hamano <gitster@pobox.com> wrote:
> [...]These
> two commands, "reset" and "checkout", share that the source we grab
> the blobs out of only need to be a tree and does not have to be a
> commit, and the only difference between them is where the blobs we
> grabbed out of that tree go, either only to the index or to both the
> index and the working tree.
Slightly off topic, but another difference (or somehow another aspect
of the same difference?) that has tripped me up a few times is that
"git checkout $rev ." only affects added and modified files (in $rev
compared to HEAD), but "git reset $rev ." would also delete deleted
files from the index. I suppose this is also a partial answer to your
question in another message:
> What does it even mean, even when you are on an existing commit, to
> hard reset partially?
>
> Perhaps you looking for "git checkout $tree -- $path"?
A more direct answer would be that I would expect "git reset --hard
$rev -- ." to behave like "git reset --hard $rev", except that it
wouldn't update HEAD. It seems to me that that would be similar to how
"git reset $rev -- ." behaves like "git reset $rev", except that it
doesn't update HEAD. But reset and checkout with and without paths
still confuse me after years of using git, so I wouldn't be surprised
if I'm not making any sense.
^ permalink raw reply
* Re: [PATCH] gitweb: add readme to overview page
From: Xypron @ 2012-11-29 22:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1352647962-21910-1-git-send-email-xypron.glpk@gmx.de>
Hello Junio,
thank you for your comment in message
<7vip9ak971.fsf@alter.siamese.dyndns.org>
that message <1352652039-31453-1-git-send-email-xypron.glpk@gmx.de>
lost the thread context.
As already described I would be happy if a README.html could be added to
the overview page of gitweb.
Please, find below an updated patch. Compared to the first version of my
patch it avoids a warning concerning doubled slashes in filenames and adds
a subtitle "projects" between the README and the project list.
Best regards
Heinrich Schuchardt
Subject: [PATCH] gitweb: add readme to overview page
For repositories it is possible to maintain a README.html which will
be shown on the summary page. This is not possible for the server
root.
German law requires to provide contact data on the web server. This
data could easily be entered in the overview page using a README.html.
Furthermore it is possible to put the repositories not directly into
the root directory but into a subdirectory. Here also a README.html
would be helpful to indicate what the subdirectory is about.
The patch introduces README.html functionality for the root directory
and all subdirectories.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
---
gitweb/gitweb.perl | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index e8812fa..618b0d8 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -6368,6 +6368,19 @@ sub git_project_list {
}
git_project_search_form($searchtext, $search_use_regexp);
+ # If XSS prevention is on, we don't include README.html.
+ # TODO: Allow a readme in some safe format.
+ my $path = "";
+ if (defined $project_filter) {
+ $path = "/$project_filter";
+ }
+ if (!$prevent_xss && -s "$projectroot$path/README.html") {
+ print "<div class=\"title\">readme</div>\n" .
+ "<div class=\"readme\">\n";
+ insert_file("$projectroot$path/README.html");
+ print "\n</div>\n"; # class="readme"
+ }
+ print "<div class=\"title\">projects</div>\n";
git_project_list_body(\@list, $order);
git_footer_html();
}
--
1.7.10.4
^ permalink raw reply related
* Re: [RFC/PATCH] l10n: de.po: translate 825 new messages
From: Thomas Rast @ 2012-11-29 23:02 UTC (permalink / raw)
To: Ralf Thielow; +Cc: git, trast, jk, stimming
In-Reply-To: <1349200849-7436-1-git-send-email-ralf.thielow@gmail.com>
Hi Ralf
Here is the final third of my review.
> #: builtin/prune-packed.c:7
> msgid "git prune-packed [-n|--dry-run] [-q|--quiet]"
> -msgstr ""
> +msgstr "git prune-packed [-n|--dry-run] [-q|--quite]"
^^^^^
typo at the far end
> #: builtin/prune.c:133
> -#, fuzzy
> msgid "report pruned objects"
> -msgstr "kann Objekt %s nicht lesen"
> +msgstr "meldet entfernte Objekte"
If you translate "pruned" as "gelöscht" or some such, that avoids the
ambiguity with "remote".
> #: builtin/prune.c:136
> msgid "expire objects older than <time>"
> -msgstr ""
> +msgstr "lässt Objekte älter als <Zeit> verfallen"
"verfallen" is nice!
> #: builtin/push.c:391
> msgid "check"
> -msgstr ""
> +msgstr "Überprüfung"
I think the original string should not be translatable to begin with.
The manpage says
--recurse-submodules=check|on-demand
Make sure all submodule commits used by the revisions to be pushed
are available on a remote tracking branch. If *check* is used git
will verify that all submodule commits that changed in the
revisions to be pushed are available on at least one remote of the
submodule. If any commits are missing the push will be aborted and
exit with non-zero status. If *on-demand* is used all submodules
that changed in the revisions to be pushed will be pushed. If
on-demand was not able to push all necessary revisions it will
also be aborted and exit with non-zero status.
So 'check' is not translatable.
> #: builtin/push.c:395 builtin/push.c:396
> msgid "receive pack program"
> -msgstr ""
> +msgstr "Programm zum Empfangen von Paketen"
Or perhaps "'receive-pack' Programm".
> #: builtin/read-tree.c:111
> -#, fuzzy
> msgid "only empty the index"
> -msgstr "Konnte die Bereitstellung nicht lesen"
> +msgstr "leert nur die Bereitstellung"
"Only" here means it doesn't read-a-tree, but empty the index. So
dropping the "nur" would probably be better.
#: builtin/remote.c:11
> msgid "git remote [-v | --verbose]"
> -msgstr ""
> +msgstr "git remove [-v | --verbose]"
^^^
typo
> #: builtin/remote.c:173
> msgid "set up remote as a mirror to push to or fetch from"
> msgstr ""
> +"Aufsetzen der Fernarchivs als Spiegelarchiv zum Versenden und Anfordern"
^^^
des?
> "Run \"git rev-parse --parseopt -h\" for more information on the first usage."
> msgstr ""
> +"git rev-parse --parseopt [Optionen] -- [<Argumente>...]\n"
> +" or: git rev-parse --sq-quote [<Argumente>...]\n"
> +" or: git rev-parse [Optionen] [<Argumente>...]\n"
> +"\n"
> +"Führe \"git rev-parse --parseopt -h\" für weitere Informationen bei erster "
> +"Verwendung aus."
Should use 'oder:' in the case split, shouldn't it?
> #: builtin/rm.c:134
> -#, fuzzy
> msgid "do not list removed files"
> -msgstr "Kann geänderte Dateien nicht aus der Bereitstellung herausnehmen"
> +msgstr "listet keine entfernten Dateien auf"
Again removed->gelöscht or some such avoids an ambiguity.
> #: builtin/show-branch.c:651
> -#, fuzzy
> msgid "show remote-tracking and local branches"
> -msgstr "Kein externer Übernahmezweig für %s von %s"
> +msgstr "zeigt externer Übernahmezweige und lokale Zweige an"
^^^
[...]
> #: builtin/show-branch.c:653
> -#, fuzzy
> msgid "show remote-tracking branches"
> -msgstr "Kein externer Übernahmezweig für %s von %s"
> +msgstr "zeigt externer Übernahmezweige an"
^^^
extern*e*
> #: builtin/tag.c:464
> -#, fuzzy
> msgid "use another key to sign the tag"
> -msgstr "konnte Markierung nicht signieren"
> +msgstr "benutzt einen Schlüssel um die Markierung zu signieren"
The original says *another* -- maybe
benutzt einen anderen Schlüssel um die Markierung zu signieren
> #: builtin/update-index.c:750
> msgid "mark files as \"not changing\""
> -msgstr ""
> +msgstr "markiert Dateien als \"not changing\""
Neither original nor translation are very helpful. Maybe
Always assume this file to be unchanged
Betrachte diese Datei immer als unverändert
> #: builtin/update-index.c:756
> msgid "mark files as \"index-only\""
> -msgstr ""
> +msgstr "markiert Dateien als \"index-only\""
Likewise, but here I don't even understand what the manpage is trying to
tell me, in particular I don't see how it would be different from
assume-unchanged. Maybe "see manpage" would be the best documentation.
> #: builtin/update-index.c:776
> msgid "repopulate stages #2 and #3 for the listed paths"
> msgstr ""
> +"wiederholte Ausführung der Phasen #2 und #3 für die aufgelisteten Pfade"
ISTR we settled on something for 'stage', but it's not in the glossary.
Either way I don't think this is it. "Ausführung der Phasen" would mean
that it's some part of a process, whereas the stages are a state.
Yay, that's it. Even in three parts it was tedious, and I cannot begin
to imagine what *writing* 825 new translations must have felt like.
Thanks for your work!
- Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* What's cooking in git.git (Nov 2012, #10; Thu, 29)
From: Junio C Hamano @ 2012-11-29 23:22 UTC (permalink / raw)
To: git
What's cooking in git.git (Nov 2012, #10; Thu, 29)
--------------------------------------------------
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Hopefully 1.8.1-rc0 preview will be tagged this weekend. Many
topics are marked to be cooked in 'next' during the feature freeze,
but some topics in flight should be in 'master' before -rc1 happens.
You can find the changes described here in the integration branches of the
repositories listed at
http://git-blame.blogspot.com/p/git-public-repositories.html
--------------------------------------------------
[New Topics]
* wk/submodule-update-remote (2012-11-28) 2 commits
- submodule add: If --branch is given, record it in .gitmodules
- submodule update: add --remote for submodule's upstream changes
Still under active discussion.
--------------------------------------------------
[Graduated to "master"]
* er/doc-add-new-commands (2012-11-26) 1 commit
(merged to 'next' on 2012-11-28 at 2daf755)
+ Documentation: how to add a new command
* fc/completion-test-simplification (2012-11-16) 6 commits
(merged to 'next' on 2012-11-28 at b7b2f67)
+ completion: simplify __gitcomp() test helper
+ completion: refactor __gitcomp related tests
+ completion: consolidate test_completion*() tests
+ completion: simplify tests using test_completion_long()
+ completion: standardize final space marker in tests
+ completion: add comment for test_completion()
Clean up completion tests. Use of conslidated helper may make
instrumenting one particular test during debugging of the test
itself, but I think that issue should be addressed in some other
way (e.g. making sure individual tests in 9902 can be skipped).
* fc/remote-hg (2012-11-27) 22 commits
(merged to 'next' on 2012-11-28 at f805784)
+ remote-hg: fix for older versions of python
+ remote-hg: fix for files with spaces
(merged to 'next' on 2012-11-18 at 4a4f2e4)
+ remote-hg: avoid bad refs
+ remote-hg: try the 'tip' if no checkout present
+ remote-hg: fix compatibility with older versions of hg
+ remote-hg: add missing config for basic tests
+ remote-hg: the author email can be null
+ remote-hg: add option to not track branches
+ remote-hg: add extra author test
+ remote-hg: add tests to compare with hg-git
+ remote-hg: add bidirectional tests
+ test-lib: avoid full path to store test results
+ remote-hg: add basic tests
+ remote-hg: fake bookmark when there's none
+ remote-hg: add compat for hg-git author fixes
+ remote-hg: add support for hg-git compat mode
+ remote-hg: match hg merge behavior
+ remote-hg: make sure the encoding is correct
+ remote-hg: add support to push URLs
+ remote-hg: add support for remote pushing
+ remote-hg: add support for pushing
+ Add new remote-hg transport helper
New remote helper for hg.
* fc/send-email-no-sender-prompt (2012-11-26) 1 commit
(merged to 'next' on 2012-11-28 at 690d525)
+ send-email: avoid questions when user has an ident
(this branch is used by jk/send-email-sender-prompt.)
In cases the sender ident is sufficiently specified, there is no
need to prompt the user before sending the series out.
* fc/zsh-completion (2012-11-19) 2 commits
(merged to 'next' on 2012-11-26 at 48ebdc9)
+ completion: start moving to the new zsh completion
+ completion: add new zsh completion
Completion script revamped for zsh users.
* jc/doc-push-satellite (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 7114637)
+ Documentation/git-push.txt: clarify the "push from satellite" workflow
Clarify what the example that pushes branches into remote-tracking
branches of another repository is trying to achieve (i.e. emulating
a fetch in reverse).
* jk/pickaxe-textconv (2012-10-28) 2 commits
(merged to 'next' on 2012-11-26 at 2c5b5c9)
+ pickaxe: use textconv for -S counting
+ pickaxe: hoist empty needle check
Use textconv filters when searching with "log -S".
* jk/send-email-sender-prompt (2012-11-28) 7 commits
(merged to 'next' on 2012-11-28 at a808921)
+ t9001: check send-email behavior with implicit sender
+ Merge branch 'fc/send-email-no-sender-prompt' into jk/send-email-sender-prompt
+ t: add tests for "git var"
+ ident: keep separate "explicit" flags for author and committer
+ ident: make user_ident_explicitly_given static
+ t7502: factor out autoident prerequisite
+ test-lib: allow negation of prerequisites
(this branch uses fc/send-email-no-sender-prompt.)
General clean-ups in various areas, originally written to support a
patch that later turned out to be unneeded.
* jl/submodule-rm (2012-11-23) 1 commit
(merged to 'next' on 2012-11-28 at 0e4115f)
+ Teach rm to remove submodules when given with a trailing '/'
Finishing touches to "git rm $submodule" that removes the working
tree of a submodule.
* km/send-email-remove-cruft-in-address (2012-11-26) 5 commits
(merged to 'next' on 2012-11-28 at 2688772)
+ git-send-email: allow edit invalid email address
+ git-send-email: ask what to do with an invalid email address
+ git-send-email: remove invalid addresses earlier
+ git-send-email: fix fallback code in extract_valid_address()
+ git-send-email: remove garbage after email address
Garbage after e-mail address on Cc: in the patch breaks the
transmission of it over send-email.
* lt/diff-stat-show-0-lines (2012-11-27) 6 commits
(merged to 'next' on 2012-11-28 at de89eed)
+ diff --shortstat: do not count "unmerged" entries
+ diff --stat: do not count "unmerged" entries
+ diff --stat: move the "total count" logic to the last loop
+ diff --stat: use "file" temporary variable to refer to data->files[i]
+ diff --stat: status of unmodified pair in diff-q is not zero
+ test: add failing tests for "diff --stat" to t4049
"git diff --stat" miscounted the total number of changed lines when
binary files were involved and hidden beyond --stat-count. It also
miscounted the total number of changed files when there were
unmerged paths.
* mk/complete-tcsh (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 5528439)
+ Support for git aliasing for tcsh completion
Completion script revamped for tcsh users.
* mm/status-push-pull-advise (2012-11-16) 1 commit
(merged to 'next' on 2012-11-26 at ed40d5e)
+ status: add advice on how to push/pull to tracking branch
When "git checkout" checks out a branch, it tells the user how far
behind (or ahead) the new branch is relative to the remote tracking
branch it builds upon. The message now also advises how to sync
them up by pushing or pulling.
* pp/gitweb-config-underscore (2012-11-21) 1 commit
(merged to 'next' on 2012-11-28 at fc9bf5f)
+ gitweb: make remote_heads config setting work
The key "gitweb.remote_heads" is not legal git config; this maps it to
"gitweb.remoteheads".
* pw/p4-various-fixes (2012-11-26) 6 commits
(merged to 'next' on 2012-11-28 at 1a6f9a9)
+ git p4: remove unneeded cmd initialization
+ git p4: fix labelDetails typo in exception
+ git p4 test: display unresolvable host error
+ git p4: catch p4 errors when streaming file contents
+ git p4: handle servers without move support
+ git p4: catch p4 describe errors
--------------------------------------------------
[Stalled]
* pf/editor-ignore-sigint (2012-11-11) 5 commits
- launch_editor: propagate SIGINT from editor to git
- run-command: do not warn about child death by SIGINT
- run-command: drop silent_exec_failure arg from wait_or_whine
- launch_editor: ignore SIGINT while the editor has control
- launch_editor: refactor to use start/finish_command
Avoid confusing cases where the user hits Ctrl-C while in the editor
session, not realizing git will receive the signal. Since most editors
will take over the terminal and will block SIGINT, this is not likely
to confuse anyone.
Some people raised issues with emacsclient, which are addressed by this
re-roll. It should probably also handle SIGQUIT, and there were a
handful of other review comments.
Expecting a re-roll.
* mo/cvs-server-updates (2012-10-16) 10 commits
- cvsserver Documentation: new cvs ... -r support
- cvsserver: add t9402 to test branch and tag refs
- cvsserver: support -r and sticky tags for most operations
- cvsserver: Add version awareness to argsfromdir
- cvsserver: generalize getmeta() to recognize commit refs
- cvsserver: implement req_Sticky and related utilities
- cvsserver: add misc commit lookup, file meta data, and file listing functions
- cvsserver: define a tag name character escape mechanism
- cvsserver: cleanup extra slashes in filename arguments
- cvsserver: factor out git-log parsing logic
Needs review by folks interested in cvsserver.
* as/check-ignore (2012-11-08) 14 commits
- t0007: fix tests on Windows
- Documentation/check-ignore: we show the deciding match, not the first
- Add git-check-ignore sub-command
- dir.c: provide free_directory() for reclaiming dir_struct memory
- pathspec.c: move reusable code from builtin/add.c
- dir.c: refactor treat_gitlinks()
- dir.c: keep track of where patterns came from
- dir.c: refactor is_path_excluded()
- dir.c: refactor is_excluded()
- dir.c: refactor is_excluded_from_list()
- dir.c: rename excluded() to is_excluded()
- dir.c: rename excluded_from_list() to is_excluded_from_list()
- dir.c: rename path_excluded() to is_path_excluded()
- dir.c: rename cryptic 'which' variable to more consistent name
Duy helped to reroll this.
Expecting a re-roll.
* aw/rebase-am-failure-detection (2012-10-11) 1 commit
- rebase: Handle cases where format-patch fails
I am unhappy a bit about the possible performance implications of
having to store the output in a temporary file only for a rare case
of format-patch aborting.
* jk/lua-hackery (2012-10-07) 6 commits
- pretty: fix up one-off format_commit_message calls
- Minimum compilation fixup
- Makefile: make "lua" a bit more configurable
- add a "lua" pretty format
- add basic lua infrastructure
- pretty: make some commit-parsing helpers more public
Interesting exercise. When we do this for real, we probably would want
to wrap a commit to make it more like an "object" with methods like
"parents", etc.
* fc/remote-testgit-feature-done (2012-10-29) 1 commit
- remote-testgit: properly check for errors
Needs review and Ack (or Nack) from people involved in the remote
helper interface for this to move forward.
* rc/maint-complete-git-p4 (2012-09-24) 1 commit
(merged to 'next' on 2012-10-29 at af52cef)
+ Teach git-completion about git p4
Comment from Pete will need to be addressed in a follow-up patch.
* as/test-tweaks (2012-09-20) 7 commits
- tests: paint unexpectedly fixed known breakages in bold red
- tests: test the test framework more thoroughly
- [SQUASH] t/t0000-basic.sh: quoting of TEST_DIRECTORY is screwed up
- tests: refactor mechanics of testing in a sub test-lib
- tests: paint skipped tests in bold blue
- tests: test number comes first in 'not ok $count - $message'
- tests: paint known breakages in bold yellow
Various minor tweaks to the test framework to paint its output
lines in colors that match what they mean better.
Has the "is this really blue?" issue Peff raised resolved???
* jc/maint-name-rev (2012-09-17) 7 commits
- describe --contains: use "name-rev --algorithm=weight"
- name-rev --algorithm=weight: tests and documentation
- name-rev --algorithm=weight: cache the computed weight in notes
- name-rev --algorithm=weight: trivial optimization
- name-rev: --algorithm option
- name_rev: clarify the logic to assign a new tip-name to a commit
- name-rev: lose unnecessary typedef
"git name-rev" names the given revision based on a ref that can be
reached in the smallest number of steps from the rev, but that is
not useful when the caller wants to know which tag is the oldest one
that contains the rev. This teaches a new mode to the command that
uses the oldest ref among those which contain the rev.
I am not sure if this is worth it; for one thing, even with the help
from notes-cache, it seems to make the "describe --contains" even
slower. Also the command will be unusably slow for a user who does
not have a write access (hence unable to create or update the
notes-cache).
Stalled mostly due to lack of responses.
* jc/xprm-generation (2012-09-14) 1 commit
- test-generation: compute generation numbers and clock skews
A toy to analyze how bad the clock skews are in histories of real
world projects.
Stalled mostly due to lack of responses.
* jc/blame-no-follow (2012-09-21) 2 commits
- blame: pay attention to --no-follow
- diff: accept --no-follow option
Teaches "--no-follow" option to "git blame" to disable its
whole-file rename detection.
Stalled mostly due to lack of responses.
* jc/doc-default-format (2012-11-26) 2 commits
- [SQAUSH] allow "cd Doc* && make DEFAULT_DOC_TARGET=..."
- Allow generating a non-default set of documentation
Need to address the installation half if this is to be any useful.
* mk/maint-graph-infinity-loop (2012-09-25) 1 commit
- graph.c: infinite loop in git whatchanged --graph -m
The --graph code fell into infinite loop when asked to do what the
code did not expect ;-)
Anybody who worked on "--graph" wants to comment?
Stalled mostly due to lack of responses.
* jc/add-delete-default (2012-08-13) 1 commit
- git add: notice removal of tracked paths by default
"git add dir/" updated modified files and added new files, but does
not notice removed files, which may be "Huh?" to some users. They
can of course use "git add -A dir/", but why should they?
Resurrected from graveyard, as I thought it was a worthwhile thing
to do in the longer term.
Waiting for comments.
* mb/remote-default-nn-origin (2012-07-11) 6 commits
- Teach get_default_remote to respect remote.default.
- Test that plain "git fetch" uses remote.default when on a detached HEAD.
- Teach clone to set remote.default.
- Teach "git remote" about remote.default.
- Teach remote.c about the remote.default configuration setting.
- Rename remote.c's default_remote_name static variables.
When the user does not specify what remote to interact with, we
often attempt to use 'origin'. This can now be customized via a
configuration variable.
Expecting a re-roll.
"The first remote becomes the default" bit is better done as a
separate step.
--------------------------------------------------
[Cooking]
* bc/append-signed-off-by (2012-11-26) 11 commits
- Unify appending signoff in format-patch, commit and sequencer
- format-patch: update append_signoff prototype
- format-patch: stricter S-o-b detection
- t4014: more tests about appending s-o-b lines
- sequencer.c: teach append_signoff to avoid adding a duplicate newline
- sequencer.c: teach append_signoff how to detect duplicate s-o-b
- sequencer.c: always separate "(cherry picked from" from commit body
- sequencer.c: recognize "(cherry picked from ..." as part of s-o-b footer
- t/t3511: add some tests of 'cherry-pick -s' functionality
- t/test-lib-functions.sh: allow to specify the tag name to test_commit
- sequencer.c: remove broken support for rfc2822 continuation in footer
Expecting a re-roll after a review.
* mh/unify-xml-in-imap-send-and-http-push (2012-11-29) 8 commits
- wrap_in_html(): process message in bulk rather than line-by-line
- wrap_in_html(): use strbuf_addstr_xml_quoted()
- imap-send: change msg_data from storing (ptr, len) to storing strbuf
- imap-send: correctly report errors reading from stdin
- imap-send: store all_msgs as a strbuf
- lf_to_crlf(): NUL-terminate msg_data::data
- xml_entities(): use function strbuf_addstr_xml_quoted()
- Add new function strbuf_add_xml_quoted()
Will merge to 'next'.
* rr/t4041-cleanup (2012-11-27) 4 commits
- t4041 (diff-submodule-option): modernize style
- t4041 (diff-submodule-option): rewrite add_file() routine
- t4041 (diff-submodule-option): parse digests sensibly
- t4041 (diff-submodule-option): don't hardcode SHA-1 in expected outputs
As a clean-up, it still misses some.
Expecting a re-roll.
* jc/doc-maintainer (2012-11-27) 1 commit
- update "howto maintain git"
An early draft that is still incomplete.
* jk/fsck-dot-in-trees (2012-11-28) 2 commits
(merged to 'next' on 2012-11-28 at 519dabc)
+ fsck: warn about ".git" in trees
+ fsck: warn about '.' and '..' in trees
Will cook in 'next'.
* mh/doc-remote-helpers (2012-11-27) 6 commits
- git-remote-helpers.txt: clarify options & ref list attributes
- git-remote-helpers.txt: clarify command <-> capability correspondences
- git-remote-helpers.txt: rearrange description of capabilities
- git-remote-helpers.txt: minor grammar fix
- git-remote-helpers.txt: document missing capabilities
- git-remote-helpers.txt: document invocation before input format
Need comment and Ack from people who have worked on remote-helpers
before this goes forward.
* mh/pthreads-autoconf (2012-11-27) 1 commit
(merged to 'next' on 2012-11-28 at 780600e)
+ configure.ac: fix pthreads detection on Mac OS X
Will cook in 'next'.
* jn/warn-on-inaccessible-loosen (2012-10-14) 4 commits
(merged to 'next' on 2012-11-28 at 43d51c2)
+ config: exit on error accessing any config file
+ doc: advertise GIT_CONFIG_NOSYSTEM
+ config: treat user and xdg config permission problems as errors
+ config, gitignore: failure to access with ENOTDIR is ok
An RFC to deal with a situation where .config/git is a file and we
notice .config/git/config is not readable due to ENOTDIR, not
ENOENT.
Will cook in 'next'.
* mh/ceiling (2012-10-29) 8 commits
(merged to 'next' on 2012-11-26 at d1ce76a)
+ string_list_longest_prefix(): remove function
+ setup_git_directory_gently_1(): resolve symlinks in ceiling paths
+ longest_ancestor_length(): require prefix list entries to be normalized
+ longest_ancestor_length(): take a string_list argument for prefixes
+ longest_ancestor_length(): use string_list_split()
+ Introduce new function real_path_if_valid()
+ real_path_internal(): add comment explaining use of cwd
+ Introduce new static function real_path_internal()
Elements of GIT_CEILING_DIRECTORIES list may not match the real
pathname we obtain from getcwd(), leading the GIT_DIR discovery
logic to escape the ceilings the user thought to have specified.
Resurrected from Stalled; the earlier performance fear was
unwarranted.
Will cook in 'next'.
* fc/fast-export-fixes (2012-11-29) 15 commits
- fast-export: make sure updated refs get updated
- fast-export: don't handle uninteresting refs
- fast-export: fix comparison in tests
- fast-export: trivial cleanup
- remote-testgit: implement the "done" feature manually
- remote-testgit: report success after an import
- remote-testgit: exercise more features
- remote-testgit: cleanup tests
- remote-testgit: remove irrelevant test
- remote-testgit: remove non-local functionality
- Add new simplified git-remote-testgit
- Rename git-remote-testgit to git-remote-testpy
- remote-helpers: fix failure message
- remote-testgit: fix direction of marks
- fast-export: avoid importing blob marks
Will merge to (and cook in) 'next'.
* jc/apply-trailing-blank-removal (2012-10-12) 1 commit
(merged to 'next' on 2012-11-26 at 3af69e7)
+ apply.c:update_pre_post_images(): the preimage can be truncated
Fix to update_pre_post_images() that did not take into account the
possibility that whitespace fix could shrink the preimage and
change the number of lines in it.
Will cook in 'next'.
* nd/pathspec-wildcard (2012-11-26) 4 commits
- tree_entry_interesting: do basedir compare on wildcard patterns when possible
- pathspec: apply "*.c" optimization from exclude
- pathspec: do exact comparison on the leading non-wildcard part
- pathspec: save the non-wildcard length part
Will merge to 'next'.
* nd/wildmatch (2012-11-20) 14 commits
(merged to 'next' on 2012-11-21 at 151288f)
+ test-wildmatch: avoid Windows path mangling
(merged to 'next' on 2012-10-25 at 510e8df)
+ Support "**" wildcard in .gitignore and .gitattributes
+ wildmatch: make /**/ match zero or more directories
+ wildmatch: adjust "**" behavior
+ wildmatch: fix case-insensitive matching
+ wildmatch: remove static variable force_lower_case
+ wildmatch: make wildmatch's return value compatible with fnmatch
+ t3070: disable unreliable fnmatch tests
+ Integrate wildmatch to git
+ wildmatch: follow Git's coding convention
+ wildmatch: remove unnecessary functions
+ Import wildmatch from rsync
+ ctype: support iscntrl, ispunct, isxdigit and isprint
+ ctype: make sane_ctype[] const array
Allows pathname patterns in .gitignore and .gitattributes files
with double-asterisks "foo/**/bar" to match any number of directory
hierarchies.
I suspect that this needs to be plugged to pathspec matching code;
otherwise "git log -- 'Docum*/**/*.txt'" would not show the log for
commits that touch Documentation/git.txt, which would be confusing
to the users.
Will cook in 'next'.
* fc/remote-bzr (2012-11-28) 10 commits
- (fixup) test-bzr.sh: fix multi-line string assignment
- remote-bzr: detect local repositories
- remote-bzr: add support for older versions of bzr
- remote-bzr: add support to push special modes
- remote-bzr: add support for fecthing special modes
- remote-bzr: add simple tests
- remote-bzr: update working tree
- remote-bzr: add support for remote repositories
- remote-bzr: add support for pushing
- Add new remote-bzr transport helper
New remote helper for bzr (v3). With minor fixes, this may be ready
for 'next'.
* cr/push-force-tag-update (2012-11-26) 7 commits
- push: clarify rejection of update to non-commit-ish
- push: require force for annotated tags
- push: require force for refs under refs/tags/
- push: flag updates that require force
- push: keep track of "update" state separately
- push: add advice for rejected tag reference
- push: return reject reasons via a mask
Require "-f" for push to update a tag, even if it is a fast-forward.
With a minor tweak, I think this is getting ready for 'next'.
Expecting a re-roll.
--------------------------------------------------
[Discarded]
* nd/unify-appending-of-s-o-b (2012-11-15) 1 commit
. Unify appending signoff in format-patch, commit and sequencer
I am not sure if the logic to refrain from adding a sign-off based
on the existing run of sign-offs is done correctly in this change.
Brandon's series attempts the same thing and seemed to be more
cleanly done.
* nd/pretty-placeholder-with-color-option (2012-09-30) 9 commits
. pretty: support %>> that steal trailing spaces
. pretty: support truncating in %>, %< and %><
. pretty: support padding placeholders, %< %> and %><
. pretty: two phase conversion for non utf-8 commits
. utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
. utf8.c: move display_mode_esc_sequence_len() for use by other functions
. pretty: support %C(auto[,N]) to turn on coloring on next placeholder(s)
. pretty: split parsing %C into a separate function
. pretty: share code between format_decoration and show_decorations
This causes warnings with -Wuninitialized, so I've ejected it from pu
for the time being.
^ permalink raw reply
* Re: [PATCH 6/8] imap-send: change msg_data from storing (char *, len) to storing strbuf
From: Jeff King @ 2012-11-29 23:43 UTC (permalink / raw)
To: Michael Haggerty; +Cc: Junio C Hamano, git, Jeremy White, Johannes Schindelin
In-Reply-To: <7vboegp04x.fsf@alter.siamese.dyndns.org>
On Thu, Nov 29, 2012 at 01:30:54PM -0800, Junio C Hamano wrote:
> > For some reason, there is a bunch of infrastructure in this file for
> > dealing with IMAP flags, although there is nothing in the code that
> > actually allows any flags to be set. If there is no plan to add
> > support for flags in the future, a bunch of code could be ripped out
> > and "struct msg_data" could be completely replaced with strbuf.
>
> Yeah, after all these years we have kept the unused flags field
> there and nobody needed anything out of it. I am OK with a removal
> if it is done at the very end of the series.
There's a bunch of unused junk in imap-send. The original implementation
copied a bunch of code from isync, a much more full-featured imap
client, and the result ended up way more complex than it needed to be. I
have ripped a few things out over the years when they cause a problem
(e.g., portability of /dev/urandom, conflict over the name "struct
string_list"), but have mostly let it be out of a vague sense that we
might one day want to pull bugfixes from isync upstream.
That has not happened once in the last six years, though, and I would
doubt that a straightforward merge would work after so many years. So
ripping out and refactoring the code in the name of maintainability is
probably a good thing at this point.
-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