* Re: [PATCH v4 4/6] revision: implement sparse algorithm
From: Derrick Stolee @ 2018-12-17 14:20 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason,
Derrick Stolee via GitGitGadget
Cc: git, peff, jrnieder, Junio C Hamano, Derrick Stolee
In-Reply-To: <87efaj1y77.fsf@evledraar.gmail.com>
On 12/14/2018 6:32 PM, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Dec 14 2018, Derrick Stolee via GitGitGadget wrote:
>
>> Despite these potential drawbacks, the benefits of the algorithm
>> are clear. By adding a counter to 'add_children_by_path' and
>> 'mark_tree_contents_uninteresting', I measured the number of
>> parsed trees for the two algorithms in a variety of repos.
> We spend a long time printing those out before we ever get to
> "Enumerating objects".
>
> Which was where I was trying to test this, i.e. is this a lot of work we
> perform before we print out the progress bar, and regardless of this
> optimization should have other progress output there, so we can see this
> time we're spending on this?
It is true that part of the problem is that a 'git push' will sit for a
while without presenting any feedback until this part of the algorithm
is complete. The current series intends to significantly reduce this time.
As for adding progress to this step, I'm open to it. It can be done as a
sequel series.
What would we use to describe this section? "Enumerating remote objects"?
Thanks,
-Stolee
^ permalink raw reply
* Can git tell me which uncommitted files clash with the incoming changes?
From: Mark Kharitonov @ 2018-12-17 13:08 UTC (permalink / raw)
To: git
Hi,
I have asked this question on SO
(https://stackoverflow.com/questions/53679167/can-git-tell-me-which-uncommitted-files-clash-with-the-incoming-changes)
and usually there are tons of responses on Git questions, but not on
this one.
Allow me to quote it now.
Please, observe:
C:\Dayforce\test [master ↓2 +0 ~2 -0 !]> git pull
error: Your local changes to the following files would be
overwritten by merge:
2.txt
Please commit your changes or stash them before you merge.
Aborting
Updating 2dc8bd0..ea343f8
C:\Dayforce\test [master ↓2 +0 ~2 -0 !]>
Does git have a command that can tell me which uncommitted files cause
the this error? I can see them displayed by git pull, but I really do
not want to parse git pull output.
I am fully aware of `pull.rebase` and `rebase.autostash` config
options, please do not bring them up.
**EDIT 1**
It is OK to execute `git pull` first. In fact, the logic to identify
the problematic files will be done after `git pull` fails with this
reason. The way I recognize it in Powershell is:
git pull
# Possible exit codes:
# 1 - either local changes or pull merge conflict (but the merge
has not been started yet)
# 128 - a merge is in progress
if ($LASTEXITCODE)
{
git merge HEAD 2> $null # Disambiguate
the exit code
if ($LASTEXITCODE -eq 128)
{
# Two options:
# - pull merge conflict
# - a merge is in progress
git mergetool
}
else
{
throw "Cannot pull due to uncommitted changes"
}
}
So, instead of aborting I would like to identify the problematic files
and essentially replicate the `rebase.autostash`, but without
`rebase`.
**EDIT 2**
I used to think that git pull outputs something like this in case of
clashes with uncommitted changes:
C:\xyz\test [master ↓4 ↑1 +0 ~3 -0 !]> git pull
error: Your local changes to the following files would be
overwritten by merge:
2.txt
a.txt
Please commit your changes or stash them before you merge.
Aborting
C:\xyz\test [master ↓4 ↑1 +0 ~3 -0 !]>
Which is easy to parse. But today, I got something different:
C:\xyz\test [master ↓4 ↑1 +0 ~2 -0 | +0 ~1 -0 !]> git pull
error: Your local changes to the following files would be
overwritten by merge:
1.txt a.txt
C:\xyz\test [master ↓4 ↑1 +0 ~2 -0 | +0 ~1 -0 !]>
I do not know if this has something to do with my Powershell console
having gotten botched somehow or with some recent git update, which I
had installed automatically without noticing it.
--
Be well and prosper.
==============================
"There are two kinds of people.Those whose guns are loaded and those who dig."
("The good, the bad and the ugly")
So let us drink for our guns always be loaded.
^ permalink raw reply
* Re: Bug in git-remote
From: Johannes Schindelin @ 2018-12-17 12:50 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Gennady Uraltsev, git
In-Reply-To: <20181215130204.GZ30222@szeder.dev>
[-- Attachment #1: Type: text/plain, Size: 2234 bytes --]
Hi Gábor,
On Sat, 15 Dec 2018, SZEDER Gábor wrote:
> On Sat, Dec 15, 2018 at 02:14:56AM -0500, Gennady Uraltsev wrote:
> > I am on git version 2.20.0
> >
> > $ git remote
> >
> > does not show remotes configured in named files in $GIT_DIR/remotes/
> >
> > I do not think that this is the intended behavior.
>
> It's a known bug. When 'git remote' was rewritten as a builtin
> command in C in commit 211c89682e (Make git-remote a builtin,
> 2008-02-29) the parts dealing with remotes under 'GIT_DIR/remotes/'
> were not rewritten. I don't know whether that was intended or not,
> but storing remote information as configuration was about two years
> old back then. Given that since then '$GIT_DIR/remotes/' got marked
> as "This mechanism is legacy and not likely to be found in modern
> repositories", I'm not sure it's worth fixing. Perhaps it's time for
> calling it deprecated.
I would be in favor of deprecating it, and then removing it.
However, when I tried a similar thing with the completely obsolete
`$GIT_DIR/branches/` feature, it was shot down IIRC on the mere suspicion
that there was a single remaining user among the Linux kernel lieutenants.
And I fear that the suspected workflow of that lieutenant involved having
those legacy remotes, too.
Hopefully this issue will be resolved somehow, as it is not exactly a
splendid idea to keep a legacy feature of a software used by millions,
just for a single user, I would think.
Ciao,
Dscho
>
>
> > In particular:
> >
> > $ git init --bare test.git
> > Initialized empty Git repository in /home/guraltsev/admin/test/git/test.git/
> >
> > $ cd test.git
> >
> > $ mkdir -p remotes
> > mkdir: created directory 'remotes'
> >
> > $ echo -e "URL: /testremote.git \n Push: *:* \n Pull:
> > refs/heads/*:refs/remotes/testremote/* " > remotes/testremote
> >
> > $ git remote
> >
> > $ git remote show testremote
> > fatal: '/testremote.git' does not appear to be a git repository
> > fatal: Could not read from remote repository.
> >
> > Please make sure you have the correct access rights
> > and the repository exists.
> >
> >
> >
> > The second to last command should show testremote as a remote.
> >
> >
> > Best,
> >
> > Gennady
> >
>
>
>
>
^ permalink raw reply
* Re: [PATCH] log: add %S option (like --source) to log --format
From: Junio C Hamano @ 2018-12-17 9:31 UTC (permalink / raw)
To: Issac Trotts; +Cc: git, Noemi Mercado
In-Reply-To: <CANdyxMwxPqTMfLsoK-2JT3Wf3hXZnQNCPRS04aSHzsMbYJZo-Q@mail.gmail.com>
Issac Trotts <issac.trotts@gmail.com> writes:
> Make it possible to write for example
>
> git log --format="%H,%S"
>
> where the %S at the end is a new placeholder that prints out the ref
> (tag/branch) for each commit.
>
> Using %d might seem like an alternative but it only shows the ref for
> the last commit in the branch.
Have your sign-off here (see Documentation/SubmittingPatches),
and then have a line that only has three-dashes on it,
and then any other additional info like this.
>
> This change is based on a question from Stack Overflow:
> https://stackoverflow.com/questions/12712775/git-get-source-information-in-format
> ---
> Documentation/pretty-formats.txt | 2 ++
> builtin/log.c | 2 +-
> log-tree.c | 1 +
> pretty.c | 10 +++++++
> t/t4205-log-pretty-formats.sh | 50 ++++++++++++++++++++++++++++++++
> 5 files changed, 64 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
> index 417b638cd..acfe7e0a4 100644
> --- a/Documentation/pretty-formats.txt
> +++ b/Documentation/pretty-formats.txt
> @@ -104,6 +104,8 @@ The placeholders are:
>
> - '%H': commit hash
> - '%h': abbreviated commit hash
> +- '%S': ref name given on the command line by which the commit was reached
> + (like `git log --source`)
This looks entirely out of place, among the description of the basic
basic data like the object name of the commit itself, its tree, etc.
Describe this immediately after %d and %D are explained, perhaps.
> diff --git a/builtin/log.c b/builtin/log.c
> index e8e51068b..a314ea2b6 100644
> --- a/builtin/log.c
> +++ b/builtin/log.c
> @@ -203,7 +203,7 @@ static void cmd_log_init_finish(int argc, const
> char **argv, const char *prefix,
> rev->diffopt.filter || rev->diffopt.flags.follow_renames)
> rev->always_show_header = 0;
>
> - if (source) {
> + if (source || (rev->pretty_given && rev->commit_format ==
> CMIT_FMT_USERFORMAT)) {
Broken line (you let your MUA line-wrap and corrupt your patch???)
> init_revision_sources(&revision_sources);
> rev->sources = &revision_sources;
> }
This means anybody who asks for say --format='%aN %s' pays the price
of keeping track of each commit's source, which is unreasonable.
Perhaps mimick the way how presence of %N is detected in
userformat_want_item() so that we do not pay the price for
init_display_notes() when a format that does not care about %N is
given?
> @@ -1149,6 +1150,15 @@ static size_t format_commit_one(struct strbuf
> *sb, /* in UTF-8 */
> parse_object(the_repository, &commit->object.oid);
>
> switch (placeholder[0]) {
> + case 'S': /* tag/branch like --source */
> + slot = revision_sources_at(c->pretty_ctx->rev->sources, commit);
> + if (slot && *slot) {
> + strbuf_addstr(sb, *slot);
> + return 1;
> + } else {
> + die(_("failed to get info for %%S"));
> + return 0;
> + }
Have this next to case arms that deal with 'd' and 'D".
> case 'H': /* commit hash */
> strbuf_addstr(sb, diff_get_color(c->auto_color, DIFF_COMMIT));
> strbuf_addstr(sb, oid_to_hex(&commit->object.oid));
This is a tangent, but I think this existing case arm should move to
the previous block before parsing the commit, as %H only needs the
object name of the commit itself (reword the comment before that
switch to read from "independent of the commit" to "computable
without parsing the commit")..
^ permalink raw reply
* [PATCH] log: add %S option (like --source) to log --format
From: Issac Trotts @ 2018-12-17 6:25 UTC (permalink / raw)
To: git; +Cc: Noemi Mercado
Make it possible to write for example
git log --format="%H,%S"
where the %S at the end is a new placeholder that prints out the ref
(tag/branch) for each commit.
Using %d might seem like an alternative but it only shows the ref for
the last commit in the branch.
This change is based on a question from Stack Overflow:
https://stackoverflow.com/questions/12712775/git-get-source-information-in-format
---
Documentation/pretty-formats.txt | 2 ++
builtin/log.c | 2 +-
log-tree.c | 1 +
pretty.c | 10 +++++++
t/t4205-log-pretty-formats.sh | 50 ++++++++++++++++++++++++++++++++
5 files changed, 64 insertions(+), 1 deletion(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 417b638cd..acfe7e0a4 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -104,6 +104,8 @@ The placeholders are:
- '%H': commit hash
- '%h': abbreviated commit hash
+- '%S': ref name given on the command line by which the commit was reached
+ (like `git log --source`)
- '%T': tree hash
- '%t': abbreviated tree hash
- '%P': parent hashes
diff --git a/builtin/log.c b/builtin/log.c
index e8e51068b..a314ea2b6 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -203,7 +203,7 @@ static void cmd_log_init_finish(int argc, const
char **argv, const char *prefix,
rev->diffopt.filter || rev->diffopt.flags.follow_renames)
rev->always_show_header = 0;
- if (source) {
+ if (source || (rev->pretty_given && rev->commit_format ==
CMIT_FMT_USERFORMAT)) {
init_revision_sources(&revision_sources);
rev->sources = &revision_sources;
}
diff --git a/log-tree.c b/log-tree.c
index 10680c139..3cb14256e 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -700,6 +700,7 @@ void show_log(struct rev_info *opt)
ctx.color = opt->diffopt.use_color;
ctx.expand_tabs_in_log = opt->expand_tabs_in_log;
ctx.output_encoding = get_log_output_encoding();
+ ctx.rev = opt;
if (opt->from_ident.mail_begin && opt->from_ident.name_begin)
ctx.from_ident = &opt->from_ident;
if (opt->graph)
diff --git a/pretty.c b/pretty.c
index b83a3ecd2..b1774acad 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1084,6 +1084,7 @@ static size_t format_commit_one(struct strbuf
*sb, /* in UTF-8 */
struct commit_list *p;
const char *arg;
int ch;
+ char **slot;
/* these are independent of the commit */
switch (placeholder[0]) {
@@ -1149,6 +1150,15 @@ static size_t format_commit_one(struct strbuf
*sb, /* in UTF-8 */
parse_object(the_repository, &commit->object.oid);
switch (placeholder[0]) {
+ case 'S': /* tag/branch like --source */
+ slot = revision_sources_at(c->pretty_ctx->rev->sources, commit);
+ if (slot && *slot) {
+ strbuf_addstr(sb, *slot);
+ return 1;
+ } else {
+ die(_("failed to get info for %%S"));
+ return 0;
+ }
case 'H': /* commit hash */
strbuf_addstr(sb, diff_get_color(c->auto_color, DIFF_COMMIT));
strbuf_addstr(sb, oid_to_hex(&commit->object.oid));
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-formats.sh
index 978a8a66f..7df8c3d4e 100755
--- a/t/t4205-log-pretty-formats.sh
+++ b/t/t4205-log-pretty-formats.sh
@@ -621,4 +621,54 @@ test_expect_success 'trailer parsing not fooled
by --- line' '
test_cmp expect actual
'
+test_expect_success 'set up %S tests' '
+ git checkout --orphan source-a &&
+ test_commit one &&
+ test_commit two &&
+ git checkout -b source-b HEAD^ &&
+ test_commit three
+'
+
+test_expect_success 'log --format=%S paints branch names' '
+ cat >expect <<-\EOF &&
+ source-b
+ source-a
+ source-b
+ EOF
+ git log --format=%S source-a source-b >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --format=%S paints tag names' '
+ git tag -m tagged source-tag &&
+ cat >expect <<-\EOF &&
+ source-tag
+ source-a
+ source-tag
+ EOF
+ git log --format=%S source-tag source-a >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'log --format=%S paints symmetric ranges' '
+ cat >expect <<-\EOF &&
+ source-b
+ source-a
+ EOF
+ git log --format=%S source-a...source-b >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '%S in git log --format works with other
placeholders (part 1)' '
+ git log --format="source-b %h" source-b >expect &&
+ git log --format="%S %h" source-b >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success '%S in git log --format works with other
placeholders (part 2)' '
+ git log --format="%h source-b" source-b >expect &&
+ git log --format="%h %S" source-b >actual &&
+ test_cmp expect actual
+'
+
test_done
--
2.19.1
^ permalink raw reply related
* Re: pack file object size question
From: Jonathan Nieder @ 2018-12-17 0:14 UTC (permalink / raw)
To: Farhan Khan; +Cc: git
In-Reply-To: <CAFd4kYAaMLvOhR_XvwoQ=y4c6CZC=+-q5BmAXO79qTKOLNFtZg@mail.gmail.com>
Hi,
Farhan Khan wrote:
>> Farhan Khan wrote:
>>> I am having trouble figuring out the boundary between two objects in
>>> the pack file.
[...]
> I think the issue is, the compressed object has a fixed
> size and git inflates it, then moves on to the next object. I am
> trying to figure out how where it identifies the size of the object.
Do you mean the compressed size or uncompressed size?
It sounds to me like pack-format.txt needs to do a better job of
distinguishing the two. Under "Pack file entry", I see
| Pack file entry: <+
|
| packed object header:
| 1-byte size extension bit (MSB)
| type (next 3 bit)
| size0 (lower 4-bit)
| n-byte sizeN (as long as MSB is set, each 7-bit)
| size0..sizeN form 4+7+7+..+7 bit integer, size0
| is the least significant part, and sizeN is the
| most significant part.
| packed object data:
| If it is not DELTA, then deflated bytes (the size above
| is the size before compression).
| If it is REF_DELTA, then
| 20-byte base object name SHA-1 (the size above is the
| size of the delta data that follows).
| delta data, deflated.
| If it is OFS_DELTA, then
| n-byte offset (see below) interpreted as a negative
| offset from the type-byte of the header of the
| ofs-delta entry (the size above is the size of
| the delta data that follows).
| delta data, deflated.
which suggests that the "length" field is something between the two:
it is the size of the inflated form of the packed object data, before
resolving deltas. It's useful for allocating a buffer to inflate
into.
The zlib container format (https://tools.ietf.org/html/rfc1950) does
not contain size information, so I believe you'll have to use a
"deflate" (https://tools.ietf.org/html/rfc1951) decoder such as zlib
to find the end of the deflated bytes.
In index-pack, you need to inflate the objects anyway. In random
lookups, the idx file tells you where to look, so it doesn't come up
there, either. So this would only be expected to come up if you are
doing a sort of partial index-pack that wants to skip some objects.
Thanks and hope that helps,
Jonathan
^ permalink raw reply
* Re: pack file object size question
From: Farhan Khan @ 2018-12-16 23:36 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20181216221457.GH75890@google.com>
On Sun, Dec 16, 2018 at 5:15 PM Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> Hi,
>
> Farhan Khan wrote:
>
> > I am trying to write an implementation of "git index-pack" and having
> > a bit of trouble with understanding the ".pack" format. Specifically,
> > I am having trouble figuring out the boundary between two objects in
> > the pack file.
>
> Have you seen Documentation/technical/pack-format.txt? If so, do you
> have ideas for improving it?
>
> Thanks,
> Jonathan
Hi Jonathan,
Yes, I have. I think the issue is, the compressed object has a fixed
size and git inflates it, then moves on to the next object. I am
trying to figure out how where it identifies the size of the object.
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE
^ permalink raw reply
* [PATCH] gitweb: correctly store previous rev in javascript-actions mode
From: Jonathan Nieder @ 2018-12-16 23:24 UTC (permalink / raw)
To: Robert Luberda; +Cc: git, Jakub Narębski
In-Reply-To: <53CECC87.7030209@debian.org>
From: Robert Luberda <robert@debian.org>
Date: Sun, 16 Mar 2014 22:57:19 +0100
Without this change, the setting
$feature{'javascript-actions'}{'default'} = [1];
in gitweb.conf breaks gitweb's blame page: clicking on line numbers
displayed in the second column on the page has no effect.
For comparison, with javascript-actions disabled, clicking on line
numbers loads the previous version of the line.
Addresses https://bugs.debian.org/741883.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Hi Robert,
Years ago, you sent this obviously correct patch to the link mentioned
above, but it got lost in the noise. Sorry about that. Hopefully
late is better than never.
May we forge your sign-off? See
https://www.kernel.org/pub/software/scm/git/docs/SubmittingPatches.html#sign-off
for more details about what this means.
Jakub et al, any thoughts? I don't see any unit tests in gitweb/static
that could avoid this regressing --- am I missing some, or if not any
hints for someone who would want to add a test framework?
Thanks,
Jonathan
gitweb/static/js/blame_incremental.js | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gitweb/static/js/blame_incremental.js b/gitweb/static/js/blame_incremental.js
index db6eb50584..e100d8206b 100644
--- a/gitweb/static/js/blame_incremental.js
+++ b/gitweb/static/js/blame_incremental.js
@@ -484,7 +484,7 @@ function processBlameLines(lines) {
case 'previous':
curCommit.nprevious++;
// store only first 'previous' header
- if (!'previous' in curCommit) {
+ if (!('previous' in curCommit)) {
var parts = data.split(' ', 2);
curCommit.previous = parts[0];
curCommit.file_parent = unquote(parts[1]);
--
2.20.0.405.gbc1bbc6f85
^ permalink raw reply related
* Re: pack file object size question
From: Jonathan Nieder @ 2018-12-16 22:14 UTC (permalink / raw)
To: Farhan Khan; +Cc: git
In-Reply-To: <CAFd4kYCHefqRsiFK=K7MHp=MTwOBXB5979WobEm3w1J5q1bZ0w@mail.gmail.com>
Hi,
Farhan Khan wrote:
> I am trying to write an implementation of "git index-pack" and having
> a bit of trouble with understanding the ".pack" format. Specifically,
> I am having trouble figuring out the boundary between two objects in
> the pack file.
Have you seen Documentation/technical/pack-format.txt? If so, do you
have ideas for improving it?
Thanks,
Jonathan
^ permalink raw reply
* [PATCH v3 3/3] branch: Add an extra verbose output displaying worktree path for refs checked out in a linked worktree
From: nbelakovski @ 2018-12-16 21:57 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
In-Reply-To: <20181216215759.24011-1-nbelakovski@gmail.com>
From: Nickolai Belakovski <nbelakovski@gmail.com>
---
builtin/branch.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/builtin/branch.c b/builtin/branch.c
index 2a24153b78..56589a3684 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -366,6 +366,10 @@ static char *build_format(struct ref_filter *filter, int maxwidth, const char *r
strbuf_addstr(&local, branch_get_color(BRANCH_COLOR_RESET));
strbuf_addf(&local, " %s ", obname.buf);
+ if (filter->verbose > 2)
+ strbuf_addf(&local, "%s%%(if:notequals=*)%%(HEAD)%%(then)%%(if)%%(worktreepath)%%(then)%%(worktreepath) %%(end)%%(end)%s",
+ branch_get_color(BRANCH_COLOR_WORKTREE), branch_get_color(BRANCH_COLOR_RESET));
+
if (filter->verbose > 1)
strbuf_addf(&local, "%%(if)%%(upstream)%%(then)[%s%%(upstream:short)%s%%(if)%%(upstream:track)"
"%%(then): %%(upstream:track,nobracket)%%(end)] %%(end)%%(contents:subject)",
--
2.14.2
^ permalink raw reply related
* [PATCH v3 2/3] branch: Mark and color a branch differently if it is checked out in a linked worktree
From: nbelakovski @ 2018-12-16 21:57 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
In-Reply-To: <20181216215759.24011-1-nbelakovski@gmail.com>
From: Nickolai Belakovski <nbelakovski@gmail.com>
In order to more clearly display which branches are active, the output
of git branch is modified to mark branches checkout out in a linked
worktree with a "+" and color them in cyan (in contrast to the current
branch, which will still be denoted with a "*" and colored in green)
This is meant to simplify workflows related to worktree, particularly
due to the limitations of not being able to check out the same branch in
two worktrees and the inability to delete a branch checked out in a
worktree. When performing branch operations like checkout and delete, it
would be useful to know more readily if the branches in which the user
is interested are already checked out in a worktree.
The git worktree list command contains the relevant information, however
this is a much less frquently used command than git branch.
---
builtin/branch.c | 12 ++++++++----
t/t3200-branch.sh | 8 ++++----
t/t3203-branch-output.sh | 21 +++++++++++++++++++++
3 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index 0c55f7f065..2a24153b78 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -47,6 +47,7 @@ static char branch_colors[][COLOR_MAXLEN] = {
GIT_COLOR_NORMAL, /* LOCAL */
GIT_COLOR_GREEN, /* CURRENT */
GIT_COLOR_BLUE, /* UPSTREAM */
+ GIT_COLOR_CYAN, /* WORKTREE */
};
enum color_branch {
BRANCH_COLOR_RESET = 0,
@@ -54,7 +55,8 @@ enum color_branch {
BRANCH_COLOR_REMOTE = 2,
BRANCH_COLOR_LOCAL = 3,
BRANCH_COLOR_CURRENT = 4,
- BRANCH_COLOR_UPSTREAM = 5
+ BRANCH_COLOR_UPSTREAM = 5,
+ BRANCH_COLOR_WORKTREE = 6
};
static const char *color_branch_slots[] = {
@@ -64,6 +66,7 @@ static const char *color_branch_slots[] = {
[BRANCH_COLOR_LOCAL] = "local",
[BRANCH_COLOR_CURRENT] = "current",
[BRANCH_COLOR_UPSTREAM] = "upstream",
+ [BRANCH_COLOR_WORKTREE] = "worktree",
};
static struct string_list output = STRING_LIST_INIT_DUP;
@@ -342,9 +345,10 @@ static char *build_format(struct ref_filter *filter, int maxwidth, const char *r
struct strbuf local = STRBUF_INIT;
struct strbuf remote = STRBUF_INIT;
- strbuf_addf(&local, "%%(if)%%(HEAD)%%(then)* %s%%(else) %s%%(end)",
- branch_get_color(BRANCH_COLOR_CURRENT),
- branch_get_color(BRANCH_COLOR_LOCAL));
+ strbuf_addf(&local, "%%(if)%%(HEAD)%%(then)* %s%%(else)%%(if)%%(worktreepath)%%(then)+ %s%%(else) %s%%(end)%%(end)",
+ branch_get_color(BRANCH_COLOR_CURRENT),
+ branch_get_color(BRANCH_COLOR_WORKTREE),
+ branch_get_color(BRANCH_COLOR_LOCAL));
strbuf_addf(&remote, " %s",
branch_get_color(BRANCH_COLOR_REMOTE));
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 478b82cf9b..e404f6e23c 100755
--- a/t/t3200-branch.sh
+++ b/t/t3200-branch.sh
@@ -292,7 +292,7 @@ test_expect_success 'git branch --list -v with --abbrev' '
test_expect_success 'git branch --column' '
COLUMNS=81 git branch --column=column >actual &&
cat >expected <<\EOF &&
- a/b/c bam foo l * master n o/p r
+ a/b/c + bam foo l * master n o/p r
abc bar j/k m/m master2 o/o q
EOF
test_cmp expected actual
@@ -307,7 +307,7 @@ test_expect_success 'git branch --column with an extremely long branch name' '
cat >expected <<EOF &&
a/b/c
abc
- bam
++ bam
bar
foo
j/k
@@ -332,7 +332,7 @@ test_expect_success 'git branch with column.*' '
git config --unset column.branch &&
git config --unset column.ui &&
cat >expected <<\EOF &&
- a/b/c bam foo l * master n o/p r
+ a/b/c + bam foo l * master n o/p r
abc bar j/k m/m master2 o/o q
EOF
test_cmp expected actual
@@ -349,7 +349,7 @@ test_expect_success 'git branch -v with column.ui ignored' '
cat >expected <<\EOF &&
a/b/c
abc
- bam
++ bam
bar
foo
j/k
diff --git a/t/t3203-branch-output.sh b/t/t3203-branch-output.sh
index ee6787614c..94ab05ad59 100755
--- a/t/t3203-branch-output.sh
+++ b/t/t3203-branch-output.sh
@@ -240,6 +240,27 @@ test_expect_success 'git branch --format option' '
test_i18ncmp expect actual
'
+test_expect_success '"add" a worktree' '
+ mkdir worktree_dir &&
+ git worktree add -b master_worktree worktree_dir master
+'
+
+cat >expect <<'EOF'
+* <GREEN>(HEAD detached from fromtag)<RESET>
+ ambiguous<RESET>
+ branch-one<RESET>
+ branch-two<RESET>
+ master<RESET>
++ <CYAN>master_worktree<RESET>
+ ref-to-branch<RESET> -> branch-one
+ ref-to-remote<RESET> -> origin/branch-one
+EOF
+test_expect_success TTY 'worktree colors correct' '
+ test_terminal git branch >actual.raw &&
+ test_decode_color <actual.raw >actual &&
+ test_cmp expect actual
+'
+
test_expect_success "set up color tests" '
echo "<RED>master<RESET>" >expect.color &&
echo "master" >expect.bare &&
--
2.14.2
^ permalink raw reply related
* [PATCH v3 1/3] ref-filter: add worktreepath atom
From: nbelakovski @ 2018-12-16 21:57 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
In-Reply-To: <20181216215759.24011-1-nbelakovski@gmail.com>
From: Nickolai Belakovski <nbelakovski@gmail.com>
Add an atom proving the path of the linked worktree where this ref is
checked out, if it is checked out in any linked worktrees, and empty
string otherwise.
---
Documentation/git-for-each-ref.txt | 4 +++
ref-filter.c | 70 ++++++++++++++++++++++++++++++++++++++
t/t6302-for-each-ref-filter.sh | 15 ++++++++
3 files changed, 89 insertions(+)
diff --git a/Documentation/git-for-each-ref.txt b/Documentation/git-for-each-ref.txt
index 901faef1bf..9590f7beab 100644
--- a/Documentation/git-for-each-ref.txt
+++ b/Documentation/git-for-each-ref.txt
@@ -209,6 +209,10 @@ symref::
`:lstrip` and `:rstrip` options in the same way as `refname`
above.
+worktreepath::
+ The absolute path to the worktree in which the ref is checked
+ out, if it is checked out in any linked worktree. ' ' otherwise.
+
In addition to the above, for commit and tag objects, the header
field names (`tree`, `parent`, `object`, `type`, and `tag`) can
be used to specify the value in the header field.
diff --git a/ref-filter.c b/ref-filter.c
index 5de616befe..e8713484a1 100644
--- a/ref-filter.c
+++ b/ref-filter.c
@@ -20,6 +20,8 @@
#include "commit-slab.h"
#include "commit-graph.h"
#include "commit-reach.h"
+#include "worktree.h"
+#include "hashmap.h"
static struct ref_msg {
const char *gone;
@@ -34,6 +36,8 @@ static struct ref_msg {
"ahead %d, behind %d"
};
+static struct worktree ** worktrees;
+
void setup_ref_filter_porcelain_msg(void)
{
msgs.gone = _("gone");
@@ -75,6 +79,12 @@ static struct expand_data {
struct object_info info;
} oi, oi_deref;
+struct reftoworktreeinfo_entry {
+ struct hashmap_entry ent; // must be the first member!
+ char * ref; // key into map
+ struct worktree * wt;
+};
+
/*
* An atom is a valid field atom listed below, possibly prefixed with
* a "*" to denote deref_tag().
@@ -114,6 +124,7 @@ static struct used_atom {
} objectname;
struct refname_atom refname;
char *head;
+ struct hashmap reftoworktreeinfo_map;
} u;
} *used_atom;
static int used_atom_cnt, need_tagged, need_symref;
@@ -420,6 +431,31 @@ static int head_atom_parser(const struct ref_format *format, struct used_atom *a
return 0;
}
+static int worktree_atom_parser(const struct ref_format *format,
+ struct used_atom *atom,
+ const char *arg,
+ struct strbuf *unused_err)
+{
+ int i;
+ worktrees = get_worktrees(0);
+
+ hashmap_init(&(atom->u.reftoworktreeinfo_map), NULL, NULL, 0);
+
+ for (i = 0; worktrees[i]; i++) {
+ if (worktrees[i]->head_ref) {
+ struct reftoworktreeinfo_entry *entry;
+ FLEXPTR_ALLOC_STR(entry, ref, worktrees[i]->head_ref);
+ hashmap_entry_init(entry, strhash(entry->ref));
+
+ entry->wt = worktrees[i];
+
+ hashmap_add(&(atom->u.reftoworktreeinfo_map), entry);
+ }
+ }
+
+ return 0;
+}
+
static struct {
const char *name;
info_source source;
@@ -461,6 +497,7 @@ static struct {
{ "flag", SOURCE_NONE },
{ "HEAD", SOURCE_NONE, FIELD_STR, head_atom_parser },
{ "color", SOURCE_NONE, FIELD_STR, color_atom_parser },
+ { "worktreepath", SOURCE_NONE, FIELD_STR, worktree_atom_parser },
{ "align", SOURCE_NONE, FIELD_STR, align_atom_parser },
{ "end", SOURCE_NONE },
{ "if", SOURCE_NONE, FIELD_STR, if_atom_parser },
@@ -1500,6 +1537,28 @@ static int get_object(struct ref_array_item *ref, int deref, struct object **obj
return 0;
}
+static const char * get_worktree_info(const struct used_atom *atom, const struct ref_array_item *ref)
+{
+ struct strbuf val = STRBUF_INIT;
+ struct reftoworktreeinfo_entry * entry;
+ struct reftoworktreeinfo_entry * lookup_result;
+
+ FLEXPTR_ALLOC_STR(entry, ref, ref->refname);
+ hashmap_entry_init(entry, strhash(entry->ref));
+ lookup_result = hashmap_get(&(atom->u.reftoworktreeinfo_map), entry, NULL);
+ free(entry);
+
+ if (lookup_result)
+ {
+ if (!strncmp(atom->name, "worktreepath", strlen(atom->name)))
+ strbuf_addstr(&val, lookup_result->wt->path);
+ }
+ else
+ strbuf_addstr(&val, " ");
+
+ return strbuf_detach(&val, NULL);
+}
+
/*
* Parse the object referred by ref, and grab needed value.
*/
@@ -1537,6 +1596,10 @@ static int populate_value(struct ref_array_item *ref, struct strbuf *err)
if (starts_with(name, "refname"))
refname = get_refname(atom, ref);
+ else if (starts_with(name, "worktreepath")) {
+ v->s = get_worktree_info(atom, ref);
+ continue;
+ }
else if (starts_with(name, "symref"))
refname = get_symref(atom, ref);
else if (starts_with(name, "upstream")) {
@@ -2013,7 +2076,14 @@ void ref_array_clear(struct ref_array *array)
int i;
for (i = 0; i < used_atom_cnt; i++)
+ {
+ if (!strncmp(used_atom[i].name, "worktreepath", strlen("worktreepath")))
+ {
+ hashmap_free(&(used_atom[i].u.reftoworktreeinfo_map), 1);
+ free_worktrees(worktrees);
+ }
free((char *)used_atom[i].name);
+ }
FREE_AND_NULL(used_atom);
used_atom_cnt = 0;
for (i = 0; i < array->nr; i++)
diff --git a/t/t6302-for-each-ref-filter.sh b/t/t6302-for-each-ref-filter.sh
index fc067ed672..add70a4c3e 100755
--- a/t/t6302-for-each-ref-filter.sh
+++ b/t/t6302-for-each-ref-filter.sh
@@ -441,4 +441,19 @@ test_expect_success '--merged is incompatible with --no-merged' '
test_must_fail git for-each-ref --merged HEAD --no-merged HEAD
'
+test_expect_success '"add" a worktree' '
+ mkdir worktree_dir &&
+ git worktree add -b master_worktree worktree_dir master
+'
+
+test_expect_success 'validate worktree atom' '
+ cat >expect <<-\EOF &&
+ master: checked out in a worktree
+ master_worktree: checked out in a worktree
+ side: not checked out in a worktree
+ EOF
+ git for-each-ref --format="%(refname:short): %(if)%(worktreepath)%(then)checked out in a worktree%(else)not checked out in a worktree%(end)" refs/heads/ >actual &&
+ test_cmp expect actual
+'
+
test_done
--
2.14.2
^ permalink raw reply related
* [PATCH v3 0/3]
From: nbelakovski @ 2018-12-16 21:57 UTC (permalink / raw)
To: git; +Cc: peff, rafa.almas, gitster, avarab, Nickolai Belakovski
In-Reply-To: <20181111235831.44824-1-nbelakovski@gmail.com>
From: Nickolai Belakovski <nbelakovski@gmail.com>
Finally got around to submitting latest changes.
I think this addresses all the feedback
The atom now returns the worktree path instead of '+'
I stuck to cyan for the coloring, since it seemed most popular
I added one more change to display the worktree path in cyan for git branch -vvv
Not sure if it's in the best place, but it seemed like it would be nice to add
the path in the same color so that there's some visibility as to why a particular
branch is colored in cyan. If it proves to be controversial, I wouldn't want it to
hold up this series, we can skip it and I can move discussion to a separate thread
(or just forget it, as the case may be)
Travis CI results: https://travis-ci.org/nbelakovski/git/builds/468569102
Nickolai Belakovski (3):
ref-filter: add worktreepath atom
branch: Mark and color a branch differently if it is checked out in a
linked worktree
branch: Add an extra verbose output displaying worktree path for refs
checked out in a linked worktree
Documentation/git-for-each-ref.txt | 4 +++
builtin/branch.c | 16 ++++++---
ref-filter.c | 70 ++++++++++++++++++++++++++++++++++++++
t/t3200-branch.sh | 8 ++---
t/t3203-branch-output.sh | 21 ++++++++++++
t/t6302-for-each-ref-filter.sh | 15 ++++++++
6 files changed, 126 insertions(+), 8 deletions(-)
--
2.14.2
^ permalink raw reply
* pack file object size question
From: Farhan Khan @ 2018-12-16 21:52 UTC (permalink / raw)
To: git
Hi all,
I am trying to write an implementation of "git index-pack" and having
a bit of trouble with understanding the ".pack" format. Specifically,
I am having trouble figuring out the boundary between two objects in
the pack file.
It seems that there is a 12 byte header (signature, version, number of
objects), then it immediately jumps into each individual object. The
object consists of the object header, then the zlib deflated object,
followed by a SHA1 of the above. Is this accurate? If so, where is the
size of the entire object size (object header + zlib deflated object +
sha) identified in git source? I tracked it down to what I believe is
builtin/index-pack.c under the function parse_pack_objects, the
for-loop currently in line 1138, but I cannot find where that object
size is calculated for the next iteration of the loop.
I think what I most specifically need is where the size of the
deflated object is identified.
Thanks,
--
Farhan Khan
PGP Fingerprint: B28D 2726 E2BC A97E 3854 5ABE 9A9F 00BC D525 16EE
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2018, #01; Sun, 9)
From: Alban Gruin @ 2018-12-16 21:48 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <xmqq8t0z3xcc.fsf@gitster-ct.c.googlers.com>
Hi Junio,
Le 09/12/2018 à 09:42, Junio C Hamano a écrit :> -%<-
> * ag/sequencer-reduce-rewriting-todo (2018-11-12) 16 commits
> . rebase--interactive: move transform_todo_file() to
rebase--interactive.c
> . sequencer: fix a call to error() in transform_todo_file()
> . sequencer: use edit_todo_list() in complete_action()
> . rebase-interactive: rewrite edit_todo_list() to handle the initial edit
> . rebase-interactive: append_todo_help() changes
> . rebase-interactive: use todo_list_write_to_file() in edit_todo_list()
> . sequencer: refactor skip_unnecessary_picks() to work on a todo_list
> . sequencer: change complete_action() to use the refactored functions
> . sequencer: make sequencer_make_script() write its script to a strbuf
> . sequencer: refactor rearrange_squash() to work on a todo_list
> . sequencer: refactor sequencer_add_exec_commands() to work on a
todo_list
> . sequencer: refactor check_todo_list() to work on a todo_list
> . sequencer: introduce todo_list_write_to_file()
> . sequencer: refactor transform_todos() to work on a todo_list
> . sequencer: make the todo_list structure public
> . sequencer: changes in parse_insn_buffer()
>
> The scripted version of "git rebase -i" wrote and rewrote the todo
> list many times during a single step of its operation, and the
> recent C-rewrite made a faithful conversion of the logic to C. The
> implementation has been updated to carry necessary information
> around in-core to avoid rewriting the same file over and over
> unnecessarily.
>
> With too many topics in-flight that touch sequencer and rebaser,
> this need to wait giving precedence to other topics that fix bugs.
>
If I’m not mistaken, there is currently 3 others series touching rebase,
rebase-interactive and/or the sequencer: en/rebase-merge-on-sequencer,
nd/the-index, and the new js/rebase-i-redo-exec. Among these, I believe
only nd/the-index actually touches the same places as
ag/sequencer-reduce-rewriting-todo, and is not a behaviour change.
Is this safe to reroll this in the next few days?
--
Alban
^ permalink raw reply
* Re: [PATCH] doc: short status for delete + intent-to-add
From: Duy Nguyen @ 2018-12-16 18:26 UTC (permalink / raw)
To: Anthony Sottile; +Cc: Git Mailing List
In-Reply-To: <20181216175536.5535-1-asottile@umich.edu>
On Sun, Dec 16, 2018 at 7:10 PM Anthony Sottile <asottile@umich.edu> wrote:
>
> $ git rm foo
> rm 'foo'
> $ touch foo
> $ git add --intent-to-add foo
> $ git status --short
> DA foo
Twisted, but not wrong. It may also be a good idea to describe
intent-to-add status, which is probably something like
[ D] A intent to add
>
> Signed-off-by: Anthony Sottile <asottile@umich.edu>
> ---
> Documentation/git-status.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
> index d9f422d56..4af7424e5 100644
> --- a/Documentation/git-status.txt
> +++ b/Documentation/git-status.txt
> @@ -202,7 +202,7 @@ in which case `XY` are `!!`.
> [AMD] not updated
> M [ MD] updated in index
> A [ MD] added to index
> - D deleted from index
> + D [ A] deleted from index
> R [ MD] renamed in index
> C [ MD] copied in index
> [MARC] index and work tree matches
> --
> 2.17.1
>
--
Duy
^ permalink raw reply
* [PATCH] doc: short status for delete + intent-to-add
From: Anthony Sottile @ 2018-12-16 17:55 UTC (permalink / raw)
To: git; +Cc: Anthony Sottile
$ git rm foo
rm 'foo'
$ touch foo
$ git add --intent-to-add foo
$ git status --short
DA foo
Signed-off-by: Anthony Sottile <asottile@umich.edu>
---
Documentation/git-status.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index d9f422d56..4af7424e5 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -202,7 +202,7 @@ in which case `XY` are `!!`.
[AMD] not updated
M [ MD] updated in index
A [ MD] added to index
- D deleted from index
+ D [ A] deleted from index
R [ MD] renamed in index
C [ MD] copied in index
[MARC] index and work tree matches
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2 0/3] A few Asciidoctor-fixes
From: Jeff King @ 2018-12-16 16:19 UTC (permalink / raw)
To: Martin Ågren; +Cc: git
In-Reply-To: <cover.1544969984.git.martin.agren@gmail.com>
On Sun, Dec 16, 2018 at 03:28:56PM +0100, Martin Ågren wrote:
> This series addresses a few instances where our documentation renders
> badly in Asciidoctor, compared to Asciidoc. The changes made are exactly
> the same as in v1 [1], but the first commit message is corrected, and
> the two patches 2/4 and 3/4 are now just a single patch 2/3.
>
> Thanks Peff for your comments on v1.
Thanks, this all looks quite sensible to me (I didn't hack up doc-diff
as you did, but I did eyeball the before/after html from asciidoctor).
-Peff
^ permalink raw reply
* Re: [PATCH 0/4] A few Asciidoctor-fixes
From: Jeff King @ 2018-12-16 16:17 UTC (permalink / raw)
To: Martin Ågren; +Cc: Git Mailing List
In-Reply-To: <CAN0heSrccWop+KRKFCTNHTB43XcAv+Q8X7p0hT1t2+rPjS1THA@mail.gmail.com>
On Sun, Dec 16, 2018 at 03:34:42PM +0100, Martin Ågren wrote:
> Your list seems complete to me in terms of "how could we teach doc-diff
> to diff asciidoctor vs asciidoc?". For the resulting diff to actually be
> useful ;-) there are two more outstanding issues that I see:
>
> - Headers and footers. Asciidoc (driven by doc-diff) uses some
> boilerplate values which avoid timestamps and the like. Asciidoctor
> partly uses different values, partly interprets the ones given
> differently.
>
> - Asciidoctor introduces a space after linkgit:foo , e.g., before
> punctuation.
>
> Both of these are problems in their own right, so they probably
> shouldn't be suppressed in the resulting diff. But as long as these
> issues remain, they produce a lot of noise which might hide more
> interesting (IMHO) differences.
If there are a small number of distinct problems (that each have many
instances), I'm not opposed to having a mode to suppress them in the
resulting diff, so we can see the other problems more clearly. Of
course, just fixing them is even better. ;)
The first one sounds like it may be a candidate for suppressing (i.e.,
it's not necessarily an actual problem).
-Peff
^ permalink raw reply
* [PATCH v2] worktree: allow to (re)move worktrees with uninitialized submodules
From: Nguyễn Thái Ngọc Duy @ 2018-12-16 14:46 UTC (permalink / raw)
To: pclouds, sunshine; +Cc: git
In-Reply-To: <20181216121239.10017-1-pclouds@gmail.com>
Uninitialized submodules have nothing valueable for us to be worried
about. They are just SHA-1. Let "worktree remove" and "worktree move"
continue in this case so that people can still use multiple worktrees
on repos with optional submodules that are never populated, like
sha1collisiondetection in git.git when checked out by doc-diff script.
Note that for "worktree remove", it is possible that a user
initializes a submodule (*), makes some commits (but not push), then
deinitializes it. At that point, the submodule is unpopulated, but the
precious new commits are still in
$GIT_COMMON_DIR/worktrees/<worktree>/modules/<submodule>
directory and we should not allow removing the worktree or we lose
those commits forever. The new directory check is added to prevent
this.
(*) yes they are screwed anyway by doing this since "git submodule"
would add submodule.* in $GIT_COMMON_DIR/config, which is shared
across multiple worktrees. But it does not mean we let them be
screwed even more.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Fixed Eric's comment. I was a bit annoyed by the duplicate die() too
but didn't think of adding "else" in front of "if (read_index"
builtin/worktree.c | 29 +++++++++++++++++++++++------
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/builtin/worktree.c b/builtin/worktree.c
index 5e84026177..3f9907fcc9 100644
--- a/builtin/worktree.c
+++ b/builtin/worktree.c
@@ -9,6 +9,7 @@
#include "refs.h"
#include "run-command.h"
#include "sigchain.h"
+#include "submodule.h"
#include "refs.h"
#include "utf8.h"
#include "worktree.h"
@@ -724,20 +725,36 @@ static int unlock_worktree(int ac, const char **av, const char *prefix)
static void validate_no_submodules(const struct worktree *wt)
{
struct index_state istate = { NULL };
+ struct strbuf path = STRBUF_INIT;
int i, found_submodules = 0;
- if (read_index_from(&istate, worktree_git_path(wt, "index"),
- get_worktree_git_dir(wt)) > 0) {
+ if (is_directory(worktree_git_path(wt, "modules"))) {
+ /*
+ * There could be false positives, e.g. the "modules"
+ * directory exists but is empty. But it's a rare case and
+ * this simpler check is probably good enough for now.
+ */
+ found_submodules = 1;
+ } else if (read_index_from(&istate, worktree_git_path(wt, "index"),
+ get_worktree_git_dir(wt)) > 0) {
for (i = 0; i < istate.cache_nr; i++) {
struct cache_entry *ce = istate.cache[i];
+ int err;
- if (S_ISGITLINK(ce->ce_mode)) {
- found_submodules = 1;
- break;
- }
+ if (!S_ISGITLINK(ce->ce_mode))
+ continue;
+
+ strbuf_reset(&path);
+ strbuf_addf(&path, "%s/%s", wt->path, ce->name);
+ if (!is_submodule_populated_gently(path.buf, &err))
+ continue;
+
+ found_submodules = 1;
+ break;
}
}
discard_index(&istate);
+ strbuf_release(&path);
if (found_submodules)
die(_("working trees containing submodules cannot be moved or removed"));
--
2.20.0.482.g66447595a7
^ permalink raw reply related
* Re: [PATCH 0/4] A few Asciidoctor-fixes
From: Martin Ågren @ 2018-12-16 14:34 UTC (permalink / raw)
To: Jeff King; +Cc: Git Mailing List
In-Reply-To: <20181216104458.GC13704@sigill.intra.peff.net>
On Sun, 16 Dec 2018 at 11:45, Jeff King <peff@peff.net> wrote:
>
> On Sat, Dec 15, 2018 at 12:27:38PM +0100, Martin Ågren wrote:
> I think the relevant bits from [1] are:
>
> * Use `make --always-make ... install-man` in doc-diff.
> * ./doc-diff -f HEAD HEAD # note -f
> * Add empty commit and tweak config.mak
> * ./doc-diff HEAD^ HEAD # note no -f
Yes, that's it.
> To make this easier, it would make sense to me to:
>
> - teach doc-diff a flag for marking one or both of the endpoints to be
> built with asciidoctor versus asciidoc
>
> - mark the asciidoc/asciidoctor in the directory name. That name
> serves as a cache key for avoiding re-doing the work, you should be
> able to just:
>
> ./doc-diff --asciidoctor HEAD HEAD
>
> and actually build and compare what you want.
>
> - it sounds from "make --always-make" that our Makefile does not
> properly rebuild when we switch from asciidoc to asciidoctor. That
Exactly.
> might be nice to fix with a mechanism similar to the GIT-BUILD-FLAGS
> we use in the top-level Makefile.
Agreed on all three points. The last one would supposedly be useful on
its own, beyond this doc-diff motivation.
Your list seems complete to me in terms of "how could we teach doc-diff
to diff asciidoctor vs asciidoc?". For the resulting diff to actually be
useful ;-) there are two more outstanding issues that I see:
- Headers and footers. Asciidoc (driven by doc-diff) uses some
boilerplate values which avoid timestamps and the like. Asciidoctor
partly uses different values, partly interprets the ones given
differently.
- Asciidoctor introduces a space after linkgit:foo , e.g., before
punctuation.
Both of these are problems in their own right, so they probably
shouldn't be suppressed in the resulting diff. But as long as these
issues remain, they produce a lot of noise which might hide more
interesting (IMHO) differences.
Martin
^ permalink raw reply
* [PATCH v2 3/3] git-status.txt: render tables correctly under Asciidoctor
From: Martin Ågren @ 2018-12-16 14:28 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <cover.1544969984.git.martin.agren@gmail.com>
Asciidoctor removes the indentation of each line in these tables, so the
last lines of each table have a completely broken alignment.
Similar to 379805051d ("Documentation: render revisions correctly under
Asciidoctor", 2018-05-06), use an explicit literal block to indicate
that we want to keep the leading whitespace in the tables.
Because this gives us some extra indentation, we can remove the one that
we have been carrying explicitly. That is, drop the first four spaces of
indentation on each line. With Asciidoc (8.6.10), this results in
identical rendering before and after this commit, both for git-status.1
and git-status.html.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
Documentation/git-status.txt | 162 ++++++++++++++++++-----------------
1 file changed, 85 insertions(+), 77 deletions(-)
diff --git a/Documentation/git-status.txt b/Documentation/git-status.txt
index d9f422d560..861d821d7f 100644
--- a/Documentation/git-status.txt
+++ b/Documentation/git-status.txt
@@ -197,31 +197,33 @@ codes can be interpreted as follows:
Ignored files are not listed, unless `--ignored` option is in effect,
in which case `XY` are `!!`.
- X Y Meaning
- -------------------------------------------------
- [AMD] not updated
- M [ MD] updated in index
- A [ MD] added to index
- D deleted from index
- R [ MD] renamed in index
- C [ MD] copied in index
- [MARC] index and work tree matches
- [ MARC] M work tree changed since index
- [ MARC] D deleted in work tree
- [ D] R renamed in work tree
- [ D] C copied in work tree
- -------------------------------------------------
- D D unmerged, both deleted
- A U unmerged, added by us
- U D unmerged, deleted by them
- U A unmerged, added by them
- D U unmerged, deleted by us
- A A unmerged, both added
- U U unmerged, both modified
- -------------------------------------------------
- ? ? untracked
- ! ! ignored
- -------------------------------------------------
+....
+X Y Meaning
+-------------------------------------------------
+ [AMD] not updated
+M [ MD] updated in index
+A [ MD] added to index
+D deleted from index
+R [ MD] renamed in index
+C [ MD] copied in index
+[MARC] index and work tree matches
+[ MARC] M work tree changed since index
+[ MARC] D deleted in work tree
+[ D] R renamed in work tree
+[ D] C copied in work tree
+-------------------------------------------------
+D D unmerged, both deleted
+A U unmerged, added by us
+U D unmerged, deleted by them
+U A unmerged, added by them
+D U unmerged, deleted by us
+A A unmerged, both added
+U U unmerged, both modified
+-------------------------------------------------
+? ? untracked
+! ! ignored
+-------------------------------------------------
+....
Submodules have more state and instead report
M the submodule has a different HEAD than
@@ -281,14 +283,16 @@ don't recognize.
If `--branch` is given, a series of header lines are printed with
information about the current branch.
- Line Notes
- ------------------------------------------------------------
- # branch.oid <commit> | (initial) Current commit.
- # branch.head <branch> | (detached) Current branch.
- # branch.upstream <upstream_branch> If upstream is set.
- # branch.ab +<ahead> -<behind> If upstream is set and
- the commit is present.
- ------------------------------------------------------------
+....
+Line Notes
+------------------------------------------------------------
+# branch.oid <commit> | (initial) Current commit.
+# branch.head <branch> | (detached) Current branch.
+# branch.upstream <upstream_branch> If upstream is set.
+# branch.ab +<ahead> -<behind> If upstream is set and
+ the commit is present.
+------------------------------------------------------------
+....
### Changed Tracked Entries
@@ -306,56 +310,60 @@ Renamed or copied entries have the following format:
2 <XY> <sub> <mH> <mI> <mW> <hH> <hI> <X><score> <path><sep><origPath>
- Field Meaning
- --------------------------------------------------------
- <XY> A 2 character field containing the staged and
- unstaged XY values described in the short format,
- with unchanged indicated by a "." rather than
- a space.
- <sub> A 4 character field describing the submodule state.
- "N..." when the entry is not a submodule.
- "S<c><m><u>" when the entry is a submodule.
- <c> is "C" if the commit changed; otherwise ".".
- <m> is "M" if it has tracked changes; otherwise ".".
- <u> is "U" if there are untracked changes; otherwise ".".
- <mH> The octal file mode in HEAD.
- <mI> The octal file mode in the index.
- <mW> The octal file mode in the worktree.
- <hH> The object name in HEAD.
- <hI> The object name in the index.
- <X><score> The rename or copy score (denoting the percentage
- of similarity between the source and target of the
- move or copy). For example "R100" or "C75".
- <path> The pathname. In a renamed/copied entry, this
- is the target path.
- <sep> When the `-z` option is used, the 2 pathnames are separated
- with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
- byte separates them.
- <origPath> The pathname in the commit at HEAD or in the index.
- This is only present in a renamed/copied entry, and
- tells where the renamed/copied contents came from.
- --------------------------------------------------------
+....
+Field Meaning
+--------------------------------------------------------
+<XY> A 2 character field containing the staged and
+ unstaged XY values described in the short format,
+ with unchanged indicated by a "." rather than
+ a space.
+<sub> A 4 character field describing the submodule state.
+ "N..." when the entry is not a submodule.
+ "S<c><m><u>" when the entry is a submodule.
+ <c> is "C" if the commit changed; otherwise ".".
+ <m> is "M" if it has tracked changes; otherwise ".".
+ <u> is "U" if there are untracked changes; otherwise ".".
+<mH> The octal file mode in HEAD.
+<mI> The octal file mode in the index.
+<mW> The octal file mode in the worktree.
+<hH> The object name in HEAD.
+<hI> The object name in the index.
+<X><score> The rename or copy score (denoting the percentage
+ of similarity between the source and target of the
+ move or copy). For example "R100" or "C75".
+<path> The pathname. In a renamed/copied entry, this
+ is the target path.
+<sep> When the `-z` option is used, the 2 pathnames are separated
+ with a NUL (ASCII 0x00) byte; otherwise, a tab (ASCII 0x09)
+ byte separates them.
+<origPath> The pathname in the commit at HEAD or in the index.
+ This is only present in a renamed/copied entry, and
+ tells where the renamed/copied contents came from.
+--------------------------------------------------------
+....
Unmerged entries have the following format; the first character is
a "u" to distinguish from ordinary changed entries.
u <xy> <sub> <m1> <m2> <m3> <mW> <h1> <h2> <h3> <path>
- Field Meaning
- --------------------------------------------------------
- <XY> A 2 character field describing the conflict type
- as described in the short format.
- <sub> A 4 character field describing the submodule state
- as described above.
- <m1> The octal file mode in stage 1.
- <m2> The octal file mode in stage 2.
- <m3> The octal file mode in stage 3.
- <mW> The octal file mode in the worktree.
- <h1> The object name in stage 1.
- <h2> The object name in stage 2.
- <h3> The object name in stage 3.
- <path> The pathname.
- --------------------------------------------------------
+....
+Field Meaning
+--------------------------------------------------------
+<XY> A 2 character field describing the conflict type
+ as described in the short format.
+<sub> A 4 character field describing the submodule state
+ as described above.
+<m1> The octal file mode in stage 1.
+<m2> The octal file mode in stage 2.
+<m3> The octal file mode in stage 3.
+<mW> The octal file mode in the worktree.
+<h1> The object name in stage 1.
+<h2> The object name in stage 2.
+<h3> The object name in stage 3.
+<path> The pathname.
+--------------------------------------------------------
+....
### Other Items
--
2.20.1
^ permalink raw reply related
* [PATCH v2 2/3] Documentation: do not nest open blocks
From: Martin Ågren @ 2018-12-16 14:28 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <cover.1544969984.git.martin.agren@gmail.com>
It appears we try to nest open blocks, but that does not work well with
Asciidoctor, which fails to indent the inner blocks. As a result, they
do not visually seem to relate (as much) to the preceding paragraph as
they should. Drop the outer blocks to fix the rendering of the inner
ones. Asciidoc renders identically before and after this patch, both
man-pages and html.
This also makes Asciidoctor stop rendering a literal '+' before "Under
--pretty=oneline ..." in the manuals for git-log and git-rev-list.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
Documentation/git-init.txt | 4 ----
Documentation/rev-list-options.txt | 4 ----
2 files changed, 8 deletions(-)
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 3c5a67fb96..057076ca38 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -38,8 +38,6 @@ the repository to another place if --separate-git-dir is given).
OPTIONS
-------
---
-
-q::
--quiet::
@@ -111,8 +109,6 @@ into it.
If you provide a 'directory', the command is run inside it. If this directory
does not exist, it will be created.
---
-
TEMPLATE DIRECTORY
------------------
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index bab5f50b17..98b538bc77 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -13,8 +13,6 @@ has a line that matches `<pattern>`), unless otherwise noted.
Note that these are applied before commit
ordering and formatting options, such as `--reverse`.
---
-
-<number>::
-n <number>::
--max-count=<number>::
@@ -308,8 +306,6 @@ ifdef::git-rev-list[]
`<header>` text will be printed with each progress update.
endif::git-rev-list[]
---
-
History Simplification
~~~~~~~~~~~~~~~~~~~~~~
--
2.20.1
^ permalink raw reply related
* [PATCH v2 1/3] git-column.txt: fix section header
From: Martin Ågren @ 2018-12-16 14:28 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <cover.1544969984.git.martin.agren@gmail.com>
We have too few dashes under "Examples", which causes Asciidoctor to not
pick it up as a section header. Instead, it thinks we are starting a
code listing block, which ends up containing the remainder of the
document. The result is quite ugly.
Make sure we have as many dashes as we have characters in "Examples".
Asciidoc renders identically before and after this patch, both man-page
and html.
Signed-off-by: Martin Ågren <martin.agren@gmail.com>
---
Documentation/git-column.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-column.txt b/Documentation/git-column.txt
index 763afabb6d..f58e9c43e6 100644
--- a/Documentation/git-column.txt
+++ b/Documentation/git-column.txt
@@ -47,7 +47,7 @@ OPTIONS
The number of spaces between columns. One space by default.
EXAMPLES
-------
+--------
Format data by columns:
------------
--
2.20.1
^ permalink raw reply related
* [PATCH v2 0/3] A few Asciidoctor-fixes
From: Martin Ågren @ 2018-12-16 14:28 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <20181216105944.GG13704@sigill.intra.peff.net>
This series addresses a few instances where our documentation renders
badly in Asciidoctor, compared to Asciidoc. The changes made are exactly
the same as in v1 [1], but the first commit message is corrected, and
the two patches 2/4 and 3/4 are now just a single patch 2/3.
Thanks Peff for your comments on v1.
[1] https://public-inbox.org/git/20181215112742.1475882-1-martin.agren@gmail.com/
Martin Ågren (3):
git-column.txt: fix section header
Documentation: do not nest open blocks
git-status.txt: render tables correctly under Asciidoctor
Documentation/git-column.txt | 2 +-
Documentation/git-init.txt | 4 -
Documentation/git-status.txt | 162 +++++++++++++++--------------
Documentation/rev-list-options.txt | 4 -
4 files changed, 86 insertions(+), 86 deletions(-)
--
2.20.1
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox