On Wed, Apr 25, 2018 at 09:05:56AM +0900, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> > In modern setups, less, the pager, uses alternate screen to show
> > the content. When it is closed, it switches back to the original
> > screen, and all content is gone.
> >
> > It is
On 25 April 2018 at 04:00, brian m. carlson
wrote:
> On Tue, Apr 24, 2018 at 11:58:17AM +0200, Martin Ågren wrote:
>> On 24 April 2018 at 01:39, brian m. carlson
>> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
>> > index c4272fbc96..5f35596c14
On Tue, Apr 24, 2018 at 11:58:17AM +0200, Martin Ågren wrote:
> On 24 April 2018 at 01:39, brian m. carlson
> > diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
> > index c4272fbc96..5f35596c14 100644
> > --- a/builtin/receive-pack.c
> > +++ b/builtin/receive-pack.c
> > @@ -454,21
On Tue, Apr 24, 2018 at 5:52 PM, Junio C Hamano wrote:
> Wink Saville writes:
>
>> Ideally I would have liked the tags fetched from gbenchmark to have a prefix
>> of gbenchmark/, like the branches have, maybe something like:
>>
>> $ git fetch --tags
On Tue, Apr 24, 2018 at 5:52 PM, Junio C Hamano wrote:
> Wink Saville writes:
>
>> Ideally I would have liked the tags fetched from gbenchmark to have a prefix
>> of gbenchmark/, like the branches have, maybe something like:
>>
>> $ git fetch --tags
On Wed, Apr 25, 2018 at 08:44:19AM +0900, Junio C Hamano wrote:
> Martin Ågren writes:
>
> >> switch (data[i]) {
> >> case 'P':
> >> i++;
> >> - if (i + 52 <= buf.len &&
> >> +
Johannes Schindelin writes:
> Thank you, and sorry for the trouble. I am just too used to a Continuous
> Integration setting with exactly one integration branch.
Fixing problems close to the source (i.e. picking an appropriately
aged base) and making sure everthing
Wink Saville writes:
> Ideally I would have liked the tags fetched from gbenchmark to have a prefix
> of gbenchmark/, like the branches have, maybe something like:
>
> $ git fetch --tags gbenchmark
> ...
> * [new branch] v2 -> gbenchmark/v2
> * [new tag]
"Philip Oakley" writes:
> Perhaps something like:
> +$GIT_DIR/shallow, and handle its contents similar to replace
> +refs (with the difference that shallow does not actually
> +create those replace refs) with the difference that shallow commits will
> +always have their
Hi list,
I'm struggling with git connecting to Github.
The problem might be SSL/TLS related.
https://githubengineering.com/crypto-removal-notice/
I suspect that my setup still uses tlsv1 or tlsv1.1.
I've tried to explicitly set git to use tlsv1.2 in my .gitconfig file
like this:
[http]
Jonathan Tan writes:
> On Mon, 23 Apr 2018 16:43:23 -0700
> Stefan Beller wrote:
>
>> diff --git a/sha1_file.c b/sha1_file.c
>> index 93f25c6c6a..b292e04fd3 100644
>> --- a/sha1_file.c
>> +++ b/sha1_file.c
>> @@ -1307,7 +1307,8 @@ int
Ben Peart writes:
> diff.renameLimit::
> The number of files to consider when performing the copy/rename
> - detection; equivalent to the 'git diff' option `-l`.
> + detection; equivalent to the 'git diff' option `-l`. This setting
> + has no effect if
On Tue, 24 Apr 2018 16:23:28 -0700
Stefan Beller wrote:
> >> s/missmatch/mismatch/
> >> Also, what is this used for?
> >
> > The mismatch should be used for (thanks for catching!)
> > checking if the remainder of a line is the same, although a boolean
> > may be not the
Johannes Sixt writes:
> In modern setups, less, the pager, uses alternate screen to show
> the content. When it is closed, it switches back to the original
> screen, and all content is gone.
>
> It is not uncommon to request that the output remains visible in
> the terminal. For
Ben Peart writes:
> That said, it makes sense to me to do
>> this when rename detection is turned off. In fact, I think you'd
>> automatically want to set aggressive to true whenever rename detection
>> is turned off (whether by your merge.renames option or the
>>
On Tue, Apr 24, 2018 at 11:50:16AM +0200, Martin Ågren wrote:
> On 24 April 2018 at 01:39, brian m. carlson
> wrote:
> > The code for reading certain pack v2 offsets had a hard-coded 5
> > representing the number of uint32_t words that we needed to skip over.
> >
On Tue, Apr 24, 2018 at 12:57 PM, Wink Saville wrote:
> If have a repository with a tag "v1.0.0" and I add a remote repository
> which also has a tag "v1.0.0" tag is overwritten.
>
> Google found [1] from 2011 and option 3 is what I'd like to see. Has it been
> implemented and I
This allows us to run git, when using the script from bin-wrappers, under
other programs. A few examples for usage within testsuite scripts:
debug git checkout master
debug --debugger=nemiver git $ARGS
debug -d "valgrind --tool-memcheck --track-origins=yes" git $ARGS
Or, if someone has
Martin Ågren writes:
>> switch (data[i]) {
>> case 'P':
>> i++;
>> - if (i + 52 <= buf.len &&
>> + if (i + hexsz + 12 <= buf.len &&
>>
Replied to Jonathan only instead of all. My reply is below:
On Tue, Apr 24, 2018 at 3:55 PM, Stefan Beller wrote:
> On Tue, Apr 24, 2018 at 3:35 PM, Jonathan Tan
> wrote:
>> On Tue, 24 Apr 2018 14:03:30 -0700
>> Stefan Beller
On Tue, 24 Apr 2018 15:37:51 -0700
Stefan Beller wrote:
> These can be combined independently, so would
> you expect the user to expect two options for them?
> For example "--color-moved=zebra" could be split
> into "--skip-small --alternate-blocks"
Yes, this is a good
On Tue, Apr 24, 2018 at 3:37 PM, Jonathan Tan wrote:
> On Tue, 24 Apr 2018 14:03:23 -0700
> Stefan Beller wrote:
>
>> v2:
>> I think I have addressed Jonathans feedback
>> * by using a string instead of counting the first character only.
>> * refined
On Tue, 24 Apr 2018 14:59:09 -0700
Stefan Beller wrote:
> This involves also adapting oid_object_info_extended and a some
> internal functions that are used to implement these. It all has to
> happen in one patch, because of a single recursive chain of calls visits
> all
On Tue, Apr 24, 2018 at 2:50 PM, Jonathan Tan wrote:
> On Tue, 24 Apr 2018 14:03:28 -0700
> Stefan Beller wrote:
>
>> Suggested-by: Ævar Arnfjörð Bjarmason
>> (https://public-inbox.org/git/87o9j0uljo@evledraar.gmail.com/)
>>
On Tue, 24 Apr 2018 14:03:23 -0700
Stefan Beller wrote:
> v2:
> I think I have addressed Jonathans feedback
> * by using a string instead of counting the first character only.
> * refined tests slightly (easier to read)
> * moved white space handling for moved blocks into its
On Tue, 24 Apr 2018 14:03:30 -0700
Stefan Beller wrote:
> +--color-moved-[no-]ignore-space-prefix-delta::
> + Ignores whitespace when comparing lines when performing the move
> + detection for --color-moved. This ignores uniform differences
> + of white space at
Hi Jonathan,
On Tue, Apr 24, 2018 at 3:00 PM, Jonathan Tan wrote:
> On Tue, 24 Apr 2018 14:03:29 -0700
> Stefan Beller wrote:
>
>> As we change the default, we'll adjust the tests.
>
> This statement is probably better written as:
>
> In some
On Tue, 24 Apr 2018 14:03:29 -0700
Stefan Beller wrote:
> As we change the default, we'll adjust the tests.
This statement is probably better written as:
In some existing tests, options like --ignore-space-at-eol were used
to control the color of the output. They have
This involves also adapting sha1_object_info_extended and a some
internal functions that are used to implement these. It all has to
happen in one patch, because of a single recursive chain of calls visits
all these functions.
sha1_object_info_extended is also used in partial clones, which allow
Add a repository argument to allow the callers of unpack_entry
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to catch
Add a repository argument to allow the callers of read_object
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to catch
This involves also adapting oid_object_info_extended and a some
internal functions that are used to implement these. It all has to
happen in one patch, because of a single recursive chain of calls visits
all these functions.
sha1_object_info_extended is also used in partial clones, which allow
Add a repository argument to allow the callers of cache_or_unpack_entry
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to
From: Jonathan Nieder
Add a repository argument to allow callers of packed_object_info to be
more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with
Add a repository argument to allow the callers of oid_object_info
to be more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to catch
Add a repository argument to allow the callers of packed_to_object_type
to be more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro to
v2:
* fixed the sha1/oid typo
* removed spurious new line
* Brandon and Jonthan discovered another dependency that I missed due
to cherrypicking that commit from a tree before partial clone was a thing.
We error out when attempting to use fetch_object for repos that are not
the_repository.
Add a repository argument to allow the callers of retry_bad_packed_offset
to be more specific about which repository to handle. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
As with the previous commits, use a macro
Add a repository argument to allow oid_object_info_extended callers
to be more specific about which repository to act on. This is a small
mechanical change; it doesn't change the implementation to handle
repositories other than the_repository yet.
Signed-off-by: Stefan Beller
Factor out a dwim_branch function, which takes care of the dwim'ery in
'git worktree add '. It's not too much code currently, but we're
adding a new kind of dwim in a subsequent patch, at which point it makes
more sense to have it as a separate function.
Factor it out now to reduce the patch
Currently 'git worktree add ' creates a new branch named after the
basename of the path by default. If a branch with that name already
exists, the command refuses to do anything, unless the '--force' option
is given.
However we can do a little better than that, and check the branch out if
it is
There are two members of 'struct add_opts', which are only used inside
the 'add()' function, but being part of 'struct add_opts' they are
needlessly also passed to the 'add_worktree' function.
Make them local to the 'add()' function to make it clearer where they
are used.
Signed-off-by: Thomas
Previous rounds are at <20180121120208.12760-1-t.gumme...@gmail.com>,
<20180204221305.28300-1-t.gumme...@gmail.com>,
<20180317220830.30963-1-t.gumme...@gmail.com>,
<2018031719.4940-1-t.gumme...@gmail.com>,
<20180325134947.25828-1-t.gumme...@gmail.com>,
Currently 'git worktree add' produces output like the following:
Preparing ../foo (identifier foo)
HEAD is now at 26da330922
The '../foo' is the path where the worktree is created, which the user
has just given on the command line. The identifier is an internal
implementation detail,
On Tue, 24 Apr 2018 14:03:28 -0700
Stefan Beller wrote:
> Suggested-by: Ævar Arnfjörð Bjarmason
> (https://public-inbox.org/git/87o9j0uljo@evledraar.gmail.com/)
> Signed-off-by: Stefan Beller
Firstly, I don't know if this is the
Hi dscho
From: "Johannes Schindelin" : Tuesday, April
24, 2018 8:10 PM
On Sun, 22 Apr 2018, Philip Oakley wrote:
From: "Johannes Schindelin"
> Now that grafts are deprecated, we should start to assume that readers
> have no idea what
--
Hello Dear Friend,
I am Williams Abbas, I need your services in a confidential matter
regarding money transfer.
This requires a private arrangement though the details of the
transaction will be furnished to you if you indicate your interest in
this proposal.We have all the legal documents
On 24.04.2018 00:01, Stefan Beller wrote:
Hi Git community,
This year we'll participate once again in Google Summer or Code!
We'll have 3 students and 3 mentors, which is more than in recent years.
Paul-Sebastian Ungureanu mentored by DScho, wants to convert git-stash
into a builtin.
Alban
The new "blocks" mode provides a middle ground between plain and zebra.
It is as intuitive (few colors) as plain, but still has the requirement
for a minimum of lines/characters to count a block as moved.
Suggested-by: Ævar Arnfjörð Bjarmason
In the original implementation of the move detection logic the choice for
ignoring white space changes is the same for the move detection as it is
for the regular diff. Some cases came up where different treatment would
have been nice.
Allow the user to specify that whitespace should be ignored
This makes the follow up patch easier.
Signed-off-by: Stefan Beller
---
diff.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index ce7bedc1b9..d1bae900cd 100644
--- a/diff.c
+++ b/diff.c
@@ -707,11 +707,15 @@ struct
These flags were there since the beginning (3443546f6e (Use a *real*
built-in diff generator, 2006-03-24), but were never used. Remove them.
Signed-off-by: Stefan Beller
---
xdiff/xdiff.h | 8
1 file changed, 8 deletions(-)
diff --git a/xdiff/xdiff.h
v2:
I think I have addressed Jonathans feedback
* by using a string instead of counting the first character only.
* refined tests slightly (easier to read)
* moved white space handling for moved blocks into its own flag field,
keeping the enum for the actual mode of move detection.
v1:
This is
There is no need to forward-declare these functions, as they are used
after their implementation only.
Signed-off-by: Stefan Beller
---
xdiff/xdiffi.c | 17 -
1 file changed, 17 deletions(-)
diff --git a/xdiff/xdiffi.c b/xdiff/xdiffi.c
index
When we initialize the hashmap, we give it a pointer to the
diff_options, which it then passes along to each call of the
hashmap_cmp_fn function. There's no need to pass it a second time as
the "keydata" parameter, and our comparison functions never look at
keydata.
This was a mistake left over
This marks moved code still as blocks when their indentation level
changes uniformly.
Signed-off-by: Stefan Beller
---
Documentation/diff-options.txt | 4 ++
diff.c | 83 +++---
diff.h | 2 +
On 4/24/2018 2:59 PM, Elijah Newren wrote:
Sorry, I noticed something else I missed on my last reading...
On Tue, Apr 24, 2018 at 10:11 AM, Ben Peart wrote:
diff --git a/builtin/merge.c b/builtin/merge.c
index 8746c5e3e8..3be52cd316 100644
--- a/builtin/merge.c
+++
---
t/t6046-merge-skip-unneeded-updates.sh | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/t/t6046-merge-skip-unneeded-updates.sh
b/t/t6046-merge-skip-unneeded-updates.sh
index 880cd782d7..fcefffcaec 100755
--- a/t/t6046-merge-skip-unneeded-updates.sh
+++
---
merge-recursive.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 1de8dc1c53..f2cbad4f10 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -3146,10 +3146,10 @@ int merge_trees(struct merge_options *o,
/*
If have a repository with a tag "v1.0.0" and I add a remote repository
which also has a tag "v1.0.0" tag is overwritten.
Google found [1] from 2011 and option 3 is what I'd like to see. Has it been
implemented and I just don't see it?
[1]:
Dear Sir/Madam.
Assalamu`Alaikum.
I am Dr mohammad ouattara, I have ($14.6 Million us dollars) to transfer into
your account,
I will send you more details about this deal and the procedures to follow when
I receive a positive response from you,
Have a great day,
Dr mohammad ouattara.
From: "Johannes Schindelin"
On Mon, 23 Apr 2018, Philip Oakley wrote:
From: "Johannes Schindelin" : Monday, April
23,
2018 1:03 PM
Subject: Re: [PATCH v8 06/16] sequencer: introduce the `merge` command
[...]
>
> > > label onto
> > >
>
Hi Philip,
On Sun, 22 Apr 2018, Philip Oakley wrote:
> From: "Johannes Schindelin"
> > Now that grafts are deprecated, we should start to assume that readers
> > have no idea what grafts are. So it makes more sense to describe the
> > "shallow" feature in terms of
Hi Eric,
On Sat, 21 Apr 2018, Eric Sunshine wrote:
> On Sat, Apr 21, 2018 at 5:48 AM, Johannes Schindelin
> wrote:
> > This option is intended to help with the transition away from the
> > now-deprecated graft file.
> >
> > Signed-off-by: Johannes Schindelin
Hi Johannes,
On Tue, Apr 24, 2018 at 11:51 AM, Johannes Schindelin
wrote:
>
> Oy vey. How many more mistakes can I introduce in one commit...
>
I ask this myself all the time, but Software is hard when not having
computer assisted checks. The test suite doesn't
Sorry, I noticed something else I missed on my last reading...
On Tue, Apr 24, 2018 at 10:11 AM, Ben Peart wrote:
> diff --git a/builtin/merge.c b/builtin/merge.c
> index 8746c5e3e8..3be52cd316 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -424,6 +424,7 @@
Derrick Stolee writes:
> On 4/18/2018 5:02 PM, Jakub Narebski wrote:
>> Derrick Stolee writes:
>>
>>> A commit A can reach a commit B only if the generation number of A
>>> is larger than the generation number of B. This condition allows
>>> significantly
On Tue, 24 Apr 2018 11:42:33 -0700
Brandon Williams wrote:
> On 04/24, Jonathan Tan wrote:
> > On Mon, 23 Apr 2018 16:43:27 -0700
> > Stefan Beller wrote:
> >
> > > This involves also adapting sha1_object_info_extended and a some
> > > internal functions
Hi Stefan,
On Mon, 23 Apr 2018, Stefan Beller wrote:
> On Fri, Apr 20, 2018 at 3:21 PM, Johannes Schindelin
> wrote:
> > @@ -250,27 +257,38 @@ static void import_object(struct object_id *oid, enum
> > object_type type,
> > - if (strbuf_read(, cmd.out,
On 04/24, Jonathan Tan wrote:
> On Mon, 23 Apr 2018 16:43:27 -0700
> Stefan Beller wrote:
>
> > This involves also adapting sha1_object_info_extended and a some
> > internal functions that are used to implement these. It all has to
> > happen in one patch, because of a single
On Tue, Apr 24, 2018 at 01:37:36AM -0400, Eric Sunshine wrote:
> On Tue, Apr 24, 2018 at 1:07 AM, Taylor Blau wrote:
> > Take advantage of 'git-grep(1)''s new option, '--column-number' in order
> > to teach Peff's 'git-jump' script how to jump to the correct column for
> > any
On Tue, Apr 24, 2018 at 03:13:55PM +0900, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
> > I think when we add features to git-grep we should be as close to GNU
> > grep as possible (e.g. not add this -m alias meaning something different
> > as in your v1), but if
On Mon, 23 Apr 2018 16:43:27 -0700
Stefan Beller wrote:
> This involves also adapting sha1_object_info_extended and a some
> internal functions that are used to implement these. It all has to
> happen in one patch, because of a single recursive chain of calls visits
> all
On Mon, 23 Apr 2018 16:43:23 -0700
Stefan Beller wrote:
> diff --git a/sha1_file.c b/sha1_file.c
> index 93f25c6c6a..b292e04fd3 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1307,7 +1307,8 @@ int oid_object_info_extended_the_repository(const
> struct object_id *oid,
On Mon, 23 Apr 2018 16:43:20 -0700
Stefan Beller wrote:
> Add a repository argument to allow the callers of oid_object_info
> to be more specific about which repository to handle. This is a small
> mechanical change; it doesn't change the implementation to handle
>
On Tue, Apr 24, 2018 at 10:11 AM, Ben Peart wrote:
> Add the ability to control rename detection for merge via a config setting.
Sweet, thanks for including the documentation updates.
I lean towards the side of the argument that says that since
merge.renameLimit
On Mon, Apr 23, 2018 at 7:09 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> This is a revamp of
>> https://public-inbox.org/git/20180416220955.46163-1-sbel...@google.com/
>>
>> Junio had some issue with that version, as it would collide config and
Hi Dscho,
On Tue, Apr 24, 2018 at 4:58 AM, Johannes Schindelin
wrote:
> Hi Junio,
>
> On Tue, 24 Apr 2018, Junio C Hamano wrote:
>
>> Yeah, but as opposed to passing "oh, let's see if we can get a
>> reasonable result without rename detection just this time" from the
Hi Ben,
On Tue, Apr 24, 2018 at 9:45 AM, Ben Peart wrote:
> On 4/20/2018 1:22 PM, Elijah Newren wrote:
>> On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart
>> wrote:
>>>
>>> Add the ability to control the aggressive flag passed to read-tree via a
>>> config
Add the ability to control rename detection for merge via a config setting.
Reviewed-by: Johannes Schindelin
Signed-off-by: Ben Peart
---
Documentation/diff-config.txt | 3 ++-
Documentation/merge-config.txt | 8 +++-
Add the ability to control the aggressive flag passed to read-tree via a config
setting.
Reviewed-by: Johannes Schindelin
Signed-off-by: Ben Peart
---
Documentation/merge-config.txt | 4
merge-recursive.c | 1 +
2 files
Updated in response to feedback. Mostly documentation changes but the diffstat
at the end of the merge (if on) now honors the new merge.rename setting as well.
Base Ref: master
Web-Diff: https://github.com/benpeart/git/commit/653bfe6e01
Checkout: git fetch https://github.com/benpeart/git
In modern setups, less, the pager, uses alternate screen to show
the content. When it is closed, it switches back to the original
screen, and all content is gone.
It is not uncommon to request that the output remains visible in
the terminal. For this, the option --no-pager can be used. But
it is
On 4/23/2018 5:32 PM, Eckhard Maaß wrote:
On Mon, Apr 23, 2018 at 09:15:09AM -0400, Ben Peart wrote:
In commit 2a2ac926547 when merge.renamelimit was added, it was decided to
have separate settings for merge and diff to give users the ability to
control that behavior. In this particular
On 4/20/2018 1:22 PM, Elijah Newren wrote:
On Fri, Apr 20, 2018 at 6:36 AM, Ben Peart wrote:
Add the ability to control the aggressive flag passed to read-tree via a config
setting.
This feels like a workaround to the performance problems with index
updates in
On Mon, Apr 23, 2018 at 10:13 PM, Martin Ågren wrote:
> The strings allocated in `setup_unpack_trees_porcelain()` are never
> freed. Provide a function `clear_unpack_trees_porcelain()` to do so and
> call it in the functions which use `setup_unpack_trees_porcelain()`.
On Tue, Apr 24, 2018 at 6:12 PM, Duy Nguyen wrote:
> git-completion.bash will be updated to ask git "give me the commands
> in the mainporcelain, completable or external category". This also
> addresses another thing that bugs me: I wanted an option to let me
> complete all
On Mon, Apr 23, 2018 at 3:32 PM, SZEDER Gábor wrote:
> But then I noticed that it's not an accurate description of the
> current situation, because there is a wide grey area between
> porcelains and plumbing, and the completion script doesn't "filter out
> plumbing
Hi Junio,
On Tue, 24 Apr 2018, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Junio C Hamano writes:
> >
> >>> base-commit: b46fe60e1d7235603a29499822493bd3791195da
> >>
> >> Basing your work on the tip of 'next' is good for discussion, but
> >> not
On 2018-04-13 01:01 PM, Michał Górny wrote:
Currently git does not control mtimes of files being checked out. This
means that the only assumption you could make is that all files created
or modified within a single checkout action will have mtime between
start time and end time of this
On 4/23/2018 5:38 PM, Jakub Narebski wrote:
Derrick Stolee writes:
On 4/18/2018 7:19 PM, Jakub Narebski wrote:
Derrick Stolee writes:
[...]
[...], and this saves time during 'git branch --contains' queries
that would otherwise walk "around" the
Hi Junio,
On Tue, 24 Apr 2018, Junio C Hamano wrote:
> Ben Peart writes:
>
> >> I also had to wonder how "merge -s resolve" faired, if the project
> >> is not interested in renamed paths at all.
> >>
> >
> > To be clear, it isn't that we're not interested in detecting
Hi Martin,
On Tue, 24 Apr 2018, Martin Ågren wrote:
> On 24 April 2018 at 08:20, Jacob Keller wrote:
> > I'm guessing the diff algorithm simply found that this was a more
> > compact representation of the change? It's a bit confusing when your
> > description indicates
Hi Philip,
On Sun, 22 Apr 2018, Philip Oakley wrote:
> From: "Johannes Schindelin"
> > Once upon a time, this here developer thought: wouldn't it be nice if,
> > say, Git for Windows' patches on top of core Git could be represented as
> > a thicket of branches, and
Hi Christian,
Thank you for the reply.
After I got the reply from Szedar I was so excited about git community
passion for help. And your reply made me ever more assure in it.
Once again thank your for the comprehensive answer. I appreciate
Daniel German's research and going to try token based
Hi Szedar,
Thank you for the reply! I didn't expect it could be so instant!
I checked 'git log -L' option and it seems to the best one so far. But
nevertheless is has a pit fall: I run it like 'git log -L ,:somefile'
and get the output that needs manual scraping since each commit spans
the whole
On 24 April 2018 at 01:39, brian m. carlson
wrote:
> Convert two uses of EMPTY_TREE_SHA1_HEX to use oid_to_hex_r and
> the_hash_algo to avoid a dependency on a given hash algorithm. Use
> oid_to_hex_r in preference to oid_to_hex because the buffer needs to
> last
On 24 April 2018 at 01:39, brian m. carlson
wrote:
> Use the GIT_SHA1_RAWSZ and GIT_SHA1_HEXSZ macros instead of hard-coding
> the constants 20 and 40. Switch one use of 20 with a format specifier
> for a hex value to use the hex constant instead, as the original
On 24 April 2018 at 01:39, brian m. carlson
wrote:
> Use the_hash_algo to find the right size for parsing pack names.
>
> Signed-off-by: brian m. carlson
> ---
> http.c | 11 ++-
> 1 file changed, 6 insertions(+), 5
On 24 April 2018 at 01:39, brian m. carlson
wrote:
> The code for reading certain pack v2 offsets had a hard-coded 5
> representing the number of uint32_t words that we needed to skip over.
> Specify this value in terms of a value from the_hash_algo.
>
>
1 - 100 of 113 matches
Mail list logo