On Monday 07 May 2018 11:45 PM, Stefan Beller wrote:
>> I could see arguments both ways, so I thought I'd take a straw poll of
>> what people on the list think.
>
> Junios reply below focuses on the URL passed to git-clone, which
> is only found at https://git-scm.com/downloads (?)
>
> There I w
Am 05.05.2018 um 04:42 schrieb Taylor Blau:
> When calling match_line(), callers presently cannot determine the
> relative offset of the match because match_line() discards the
> 'regmatch_t' that contains this information.
>
> Instead, teach match_line() to take in a 'regmatch_t *' so that caller
Ilya Kantor writes:
> P.S. I assume, `cherry-pick -n ` is meant to merge given
> commits' changes into the current working directory and the index,
> without making new commits, for any given set of commits, hope that's right?
Hmph.
One step in cherry-pick should refuse to start when HEAD and t
Ævar Arnfjörð Bjarmason writes:
> > Tags need not be pointing at commits so there is no way to
> > guarantee "fast-forward" anyway.
The observation the above statement makes is not incorrect per-se,
but it does not justify "anything goes". "nothing is allowed unless
forced" is equally
Ævar Arnfjörð Bjarmason writes:
> +
> The is often the name of the branch you would want to push, but
> -it can be any arbitrary "SHA-1 expression", such as `master~4` or
> -`HEAD` (see linkgit:gitrevisions[7]).
> +it can be any arbitrary "SHA-1 expression" referring to a branch, such
> +as `
On Tuesday 08 May 2018 07:28 AM, brian m. carlson wrote:
> An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to
> individual persons", 2013-08-12), noted that there were two name
> spellings and two email addresses and mapped the crustytoothpaste.net
> address to the crustytoothpas
Ævar Arnfjörð Bjarmason writes:
> Change the test that asserts that lightweight tags can only be
> clobbered by a force-push to check do the same tests for annotated
> tags.
>
> There used to be less exhaustive tests for this with the code added in
> 40eff17999 ("push: require force for annotate
Nguyễn Thái Ngọc Duy writes:
> The help command currently hard codes the list of guides and their
> summary in C. Let's move this list to command-list.txt. This lets us
> extract summary lines from Documentation/git*.txt. This also
> potentially lets us list guides in git.txt, but I'll leave tha
Nguyễn Thái Ngọc Duy writes:
> This allows us to select any group of commands by a category defined
> in command-list.txt. This is an internal/hidden option so we don't
> have to be picky about the category name or worried about exposing too
> much.
>
> This will be used later by git-completion.
On Fri, May 04, 2018 at 12:48:21AM +0300, Paul-Sebastian Ungureanu wrote:
> Hello everybody,
>
> The community bonding period started. It is well known that for a greater
> rate of success, it is recommended to send weekly reports regarding project
> status. But, what would be a good form for such
Nguyễn Thái Ngọc Duy writes:
> Even if these are hidden options, let's make them a bit more generic
> since we're introducing more listing types shortly. The code is
> structured to allow combining multiple listing types together because
> we will soon add more types the 'builtins'.
>
> 'parseop
On Mon, May 07, 2018 at 11:44:29PM -0400, Jeff King wrote:
> On Mon, May 07, 2018 at 03:24:59PM -0700, Stefan Beller wrote:
>
> > Hence I propose "git range-diff", similar to topic-diff, that
> > was proposed earlier.
> >
> > * it "diffs ranges" of commits.
> > * it can also deal with out-of-git
Nguyễn Thái Ngọc Duy writes:
> The current generate-cmds.sh generates just enough to print "git help"
> output. That is, it only extracts help text for common commands.
>
> The script is now updated to extract help text for all commands and
> keep command classification a new file, command-list.
On Mon, May 07, 2018 at 03:24:59PM -0700, Stefan Beller wrote:
> Hence I propose "git range-diff", similar to topic-diff, that
> was proposed earlier.
>
> * it "diffs ranges" of commits.
> * it can also deal with out-of-git things like patch series,
> but that is a mere by product and may not b
Todd Zullinger writes:
> Hi Matthew,
>
> Matthew Coleman wrote:
>> I haven't seen any discussion about this recently. What
>> are the chances of getting it merged? I'd like to see this
>> included in 2.18.
>
> Junio's last few "What's cooking" updates have mentioned it:
>
>> * sg/completion-clear
Konstantin Ryabitsev writes:
> On Tue, May 08, 2018 at 01:51:30AM +, brian m. carlson wrote:
>>
>> I think I would also prefer a list of available repositories over a
>> hard-coded choice. It may be that some places (say, Australia) have
>> better bandwidth to one over the other, and users w
"brian m. carlson" writes:
> An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to
> individual persons", 2013-08-12), noted that there were two name
> spellings and two email addresses and mapped the crustytoothpaste.net
> address to the crustytoothpaste.ath.cx address. The latt
Junio C Hamano writes:
> I couldn't quite get what you meant by "(but not the other way
> around)". Did you mean
>
> $ git push --force ../child2 refs/tags/*:refs/tags/*
>
> should not become non-forcing version because of the (lack of)
> prefix on the refspec does not trump the --force co
On Tue, May 08, 2018 at 01:51:30AM +, brian m. carlson wrote:
> On Mon, May 07, 2018 at 11:15:46AM -0700, Stefan Beller wrote:
> > There I would try to mirror Junios list of "public repositories"
> > https://git-blame.blogspot.com/p/git-public-repositories.html
> > without officially endorsing
Ævar Arnfjörð Bjarmason writes:
> Improve the tests added in dbfeddb12e ("push: require force for refs
> under refs/tags/", 2012-11-29) to assert that the same behavior
> applies various forms other refspecs, and that "+" in a refspec will
> override the "--no-force" option (but not the other wa
On Tue, May 8, 2018 at 12:20 AM, Stefan Beller wrote:
> Hi Pratik,
Hi Stefan,
> On Sat, May 5, 2018 at 5:24 AM, Pratik Karki wrote:
>> On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote:
>>> Hi everybody,
>>>
>>> as my fellow students, I started a blog series about my GSoC project[1].
>>> First,
Hi Matthew,
Matthew Coleman wrote:
> I haven't seen any discussion about this recently. What
> are the chances of getting it merged? I'd like to see this
> included in 2.18.
Junio's last few "What's cooking" updates have mentioned it:
> * sg/completion-clear-cached (2018-04-18) 1 commit
> (mer
Hi Johannes,
Johannes Schindelin wrote:
> Hi Todd,
>
> On Sat, 5 May 2018, Todd Zullinger wrote:
>
>>> @@ -430,6 +451,8 @@ int cmd_branch_diff(int argc, const char **argv, const
>>> char *prefix)
>>> struct string_list branch1 = STRING_LIST_INIT_DUP;
>>> struct string_list branch2 = STR
An earlier change, cdb6b5ac (".mailmap: Combine more (name, email) to
individual persons", 2013-08-12), noted that there were two name
spellings and two email addresses and mapped the crustytoothpaste.net
address to the crustytoothpaste.ath.cx address. The latter is an older,
obsolete address, whi
On Mon, May 07, 2018 at 11:15:46AM -0700, Stefan Beller wrote:
> There I would try to mirror Junios list of "public repositories"
> https://git-blame.blogspot.com/p/git-public-repositories.html
> without officially endorsing one over another.
I think I would also prefer a list of available reposit
On Mon, May 07, 2018 at 06:11:43AM +0200, Martin Ågren wrote:
> On 6 May 2018 at 22:42, brian m. carlson wrote:
> > When creating a literal block from an indented block without any sort of
> > delimiters, Asciidoctor strips off all leading whitespace, resulting in
> > a misrendered chart. Use an
Stefan Beller writes:
> The replacement with mem-pool might be easier than making sure
> that alloc.c has no globals and handles allocations per repository
> correctly. It would make the sb/object-store-alloc series shorter than
> it currently is, and maybe easier to review the code.
>
> However
Elijah Newren writes:
>> Rename detection logic in "diff" family that is used in "merge" has
>> learned to guess when all of x/a, x/b and x/c have moved to z/a,
>> z/b and z/c, it is likely that x/d added in the meantime would also
>> want to move to z/d by taking the hint that the entire dir
Elijah Newren writes:
> I'm actually curious what the "Will merge to 'master'" and "Will merge
> to 'next'" are intended to mean in general. I thought it meant that
> the topic would be merged the following week barring further
> discussion, but that hasn't always been the case ...
These have a
On Mon, May 7, 2018 at 5:37 PM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>>> So I think we could just replace it for now and optimize again later, if it
>>> turns out to be a problem. I think the easiest optimisation is to increase
>>> the allocation size of having a lot more objects per mp_b
Duy Nguyen writes:
>> So I think we could just replace it for now and optimize again later, if it
>> turns out to be a problem. I think the easiest optimisation is to increase
>> the allocation size of having a lot more objects per mp_block.
>
> Yeah. I also tested this from a different angle: me
Jeff King writes:
> One of the things I don't like about "git branch --diff" is that this
> feature is not _just_ about branches at all.
I actually wouldn't be that much against the word "branch" in
"branch-diff" on the ground that we are typically not feeding
branches to the command (we are fee
On Sat, May 05, 2018 at 03:36:12AM -0400, Eric Sunshine wrote:
> On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote:
> > Teach GNU grep(1)'s '-o' ('--only-matching') to 'git-grep'. This option
> > prints only the matching components of each line. It writes multiple
> > lines if more than one match
On Sat, May 05, 2018 at 03:30:51AM -0400, Eric Sunshine wrote:
> On Sat, May 5, 2018 at 12:03 AM, Taylor Blau wrote:
> > Teach 'git-grep(1)' how to print a line header multiple times from
> > show_line() in preparation for it learning '--only-matching'.
> >
> > show_line_header() comprises of the
On Mon, May 07, 2018 at 11:13:12PM +0900, Junio C Hamano wrote:
> Taylor Blau writes:
>
> > diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
> > index 18b494731f..5409a24399 100644
> > --- a/Documentation/git-grep.txt
> > +++ b/Documentation/git-grep.txt
> > @@ -13,7 +13,7 @@ S
On Mon, May 07, 2018 at 12:25:09PM -0700, Stefan Beller wrote:
> brian,
>
> sorry to break you there. I was the author of the patch Junio found,
> organizing
> the .mailmap file was one of my starter contributions. I recall asking all the
> people if they were ok with it their names combined in d
On Mon, May 07, 2018 at 12:37:05PM +0900, Junio C Hamano wrote:
> I initially reacted to "was reversed" with "yikes, did we break the
> mailmap reader and we need to update the file?", but apparently that
> is not what this patch is about. I think what is happening here is
> that cdb6b5ac (".mailm
On Mon, May 07, 2018 at 12:24:13PM +0200, Martin Ågren wrote:
> This could be more centralized at the top of the file, more likely to be
> noticed during a `make test` and easier to adapt in the future. Maybe
> something like this at the top of the file:
>
> if hash for storage is SHA-1 then
>
On Sun, May 06, 2018 at 07:56:42PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Sat, May 05 2018, Taylor Blau wrote:
>
>
> > + test_expect_success "grep -w $L (with --{line,column}-number)" '
>
> It's now --column in v4 but this still refers to v3 --column-number.
Thanks, I certainly missed this
Hi Stefan,
On 08/05/2018 00:24, Stefan Beller wrote:
>
> > List, rename, delete -- all these seem more as basic CRUD operations,
> > where comparison is a more complex one. And not to get me wrong - I
> > could see "branch diff" being part of "branch", but not really when
> > "diff" already exist
On Sat, May 05, 2018 at 08:15:03AM +0200, Duy Nguyen wrote:
> On Sat, May 5, 2018 at 4:43 AM, Taylor Blau wrote:
> > Teach 'git-grep(1)' a new option, '--column', to show the column
> > number of the first match on a non-context line.
>
> Why? Or put it another way, what is this option used for? O
On Sun, May 06, 2018 at 08:03:01PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Sun, May 06 2018, Martin Ågren wrote:
>
> > On 5 May 2018 at 04:43, Taylor Blau wrote:
> >> Take advantage of 'git-grep(1)''s new option, '--column' in order to
> >> teach Peff's 'git-jump' script how to jump to the co
On Mon, May 07, 2018 at 12:10:39PM +0200, Martin Ågren wrote:
> On 7 May 2018 at 01:17, brian m. carlson wrote:
> > Add an SHA1 prerequisite to annotate both of these types of tests and
> > disable them when we're using a different hash. In the future, we can
> > create versions of these tests wh
On Mon, May 07, 2018 at 05:45:00AM -0400, Jeff King wrote:
> Isn't that basically what this patch is, though? Or at least a step in
> that direction? For generic signing support, you need:
>
> 1. A way to tell Git to recognize that a signature exists, and what
> type it is.
>
> 2. A way
This is a small mechanical change; it doesn't change the
implementation to handle repositories other than the_repository yet.
Use a macro to catch callers passing a repository other than
the_repository at compile time.
Signed-off-by: Stefan Beller
---
alloc.c | 2 +-
cache.h | 3 ++-
2 files cha
This is a small mechanical change; it doesn't change the
implementation to handle repositories other than the_repository yet.
Use a macro to catch callers passing a repository other than
the_repository at compile time.
Signed-off-by: Stefan Beller
---
alloc.c | 2 +-
cache.h | 3 ++-
tag.c | 2
Convert the existing global cache for parsed objects (obj_hash) into
repository-specific parsed object caches. Existing code that uses
obj_hash are modified to use the parsed object cache of
the_repository; future patches will use the parsed object caches of
other repositories.
Another future use
This is a small mechanical change; it doesn't change the
implementation to handle repositories other than the_repository yet.
Use a macro to catch callers passing a repository other than
the_repository at compile time.
Signed-off-by: Stefan Beller
---
alloc.c | 2 +-
blame.c
This is a small mechanical change; it doesn't change the
implementation to handle repositories other than the_repository yet.
Use a macro to catch callers passing a repository other than
the_repository at compile time.
Signed-off-by: Stefan Beller
---
alloc.c | 2 +-
cache.h | 3 ++-
tree.c | 2
We have to convert all of the alloc functions at once, because alloc_report
uses a funky macro for reporting. It is better for the sake of mechanical
conversion to convert multiple functions at once rather than changing the
structure of the reporting function.
We record all memory allocation in al
Add a repository argument to allow the callers of create_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.
Signed-off-by: Jonathan Nieder
Signed-off-by: Stefan
Reviewed-by: Jonathan Tan
Signed-off-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
object.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/object.c b/object.c
index a365a910859..0fcd6f6df42 100644
--- a/object.c
+++ b/object.c
@@ -116,27 +116,27 @@ s
This is a small mechanical change; it doesn't change the
implementation to handle repositories other than the_repository yet.
Use a macro to catch callers passing a repository other than
the_repository at compile time.
Signed-off-by: Stefan Beller
---
alloc.c | 2 +-
cache.h | 3 ++-
object.c
Reviewed-by: Jonathan Tan
Signed-off-by: Jonathan Nieder
Signed-off-by: Stefan Beller
---
object.c | 12 ++--
object.h | 3 +--
2 files changed, 7 insertions(+), 8 deletions(-)
diff --git a/object.c b/object.c
index 0fcd6f6df42..49b952e9299 100644
--- a/object.c
+++ b/object.c
@@ -139
This is a small mechanical change; it doesn't change the
implementation to handle repositories other than the_repository yet.
Use a macro to catch callers passing a repository other than
the_repository at compile time.
Signed-off-by: Stefan Beller
---
alloc.c | 4 ++--
cache.h | 3 ++-
object.
v2:
* I decided to stick with alloc.c and not migrate it to the mem-pool for now.
The reasoning for that is that mem-pool.h would introduce some alignment
waste, which I really did not want to.
* renamed to struct parsed_object_pool;
* free'd the additional memory of trees and commits.
* do not
This is a small mechanical change; it doesn't change the
implementation to handle repositories other than the_repository yet.
Use a macro to catch callers passing a repository other than
the_repository at compile time.
Signed-off-by: Stefan Beller
---
alloc.c | 2 +-
blob.c | 2 +-
cache.h | 3
From: Jonathan Nieder
Add a repository argument to allow the caller of grow_object_hash 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.
Signed-off-by: Jonathan Nied
On Mon, May 7, 2018 at 3:05 PM, Igor Djordjevic
wrote:
> List, rename, delete -- all these seem more as basic CRUD operations,
> where comparison is a more complex one. And not to get me wrong - I
> could see "branch diff" being part of "branch", but not really when
> "diff" already exists as a s
Hi Dscho,
On 07/05/2018 03:34, Johannes Schindelin wrote:
>
> > > I think Todd's idea to shift it from a full-blown builtin to a cmdmode
> > > of `branch` makes tons of sense.
> >
> > I don`t know, I still find it a bit strange that in order to "diff
> > something", you go to "something" and tell
On 07/05/2018 09:48, Jeff King wrote:
>
> > > Let's, please, not fall into the trap of polluting git-branch with
> > > utterly unrelated functionality, as has happened a few times with
> > > other Git commands. Let's especially not do so merely for the sake of
> > > tab-completion. git-branch is f
On 7 May 2018 at 17:24, Duy Nguyen wrote:
> On Sun, May 6, 2018 at 9:32 PM, Martin Ågren wrote:
>> On 6 May 2018 at 19:42, Duy Nguyen wrote:
>> Thank you Duy for your comments. How about I write the commit message
>> like so:
>
> +Jeff. Since he made it possible to remove lock file from the glob
Hi Junio,
On Mon, May 7, 2018 at 7:05 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> This applies on top of sb/oid-object-info and is the logical continuum of
>> the series that it builds on; this brings the object store into more of
>> Gits code, removing global state, such that reasoni
On Mon, May 7, 2018 at 8:28 AM, Duy Nguyen wrote:
>>> I do hear you. Especially since I hate `git cherry` every single time that
>>> I try to tab-complete `git cherry-pick`.
>>
>> Me too. :)
>
> Just so you know I'm also not happy with that "git cherry". Since I'm
> updating git-completion.bash i
Dearest,
I am Sister Renee Shine, I contacted you regards to the total sum of(3
million USD) which I signed and donated in your custody as the
beneficiary,I was diagnosed with the cancer of the esophagus it has
defied all forms of medical treatment and at this point i have few
weeks to live accord
On Sun, May 6, 2018 at 8:37 PM, Junio C Hamano wrote:
> "brian m. carlson" writes:
>
>> The order of addresses in the mailmap file was reversed, leading to git
>> preferring the crustytoothpaste.ath.cx address, which is obsolete, over
>> the crustytoothpaste.net address, which is current. Switch
On Sun, May 6, 2018 at 11:10 AM, Kaartic Sivaraam
wrote:
> I recently faced the consequence of the weak option parsing done by in
> `git submodule`. Initially tried to add a new submodule using the `git
> submodule add` sub-command in the following way,
>
> $ git submodule add ./foo/bar
>
> Th
+cc Michael, who did extensive work in the refs.c code.
On Sun, May 6, 2018 at 7:10 AM, Martin Ågren wrote:
> If we could not take the lock, we add an error to the `strbuf err` and
> return. However, this code is dead. The reason is that we take the lock
> using `LOCK_DIE_ON_ERROR`. Drop the flag
On Mon, May 7, 2018 at 10:50 AM, SZEDER Gábor wrote:
>> 2) Your completion commands for branch-diff will only complete one
>> revision range, not two. e.g.
>> git branch-diff origin/master..my-topic@{2} origin/master..my-top
>> won't complete "my-topic" as I'd expect.
>
> It does complete two
Hi Pratik,
On Sat, May 5, 2018 at 5:24 AM, Pratik Karki wrote:
> On Sat, May 5, 2018 at 5:11 PM, Alban Gruin wrote:
>> Hi everybody,
>>
>> as my fellow students, I started a blog series about my GSoC project[1].
>> First, I wanted to post them directly on the mailing list, but a blog
>> allows m
On May 6, 2018 9:56:31 AM MDT, "Martin Ågren" wrote:
>On 6 May 2018 at 17:48, David Turner wrote:
>> On Sun, 2018-05-06 at 16:10 +0200, Martin Ågren wrote:
>>> While at it, make the lock non-static.
>
>> Re making the lock static, I wonder about the following case:
>>
>> if (read_ref(pseu
Hi Jeff,
On Sun, May 6, 2018 at 11:37 PM, Jeff King wrote:
> The git-scm.com site currently links to https://github.com/git/git for
> the (non-tarball) source code. Somebody raised the question[1] of
> whether it should point to kernel.org instead. Do people find one
> interface more or less plea
The previous commit added code generation for all_cmd_desc[] which
includes almost everything we need to generate common command list.
Convert help code to use that array instead and drop common_cmds[] array.
The description of each common command group is removed from
command-list.txt. This keeps
This allows us to select any group of commands by a category defined
in command-list.txt. This is an internal/hidden option so we don't
have to be picky about the category name or worried about exposing too
much.
This will be used later by git-completion.bash to retrieve certain
command groups.
--
This is intended to help anybody who needs to update command-list.txt.
It gives a brief introduction of all attributes a command can take.
---
command-list.txt | 44
1 file changed, 44 insertions(+)
diff --git a/command-list.txt b/command-list.txt
inde
The help command currently hard codes the list of guides and their
summary in C. Let's move this list to command-list.txt. This lets us
extract summary lines from Documentation/git*.txt. This also
potentially lets us list guides in git.txt, but I'll leave that for
now.
---
Documentation/gitattribu
By default we show porcelain, external commands and a couple others
that are also popular. If you are not happy with this list, you can
now customize it. See the big comment block for details.
PS. perhaps I should make aliases a group too, which makes it possible
to _not_ complete aliases by omitt
The current generate-cmds.sh generates just enough to print "git help"
output. That is, it only extracts help text for common commands.
The script is now updated to extract help text for all commands and
keep command classification a new file, command-list.h. This will be
useful later:
- "git hel
After the last patch, common-cmds.h is no longer used (and it was
actually broken). Remove all related code. command-list.h will take
its place from now on.
---
.gitignore | 1 -
Makefile| 17 ++---
generate-cmdlist.sh | 46 +++-
Instead of parsing "git help -a" output, which is tricky to get right,
less elegant and also slow, make git provide the list in a
machine-friendly form. This adds two separate listing types, main and
others, instead of just "all" for more flexibility.
---
contrib/completion/git-completion.bash |
Even if these are hidden options, let's make them a bit more generic
since we're introducing more listing types shortly. The code is
structured to allow combining multiple listing types together because
we will soon add more types the 'builtins'.
'parseopt' remains separate because it has separate
Instead of maintaining a separate list of command classification,
which often could go out of date, let's centralize the information
back in git.
While the function in git-completion.bash implies "list porcelain
commands", that's not exactly what it does. It gets all commands (aka
--list-cmds=main
Instead of printing the command directly one by one, keep them in a
list and print at the end. This allows more modification before we
print out (e.g. sorting, removing duplicates or even excluding some
items).
---
git.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
This lists all recognized commands [1] by category. The group order
follows closely git.txt.
[1] We may actually show commands that are not built (e.g. if you set
NO_PERL you don't have git-instaweb but it's still listed here). I
ignore the problem because on Linux a git package could be split
any
v6 is now "feature complete". v6 adds
- documentation in command-list.txt so people know how to update it
- support for config key completion.commands, which consists
of extra commands. It could also be used for excluding some
commands.
Interdiff
diff --git a/command-list.txt b/command-list.
This makes it easier to reuse the same code in another place (very
soon).
---
generate-cmdlist.sh | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index eeea4b67ea..31b6d886cb 100755
--- a/generate-cmdlist.sh
+++ b/ge
> 2) Your completion commands for branch-diff will only complete one
> revision range, not two. e.g.
> git branch-diff origin/master..my-topic@{2} origin/master..my-top
> won't complete "my-topic" as I'd expect.
It does complete two revision ranges, but if you want to look at
reflogs, then yo
Hi Dscho,
On Sat, May 5, 2018 at 1:03 PM, Johannes Schindelin
wrote:
> Hi Elijah,
>
> On Fri, 4 May 2018, Elijah Newren wrote:
>
>> - tbdiff aligned output columns better when there were more than 9
>> patches (I'll comment more on patch 09/18)
>
> I added a new patch to align the patch numbers
Hello,
On 06.05.2018 16:22, Kaartic Sivaraam wrote:
The blog looks pretty well written. I also read your proposal. It also
seems to be pretty much well written. I like the way you explain things.
Particularly, you seem to be explaining the problem and the way you're
about to approach it well. Th
Hi,
On Mon, May 7, 2018 at 8:20 AM, Derrick Stolee wrote:
> On 5/7/2018 10:58 AM, Junio C Hamano wrote:
>> Will merge to 'master'.
>
> These have been queued for master for a few weeks. Is anything delaying
> them?
I'm actually curious what the "Will merge to 'master'" and "Will merge
to 'nex
Hi Junio,
On Mon, May 7, 2018 at 7:58 AM, Junio C Hamano wrote:
> * en/rename-directory-detection-reboot (2018-04-25) 36 commits
> - merge-recursive: fix check for skipability of working tree updates
> - merge-recursive: make "Auto-merging" comment show for other merges
> - merge-recursive: fi
---
merge-recursive.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/merge-recursive.c b/merge-recursive.c
index 5f42c677d5..9b9a4b8213 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -1851,7 +1851,7 @@ static struct hashmap *get_directory_renames(struct
diff_qu
On Mon, May 7, 2018 at 9:50 AM, Jeff King wrote:
> On Sat, May 05, 2018 at 11:57:26PM +0200, Johannes Schindelin wrote:
>
>> > It feels really petty complaining about the name, but I just want to
>> > raise the point, since it will never be easier to change than right now.
>>
>> I do hear you. Esp
On Sun, May 6, 2018 at 9:32 PM, Martin Ågren wrote:
> On 6 May 2018 at 19:42, Duy Nguyen wrote:
>> On Sun, May 6, 2018 at 7:26 PM, Duy Nguyen wrote:
>>> On Sun, May 6, 2018 at 4:10 PM, Martin Ågren wrote:
These `struct lock_file`s are local to their respective functions and we
can dro
Hi guys,
I am going to try and build the OpenSSL and Git locally.
Search brought me here:
https://wiki.openssl.org/index.php/Compilation_and_Installation#OS_X.
Which options do I absolutely have to have for configuring OpenSSL?
Should I exclude "no--ssl2"? "no-ssl3"?
Thank you.
On Mon, Apr 23,
On 5/7/2018 10:58 AM, Junio C Hamano wrote:
* ds/generation-numbers (2018-05-02) 11 commits
- commit-graph.txt: update design document
- merge: check config before loading commits
- commit: use generation number in remove_redundant()
- commit: add short-circuit to paint_down_to_common()
Jeff King writes:
> On Tue, Apr 17, 2018 at 12:12:12AM +, brian m. carlson wrote:
>
>> > That argues more strongly that we would regret unless we make the
>> > end-user configuration to at least the whole string (which later can
>> > be promoted to "a pattern that matches the whole string"),
Johannes Schindelin writes:
> It would be easy to introduce, but I am wary about its usefulness.
> Unless you re-generate the branch from patches (which I guess you do a
> lot, but I don't), you are likely to compare incomplete patch series: say,
> when you call `git rebase -i` to reword 05/18's
I haven't seen any discussion about this recently. What are the chances of
getting it merged? I'd like to see this included in 2.18.
>> To get the names of all '$__git_builtin_*' variables caching --options
>> of builtin commands in order to unset them, 8b0eaa41f2 (completion:
>> clear cached --o
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 any of
the integration branches, but I am still holding onto them.
You can find the changes described
1 - 100 of 125 matches
Mail list logo
