Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

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:

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

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

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

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

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

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

Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

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

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

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

Re: [ANN] Pro Git Reedited 2nd Edition

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

Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

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

Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

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

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

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

Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

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

Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

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

Re: [ANN] Pro Git Reedited 2nd Edition

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

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

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

Re: [ANN] Pro Git Reedited 2nd Edition

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

[RFC] A Change to Commit IDs Too Ridiculous to Consider?

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

Re: [ANN] Pro Git Reedited 2nd Edition

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

Re: [ANN] Pro Git Reedited 2nd Edition

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

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

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

Re: [PATCH] format-patch: escape "From " lines recognized by mailsplit

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

Re: [PATCH 2/2] format-patch: escape "From " lines recognized by mailsplit

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, > >

Re: [PATCH 0/3] minor git-jump improvements

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

Message From US ARMY Medical Team

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

Bug: "git log --format='format:%+s%+b'" doesn't insert newline before body

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

Re: [PATCH v1 3/3] convert: add filter..useProtocol option

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

Is me Ruth

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

Re: [PATCH v1 0/3] Git filter protocol

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

Re: [RFC 0/3] dumb HTTP transport speedups

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 >

Re: [PATCH] format-patch: escape "From " lines recognized by mailsplit

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. --

Re: [RFC 0/3] dumb HTTP transport speedups

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

Re: [ANN] Pro Git Reedited 2nd Edition

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

Re: [PATCH 1/2] mailinfo: extract is_from_line from mailsplit

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 >> > @@

Re: [PATCH 1/2] mailinfo: extract is_from_line from mailsplit

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) > > > >

Re: [PATCH 2/2] format-patch: escape "From " lines recognized by mailsplit

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 { > -

Re: [PATCH 1/2] mailinfo: extract is_from_line from mailsplit

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(>log_message); > } > + > +int is_from_line(const char

Re: [PATCH] format-patch: escape "From " lines recognized by mailsplit

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