{remove_plus}' lines, delete them.
> # Lines starting with # will be removed.
> -#
> -# If the patch applies cleanly, the edited hunk will immediately be
> -# marked for $participle. If it does not apply cleanly, you will be given
> +#"), $remove_minus, $remove_plus),
# Lines starting with # will be removed.
+#
+# If the patch applies cleanly, the edited hunk will immediately be
+# marked for {participle}. If it does not apply cleanly, you will be given
[...]
Here is definition of relevant subroutines, based on Locale::TextDomain.
sub N__p($$) {
return @_;
}
--
Jakub Narębski
;> +} elsif ($patch_mode eq 'stash') {
>> + ...
>> +}
>> +}
>
> I wonder if you can make a simple helper function so that the caller
> here can still be a single-liner:
>
> print_colored $prompt_color,
> sprintf(patch_update_prompt_string($patch_mode,
> $hunk[$ix]{TYPE}), $other);
>
> where the patch_update_prompt_string helper function would look up
> these messages from a table that is looked up by patch-mode and TYPE
> and the run __() on it, or something?
Yes, this would be necessary; hide complexity behind helper function.
--
Jakub Narębski
print colored $header_color, "Split
>> into ",
>> -scalar(@split), " hunks.\n";
>> +print colored $header_color, sprintf(
>> + Q__("Split into %d hunk.\n",
>> +"Split into %d hunks.\n",
>> +scalar(@split)),
>> scalar(@split));
>
> Like we do with this.
Note that it is a bit of change in behavior: previously Git would
say "Split into 0 hunks.\n".
Though this is probably more work that you wanted to do. The __n would
take place of Q__, while the __nx function might be defined like this
(borrowing from Locale::TextDomain), which needs to be put into Git::I18N:
# Plural with interpolation.
sub __nx ($$$@)
{
my ($msgid, $msgid_plural, $count, %args) = @_;
return __expand ((__n $msgid, $msgid_plural, $count),
%args);
}
Best regards,
--
Jakub Narębski
W dniu 01.10.2016 o 00:18, santi...@nyu.edu pisze:
> From: Lukas Puehringer
>
> ref-filter functions are useful for printing git object information
> using a format specifier. However, some other modules may not want to use
> this functionality on a ref-array but only print a single item.
>
> Ex
these to be fairly infrequent.
Like handling merge conflict...??? Infrequent doesn't mean
unimportant.
That's all my comments for now.
This is a very interesting research. Those problems (misfits)
are legitimate concern. Even if it would not result in changes
to how Git works, it should improve how we are talking about
version control, and how we design them (that includes GUIs
that work above version control systems).
Best regards,
--
Jakub Narębski
sub __expand ($%)
{
my ($translation, %args) = @_;
my $re = join '|', map { quotemeta $_ } keys %args;
$translation =~ s/\{($re)\}/defined $args{$1} ? $args{$1} : "{$1}"/ge;
return $translation;
}
Best regards,
--
Jakub Narębski
t nothing
> -EOF
> + - (empty) select nothing"),
> +"\n";
> }
[... enough for information ...]
Regards,
--
Jakub Narębski
ubleshooting over the phone harder, I would guess.
>
> A: "Hi, I am in a 'git add -i' session."
> B: "Give 's' at the prompt."
> A: "My Git does not seem to take 's' as a valid command."
> B: "What? I've never seen that problem."
> ... back and forth wastes 10 minutes ...
> A: "By the way, I am running Git in Portuguese."
Also, for one-letter commands to work (there is setting where you
don't even need to press enter, IIRC) all those translations would
have to be chosen to begin with different letter, isn't it?
Best,
--
Jakub Narębski
. '(saying "no" discards!) [y/n]? ')
>
> Not just [y/n], but "no" in "saying no discards!" also needs to
> stay, no? I wonder if it is a good idea to lose the TRANSLATORS
> comment by ejecting "[y/n]" outside the "__()" construct here.
Actually the message to translators should also mention that if
the translation of "no" doesn't begin with 'n', then one needs
to say something like '(saying "n" for "no" discards!)'.
Best,
--
Jakub Narębski
even better: make filter driver write its pid to pidfile, and then
"wait $(cat rot13-filter.pid)". That's what we do in lib-git-daemon.sh
(I think).
If the problem is exit status of "wait" builtin, then filter driver
can remove its pidfile after writing "STOP", just before ending.
--
Jakub Narębski
, and not
GIT_CONFIG_SYSTEM / GIT_CONFIG_SYSTEM_PATH, that is something
OS-neutral?
--
Jakub Narębski
hnames charset (like UTF-8).
One thing pathname cannot include is NUL ("\0") character.
So in most cases they are ASCII, but might not be. Not that
pkt-line text packets are binary-unsafe... I think the trailing
"\n" is here for easier debugging.
http://www.dwheeler.com/essays/filenames-in-shell.html
http://www.dwheeler.com/essays/fixing-unix-linux-filenames.html
--
Jakub Narębski
W dniu 26.09.2016 o 20:49, Lars Schneider pisze:
> On 24 Sep 2016, at 23:14, Jakub Narębski wrote:
>> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>>
>>> From: Lars Schneider
>>>
>>> packet_write() should be called packet_write_fmt() as
s ( $buf =~ /\n$/ ) {
> + die "A non-binary line SHOULD BE terminated by an LF.";
First, if SHOULD BE, then perhaps 'warn' not 'die'... though for
tests it is probably better to 'die'.
Second, we should probably print (a fragment of) this line.
> +}
> +return ( $res, substr( $buf, 0, -1 ) );
Same comment as for example file in contrib/ - use s/// and no
need for substr stuff.
> +}
> +
> +sub packet_bin_write {
> +my ($packet) = @_;
> +print STDOUT sprintf( "%04x", length($packet) + 4 );
> +print STDOUT $packet;
> +STDOUT->flush();
> +}
> +
> +sub packet_txt_write {
> +packet_bin_write( $_[0] . "\n" );
> +}
> +
> +sub packet_flush {
> +print STDOUT sprintf( "%04x", 0 );
> +STDOUT->flush();
> +}
Looks good to me (though same comments as to contrib/ file applies).
> +
> +print $debug "START\n";
> +$debug->flush();
> +
> +( packet_txt_read() eq ( 0, "git-filter-client" ) ) || die "bad initialize";
> +( packet_txt_read() eq ( 0, "version=2" ) ) || die "bad version";
> +( packet_bin_read() eq ( 1, "" ) ) || die "bad version end";
> +
> +packet_txt_write("git-filter-server");
> +packet_txt_write("version=2");
> +
> +( packet_txt_read() eq ( 0, "clean=true" ) ) || die "bad capability";
> +( packet_txt_read() eq ( 0, "smudge=true" ) ) || die "bad capability";
> +( packet_bin_read() eq ( 1, "" ) )|| die "bad capability end";
> +
> +foreach (@capabilities) {
> +packet_txt_write( $_ . "=true" );
> +}
> +packet_flush();
> +print $debug "wrote filter header\n";
Or perhaps "handshake end"?
> +$debug->flush();
> +
> +while (1) {
> +my ($command) = packet_txt_read() =~ /^command=([^=]+)$/;
> +print $debug "IN: $command";
> +$debug->flush();
> +
> +my ($pathname) = packet_txt_read() =~ /^pathname=([^=]+)$/;
All right, here list context is necessary.
> +print $debug " $pathname";
No " pathname=$pathname" ?
> +$debug->flush();
> +
> +# Flush
> +packet_bin_read();
Same comment as earlier: read_flush, or read_varlist (till flush)
to have would be better.
> +
> +my $input = "";
> +{
> +binmode(STDIN);
> +my $buffer;
> +my $done = 0;
> +while ( !$done ) {
> +( $done, $buffer ) = packet_bin_read();
> +$input .= $buffer;
> +}
> +print $debug " " . length($input) . " [OK] -- ";
> +$debug->flush();
> +}
> +
> +my $output;
> +if ( $pathname eq "error.r" or $pathname eq "abort.r" ) {
> +$output = "";
> +}
> +elsif ( $command eq "clean" and grep( /^clean$/, @capabilities ) ) {
> +$output = rot13($input);
> +}
> +elsif ( $command eq "smudge" and grep( /^smudge$/, @capabilities ) ) {
> +$output = rot13($input);
> +}
> +else {
> +die "bad command '$command'";
> +}
> +
> +print $debug "OUT: " . length($output) . " ";
Shouldn't we write the length of output only if we don't error out,
abort, or fail?
> +$debug->flush();
> +
> +if ( $pathname eq "error.r" ) {
> +print $debug "[ERROR]\n";
> +$debug->flush();
> +packet_txt_write("status=error");
> +packet_flush();
> +}
> +elsif ( $pathname eq "abort.r" ) {
> +print $debug "[ABORT]\n";
> +$debug->flush();
> +packet_txt_write("status=abort");
> +packet_flush();
> +}
Looks good, so this is upfront status=error or status-abort.
> +else {
> +packet_txt_write("status=success");
> +packet_flush();
> +
> +if ( $pathname eq "${command}-write-fail.r" ) {
> +print $debug "[WRITE FAIL]\n";
> +$debug->flush();
> +die "${command} write error";
> +}
> +
> +while ( length($output) > 0 ) {
> +my $packet = substr( $output, 0, $MAX_PACKET_CONTENT_SIZE );
> +packet_bin_write($packet);
> +print $debug ".";
All right, so number of dots is the number of packets. This is
surprisingly opaque.
> +if ( length($output) > $MAX_PACKET_CONTENT_SIZE ) {
> +$output = substr( $output, $MAX_PACKET_CONTENT_SIZE );
> +}
> +else {
> +$output = "";
> +}
> +}
> +packet_flush();
> +print $debug " [OK]\n";
> +$debug->flush();
> +packet_flush();
Should we test partial contents case? Or failure during printing?
What happens then - is file cleared by Git, or left partially converted?
> +}
> +}
>
Keep up good work. Looks quite good.
--
Jakub Narębski
W dniu 27.09.2016 o 21:01, René Scharfe pisze:
> Signed-off-by: Rene Scharfe
> ---
> .gitignore | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.gitignore b/.gitignore
> index 05cb58a..f370ba0 100644
> --- a/.gitignore
> +++ b/.gitignore
Wouldn't it be better to have this in contrib/co
W dniu 27.09.2016 o 10:39, Jeff King pisze:
> On Mon, Sep 26, 2016 at 09:21:10PM +0200, Lars Schneider wrote:
>
>> On 25 Sep 2016, at 13:26, Jakub Narębski wrote:
>>
>>> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>>>> From: Lars Sc
ing_tree_internal(const char
> *path, const char *src,
> int normalizing)
> {
> int ret = 0, ret_filter = 0;
> - const char *filter = NULL;
> - int required = 0;
> struct conv_attrs ca;
>
> convert_attrs(&ca, path);
> - if (ca.drv) {
> - filter = ca.drv->smudge;
> - required = ca.drv->required;
> - }
Well, this is the same change as a bit eaelier.
>
> ret |= ident_to_worktree(path, src, len, dst, ca.ident);
> if (ret) {
> @@ -936,9 +1225,10 @@ static int convert_to_working_tree_internal(const char
> *path, const char *src,
> }
> /*
>* CRLF conversion can be skipped if normalizing, unless there
> - * is a smudge filter. The filter might expect CRLFs.
> + * is a smudge or process filter (even if the process filter doesn't
> + * support smudge). The filters might expect CRLFs.
>*/
> - if (filter || !normalizing) {
> + if ((ca.drv && (ca.drv->smudge || ca.drv->process)) || !normalizing) {
> ret |= crlf_to_worktree(path, src, len, dst, ca.crlf_action);
> if (ret) {
> src = dst->buf;
> @@ -946,8 +1236,8 @@ static int convert_to_working_tree_internal(const char
> *path, const char *src,
> }
> }
>
> - ret_filter = apply_filter(path, src, len, -1, dst, filter);
> - if (!ret_filter && required)
> + ret_filter = apply_filter(path, src, len, -1, dst, ca.drv, CAP_SMUDGE);
> + if (!ret_filter && ca.drv && ca.drv->required)
> die("%s: smudge filter %s failed", path, ca.drv->name);
>
> return ret | ret_filter;
Looks good to me. I understand ca.drv is checked so that ca.drv->required
and/or ca.drv->smudge / ca.drv->clean / ca.drv->process can be safely
checked, isn't it.
> @@ -1399,7 +1689,7 @@ struct stream_filter *get_stream_filter(const char
> *path, const unsigned char *s
> struct stream_filter *filter = NULL;
>
> convert_attrs(&ca, path);
> - if (ca.drv && (ca.drv->smudge || ca.drv->clean))
> + if (ca.drv && (ca.drv->process || ca.drv->smudge || ca.drv->clean))
LGTM, understandable change.
> return NULL;
>
> if (ca.crlf_action == CRLF_AUTO || ca.crlf_action == CRLF_AUTO_CRLF)
> diff --git a/pkt-line.h b/pkt-line.h
> index 6df8449..3d873f3 100644
> --- a/pkt-line.h
> +++ b/pkt-line.h
> @@ -86,6 +86,7 @@ ssize_t read_packetized_to_buf(int fd_in, struct strbuf
> *sb_out);
>
> #define DEFAULT_PACKET_MAX 1000
> #define LARGE_PACKET_MAX 65520
> +#define PKTLINE_DATA_MAXLEN (LARGE_PACKET_MAX - 4)
What the... didn't you use PKTLINE_DATA_MAXLEN in one of
earlier patches in this series? How this even...?
> extern char packet_buffer[LARGE_PACKET_MAX];
>
> #endif
> diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh
> index dc50938..210c4f6 100755
> --- a/t/t0021-conversion.sh
> +++ b/t/t0021-conversion.sh
I'll stop here, and I'll finish the review later.
To be continued,
--
Jakub Narębski
acket_flush();
All right.
> +
> +while (1) {
> +my ($command) = packet_txt_read() =~ /^command=([^=]+)$/;
> +my ($pathname) = packet_txt_read() =~ /^pathname=([^=]+)$/;
Do we require this order? If it is, is that explained in the
documentation?
> +
> +packet_bin_read();
I think there can be other auxiliary data (like "size=") that
filter do not need to understand.
Anyway, using packet_bin_read() is quite unreadable. What you
mean is to wait until flush packet, or expect flush packet.
my $done = 0;
while ( !$done ) {
( $done, undef ) = packet_bin_read();
}
Or
wait_for_flush();
Or
skip_until_flush();
> +
> +my $input = "";
> +{
> +binmode(STDIN);
> +my $buffer;
> +my $done = 0;
> +while ( !$done ) {
> +( $done, $buffer ) = packet_bin_read();
> +$input .= $buffer;
> +}
> +}
All right.
> +
> +my $output;
> +if ( $command eq "clean" ) {
> +### Perform clean here ###
> +$output = $input;
Perhaps we should also mention here how to handle errors
(the "status=error" and "status=abort" both for upfront
and partial contents case).
> +}
> +elsif ( $command eq "smudge" ) {
> +### Perform smudge here ###
> +$output = $input;
Same as above.
> +}
> +else {
> +die "bad command '$command'";
> +}
All right.
> +
> +packet_txt_write("status=success");
> +packet_flush();
> +while ( length($output) > 0 ) {
> +my $packet = substr( $output, 0, $MAX_PACKET_CONTENT_SIZE );
> +packet_bin_write($packet);
> +if ( length($output) > $MAX_PACKET_CONTENT_SIZE ) {
> +$output = substr( $output, $MAX_PACKET_CONTENT_SIZE );
> +}
> +else {
> +$output = "";
> +}
> +}
> +packet_flush();# flush content!
All right.
> +packet_flush();# empty list!
This is less "empty list!", and more keeping "status=success" unchanged.
> +}
> diff --git a/convert.c b/convert.c
> index 597f561..bd66257 100644
> --- a/convert.c
> +++ b/convert.c
I'll stop here, and I'll finish the review later.
To be continued,
--
Jakub Narębski
On 26 September 2016 at 18:13, Lars Schneider wrote:
>> On 25 Sep 2016, at 00:12, Jakub Narębski wrote:
>> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
>>> From: Lars Schneider
>>>
>>> Move check_pipe() to run_command and make it public. Thi
#x27;ve implemented
> recursive parsing without looking at what you provided, just to see what
> I'd came up with. Though I've not implemented a recursive descent
> parser, but it might suffice.
I think you can implement a parser handling proper nesting of parens
without recursion.
Though... what is the definition in the RFC?
--
Jakub Narębski
CGI.
>
> Document the feature and improve syntax highlight documentation, add
> test to ensure gitweb doesn't crash when language detection is used.
>
> Signed-off-by: Ian Kelling
For what it is worth it:
Acked-by: Jakub Narębski
(but unfortunately *not* tested
W dniu 25.09.2016 o 00:32, Ian Kelling pisze:
> Subject: gitweb: remove unused guess_file_syntax() parameter
>
> Signed-off-by: Ian Kelling
Acked-by: Jakub Narębski
> ---
>
> Notes:
> The only change from v3 is a more descriptive commit message
>
> gitweb/git
W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> apply_filter() returns a boolean that tells the caller if it
> "did convert or did not convert". The variable `ret` was used throughout
> the function to track errors whereas `1` denoted success and `0`
> failur
e)
> test_expect_success "filter: clean empty file" '
> test_expect_success "filter: smudge empty file" '
* double quoted names (twice, see above)
* proper modern names, with single quotes (the rest),
which is as almost all the rest should be using
Best,
--
Jakub Narębski
W dniu 25.09.2016 o 10:55, Vegard Nossum pisze:
> I use rev^..rev daily, and I'm surely not the only one. To save typing
> (or copy-pasting, if the rev is long -- like a full SHA-1 or branch name)
> we can make rev^- a shorthand for that.
>
> The existing syntax rev^! seems like it should do the s
W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> Git filter driver commands with spaces (e.g. `filter.sh foo`) are hard
> to read in error messages. Quote them to improve the readability.
>
> Signed-off-by: Lars Schneider
> ---
> convert.c | 12 ++--
W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> write_packetized_from_fd() and write_packetized_from_buf() write a
> stream of packets. All content packets use the maximal packet size
> except for the last one. After the last content packet a `flush` control
We can check if 'buf + 4 == data', and if it is, we can skip
memcpy() as an optimization.
This is something for the future, but not very important for
having this patch series accepted.
> +
> void packet_buf_write(struct strbuf *buf, const char *fmt, ...)
> {
> va_list args;
>
Best,
--
Jakub Narębski
W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> packet_flush() would die in case of a write error even though for some
> callers an error would be acceptable. Add packet_flush_gently() which
> writes a pkt-line flush packet like packet_flush() but does not di
W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> packet_write_fmt() would die in case of a write error even though for
> some callers an error would be acceptable. Add packet_write_fmt_gently()
> which writes a formatted pkt-line like packet_write_fmt() but do
n Documentation/technical/api-run-command.txt
Or is it not worth it?
Best regards,
--
Jakub Narębski
W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze:
> From: Lars Schneider
>
> Subject: [PATCH v8 02/11] pkt-line: extract set_packet_header()
>
> set_packet_header() converts an integer to a 4 byte hex string. Make
> this function locally available so that other pkt-line functions can
>
-
> 11 files changed, 29 insertions(+), 29 deletions(-)
Diffstat looks correct. Was the patch generated by doing search
and replace?
Best,
--
Jakub Narębski
ome time in
the future; in meantime one can use public-inbox URLs.
HTH,
--
Jakub Narębski
W dniu 24.09.2016 o 00:15, Jakub Narębski pisze:
> W dniu 23.09.2016 o 11:08, Ian Kelling napisał:
>>After curling blob view of unhighlighted large and small text
>> files of perl code and license text 100 times each on a local
>> Apache/2.4.23 (Debian) instance, i
well; the only problem is that `git stash` would
not stash away your changes, and you would need to unmark such
file before saving a stash.
With --assume-unchanged used for ignoring changes to tracked files,
you can quite easily lose your work because you are lying to Git.
Note also that in Git classic "ignored" implies unimportant.
--
Jakub Narębski
W dniu 23.09.2016 o 11:08, Ian Kelling napisał:
> The "highlight" binary can, in some cases, determine the language type
> by the means of file contents, for example the shebang in the first line
> for some scripting languages. Make use of this autodetection for files
> which syntax is not known
o long...
>
> Signed-off-by: Ian Kelling
With, or without this change, it's nice.
Acked-by: Jakub Narębski
> ---
> gitweb/gitweb.perl | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 33d
rs.sh
Nice.
> @@ -709,6 +709,14 @@ test_expect_success HIGHLIGHT \
>git commit -m "Add test.sh" &&
> gitweb_run "p=.git;a=blob;f=test.sh"'
>
> +test_expect_success HIGHLIGHT \
> + 'syntax highlighting (highlighter language autodetection)' \
> + 'git config gitweb.highlight yes &&
Modern way would be
+ 'test_config gitweb.highlight yes &&
but other tests in this file do not use it.
> + echo "#!/usr/bin/ruby" > test &&
Preferred style would be
+ echo "#!/usr/bin/ruby" >test &&
but other tests in this file do not use it.
Sidenote: why Ruby, and not sh / bash, Perl or Python?
> + git add test &&
> + git commit -m "Add test" &&
> + gitweb_run "p=.git;a=blob;f=test"'
> +
> # --
> # forks of projects
>
>
Thank you for your work.
--
Jakub Narębski
W dniu 21.09.2016 o 19:58, Ævar Arnfjörð Bjarmason pisze:
> On Wed, Sep 21, 2016 at 7:09 PM, Jakub Narębski wrote:
>> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
>>> +(?>> +[A-Za-z0-9.-]+
>>> +(?!\
W dniu 21.09.2016 o 20:04, Ævar Arnfjörð Bjarmason pisze:
> On Wed, Sep 21, 2016 at 6:26 PM, Jakub Narębski wrote:
>
>> P.S. I have reworking of commit message parsing and enhancement in my
>> long, long and dated gitweb TODO list :-(
>
> Anything specific you could shar
W dniu 21.09.2016 o 18:37, Junio C Hamano pisze:
> Jakub Narębski writes:
>>> Have you tried "git symbolic-ref HEAD"?
>>>
>>> $ git symbolic-ref HEAD
>>> refs/heads/master
>>>
>>> If you don't want the fully-qualified ref,
W dniu 21.09.2016 o 18:38, Junio C Hamano pisze:
> Jakub Narębski writes:
>> W dniu 06.09.2016 o 21:00, Ian Kelling pisze:
>>
>>> The highlight binary can detect language by shebang when we can't tell
>>> the syntax type by the name of the file.
>&
to do it with one command.
Also, "git rev-parse --verify [--quiet]" can verify only one
revision at once, isn't it? Maybe something like 'git cat-file
--batch-check' would be better (one fork)?
It's a matter of balance between false positives (and unresolving
links) and performance...
Best,
--
Jakub Narębski
W dniu 21.09.2016 o 16:17, Ævar Arnfjörð Bjarmason napisał:
> On Wed, Sep 21, 2016 at 3:33 PM, Jakub Narębski wrote:
>> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
[...]
>>> -# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0)
>>> +
iting to git-describe output, we can get rid of A-F here.
> +|
> +# Just a normal looking Git SHA1
> +[0-9a-fA-F]{7,40}
> +)
> +\b
> +}{
> $cgi->a({-href => href(action=>"object", hash=>$1),
> -class => "text"}, $1);
> - }eg;
> + }egx;
>
> return $line;
> }
>
Good work.
I assume that you are using git-describe output in commit messages
a lot, isn't it?
--
Jakub Narębski
-class => "text"}, $1);
> }eg;
>
Nice and simple.
P.S. I have reworking of commit message parsing and enhancement in my
long, long and dated gitweb TODO list :-(
P.P.S. Kay Sievers no longer works on gitweb, and I think no longer
works at SuSE but at RedHat.
Best,
--
Jakub Narębski
git checkout HEAD^0
Note: checking out 'HEAD^0'.
You are in 'detached HEAD' state. [...]
$ git rev-parse --symbolic-full-name HEAD
HEAD
$ git symbolic-ref HEAD
fatal: ref HEAD is not a symbolic ref
$ git branch
* (HEAD detached at 3e2ebf9)
master
--
Jakub Narębski
W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał:
> Subject: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786
It is more "ancient typo from v1.7.7-rc1-1-g0866786", but perhaps more
important is "ancient typo in a comment"
>
> The Content-Type is application/xhtml+xml, n
Hello Dscho,
W dniu 11.09.2016 o 10:33, Johannes Schindelin napisał:
> On Fri, 9 Sep 2016, Jakub Narębski wrote:
[...]
>> When preserving merges, there are (as far as I understand it), two
>> problems:
>> - what it means to preserve changes (which change to pick,
>
'git config gitweb.highlight yes &&
> - echo "#!/usr/bin/sh" > test.sh &&
> - git add test.sh &&
> - git commit -m "Add test.sh" &&
> - gitweb_run "p=.git;a=blob;f=test.sh"'
> + echo "#!/usr/bin/sh" > test &&
> + git add test &&
> + git commit -m "Add test" &&
> + gitweb_run "p=.git;a=blob;f=test"'
> +
> +test_expect_success HIGHLIGHT \
> + 'syntax highlighting (highlighted, header file)' \
Do we check explicit syntax knowledge (based on the extension),
or autodetect again?
> + 'git config gitweb.highlight yes &&
> + echo "#define ANSWER 42" > test.h &&
> + git add test.h &&
> + git commit -m "Add test.h" &&
> + gitweb_run "p=.git;a=blob;f=test.h"'
>
> # --
> # forks of projects
>
Thank you for your work on this patch,
--
Jakub Narębski
about files (gitignore,
gitattributes, to some extent githooks).
Those are only accessible with `git help ` or, on OS with
installed 'man', also `man `.
Just FYI
--
Jakub Narębski
On 13 September 2016 at 22:11, Lars Schneider wrote:
>> On 13 Sep 2016, at 17:54, Jakub Narębski wrote:
>> On 13 September 2016 at 18:15, David Bainbridge
>> wrote:
>>> Hi Jakub,
>>>
>>> You said:
>>> P.S. At request I can open a separate
pen a channel for use by Ericsson?
Sent (privately to David).
Best regards,
--
Jakub Narębski
Hello Kevin,
On 13 September 2016 at 15:32, Kevin Daudt wrote:
> On Mon, Sep 12, 2016 at 09:51:09PM +0200, Jakub Narębski wrote:
>>
>> P.P.S. Different announcements use different URLs (different channels)
>> to better track where one got information about this survey.
&g
d posted.
> Anyone wishing to record the talks/discussions is likely welcome
> to do so.
I think LWN.net usually covers Linux Plumbers Conference, see e.g.
https://lwn.net/Archives/ConferenceByYear/#2015-Linux_Plumbers_Conference
Hopefully they would cover it this year too.
HTH
--
Jakub Narębski
nly ".
But it was always about working tree version of .
And of course older version control systems didn't have the index...
--
Jakub Narębski
he name of the channel would
be visible to others.
P.P.S. Different announcements use different URLs (different channels)
to better track where one got information about this survey.
Thanks in advance for taking time to answer the survey,
--
Jakub Narębski
on behalf of
Git Development Community
.gitattributes files to
find out all patterns that match specific attribute; you would need
to duplicate configuration:
.gitattributes:
*.conf filter=transform
.git/config
[filter "transform"]
clean = replace-with-placeholder %f
smudge = expand-with-branchname %f
.git/hooks/post-checkout
#!/bin/sh
test "$3" -eq "1" && git checkout -- '*.conf'
Or something like that.
--
Jakub Narębski
W dniu 09.09.2016 o 22:52, Christian Neukirchen napisał:
> Jakub Narębski writes:
>
>> Which means that with "git add -p && git commit ",
>> the "git add -p " would carefully craft the state
>> in the index... and "git commit " wo
ree contents* of
the paths specified on the command line, disregarding any contents
that have been staged for other paths. [...]
Which means that with "git add -p && git commit ",
the "git add -p " would carefully craft the state
in the index... and "git commit " would take worktree version
of for commit, ignoring what was in the index :-(
Currently there is no way to create commit out of subset of the index,
e.g. with "git commit :0:"
Best,
--
Jakub Narębski
hard in general;
> for mathematically inclined you can think about it as a weighted average."
> Not sure that this adds anything useful to the survey and could be removed,
> or at least needs correcting to mention the correct questions.
Fixed question numbers, removed unnecessary and not useful note about
"weighted average".
> OK, that's it from me!
Thanks!
Regards,
--
Jakub Narębski
Hello Johannes,
W dniu 09.09.2016 o 16:40, Johannes Schindelin napisał:
> On Fri, 2 Sep 2016, Jakub Narębski wrote:
>> W dniu 01.09.2016 o 16:20, Johannes Schindelin pisze:
>>> On Thu, 1 Sep 2016, Jakub Narębski wrote:
>>>> W dniu 29.08.2016 o 10:06, Johannes S
ruction sheet could
look like this:
merge -m 1 map(2fd4e1c67a2d28fced849ee1bb76e7391b93eb12)
da39a3ee5e6b4b0d3255bfef95601890afd80709 \t Merge 'foo' into master
Note that it has nothing to do with this series!
Best regards,
--
Jakub Narębski
Hello Johannes,
W dniu 09.09.2016 o 15:06, Johannes Schindelin napisał:
> On Sun, 28 Aug 2016, Jakub Narębski wrote:
>> W dniu 28.08.2016 o 10:38, Johannes Schindelin pisze:
>>
>>> I would like to strongly caution against putting too much stock into
>>> this user
depends on the branch?
Or make post-checkout hook invoke smudge filter... though
`git cat-file --filters` is not in any released version, I think...
Best,
--
Jakub Narębski
W dniu 06.09.2016 o 19:03, Stefan Beller pisze:
> On Tue, Sep 6, 2016 at 7:05 AM, Jakub Narębski wrote:
>> If not for `color.moved`, I would have thought that instead of adding
>> new command line option `--color-moved` (and the fact that it is on
>> by default),
const char *new_refname);
Just a sidenote: does Git have a naming convention for query functions
returning a boolean, for example using is_* as a prefix? That is, shouldn't
it be
int is_rename_ref_available(const char *old_refname, const char *new_refname);
I'm sorry if this is too nitpicky
--
Jakub Narębski
n as a signal of stronger detection, namely "-M -M" (and also
"-C -C" to handle copy detection) that git-blame uses...
--
Jakub Narębski
W dniu 06.09.2016 o 00:27, Eric Wong pisze:
> larsxschnei...@gmail.com wrote:
>> -int git_open_noatime(const char *name)
>> +int git_open_noatime_cloexec(const char *name)
[...]
>
> I question the need for the "_cloexec" suffixing in the
> function name since the old function is going away entire
Hello,
As I wrote previously, I am thinking about returning to doing the
Git User's Survey this year.
Message-ID: <577e6f32.7020...@gmail.com>
https://marc.info/?l=git&m=146790381602547&w=2
https://public-inbox.org/git/577E6F32.7020007%40gmail.com/
In this email I'd like to propose the re
W dniu 03.09.2016 o 16:43, Satoshi Yasushima pisze:
> msgid "Tracking branch %s is not a branch in the remote repository."
> -msgstr "トラッキング・ブランチ %s は遠隔リポジトリのブランチではありません。"
> +msgstr ""
What for is the above part of change (empty string)?
> +"トラッ
W dniu 04.09.2016 o 07:31, Stefan Beller pisze:
> On Sat, Sep 3, 2016 at 5:25 AM, Jakub Narębski wrote:
>> W dniu 03.09.2016 o 05:31, Stefan Beller pisze:
>>
>>> When moving code (e.g. a function is moved to another part of the file or
>>> to a different file)
W dniu 03.09.2016 o 05:31, Stefan Beller pisze:
> When moving code (e.g. a function is moved to another part of the file or
> to a different file), the review process is different than reviewing new
> code. When reviewing moved code we are only interested in the diff as
> where there are differenc
W dniu 03.09.2016 o 04:17, Junio C Hamano pisze:
> Please remember to always state
>
> - what you wanted to achieve;
>
> - what you did (the version of git and the command sequence to reproduce
>the behavior);
I wonder if it be worth adding to not use aliases (or expand them). I have
see
, 227 deletions(-)
>
> Based-On: libify-sequencer at https://github.com/dscho/git
> Fetch-Base-Via: git fetch https://github.com/dscho/git libify-sequencer
> Published-As: https://github.com/dscho/git/releases/tag/prepare-sequencer-v1
> Fetch-It-Via: git fetch https://github.com/dscho/git prepare-sequencer-v1
An unrelated question: Dscho, how are you generating above lines?
--
Jakub Narębski
Hello Johannes,
W dniu 01.09.2016 o 16:20, Johannes Schindelin pisze:
> On Thu, 1 Sep 2016, Jakub Narębski wrote:
>> W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze:
>>> if (commit_lock_file(&msg_file) < 0)
>>> return error(_(
Hello Johannes,
W dniu 01.09.2016 o 16:13, Johannes Schindelin pisze:
> On Thu, 1 Sep 2016, Jakub Narębski wrote:
>> 'bol' is beginning-of-line, isn't it (a complement to eol)?
>
> Yep. How did you guess? :-)
Wouldn't 'beg' and 'end' i
Hello Johannes,
W dniu 01.09.2016 o 15:56, Johannes Schindelin pisze:
> On Thu, 1 Sep 2016, Jakub Narębski wrote:
>> It's a pity that emulation of named parameters in C requires
>> relying on designated inits from C99
>>
>> typedef struct {
>
Hello Johannes,
W dniu 01.09.2016 o 15:33, Johannes Schindelin pisze:
> On Wed, 31 Aug 2016, Jakub Narębski wrote:
>> W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze:
>>> @@ -471,17 +487,20 @@ int sequencer_commit(const char *defmsg, struct
>>> replay_o
Hello,
W dniu 01.09.2016 o 15:12, Johannes Schindelin pisze:
> On Wed, 31 Aug 2016, Jakub Narębski wrote:
>> W dniu 31.08.2016 o 21:10, Junio C Hamano pisze:
>>> So I am not sure if we want a parsed commit there (I would not
>>> object if we kept the texual obj
W dniu 01.09.2016 o 11:37, Johannes Schindelin pisze:
> On Wed, 31 Aug 2016, Junio C Hamano wrote:
>> Jakub Narębski writes:
>>
>>>> diff --git a/sequencer.c b/sequencer.c
>>>> index 06759d4..3398774 100644
>>>> --- a/sequencer.c
>>
Hello Johannes
W dniu 01.09.2016 o 09:52, Johannes Schindelin pisze:
> On Wed, 31 Aug 2016, Jakub Narębski wrote:
>> CC-ed to Jiang Xin, L10N coordinator.
>> W dniu 29.08.2016 o 10:05, Johannes Schindelin pisze:
[...]
>>> - /* Different translation strings fo
Hello Johannes,
W dniu 01.09.2016 o 09:49, Johannes Schindelin pisze:
> On Wed, 31 Aug 2016, Jakub Narębski wrote:
>> W dniu 29.08.2016 o 10:05, Johannes Schindelin pisze:
[...]
>> Hmmm... commit_list is, as defined in commit.h, a linked list.
>
> That is the most prominen
Hello Johannes,
W dniu 01.09.2016 o 10:01, Johannes Schindelin pisze:
> On Wed, 31 Aug 2016, Jakub Narębski wrote:
>> W dniu 31.08.2016 o 20:36, Johannes Schindelin pisze:
>>
>> I wonder: would 'git cherry-pick --continue' be able to finish
>> 'g
need to come up
with a better function name (to describe its function better).
> +
> /*
> * Reads a file that was presumably written by a shell script, i.e.
> * with an end-of-line marker that needs to be stripped.
>
And thus we got to the last patch in this series. I have skipped
patches that already got reviewed; are there some that you would
like to have second review of? Is there patch series that needs
to be applied earlier that needs a review?
P.S. I'll try to respond to your comments later today.
Regards,
--
Jakub Narębski
x27;bol' is beginning-of-line, isn't it (a complement to eol)?
> for (i = 0; i < ARRAY_SIZE(todo_command_strings); i++)
> if (skip_prefix(bol, todo_command_strings[i], &bol)) {
> item->command = i;
>
--
Jakub Narębski
Hello Johannes,
W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze:
> The sequencer_commit() function already knows how to amend commits, and
> with this new option, it can also clean up commit messages (i.e. strip
> out commented lines). This is needed to implement rebase -i's 'fixup'
> and 's
W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze:
> This teaches the sequencer_commit() function to take an argument that
> will allow us to implement "todo" commands that need to amend the commit
> messages ("fixup", "squash" and "reword").
>
> Signed-off-by: Johannes Schindelin
> ---
> se
W dniu 29.08.2016 o 10:06, Johannes Schindelin pisze:
> In the upcoming commits, we will implement more and more of rebase
> -i's functionality. One particular feature of the commands to come is
> that some of them allow editing the commit message while others don't,
> i.e. we cannot define in the
W dniu 31.08.2016 o 22:12, Junio C Hamano pisze:
> Jakub Narębski writes:
>> Johannes Schindelin wrote:
>>> + else {
>>> + opts->gpg_sign = buf.buf + 2;
>>> + strbuf_detach(&buf, NULL
x27;)
> + buf.len--;
> + buf.buf[buf.len] = '\0';
> + }
Isn't there some strbuf_chomp() / strbuf_strip_eof() function?
Though as strbuf_getline() uses something similar...
> +
> + if (!starts_with(buf.buf, "-S"))
> + strbuf_reset(&buf);
Should we signal that there was problem with a file contents?
> + else {
> + opts->gpg_sign = buf.buf + 2;
> + strbuf_detach(&buf, NULL);
Wouldn't we leak 2 characters that got skipped? Maybe xstrdup would
be better (if it is leaked, and not reattached)?
> + }
> + }
> +
> return 0;
> + }
>
> if (!file_exists(git_path_opts_file()))
> return 0;
>
--
Jakub Narębski
W dniu 31.08.2016 o 21:10, Junio C Hamano pisze:
> Jakub Narębski writes:
>
>>> diff --git a/sequencer.c b/sequencer.c
>>> index 06759d4..3398774 100644
>>> --- a/sequencer.c
>>> +++ b/sequencer.c
>>> @@ -709,6 +709,8 @@ static int r
Hello Johannes,
W dniu 31.08.2016 o 20:36, Johannes Schindelin pisze:
> On Wed, 31 Aug 2016, Jakub Narębski wrote:
>> W dniu 29.08.2016 o 10:04, Johannes Schindelin pisze:
> I am of the opinion that overzealous checking of certain implementation
> details is something to be av
W dniu 29.08.2016 o 10:05, Johannes Schindelin pisze:
> The `git-rebase-todo` file contains a list of commands. Most of those
> commands have the form
>
>
>
> The is displayed primarily for the user's convenience, as
> rebase -i really interprets only the part. However, there
> are *
W dniu 29.08.2016 o 10:05, Johannes Schindelin pisze:
> The subcommands are used exactly once, at the very beginning of
> sequencer_pick_revisions(), to determine what to do. This is an
> unnecessary level of indirection: we can simply call the correct
> function to begin with. So let's do that.
CC-ed to Jiang Xin, L10N coordinator.
W dniu 29.08.2016 o 10:05, Johannes Schindelin pisze:
> Signed-off-by: Johannes Schindelin
> ---
> sequencer.c | 7 ++-
> 1 file changed, 2 insertions(+), 5 deletions(-)
>
> diff --git a/sequencer.c b/sequencer.c
> index cbdce6d..1b65202 100644
> --- a
W dniu 29.08.2016 o 10:05, Johannes Schindelin pisze:
> When we came up with the "sequencer" idea, we really wanted to have
> kind of a plumbing equivalent of the interactive rebase. Hence the
> choice of words: the "todo" script, a "pick", etc.
>
> However, when it came time to implement the ent
W dniu 29.08.2016 o 10:04, Johannes Schindelin pisze:
> The sequencer was introduced to make the cherry-pick and revert
> functionality available as library function, with the original idea
> being to extend the sequencer to also implement the rebase -i
> functionality.
>
> The test to ensure that
iconv might be good example, but I think it is not a practical
one; are there development environments that do not handle UTF-8?
More practical would be to have for example LFS-ish solution of
storing files as-is in a specified directory. ROT13 is also good,
if not a very practical example. Or rezipping all ZIP-compression
based files (ODF, JAR/WAR, DOCX / OOXML, CBZ, EPUB, APK, etc.).
--
Jakub Narębski
101 - 200 of 501 matches
Mail list logo
