Ilya Tumaykin gmail.com> writes:
> $ git --no-pager log -1 --format='format:%+s%+b'
> Please fix.
Simply use `git --no-pager log -1 --format='format:%+s%n%+b'`
The message body excludes the empty line preceding it.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bo
Another possibility is to set authordate and committerdate to some
specified time by the way of appropriate environment variables.
To follow up, Jakub's approach works great without
requiring any changes to Git.
For example, the following test script always
produces the same commit ID:
W dniu 2016-07-25 o 00:36, Ramsay Jones pisze:
> On 24/07/16 18:16, Lars Schneider wrote:
>> On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
>>> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
[...]
This patch adds the filter..useProtocol option which, if enabled,
keeps the external fil
On 24/07/16 18:16, Lars Schneider wrote:
>
> On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
>
>> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
>>> From: Lars Schneider
>>>
>>> Git's clean/smudge mechanism invokes an external filter process for every
>>> single blob that is affected by a f
W dniu 2016-07-24 o 22:14, Jakub Narębski pisze:
> W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
>> I agree that the name is not ideal. "UseProtocol" as it is would be a
>> boolean.
>> I thought about "persistent" but this name wouldn't convey the scope of the
>> persistency ("persistent for
W dniu 2016-07-24 o 21:20, Jon Forrest pisze:
> On 7/24/2016 11:46 AM, Jakub Narębski wrote:
>>
>> Another possibility is to set authordate and committerdate to some
>> specified time by the way of appropriate environment variables.
>
> That sounds like a great idea. Assuming it
> works the way I
W dniu 2016-07-24 o 20:36, Lars Schneider pisze:
> On 23 Jul 2016, at 02:11, Jakub Narębski wrote:
>> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze:
>>> From: Lars Schneider
>>
>> Nb. this line is only needed if you want author name and/or date
>> different from the email sender, or i
Also, I realized one potentially major disadvantage of sharing in
Google Drive. This is that the URL will change each time I update
the book. Apparently Google is taking away the ability to create
a static link at the end of August 2016.
I think you can share a folder instead, and this would be
On 7/24/2016 11:51 AM, Rodrigo Campos wrote:
And what is the problem with that, if you are doing it with instructional
purposes? Let's assume that this helps and not confuses later when the commits
*do* change. What is the problem you face?
A lot of instructional material contains stuff like
On 7/24/2016 11:46 AM, Jakub Narębski wrote:
Please try to keep to the 80-character lines.
Sorry.
Another possibility is to set authordate and committerdate to some
specified time by the way of appropriate environment variables.
That sounds like a great idea. Assuming it
works the way I e
On 23 Jul 2016, at 10:14, Eric Wong wrote:
> larsxschnei...@gmail.com wrote:
>> Please note that the protocol filters do not support stream processing
>> with this implemenatation because the filter needs to know the length of
>> the result in advance. A protocol version 2 could address this in
On Sun, Jul 24, 2016 at 11:12:12AM -0700, Jon Forrest wrote:
>
> Those of us who write instructional material about Git all face the same
> problem.
> This is that we can't write step by step instructions that show the results of
> making a commit because users will always see different commit ID
Please try to keep to the 80-character lines.
W dniu 2016-07-24 o 20:12, Jon Forrest pisze:
> Those of us who write instructional material about Git all face the
> same problem. This is that we can't write step by step instructions
> that show the results of making a commit because users will alw
On 7/24/2016 11:27 AM, Jakub Narębski wrote:
In my opinion being able to view it online has its advantages.
Even casual reader can check it, and point errors or offer suggestions
for improvements.
Absolutely. Now that I've finished the editing I'll look
into that.
I think you can share a f
On 23 Jul 2016, at 02:11, Jakub Narębski wrote:
> W dniu 2016-07-22 o 17:49, larsxschnei...@gmail.com pisze:
>> From: Lars Schneider
>
> Nb. this line is only needed if you want author name and/or date
> different from the email sender, or if you have sender line misconfigured
> (e.g. lacking
W dniu 2016-07-24 o 19:34, Jon Forrest pisze:
> On 7/24/2016 10:19 AM, Jakub Narębski wrote:
>
>> As far as I can see you cannot view it online (without downloading).
>
> True. I changed the way the HTML file is generated so that it
> contains all the images downloading it is as good as viewing
>
Those of us who write instructional material about Git all face the same
problem.
This is that we can't write step by step instructions that show the results of
making a commit because users will always see different commit IDs.
This is fundamental to the design of Git.
Even if the instructiona
On 7/24/2016 10:19 AM, Jakub Narębski wrote:
As far as I can see you cannot view it online (without downloading).
True. I changed the way the HTML file is generated so that it
contains all the images downloading it is as good as viewing
it online. I'm not current with the thinking about the m
Re-added git mailing list
On 24 July 2016 at 17:57, Jon Forrest wrote:
> On 7/24/2016 2:00 AM, Jakub Narębski wrote:
>
>> I have not checked the book itself; it would be nice if it were
>> hosted somewhere, even if using GitHub Pages (per-project or
>> per-user).
>
> Do you mean in some format ot
On 23 Jul 2016, at 01:19, Ramsay Jones wrote:
> On 22/07/16 16:49, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> Git's clean/smudge mechanism invokes an external filter process for every
>> single blob that is affected by a filter. If Git filters a lot of blobs
>> then the star
Junio C Hamano writes:
> Eric Wong writes:
>
>> Users have mistakenly copied "From " lines into commit messages
>> in the past, and will certainly make the same mistakes in the
>> future. Since not everyone uses mboxrd, yet, we should at least
>> prevent miss-split mails by always escaping "Fro
On Sun, Jul 24, 2016 at 09:37:57AM +0200, Johannes Schindelin wrote:
> On Sun, 24 Jul 2016, Eric Wong wrote:
>
> > @@ -1745,9 +1746,18 @@ void pp_remainder(struct pretty_print_context *pp,
> > strbuf_add_tabexpand(sb, pp->expand_tabs_in_log,
> >
On Sat, Jul 23, 2016 at 10:52:09AM +0200, Johannes Schindelin wrote:
> On Fri, 22 Jul 2016, Jeff King wrote:
>
> > Here are a few quick fixes and features for git-jump. The first is a bug
> > I noticed and fixed recently. And that reminded me of the second one,
> > which I'd been carrying in my l
Greetings,
I know you will be surprised to read my email. Apart from being surprise you
may be skeptical to reply me because based on what is happening on the internet
world, one has to be very careful because a lot of scammers are out there to
scam innocent citizens and this has made it ver
Hello.
Steps to reproduce:
$ git init
$ >123
$ git add 123
$ git commit -v -m 'This is subject' -m 'And this is body'
$ git --no-pager log -1 --format='format:%+s%+b'
Actual results:
```
This is subject
And this is body
```
Expected results:
```
This is subject
And this is body
```
$ git --v
On 23 Jul 2016, at 00:32, Torsten Bögershausen wrote:
> On 07/22/2016 05:49 PM, larsxschnei...@gmail.com wrote:
>> From: Lars Schneider
>>
>> [...]
>>
>> 1. Git starts the filter on first usage and expects a welcome message
>> with protocol version number:
>> Git <-- Filter: "git-filter-
Het is me Ruth, krijg je mijn e-mail? schrijf me onmiddellijk terug om me te
laten weten, kussen.
Ruth.
Wachten.
It's me Ruth, are you getting my email? please write me back immediately to let
me know, kisses.
Ruth.
Waiting.
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
On 22 Jul 2016, at 23:39, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
>> The first two patches are cleanup patches which are not really necessary
>> for the feature.
>
> These two looked trivially good.
Thanks!
> I think I can agree with what 3/3 wants to do in principle, but
Jakub Narębski wrote:
> W dniu 2016-07-11 o 22:51, Eric Wong pisze:
>
> > TL;DR: dumb HTTP clone from a certain badly-packed repo goes from
> > ~2 hours to ~30 min memory usage drops from 2G to 360M
> >
> >
> > I hadn't packed the public repo at https://public-inbox.org/git
> > for a few weeks.
Junio C Hamano wrote:
> As a tool to produce mbox file, quoting like this in format-patch
> output may make sense, I would think, but shouldn't send-email undo
> this when sending individual patches?
Yes, that sounds like a good idea. Thanks.
Will followup in a day or two.
--
To unsubscribe from
W dniu 2016-07-11 o 22:51, Eric Wong pisze:
> TL;DR: dumb HTTP clone from a certain badly-packed repo goes from
> ~2 hours to ~30 min memory usage drops from 2G to 360M
>
>
> I hadn't packed the public repo at https://public-inbox.org/git
> for a few weeks. As an admin of a small server limited
W dniu 2016-07-24 o 06:07, Jon Forrest pisze:
> This an announcement of Pro Git Reedited 2nd Edition, which is
> a substantial edit of Chacon and Straub's Pro Git 2nd Edition.
> I spent a lot of time tightening it up and maybe clearing
> up some explanations.
[...]
> The sources for this book are
Johannes Schindelin writes:
> Hi Andreas,
>
> On Sun, 24 Jul 2016, Andreas Schwab wrote:
>
>> Eric Wong writes:
>>
>> > diff --git a/mailinfo.c b/mailinfo.c
>> > index 9f19ca1..0ebd953 100644
>> > --- a/mailinfo.c
>> > +++ b/mailinfo.c
>> > @@ -1035,3 +1035,34 @@ void clear_mailinfo(struct mail
Hi Andreas,
On Sun, 24 Jul 2016, Andreas Schwab wrote:
> Eric Wong writes:
>
> > diff --git a/mailinfo.c b/mailinfo.c
> > index 9f19ca1..0ebd953 100644
> > --- a/mailinfo.c
> > +++ b/mailinfo.c
> > @@ -1035,3 +1035,34 @@ void clear_mailinfo(struct mailinfo *mi)
> >
> > strbuf_release(&mi-
Hi Eric,
On Sun, 24 Jul 2016, Eric Wong wrote:
> @@ -1745,9 +1746,18 @@ void pp_remainder(struct pretty_print_context *pp,
> strbuf_add_tabexpand(sb, pp->expand_tabs_in_log,
>line, linelen);
> else {
> -
Eric Wong writes:
> diff --git a/mailinfo.c b/mailinfo.c
> index 9f19ca1..0ebd953 100644
> --- a/mailinfo.c
> +++ b/mailinfo.c
> @@ -1035,3 +1035,34 @@ void clear_mailinfo(struct mailinfo *mi)
>
> strbuf_release(&mi->log_message);
> }
> +
> +int is_from_line(const char *line, int len)
>
Eric Wong writes:
> Users have mistakenly copied "From " lines into commit messages
> in the past, and will certainly make the same mistakes in the
> future. Since not everyone uses mboxrd, yet, we should at least
> prevent miss-split mails by always escaping "From " lines based
> on the check u
37 matches
Mail list logo
