Cher utilisateur de messagerie,
Dans nos efforts pour fournir un excellent service à tous nos utilisateurs,
nous prévoyons d'effectuer une mise à niveau du système. Le processus prend
environ 30 minutes. Ce message est diffusé depuis quelque temps déjà et nous
conseillons aux utilisateurs de se
Cher utilisateur de messagerie,
Dans nos efforts pour fournir un excellent service à tous nos utilisateurs,
nous prévoyons d'effectuer une mise à niveau du système. Le processus prend
environ 30 minutes. Ce message est diffusé depuis quelque temps déjà et nous
conseillons aux utilisateurs de se
On Sun, Jun 23, 2019 at 01:32:16PM -0700, Pedro Larroy wrote:
> Thanks for your answer.
>
> I was expecting the HEAD to point to the first bad commit.
>
> In mercurial, the exit status tells you information about the
> bisection process: https://www.mercurial-scm.org/repo/hg/help/bisect
>
> Su
On Sun, Jun 23, 2019 at 06:00:50PM +0200, René Scharfe wrote:
> > I do think if it took the more usual pass-by-const-pointer we'd probably
> > still end up with the exact same code from an optimizing compiler, since
> > all of the references and dereferences would cancel out once it was
> > inline
On Sun, Jun 23, 2019 at 06:08:25PM +, Eric Wong wrote:
> > I'm not sure of the right solution. For maximal backwards-compatibility,
> > the default for bitmaps could become "if not bare and if there are no
> > .keep files". But that would mean bitmaps sometimes not getting
> > generated becaus
From: "Robin H. Johnson"
The pre-built htmldoc/manpage tarballs do not include any documentation
from the contrib code. As a result, if you want that documentation, you
need the full documentation stack to build them.
By including the contrib docs in the tarballs, this is prevented.
The documen
Thanks for your answer.
I was expecting the HEAD to point to the first bad commit.
In mercurial, the exit status tells you information about the
bisection process: https://www.mercurial-scm.org/repo/hg/help/bisect
Sure one can parse stdout, it's just more tedious than just checking
the return c
Calls to advise() which are not guarded by advice.* config variables
are "bad" as they do not let the user say, "I've learned this part
of Git enough, please don't tell me what to do verbosely.". Add a
configuration variable "sequencerInUse" which controls whether to
display advice when any sequenc
git am or rebase have a --skip flag to skip the current commit if the
user wishes to do so. During a cherry-pick or revert a user could
likewise skip a commit, but needs to use 'git reset' (or in the case
of conflicts 'git reset --merge'), followed by 'git (cherry-pick |
revert) --continue' to skip
Tied all loose ends. Add an advice config variable to guard advise() call
in 2/6.
Rohit Ashiwal (6):
advice: add sequencerInUse config variable
sequencer: add advice for revert
sequencer: rename reset_for_rollback to reset_merge
sequencer: use argv_array in reset_merge
cherry-pick/revert
Avoid using magic numbers for array size and index under `reset_merge`
function. Use `argv_array` instead. This will make code shorter and
easier to extend.
Signed-off-by: Rohit Ashiwal
---
sequencer.c | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/sequenc
In the case of merge conflicts, while performing a revert, we are
currently advised to use `git cherry-pick --`
of which --continue is incompatible for continuing the revert.
Introduce a separate advice message for `git revert`. Also change
the signature of `create_seq_dir` to handle which advice t
The previous commit introduced a --skip flag for cherry-pick and
revert. Update the advice messages, to tell users about this less
cumbersome way of skipping commits. Also add tests to ensure
everything is working fine.
Signed-off-by: Rohit Ashiwal
---
builtin/commit.c| 13 ++
We are on a path to teach cherry-pick/revert how to skip commits. To
achieve this, we could really make use of existing functions.
reset_for_rollback is one such function, but the name does not
intuitively suggest to use it to reset a merge, which it was born to
perform see 539047c ("revert: introd
On Wed, Jun 19, 2019 at 7:36 PM Emily Shaffer wrote:
> On Wed, Jun 19, 2019 at 04:13:35AM -0400, Eric Sunshine wrote:
> > Maybe I got confused because the tiny cmd_walken() snippets followed
> > one another so closely (or because I got interrupted several times
> > during the review), but one way
Jeff King wrote:
> On Sun, Jun 23, 2019 at 04:54:50PM +0200, Ævar Arnfjörð Bjarmason wrote:
>
> > I haven't looked at this for more than a couple of minutes (and don't
> > have more time now), but this is almost certainly due to 36eba0323d
> > ("repack: enable bitmaps by default on bare repos", 2
On Sun, Jun 23, 2019 at 04:54:50PM +0200, Ævar Arnfjörð Bjarmason wrote:
> I haven't looked at this for more than a couple of minutes (and don't
> have more time now), but this is almost certainly due to 36eba0323d
> ("repack: enable bitmaps by default on bare repos", 2019-03-14). Can you
> confir
On 2019-06-23 at 08:28:41, Dimitriy wrote:
> brian m. carlson wrote:
> > In my view, the translation is less important for the prefixes and more
> > important for the unit: at least French prefers the term "octet" over
> > "byte"[0], so instead of writing "MB", you'd write "Mo".
>
> Localization
Am 20.06.19 um 20:27 schrieb Jeff King:
> On Thu, Jun 20, 2019 at 10:44:17AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>>> For use in object_id hash tables, we have oid_hash() and oid_equal().
>>> But these are confusingly similar to the existing oideq() and the
>>> oidhash() we plan
Thanks for looking at this, yes, it seems it's purely the .bitmap
writing. With disabled repack.writeBitmaps, it all behaves as before
(and yes, these are bare repros for keeping an intermediate backup).
With the easy workaround in place, I'm back at 2.22 for now, thanks!
On Sun, Jun 23, 2019 at
On Sun, Jun 23 2019, Janos Farkas wrote:
> I'm using .keep files to... well.. keep packs to avoid some CPU time
> spent on repacking huge packs and make the process somewhat more
> incremental.
>
> Something changed with 22.2.0. Now .bitmap files are also created,
> and no simple repacks re-cre
Am 23.06.19 um 10:28 schrieb Dimitriy:
> brian m. carlson wrote:
>>
>> On 2019-06-22 at 21:42:33, Johannes Sixt wrote:
>>> Am 22.06.19 um 11:36 schrieb Dimitriy Ryazantcev:
diff --git a/strbuf.c b/strbuf.c
index 0e18b259ce..0a3ebc3749 100644
--- a/strbuf.c
+++ b/strbuf.c
@
I'm using .keep files to... well.. keep packs to avoid some CPU time
spent on repacking huge packs and make the process somewhat more
incremental.
Something changed with 22.2.0. Now .bitmap files are also created,
and no simple repacks re-create the pack data in a completely new
file, wasting qui
Signed-off-by: Dimitriy Ryazantcev
---
progress.c | 4 +++-
strbuf.c | 16
2 files changed, 15 insertions(+), 5 deletions(-)
diff --git a/progress.c b/progress.c
index a2e8cf64a8..fc62941fa4 100644
--- a/progress.c
+++ b/progress.c
@@ -151,7 +151,9 @@ static void throughput_s
brian m. carlson wrote:
>
> On 2019-06-22 at 21:42:33, Johannes Sixt wrote:
> > Am 22.06.19 um 11:36 schrieb Dimitriy Ryazantcev:
> > > diff --git a/strbuf.c b/strbuf.c
> > > index 0e18b259ce..0a3ebc3749 100644
> > > --- a/strbuf.c
> > > +++ b/strbuf.c
> > > @@ -814,20 +814,28 @@ void strbuf_addst
25 matches
Mail list logo
