"Kunal Tyagi via GitGitGadget" writes:
> From: Kunal Tyagi
>
> Report the current hunk count and total number of hunks for the current
> file in the prompt
> Adjust the expected output in some tests to account for new data on the prompt
>
> Signed-off-by: Kunal Tyagi
> ---
> git-add--interacti
Denton Liu writes:
> Range-diff against v1:
> 1: e77af8cde5 = 1: e77af8cde5 test-lib: let test_merge() perform octopus
> merges
micronit: I would say s/let/allow/ if I were writing this.
> 2: 4a93deb3f6 = 2: 4a93deb3f6 t4214: use test_merge
> 3: c09f761185 = 3: c09f761185 t4214: generate
Elijah Newren writes:
> This series improves the incremental export story for fast-export and
> fast-import (--export-marks and --import-marks fell a bit short),
> fixes a couple small export/import bugs, and enables handling nested
> tags. In particular, the nested tags handling makes it so tha
"Johannes Schindelin via GitGitGadget"
writes:
> +test_expect_success 'parallel' '
> + git remote add one ./bogus1 &&
> + git remote add two ./bogus2 &&
> +
> + test_must_fail env GIT_TRACE="$PWD/trace" \
> + git fetch --jobs=2 --multiple one two 2>err &&
> + grep "2 t
Eric Wong writes:
> That seems too tedious. I'm learning towards just initializing
> var = NULL in the start of the for-loop:
>
> @@ -449,7 +449,8 @@ static inline struct hashmap_entry
> *hashmap_iter_first(struct hashmap *map,
> * containing a @member which is a "struct hashmap_entry"
> */
Junio C Hamano wrote:
> Eric Wong writes:
>
> > In the future, list iterator macros (e.g. list_for_each_entry)
> > may also be implemented using OFFSETOF_VAR to save hackers the
> > trouble of using container_of/list_entry macros and without
> > relying on non-portable `__typeof__'.
>
> Can we
Eric Wong writes:
> In the future, list iterator macros (e.g. list_for_each_entry)
> may also be implemented using OFFSETOF_VAR to save hackers the
> trouble of using container_of/list_entry macros and without
> relying on non-portable `__typeof__'.
Can we add something like this as a preliminar
Josh Steadmon writes:
> trace2 can write files into a target directory. With heavy usage, this
> directory can fill up with files, causing difficulty for
> trace-processing systems.
Sorry for not mentioning this, but "don't overload" is a suboptimal
keyword for the entire topic and for this part
Before, the expect files of the test case were being generated in the
setup method. However, it would make more sense to generate these files
within the test cases that actually use them so that it's obvious to
future readers where the expected values are coming from.
Move the generation of the ex
In the previous commit, we extended test_merge() so that it could
perform octopus merges. Now that the restriction is lifted, use
test_merge() to perform the octopus merge instead of manually
duplicating test_merge() functionality.
Signed-off-by: Denton Liu
---
t/t4214-log-graph-octopus.sh | 3 +
Junio, the test cases from earlier didn't exactly cover the cases Peff
talked about so I added a few more test cases. These should cover those
situations and a few more so we can be extra sure when the bug is fixed.
This patchset cleans up t4214 and then, in the last patch, demonstrates
a bug in
In a future test case, we will be extending the commit graph. As a
result, explicitly list the tags that will generate the graph so that
when future additions are made, the current graph illustrations won't be
affected.
Signed-off-by: Denton Liu
---
t/t4214-log-graph-octopus.sh | 8
1 f
The graph coloring logic for octopus merges currently has a bug. This
can be seen git.git with 74c7cfa875 (Merge of
http://members.cox.net/junkio/git-jc.git, 2005-05-05), whose second
child is 211232bae6 (Octopus merge of the following five patches.,
2005-05-05).
If one runs
git log --gra
Currently test_merge() only allows developers to merge in one branch.
However, this restriction is artificial and there is no reason why it
needs to be this way.
Extend test_merge() to allow the specification of multiple branches so
that octopus merges can be performed.
Signed-off-by: Denton Liu
"William Baker via GitGitGadget" writes:
> create mode 100755 t/t7519/fsmonitor-env
> ...
> + if (pos >= istate->cache_nr)
> + BUG("fsmonitor_dirty has more entries than the index
> (%"PRIuMAX" >= %"PRIuMAX")",
> + (uintmax_t)pos, (uintmax_t)istate->cache_nr);
T
Move the description of trace2's target-directory behavior into the
shared trace2-target-values file so that it is included in both the
git-config and api-trace2 docs. Leave the SID discussion only in
api-trace2 since it's a technical detail.
Signed-off-by: Josh Steadmon
---
Documentation/techni
trace2 can write files into a target directory. With heavy usage, this
directory can fill up with files, causing difficulty for
trace-processing systems.
This patch adds a config option (trace2.maxFiles) to set a maximum
number of files that trace2 will write to a target directory. The
following b
Add a new "overload" event type for trace2 event destinations. When the
trace2 overload feature creates a sentinel file, it will include the
normal trace2 output in the sentinel, along with this new overload
event.
Writing this message into the sentinel file is useful for tracking how
often the ov
Apologies for the delayed reply. I've added a new documentation patch
describing what we expect w.r.t. the version event and its "evt" field.
I've also reworked the final patch to allow writing a full trace session
to the sentinel file, and to make sure that the overload event comes
after the versi
Make it explicit that we always want trace2 "version" events to be the
first event of any trace session. Also list the changes that would or
would not cause the EVENT format version field to be incremented.
Signed-off-by: Josh Steadmon
---
Documentation/technical/api-trace2.txt | 8 +++-
1 f
Johannes Schindelin writes:
> Hi all,
>
> On Thu, 3 Oct 2019, William Baker via GitGitGadget wrote:
>
>> This patch series fixes a segfault that I encountered while testing
>> fsmonitor. Under some circumstances, the fsmonitor extension was being
>> written with too many bits, and subsequent git
René Scharfe writes:
> Found with "git grep '^#include ' '*.c' | sort | uniq -d".
>
> Signed-off-by: René Scharfe
> ---
> Patch formatted with --function-context for easier review.
I have a mixed feelings about that.
The only audience benefitted by --function-context patch are those
who read t
Carlo Arenas writes:
> or we could drop the current branch in pu and start again from scratch
> now that all of the required dependencies had been merged.
That would be the cleanest from my point of view. Thanks, both.
Duy Nguyen writes:
> On Thu, Oct 3, 2019 at 7:52 AM Junio C Hamano wrote:
>> > In fact, running `git am --show-current-patch` shows the whole mail, not
>> > only the 'patch' file so users would have no reason to expect the line
>> > numbers to refer to the 'patch' file.
>>
>> Yeah, show-current-
"William Baker via GitGitGadget" writes:
> This is the third iteration of changes for adding support for
> --[no-]progress to multi-pack-index, and it includes the following updates
> for the feedback I received on v2:
>
> * Fixed commit message formatting
> * Updated 'pack_paths_checked' from
"Johannes Schindelin via GitGitGadget"
writes:
> While at it, we take care of reporting overflows (which are unlikely,
> but hey, defensive programming is good!).
>
> We _also_ take pains of casting the unsigned value to signed: otherwise,
> the signed operand (i.e. the `-1`) would be cast to uns
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> This function is marked as `NORETURN`, and it indeed does not want to
> return anything. So let's not declare it with the return type `int`.
> This fixes the following warning when building with MSVC:
>
> C4646:
when running git commands outside of a git repo, we often see:
fatal: Not a git repository (or any of the parent directories): .git
such a lame message lol.
can we get an absolute path on this message in future git versions, eg:
Not a git repository (or any of the parent directories): /home/ubun
Elijah Newren writes:
> Actually, René posted a code cleanup suggestion for patch 2/8, so I
> sent a V3 re-roll[1]. Could you pick up V3 instead of merging V2 down
> to next?
>
> [1] https://public-inbox.org/git/20191003202709.26279-1-new...@gmail.com/
Thanks for stopping me.
Will take a look.
Emily Shaffer writes:
> On Thu, Oct 03, 2019 at 02:04:39PM +0900, 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
Derrick Stolee writes:
> On 9/19/2019 10:43 AM, Derrick Stolee via GitGitGadget wrote:
>> This series makes the sparse-checkout feature more user-friendly. While
>> there, I also present a way to use a limited set of patterns to gain a
>> significant performance boost in very large repositories.
"Johannes Schindelin via GitGitGadget"
writes:
> diff --git a/builtin/stash.c b/builtin/stash.c
> index b5a301f24d..a1e2e7ae7e 100644
> --- a/builtin/stash.c
> +++ b/builtin/stash.c
> @@ -497,6 +497,8 @@ static int do_apply_stash(const char *prefix, struct
> stash_info *info,
>*/
Jeff King writes:
> That works for the diagram in the code:
>
>| *---.
>| |\ \ \
>|/ / / /
>x 0 1 2
>
> where one of the parent lines is collapsing back to the left. But not
> for this more mundane case:
>
> | *-. commit 211232bae64bcc60bbf5
On 03/10/2019 21:35, Emily Shaffer wrote:
Hi George, it sounds like you are probably using Git for Windows
(https://github.com/git-for-windows/git).
I'm actually not very familiar with how folks who primarily use GfW as
their client manage their contributions to the main Git project.
However, I
Hi Harish,
Thanks for the patch. Unfortunately, it seems your mail client messed up
the formatting, and the patch won't apply. I'm guessing it is because
your mail client broke long lines into two, messing up the diff.
We use an email-based workflow, so please either configure your mail
client
On 03/10/2019 21:54, Pratyush Yadav wrote:
My only remaining bikeshed question it prompted was to check which parts
would be committed as part of committing the whole "hunk". But haven't had
time to look at all!
I'm not sure what you mean by "committing the whole hunk". In a merge
conflict state
Hi,
yes, there is no `make` or `gcc` available on Windows by default. You
will have to download and install the Git for Windows SDK:
https://gitforwindows.org/#download-sdk
Ciao,
Johannes
On Thu, 3 Oct 2019, Emily Shaffer wrote:
> Hi George, it sounds like you are probably using Git for Window
Hi all,
On Thu, 3 Oct 2019, William Baker via GitGitGadget wrote:
> This patch series fixes a segfault that I encountered while testing
> fsmonitor. Under some circumstances, the fsmonitor extension was being
> written with too many bits, and subsequent git commands would segfault when
> trying t
On 03/10/19 09:02PM, Philip Oakley wrote:
> On 30/09/2019 13:17, Bert Wesarg wrote:
> > Pratyush,
> >
> > On Sun, Sep 29, 2019 at 5:04 PM Pratyush Yadav
> > wrote:
> > > Hi Philip, Bert,
> > >
> > > Is there any way I can test this change? Philip, I ran the rebase you
> > > mention in the GitHu
From: Arash Bannazadeh-Mahani
The change is stemmed from a problem on the MacOS where, if --all
is passed to gitk it should show all the refs/commits graphically.
However, on really large git repos, in my instance a git repo with
over 52,000 commits, gitk will report an error,
"Error executing gi
gitk: no need to specify all refs, since git log --all is the same as list
is all the refs/commit ids. Also Mac OS has a limit on size of the list of
params for a command line
Arash Bannazadeh-Mahani (1):
gitk: Addressing error running on MacOS with large repos.
gitk-git/gitk | 7 ++-
1 fi
Hi George, it sounds like you are probably using Git for Windows
(https://github.com/git-for-windows/git).
I'm actually not very familiar with how folks who primarily use GfW as
their client manage their contributions to the main Git project.
However, I know there are plenty - the GfW maintainer i
On Wed, Oct 2, 2019 at 10:22 PM Junio C Hamano wrote:
>
> * en/fast-imexport-nested-tags (2019-10-02) 8 commits
> - fast-export: handle nested tags
> - t9350: add tests for tags of things other than a commit
> - fast-export: allow user to request tags be marked with --mark-tags
> - fast-export
Signed-off-by: Elijah Newren
---
builtin/fast-export.c | 30 ++
t/t9350-fast-export.sh | 2 +-
2 files changed, 19 insertions(+), 13 deletions(-)
diff --git a/builtin/fast-export.c b/builtin/fast-export.c
index d32e1e9327..58a74de42a 100644
--- a/builtin/fast-export
fast-import has support for both an --import-marks flag and an
--import-marks-if-exists flag; the latter of which will not die() if the
file does not exist. fast-export only had support for an --import-marks
flag; add an --import-marks-if-exists flag for consistency.
Signed-off-by: Elijah Newren
Multiple changes here:
* add a test for a tag of a blob
* add a test for a tag of a tag of a commit
* add a comment to the tests for (possibly nested) tags of trees,
making it clear that these tests are doing much less than you might
expect
Signed-off-by: Elijah Newren
---
t/t9350-
Mark identifiers are used in fast-export and fast-import to provide a
label to refer to earlier content. Blobs are given labels because they
need to be referenced in the commits where they first appear with a
given filename, and commits are given labels because they can be the
parents of other com
Add a new option, --mark-tags, which will output mark identifiers with
each tag object. This improves the incremental export story with
--export-marks since it will allow us to record that annotated tags have
been exported, and it is also needed as a step towards supporting nested
tags.
Signed-of
If our input stream includes a tag which is later deleted, we were not
properly deleting it. We did have a step which would delete it, but we
left a tag in the tag list noting that it needed to be updated, and the
updating of annotated tags occurred AFTER ref deletion. So, when we
record that a t
fast-export and fast-import have nice --import-marks flags which allow
for incremental migrations. However, if there is a mark in
fast-export's file of marks without a corresponding mark in the one for
fast-import, then we run the risk that fast-export tries to send new
objects relative to the mar
This series improves the incremental export story for fast-export and
fast-import (--export-marks and --import-marks fell a bit short),
fixes a couple small export/import bugs, and enables handling nested
tags. In particular, the nested tags handling makes it so that
fast-export and fast-import ca
fast-export allows specifying revision ranges, which can be used to
export a tag without exporting the commit it tags. fast-export handled
this rather poorly: it would emit a "from :0" directive. Since marks
start at 1 and increase, this means it refers to an unknown commit and
fast-import will c
On 03/10/2019 19:02, Rohit Sanjay wrote:
subscribe me
try http://vger.kernel.org/vger-lists.html#git for more info...
(email to majord...@vger.kernel.org
body = `subscribe git`)
--
Philip
PS. the list uses bottom posting
https://en.wikipedia.org/wiki/Posting_style
On 30/09/2019 13:17, Bert Wesarg wrote:
Pratyush,
On Sun, Sep 29, 2019 at 5:04 PM Pratyush Yadav wrote:
Hi Philip, Bert,
Is there any way I can test this change? Philip, I ran the rebase you
mention in the GitHub issue [0], and I get that '9c8cba6862abe5ac821' is
an unknown revision.
Is ther
From: William Baker
While doing some testing with fsmonitor enabled I found
that git commands would segfault after staging and
unstaging an untracked file. Looking at the crash it
appeared that fsmonitor_ewah_callback was attempting to
adjust bits beyond the bounds of the index cache.
Digging i
This patch series fixes a segfault that I encountered while testing
fsmonitor. Under some circumstances, the fsmonitor extension was being
written with too many bits, and subsequent git commands would segfault when
trying to apply the bits to the index.
As part of these changes I've added some BUG
On Thu, Oct 03, 2019 at 02:04:39PM +0900, 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 branche
Hi Carlo,
On Thu, 3 Oct 2019, Carlo Arenas wrote:
> On Thu, Oct 3, 2019 at 1:09 AM Johannes Schindelin
> wrote:
> > I still need
> > https://github.com/git-for-windows/git/commit/719beb813e4f27f090696ce583df3e5f3c480545
> > and
> > https://github.com/git-for-windows/git/commit/3369c322bbd95820b9
subscribe me
From: William Baker
Add progress to write_midx_file. Progress is displayed
when the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/midx.c b/midx.c
index b2673f52e8..0808a40dd4 10
From: William Baker
Update midx_repack to only display progress when
the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/midx.c b/midx.c
index ced5898bbf..1c5ddeb007 100644
--- a/midx.c
+++ b/midx.c
@@ -1374,6 +1374,1
From: William Baker
Add the --[no-]progress option to git multi-pack-index.
Pass the MIDX_PROGRESS flag to the subcommand functions
when progress should be displayed by multi-pack-index.
The progress feature was added to 'verify' in 144d703
("multi-pack-index: report progress during 'verify'", 20
From: William Baker
Add the MIDX_PROGRESS flag and update the
write|verify|expire|repack functions in midx.h
to accept a flags parameter. The MIDX_PROGRESS
flag indicates whether the caller of the function
would like progress information to be displayed.
This patch only changes the method protot
From: William Baker
Update verify_midx_file to only display progress when
the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/midx.c b/midx.c
index f14bebb092..ced5898bbf 100644
--- a/m
From: William Baker
Add progress to expire_midx_packs. Progress is
displayed when the MIDX_PROGRESS flag is set.
Signed-off-by: William Baker
---
midx.c | 12
1 file changed, 12 insertions(+)
diff --git a/midx.c b/midx.c
index 0808a40dd4..f14bebb092 100644
--- a/midx.c
+++ b/mid
Hello Git contributors,
This is the third iteration of changes for adding support for
--[no-]progress to multi-pack-index, and it includes the following updates
for the feedback I received on v2:
* Fixed commit message formatting
* Updated 'pack_paths_checked' from u32 to unsigned
Thanks, Will
Denton,
On Wed, Oct 2, 2019 at 11:47 PM Denton Liu wrote:
>
> Hi Bert,
>
> > Subject: format-patch: document and exercise that -o does only create the
> > trailing directory
>
> s/does only create/only creates/ ?
>
> Anyway, as a prepatory patch, I don't think that it's necessary. Maybe
> it's j
Hi All,
I', Just reopening this feature request.
A quick summary of my proposal is given below.
1. This PR will allow an additional configuration option
"guitool..gitgui-shortcut" which will allow us to specify
keyboard shortcut for custom commands in git-gui
2. Even there exists a parameter cal
Found with "git grep '^#include ' '*.c' | sort | uniq -d".
Signed-off-by: René Scharfe
---
Patch formatted with --function-context for easier review.
builtin/am.c | 1 -
builtin/blame.c| 1 -
builtin/clone.c| 1 -
builtin/describe.c | 1 -
builtin/rev-list.c | 1 -
builtin/worktre
Am 30.09.19 um 23:10 schrieb Elijah Newren:
> If our input stream includes a tag which is later deleted, we were not
> properly deleting it. We did have a step which would delete it, but we
> left a tag in the tag list noting that it needed to be updated, and the
> updating of annotated tags occur
On Thu, Oct 3, 2019 at 1:09 AM Johannes Schindelin
wrote:
> I still need
> https://github.com/git-for-windows/git/commit/719beb813e4f27f090696ce583df3e5f3c480545
> and
> https://github.com/git-for-windows/git/commit/3369c322bbd95820b971701fef7db44b26dd826f
> to fix that part in Git for Windows' `s
Hi Junio,
On Thu, 3 Oct 2019, Junio C Hamano wrote:
> Carlo Arenas writes:
>
> > On Tue, Aug 27, 2019 at 2:07 AM Johannes Schindelin
> > wrote:
> >>
> >> Unfortunately, this is _still_ incorrect.
> > ...
> > Just to clarify, I think my patch accounts for that (haven't tested
> > that assumption
72 matches
Mail list logo
