Am 18.03.19 um 17:15 schrieb Ævar Arnfjörð Bjarmason:
> +Using this option may optimize for disk space at the expense of
> +runtime performance. See the `--depth` and `--window` documentation in
> +linkgit:git-repack[1]. It is not recommended that this option be used
> +to improve performance for a
On Fri, Mar 08, 2019 at 10:27:11AM +0200, Mikko Rantalainen wrote:
> If I configure bare repo with
>
> git config gc.pruneExpire never
> git config gc.reflogExpire never
>
> then git will never garbage collect any commit ever stored in the repo.
> This is what I want.
>
> However, all commits r
On Fri, Mar 08, 2019 at 10:36:44AM -0500, Robert P. J. Day wrote:
> as an example, i cloned the linux kernel source tree, then added
> the linux-next repo as a remote -- the end result was two pack files
> (the smaller one i'm assuming being for linux-next):
>
> $ ls -l .git/objects/pack
> tota
On Thu, Mar 14, 2019 at 01:34:32PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Addresse Peff's comments to v1. For a couple of patches I've faked up
> his SOB where I copy/pasted a comment or code from a v1 comment
> verbatim. Will see if he acks that.
Yep, for the record, those are fine (actually, I
On Fri, Mar 15, 2019 at 04:59:57PM +0100, Ævar Arnfjörð Bjarmason wrote:
> When gc.reflogExpire and gc.reflogExpireUnreachable are set to "never"
> and --stale-fix isn't in effect (covered by the first part of the "if"
> statement being modified here) we *could* exit early without
> pointlessly lo
مُرسل من هاتف Huawei الخاص بي
Ævar Arnfjörð Bjarmason writes:
+ if (a->pack_int_id < b->pack_int_id)
+ return -1;
+ if (a->pack_int_id > b->pack_int_id)
+ return 1;
+
+ return 0;
+}
>>> ...
>>> succinct subtraction idiom of e.g. (in this case):
>>>
>>> return b->pac
Jeff King writes:
> So in my mind, the endgame is that we eventually drop asciidoc in favor
> of asciidoctor. The repo at:
>
> https://github.com/asciidoc/asciidoc
>
> says:
>
> NOTE: This implementation is written in Python 2, which EOLs in Jan
> 2020. AsciiDoc development is being continu
On Mon, Mar 18, 2019 at 10:46:45PM -0400, Jeff King wrote:
> > * Provide the `mansource` attribute to Asciidoctor. This attribute
> > looks promising until one realizes that it can only be given inside
> > the source file (the .txt file in our case), *not* on the command
> > line usi
On Sun, Mar 17, 2019 at 07:35:59PM +0100, Martin Ågren wrote:
> I've taught `doc-diff` a few new knobs to support usage like
>
> $ ./doc-diff --from-asciidoc --to-asciidoctor HEAD HEAD
>
> and I don't think I've messed it up too badly in the process. I'm open
> to the idea that this might not
On Mon, Mar 18, 2019 at 10:40:00AM +0900, Junio C Hamano wrote:
> After seeing that the possibilities got discussed on the list, and
> that nobody seems to be very much demanding customizability (I am
> taking Ævar's mention of strftime as a mere "if we were doing an
> optional timestamp, why not
On Mon, Mar 18, 2019 at 10:46:46PM -0400, Jeff King wrote:
> > Let's instead try to stay as close as possible to what asciidoc.conf
> > does. We'll make it fairly obvious that we aim to inject the exact same
> > three lines of `` that asciidoc.conf provides. The only
> > somewhat tricky part is th
On Sun, Mar 17, 2019 at 03:47:47PM +0100, Martin Ågren wrote:
> Cc Todd and Peff who had a brief exchange [1] a while ago. Apparently
> Todd saw this "[FIXME: source]" on Fedora but Peff did not on Debian.
> I'm on Ubuntu 18.04 and used to see this also on 16.04. I'm not sure
> what might make
On Mon, Mar 18, 2019 at 11:15 PM Ævar Arnfjörð Bjarmason
wrote:
>
> Rather than duplicating the documentation for the various "gc" options
> let's include the "gc" docs from git-config. They were mostly better
> already, and now we don't have the same docs in two places with subtly
> different wor
On Mon, Mar 18, 2019 at 03:45:25PM +0900, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> >> - This is synonymous to the previous form. If on
> >> + This is synonymous to the previous form. However,
> >> + users should prefer the previous form over this form
> >> + as th
Ævar Arnfjörð Bjarmason writes:
> Some of this thread's confusing, and on re-reading I see my reply hasn't
> helped much.
>
> To clarify. There's at least these things to consider:
>
> 1. What should the semantics of .. or ... be?
> 2. What semantics (regardless of syntax) should we recommend for
On 18/03/2019 20:04, Eric Sunshine wrote:
> On Sun, Mar 17, 2019 at 6:16 AM Denton Liu wrote:
>> Define a function which allows us to get the string configuration value
>> of a enum commit_msg_cleanup_mode. This is done by refactoring
>> get_cleanup_mode such that it uses a lookup table to find
Duy Nguyen writes:
> On Mon, Mar 18, 2019 at 11:54 AM Junio C Hamano wrote:
>> I often find "git reset --hard " after a
>
> It still bugs me that I need to use this to abort some in-progress
> operation.
Note that my comment was *NOT* about aborting the in-progress "am".
What happens in that "I
Jeff King writes:
> On Mon, Mar 18, 2019 at 09:48:42PM +, Thomas Gummerer wrote:
>
>> > It looks like GitGitGadget just uses normal SMTP to submit the messages.
>> > I wonder if normal people using gmail as their SMTP server for
>> > send-email also suffer from this. I've not ever noticed it,
Jeff King writes:
> The way it is written, I think the intent is that you would do:
>
> OPT_ARGUMENT("foo", &saw_foo, ...),
> OPT_ARGUMENT("no-foo", &saw_no_foo, ...),
>
> I'm happy to punt on it until it ever comes up (which I suspect may be
> never).
Yeah, having to have one extra element
On Mon, Mar 18, 2019 at 11:45:39PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I don't think the quarantine stuff should impact contention at all. It's
> > only quarantining the objects, which are the least contentious part of
> > Git (because object content is idempotent, so we don't do any locking
こんにちは
あなたの意見に耳を傾け、そしてビジネスパートナーシップのためにあなたを信頼することは私の喜びです。私たちは以前に会ったことはありませんでしたが、人生で成功するためには人を信頼するリスクを冒さなければならないことがあると思います。私はJoy
Nitaさんです。そしてコートジボワール北部のBouakeから来ました。一人で扱うには若すぎるのであなたの助けとアドバイスが必要です。
私の故父親が、コートジボワールのアビジャンにある経済的な首都の銀行に合計3500万ドルを預けました。状況に応じて、私は自分の国にこのお金を投資したいと思った。政治が頻繁であり、不安定さと安全保障上の理由か
On Sun, Mar 17, 2019 at 8:51 AM Nguyễn Thái Ngọc Duy wrote:
> --discard-changes is a better name than --force for this option since
> it's what really happens. --force is turned to an alias for
> --discard-changes. But it's meant to an alias for potentially more force
s/to an/to be an/
> options
On Mon, Mar 18, 2019 at 11:13:57PM +0100, Ævar Arnfjörð Bjarmason wrote:
> What happened here is that I'd entirely forgotten about your 07e7dbf0db
> and in skimming while writing this throught we were still picking larger
> depth values, which we aren't.
>
> I'll fix that, and see that gc.aggress
On Mon, Mar 18, 2019 at 11:48:46PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > I know this last sentence came from the existing documentation, but I
> > wonder if we should be more vague here. We'd pack with "repack -dl" when
> > we have just loose objects, and "repack -Adl" when we have too many
>
On Mon, Mar 18 2019, Jeff King wrote:
> On Mon, Mar 18, 2019 at 05:15:01PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> In an earlier commit I started including the "gc.*" documentation from
>> git-config(1) in the git-gc(1) documentation. That still left us in a
>> state where the "--auto" option
On Mon, Mar 18 2019, Jeff King wrote:
> On Mon, Mar 18, 2019 at 05:14:58PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> This series is unrelated (and does not conflict with) my in-flight gc
>> contention series
>> (https://public-inbox.org/git/20190315155959.12390-1-ava...@gmail.com/),
>> but the
On Mon, Mar 18 2019, Jeff King wrote:
> On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Hmm. I guess it is still an issue in GGG. This thread has identical
>> > timestamps on patches 1 and 2 (and my server received them out of order
>> > by 2 secon
On Mon, Mar 18 2019, Jeff King wrote:
> On Mon, Mar 18, 2019 at 05:14:59PM +0100, Ævar Arnfjörð Bjarmason wrote:
>
>> The docs have been recommending that users need to run this manually,
>> but that hasn't been needed in practice for a long time.
>>
>> Let's instead have this reflect reality an
On Mon, Mar 18 2019, Jeff King wrote:
> On Mon, Mar 18, 2019 at 01:28:24PM -0700, Jonathan Nieder wrote:
>
>> > +Using this option may optimize for disk space at the expense of
>> > +runtime performance. See the `--depth` and `--window` documentation in
>> > +linkgit:git-repack[1]. It is not rec
On Mon, Mar 18 2019, Jeff Hostetler wrote:
> On 3/18/2019 11:53 AM, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Mon, Mar 18 2019, Jeff Hostetler via GitGitGadget wrote:
>>
>>> +static int compare_pair_pos_vs_id(const void *_a, const void *_b)
>>> +{
>>> + struct pair_pos_vs_id *a = (struct pair_po
On Mon, Mar 18, 2019 at 09:48:42PM +, Thomas Gummerer wrote:
> > It looks like GitGitGadget just uses normal SMTP to submit the messages.
> > I wonder if normal people using gmail as their SMTP server for
> > send-email also suffer from this. I've not ever noticed it, but I
> > don't know how
On Mon, Mar 18, 2019 at 05:14:58PM +0100, Ævar Arnfjörð Bjarmason wrote:
> This series is unrelated (and does not conflict with) my in-flight gc
> contention series
> (https://public-inbox.org/git/20190315155959.12390-1-ava...@gmail.com/),
> but the "git-gc" docs should be updated to discuss the
>
On 03/18, Jeff King wrote:
> On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > Hmm. I guess it is still an issue in GGG. This thread has identical
> > > timestamps on patches 1 and 2 (and my server received them out of order
> > > by 2 seconds, so
On Mon, Mar 18, 2019 at 05:15:01PM +0100, Ævar Arnfjörð Bjarmason wrote:
> In an earlier commit I started including the "gc.*" documentation from
> git-config(1) in the git-gc(1) documentation. That still left us in a
> state where the "--auto" option and "gc.auto" were redundantly
> discussing th
On 3/18/2019 11:53 AM, Ævar Arnfjörð Bjarmason wrote:
On Mon, Mar 18 2019, Jeff Hostetler via GitGitGadget wrote:
+static int compare_pair_pos_vs_id(const void *_a, const void *_b)
+{
+ struct pair_pos_vs_id *a = (struct pair_pos_vs_id *)_a;
+ struct pair_pos_vs_id *b = (struct
On Mon, Mar 18, 2019 at 05:15:00PM +0100, Ævar Arnfjörð Bjarmason wrote:
> Rather than duplicating the documentation for the various "gc" options
> let's include the "gc" docs from git-config. They were mostly better
> already, and now we don't have the same docs in two places with subtly
> differ
On Mon, Mar 18, 2019 at 05:14:59PM +0100, Ævar Arnfjörð Bjarmason wrote:
> The docs have been recommending that users need to run this manually,
> but that hasn't been needed in practice for a long time.
>
> Let's instead have this reflect reality and say that most users don't
> need to run this
On Mon, Mar 18, 2019 at 01:28:24PM -0700, Jonathan Nieder wrote:
> > +Using this option may optimize for disk space at the expense of
> > +runtime performance. See the `--depth` and `--window` documentation in
> > +linkgit:git-repack[1]. It is not recommended that this option be used
> > +to impro
On Mon, Mar 18, 2019 at 06:28:16PM +0100, Björn Kautler wrote:
> I think fast-import should refuse to import paths Git cannot handle
> properly later on, so that the migration fails early and the frontend
> that generates the fast-import stream can be fixed / configured to not
> include such inval
On Mon, Mar 18, 2019 at 11:52:54AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > Hmm. I guess it is still an issue in GGG. This thread has identical
> > timestamps on patches 1 and 2 (and my server received them out of order
> > by 2 seconds, so mutt orders them wrong):
> >
> > https:
On Mon, Mar 18, 2019 at 11:47:20AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> >> +`OPT_ARGUMENT(long, &int_var, description)`::
> >>Introduce a long-option argument that will be kept in `argv[]`.
> >> + If this option was seen, `int_var` will be set to one (except
> >> + if a `NU
On Mon, Mar 18, 2019 at 4:30 PM Denton Liu wrote:
> On Mon, Mar 18, 2019 at 04:04:22PM -0400, Eric Sunshine wrote:
> > These two Reviewed-by: lines should be dropped for a couple reasons.
> >
> I was using it to give credit for changes that I incorporated in
> response to a review. In addition, it
On Mon, Mar 18, 2019 at 04:04:22PM -0400, Eric Sunshine wrote:
> On Sun, Mar 17, 2019 at 6:16 AM Denton Liu wrote:
> > Define a function which allows us to get the string configuration value
> > of a enum commit_msg_cleanup_mode. This is done by refactoring
> > get_cleanup_mode such that it uses a
Hi,
Ævar Arnfjörð Bjarmason wrote:
> --- a/Documentation/git-gc.txt
> +++ b/Documentation/git-gc.txt
> @@ -41,10 +41,20 @@ OPTIONS
> --aggressive::
> Usually 'git gc' runs very quickly while providing good disk
> space utilization and performance. This option will cause
> - 'git
On Sun, Mar 17, 2019 at 6:16 AM Denton Liu wrote:
> Define a function which allows us to get the string configuration value
> of a enum commit_msg_cleanup_mode. This is done by refactoring
> get_cleanup_mode such that it uses a lookup table to find the mappings
> between string and enum and then u
On Sun, Mar 17, 2019 at 7:03 PM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > I don't see why even makes sense to use with --orphan;
> > you should error if both are given, IMO. The point of --orphan is to
> > create some entirely new history. So, I'd expect "git switch --orphan
> > "
On Mon, Mar 18 2019, Elijah Newren wrote:
> On Sun, Mar 17, 2019 at 6:41 AM Ævar Arnfjörð Bjarmason
> wrote:
>> On Sun, Mar 17 2019, Denton Liu wrote:
>>
>> > diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
>> > index 72179d993c..10c7a2220c 100644
>> > --- a/Documentation/g
On Mon, Mar 18, 2019 at 10:11 AM Michal Suchánek wrote:
>
> On Mon, 18 Mar 2019 10:07:08 -0700
> Elijah Newren wrote:
>
> > On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
> > wrote:
> > > On Tue, Mar 12 2019, Andreas Schwab wrote:
> > > > On Mär 12 2019, Junio C Hamano wrote:
> > > >
>
>
> Hello,
>
> we are periodically doing a 'git p4 sync' on a p4 clone that was initially
> created by 'git p4 clone --bare //DEPOT'. Now on P4 side the mail addresses
> have
> changed, but git still uses the old addresses.
> p4 users already shows the new addresses but new changes in the git lo
Hi Denton,
Thanks for working on this. Some thoughts...
On Sun, Mar 17, 2019 at 4:09 AM Denton Liu wrote:
>
> The documentation used to consider
>
> git diff
>
> and
>
> git diff ..
>
> to be equal counterparts. However, rev-list-ish commands also use the
> .. notation, but in
On Mon, Mar 18 2019, Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
> wrote:
>> On Tue, Mar 12 2019, Andreas Schwab wrote:
>> > On Mär 12 2019, Junio C Hamano wrote:
>> >
>> >> I however think it may be worth making sure that our docs do not
>> >> encourage "dif
> And I couldn't find any hints that va_list and pointers can be mixed,
> and no hints that they can't either
C99, Section 7.15, simply says that it "is an object type suitable for
holding information needed by the macros va_start, va_end, and
va_copy".
So clearly not guaranteed to be mixable wit
Hi,
with this simple recipe, you get a non-usable repository:
mkdir foo
cd foo
git init --bare repo
cd repo
git fast-import <<"EOM"
commit refs/heads/master
committer 0 +
data 3
foo
M 644 inline foo/.git/bar
data 3
baz
EOM
cd ..
git clone repo worktree
This actually happened when a user tri
On Sun, Mar 17, 2019 at 6:41 AM Ævar Arnfjörð Bjarmason
wrote:
> On Sun, Mar 17 2019, Denton Liu wrote:
>
> > diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
> > index 72179d993c..10c7a2220c 100644
> > --- a/Documentation/git-diff.txt
> > +++ b/Documentation/git-diff.txt
> > @
On Mon, 18 Mar 2019 10:07:08 -0700
Elijah Newren wrote:
> On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
> wrote:
> > On Tue, Mar 12 2019, Andreas Schwab wrote:
> > > On Mär 12 2019, Junio C Hamano wrote:
> > >
> > >> I however think it may be worth making sure that our docs do not
On Tue, Mar 12, 2019 at 2:01 PM Ævar Arnfjörð Bjarmason
wrote:
> On Tue, Mar 12 2019, Andreas Schwab wrote:
> > On Mär 12 2019, Junio C Hamano wrote:
> >
> >> I however think it may be worth making sure that our docs do not
> >> encourage "diff A..B" and teach "diff A B" when comparing two
> >> e
On Sun, Mar 17, 2019 at 5:50 AM Nguyễn Thái Ngọc Duy wrote:
>
> "git checkout" doing too many things is a source of confusion for many
> users (and it even bites old timers sometimes). To remedy that, the
> command will be split into two new ones: switch and restore. The good
> old "git checkout"
On Mon, Mar 18, 2019 at 1:52 PM Duy Nguyen wrote:
>
> On Mon, Feb 4, 2019 at 4:17 PM Christian Couder
> wrote:
> > Anyway feel free to comment and suggest improvements on those pages,
> > especially the micro-projects and ideas one. Pull requests on
> > https://github.com/git/git.github.io/ are
Rather than duplicating the documentation for the various "gc" options
let's include the "gc" docs from git-config. They were mostly better
already, and now we don't have the same docs in two places with subtly
different wording.
In the cases where the git-gc(1) docs were saying something the "gc"
The docs have been recommending that users need to run this manually,
but that hasn't been needed in practice for a long time.
Let's instead have this reflect reality and say that most users don't
need to run this manually at all.
Signed-off-by: Ævar Arnfjörð Bjarmason
---
Documentation/git-gc.
I've been annoyed by the "gc" docs for a while. This fixes most of the
issues I've noticed, and also removes the duplication between the "gc"
variables in git-config(1) and in git-gc(1), which was made possible
by Duy's Documentation/config/* series.
This should make the "gc" docs more awesome, an
The existing "gc --aggressive" docs come just short of recommending to
users that they run it regularly. In reality it's a waste of CPU for
most users, and may even make things actively worse. I've personally
talked to many users who've taken these docs as an advice to use this
option, and have.
L
In an earlier commit I started including the "gc.*" documentation from
git-config(1) in the git-gc(1) documentation. That still left us in a
state where the "--auto" option and "gc.auto" were redundantly
discussing the same thing.
Fix that by briefly discussing how the option itself works for
"--a
On Mon, Mar 18, 2019 at 08:35:26AM -0400, Jeff Hostetler wrote:
>
>
> On 3/16/2019 6:47 AM, tbo...@web.de wrote:
> > From: Torsten Bögershausen
> >
> > Some compilers don't allow NULL to be passed for a va_list.
> > Use va_list instead.
> >
> > Signed-off-by: Torsten Bögershausen
>
> Thanks for t
On Mon, Mar 18 2019, Jeff Hostetler via GitGitGadget wrote:
> +static int compare_pair_pos_vs_id(const void *_a, const void *_b)
> +{
> + struct pair_pos_vs_id *a = (struct pair_pos_vs_id *)_a;
> + struct pair_pos_vs_id *b = (struct pair_pos_vs_id *)_b;
> +
> + if (a->pack_int_id < b
On Mon, Mar 18, 2019 at 4:38 AM Nguyễn Thái Ngọc Duy wrote:
>
> Phillip found out that 'git checkout -f ' does not restore
> conflict/unmerged files correctly. All tracked files should be taken
> from and all non-zero stages removed. Most of this is true,
> except that the final file could be in
On Sun, Mar 17, 2019 at 4:02 PM Todd Zullinger wrote:
>
> d76ce4f734 ("log,diff-tree: add --combined-all-paths option",
> 2019-02-07) added tests for files containing tabs.
>
> When the tests are run with bash, the lack of quoting during the file
> setup causes 'ambiguous redirect' errors.
>
> Sig
From: Jeff Hostetler
Log multi-pack-index command mode.
Log number of objects and packfiles in the midx.
Signed-off-by: Jeff Hostetler
---
builtin/multi-pack-index.c | 3 +++
midx.c | 4
2 files changed, 7 insertions(+)
diff --git a/builtin/multi-pack-index.c b/builti
From: Jeff Hostetler
Teach `multi-pack-index verify` to sort the set of objects by
packfile so that only one packfile needs to be open at a time.
This is a performance improvement. Previously, objects were
verified in OID order. This essentially requires all packfiles
to be open at the same ti
From: Jeff Hostetler
Fix "git multi-pack-index verify" to handle repos with thousands
of packfiles.
Midx verify adds the individual "packed_git" structures to the
multi_pack_index.packs array, but it does not add them to the
"repository.objects.packed_git" list. During the verification
code, ea
Teach "multi-pack-index verify" to handle cases where the number of
packfiles exceeds the open file handle limit.
The first commit fixes a problem that prevented the LRU-style
close_one_pack() mechanism from working which caused midx verify to run out
of file descriptors.
The second commit teache
On Mon, Feb 4, 2019 at 4:17 PM Christian Couder
wrote:
>
> Hi everyone,
>
> There are now ideas, micro-projects and organization application pages
> for GSoC 2019 on https://git.github.io/
>
> It would be nice to have a few more project ideas.
> https://git.github.io/SoC-2019-Ideas/ currently list
On 3/15/2019 4:38 PM, Josh Steadmon wrote:
On 2019.03.15 15:18, Jeff Hostetler wrote:
On 3/13/2019 7:33 PM, Josh Steadmon wrote:
Persistently enabling trace2 output is difficult because it requires
specifying a full filename. This series teaches tr2_dst_get_trace_fd()
to randomize filename
On 3/16/2019 6:47 AM, tbo...@web.de wrote:
From: Torsten Bögershausen
Some compilers don't allow NULL to be passed for a va_list.
Use va_list instead.
Signed-off-by: Torsten Bögershausen
Thanks for the fixup.
For future reference, can you elaborate on which compiler
and/or platform has
Hello,
we are periodically doing a 'git p4 sync' on a p4 clone that was initially
created by 'git p4 clone --bare //DEPOT'. Now on P4 side the mail addresses have
changed, but git still uses the old addresses.
p4 users already shows the new addresses but new changes in the git log are
showing the
On Mon, Mar 18, 2019 at 11:54 AM Junio C Hamano wrote:
> I often find "git reset --hard " after a
It still bugs me that I need to use this to abort some in-progress
operation. There's "git X --abort" but I would need to find out what X
is first. I would like "git abort" or something (and "git con
On Fri, Mar 15, 2019 at 06:38:07PM -0700, nbelakov...@gmail.com wrote:
> diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
> index ceb74e0826..e5dc23e225 100755
> --- a/t/t3203-branch-output.sh
> +++ b/t/t3203-branch-output.sh
> @@ -328,4 +328,23 @@ test_expect_success '--color overr
On Mon, Mar 18, 2019 at 9:03 AM Junio C Hamano wrote:
>
> Elijah Newren writes:
>
> > I don't see why even makes sense to use with --orphan;
> > you should error if both are given, IMO. The point of --orphan is to
> > create some entirely new history. So, I'd expect "git switch --orphan
> > "
Phillip found out that 'git checkout -f ' does not restore
conflict/unmerged files correctly. All tracked files should be taken
from and all non-zero stages removed. Most of this is true,
except that the final file could be in stage one instead of zero.
"checkout -f" (among other commands) does t
On Sat, Mar 16 2019, Johannes Schindelin via GitGitGadget wrote:
> It was reported by Ævar Arnfjörð Bjarmason
> [https://public-inbox.org/git/nycvar.qro.7.76.6.1903142058130...@tvgsbejvaqbjf.bet/T/#mb8718fe52e4721dacd3b143a09187ff9090ef4e3]
> that there were problems with the fsmonitor feature i
Remove the rebase.useBuiltin setting, which was added as an escape
hatch to disable the builtin version of rebase first released with Git
2.20.
See [1] for the initial implementation of rebase.useBuiltin, and [2]
and [3] for the documentation and corresponding
GIT_TEST_REBASE_USE_BUILTIN option.
Hi Ævar
Thanks for doing this, it's great to see it from a maintenance
perspective as well as it meaning the builtin rebase is considered
stable. A couple small nit picks below
On 15/03/2019 13:45, Ævar Arnfjörð Bjarmason wrote:
Remove the rebase.useBuiltin setting, which was added as an esc
On 17/03/2019 08:18, Johannes Sixt wrote:
Am 16.03.19 um 23:09 schrieb Robert P. J. Day:
On Sat, 16 Mar 2019, Johannes Sixt wrote:
Am 16.03.19 um 13:22 schrieb Robert P. J. Day:
as a working example, i looked at the top-level .gitattributes file
in the git source code itself, which opens w
On Mon, Mar 18, 2019 at 1:16 AM Todd Zullinger wrote:
>
> From: Jeff King
>
> Normally code that is checking config before we've decided to do
> setup_git_directory() would use read_early_config(), which uses
> discover_git_directory() to tentatively see if we're in a repo,
> and if so to add it
Duy Nguyen writes:
>> > + test_cmp_rev :1:a $A_OBJ &&
>> > + test_cmp_rev :2:a $B_OBJ &&
>> > + test_cmp_rev :3:a $C_OBJ &&
>> > + git checkout -f topic &&
>> > + test_cmp_rev :a $A_OBJ
>>
>> So in short, "checkout -f" should have given us an entry for path
>> "a", taken from
On Mon, Mar 18, 2019 at 10:58 AM Junio C Hamano wrote:
>
> Nguyễn Thái Ngọc Duy writes:
>
> > One-way merge is supposed to take stat info from the index and
> > everything else from the given tree. This implies stage 0 because trees
> > can't have non-zero stages. The add_entry(.., old, ...) cal
On 18/03/2019 06:42, Junio C Hamano wrote:
>> diff --git a/Documentation/gitattributes.txt
>> b/Documentation/gitattributes.txt
>> index 9b41f81c06..908d9a3009 100644
>> --- a/Documentation/gitattributes.txt
>> +++ b/Documentation/gitattributes.txt
>> @@ -314,8 +314,8 @@ stored as UTF-8 internally.
Denton Liu writes:
>> > Here you could swap the order of when you write to 'act' and 'tmp',
>> > and thus make the 'mv' unnecessary, like this:
>> >
>> > git commit [...] >tmp &&
>> > head -1 act >tmp &&
>> > [...rest of the test...]
>> >
>> > Note also that 'head' (or 'sed' in later tests)
Ævar Arnfjörð Bjarmason writes:
> No objections to changing this, but I don't think it's the fault of a
> commit message if someone reading it doesn't get an explanation for a
> future unrelated improvement.
>
> The times when a commit should have such an explanation are cases like
> e.g. introdu
Duy Nguyen writes:
> One of the problems I
> have with separating tests from the actual code change is the
> description of the problem often stays on the test commit, which I
> can't see in git-log if I'm searching for the code change.
In the message you are reponding to, Dscho made it sou
Hi Junio,
On Mon, Mar 18, 2019 at 03:35:56PM +0900, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
> >> + git commit ${3+"$3"} -m "$2" >act &&
> >> + head -1 tmp &&
> >> + mv tmp act &&
> >
> > Here you could swap the order of when you write to 'act' and 'tmp',
> > and thus make the 'mv' unne
On Sun, Mar 17 2019, Thomas Gummerer wrote:
> On 03/17, Ævar Arnfjörð Bjarmason wrote:
>>
>> On Sun, Mar 17 2019, Jonathan Chang wrote:
>>
>> > Signed-off-by: Jonathan Chang
>> > ---
>> > t/t-basic.sh | 7 +++
>> > 1 file changed, 3 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/
Johannes Schindelin writes:
>> "gir rebase" that was reimplemented in C did not set ORIG_HEAD
>
> s/gir/git/ (assuming that you use these descriptions to generate the
> announcement mails?)
Thanks.
Alexander Blesius writes:
> Signed-off-by: Alexander Blesius
> ---
> Documentation/git-worktree.txt | 4 ++--
> Documentation/gitattributes.txt | 4 ++--
> 2 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
> index
On Mon, 2019-03-18 at 15:28 +0900, Junio C Hamano wrote:
> Joe Perches writes:
>
> > My preference would be for correctness.
> > I presume something like this isn't too onerous.
>
> I am guessing that /^---/ is to stop at the three-dash line *OR*
> after the initial handful of lines of the first
Junio C Hamano writes:
> Johannes Schindelin writes:
>
>> Fine. But in that case, I would appreciate not being reminded of the
>> messiness. Not unless you let me do something about it. Don't put me
>> between a rock and a hard place, please.
Perhaps your attitude is coming from a fundamental m
98 matches
Mail list logo
