shadow,Natural shadow
Photo Retouching Service
Photo Retouching, Glamour Retouching.
Our Service is 24-48 hours but we can deliver the images sooner in case of
emergency.
We can give you editing test on your photos.
We do unlimited revisions until you are satisfied with the work.
Thanks,
Jan Williams
th a fact that test restarts daemon few times. I can barely
wrap my head around it but I guess it's somewhat around "shell still tries to
read fifo while attempt to create new one is made".
Regards
Jan
ent might possibly land in the file after zeroing.
The reason I'm asking is because /bin/sh in my distribution (mksh) actually
manifests the issue -- test fails because at the time of grep output was not
processed yet (fixed by sleep 1 before grep). Also there is an issue with output
of previous test landing in daemon.log despite ">daemon.log".
Regards
Jan
;abcd1234", "summary": "Implement loop",
"characters": ")" },
{ "commit": "d1234abc", "summary": "Add missing
semicolon", "characters": ";" },
{ "commit": "abcd1234", "summary": "Implement loop",
"characters": " }" }
]
What would be the most direct way to achieve such a character-based
blame/annotate? Should I write some sort of Git extension, or hack
into Git's source code?
E.g. I looked for an option in `git-blame` or `git-annotate` to change
the "next line boundary" from "carret return" (line-based blame) to
"any whitespace" (word-based blame) or "character-by-character"
(character-based blame), but I didn't find it. Could this be
implemented in `blame.c`? If so, which methods would need tweaking?
Many thanks!
Jan
Hello there,
I would like to ask how can I uninstall Git?
Kind regards
Jan
p
git log -1
# here, you can see the bad merge commit message
Regards
Jan
I have been trying to reach you contact
me--(jonathansymonds...@hotmail.com) for more details
On Tue, 2017-10-03 at 05:10 -0400, Jeff King wrote:
> I dunno. Maybe I am wrong, because certainly I never set it. We've
> had
> two reports on the list since v2.14.2. The motivation for the first
> was
> "I have no idea why I set that, and I'll switch to auto". This is the
> second.
>
I also
> On 20. Aug 2017, at 12:27 , Andreas Heiduk <ashei...@gmail.com> wrote:
>
> Am 19.08.2017 um 14:45 schrieb Jan Teske:
>> Is there any way to fix such branches from subfolders in a way that they
>> integrate correctly with the converted git repository, without losi
Hello,
I’m trying to do a one-time conversion of a large SVN repository to git using
git-svn. Unfortunately, this SVN repo contains a substantial amount of
non-standard branches created from a subfolder of trunk/. Users that only need
to work on part of the code inside the repo usually create
.` inside the extracted tarball, or maybe
`git clone `?
Many thanks,
Jan Keromnes
On Wed, Jul 19, 2017 at 12:16 PM, Jan Keromnes <j...@linux.com> wrote:
> Hello,
>
> I'm trying to build a profile-optimized Git. I used to do this with
> the following commands:
>
> mkdir /t
http://git.661346.n2.nabble.com/make-profile-issue-on-Git-2-1-0-td7616964.html
Is it possible that the above commit fixed `make profile`, but not
`make profile-fast`?
Or, is there a good way for me to work around this issue?
Many thanks,
Jan Keromnes
, refs/mirror/* in addition to your branches in
> refs/heads/*). The obvious downside is that anybody cloning your
> downstream mirror doesn't pick up refs/mirror unless they configure
> that refspec explicitly.
This sounds very useful. How would one go about setting up this
configuration?
--
Kind regards,
Jan Danielsson
emote update --prune
git push
This seems to accomplish everything I want except that the the "git
push" deletes any branches I have created on my self-hosted repository.
Am I doing it completely wrong? If not, how do I make my branches
survive the push?
--
Kind regards,
Jan Danielsson
would be to "just" enable sending a whole patch
set in 2 rounds manually. But I didn't find any way how to do it right.
Regards
Jan
> >
> > I wonder if something like this would Just Work for this case without
> > any configuration or command-line options, with the added
"cc" => \@initial_cc,
> @@ -358,6 +366,8 @@ $rc = GetOptions(
> "force" => \$force,
> "xmailer!" => \$use_xmailer,
> "no-xmailer" => sub {$use_xmailer = 0},
> +
Hello, thank you for posting this improvement. I've been missing such feature
in git. I hope to test it soon.
Jan Viktorin
RehiveTech
Sent from a mobile device
Původní zpráva
Od: xiaoqiang zhao
Odesláno: pondělí, 1. května 2017 15:00
Komu: git@vger.kernel.org
Kopie: gits...@pobox.com; vikto
On 22.03.2017 13:08, Junio C Hamano wrote:
> Please respond to the list, saying it is OK to add your "sign-off"
> (see Documentation/SubmittingPatches) to these patches.
Please feel free to do so and thanks for handling the issue.
Regards
Jan
It appears more tests are affected:
$ grep -r '^[[:space:]]*EOF &&' .
./t7406-submodule-update.sh:EOF &&
./t7030-verify-tag.sh: EOF &&
./t7030-verify-tag.sh: EOF &&
./t7004-tag.sh: EOF &&
./t7004-tag.sh: EOF &&
attaching patch for t7406 and t7030 which both fail even after fix is
ote that I'm not subscribed to mailing list so in case of any questions
please mail me directly.
Regards
Jan
diff -urN git-2.11.1.orig/t/t5615-alternate-env.sh
git-2.11.1/t/t5615-alternate-env.sh
--- git-2.11.1.orig/t/t5615-alternate-env.sh2017-02-03 02:24:45.115143042
+0100
+++ git-2.11.1
Current version: 2.10.2
Example workflow:
* I would do a global substitution across a source tree, e.g. `perl -i
-pe 's{OLD_FOO\(x\)}{NEW_BAR(x, 0)}' *.c`
* Using `git add -p`, I would verify each of the substitutions that they
make sense in their respective locations, and, based on that,
details below, and I can provide further debug information if you
don't already know the problem.
Thanks,
Jan
[0] "`make profile-install` fails in 2.9.3" -
https://marc.info/?l=git=147274608823171=2
[1] "Fwd: Git 2.8.1 fails test 32 of t7300-clean.sh, breaks profile
build" - http
,
Jan Keromnes
---
Steps to reproduce:
curl https://www.kernel.org/pub/software/scm/git/git-2.9.3.tar.xz | tar xJ \
&& cd git-2.9.3 \
&& make prefix=/usr profile-install install-man -j18
Expected result:
- runs all tests to get a profile (ignoring occ
m not subscribed to the list.
Thanks
Jan
The pre-receive hook from my quick testing => press Ctrl-C on the client
when it is busy processing the 'sleep 5'
In my testing I was committing/pushing 32MB+ binary files that take some
time to process.
#!/bin/bash
trap 'echo TRAP >> /tmp/git
line "Removing possible_sub1/", it looks like Git
2.8.2 removes a possible submodule while executing `git clean -f -d`,
whereas the test expects it not to.
Is it possible to make Git's output even more verbose, so that it
tells why it decides to remove "possible_sub1"? Are you able
On Sat, Apr 30, 2016 at 3:19 AM, David Aguilar <dav...@gmail.com> wrote:
> On Wed, Apr 27, 2016 at 11:12:25AM +0200, Jan Smets wrote:
>> Hi
>>
>> Please consider following example
>>
>> #!/bin/bash
>> rm -rf /tmp/gittest
>> mkdir /tmp/gittest
&
chmod 0 possible_sub1/.git &&
# >to_clean/should_clean.this &&
# git clean -f -d &&
# test_path_is_file possible_sub1/.git &&
# test_path_is_file possible_sub1/hello.world &&
# te
executing git difftool with the -d option :
/usr/lib/git-core/git-difftool line 260: File exists
A possible solution is to build an unique list in @working_tree
The purpose is to edit/resolve the conflict in the difftool.
Thanks!
--
Smets Jan
j...@smets.cx
--
To unsubscribe from this list: send
> One thing I wondered about is whether this should be enabled by
> default or not. Long-time users of git-p4 might be a bit surprised to
> find their git commits suddenly gaining an extra Job: field.
I thought about that too when but then I realized that there's no
switch for the reverse
> By the way, you may or may not have noticed that I've been
> reordering the lines of your message quoted in my responses; around
> here, top-posting is frowned upon.
I haven't noticed. Thanks for pointing out.
As for the submitGit cover letter I wanted to raise at least an issue
(if not create
of the commits.
Maybe submitGit tried to be smart there? Or maybe it just really
doesn't support it (yet?).
On Tue, Apr 19, 2016 at 11:09 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Jan Durovec <jan.duro...@gmail.com> writes:
>
>> On Tue, Apr 19, 2016 at 8:50 P
Huh... seems that it works :)
v3 sent in 2 parts
On Tue, Apr 19, 2016 at 8:50 PM, Jan Durovec <jan.duro...@gmail.com> wrote:
>> Any submitGit users? I think it lets you throw multiple-patch
>> series just fine. In this case, you'd prepare a two patch series on
>> a bra
commit messages on git side).
The jobs are added to the message in the same format as is expected when
migrating in the reverse direction.
Signed-off-by: Jan Durovec <jan.duro...@gmail.com>
---
git-p4.py | 12 ++
t/lib-git-p4.sh| 9 +
t/t9829-git-p4-jobs.s
Preliminary clean-up of testing libraries for git-p4.
* spaces added to both sides of () in function definitions in lib-git-p4
* tab indentation added to git-p4 tests when <<- redirection is used
Signed-off-by: Jan Durovec <jan.duro...@gmail.com>
---
t/lib-git-p4.sh
> Any submitGit users? I think it lets you throw multiple-patch
> series just fine. In this case, you'd prepare a two patch series on
> a branch, 1/2 being the clean-up and 2/2 being the new feature, and
> if you give that branch to submitGit as a whole it should do the
> right thing, I'd
patch I'll
* add spaces before () for functions in t/lib-git-p4.sh
* remove name local variable in p4_add_job/user in t/lib-git-p4.sh
* fix t/t98* leading tabs where <<- is used
On Tue, Apr 19, 2016 at 7:47 PM, Junio C Hamano <gits...@pobox.com> wrote:
> Jan Durovec <jan.duro...
(see t/t9826...)
...is there anything left to fix in this patch or is it good as is?
I.e. would you prefer me to change the code mentioned above at the cost
of code style consistency?
Is there something else that I have missed in my enumeration?
Regards,
Jan
On Tue, Apr 19, 2016 at 6:45 PM, Junio
commit messages on git side).
The jobs are added to the message in the same format as is expected when
migrating in the reverse direction.
Signed-off-by: Jan Durovec <jan.duro...@gmail.com>
---
git-p4.py | 12 ++
t/lib-git-p4.sh| 10 +
t/t9829-git-p4-jobs.s
advise how to mark it as executable? Does it need to be
added to some configuration file? Or am I interpreting the error
message incorrectly?
Regards,
Jan
On Sat, Apr 16, 2016 at 12:10 AM, Luke Diamand <l...@diamand.org> wrote:
> On 15 April 2016 at 21:27, Junio C Hamano <gits...@po
Hi,
this patch makes it possible to use --show-linear-break in `git log --graph
--oneline --all`.
(Please Cc me on replies, I'm not subscribed to the Git ML.)
Cheers,
Jan
--
Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/From 1ac6bb7c31652835d3d046c82e423f0cea6e0904 Mon
when describing master:
$ git describe master
v4.2-2-g34eb80b
$ git describe master --match=v4.1
v4.1-1046-g34eb80b
However when I merged master into next, it started producing those incorrect
results.
--
- Jan Hudec <b...@ucw.cz>
--
To unsubscribe from this list: send th
to hear them.
Thank you
- Jan
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
message:
$ git gc --prune=all
error: refs/heads/master does not point to a valid object!
fatal: bad object refs/heads/master
error: failed to run repack
$ git log -1
fatal: bad object HEAD
This behaviour has been observed with version 2.4.4, 2.5.[12] and 2.6.1
Thank you
- Jan
--
To unsu
, it works as a whitelist
of allowed mechanisms for authentication selected from the ones
supported by the installed SASL perl library.
Signed-off-by: Jan Viktorin vikto...@rehivetech.com
---
Documentation/git-send-email.txt | 11 +++
git-send-email.perl | 26
On Sun, 9 Aug 2015 14:13:33 -0400
Eric Sunshine sunsh...@sunshineco.com wrote:
On Wed, Aug 5, 2015 at 3:17 AM, Jan Viktorin
vikto...@rehivetech.com wrote:
Do I understand well that you are complaining about too
narrow commmit message?
Yes, I'm a complainer. ;-) It's minor, though
could see its contents
but still...). Is it suitable for my tests?
* Should I check the behaviour '--smtp-auth overrides
sendemail.smtpAuth'?
Regards
Jan
On Sun, 2 Aug 2015 14:57:19 -0400
Eric Sunshine sunsh...@sunshineco.com wrote:
On Sun, Aug 2, 2015 at 12:42 PM, Jan Viktorin
vikto
On Sun, 02 Aug 2015 11:28:49 -0700
Junio C Hamano gits...@pobox.com wrote:
Jan Viktorin vikto...@rehivetech.com writes:
Authen::SASL gives:
No SASL mechanism found
at /usr/share/perl5/vendor_perl/Authen/SASL.pm line 77.
at /usr/share/perl5/core_perl/Net/SMTP.pm line 207
,
it works as a whitelist of allowed mechanisms for
authentication selected from the ones supported by
the installed SASL perl library.
Signed-off-by: Jan Viktorin vikto...@rehivetech.com
---
Changes v1 - v2:
- check user input by regex
- added documentation
- still missing a test
already mentioned. at least, it filters out the
unwanted characters like '/', '.', etc.
Regards
Jan
On Sun, 2 Aug 2015 05:41:29 -0400
Eric Sunshine sunsh...@sunshineco.com wrote:
On Sat, Aug 1, 2015 at 2:19 PM, Jan Viktorin
vikto...@rehivetech.com wrote:
On Sat, 1 Aug 2015 05:33:28 -0400 Eric
:28 -0400
Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, Jul 31, 2015 at 7:33 PM, Jan Viktorin
vikto...@rehivetech.com wrote:
When sending an e-mail, the client and server must
agree on an authentication mechanism. Some servers
(due to misconfiguration or a bug) denies valid
s
is defined, it works as a whitelist
of allowed mechanisms for authentication. There
are four mechanisms supported: PLAIN, LOGIN,
CRAM-MD5, DIGEST-MD5. However, their availability
depends on the installed SASL library.
Signed-off-by: Jan Viktorin vikto...@rehivetech.com
---
git-send-email.perl | 31
shows like 150k files and only like 159 were
deleted?
There should be like 149k files in that archive.
Also only the few files are all from var and none from etc or srv
where definitely files changed in too! (and show up in latest.zip.files)
Is there a limit of files git archive can process?
lg
Jan
On 17.06.2015 18:42, Junio C Hamano wrote:
Jan-Philip Gehrcke jgehr...@googlemail.com writes:
I was surprised to see that the output of
git log --encoding=utf-8 --format=format:%b
can contain byte sequences that are invalid in UTF-8. Note: I am using
git 2.1.4 and the %b format
On 15.06.2015 18:21, Torsten Bögershausen wrote:
On 2015-06-15 10.50, Jan-Philip Gehrcke wrote:
Let me describe what I think it currently does:
The program attempts to re-code a log message, so it follows the chain
raw input - unicode - raw output
Not sure what raw input/output means
not entirely sure where this discussion should lead to. However, I
think that if the behavior of the software will not be changed, then the
documentation for the --encoding option should be more precise and
clarify what actually happens behind the scenes. What do you think?
Cheers,
Jan
printing all such tags would let
them select the desired tag with grep or some more elaborate scripting...
Just a thought.
Honza
--
Jan Kara j...@suse.cz
SUSE Labs, CR
--
To unsubscribe from this list: send the line unsubscribe git
On Thursday 2014-02-20 00:40, Junio C Hamano wrote:
On Wed, Feb 19, 2014 at 2:58 PM, Jan Engelhardt jeng...@inai.de wrote:
Looking at it from one more angle, `git fetch r --tags` and
`git push r --tags` is now no longer symmetric :(
I would have loved to hear such comments _during_
On Thu, 20 Feb 2014 12:06:17, Michael Haggerty wrote:
On 02/19/2014 11:58 PM, Jan Engelhardt wrote:
Looking at it from one more angle, `git fetch r --tags` and
`git push r --tags` is now no longer symmetric :(
I'm glad you brought this up, because I didn't really think about
whether git push
it was done
extensively for git add -- how to get back the old
behavior (perhaps through now-different commands).
thanks,
Jan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo
On Thursday 2013-05-23 20:16, Bernhard R. Link wrote:
Not sure if German users would know what hunk means, in case we
leave it untranslated. And I'm not sure if I would understand Kontext.
I tend to leave it untranslated.
Anyone found a German translation of the Patch manpage? Translating
On Wednesday 2013-05-22 17:52, Holger Hellmuth (IKS) wrote:
Not sure if German users would know what hunk means, in case we
leave it untranslated. And I'm not sure if I would understand Kontext.
I tend to leave it untranslated.
I don't think Bereich is a bad choice. As hunk is not a word
On Wednesday 2013-05-15 13:26, Jens Lehmann wrote:
Hmm, I rather tend towards using Repository instead of Archiv too, as
Archiv can mean anything from a tar-file to a git repository
It's exactly the reasoning I made in my git-glossary.txt sample
(of which the reasoning apparently has not made
On Wednesday 2013-05-15 14:27, Jens Lehmann wrote:
While it's spoken Packdatei, the way to actually write it is
.pack-Datei or .pack-Datei.
I actually had the '-' in there too until I tried to look up Zip-Datei
in the Duden. While I don't get the leading '.' (I cannot remember having
seen
On Wednesday 2013-05-15 17:31, Holger Hellmuth (IKS) wrote:
I actually had the '-' in there too until I tried to look up Zip-Datei
in the Duden. While I don't get the leading '.' (I cannot remember having
seen that anywhere, AFAIK the file extensions are always used without the
dot), I'm not
On Monday 2013-05-13 14:54, Thomas Rast wrote:
As I am sure you are all aware, there are two main religions as to how
one can translate technical material into German: leave the technical
terms mostly in English, or translate them to an appropriate
corresponding word. I'll denote them G+E and
On Monday 2013-05-13 20:57, Ralph Haußmann wrote:
There is a glossary for the pro-git book (see [2]) but it is not up-to-date
and it is also mixed. Therefor I would like to avoid using this glossary.
I like the idea of a shared wiki (git de.po and pro-git).
I suggest a single page as overview
Am Dienstag, den 23.04.2013, 22:50 +0200 schrieb Johan Herland:
On Tue, Apr 23, 2013 at 4:59 PM, Junio C Hamano gits...@pobox.com wrote:
Jan Weitzel j.weit...@phytec.de writes:
Hello,
I have the following problem: I have 2 bare git repositories one has
several branches and tags.
If I
is to fetch only specific branches and the related tags.
Jan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Am Dienstag, den 23.04.2013, 13:25 +0200 schrieb Johan Herland:
On Tue, Apr 23, 2013 at 12:53 PM, Jan Weitzel j.weit...@phytec.de wrote:
Hello,
I have the following problem: I have 2 bare git repositories one has
several branches and tags.
If I try this in the second repository:
git
Duy Nguyen pclo...@gmail.com wrote:
On Sat, Mar 30, 2013 at 8:45 PM, Jan Larres j...@majutsushi.net wrote:
I would expect the last command to also report 'set'. I've also tried
other patterns like 'foo/' and 'foo*', but it didn't make any
difference.
Try foo/**. You need 1.8.2 though
subjective.
Cheers,
Jan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
'unspecified'. More precisely:
$ git init test
Initialized empty Git repository in /home/jan/test/.git/
$ cd test
$ mkdir foo
$ touch foo/bar
$ echo foo export-ignore .gitattributes
$ git check-attr export-ignore foo
foo: export-ignore: set
$ git check-attr export-ignore foo/bar
foo/bar: export-ignore
copy)
Is there some way how to do it without swithing to each branch and update
them manually?
Thanks,
Jan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
that was added to 1.5.x in this merge has a '*' suffix
for 1.5.x\www.
This '*' is the marker for a non-inheritable mergeinfo range.
The '*' means that only the path on which the mergeinfo is explicitly set has
had this range merged into it.
Signed-off-by: Jan Pesta jan.pe...@certicon.cz
---
perl/Git/SVN.pm
is explicitly set
has had this range merged into it.
Signed-off-by: Jan Pesta jan.pe...@certicon.cz
---
perl/Git/SVN.pm | 5 +
1 file changed, 5 insertions(+)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0ebc68a..74d49bb 100644
--- a/perl/Git/SVN.pm
+++ b/perl/Git/SVN.pm
@@ -1493,6
Hi,
I found a problem when using GIT-SVN.
In inproperly merges in SVN causes that the ranges contains additional
character *.
Attached patch fix this issue, I have it already tested for several months.
Regards,
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s
Sorry,
My fault :)
Here is a patch atached.
Jan
Kind regards / S pozdravem
Jan Pešta
SW Engineer Sr.
CertiCon a.s., www.certicon.cz
Vaclavska 12
12000 Prague 2
Czech Republic
Office Prague: +420 224 904 406
Mobile: +420 604 794 306
E-mail: jan.pe...@certicon.cz
-Original Message
Hi again,
Finally I created patch according to document.
Please have a look on referenced site for more details.
Currently I have a problems in our project, where SVN is main repository and
merge-info contains * which causes troubles in SVN.pm.
Regards,
Jan
Kind regards / S pozdravem
Jan
mergeinfo range.
The '*' means that only the path on which the mergeinfo is explicitly set
has had this range merged into it.
Signed-off-by: Jan Pesta jan.pe...@certicon.cz
---
perl/Git/SVN.pm | 1 +
1 file changed, 1 insertion(+)
diff --git a/perl/Git/SVN.pm b/perl/Git/SVN.pm
index 0ebc68a..6bd18e9
it upstream?
Regards
Jan Rüegg
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 2012-10-02 10:26, Johannes Sixt wrote:
Note that git commit -m A --allow-empty *DID* create a commit. Only, that
it received the same name (SHA1) as the commit you created before it
because it had the exact same contents (files, parents, author, committer,
and timestamps). Obviously,
On Wednesday 2012-10-03 21:03, Junio C Hamano wrote:
I said that git reset --keep started out as an ugly workaround for
the lack of git checkout -B $current_branch. Now we have it, so
we can afford to make reset --keep less prominently advertised in
our tool set. As I already said back then,
() is already in master.
= Nothing to do. :)
Regards
Jan
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
---
I wrote a small C program to compare the result of all is* functions
that Git replaces against the libc version. These are the only ones that
differ. Which matches what Jan Schönherr commented.
ctype.c | 6 +++---
git-compat-util.h | 11 ++-
2 files changed, 9
2047 than v1
- updated commit messages/comments
Regards
Jan
Jan H. Schönherr (7):
utf8: fix off-by-one wrapping of text
format-patch: do not wrap non-rfc2047 headers too early
format-patch: do not wrap rfc2047 encoded headers too late
format-patch: introduce helper function last_line_length
From: Jan H. Schönherr schn...@cs.tu-berlin.de
The wrapping logic in strbuf_add_wrapped_text() does currently not allow
lines that entirely fill the allowed width, instead it wraps the line one
character too early.
For example, the text This is the sixth commit. formatted via
%w(11,1,2) (wrap
From: Jan H. Schönherr schn...@cs.tu-berlin.de
Do not wrap the second and later lines of non-rfc2047-encoded headers
substantially before the 78 character limit.
Instead of passing the remaining length of the first line as wrapping
width, use the correct maximum length and tell
From: Jan H. Schönherr schn...@cs.tu-berlin.de
Encoded characters add more than one character at once to an encoded
header. Include all characters that are about to be added in the length
calculation for wrapping.
Additionally, RFC 2047 imposes a maximum line length of 76 characters
if that line
From: Jan H. Schönherr schn...@cs.tu-berlin.de
Currently, an open-coded loop to calculate the length of the last
line of a string buffer is used in multiple places.
Move that code into a function of its own.
Signed-off-by: Jan H. Schönherr schn...@cs.tu-berlin.de
---
pretty.c | 25
From: Jan H. Schönherr schn...@cs.tu-berlin.de
RFC 2047 requires more characters to be encoded than it is currently done.
Especially, RFC 2047 distinguishes between allowed remaining characters
in encoded words in addresses (From, To, etc.) and other headers, such
as Subject.
Make add_rfc2047
From: Jan H. Schönherr schn...@cs.tu-berlin.de
According to RFC 2047 and RFC 822, rfc2047 encoded words and and rfc822
quoted strings do not mix. Since add_rfc2047() no longer leaves RFC 822
specials behind, the quoting is also no longer necessary to create a
standard-conform mail.
Remove
From: Jan H. Schönherr schn...@cs.tu-berlin.de
git-format-patch does currently not parse user supplied extra header
values (e. g., --cc, --add-header) and just replays them. That forces
users to add them RFC 2822/2047 conform in encoded form, e. g.
--cc '=?UTF-8?q?Jan=20H=2E=20Sch=C3=B6nherr
| \
+ GIT_PATHSPEC_MAGIC))
Normal isprint() only includes space (32) from the white-space characters.
The other white-space characters are not considered printable.
Do we want to stay close to the original, or not?
Regards
Jan
--
To unsubscribe from this list: send the line
Am 09.10.2012 21:30, schrieb Junio C Hamano:
Jan H. Schönherr schn...@cs.tu-berlin.de writes:
...
static int is_rfc2047_special(char ch)
{
+/*
+ * We encode ' ' using '=20' even though rfc2047
+ * allows using '_' for readability. Unfortunately,
+ * many programs do
Am 09.10.2012 21:07, schrieb Junio C Hamano:
Jan H. Schönherr schn...@cs.tu-berlin.de writes:
During the creation of this series, I came across the strbuf
wrapping functions, and I wonder if there is an off-by-one issue.
Consider the following excerpt from t4202:
...
Yeah, that does
From: Jan H. Schönherr schn...@cs.tu-berlin.de
According to RFC 2047 and RFC 822, rfc2047 encoded words and and rfc822
quoted strings do not mix.
Be more strict about rfc2047 encoded words in addresses, so that it is a
bit more conform to RFC 2047.
(Especially, my own name gets correctly
From: Jan H. Schönherr schn...@cs.tu-berlin.de
Do some checks for RFC 822 and RFC 2047 support in To:
and Cc: headers and fix ambiguous old checks.
Signed-off-by: Jan H. Schönherr schn...@cs.tu-berlin.de
---
t/t4014-format-patch.sh | 98 +
1 Datei
.
(In that case, I would repost an updated version of this series.)
Regards
Jan
Jan H. Schönherr (5):
format-patch: do not wrap non-rfc2047 headers too early
format-patch: do not wrap rfc2047 encoded headers too late
format-patch: introduce helper function last_line_length()
format-patch: fix
From: Jan H. Schönherr schn...@cs.tu-berlin.de
Do not wrap the second and later lines of an ASCII header substantially
before the 78 character limit.
Signed-off-by: Jan H. Schönherr schn...@cs.tu-berlin.de
---
pretty.c| 2 +-
t/t4014-format-patch.sh | 60
From: Jan H. Schönherr schn...@cs.tu-berlin.de
Currently, an open-coded loop to calculate the length of the last
line of a string buffer is used in multiple places.
Move that code into a function of its own.
Signed-off-by: Jan H. Schönherr schn...@cs.tu-berlin.de
---
pretty.c | 25
1 - 100 of 121 matches
Mail list logo
