Dear Sir,
I write to you based on a request by an investor. My name is Manda
Khazaleh, an investment Director (Europe/East and North African).
We represent the interests of some elite class mainly from East and
North Africa. Due to the sensitivity of their position they hold in
their
On Tue, Oct 09 2018, Martin Langhoff wrote:
> Hi folks,
>
> Long time no see! Importing a 3GB (~25K revs, tons of files) SVN repo
> I hit the gc error:
>
> warning: There are too many unreachable loose objects; run 'git prune'
> to remove them.
> gc --auto: command returned error: 255
>
> I
On Wed, Oct 10 2018, Junio C Hamano wrote:
> * jk/drop-ancient-curl (2017-08-09) 5 commits
> - http: #error on too-old curl
> - curl: remove ifdef'd code never used with curl >=7.19.4
> - http: drop support for curl < 7.19.4
> - http: drop support for curl < 7.16.0
> - http: drop support
Johannes Schindelin writes:
> Personally, I find the "whoever is picking it up should do the thinking"
> much too harsh for a first-time contributor who specifically came through
> the Outreachy program, i.e. expected to have a gentle introduction into
> the project, and into the ways we work.
From: Johannes Schindelin
The 'edit' command can be used to cherry-pick a commit and then
immediately drop out of the interactive rebase, with exit code 0, to let
the user amend the commit, or test it, or look around.
Sometimes this functionality would come in handy *without*
cherry-picking a
Stefan asked a while back
[https://public-inbox.org/git/20180118183618.39853-3-sbel...@google.com/]
for a todo command in interactive rebases that would essentially perform the
"stop" part of the edit command, but without the "pick" part: interrupt the
interactive rebase, with exit code 0,
From: Johannes Schindelin
We had not documented previously what happens when an `exec` command in
an interactive rebase fails. Now we do.
Signed-off-by: Johannes Schindelin
---
Documentation/git-rebase.txt | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
On Tue, Oct 9, 2018 at 4:59 PM Junio C Hamano wrote:
> My inclination is to recommend to:
>
> (1) name the "show the current one" not "--current" but with some
> verb
>
> (2) display nothing when there is no current branch (i.e. detached
> HEAD) and without any error.
Sensible
Hi Junio & Ananya,
Ananya, I think you did a really good job at contributing your first
patch, demonstrated by the useful comments you already received.
On Tue, 9 Oct 2018, Junio C Hamano wrote:
> Derrick Stolee writes:
>
> > On 10/8/2018 1:05 PM, Ananya Krishna Maram wrote:
> >> Hi All,
> >
On Mon, Oct 08 2018, Thiago Saife wrote:
> Hello Git Team.
>
> I would like to help to continue the books' translation to Brazilian
> Portuguese and I don't know how to proceed. Thanks in advance for your
> help.
That would be great. Have you seen
On Wed, Oct 10 2018, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Oct 08 2018, Thiago Saife wrote:
>
>> Hello Git Team.
>>
>> I would like to help to continue the books' translation to Brazilian
>> Portuguese and I don't know how to proceed. Thanks in advance for your
>> help.
>
> That would be
On Wed, Oct 10, 2018 at 10:46 AM Junio C Hamano wrote:
>
> Johannes Schindelin writes:
>
> > Personally, I find the "whoever is picking it up should do the thinking"
> > much too harsh for a first-time contributor who specifically came through
> > the Outreachy program, i.e. expected to have a
On Wed, Oct 10, 2018 at 5:29 AM Eric Sunshine wrote:
> On Tue, Oct 9, 2018 at 4:59 PM Junio C Hamano wrote:
> > My inclination is to recommend to:
> >
> > (1) name the "show the current one" not "--current" but with some
> > verb
> >
> > (2) display nothing when there is no current branch
Hi Eric
Thanks for looking at this series, sorry it has taken so long for me to
reply.
On 14/09/2018 00:49, Eric Sunshine wrote:
> On Wed, Sep 12, 2018 at 6:11 AM Phillip Wood
> wrote:
>> Add read_author_script() to sequencer.c based on the implementation in
>> builtin/am.c and update
On Wed, Oct 10, 2018 at 4:54 AM Johannes Schindelin via GitGitGadget
wrote:
> We had not documented previously what happens when an `exec` command in
> an interactive rebase fails. Now we do.
>
> Signed-off-by: Johannes Schindelin
> ---
> diff --git a/Documentation/git-rebase.txt
I am running:
Linux 4.18.12-arch1-1-ARCH #1 SMP PREEMPT Thu Oct 4 01:01:27 UTC 2018 x86_64
GNU/Linux
git version 2.19.1
etckeeper Version: 1.18.8
I ran into a strange bug. In the following script the commit at the end will
fail with:
> The following paths are ignored by one of your
On Wed, Oct 10, 2018 at 6:14 AM Phillip Wood wrote:
> On 14/09/2018 00:49, Eric Sunshine wrote:
> > What if, instead of exit()ing directly, you drop the conditional and
> > instead return the value of read_author_script():
> >
> > return read_author_script(...);
> >
> > and let the caller
On 14/09/2018 01:31, Eric Sunshine wrote:
> On Wed, Sep 12, 2018 at 6:11 AM Phillip Wood
> wrote:
>> Use the new function to read the author script, updating
>> read_env_script() and read_author_ident(). This means we now have a
>> single code path that reads the author script and uses
Improve the error message added in f8aae12034 ("push: allow
unqualified dest refspecs to DWIM", 2008-04-23), which before this
change looks like this:
$ git push avar v2.19.0^{commit}:newbranch -n
error: unable to push to unqualified destination: newbranch
The destination refspec
Mark up the error(...) messages in remote.c for translation. The likes
of "unable to push to unqualified destination" are relatively big
parts of the UI, i.e. error messages shown when "git push" fails.
I don't think any of these are plumbing, an the entire test suite
passes when running the
Years ago I accidentally deleted the "master" branch at work (due to
git push origin $emptyvar:master), and while I could tell from the
reflogs what SHA-1 I needed on the other side ran into the fairly
cryptic error message, certainly to me when the adrenaline is flowing
and you've just ruined
Ævar Arnfjörð Bjarmason writes:
> - We use this warning as a proxy for "let's not run for a day",
>otherwise we'll just grind on gc --auto trying to consolidate
>possibly many hundreds of K of loose objects only to find none of
>them can be pruned because the run into the expiry
Christian Couder writes:
> So I think one solution to this problem is already proposed on our web site.
OK, that's a good start. The next step is to make those who are
involved in these education programs to be more aware of it ;-)
Hi Junio,
On Wed, 10 Oct 2018, Junio C Hamano wrote:
> We haven't seen much complaints and breakages reported against the
> two big "rewrite in C" topics around "rebase"; perhaps it is a good
> time to merge them to 'next' soonish to cook them for a few weeks
> before moving them to 'master'?
I
On Wed, Oct 10 2018, Rasmus Villemoes wrote:
> + if ($c !~ /.+@.+|<.+>/) {
> + printf("(body) Ignoring %s from line '%s'\n",
> + $what, $_) unless $quiet;
> + next;
> +
On Wed, Oct 10 2018, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> - We use this warning as a proxy for "let's not run for a day",
>>otherwise we'll just grind on gc --auto trying to consolidate
>>possibly many hundreds of K of loose objects only to find none of
>>
Johannes Schindelin writes:
> Speaking about the two `rebase` ones: they are simple fixup! commits,
> could I trouble you to fetch and cherry-pick them into `pu`, or would you
> prefer if I sent another iteration of `rebase-in-c-4-opts`?
If it were only about me, then the former if I can do my
Hi Avar.
What it means? I should not continue the translation? Because
Brazilian Portuguese states as Translations started for, but it's not
finished yet.
On Wed, Oct 10, 2018 at 6:04 AM Ævar Arnfjörð Bjarmason
wrote:
>
>
> On Wed, Oct 10 2018, Ævar Arnfjörð Bjarmason wrote:
>
> > On Mon, Oct
Good day,
I am Mdm. SUI Yang, Chief Financial Officer of the Bank of China
I am looking for a manager / investment partner who will work with me for
a joint venture.
Contact me in my private email for more details.
email (suiyan...@gmail.com)
Waiting to hear from you.
Thank you,
Mdm SUI Yang`
On Wed, Oct 10, 2018 at 2:41 PM Thiago Saife wrote:
>
> Hi Avar.
>
> What it means? I should not continue the translation? Because
> Brazilian Portuguese states as Translations started for, but it's not
> finished yet.
I misunderstood and thought you meant the translation of the git program
Ok, no problem.
Regards,
On Wed, Oct 10, 2018 at 9:43 AM Ævar Arnfjörð Bjarmason
wrote:
>
> On Wed, Oct 10, 2018 at 2:41 PM Thiago Saife
> wrote:
> >
> > Hi Avar.
> >
> > What it means? I should not continue the translation? Because
> > Brazilian Portuguese states as Translations started for,
On 10/10/2018 06:43, Junio C Hamano wrote:
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
On Wed, Oct 10, 2018 at 01:44:41PM +0200, SZEDER Gábor wrote:
> > So that's really weird and counter-intuitive, since we should be doing
> > strictly less work. I know that spatch tries to parallelize itself,
> > though from my tests, 1.0.4 does not. I wonder if the version in Travis
> > differs
On Wed, Oct 03 2018, Johannes Schindelin via GitGitGadget wrote:
> Quite some time ago, a last plea to the XP users out there who want to
> see Windows XP support in Git for Windows, asking them to get engaged
> and help, vanished into the depths of the universe.
>
> We tried for a long time to
On 10/10, Junio C Hamano wrote:
> * ps/stash-in-c (2018-08-31) 20 commits
> - stash: replace all `write-tree` child processes with API calls
> - stash: optimize `get_untracked_files()` and `check_changes()`
> - stash: convert `stash--helper.c` into `stash.c`
> - stash: convert save to builtin
/etc/.git/hooks/pre-commit is installed by etckeeper and runs
etckeeper pre-commit, which deals with /etc/.etckeeper, including
running "git add .etckeeper". Why that file would match a gitignore
seems much less important than why git would run that hook in an
entirely different git repository.
I noticed that git-merge-base was unlikely to actually be a git command,
and tried it in my shell. Seeing that it doesn't work, I cleaned up two
places in the docs where it appears.
Signed-off-by: Mihir Mehta
---
Documentation/git-diff.txt | 7 ---
Thanks, Junio. Instead of removing that part of the patch, I opted to
expand it to make it a little clearer (in my opinion) than it was
before. Let me know if this works.
Mihir.
On Wed, Oct 10 2018, Rasmus Villemoes wrote:
> - next if $suppress_cc{'sob'} and $what =~
> /Signed-off-by/i;
> + next if $suppress_cc{'sob'} and $what =~
> /^Signed-off-by$/i;
> + next if
On 2018-10-10 14:57, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Oct 10 2018, Rasmus Villemoes wrote:
>
>> +if ($c !~ /.+@.+|<.+>/) {
>> +printf("(body) Ignoring %s from line '%s'\n",
>> +$what, $_) unless $quiet;
On Wed, Oct 10, 2018 at 05:59:05AM +0900, Junio C Hamano wrote:
>
> But I do not think that is what is going on. There is "--list" that
> lists branches whose name match given patterns, and at the end-user
> level (I haven't seen the implementation) this is another mode of
> that operation that
On Fri, Sep 21, 2018 at 05:57:33PM +0200, Nguyễn Thái Ngọc Duy wrote:
> diff --git a/diff.c b/diff.c
> index 140d0e86df..5256b9eabc 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -2093,23 +2093,25 @@ static void diff_words_flush(struct emit_callback
> *ecbdata)
> }
> }
>
> -static void
Do like it's done in grep so mode doesn't end up as
016, which means range-diff doesn't work if one has
"submodule.diff = log" in the configuration. Without this
while using range-diff I only get a
Submodule a 000...000 (new submodule)
instead of the diff between the revisions.
Johannes Schindelin writes:
> Hi Junio,
>
> On Wed, 10 Oct 2018, Junio C Hamano wrote:
>
>> * js/mingw-wants-vista-or-above (2018-10-04) 3 commits
>> - mingw: bump the minimum Windows version to Vista
>> - mingw: set _WIN32_WINNT explicitly for Git for Windows
>> - compat/poll: prepare for
On Tue, Oct 09 2018, Daniels Umanovskis wrote:
> I often find myself needing the current branch name, for which
> currently there's git rev-parse --abrev-ref HEAD. I would expect `git
> branch` to have an option to output the branch name instead.
>
> This is my first patch to Git, so
Hi Junio,
On Wed, 10 Oct 2018, Junio C Hamano wrote:
> * js/mingw-wants-vista-or-above (2018-10-04) 3 commits
> - mingw: bump the minimum Windows version to Vista
> - mingw: set _WIN32_WINNT explicitly for Git for Windows
> - compat/poll: prepare for targeting Windows Vista
>
> The minimum
Good day,
I am Mdm. SUI Yang, Chief Financial Officer of the Bank of China
I am looking for a manager / investment partner who will work with me for
a joint venture.
Contact me in my private email for more details.
email (suiyan...@gmail.com)
Waiting to hear from you.
Thank you,
Mdm SUI Yang`
On 2018-10-07 2:08 am, Junio C Hamano wrote:
Steve writes:
Since stash list accepts git-log options, add the following useful
options that make sense in the context of the `git stash list`
command:
--name-status --oneline --patch-with-stat
Signed-off-by: Steven Fernandez
---
This is
ATTN:
I am MR.Ken Obodo, writing you in respect of my deceased client,I have
been trying to locate any member of his family to assist in
repatriating his fund he deposited in finance house valued at
US$10.500.000 .Contact me with your full names, occupation, country of
residence and direct
From: Ben Peart
Fixed issues identified in review the most impactful probably being plugging
some leaks and improved error handling. Also added better error messages
and some code cleanup to code I'd touched.
The biggest change in the interdiff is the impact of renaming ieot_offset to
From: Ben Peart
Add support for a new index.threads config setting which will be used to
control the threading code in do_read_index(). A value of 0 will tell the
index code to automatically determine the correct number of threads to use.
A value of 1 will make the code single threaded. A
From: Ben Peart
This patch does a clean up pass to minimize the casting required to work
with the memory mapped index (mmap).
It also makes the decoding of network byte order more consistent by using
get_be32() where possible.
Signed-off-by: Ben Peart
---
read-cache.c | 23
From: Nguyễn Thái Ngọc Duy
Index format v4 requires some more computation to assemble a path
based on a previous one. The current code is not very efficient
because
- it doubles memory copy, we assemble the final path in a temporary
first before putting it back to a cache_entry
-
From: Ben Peart
The End of Index Entry (EOIE) is used to locate the end of the variable
length index entries and the beginning of the extensions. Code can take
advantage of this to quickly locate the index extensions without having
to parse through all of the index entries.
The EOIE extension
On Wed, Oct 10 2018, Martin Langhoff wrote:
> On Wed, Oct 10, 2018 at 7:27 AM Ævar Arnfjörð Bjarmason
> wrote:
>> As Jeff's
>> https://public-inbox.org/git/20180716175103.gb18...@sigill.intra.peff.net/
>> and my https://public-inbox.org/git/878t69dgvx@evledraar.gmail.com/
>> note it's a
On Wed, Oct 10, 2018 at 09:33:00AM +, Naja Melan wrote:
> I ran into a strange bug. In the following script the commit at the end will
> fail with:
>
> > The following paths are ignored by one of your .gitignore files:
> > .etckeeper
> > Use -f if you really want to add them.
>
> Note
On Wed, Oct 10, 2018 at 09:59:16AM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> On Wed, Oct 10 2018, Junio C Hamano wrote:
>
> > * jk/drop-ancient-curl (2017-08-09) 5 commits
> > - http: #error on too-old curl
> > - curl: remove ifdef'd code never used with curl >=7.19.4
> > - http: drop
On 09/10/2018 22:10, Stefan Beller wrote:
As I said above I've more or less come to the view that the correctness
of pythonic indentation is orthogonal to move detection as it affects
all additions, not just those that correspond to moved lines.
Makes sense.
Right so are you happy for we to
On 10/10/18 5:03 PM, Ævar Arnfjörð Bjarmason wrote:
>
> I'm mildly negative on this because git-rev-parse is plumbing, but
> git-branch is porcelain [..]
>
> We also list git-rev-parse as porcelain, just under "Porcelain / Ancillary
> Commands / Interrogators".
>
> Should we just move it to
On Wed, Oct 10, 2018 at 8:21 AM Junio C Hamano wrote:
> We probably can keep the "let's not run for a day" safety while
> pretending that "git gc -auto" succeeded for callers like "git svn"
> so that these callers do not hae to do "eval { ... }" to hide our
> exit code, no?
>
> I think that is
On Wed, Oct 10, 2018 at 09:51:52AM -0700, Jonathan Nieder wrote:
> Ævar Arnfjörð Bjarmason wrote:
>
> > I'm just saying it's hard in this case to remove one piece without the
> > whole Jenga tower collapsing, and it's probably a good idea in some of
> > these cases to pester the user about what
> I'd be happy to submit a documentation patch for discussion that
> formally moves rev-parse to plumbing.
I'd be happy to see such a patch.
From: Ben Peart
This patch enables addressing the CPU cost of loading the index by adding
additional data to the index that will allow us to efficiently multi-
thread the loading and conversion of cache entries.
It accomplishes this by adding an (optional) index extension that is a
table of
From: Ben Peart
This patch helps address the CPU cost of loading the index by loading
the cache extensions on a worker thread in parallel with loading the cache
entries.
In some cases, loading the extensions takes longer than loading the
cache entries so this patch utilizes the new EOIE to
From: Ben Peart
This patch helps address the CPU cost of loading the index by utilizing
the Index Entry Offset Table (IEOT) to divide loading and conversion of
the cache entries across multiple threads in parallel.
I used p0002-read-cache.sh to generate some performance data:
Test w/100,000
Hi,
Ævar Arnfjörð Bjarmason wrote:
> I'm just saying it's hard in this case to remove one piece without the
> whole Jenga tower collapsing, and it's probably a good idea in some of
> these cases to pester the user about what he wants, but probably not via
> gc --auto emitting the same warning
On Wed, Oct 10, 2018 at 8:26 AM Phillip Wood wrote:
>
> On 09/10/2018 22:10, Stefan Beller wrote:
> >> As I said above I've more or less come to the view that the correctness
> >> of pythonic indentation is orthogonal to move detection as it affects
> >> all additions, not just those that
Looking around, Jonathan Tan's "[PATCH] gc: do not warn about too many
loose objects" makes sense to me.
- remove unactionable warning
- as the warning is gone, no gc.log is produced
- subsequent gc runs don't exit due to gc.log
My very humble +1 on that.
As for downsides... if we have truly
For consistency, add full stops in a few places and outdent a line by
one space.
Signed-off-by: Rasmus Villemoes
---
Documentation/git-send-email.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
This has been attempted multiple times before, but I hope that this
can make it in this time around. That *-by addresses are not
automatically Cc'ed certainly still surprises people from time to
time.
I hope that this addresses all the concerns Junio had in
https://lkml.org/lkml/2016/8/31/768 .
When rerolling a patch series, including various Reviewed-by etc. that
may have come in, it is quite convenient to have git-send-email
automatically cc those people.
So pick up any *-by lines, with a new suppression category 'misc-by',
but special-case Signed-off-by, since that already has its
While the address sanitizations routines do accept local addresses, that
is almost never what is meant in a Cc or Signed-off-by trailer.
Looking through all the signed-off-by lines in the linux kernel tree
without a @, there are mostly two patterns: Either just a full name, or
a full name
On Wed, Oct 10 2018, Martin Langhoff wrote:
> Looking around, Jonathan Tan's "[PATCH] gc: do not warn about too many
> loose objects" makes sense to me.
>
> - remove unactionable warning
> - as the warning is gone, no gc.log is produced
> - subsequent gc runs don't exit due to gc.log
>
> My
On Wed, Oct 10, 2018 at 7:27 AM Ævar Arnfjörð Bjarmason
wrote:
> As Jeff's
> https://public-inbox.org/git/20180716175103.gb18...@sigill.intra.peff.net/
> and my https://public-inbox.org/git/878t69dgvx@evledraar.gmail.com/
> note it's a bit more complex than that.
Ok, my bad for not reading
On Wed, Oct 10 2018, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Oct 10 2018, Martin Langhoff wrote:
>
>> Looking around, Jonathan Tan's "[PATCH] gc: do not warn about too many
>> loose objects" makes sense to me.
>>
>> - remove unactionable warning
>> - as the warning is gone, no gc.log is
On Mon, Oct 08, 2018 at 11:15:42PM -0400, Jeff King wrote:
> On Fri, Oct 05, 2018 at 09:54:13PM +0200, SZEDER Gábor wrote:
>
> > Runtimes tend to fluctuate quite a bit more on Travis CI compared to
> > my machine, but not this much, and it seems to be consistent so far.
> >
> > After
Am 10.10.18 um 07:43 schrieb Junio C Hamano:
We haven't seen much complaints and breakages reported against the
two big "rewrite in C" topics around "rebase"; perhaps it is a good
time to merge them to 'next' soonish to cook them for a few weeks
before moving them to 'master'?
Please let me
Checking gc_auto_threshold in too_many_loose_objects() was added in
17815501a8 ("git-gc --auto: run "repack -A -d -l" as necessary.",
2007-09-17) when need_to_gc() itself was also reliant on
gc_auto_pack_limit before its early return:
gc_auto_threshold <= 0 && gc_auto_pack_limit <= 0
When
Hi,
Ævar Arnfjörð Bjarmason wrote:
> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
> configuration option to optionally bring back the 'git gc --auto' exit
> code behavior as it existed between 2.6.3..2.19.0 (inclusive).
Hm. Can you tell me more about the use case
When called with --show-current, git branch will print the current
branch name and terminate. Only the actual name gets printed,
without refs/heads. In detached HEAD state, nothing is output.
Intended both for scripting and interactive/informative use.
Unlike git branch --list, no filtering is
Jonathan Nieder writes:
> Perhaps this reporting could also print the message from a previous
> run, so you could write:
>
> git gc --detached-status || exit
> git gc --auto; # perhaps also passing --detach
>
> (Names still open for bikeshedding.)
When the command is given
git-rev-parse mostly seems like plumbing, and is more usd in
scripts than in regular use. Online it's often mentioned as
a plumbing command. Nonetheless it's listed under porcelain
interrogators in `man git`. It seems appropriate to formally
move git-rev-parse to plumbing interrogators.
This patch started as a refactoring to make 'get_next_submodule' more
readable, but upon doing so, I realized that "git fetch" of the submodule
actually doesn't need to be run in the submodules worktree. So let's run
it in its git dir instead.
That should pave the way towards fetching submodules
Currently when git-fetch is asked to recurse into submodules, it dispatches
a plain "git-fetch -C " (with some submodule related options
such as prefix and recusing strategy, but) without any information of the
remote or the tip that should be fetched.
This works surprisingly well in some
We can string_list_insert() to maintain sorted-ness of the
list as we find new items, or we can string_list_append() to
build an unsorted list and sort it at the end just once.
As we do not rely on the sortedness while building the
list, we pick the "append and sort at the end" as it
has better
The submodule subsystem is really bad at staying within 80 characters.
Fix it while we are here.
Signed-off-by: Stefan Beller
---
submodule.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/submodule.c b/submodule.c
index b53cb6e9c4..0de9e2800a 100644
---
Helped-by: Junio C Hamano
Signed-off-by: Stefan Beller
---
Documentation/technical/api-oid-array.txt | 5 +
sha1-array.c | 17 +
sha1-array.h | 3 +++
3 files changed, 25 insertions(+)
diff --git
The `changed_submodule_names` are only used for fetching, so let's make it
part of the struct that is passed around for fetching submodules.
Signed-off-by: Stefan Beller
---
submodule.c | 42 +++---
1 file changed, 23 insertions(+), 19 deletions(-)
diff
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> Perhaps this reporting could also print the message from a previous
>> run, so you could write:
>>
>> git gc --detached-status || exit
>> git gc --auto; # perhaps also passing --detach
>>
>> (Names still open for bikeshedding.)
>
>
Gerrit, the code review tool, has a different workflow than our mailing
list based approach. Usually users upload changes to a Gerrit server and
continuous integration and testing happens by bots. Sometimes however a
user wants to checkout a change locally and look at it locally. For this
use
On Wed, 10 Oct 2018 18:51:17 -, Michael Witten wrote:
> merge -# Same as merge -C abcde r1
That should be:
merge -# Same as `merge r1'
On Tue, Oct 9, 2018 at 6:10 PM Junio C Hamano wrote:
>
> Stefan Beller writes:
> >> Oh, I think I misled you by saying "more important".
> >> ...
> > I do challenge the decision to take a hardcoded value, though, ...
>
> I do not find any reason why you need to say "though" here.
I caught
> * pw/diff-color-moved-ws-fix (2018-10-04) 5 commits
> - diff --color-moved: fix a memory leak
> - diff --color-moved-ws: fix another memory leak
> - diff --color-moved-ws: fix a memory leak
> - diff --color-moved-ws: fix out of bounds string access
> - diff --color-moved-ws: fix double free
Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
configuration option to optionally bring back the 'git gc --auto' exit
code behavior as it existed between 2.6.3..2.19.0 (inclusive).
This was changed in 3029970275 ("gc: do not return error for prior
errors in daemonized
On Wed, Oct 10, 2018 at 07:27:32PM +, Ævar Arnfjörð Bjarmason wrote:
> Add an --auto-exit-code variable and a corresponding 'gc.autoExitCode'
> configuration option to optionally bring back the 'git gc --auto' exit
> code behavior as it existed between 2.6.3..2.19.0 (inclusive).
>
> This was
Ævar Arnfjörð Bjarmason wrote:
> Right. I know. What I mean is now I can (and do) use it to run 'git gc
> --auto' across our server fleet and see whether I have any of #3, or
> whether it's all #1 or #2. If there's nothing to do in #1 that's fine,
> and it just so happens that
On Wed, 10 Oct 2018 14:43:46 +0900, Junio wrote:
> We haven't seen much complaints and breakages reported against the
> two big "rewrite in C" topics around "rebase"; perhaps it is a good
> time to merge them to 'next' soonish to cook them for a few weeks
> before moving them to 'master'?
Explicitly mention in the intro that we may be writing supplemental
data structures such as the commit-graph during "gc", i.e. to call out
the "optimize" part of what this command does, it doesn't just
"collect garbage" as the "gc" name might imply.
Past changes have updated the intro to reflect
v2 reroll of a previously-discussed patch. Thanks to everyone for their
comments. Based on feedback:
1. Command is now a verb: git branch --show-current.
2. Changed to gitster's suggested implementation: nothing is printed
if HEAD does not point to a symbolic ref. A fatal
error if HEAD is a
On Wed, Oct 10, 2018 at 10:41:45AM +, Ævar Arnfjörð Bjarmason wrote:
> Improve the error message added in f8aae12034 ("push: allow
> unqualified dest refspecs to DWIM", 2008-04-23), which before this
> change looks like this:
>
> $ git push avar v2.19.0^{commit}:newbranch -n
> error:
1 - 100 of 162 matches
Mail list logo
