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.
> >
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
> op
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, it
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,
> > }
> >
> > /* Person/da
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 "git commit", bec
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 in
> 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 it.
>>
>> While I do NOT think "total size u
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 +--
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 creation then the
PKTLINE_DA
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. Fix it by moving the trace
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
---
t/t0021-conversion.sh | 48 +++
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 execution time.
This patc
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
---
Documentation/technical/protocol-c
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 insertions(+), 6 deletions(-)
diff --git a/convert.c b
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 changed, 10 insertions(+), 5 deletions(-)
diff --git
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 insertions(+), 4 deletions(-)
diff --git a/run-command.c b/r
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 Schneider
---
pkt-line.c | 6 +++
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" (Jakub)
* use proper types
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 costs,
> I do not think the abov
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
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 com
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 seems like nobody
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 pull.rebase that mak
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: fast-forward "pull --reba
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 does not begin in
a capita
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 more-or-less useless
noiseword i
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) &&
> + commit_patch_id(a->commit, opt, a->p
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)
> {
> memset(ids, 0, sizeof(
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
index 4865304..494f5b8 1
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
---
t/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
--- a/t/t3700-add.sh
+++ b/t/t3700-add.s
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 cherry_flag on the correct
> commit when running throu
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 the patch ids.
>
> Signed-off-by: Kevin Willford
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 determine if two commit
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 looks simple, sometim
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. "pr
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 th
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 that, perhaps?
-- >
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
>> NO_THE_INDEX_COMPATIBILITY_MACROS globally (and avoid th
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 that a fast-forwar
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 ident
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
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
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, there is a risk. I lo
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 rebase trying to make sure it has enough informati
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 to cache by def
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 trivially fix the g
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 has
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(&git_default_date);
>> +}
>
> Looks sane.
>
>> and then to sprinkle calls liberally thr
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 no
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
\ /
o---G
and you
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 majord...@vger.ke
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 emails for work and perso
> 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 add that to the
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 ANY sense.
Big files are by
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.
>
>> +echo foo
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 "git rebase", and the codepath th
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 case, overcoming
>> Gerrit's limitat
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 commit_tree_extended(), and
>> just s
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() to drive "git c
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 this list: send the line "u
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 ",
[+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 xfoo
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 changed, 6 insertions(+
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 side when a patch_id ma
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-ids.c | 2 +-
3 files changed, 12 insertio
> 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 until the flush pa
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) and skipping those local
p
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
---
patch-ids.c | 86 +
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 Willford
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 should exist or not.
>
> Also the same bl
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
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 betwe
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 or
>> index_name_pos).
>
> The
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 delta against
> a
(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
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
---
gitweb/gitw
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 should be used like this:
>>>
>>> /* Save current index file *
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 m
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
> Gerri
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 --git a/t/t3700-add.sh
> 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, const
size_t size)
>>>
>>> I'm
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 const-correctness taken
>> too
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 a
> 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 read(2) prototype
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 st
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 "p
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
Th
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
>> date.
>
> No, that would be nasty, partly f
> 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 - otherwise I would have
> 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 by a filter. If Git filters a lot of blobs
>>
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 is
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 th
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 --h
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 would be to stop putti
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 arguments
96 matches
Mail list logo
