Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote: [snip] > > These definitely seem like a family of related problems. I'd like to > use git-series as a format for storing iterations on things like GitHub > pull-requests or Gerrit patch versions (in the latter case, overcoming >

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote: [snip] > > I'd welcome any feedback, whether on the interface and workflow, the > internals and collaboration, ideas on presenting diffs of patch series, > or anything else. > This looks awesome! I've been working on some similar

Re: [PATCH v2 5/5] convert: add filter..process option

W dniu 2016-07-29 o 12:38, Lars Schneider pisze: > On 27 Jul 2016, at 11:41, Eric Wong wrote: >> larsxschnei...@gmail.com wrote: >>> +static off_t multi_packet_read(struct strbuf *sb, const int fd, const >>> size_t size) >> >> I'm no expert in C, but this might be

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Fri, Jul 29, 2016 at 11:10:11AM +0100, Richard Ipsum wrote: > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote: > [snip] > > > > I'd welcome any feedback, whether on the interface and workflow, the > > internals and collaboration, ideas on presenting diffs of patch series, > > or

Re: [PATCH v2 5/5] convert: add filter..process option

> On 29 Jul 2016, at 13:24, Jakub Narębski wrote: > > W dniu 2016-07-29 o 12:38, Lars Schneider pisze: >> On 27 Jul 2016, at 11:41, Eric Wong wrote: >>> larsxschnei...@gmail.com wrote: > +static off_t multi_packet_read(struct strbuf *sb, const int fd,

Re: [PATCH v2 5/5] convert: add filter..process option

> On 27 Jul 2016, at 11:41, Eric Wong wrote: > > larsxschnei...@gmail.com wrote: >> +static off_t multi_packet_read(struct strbuf *sb, const int fd, const >> size_t size) > > I'm no expert in C, but this might be const-correctness taken > too far. I think basing this on the

[PATCH] Fix failing test t3700-add.sh

At the time of the test xfoo1 already exists and is a link. As a result, the check for file mode 100644 fails. Create not yet existing file xfoo instead. Signed-off-by: Ingo Brückl --- t/t3700-add.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff

[ANNOUNCE] git-series: track changes to a patch series over time

I'd like to announce a project I've been working on for a while: git-series provides a tool for managing patch series with git, tracking the "history of history". git series tracks changes to the patch series over time, including rebases and other non-fast-forwarding changes. git series also

Re: [PATCH v2 0/5] Git filter protocol

> On 29 Jul 2016, at 09:40, Jakub Narębski wrote: > > W dniu 2016-07-28 o 15:29, Jeff King pisze: >> On Thu, Jul 28, 2016 at 09:16:18AM +0200, Lars Schneider wrote: >> >>> But Peff ($gmane/299902), Duy, and Eric, seemed to prefer the pkt-line >>> solution (gmane is down -

⊙¤Hi

hi this is an electronics shop bike,brand guitar,camera,tv,samsung product free shipping www .slooone .com if you do not want to receive our email,please reply to us, we will never send email to you

Re: Small trivial annoyance with the nice new builtin "git am"

On Fri, Jul 29, 2016 at 2:32 AM, Linus Torvalds wrote: > On Thu, Jul 28, 2016 at 5:21 PM, Jeff King wrote: >> >> I do wonder if you would be happier giving each commit a "fake" >> monotonically increasing time, so they are correctly ordered by commit

Re: [PATCH] pack-objects: Use reachability bitmap index when generating non-stdout pack too

On Thu, Jul 28, 2016 at 02:18:29PM -0700, Junio C Hamano wrote: > Kirill Smelkov writes: > > > I'm waiting so long for main patch to be at least queued to pu, that I'm > > now a bit frustrated and ready to do something not related to main goal :) > > Perhaps the first step

Re: [PATCH v2 0/5] Git filter protocol

W dniu 2016-07-28 o 15:29, Jeff King pisze: > On Thu, Jul 28, 2016 at 09:16:18AM +0200, Lars Schneider wrote: > >> But Peff ($gmane/299902), Duy, and Eric, seemed to prefer the pkt-line >> solution (gmane is down - otherwise I would have given you the links). > > FWIW, I think there are

Re: [PATCH 0/3] diff-highlight: add support for git log --graph output.

W dniu 2016-07-28 o 18:27, Brian Henderson pisze: > Hi, I've been working with Jeff King on this patch, but he encouraged me to > email the list. > > I recently learned about the diff-highlight tool and find it very helpful, > however, I frequently use the --graph option to git log which breaks

[PATCH v4 2/2] pack-objects: Teach it to use reachability bitmap index when generating non-stdout pack too

Starting from 6b8fda2d (pack-objects: use bitmaps when packing objects) if a repository has bitmap index, pack-objects can nicely speedup "Counting objects" graph traversal phase. That however was done only for case when resultant pack is sent to stdout, not written into a file. The reason here

[PATCH 1/2] pack-objects: Teach --use-bitmap-index codepath to respect --local, --honor-pack-keep and --incremental

Since 6b8fda2d (pack-objects: use bitmaps when packing objects) there are two codepaths in pack-objects: with & without using bitmap reachability index. However add_object_entry_from_bitmap(), despite its non-bitmapped counterpart add_object_entry(), in no way does check for whether --local or

Re: [PATCH v2 5/5] convert: add filter..process option

> On 28 Jul 2016, at 01:31, Jakub Narębski wrote: > > W dniu 2016-07-27 o 02:06, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> Git's clean/smudge mechanism invokes an external filter process for every >> single blob that is affected

git bisect for reachable commits only

Hi all, I just found an interesting post how git bisect can trouble humans. Full story is here https://groups.google.com/forum/#!topic/git-users/v3__t42qbKE My suggestion to fix it (ditto) What I suggest change logic of bisecting to something like git config bisect.reachable true

Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Hello, I have a question which may be a bug (I'm a bit skeptical), but here goes: In my global .gitconfig, I have "user.useConfigOnly = true" and user.email isn't set there (I prefer to be forced to set it on a per-repo basis, as I use different emails for work and personal repos). I ALSO have

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Fri, Jul 29, 2016 at 01:44:44PM +0100, Richard Ipsum wrote: > On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote: > > I hope to use git notes with git-series in the future, by putting > > another gitlink under the git-series for notes related to the series. > > I'd intended that for

Re: [PATCH v8 32/41] environment: add set_index_file()

On Wed, Jul 27, 2016 at 5:14 PM, Duy Nguyen wrote: > On Tue, Jul 26, 2016 at 9:28 PM, Junio C Hamano wrote: >> Christian Couder writes: >> >>> Introduce set_index_file() to be able to temporarily change the index file. >>> >>> It

Re: [[PATCH v2] 2/4] patch-ids: replace the seen indicator with a commit pointer

Kevin Willford writes: > From: Kevin Willford > > The cherry_pick_list was looping through the original side checking the > seen indicator and setting the cherry_flag on the commit. If we save > off the commit in the patch_id we can set the

Re: [[PATCH v2] 0/4] Use header data patch ids for rebase to avoid loading file content

Kevin Willford writes: > This patch series is to remove the hand rolled hashmap in the patch_ids > and use the hashmap.h implementation. It also introduces the idea of having > a header only patch id so that the contents of the files do not have to be > loaded in order to

Re: [[PATCH v2] 1/4] patch-ids: stop using a hand-rolled hashmap implementation

Kevin Willford writes: > From: Kevin Willford > > This change will use the hashmap from the hashmap.h to keep track of the > patch_ids that have been encountered instead of using an internal > implementation. This simplifies the implementation of

Re: [PATCH v8 32/41] environment: add set_index_file()

On Fri, Jul 29, 2016 at 4:21 PM, Christian Couder wrote: >> I agree we should avoid this. There's a bunch of cache_name_pos() (and >> even read_cache()) in the libified apply.c, those will need to be >> converted to take struct index_state* directly (read_index_from

[PATCH 0/3] diff-highlight: add support for git log --graph output.

(resending as thread instead of attachments) Hi, I've been working with Jeff King on this patch, but he encouraged me to email the list. I recently learned about the diff-highlight tool, and find it very helpful, however, I frequently use the --graph option to git log which breaks the tool. This

Re: [PATCH/RFC 0/7] Add possibility to clone specific subdirectories

On Thu, Jul 28, 2016 at 10:33 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >>> 4. Fsck complains about missing blobs. Should be fairly easy to fix. >> >> Not really. You'll have to associate path information with blobs >> before you decide that a blob

[PATCH] gitweb: escape link body in format_ref_marker

Fix a case where an html link can be generated from unescaped input resulting in invalid strict xhtml or potentially injected code. An overview of a repo with a tag "1.0.0&0.0.1" would previously result in an unescaped amperstand in the link body. Signed-off-by: Andreas Brauchli

Re: [PATCH v2 7/7] pack-objects: use mru list when iterating over packs

Jeff King writes: > On Fri, Jul 29, 2016 at 12:15:24AM -0400, Jeff King wrote: > > But because this series switches the order of pack-lookup between > objects, it is possible for us to find a `B` which is a delta against > `A` in one pack, and then another copy of `A` which is a

Re: [PATCH v2 0/5] Git filter protocol

On Fri, Jul 29, 2016 at 10:14:17AM +0200, Lars Schneider wrote: > My current implementation supports only two cases. Either the filter > knows the size and sends it back. Or the filter doesn't know the size > and Git reads until the flush packet (your "unknown" case). "Approx" is > probably hard

Re: Small trivial annoyance with the nice new builtin "git am"

On Thu, Jul 28, 2016 at 05:37:08PM -0700, Linus Torvalds wrote: > > and then to sprinkle calls liberally through builtin-ified programs when > > they move from one unit of work to the next. > > Maybe we can just add it to the end of commit_tree_extended(), and > just say "the cache is reset

[PATCH v2 3/3] Simplify test t3700-add.sh

Utilize the test_mode_in_index helper function. Signed-off-by: Ingo Brückl --- t/t3700-add.sh | 30 ++ 1 file changed, 6 insertions(+), 24 deletions(-) diff --git a/t/t3700-add.sh b/t/t3700-add.sh index c08ec9e..0e21a52 100755 ---

Re: [[PATCH v2] 1/4] patch-ids: stop using a hand-rolled hashmap implementation

Kevin Willford writes: > +static int patch_id_cmp(struct patch_id *a, > + struct patch_id *b, > + void *keydata) > { > + return hashcmp(a->patch_id, b->patch_id); > } > > int init_patch_ids(struct patch_ids *ids) > { >

Re: [PATCH v2 1/3] Enhance test t3700-add.sh

Ingo Brückl writes: > Subject: Re: [PATCH v2 1/3] Enhance test t3700-add.sh > > The files to be tested may already exist and be links which will make > the test fail. So ensure that we are working in a clean environment. "Enhance", like "Update" or "Change", is a

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

On Fri, Jul 29, 2016 at 11:37:59AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > ... So I do think there may be a bug to be fixed, > > but it is simply commands being over-eager to make sure we have an > > ident when they might not need it. > > 36267854 (pull:

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Jeff King writes: > TBH, I'm not sure anybody cares that much between the three. Even before > user.useConfigOnly, this could be an issue on machines where the ident > could not be auto-configured, and it seems like nobody ran across it. > It's only the funny interaction with

Does anything document --date=tea/yesterday/noon/midnight/never/now etc.?

These were originally added by Linus back in v0.99.9-230-ga8aca41, a bit was added to them since then. See https://github.com/git/git/blob/v2.9.2/date.c#L927 The v0.99.9-214-g3c07b1d commit also has some info on the warty edge cases these have to deal with. I was checking what documented "git

Re: [PATCH v2 5/5] convert: add filter..process option

W dniu 2016-07-29 o 19:35, Junio C Hamano pisze: > Lars Schneider writes: > >> I think sending it upfront is nice for buffer allocations of big files >> and it doesn't cost us anything to do it. > > While I do NOT think "total size upfront" MUST BE avoided at all

Re: [PATCH v2 5/5] convert: add filter..process option

> On 30 Jul 2016, at 01:11, Jakub Narębski wrote: > > W dniu 2016-07-29 o 19:35, Junio C Hamano pisze: >> Lars Schneider writes: >> >>> I think sending it upfront is nice for buffer allocations of big files >>> and it doesn't cost us anything to do

What's cooking in git.git (Jul 2016, #09; Fri, 29)

What's cooking in git.git (Jul 2016, #09; Fri, 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'. The ones marked with '.' do not appear

Re: [PATCH] reset cached ident date before creating objects

Hi Jeff, On Sat, Jul 30, 2016 at 2:05 AM, Jeff King wrote: > When we compute the date to put in author/committer lines of > commits, or tagger lines of tags, we get the current date > once and then cache it for the rest of the program. This is > a good thing in some cases, like

[PATCH v2 1/3] Enhance test t3700-add.sh

The files to be tested may already exist and be links which will make the test fail. So ensure that we are working in a clean environment. Signed-off-by: Ingo Brückl --- t/t3700-add.sh | 3 +++ 1 file changed, 3 insertions(+) diff --git a/t/t3700-add.sh b/t/t3700-add.sh

[PATCH v2 2/3] Make test t3700-add.sh more robust

Don't rely on chmod to work on the underlying platform (although it wouldn't harm the result of the '--chmod=-x' test). Directly check the result of the --chmod option. Add a test_mode_in_index helper function in order to check for success. Signed-off-by: Ingo Brückl ---

[PATCH v3 03/10] pkt-line: add packet_flush_gentle()

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_gentle() which writes a pkt-line flush packet and returns `0` for success and `1` for failure. Signed-off-by: Lars

[PATCH v3 08/10] convert: modernize tests

From: Lars Schneider Use `test_config` to set the config, check that files are empty with `test_must_be_empty`, compare files with `test_cmp`, and remove spaces after ">" and "<". Signed-off-by: Lars Schneider --- t/t0021-conversion.sh | 62

[PATCH v3 02/10] pkt-line: add direct_packet_write() and direct_packet_write_data()

From: Lars Schneider Sometimes pkt-line data is already available in a buffer and it would be a waste of resources to write the packet using packet_write() which would copy the existing buffer into a strbuf before writing it. If the caller has control over the buffer

[PATCH v3 04/10] pkt-line: call packet_trace() only if a packet is actually send

From: Lars Schneider The packet_trace() call is not ideal in format_packet() as we would print a trace when a packet is formatted and (potentially) when the packet is actually send. This was no problem up until now because format_packet() was only used by one function.

[PATCH v3 09/10] convert: generate large test files only once

From: Lars Schneider Generate more interesting large test files with pseudo random characters in between and reuse these test files in multiple tests. Run tests formerly marked as EXPENSIVE every time but with a smaller data set. Signed-off-by: Lars Schneider

[PATCH v3 10/10] convert: add filter..process option

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 startup time of the external filter processes can become a significant part of the overall Git

[PATCH v3 07/10] convert: quote filter names in error messages

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 ++-- 1 file changed, 6

[PATCH v3 01/10] pkt-line: extract set_packet_header()

From: Lars Schneider set_packet_header() converts an integer to a 4 byte hex string. Make this function locally available so that other pkt-line functions can use it. Signed-off-by: Lars Schneider --- pkt-line.c | 15 ++- 1 file

[PATCH v3 06/10] run-command: add clean_on_exit_handler

From: Lars Schneider Some commands might need to perform cleanup tasks on exit. Let's give them an interface for doing this. Signed-off-by: Lars Schneider --- run-command.c | 12 run-command.h | 1 + 2 files changed, 9

[PATCH v3 05/10] pack-protocol: fix maximum pkt-line size

From: Lars Schneider According to LARGE_PACKET_MAX in pkt-line.h the maximal lenght of a pkt-line packet is 65520 bytes. The pkt-line header takes 4 bytes and therefore the pkt-line data component must not exceed 65516 bytes. Signed-off-by: Lars Schneider

Re: [[PATCH v2] 4/4] rebase: avoid computing unnecessary patch IDs

Kevin Willford writes: > static int patch_id_cmp(struct patch_id *a, > struct patch_id *b, > - void *keydata) > + struct diff_options *opt) > { > + if (is_null_sha1(a->patch_id) && > +

Re: [PATCH v2 2/3] Make test t3700-add.sh more robust

Ingo Brückl writes: > Subject: Re: [PATCH v2 2/3] Make test t3700-add.sh more robust Please check output from "git shortlog --no-merges -100" to see how your titles play well with others. We typically prefix the title with a specific area, a colon, and a sentence that

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Thu, Jul 28, 2016 at 07:08:02PM -0700, Josh Triplett wrote: > > I think on the whole that defaulting to "--from" would help more people > > than hurt them, but if we do believe there are scripts that would be > > regressed, it probably needs a deprecation period. > > I don't think it's likely

[PATCH v3 00/10] Git filter protocol

From: Lars Schneider Hi, thanks a lot to Jakub, Peff, Torsten, Eric, and Junio for comments and reviews. Here is what has changed since v2: * replace `/dev/urandom` with `test-genrandom` (Torsten, Peff) * improve commit message "Git filter driver command with spaces"

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

On Fri, Jul 29, 2016 at 03:45:35PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > TBH, I'm not sure anybody cares that much between the three. Even before > > user.useConfigOnly, this could be an issue on machines where the ident > > could not be auto-configured, and it

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Sat, Jul 30, 2016 at 01:47:42AM -0400, Jeff King wrote: > On Fri, Jul 29, 2016 at 09:50:55PM -0700, Josh Triplett wrote: > > > I would propose the following then: > > > > - I'll write a patch adding a config option format.from, along with > > documentation, without changing the default. > >

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Fri, Jul 29, 2016 at 09:50:55PM -0700, Josh Triplett wrote: > I would propose the following then: > > - I'll write a patch adding a config option format.from, along with > documentation, without changing the default. > - The release notes for the version of git introducing that config >

Re: [PATCH] reset cached ident date before creating objects

On Sat, Jul 30, 2016 at 10:11:56AM +0800, Paul Tan wrote: > > diff --git a/commit.c b/commit.c > > index 71a360d..7ddbffe 100644 > > --- a/commit.c > > +++ b/commit.c > > @@ -1548,6 +1548,7 @@ int commit_tree_extended(const char *msg, size_t > > msg_len, > > } > > > > /*

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Fri, Jul 29, 2016 at 06:58:00PM -0400, Jeff King wrote: > On Thu, Jul 28, 2016 at 07:08:02PM -0700, Josh Triplett wrote: > > > > I think on the whole that defaulting to "--from" would help more people > > > than hurt them, but if we do believe there are scripts that would be > > > regressed,

[[PATCH v2] 0/4] Use header data patch ids for rebase to avoid loading file content

This patch series is to remove the hand rolled hashmap in the patch_ids and use the hashmap.h implementation. It also introduces the idea of having a header only patch id so that the contents of the files do not have to be loaded in order to determine if two commits are different. Kevin

[[PATCH v2] 3/4] patch-ids: add flag to create the diff patch id using header only data

From: Kevin Willford This will allow a diff patch id to be created using only the header data so that the contents of the file will not have to be loaded. Signed-off-by: Kevin Willford --- diff.c | 16 ++-- diff.h | 2 +-

[[PATCH v2] 2/4] patch-ids: replace the seen indicator with a commit pointer

From: Kevin Willford The cherry_pick_list was looping through the original side checking the seen indicator and setting the cherry_flag on the commit. If we save off the commit in the patch_id we can set the cherry_flag on the correct commit when running through the other

Re: [PATCH] Fix failing test t3700-add.sh

Am 29.07.2016 um 14:31 schrieb Ingo Brückl: At the time of the test xfoo1 already exists and is a link. As a result, the check for file mode 100644 fails. Create not yet existing file xfoo instead. Signed-off-by: Ingo Brückl --- t/t3700-add.sh | 12 ++-- 1 file

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

Josh Triplett writes: > So, it seems exceedingly unlikely to me that this would result in > unnecessary in-body "From:" headers. Yup, Peff elsewhere on the thread gave the same conclusion, and after reading the codepaths involved again, I agree. -- To unsubscribe from

Re: [PATCH] Fix failing test t3700-add.sh

[+cc Ed, who wrote 4e55ed3 (add: add --chmod=+x / --chmod=-x options, 2016-05-31)] On Fri, Jul 29, 2016 at 02:31:28PM +0200, Ingo Brückl wrote: > At the time of the test xfoo1 already exists and is a link. > As a result, the check for file mode 100644 fails. > > Create not yet existing file

Re: Small trivial annoyance with the nice new builtin "git am"

Jeff King writes: > On Thu, Jul 28, 2016 at 04:47:17PM -0700, Junio C Hamano wrote: > >> Also makes me wonder if "git cherry-pick A..B" shares the same >> breakage. > > Probably. It seems that "cherry-pick A..B" leads to sequencer.c::run_git_commit() that uses run_command_v_opt()

[[PATCH v2] 1/4] patch-ids: stop using a hand-rolled hashmap implementation

From: Kevin Willford This change will use the hashmap from the hashmap.h to keep track of the patch_ids that have been encountered instead of using an internal implementation. This simplifies the implementation of the patch ids. Signed-off-by: Kevin Willford

Re: [PATCH v2 0/5] Git filter protocol

> On 29 Jul 2016, at 17:57, Jeff King wrote: > > On Fri, Jul 29, 2016 at 10:14:17AM +0200, Lars Schneider wrote: > >> My current implementation supports only two cases. Either the filter >> knows the size and sends it back. Or the filter doesn't know the size >> and Git reads

[[PATCH v2] 4/4] rebase: avoid computing unnecessary patch IDs

From: Kevin Willford The `rebase` family of Git commands avoid applying patches that were already integrated upstream. They do that by using the revision walking option that computes the patch IDs of the two sides of the rebase (local-only patches vs upstream-only ones)

Re: [PATCH v2 0/5] Git filter protocol

On Fri, Jul 29, 2016 at 06:20:51PM +0200, Lars Schneider wrote: > >> That being said a "fail" response is a very good idea! This allows > >> the filter to communicate to git that a non required filter process > >> failed. I will add that to the protocol. Thanks :) > > > > Maybe just send "ok ",

Re: git bisect for reachable commits only

Oleg Taranenko writes: > What I suggest change logic of bisecting to something like > > git config bisect.reachable true Such a configuration should not be needed. When a history with this shape is given to "git bisect": o---o---X---Y---B \

[PATCH] reset cached ident date before creating objects

On Fri, Jul 29, 2016 at 10:15:26AM -0700, Junio C Hamano wrote: > > One obvious impact would be reflog entries, since we would reset the > > time between the object creation and the ref write (so your reflog entry > > would sometimes be a second or more after the commit time it writes). > > I'm

Re: Small trivial annoyance with the nice new builtin "git am"

On Thu, Jul 28, 2016 at 5:37 PM, Linus Torvalds wrote: > On Thu, Jul 28, 2016 at 5:29 PM, Jeff King wrote: >> >> I guess we want something like: >> >> +void reset_ident_date(void) >> +{ >> + strbuf_reset(_default_date); >> +} > > Looks sane. >

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

On Fri, Jul 29, 2016 at 10:47:27AM -0700, Junio C Hamano wrote: > > In those cases specifically, I never have local commits that differ > > from the remote, so a "pull --ff-only" should leave me in the same > > state as a "pull --rebase". > > > > Is this a case of rebase trying to make sure it

Re: [PATCH] reset cached ident date before creating objects

On Fri, Jul 29, 2016 at 11:05 AM, Jeff King wrote: > > Linus suggested resetting the timestamp after making the commit, to > clear the way for the next commit. But if we reset any cached value > _before_ making the commit, this has a few advantages: Looks fine to me. It should

Re: [PATCH] reset cached ident date before creating objects

Jeff King writes: > Linus suggested resetting the timestamp after making the commit, to > clear the way for the next commit. But if we reset any cached value > _before_ making the commit, this has a few advantages: I guess our mails crossed ;-). > It does feel a little backwards

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Junio C Hamano writes: > Dakota Hawkins writes: > >> In those cases specifically, I never have local commits that differ >> from the remote, so a "pull --ff-only" should leave me in the same >> state as a "pull --rebase". >> >> Is this a case of

Re: [PATCH v8 32/41] environment: add set_index_file()

On Fri, Jul 29, 2016 at 5:34 PM, Duy Nguyen wrote: > > Yeah. If the libification movement is going strong, we can start > converting and at some point should be able to define > NO_THE_INDEX_COMPATIBILITY_MACROS globally (and avoid the_index along > the way) > > Without that,

Re: [PATCH] reset cached ident date before creating objects

On Fri, Jul 29, 2016 at 11:15:39AM -0700, Junio C Hamano wrote: > > It does feel a little backwards to cache by default, and then try to > > catch all the places that want to reset. Another way of thinking about > > it would be to almost _never_ cache, but let a few callsites like (the > > commit

Re: [PATCH v2 0/5] Git filter protocol

On Fri, Jul 29, 2016 at 07:43:49PM +0200, Lars Schneider wrote: > Here is the reject case (non-streaming): > > git> smudge > git> > git> > git> ...pkt-lines... > git> pktline-flush > > git< 0 > git< reject > > > Do you see a problem with this approach? Only that it seemed a little weird to

Re: Small trivial annoyance with the nice new builtin "git am"

Jeff King writes: > On Thu, Jul 28, 2016 at 05:37:08PM -0700, Linus Torvalds wrote: > >> > and then to sprinkle calls liberally through builtin-ified programs when >> > they move from one unit of work to the next. >> >> Maybe we can just add it to the end of

Re: Small trivial annoyance with the nice new builtin "git am"

Linus Torvalds writes: > So we do want to cache things for a single commit, it's just that for > things like "git am" (or, like Junio wondered, "git rebase" - I didn't > check) we probabyl just just flush the cache in between commits. What I cautioned was indeed

Re: [PATCH] Fix failing test t3700-add.sh

Jeff King writes: > I was also puzzled why the test fails for you; it does not for me. > Running the test script as root does make it fail. There are some > earlier tests which are skipped in this case, which run "git reset > --hard" with xfoo1 in the index, which cleans it up. >

Re: [PATCH v2 0/5] Git filter protocol

> On 29 Jul 2016, at 18:50, Jeff King wrote: > > On Fri, Jul 29, 2016 at 06:20:51PM +0200, Lars Schneider wrote: > That being said a "fail" response is a very good idea! This allows the filter to communicate to git that a non required filter process failed. I will

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Dakota Hawkins writes: > I have a question which may be a bug (I'm a bit skeptical), but here goes: > > In my global .gitconfig, I have "user.useConfigOnly = true" and > user.email isn't set there (I prefer to be forced to set it on a > per-repo basis, as I use different

Re: [PATCH 0/3] diff-highlight: add support for git log --graph output.

On Fri, Jul 29, 2016 at 07:51:27AM -0700, Brian Henderson wrote: > (resending as thread instead of attachments) Hmm, the actual patches don't seem to have made it to the list. :( -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Fri, Jul 29, 2016 at 5:44 AM, Richard Ipsum wrote: >> >> These definitely seem like a family of related problems. I'd like to >> use git-series as a format for storing iterations on things like GitHub >> pull-requests or Gerrit patch versions (in the latter

Re: [PATCH v2 5/5] convert: add filter..process option

Lars Schneider writes: > I think sending it upfront is nice for buffer allocations of big files > and it doesn't cost us anything to do it. While I do NOT think "total size upfront" MUST BE avoided at all costs, I do not think the above statement to justify it makes

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

On Fri, Jul 29, 2016 at 11:20:49AM -0700, Junio C Hamano wrote: > There is one that still wants to know who you are, I think. The > reflog entries record who moved the tip of the ref and when, and > obviously a fast-forward is also recorded. > > I _think_ our intention was to allow a bogus

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Jeff King writes: >> > Is this a case of rebase trying to make sure it has enough information >> > for me to be a committer before knowing whether I even need to rewrite >> > any commits, and could/should that be avoided? Alternatively (or also) >> > could/should rebase detect

Re: [PATCH v8 32/41] environment: add set_index_file()

On Fri, Jul 29, 2016 at 8:23 PM, Christian Couder wrote: > On Fri, Jul 29, 2016 at 5:34 PM, Duy Nguyen wrote: >> >> Yeah. If the libification movement is going strong, we can start >> converting and at some point should be able to define >>

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

Jeff King writes: > ... So I do think there may be a bug to be fixed, > but it is simply commands being over-eager to make sure we have an > ident when they might not need it. 36267854 (pull: fast-forward "pull --rebase=true", 2016-06-29) may be a part of a good solution for

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

On Fri, Jul 29, 2016 at 11:32:40AM -0700, Junio C Hamano wrote: > > Wouldn't it be wrong to create a commit with non-config ident when > > user.useConfigOnly is set, though? > > That is exactly what I was getting at. Ah, OK, I thought you were trying to explore the opposite direction. > > If

Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"

On Fri, Jul 29, 2016 at 02:39:11PM -0400, Jeff King wrote: > From my limited testing, "git pull --rebase" is perfectly fine. The > culprit is "--rebase=preverse", which complains even if it would be a > fast-forward. That should be preserve, of course. :) And I think I see what is happening.

Re: [PATCH v8 32/41] environment: add set_index_file()

Duy Nguyen writes: > On Fri, Jul 29, 2016 at 8:23 PM, Christian Couder > >> Do you mean that it might be a source of micro-projects for the next >> GSoC or Outreachy? ;-) > > No that's what I meant by boring. This is not something to interest > GSoC candidates, and while it