On Mon, Feb 12, 2018 at 10:55 PM, Eric Sunshine wrote:
> On Mon, Feb 12, 2018 at 8:41 PM, Stefan Beller wrote:
>> + * Output the formatted string in the specified color (and then reset to
>> normal
>> + * color so subsequent output is uncolored). Omits the color encapsulation
>> if
>> + * `colo
Johannes Schindelin writes:
[...]
> Just to give you one concrete example: when I recently rebased some
> patches (no reording or dropping involved here!) and one of the picks
> failed with merge conflicts, I realized that that particular commit
> introduced incorrect formatting and fixed that rig
I have a git repo with large submodules, notably the Linux kernel, and
shallow clone saves a lot of time.
However, QEMU is also a submodule, which I don't control, and QEMU has
submodules which don't point to commits that are not on any tag or
branch, so:
git clone --recurse-submodules --shallow
When using git-subtree with --squash option, you may not have commits
indicated by git-subtree-split: at hand.
find_existing_splits dies on such situation, but the caller cmd_split
ignored it and produce unwanted output, i.e. a history that does not
contain commits from subproject. This patch fixe
On Tue, Feb 13, 2018 at 07:27:58AM +0700, Duy Nguyen wrote:
> > Makes sense to try to make sure that we don't regress leak-free tests. I
> > don't know what our Travis-budget looks like, but I would volunteer to
> > run something like this periodically using my own cycles.
> >
> > My experience w
On 02/14/2018 02:35 AM, Jeff King wrote:
> On Sat, Feb 10, 2018 at 07:36:47PM +0100, Leo Gaspard wrote:
>> [...]
> I think there may have been some more concrete proposals after that, but
> that's what I was able to dig up quickly.
Thanks! Though it looks way above my knowledge of git internals as
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
On Sat, Feb 10, 2018 at 4:21 AM, Jeff King wrote:
> On Sat, Feb 10, 2018 at 01:37:20AM +0100, Leo Gaspard wrote:
>
>> > Yeah, tag-following may be a little tricky, because it usually wants to
>> > write to refs/tags/. One workaround would be to have your config look
>> > like this:
>> >
>> > [re
On Mon, Feb 12, 2018 at 11:23:27AM -0800, Brandon Williams wrote:
> Maybe this isn't helpful but you may be able to implement this by using
> a remote-helper. The helper could perform any sort of caching it needed
> to prevent re-downloading large amounts of data that is potentially
> thrown away
On Mon, Feb 12, 2018 at 11:15 PM, Sergey Organov wrote:
> Hi Jake,
>
> Jacob Keller writes:
>
>> On Mon, Feb 12, 2018 at 12:39 PM, Johannes Schindelin
>> wrote:
>>> Hi Sergey,
>>>
>>> On Mon, 12 Feb 2018, Sergey Organov wrote:
> Have a look at https://github.com/git/git/pull/447, especially
On Sat, Feb 10, 2018 at 07:36:47PM +0100, Leo Gaspard wrote:
> Hmm... would this also drown the remote..fetch map? Also, I think
> this behavior could be emulated with fetch and fetchTagsTo, and it would
> look like:
> [remote "my-remote"]
> fetch = +refs/heads/*:refs/remotes/my-remote/heads/*
René Scharfe writes:
> A short semantic patch with a limited time of usefulness and possible
> side-effects can easily be included in a commit message, of course..
Yeah, I think that is Jonathan's favourite approach as well, and I
do not have problem with that. This transition spatch is unlike
On Wed, Feb 14, 2018 at 12:57 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> It's very tempting considering that the amount of changes is much
>> smaller. But I think we should go with my version. The hope is when a
>> _new_ call site appears, the author would think twice before passing
>> z
On Wed, Feb 14, 2018 at 2:26 AM, Jonathan Nieder wrote:
>> Duy suggested that we shall not use the repository blindly, but should
>> carefully
>> examine whether to pass on an object store or the refstore or such[4], which
>> I agree with if it makes sense. This series unfortunately has an issue
On Tue, Feb 13, 2018 at 8:22 AM, Stefan Beller wrote:
> Signed-off-by: Stefan Beller
> ---
> object-store.h | 3 +--
> sha1_file.c| 21 +++--
> 2 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/object-store.h b/object-store.h
> index d96a16edd1..add1d4e27c
Stefan Beller writes:
> Which is why I'd strongly consider having it only in the repository
> object as that is the largest-scoped thing we'd want. e.g. submodules
> should care about environment variables differently:
>
> GIT_WORK_TREE=~/mysuperproject git checkout \
> --recurse-
also just noticed the following:
Documentation/RelNotes/2.13.0.txt:489: * A few commands that recently learned
the "--recurse-submodule"
Documentation/RelNotes/2.12.0.txt:226: * "git push --dry-run
--recurse-submodule=on-demand" wasn't
Documentation/RelNotes/2.11.1.txt:27: * "git push --dry-r
--
This is Mrs. Emile Kenold a missionary contacting you from London. I
pray you will be kind enough to deliver my £7 million pounds donation
to the less privileged ones in your country and God will bless your
generation for doing this humanitarian work.
I am a widow suffering of lung cancer whic
Hello dear how are you?
Nice to meet you,my name is Miss Nadege Yann, can we become friends? hope to
hear from you so that we can know each other very well, love matters mostly in
life,i will also send you my pictures and tell you more about myself, my email
address is(missnade...@gmail.com)
w
On Thu, 8 Feb 2018 15:37:35 -0500
Derrick Stolee wrote:
> | Command | Before | After | Rel % |
> |--|||---|
> | log --oneline --topo-order -1000 | 5.9s | 0.7s | -88% |
> | branch -vv | 0.42s
There are a small number of misspellings, ".gitmodule", scattered
throughout the code base, correct them ... no apparent functional
changes.
Documentation/technical/api-submodule-config.txt | 2 +-
contrib/subtree/git-subtree.txt | 2 +-
submodule-config.c
On Tue, Feb 13, 2018 at 10:44:04AM +, Phillip Wood wrote:
> From: Phillip Wood
>
> While working on a patch series to stage selected lines from a hunk
> without having to edit it I got worried that subsequent patches would
> be applied in the wrong place which lead to this series to correct t
On Tue, Feb 13, 2018 at 3:33 PM, Robert P. J. Day wrote:
>
> There are a small number of misspellings, ".gitmodule", scattered
> throughout the code base, correct them ... no apparent functional
> changes.
Thanks for catching these!
> Documentation/technical/api-submodule-config.txt | 2 +-
>
This fixes a (probably harmless) parsing problem in
sq_dequote_step(), in which we parse some bogus input
incorrectly rather than complaining that it's bogus.
Our shell-dequoting function is very strict: it can unquote
everything generated by sq_quote(), but not arbitrary
strings. In particular, i
There are a small number of misspellings, ".gitmodule", scattered
throughout the code base, correct them ... no apparent functional
changes.
Documentation/technical/api-submodule-config.txt | 2 +-
contrib/subtree/git-subtree.txt | 2 +-
submodule-config.c
On Thu, 8 Feb 2018 15:37:32 -0500
Derrick Stolee wrote:
> Teach Git to delete the current 'graph_head' file and the commit graph
> it references. This is a good safety valve if somehow the file is
> corrupted and needs to be recalculated. Since the commit graph is a
> summary of contents already
On Tue, Feb 13, 2018 at 7:25 PM, Σπύρος Βαζαίος wrote:
> While I din't have the experience to express an opinion on this
> matter, I have to say that the --no-indent-heuristic that Jeff
> suggested worked great.
> There were more than a handful of cases that this issue happened in my
> diff file (
On Thu, 8 Feb 2018 15:37:31 -0500
Derrick Stolee wrote:
> It is possible to have multiple commit graph files in a pack directory,
> but only one is important at a time. Use a 'graph_head' file to point
> to the important file. Teach git-commit-graph to write 'graph_head' upon
> writing a new com
Using strace I noticed that git-revert invokes only two hooks:
- prepare-commit-msg
- post-commit
But git-commit invoke these four:
- pre-commit
- prepare-commit-msg
- commit-msg
- post-commit
Since git-revert produces a commit, why doesn't it invoke the same
hooks as git-commit?
I couldn't find
On Tue, Feb 13, 2018 at 01:36:01AM +0100, SZEDER Gábor wrote:
> 'git for-each-ref' should error out when invoked with more than one
> quoting style options. The tests checking this have two issues:
>
> - They run 'git for-each-ref' upstream of a pipe, hiding its exit
> code, thus don't act
On Thu, 8 Feb 2018 15:37:29 -0500
Derrick Stolee wrote:
> +test_expect_success 'setup full repo' '
> + rm -rf .git &&
> + mkdir full &&
> + cd full &&
> + git init &&
> + packdir=".git/objects/pack"'
Thanks for simplifying the repo generated in the test. One more style
nit:
On Tue, Feb 13, 2018 at 12:22 PM, Psidium Guajava wrote:
> Hello git community,
>
> I'd like to add a new feature in git-rebase: --undo-skip.
> But first, I'd like to consult with the experts if it would be
> beneficial for the project and if my line of tought is correct.
>
> Imagine that you are
Phillip Wood writes:
> From: Phillip Wood
>
> When a hunk is skipped by add -i the offsets of subsequent hunks are
> not adjusted to account for any missing insertions due to the skipped
> hunk. Most of the time this does not matter as apply uses the context
> lines to apply the subsequent hunks
Hello git community,
I'd like to add a new feature in git-rebase: --undo-skip.
But first, I'd like to consult with the experts if it would be
beneficial for the project and if my line of tought is correct.
Imagine that you are working on a feature for a long time, but there
are multiple bug fixes
On Tue, 13 Feb 2018 11:57:16 -0800
Junio C Hamano wrote:
> Jonathan Tan writes:
>
> > Updates from v1:
> > - use uint32_t so that we can operate on packfiles of up to 4G objects
> >(this also means that I had to change the signature of the function)
> > - don't hide types
> >
> > Derrick:
Jonathan Tan writes:
> Updates from v1:
> - use uint32_t so that we can operate on packfiles of up to 4G objects
>(this also means that I had to change the signature of the function)
> - don't hide types
>
> Derrick: you'll need to slightly change your patch to use the new API.
> As for fin
On Tue, Feb 13, 2018 at 10:51 AM, Brandon Williams wrote:
>> +#include "cache.h"
>> +
>
> Maybe we would want to move the definition of the alternate store to
> this header file? That way we don't need to include cache.h here.
>
Sounds good. I'll take a look at that.
Stefan
On Tue, Feb 13, 2018 at 10:52 AM, René Scharfe wrote:
> Am 12.02.2018 um 22:48 schrieb Junio C Hamano:
>> René Scharfe writes:
>>
>>> Am 12.02.2018 um 22:04 schrieb Junio C Hamano:
Stefan Beller writes:
> I thought it may be a helpful
> for merging this series with the rest of
On Tue, Feb 13, 2018 at 11:35 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> For now the ignore_env bit lives in the repository, as that helps
>> when working with submodules, when reading its comments.
>> Unfortunately 359efeffc1 (repository: introduce the repository
>> object, 2017-06-2
Stefan Beller writes:
> For now the ignore_env bit lives in the repository, as that helps
> when working with submodules, when reading its comments.
> Unfortunately 359efeffc1 (repository: introduce the repository
> object, 2017-06-22) did not reason about the existence of the ignore_env
> flag i
On 02/12, Stefan Beller wrote:
> This is a real take on the first part of the recent RFC[1].
>
> Jonathan Tan suggested[2] that "sha1_loose_object_info to handle arbitrary
> repositories"
> might be a good breaking point for a first part at that RFC at patch 38.
> This series is smaller and conta
Hi,
Stefan Beller wrote:
> This is a real take on the first part of the recent RFC[1].
>
> Jonathan Tan suggested[2] that "sha1_loose_object_info to handle arbitrary
> repositories"
> might be a good breaking point for a first part at that RFC at patch 38.
> This series is smaller and contains o
On Tue, Feb 13, 2018 at 10:57 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Oh, that is an interesting perspective. Here is how I arrived at the opposite
>> conclusion initially: Searching for 'ignore_env' shows that we care about it
>> as well for the index and graft paths, which are no
Stefan Beller writes:
> Oh, that is an interesting perspective. Here is how I arrived at the opposite
> conclusion initially: Searching for 'ignore_env' shows that we care about it
> as well for the index and graft paths, which are not the object store, hence
> it would be better kept in the repo
Am 12.02.2018 um 22:48 schrieb Junio C Hamano:
> René Scharfe writes:
>
>> Am 12.02.2018 um 22:04 schrieb Junio C Hamano:
>>> Stefan Beller writes:
>>>
I thought it may be a helpful
for merging this series with the rest of the evolved code base which
may make use of one of the con
On 2/13/2018 1:39 PM, Jonathan Tan wrote:
Updates from v1:
- use uint32_t so that we can operate on packfiles of up to 4G objects
(this also means that I had to change the signature of the function)
I take it "4G objects" means "4 billion objects". The distinction is
only important that
On 02/12, Stefan Beller wrote:
> In a process with multiple repositories open, alternates should be
> associated to a single repository and not shared globally. Move
> alt_odb_list and alt_odb_tail into the_repository and adjust callers
> to reflect this.
>
> Now that the alternative object data b
On Tue, 13 Feb 2018 02:23:52 +
"brian m. carlson" wrote:
> In the description of git interpret-trailers, we describe "a group…of
> lines" that have certain characteristics. Ensure both options
> describing this group use a singular verb for parallelism.
>
> Signed-off-by: brian m. carlson
Updates from v1:
- use uint32_t so that we can operate on packfiles of up to 4G objects
(this also means that I had to change the signature of the function)
- don't hide types
Derrick: you'll need to slightly change your patch to use the new API.
As for find_abbrev_len_for_pack(), that's a go
In commit 628522ec1439 ("sha1-lookup: more memory efficient search in
sorted list of SHA-1", 2008-04-09), a different algorithm for searching
a sorted list was introduced, together with a set of log statements
guarded by GIT_DEBUG_LOOKUP that are invoked both when using that
algorithm and when usin
Subsequent patches will introduce file formats that make use of a fanout
array and a sorted table containing hashes, just like packfiles.
Refactor the hash search in packfile.c into its own function, so that
those patches can make use of it as well.
Signed-off-by: Jonathan Tan
---
packfile.c
Hi guys,
While I din't have the experience to express an opinion on this
matter, I have to say that the --no-indent-heuristic that Jeff
suggested worked great.
There were more than a handful of cases that this issue happened in my
diff file (all were the same: #endif followed by #ifdef).
Oh, and t
On Tue, Feb 13, 2018 at 5:06 AM, Robert P. J. Day wrote:
>
> looking for general opinions ... i am (frighteningly :-) teaching a
> git course later this week, and one of the topics on the list is git
> submodules, which was specifically requested by the client as their
> idea of how to start inc
On Tue, Feb 13, 2018 at 8:08 AM, Jeff King wrote:
> On Tue, Feb 13, 2018 at 05:06:15PM +0200, Σπύρος Βαζαίος wrote:
>
>> Hi, I've came across an issue when using the git diff command. In
>> particular the diff is different to what the svn diff produces. While
>> both being correct the output of th
Jeff King writes:
> If I understand Gábor's patch correctly, it is using test_i18ngrep for
> the specific lines we care about so that we don't have to worry about
> other cruft lines that may or may not appear (including the hangup one).
>
> The downside is that we would not notice if a _new_ err
Duy Nguyen writes:
> It's very tempting considering that the amount of changes is much
> smaller. But I think we should go with my version. The hope is when a
> _new_ call site appears, the author would think twice before passing
> zero or one to the safe_path argument.
Wouldn't it be a better A
On Tue, Feb 13, 2018 at 4:13 AM, Duy Nguyen wrote:
> On Tue, Feb 13, 2018 at 6:49 PM, Duy Nguyen wrote:
>> On Mon, Feb 12, 2018 at 05:22:15PM -0800, Stefan Beller wrote:
>>> This is a real take on the first part of the recent RFC[1].
>>>
>>> ...
>>>
>>> Duy suggested that we shall not use the rep
On Tue, Feb 13, 2018 at 9:18 AM, Junio C Hamano wrote:
>
> That makes me wonder if another heuristic I floated earlier is more
> appropriate. When merging a tag object T, if refs/tags/T exists and
> it is that tag object, then an updated "merge" would default to "--ff";
> otherwise, it would keep
On Tue, Feb 13, 2018 at 09:08:44AM -0800, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> > A third possible fix, which is also in the "we don't care about the
> > order of multiple warning messages" camp and has a nice looking
> > diffstat, would be something like this:
>
> Hmph, we are runni
Mauro Carvalho Chehab writes:
> Yes, that's my pain. I don't want ff only when pulling from others,
> only when pulling from upstream tree.
>
>>
>> We may want per-remote equivalent for it, i.e. e.g.
>>
>> [pull]
>> ff=false ;# good default for collecting contributions
>>
>>
SZEDER Gábor writes:
> A third possible fix, which is also in the "we don't care about the
> order of multiple warning messages" camp and has a nice looking
> diffstat, would be something like this:
Hmph, we are running a "git fetch" locally and observing the error
output from both "fetch" and i
On 02/07, Stefan Beller wrote:
> On Tue, Feb 6, 2018 at 5:12 PM, Brandon Williams wrote:
> > Add the 'shallow' feature to the protocol version 2 command 'fetch'
> > which indicates that the server supports shallow clients and deepen
> > requets.
> >
> > Signed-off-by: Brandon Williams
> > ---
> >
On 02/13, Duy Nguyen wrote:
> On Tue, Feb 13, 2018 at 6:49 PM, Duy Nguyen wrote:
> > On Mon, Feb 12, 2018 at 05:22:15PM -0800, Stefan Beller wrote:
> >> This is a real take on the first part of the recent RFC[1].
> >>
> >> ...
> >>
> >> Duy suggested that we shall not use the repository blindly, b
On Tue, Feb 13, 2018 at 05:06:15PM +0200, Σπύρος Βαζαίος wrote:
> Hi, I've came across an issue when using the git diff command. In
> particular the diff is different to what the svn diff produces. While
> both being correct the output of the svn diff is easier to understand
> than the git diff on
On 02/12/2018 08:23 PM, Brandon Williams wrote:> Maybe this isn't
helpful but you may be able to implement this by using
> a remote-helper. The helper could perform any sort of caching it needed
> to prevent re-downloading large amounts of data that is potentially
> thrown away, while only sending
This is the second time i am sending you this mail.
I, Mavis Wanczyk donates $ 5 Million Dollars from part of my Powerball
Jackpot Lottery of $ 758 Million Dollars, respond with your details
for claims.
I await your earliest response and God Bless you
Good luck.
Mavis Wanczyk
Hi, I've came across an issue when using the git diff command. In
particular the diff is different to what the svn diff produces. While
both being correct the output of the svn diff is easier to understand
than the git diff one. See the following issue on github where I
initially reported the issue
--
Hello,
I have a proposal for you.kindly get back to me
Best Regards.
Sherry Brydson
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Le 13/02/2018 à 14:06, Robert P. J. Day a écrit :
> looking for general opinions ... i am (frighteningly :-) teaching a
> git course later this week, and one of the topics on the list is git
> submodules, which was specifically requested by the client as their
> idea of how to start incorporati
Small changes in messages to fit the style and typography of rest.
Reuse already translated messages if possible.
Do not translate messages aimed at developers of git.
Fix unit tests depending on the original string.
Use `test_i18ngrep` for tests with translatable strings.
Change and verify rest of
Following suggestions on last email exchange:
Junio C Hamano
1. End sentences in long log message with '.'
2. Leave final merge fixes to him based on suggestion from Jeff King
Previous changes:
Eric Sunshine:
1. Use 'test_i18ngrep' rather than 'grep'
Jeff King:
2. Fix t1506
Johannes Si
On Tue, 13 Feb 2018, Christian Couder wrote:
> On Tue, Feb 13, 2018 at 1:28 PM, Robert P. J. Day
> wrote:
> >
> > p.s. i suspect i should RTFS to see exactly how git bisect does its
> > work.
>
> You might want to read
> https://git-scm.com/docs/git-bisect-lk2009.html before reading the
> source
looking for general opinions ... i am (frighteningly :-) teaching a
git course later this week, and one of the topics on the list is git
submodules, which was specifically requested by the client as their
idea of how to start incorporating child repos in new projects.
however, given the numbe
On Tue, Feb 13, 2018 at 1:28 PM, Robert P. J. Day wrote:
>
> p.s. i suspect i should RTFS to see exactly how git bisect does its
> work.
You might want to read https://git-scm.com/docs/git-bisect-lk2009.html
before reading the source code.
On Fri, 9 Feb 2018, Philip Oakley wrote:
> From: "Robert P. J. Day"
> > On Fri, 9 Feb 2018, Philip Oakley, CEng MIET wrote:
> (apologies for using the fancy letters after the name ID...)
> >
> >> From: "Robert P. J. Day"
> >> >
> >> > writing a short tutorial on "git bisect" and, all the details
On Mon, 12 Feb 2018, Christian Couder wrote:
> On Mon, Feb 12, 2018 at 11:44 AM, Robert P. J. Day
> wrote:
> > On Fri, 9 Feb 2018, Junio C Hamano wrote:
> >
> >> "Robert P. J. Day" writes:
> >>
> >> > i'm confused ... why, after skipping a good chunk in the interval
> >> > [v4.13,v4.14], do i
On Tue, Feb 13, 2018 at 6:49 PM, Duy Nguyen wrote:
> On Mon, Feb 12, 2018 at 05:22:15PM -0800, Stefan Beller wrote:
>> This is a real take on the first part of the recent RFC[1].
>>
>> ...
>>
>> Duy suggested that we shall not use the repository blindly, but
>> should carefully examine whether to
On Mon, Feb 12, 2018 at 05:22:15PM -0800, Stefan Beller wrote:
> This is a real take on the first part of the recent RFC[1].
>
> ...
>
> Duy suggested that we shall not use the repository blindly, but
> should carefully examine whether to pass on an object store or the
> refstore or such[4], which
On 13 February 2018 at 11:25, Duy Nguyen wrote:
> On Sun, Feb 11, 2018 at 11:40 PM, Martin Ågren wrote:
>> Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only,
>> 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect
>> `pager.config` when we are listing or "get"ing confi
From: Phillip Wood
Recount the number of preimage and postimage lines in a hunk after it
has been edited so any change in the number of insertions or deletions
can be used to adjust the offsets of subsequent hunks. If an edited
hunk is subsequently split then the offset correction will be lost. I
From: Phillip Wood
When a hunk is skipped by add -i the offsets of subsequent hunks are
not adjusted to account for any missing insertions due to the skipped
hunk. Most of the time this does not matter as apply uses the context
lines to apply the subsequent hunks in the correct place, however in
From: Phillip Wood
This code is duplicated in a couple of places so make it into a
function as we're going to add some more callers shortly.
Signed-off-by: Phillip Wood
---
git-add--interactive.perl | 21 +++--
1 file changed, 11 insertions(+), 10 deletions(-)
diff --git a/git
From: Phillip Wood
While working on a patch series to stage selected lines from a hunk
without having to edit it I got worried that subsequent patches would
be applied in the wrong place which lead to this series to correct the
offsets of hunks following those that are skipped or edited.
Phillip
From: Phillip Wood
Since commit 8cbd431082 ("git-add--interactive: replace hunk
recounting with apply --recount", 2008-7-2) if a hunk is skipped then
we rely on the context lines to apply subsequent hunks in the right
place. While this works most of the time it is possible for hunks to
end up bei
From: Phillip Wood
Improve the help displayed if the user presses an inactive key by only
listing active keys and printing specific messages for some keys. Also
disable search if there's only a single hunk.
Phillip Wood (3):
add -p: only display help for active keys
add -p: Only bind search
From: Phillip Wood
If there is only a single hunk then disable searching as there is
nothing to search for. Also print a specific error message if the user
tries to search with '/' when there's only a single hunk rather than
just listing the key bindings.
Signed-off-by: Phillip Wood
---
git-ad
From: Phillip Wood
If the user presses a key that isn't currently active then explain why
it isn't active rather than just listing all the keys. It already did
this for some keys, this patch does the same for the those that
weren't already handled.
Signed-off-by: Phillip Wood
---
git-add--inte
From: Phillip Wood
If the user presses a key that add -p wasn't expecting then it prints
a list of key bindings. Although the prompt only lists the active
bindings the help was printed for all bindings. Fix this by using the
list of keys in the prompt to filter the help. Note that the list of
ke
On Sun, Feb 11, 2018 at 11:40 PM, Martin Ågren wrote:
> Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only,
> 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect
> `pager.config` when we are listing or "get"ing config.
>
> Some getters give at most one line of output, b
> > I must admit that I didn't think about the effect of the useless
> > "| sort" on the exit status! What I saw was: a process that
> > received no input, sorted nothing and produced no output - pretty
> > much the definition of useless! ;-)
>
> I am not sure what you mean by "receive no input,
On Wed, Feb 7, 2018 at 11:59 PM, Ben Peart wrote:
> diff --git a/dir.c b/dir.c
> index 7c4b45e30e..d431da46f5 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1773,7 +1773,7 @@ static enum path_treatment treat_path(struct
> dir_struct *dir,
> if (!de)
> return treat_path_fast(dir,
On Tue, Feb 13, 2018 at 12:57 AM, Ben Peart wrote:
>> Another case that could touches a lot of directories over time is
>> switch trees (e.g. "git checkout master" then "checkout next" or worse
>> "checkout v1.0").
>
>
> You're example above makes me wonder if you understand what my patch is
> doi
Darlehen Angebot bei 3%, zögern Sie nicht, uns für weitere Informationen zu
kontaktieren
93 matches
Mail list logo