On 06/16/2017 07:42 AM, Stefan Beller wrote:
> On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty
> wrote:
>> This will later become a method of `packed_ref_store`.
>
> Also while touching it, maybe rename sha1 to object_hash
> (not saying object_id as that would be confusing with the actual
> oi
On 06/16/2017 07:39 AM, Stefan Beller wrote:
> On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty
> wrote:
>> [...]
>> @@ -125,7 +125,7 @@ static void clear_packed_ref_cache(struct
>> files_ref_store *refs)
>> if (refs->packed_ref_store->cache) {
>> struct packed_ref_cache
On 06/15/2017 09:22 PM, Stefan Beller wrote:
On Thu, Jun 15, 2017 at 5:52 PM, Michael Eager wrote:
One other variant of the rebase approach I've thought of is to do
this incrementally, rebasing the old repo against an upstream commit
a short time after the old repo was forked, fixing any confl
On Fri, Jun 16 2017, brian m. carlson jotted:
> On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
>> On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson
>> wrote:
>> > SHA-256 acceleration exists for some existing Intel platforms already.
>> > However, they're not practical
Thanks for your comments.
On 06/15/2017 07:57 PM, Michael O'Cleirigh wrote:
Hi Michael,
In git if you don't merge often then you get these merge conflict hell
situations.
In my experience the main conflicts come not from the unified diff of those 130
commits but from
differences in the surro
On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty wrote:
> Now that the interface between `files_ref_store` and
> `packed_ref_store` is relatively narrow, move the latter into a new
> module, "refs/packed-backend.h" and "refs/packed-backend.c". It still
> doesn't quite implement the `ref_store` in
On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty wrote:
> This will later become a method of `packed_ref_store`.
Also while touching it, maybe rename sha1 to object_hash
(not saying object_id as that would be confusing with the actual
oid struct), maybe?
On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty wrote:
> Move the `packed_refs_lock` member from `files_ref_store` to
> `packed_ref_store`, and rename it to `lock` since it's now more
> obvious what it is locking.
>
> Signed-off-by: Michael Haggerty
> ---
> refs/files-backend.c | 31 ++
On Thu, Jun 15, 2017 at 7:47 AM, Michael Haggerty wrote:
> Move `packed_refs_path` from `files_ref_store` to `packed_ref_store`,
> and rename it to `path` since its meaning is clear from its new
> context.
>
> Inline `files_packed_refs_path()`.
>
> Signed-off-by: Michael Haggerty
> ---
> refs/fi
Most of the time, a 'stash entry' is called a 'stash'
or a 'stash state'. Lets use 'stash entry' instead.
Signed-off-by: Liam Beguin
---
Documentation/config.txt | 6 +++---
Documentation/git-pull.txt | 2 +-
Documentation/git-rebase.txt | 2 +-
Documentation/git-stash.txt | 49 +++
Add the `status.showStash` configuration option to allow git-status to
show information about currently stashed entries.
Signed-off-by: Liam Beguin
---
Documentation/config.txt | 5 +
wt-status.c | 24
2 files changed, 29 insertions(+)
diff --git a/Doc
Add glossary entry for "stash entries".
Signed-off-by: Liam Beguin
---
Documentation/glossary-content.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/glossary-content.txt
b/Documentation/glossary-content.txt
index 6e991c246915..026f66e7240a 100644
--- a/Documentation/g
On Thu, Jun 15, 2017 at 12:17:15PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> >> contrib/diff-highlight/.gitignore | 2 ++
> >> .../{diff-highlight => DiffHighlight.pm} | 40
> >> +-
> >> contrib/diff-highlight/Makefile
As discussed here [*1*], this allows `git status` to show the number of
entries currently stashed away.
I also tried to update the related parts of the documentation to use
'stash entry' instead of 'stash' as we agreed that it was a bit better.
I don't mind dropping the documentation update and us
On Fri, Jun 16, 2017 at 06:10:22AM +0900, Mike Hommey wrote:
> > > What do the experts think or SHA512/256, which completely removes the
> > > concerns over length extension attack? (which I'd argue is better than
> > > sweeping them under the carpet)
> >
> > I don't think it's sweeping them unde
On Thu, Jun 15, 2017 at 5:52 PM, Michael Eager wrote:
> One other variant of the rebase approach I've thought of is to do
> this incrementally, rebasing the old repo against an upstream commit
> a short time after the old repo was forked, fixing any conflicts,
> rebuilding and fixing build failur
Hi,
On 14/06/17 09:08 AM, Johannes Schindelin wrote:
> diff --git a/sequencer.c b/sequencer.c
> index a697906d463..a0e020dab09 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -2640,3 +2640,110 @@ int check_todo_list(void)
>
> return res;
> }
> +
> +/* skip picking commits whose paren
Hi All --
I'm working with code that is based on a five year old repository.
There are 130 local commits since the repo was forked. Naturally,
the upstream project has moved on significantly.
I'm wondering about best approaches to updating the repo to the
current upstream version. Here are the
On Fri, Jun 16, 2017 at 01:36:13AM +0200, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson
> wrote:
> > SHA-256 acceleration exists for some existing Intel platforms already.
> > However, they're not practically present on anything but servers at the
> > moment,
On 06/15, Brandon Williams wrote:
> On 06/15, Junio C Hamano wrote:
> > Brandon Williams writes:
> >
> > > On 06/15, Junio C Hamano wrote:
> > >
> > >> ... so please eyeball the resulting 12 patches carefully when
> > >> they are pushed out.
I just took a look at what you pushed out and they loo
On Thu, Jun 15, 2017 at 6:55 PM, Samuel Lijin wrote:
>
> Can you elaborate on why you consider this useful specifically?
Personally, primary usages of the current commit-ish info are to file bug
reports that include the specific git revision of any given branch that a bug
was observed in/on and t
On Thu, Jun 15, 2017 at 7:43 PM, Mahmoud Al-Qudsi wrote:
> Hello all,
>
> I hope it is not considered too forward of me for my first post to this list
> to be a suggestion on a change to git’s behavior (though not in any
> functional manner); but a persistent frustration for me and everyone I’ve
>
Hello all,
I hope it is not considered too forward of me for my first post to this list
to be a suggestion on a change to git’s behavior (though not in any
functional manner); but a persistent frustration for me and everyone I’ve
worked with (so, yes, 100% based off of anecdata) has been that the
On Fri, Jun 16, 2017 at 12:41 AM, brian m. carlson
wrote:
> On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote:
>> (I was asked to comment a few points in public by Jonathan.)
>>
>> I think this group can safely assume that SHA-256, SHA-512, BLAKE2,
>> K12, etc are all secure to the exte
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Phillip Wood writes:
>>
>>> From: Phillip Wood
>>>
>>> I've revised the second two tests as Johannes suggested to drop the
>>> sed script. The first one is unchanged.
>>>
>>> Phillip Wood (3):
>>> rebase -i: Add test for reflog message
>>>
Junio C Hamano writes:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> I've revised the second two tests as Johannes suggested to drop the
>> sed script. The first one is unchanged.
>>
>> Phillip Wood (3):
>> rebase -i: Add test for reflog message
>> rebase: Add regression tests for co
Signed-off-by: Ævar Arnfjörð Bjarmason
---
contrib/coccinelle/free.cocci | 8
1 file changed, 8 insertions(+)
diff --git a/contrib/coccinelle/free.cocci b/contrib/coccinelle/free.cocci
index c03ba737e5..35fb992621 100644
--- a/contrib/coccinelle/free.cocci
+++ b/contrib/coccinelle/free.
A follow-up to the existing "type" rule added in an earlier
change. This catches some occurrences that are missed by the previous
rule.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
contrib/coccinelle/free.cocci | 7 +++
1 file changed, 7 insertions(+)
diff --git a/contrib/coccinelle/free.cocc
Replace occurrences of `free(ptr); ptr = NULL` which weren't caught by
the coccinelle rule. These fall into two categories:
- free/NULL assignments one after the other which coccinelle all put
on one line, which is functionally equivalent code, but very ugly.
- manually spotted occurrences w
Add a FREE_AND_NULL() wrapper marco for the common pattern of freeing
a pointer and assigning NULL to it right afterwards.
The implementation is similar to the (currently unused) XDL_PTRFREE
macro in xdiff/xmacros.h added in commit 3443546f6e ("Use a *real*
built-in diff generator", 2006-03-24). T
A follow-up to the existing "expression" rule added in an earlier
change. This manually excludes a few occurrences, mostly things that
resulted in many FREE_AND_NULL() on one line, that'll be manually
fixed in a subsequent change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
blame.c| 3 +--
ll
Apply the result of the just-added coccinelle rule. This manually
excludes a few occurrences, mostly things that resulted in many
FREE_AND_NULL() on one line, that'll be manually fixed in a subsequent
change.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
alias.c | 6 ++
apply.
Hi,
Git-cinnabar is a git remote helper to interact with mercurial
repositories. It allows to clone, pull and push from/to mercurial remote
repositories, using git.
Code on https://github.com/glandium/git-cinnabar
This release on
https://github.com/glandium/git-cinnabar/releases/tag/0.5.0b2
What
I didn't know about the coccinelle semantic patch facility. This adds
coccinelle rules to do the code changes, and adds subsequent follow-up
commits which apply that change, with the series ending with a patch
that I manually authored.
This fixes a bug in earlier versions of the series. I was mist
Johannes Schindelin writes:
> Changes since v4:
>
> - replaced the "sha1s" part of the names by "ids", to reflect the
> current effort to move away from the cryptographically unsafe SHA-1
>
> - replaced the confusing term "instruction sheet" in an error message by
> the more commonly used "to
Phillip Wood writes:
> From: Phillip Wood
>
> I've revised the second two tests as Johannes suggested to drop the
> sed script. The first one is unchanged.
>
> Phillip Wood (3):
> rebase -i: Add test for reflog message
> rebase: Add regression tests for console output
> rebase: Add more re
On Thu, Jun 15, 2017 at 02:59:57PM -0700, Adam Langley wrote:
> (I was asked to comment a few points in public by Jonathan.)
>
> I think this group can safely assume that SHA-256, SHA-512, BLAKE2,
> K12, etc are all secure to the extent that I don't believe that making
> comparisons between them o
Michael Haggerty writes:
> `for_each_bisect_ref()` is called by `for_each_bad_bisect_ref()` with
> a term "bad". This used to make it call `for_each_ref_in_submodule()`
> with a prefix "refs/bisect/bad". But the latter is the name of the
> reference that is being sought, so the empty string was b
Christian Couder writes:
> This makes the code simpler by removing a few lines, and getting
> rid of one variable.
>
> Signed-off-by: Christian Couder
> ---
This patch may have meant well, but I think e5698f3a ("clone:
respect additional configured fetch refspecs during initial fetch",
2017-05-
Ævar Arnfjörð Bjarmason writes:
> A negated character class that does not include '/', e.g. [^a-z]:
>
> - Should match '/' when doing "wildmatch"
> - Should not match '/' when doing "pathmatch"
>
> Add two tests to cover these cases.
>
> Helped-by: Junio C Hamano
> Signed-off-by: Ævar Arnfjör
Ævar Arnfjörð Bjarmason writes:
> On Thu, Jun 15 2017, Ævar Arnfjörð Bjarmason jotted:
>> I'll change it to FREE_AND_NULL and submit my patch as-is, my reading
>> of the rest of this thread is that making it a function instead of a
>> macro would be interesting, but has its own caveats that are
(I was asked to comment a few points in public by Jonathan.)
I think this group can safely assume that SHA-256, SHA-512, BLAKE2,
K12, etc are all secure to the extent that I don't believe that making
comparisons between them on that axis is meaningful. Thus I think the
question is primarily concer
René Scharfe writes:
>> If it is a concern, I think it could be solved by "unpretending" after
>> our call to checkout_entry completes. That would need a new call in
>> sha1_file.c, but it should be easy to write.
>
> Good point; we'd accumulate fake entries that we'll never need again.
Hopefull
René Scharfe writes:
> Am 15.06.2017 um 15:52 schrieb Jeff King:
>> But for the special case of the "-local" formats, we can
>> just skip the adjustment and use localtime() instead of
>> gmtime(). This makes --date=format-local:%Z work correctly,
>> showing the local timezone instead of an empty
Jonathan Nieder writes:
> Christian Couder wrote:
>
>> Subject: sub-process: fix comment about api-sub-process.txt
>
> nit: this one-line description doesn't describe what was wrong and is
> being fixed. I think something like
>
> sub-process: correct path to API docs in comment
>
> would
On 06/15, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > On 06/15, Junio C Hamano wrote:
> >
> >> ... so please eyeball the resulting 12 patches carefully when
> >> they are pushed out.
> >
> > Ugh, I'm terribly sorry. Completely my bad as I didn't consider what
> > you would need to do
Thanks.
A negated character class that does not include '/', e.g. [^a-z]:
- Should match '/' when doing "wildmatch"
- Should not match '/' when doing "pathmatch"
Add two tests to cover these cases.
Helped-by: Junio C Hamano
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Now with updated commit message,
On Thu, Jun 15, 2017 at 09:01:45AM -0400, Jeff King wrote:
> On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote:
>
> > On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
> > > Footnote *1*: SHA-256, as all hash functions whose output is essentially
> > > the entire inter
Brandon Williams writes:
> On 06/15, Junio C Hamano wrote:
>
>> ... so please eyeball the resulting 12 patches carefully when
>> they are pushed out.
>
> Ugh, I'm terribly sorry. Completely my bad as I didn't consider what
> you would need to do on your end. When I built my patches on top of hi
Replace occurrences of `free(ptr); ptr = NULL` with
`FREE_AND_NULL(ptr)`. This introduces no functional changes, but
reduces the line count and establishes this pattern as a common idiom
with a wrapper macro.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
alias.c | 6 ++
apply.
Add a FREE_AND_NULL() wrapper marco for the common pattern of freeing
a pointer and assigning NULL to it right afterwards.
The implementation is similar to the (currently unused) XDL_PTRFREE
macro in xdiff/xmacros.h added in commit 3443546f6e ("Use a *real*
built-in diff generator", 2006-03-24). T
On Thu, Jun 15 2017, Ævar Arnfjörð Bjarmason jotted:
> I'll change it to FREE_AND_NULL and submit my patch as-is, my reading
> of the rest of this thread is that making it a function instead of a
> macro would be interesting, but has its own caveats that are likely
> better considered as part of it
On Thu, 15 Jun 2017 16:28:24 -0400
Jeff Hostetler wrote:
> I agree with Peff here. I've been working on my partial/narrow/sparse
> clone/fetch ideas since my original RFC and have come to the conclusion
> that the server can do the size limiting efficiently, but we should
> leave the pathname fi
Jonathan Tan writes:
> There is indeed no reason why we need to keep multiple ones separate for
> an extended period of time - my thinking was to let fetch/clone be fast
> by not needing to scan through the entire existing manifest (in order to
> create the new one), letting GC take care of cons
In a subsequent patch, packed_object_info() will be modified to use the
delta base cache, so move the relevant code to before
packed_object_info().
Signed-off-by: Jonathan Tan
---
sha1_file.c | 220 ++--
1 file changed, 110 insertions(+), 1
Thanks - this has been updated following Junio's comments.
Patch 1 is unmodified from the previous version.
Patch 2 has been modified to remove the extraneous code pointed out by
Junio. I previously had an idea of populating those fields in
packed_object_info(), but later changed my mind, but a r
In commit 46f0344 ("sha1_file: support reading from a loose object of
unknown type", 2015-05-06), "struct object_info" gained a "typename"
field that could represent a type name from a loose object file, whether
valid or invalid, as opposed to the existing "typep" which could only
represent valid t
Currently, Git does not support repos with very large numbers of blobs
or repos that wish to minimize manipulation of certain blobs (for
example, because they are very large) very well, even if the user
operates mostly on part of the repo, because Git is designed on the
assumption that every blob r
In sha1_file.c, there are a few functions that provide information on an
object regardless of its storage (cached, loose, or packed). Looking
through all non-static functions in sha1_file.c that take in an unsigned
char * pointer, the relevant ones are:
- sha1_object_info_extended
- sha1_object_i
On 06/15, Junio C Hamano wrote:
> Brandon Williams writes:
>
> > Changes in v3:
> >
> > * tweaked the discover_git_directory function's API based on Peff's feedback
> > * reordered the last three patches so that they flowed a bit better
> > * renamed 'git_config_with_options'
> > * rebased ontop
A reroll is coming soon, but there is an interesting discussion point
here so I'll reply to this e-mail first.
On Thu, 15 Jun 2017 11:34:45 -0700
Junio C Hamano wrote:
> Jonathan Tan writes:
>
> > +struct missing_blob_manifest {
> > + struct missing_blob_manifest *next;
> > + const char *d
On 6/2/2017 6:26 PM, Jeff King wrote:
On Fri, Jun 02, 2017 at 12:38:45PM -0700, Jonathan Tan wrote:
...
We have a name-hash cache extension in the bitmap file, but it doesn't
carry enough information to deduce the .git-ness of a file. I don't
think it would be too hard to add a "flags" extens
On 06/15/2017 12:15 PM, Junio C Hamano wrote:
> Do you want +x bit for the last one? I could throw that bit in
> while queuing if you want.
>
> Thanks.
>
Ya probably best.
Brandon Williams writes:
> Changes in v3:
>
> * tweaked the discover_git_directory function's API based on Peff's feedback
> * reordered the last three patches so that they flowed a bit better
> * renamed 'git_config_with_options'
> * rebased ontop of v4 of Dscho's alias series
>
> https://pub
Hi Junio,
On Thu, 15 Jun 2017, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > +struct config_alias_data
> > +{
>
> Style: "struct config_alias_data {"
>
> which I can tweak while applying.
Please do.
> Other than that, everything looks good.
Thanks,
Dscho
Johannes Schindelin writes:
> +struct config_alias_data
> +{
Style: "struct config_alias_data {"
which I can tweak while applying.
Other than that, everything looks good.
Thanks.
Hi,
On Thu, 15 Jun 2017, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Jun 15 2017, Jeff King jotted:
>
> > On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote:
> >
> >> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
> >>
> >> > Footnote *1*: SHA-256, as all hash functio
Brandon Williams writes:
>> It would make a whole of a lot of sense to make that knob not Boolean,
>> but to specify which hash function is in use.
>
> 100% agree on this point. I believe the current plan is to have the
> hashing function used for a repository be a repository format extension
>
Junio C Hamano writes:
>> contrib/diff-highlight/.gitignore | 2 ++
>> .../{diff-highlight => DiffHighlight.pm} | 40
>> +-
>> contrib/diff-highlight/Makefile| 21 ++--
>> contrib/diff-highlight/README
Jeff King writes:
> The diff-so-fancy project is also written in perl, and most
> of its users pipe diffs through both diff-highlight and
> diff-so-fancy. It would be nice if this could be done in a
> single script. So let's pull most of diff-highlight's code
> into its own module which can be us
Hi Dscho,
Johannes Schindelin wrote:
> From what I read, pretty much everybody who participated in the discussion
> was aware that the essential question is: performance vs security.
I don't completely agree with this framing. The essential question is:
how to get the right security properties
Dear Git users,
It is my pleasure to announce that Git for Windows 2.13.1(2) is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.13.1 (June 13th 2017)
Bug Fixes
* git commit and git status no longer randomly throw segmentation
faults.
Filename
René Scharfe writes:
> Am 13.06.2017 um 23:20 schrieb Junio C Hamano:
>
>> I think the real question is how likely people use more than one
>> occurrence of the same thing in their custom format, and how deeply
>> they care that --format='%h %h' costs more than --format='%h'. The
>> cost won't o
Jonathan Tan writes:
> diff --git a/sha1_file.c b/sha1_file.c
> index 98086e21e..75fe2174d 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -27,6 +27,9 @@
> #include "list.h"
> #include "mergesort.h"
> #include "quote.h"
> +#include "iterator.h"
> +#include "dir-iterator.h"
> +#include "sha
On Thu, 15 Jun 2017 10:50:46 -0700
Junio C Hamano wrote:
> Jonathan Tan writes:
>
> > Looking at the 3 primary functions (sha1_object_info_extended,
> > read_object, has_sha1_file_with_flags), they independently implement
> > mechanisms such as object replacement, retrying the packed store afte
Andreas Heiduk writes:
> Am 15.06.2017 um 18:43 schrieb Junio C Hamano:
>> Another thing that may regress that you did not mention is that we
>> would lose a convenient way to _count_ proposed changes coming via
>> submitGit (i.e. you can simply go to the pull-request page), so that
>> the number
Jonathan Tan writes:
> Looking at the 3 primary functions (sha1_object_info_extended,
> read_object, has_sha1_file_with_flags), they independently implement
> mechanisms such as object replacement, retrying the packed store after
> failing to find the object in the packed store then the loose sto
Any chance you can tell us what repo this happens on? + git version,
OS, and what the triggering diff invocation is.
On Thu, Jun 15, 2017 at 12:19 PM, Matthew Groth wrote:
> When I do `git diff` sometimes I get this:
>
>
> ...skipping...
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
> ~
On 06/15, Johannes Schindelin wrote:
> Hi,
>
> I thought it better to revive this old thread rather than start a new
> thread, so as to automatically reach everybody who chimed in originally.
>
> On Mon, 6 Mar 2017, Brandon Williams wrote:
>
> > On 03/06, brian m. carlson wrote:
> >
> > > On Sat
Am 15.06.2017 um 18:43 schrieb Junio C Hamano:
> Another thing that may regress that you did not mention is that we
> would lose a convenient way to _count_ proposed changes coming via
> submitGit (i.e. you can simply go to the pull-request page), so that
> the number can be compared with the numbe
On Thu, Jun 15, 2017 at 6:48 PM, Junio C Hamano wrote:
> Jeff King writes:
>
>> On Sat, Jun 10, 2017 at 03:21:43AM +, Eric Wong wrote:
>>
>>> > So make Jonathan's freez_impl a public API and rename it to
>>> > free_and_null(), perhaps?
>>>
>>> Perhaps... I think it needs to take "void *" to
Jonathan Tan writes:
> In a subsequent patch, packed_object_info() will be modified to use the
> delta base cache, so move the relevant code to before
> packed_object_info().
>
> Signed-off-by: Jonathan Tan
> ---
> sha1_file.c | 226
> +++
Jeff King writes:
> On Sat, Jun 10, 2017 at 03:21:43AM +, Eric Wong wrote:
>
>> > So make Jonathan's freez_impl a public API and rename it to
>> > free_and_null(), perhaps?
>>
>> Perhaps... I think it needs to take "void *" to avoid warnings:
>>
>> static inline void free_and_null(voi
Ævar Arnfjörð Bjarmason writes:
> There are things we get out of this that would regress if
> submitGit were changed this way:
>
> * Now when you submit a pull request you get a Travis build for
> git/git, I don't get this if I push to any random branch in my
> avar/git, and although I could pro
The diff-so-fancy project is also written in perl, and most
of its users pipe diffs through both diff-highlight and
diff-so-fancy. It would be nice if this could be done in a
single script. So let's pull most of diff-highlight's code
into its own module which can be used by diff-so-fancy.
In addit
On Thu, Jun 15 2017, Jeff King jotted:
> On Thu, Jun 15, 2017 at 08:05:18PM +0900, Mike Hommey wrote:
>
>> On Thu, Jun 15, 2017 at 12:30:46PM +0200, Johannes Schindelin wrote:
>> > Footnote *1*: SHA-256, as all hash functions whose output is essentially
>> > the entire internal state, are suscept
When I do `git diff` sometimes I get this:
...skipping...
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
...skipping...
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
...skipping...
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
~
it goes on like this for about 10 times the length. Looks like this
happens
Am 15.06.2017 um 15:52 schrieb Jeff King:
But for the special case of the "-local" formats, we can
just skip the adjustment and use localtime() instead of
gmtime(). This makes --date=format-local:%Z work correctly,
showing the local timezone instead of an empty string.
Documentation/rev-list-op
Jonathan Nieder writes:
>> It is not known if a simple "yes/no" is sufficient in the longer
>> term, and what should happen when --recurse-submodules option starts
>> taking "recurse into them how?" parameter, though.
>
> Any pointers for where this has been discussed, if anywhere (e.g. was
I
Am 15.06.2017 um 15:57 schrieb Jeff King:
> On Thu, Jun 15, 2017 at 01:33:42PM +0200, René Scharfe wrote:
>
>> Merge results need to be written to the worktree, of course, but we
>> don't necessarily need object entries for them, especially if they
>> contain conflict markers. Use pretend_sha1_fi
That way the callers don't have to come up with error messages
themselves.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 6 ++
refs/packed-backend.c | 17 +++--
refs/packed-backend.h | 6 +++---
3 files changed, 16 insertions(+), 13 deletions(-)
diff --git a/refs
The existing callers already check that the lock isn't held just
before calling `clear_packed_ref_cache()`, and in the near future we
want to be able to call this function when the lock is held.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 2 --
1 file changed, 2 deletions(-)
dif
Start extracting the packed-refs-related data structures into a new
class, `packed_ref_store`. It doesn't yet implement `ref_store`, but
it will.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 42 +-
1 file changed, 33 insertions(+), 9 deletion
Change `repack_without_refs()` to expect the packed-refs lock to be
held already, and not to release the lock before returning. Change the
callers to deal with lock management.
This change makes it possible for callers to hold the packed-refs lock
for a longer span of time, a possibility that will
It only cares about the packed-refs part of the reference store.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 15 +++
1 file changed, 7 insertions(+), 8 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 5d159620f0..a08d3fbadf 100644
--- a/refs
It only cares about the packed-refs part of the reference store.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index de8293493f..2b0db60b2b 100644
--- a/ref
It only cares about the packed-refs part of the reference store.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 2b0db60b2b..f061506bf0 100644
--- a/refs/f
Instead, change the callers of `commit_packed_refs()` to call
`packed_refs_unlock()`.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 2 ++
refs/packed-backend.c | 18 --
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/refs/files-backend.c b/refs/fil
The old code ignored any lines that it didn't understand. This is
dangerous. Instead, `die()` if the `packed-refs` file contains any
lines that we don't know how to handle.
Signed-off-by: Michael Haggerty
---
refs/packed-backend.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff
1 - 100 of 150 matches
Mail list logo
