Re: [RFC] Proposed questions for "Git User's Survey 2016"

[Andrew Ardill]

On 21 August 2016 at 04:56, Jakub Narębski  wrote:
> 25. What [channel(s)] do you use to request/get help about Git [(if any)]

It may also be useful to ask how people hear news about git, such as
when a new release comes out. Not sure if worth a separate question,
as there is a lot of crossover in the resources available for this and
for requesting help, but knowing this information would help us
understand what kinds of users are responding and which communication
channels are effective for git news.

Related, it might be worth asking how often people upgrade their git
clients and servers, particularly in corporate/managed environments.
This question would ask two things, how long after a new release comes
out do you install it, and do you install every update that comes out
or do you skip versions. I suspect many would just use whatever is
released in their distro and update at the same time as they update
other packages, but it would be interesting to know if people, for
example, only upgrade their managed environments every year/6 months
or something to avoid introducing changes to their users.

Regards,

Andrew Ardill
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Editing a typo in the message given to "git commit"

[Eric Wong]

Pranit Bauva  wrote:
> On Sun, Aug 21, 2016 at 8:49 PM,   wrote:
> > I am learning how to use git. I would like to know:
> >
> > How can I correct a typo in the message I gave to an old "git commit"? I see
> > that the typo occurs in exactly two files in .git:
> >
> > .git/logs/refs/heads/master
> > .git/logs/HEAD
> >
> > /usr/bin/file says that they are both ASCII English text. So I could just
> > hand edit them. But that seems somehow sacrilegious and might break git.
> 
> Messages to commits aren't just stored in these two files.
> Hand editing them will definitely break git and its highly advisable
> not to do that. In fact, for beginners its highly recommended to never
> visit the ".git" folder. What you need in this case is `git-rebase
> -i`. Using that you can go to the commit where you want to edit the
> message and mark it as "reword". Also if you want to make some
> modifications in the code, then you can mark it as "edit". Try `man
> git-rebase` for more info on the command.

Agreed.  I use "git commit --amend" if it's the latest commit;
saves typing.  Definitely don't edit anything in .git/logs/ by
hand.

> Also on a side note: This is a developer's mailing list. Please try to
> use the user's mailing list[1] for doubts. But if you have a doubt as
> to why this commands functions in a particular way (in which you think
> it should not) or you find a possible bug then feel free to discuss it
> on this mailing list. Also to save other people's time, first search
> for the doubt in the archives or google about it.

I disagree with this being a developer's-only list and pointing
users to a separate list.  Every git user is a potential
developer (especially for a tool aimed for managing source).
Often user questions turn into bug reports aimed at
developers.

Nothing in our manpages even mentions this git-users list.

> [1]: https://groups.google.com/forum/#!forum/git-users


Keep in mind I have a strong anti-centralization bias and
Google is a big basket, here.  I'll let their history of
discontinuing services like Google Reader, Google Code,
etc. speak for itself :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

hello git

[bbenta]

good morning git

http://s-catalog.online/everywhere.php?bear=1pms6hakx989f





bbenta
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Minor bug: git config ignores empty sections

[Jakub Narębski]

W dniu 16.08.2016 o 14:36, Jeff King pisze:

> What I think would be much more sane in general is to parse the whole
> thing into a tree (or even a flat list of events),

List of events is cheaper on memory (though I don't think there is
an issue with size of config file), and can be turned into tree
and DOM easily.

>marking each
> syntactically as a section header, a key, a comment, a run of
> whitespace, and so on. And then do manipulations on that tree (e.g.,
> walk down to the section of interest, add a new key at the end), and
> then reformat the tree back into a stream of bytes. That lets you
> separate the policy logic from the parsing, and do high-level operations
> that might involve multiple passes or backtracking in the tree (e.g.,
> walk to the section, walk past any existing keys, walk past any comments
> but _not_ past any blank lines, then add the new key).
> 
> There are other other upsides, too. For example, the current code cannot
> write multiple unrelated keys in a single pass.
> 
> The downsides is that it's a complete rewrite of the code. So it's a
> _lot_ more work, and it carries more risk of regression. So please don't
> take this as "no, your solution isn't OK; you have to do the rewrite".
> We've been living with band-aids on the config code for a decade, so I
> am OK with one more.

So how 'git config --show-origin --list' works?  

Ah, I guess it prints as it goes, instead of parsing config file(s)
into stream of events, and printing from those.

-- 
Jakub Narębski

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [L10N] Kickoff of translation for Git 2.10.0 round 1

[Jiang Xin]

2016-08-21 2:38 GMT+08:00 Jean-Noël AVILA :
> On samedi 20 août 2016 11:03:00 CEST Junio C Hamano wrote:
>> Jean-Noël AVILA  writes:
>> > 1.  In config.c, the changes to the function die_bad_number tried to
>> > flatten the translated strings (no message building logic). I think it
>> > went too far, and the reason of the failure can be factorized so that we
>> > don't have to retranslate each time. I might be wrong on this one, but I
>> > have no example of language where we would need differentiated error
>> > reasons.
>>
>> I do not have a strong opinion on this one.  I think it is an
>> attempt to avoid language-lego.
>
> No problem with the changes for blob, files, command line. It's just about
> dividing by two the number of strings to translate by factorizing "out of
> range" and "invalid unit", which are invariable anyway.

I agree with you.  It maybe not a good solution to expanded string "reason"
in commit 1b8132d:

-   const char *reason = errno == ERANGE ?
-"out of range" :
-"invalid unit";


>> > 3. git-rebase--interactive, in this_nth_commit_message and
>> > skip_nth_commit_message are not localizable,
>>
>> As the "TRANSLATORS" comment alludes to, "This is the Nth thing" can
>> be rephrased to "This is the thing N" or "This is the thing #N"
>> easily, and if that form without ordinal is acceptable for many
>> languages, we should say that it is also OK in C-locale without
>> translation.  So I agree that the recent change was pointless (even
>> though the result may be localizable).
>>
>> In an ideal world, I would imagine that this would be done by using
>> Q_("This is the first thing", "This is the thing #%d", nth) aka
>> ngettext, but
>>
>> (1) I haven't seen ngettext used from shell scripts; and
>>
> There's a use_ngettext macro
>
>> (2) I do not think po files are set up to express "for this
>> message, this language has 4 variants and here are the local
>> rules to decide which one to use depending on the number,
>> but the rules apply only to this message".  The Plural-Forms
>> rule [*1*] seems to be global to a .po file, unfortunately.
>>
>
>
>> so I do not think we cannot do it with ngettext().
>>
>
> Let's cut it like this : first ten are literally translated, the following 
> ones
> fall back to a general rule. All languages are treated equally. With more than
> 10 squashed commit, you no longer really care if the numbering is pedantically
> correct.


It's boring to translate all these 30 messages, I prefer #N like:

gettext "The commit message #\${n} will be skipped:"
gettext "This is the commit message #\${n}:"


-- 
Jiang Xin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Editing a typo in the message given to "git commit"

[Pranit Bauva]

Hey Norman,

On Sun, Aug 21, 2016 at 8:49 PM,   wrote:
> I am learning how to use git. I would like to know:
>
> How can I correct a typo in the message I gave to an old "git commit"? I see
> that the typo occurs in exactly two files in .git:
>
> .git/logs/refs/heads/master
> .git/logs/HEAD
>
> /usr/bin/file says that they are both ASCII English text. So I could just
> hand edit them. But that seems somehow sacrilegious and might break git.

Messages to commits aren't just stored in these two files.
Hand editing them will definitely break git and its highly advisable
not to do that. In fact, for beginners its highly recommended to never
visit the ".git" folder. What you need in this case is `git-rebase
-i`. Using that you can go to the commit where you want to edit the
message and mark it as "reword". Also if you want to make some
modifications in the code, then you can mark it as "edit". Try `man
git-rebase` for more info on the command.

Also on a side note: This is a developer's mailing list. Please try to
use the user's mailing list[1] for doubts. But if you have a doubt as
to why this commands functions in a particular way (in which you think
it should not) or you find a possible bug then feel free to discuss it
on this mailing list. Also to save other people's time, first search
for the doubt in the archives or google about it.

[1]: https://groups.google.com/forum/#!forum/git-users

Regards,
Pranit Bauva
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Editing a typo in the message given to "git commit"

[norm]

I am learning how to use git. I would like to know:

How can I correct a typo in the message I gave to an old "git commit"? I see
that the typo occurs in exactly two files in .git:

.git/logs/refs/heads/master
.git/logs/HEAD

/usr/bin/file says that they are both ASCII English text. So I could just
hand edit them. But that seems somehow sacrilegious and might break git.

Norman Shapiro
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/3] i18n: fix typos for translation

[Jean-Noel Avila]

Signed-off-by: Jean-Noel Avila 
---
 bisect.c| 10 +-
 sequencer.c |  2 +-
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/bisect.c b/bisect.c
index 6f512c2..b9a0701 100644
--- a/bisect.c
+++ b/bisect.c
@@ -760,7 +760,7 @@ static void handle_skipped_merge_base(const unsigned char 
*mb)
char *bad_hex = oid_to_hex(current_bad_oid);
char *good_hex = join_sha1_array_hex(_revs, ' ');
 
-   warning(_("the merge base between %s and [%s] "
+   warning(_("The merge base between %s and [%s] "
"must be skipped.\n"
"So we cannot be sure the first %s commit is "
"between %s and %s.\n"
@@ -846,7 +846,7 @@ static void check_good_are_ancestors_of_bad(const char 
*prefix, int no_checkout)
int fd;
 
if (!current_bad_oid)
-   die(_("a %s revision is needed"), term_bad);
+   die(_("A %s revision is needed"), term_bad);
 
/* Check if file BISECT_ANCESTORS_OK exists. */
if (!stat(filename, ) && S_ISREG(st.st_mode))
@@ -863,7 +863,7 @@ static void check_good_are_ancestors_of_bad(const char 
*prefix, int no_checkout)
/* Create file BISECT_ANCESTORS_OK. */
fd = open(filename, O_CREAT | O_TRUNC | O_WRONLY, 0600);
if (fd < 0)
-   warning_errno(_("could not create file '%s'"),
+   warning_errno(_("Could not create file '%s'"),
  filename);
else
close(fd);
@@ -914,7 +914,7 @@ void read_bisect_terms(const char **read_bad, const char 
**read_good)
*read_good = "good";
return;
} else {
-   die_errno(_("could not read file '%s'"), filename);
+   die_errno(_("Could not read file '%s'"), filename);
}
} else {
strbuf_getline_lf(, fp);
@@ -944,7 +944,7 @@ int bisect_next_all(const char *prefix, int no_checkout)
 
read_bisect_terms(_bad, _good);
if (read_bisect_refs())
-   die(_("reading bisect refs failed"));
+   die(_("Reading bisect refs failed"));
 
check_good_are_ancestors_of_bad(prefix, no_checkout);
 
diff --git a/sequencer.c b/sequencer.c
index 2e9c7d0..3804fa9 100644
--- a/sequencer.c
+++ b/sequencer.c
@@ -702,7 +702,7 @@ static struct commit *parse_insn_line(char *bol, char *eol, 
struct replay_opts *
if (action != opts->action) {
if (action == REPLAY_REVERT)
  error((opts->action == REPLAY_REVERT)
-   ? _("Cannot revert during a another revert.")
+   ? _("Cannot revert during another revert.")
: _("Cannot revert during a cherry-pick."));
else
  error((opts->action == REPLAY_REVERT)
-- 
2.10.0.rc0.37.gd7d1c14.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/3] i18n: fix git rebase interactive commit messages

[Jean-Noel Avila]

For proper i18n, the logic cannot embed english specific processing.

Signed-off-by: Jean-Noel Avila 
---
 git-rebase--interactive.sh | 16 
 1 file changed, 16 deletions(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index e2da524..7baf5f4 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -415,14 +415,6 @@ this_nth_commit_message () {
8) gettext "This is the 8th commit message:";;
9) gettext "This is the 9th commit message:";;
10) gettext "This is the 10th commit message:";;
-   # TRANSLATORS: if the language you are translating into
-   # doesn't allow you to compose a sentence in this fashion,
-   # consider translating as if this and the following few strings
-   # were "This is the commit message ${n}:"
-   *1[0-9]|*[04-9]) eval_gettext "This is the \${n}th commit message:";;
-   *1) eval_gettext "This is the \${n}st commit message:";;
-   *2) eval_gettext "This is the \${n}nd commit message:";;
-   *3) eval_gettext "This is the \${n}rd commit message:";;
*) eval_gettext "This is the commit message \${n}:";;
esac
 }
@@ -439,14 +431,6 @@ skip_nth_commit_message () {
8) gettext "The 8th commit message will be skipped:";;
9) gettext "The 9th commit message will be skipped:";;
10) gettext "The 10th commit message will be skipped:";;
-   # TRANSLATORS: if the language you are translating into
-   # doesn't allow you to compose a sentence in this fashion,
-   # consider translating as if this and the following few strings
-   # were "The commit message ${n} will be skipped:"
-   *1[0-9]|*[04-9]) eval_gettext "The \${n}th commit message will be 
skipped:";;
-   *1) eval_gettext "The \${n}st commit message will be skipped:";;
-   *2) eval_gettext "The \${n}nd commit message will be skipped:";;
-   *3) eval_gettext "The \${n}rd commit message will be skipped:";;
*) eval_gettext "The commit message \${n} will be skipped:";;
esac
 }
-- 
2.10.0.rc0.37.gd7d1c14.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 3/3] i18n: simplify numeric error reporting

[Jean-Noel Avila]

Signed-off-by: Jean-Noel Avila 
---
 config.c | 43 +++
 1 file changed, 15 insertions(+), 28 deletions(-)

diff --git a/config.c b/config.c
index 584cacf..e33c703 100644
--- a/config.c
+++ b/config.c
@@ -655,43 +655,30 @@ static void die_bad_number(const char *name, const char 
*value)
if (!value)
value = "";
 
+   const char * error_type = (errno == ERANGE)? _("out of 
range"):_("invalid unit");
if (!(cf && cf->name))
-   die(errno == ERANGE
-   ? _("bad numeric config value '%s' for '%s': out of range")
-   : _("bad numeric config value '%s' for '%s': invalid unit"),
-   value, name);
+   die(_("bad numeric config value '%s' for '%s': %s"),
+   value, name, error_type);
 
switch (cf->origin_type) {
case CONFIG_ORIGIN_BLOB:
-   die(errno == ERANGE
-   ? _("bad numeric config value '%s' for '%s' in blob %s: out 
of range")
-   : _("bad numeric config value '%s' for '%s' in blob %s: 
invalid unit"),
-   value, name, cf->name);
+   die(_("bad numeric config value '%s' for '%s' in blob %s: %s"),
+   value, name, cf->name, error_type);
case CONFIG_ORIGIN_FILE:
-   die(errno == ERANGE
-   ? _("bad numeric config value '%s' for '%s' in file %s: out 
of range")
-   : _("bad numeric config value '%s' for '%s' in file %s: 
invalid unit"),
-   value, name, cf->name);
+   die(_("bad numeric config value '%s' for '%s' in file %s: %s"),
+   value, name, cf->name, error_type);
case CONFIG_ORIGIN_STDIN:
-   die(errno == ERANGE
-   ? _("bad numeric config value '%s' for '%s' in standard 
input: out of range")
-   : _("bad numeric config value '%s' for '%s' in standard 
input: invalid unit"),
-   value, name);
+   die(_("bad numeric config value '%s' for '%s' in standard 
input: %s"),
+   value, name, error_type);
case CONFIG_ORIGIN_SUBMODULE_BLOB:
-   die(errno == ERANGE
-   ? _("bad numeric config value '%s' for '%s' in 
submodule-blob %s: out of range")
-   : _("bad numeric config value '%s' for '%s' in 
submodule-blob %s: invalid unit"),
-   value, name, cf->name);
+   die(_("bad numeric config value '%s' for '%s' in submodule-blob 
%s: %s"),
+   value, name, cf->name, error_type);
case CONFIG_ORIGIN_CMDLINE:
-   die(errno == ERANGE
-   ? _("bad numeric config value '%s' for '%s' in command line 
%s: out of range")
-   : _("bad numeric config value '%s' for '%s' in command line 
%s: invalid unit"),
-   value, name, cf->name);
+   die(_("bad numeric config value '%s' for '%s' in command line 
%s: %s"),
+   value, name, cf->name, error_type);
default:
-   die(errno == ERANGE
-   ? _("bad numeric config value '%s' for '%s' in %s: out of 
range")
-   : _("bad numeric config value '%s' for '%s' in %s: invalid 
unit"),
-   value, name, cf->name);
+   die(_("bad numeric config value '%s' for '%s' in %s: %s"),
+   value, name, cf->name, error_type);
}
 }
 
-- 
2.10.0.rc0.37.gd7d1c14.dirty

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Extending "extended SHA1" syntax to traverse through gitlinks?

[Josh Triplett]

On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote:
> W dniu 21.08.2016 o 00:50, Josh Triplett pisze:
> > Currently, if you have a branch "somebranch" that contains a gitlink
> > "somecommit", you can write "somebranch:somecommit" to refer to the
> > commit, just like a tree or blob.  ("man git-rev-parse" defines this
> > syntax in the "SPECIFYING REVISIONS" section.)  You can use this
> > anywhere you can use a committish, including "git show
> > somebranch:somecommit", "git log somebranch:somecommit..anotherbranch",
> > or even "git format-patch -1 somebranch:somecommit".
> > 
> > However, you cannot traverse *through* the gitlink to look at files
> > inside its own tree, or to look at other commits relative to that
> > commit.  For instance, "somebranch:somecommit:somefile" and
> > "somebranch:somecommit~3" do not work.
> 
> Note that there is the same problem traversing through trees:
> while 'git cat-file -p HEAD:subdir/file' works, the 'HEAD:subdir:file'
> doesn't:
> 
>   $ git cat-file -p HEAD:subdir:file
>   fatal: Not a valid object name HEAD:subdir:file

Interesting point; if extending this syntax anyway, any treeish ought to
work, not just a committish.

> Though you can do resolve step manually
> 
>   $ git cat-file -p $(git rev-parse HEAD:subdir):file
> 
> This works.

True, but that seems quite inconvenient.

> > I'd love to have a syntax that allows traversing through the gitlink to
> > other files or commits.  Ideally, I'd suggest the syntax above, as a
> > natural extension of the existing extended syntax.
> 
> And with the above manual resolving, you can see the problem with
> implementing it: the git-cat-file (in submodule) and git-rev-parse
> (in supermodule) are across repository boundary.

Only if the gitlink points to a commit that doesn't exist in the same
repository.  A gitlink can point to a commit you already have.

> Also the problem with proposed syntax is that is not very visible.
> But perhaps it is all right.  Maybe :/ as separator would be better,
> or using parentheses or braces?

It seems as visible as the standard commit:path syntax; the second colon
seems just as visible as the first.  :/ already has a different meaning
(text search), so that would introduce inconsistency.

> > (That syntax would potentially introduce ambiguity if you had a file
> > named "somecommit:somefile" or "somecommit~3".  That doesn't seem like a
> > problem, though; the existing syntax already doesn't support accessing a
> > file named "x..y" or "x...y", so scripts already can't expect to access
> > arbitrary filenames with that syntax without some kind of quoting, which
> > we also don't have.)
> 
> Errr... what?
> 
>   $ echo A..B >A..B
>   $ git add A..B
>   $ git commit -m 'A..B added'
>   [master 2d69af9] A..B added
>1 file changed, 1 insertion(+), 1 deletion(-)
>create mode 100644 A..B
>   $ git show HEAD:A..B
>   A..B

I stand corrected; I didn't find that.  I thought rev parsing worked
independently from the repository, and didn't have any automagic
detection based on the contents of the repository?

This seems ambiguous, and (AFAICT) not documented.  If HEAD:A and B both
refer to a commit, in addition to the blob A..B, which will HEAD:A..B
refer to?  I did test the HEAD:gitlink..anotherbranch case, and it does
parse as a range.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding more namespace support to git

[Josh Triplett]

On Sun, Aug 21, 2016 at 12:30:16PM +0100, Richard wrote:
> On 21 August 2016 at 03:05, Josh Triplett  wrote:
> > Unfortunately, I think at this point, GIT_NAMESPACE has to exclusively
> > refer to the namespace for the remote end, to avoid breakage.  Which
> > means any automatic pervasive support for namespaces on the local side
> > would need to use a different mechanism.  (In addition to applying to
> > ref enumeration, this would also need to apply to the local end of
> > refspecs.)  And this new mechanism would need to not affect the remote
> > end, to allow remapping the local end while accessing an un-namespaced
> > (or differently namespaced) remote.
> 
> The problem for hooks is that it is implicitly inherited,
> so it could work if upload-pack receive-pack and http-backend work
> with GIT_NAMESPACE set,
> but everything else that wants to use a namespace has to set
> --namespace on the command-line.

I'd like to see it work more automatically than that.  Perhaps a
separate environment variable to set the client-side namespace?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Extending "extended SHA1" syntax to traverse through gitlinks?

[Jakub Narębski]

W dniu 21.08.2016 o 00:50, Josh Triplett pisze:

> Currently, if you have a branch "somebranch" that contains a gitlink
> "somecommit", you can write "somebranch:somecommit" to refer to the
> commit, just like a tree or blob.  ("man git-rev-parse" defines this
> syntax in the "SPECIFYING REVISIONS" section.)  You can use this
> anywhere you can use a committish, including "git show
> somebranch:somecommit", "git log somebranch:somecommit..anotherbranch",
> or even "git format-patch -1 somebranch:somecommit".
> 
> However, you cannot traverse *through* the gitlink to look at files
> inside its own tree, or to look at other commits relative to that
> commit.  For instance, "somebranch:somecommit:somefile" and
> "somebranch:somecommit~3" do not work.

Note that there is the same problem traversing through trees:
while 'git cat-file -p HEAD:subdir/file' works, the 'HEAD:subdir:file'
doesn't:

  $ git cat-file -p HEAD:subdir:file
  fatal: Not a valid object name HEAD:subdir:file

Though you can do resolve step manually

  $ git cat-file -p $(git rev-parse HEAD:subdir):file

This works.

> 
> I'd love to have a syntax that allows traversing through the gitlink to
> other files or commits.  Ideally, I'd suggest the syntax above, as a
> natural extension of the existing extended syntax.

And with the above manual resolving, you can see the problem with
implementing it: the git-cat-file (in submodule) and git-rev-parse
(in supermodule) are across repository boundary.

Also the problem with proposed syntax is that is not very visible.
But perhaps it is all right.  Maybe :/ as separator would be better,
or using parentheses or braces?

> (That syntax would potentially introduce ambiguity if you had a file
> named "somecommit:somefile" or "somecommit~3".  That doesn't seem like a
> problem, though; the existing syntax already doesn't support accessing a
> file named "x..y" or "x...y", so scripts already can't expect to access
> arbitrary filenames with that syntax without some kind of quoting, which
> we also don't have.)

Errr... what?

  $ echo A..B >A..B
  $ git add A..B
  $ git commit -m 'A..B added'
  [master 2d69af9] A..B added
   1 file changed, 1 insertion(+), 1 deletion(-)
   create mode 100644 A..B
  $ git show HEAD:A..B
  A..B

> 
> Does this seem reasonable?  Would a patch introducing such syntax
> (including documentation and tests) be acceptable?

-- 
Jakub Narębski

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Adding more namespace support to git

[Richard]

On 21 August 2016 at 03:05, Josh Triplett  wrote:
> On Sat, Aug 20, 2016 at 08:07:00PM +0100, Richard wrote:
>> Since when upload-pack and receive-pack run hooks they leave GIT_NAMESPACE 
>> set
>> there are hook scripts that expect that the current namespace is ignored,
>> so commands that now want to be namespace aware would have to opt-in.
>
> That seems really unfortunate.  While at the time we wanted to start
> with namespace support in upload-pack and receive-pack (and
> http-backend) because those would allow using it as a server-side
> storage format, I don't think we realized that leaving GIT_NAMESPACE in
> the hook environment would completely prevent other git commands from
> automatically handling namespaces.
>
> And conversely, we can't just have upload-pack and receive-pack start
> removing it from the hook environment, because a hook might expect to
> read the current namespace from it (and then run git commands that the
> hook expects will ignore it).

This is exactly what I've had to do for my proof of concept
https://git.gitano.org.uk/cgit.git/commit/?h=richardmaw/namespaces=379124469a8a13208f976eb816375b00901ae77f

> For that matter, someone could run "GIT_NAMESPACE=foo git push
> remotename branchname" or
> "GIT_NAMESPACE=foo git clone remotename", and based on the current
> behavior, they'd expect to have the namespace apply to the remote end,
> but not the local end.

I'm fairly sure this isn't the case, at least from what I've tried.
At one point it appeared to be working,
but that was just because it started the upload-pack as a subprocess,
which inherited the GIT_NAMESPACE environment variable rather than
being passed it.
I think this is why the test suite always sets up a remote with the ext:: helper
so it can set --namespace=foo in the command.

This is one of the reasons why I have been working on namespace
support in the git server,
you have to encode the namespace in the url somehow
since it isn't passed through the git protocol.

We were thinking of adding ssh://git@server/~username/repo/path.git syntax
for letting users have their own private namespace in a repository,
and later extending the backend of the git server's repository storage
so that other repositories could just be namespaces of a different repository
so we could do something like repository forks
provided the repositories have the same availability.

> Unfortunately, I think at this point, GIT_NAMESPACE has to exclusively
> refer to the namespace for the remote end, to avoid breakage.  Which
> means any automatic pervasive support for namespaces on the local side
> would need to use a different mechanism.  (In addition to applying to
> ref enumeration, this would also need to apply to the local end of
> refspecs.)  And this new mechanism would need to not affect the remote
> end, to allow remapping the local end while accessing an un-namespaced
> (or differently namespaced) remote.

The problem for hooks is that it is implicitly inherited,
so it could work if upload-pack receive-pack and http-backend work
with GIT_NAMESPACE set,
but everything else that wants to use a namespace has to set
--namespace on the command-line.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v13 04/13] bisect--helper: `bisect_clean_state` shell function in C

[Pranit Bauva]

Hey,

On Sat, Aug 20, 2016 at 2:02 AM, Pranit Bauva  wrote:
> Reimplement `bisect_clean_state` shell function in C and add a
> `bisect-clean-state` subcommand to `git bisect--helper` to call it from
> git-bisect.sh .
>
> Using `--bisect-clean-state` subcommand is a measure to port shell
> function to C so as to use the existing test suite. As more functions
> are ported, this subcommand will be retired but its implementation  will
> be called by bisect_reset() and bisect_start().
>
> Mentored-by: Lars Schneider 
> Mentored-by: Christian Couder 
> Signed-off-by: Pranit Bauva 
> ---
>  bisect.c | 43 +++
>  bisect.h |  2 ++
>  builtin/bisect--helper.c | 14 +-
>  git-bisect.sh| 26 +++---
>  4 files changed, 61 insertions(+), 24 deletions(-)
>
> diff --git a/bisect.c b/bisect.c
> index 6f512c2..45d598d 100644
> --- a/bisect.c
> +++ b/bisect.c
> @@ -430,6 +430,12 @@ static int read_bisect_refs(void)
>
>  static GIT_PATH_FUNC(git_path_bisect_names, "BISECT_NAMES")
>  static GIT_PATH_FUNC(git_path_bisect_expected_rev, "BISECT_EXPECTED_REV")
> +static GIT_PATH_FUNC(git_path_bisect_ancestors_ok, "BISECT_ANCESTORS_OK")
> +static GIT_PATH_FUNC(git_path_bisect_run, "BISECT_RUN")
> +static GIT_PATH_FUNC(git_path_bisect_start, "BISECT_START")
> +static GIT_PATH_FUNC(git_path_bisect_log, "BISECT_LOG")
> +static GIT_PATH_FUNC(git_path_bisect_terms, "BISECT_TERMS")
> +static GIT_PATH_FUNC(git_path_head_name, "head-name")
>
>  static void read_bisect_paths(struct argv_array *array)
>  {
> @@ -1040,3 +1046,40 @@ int estimate_bisect_steps(int all)
>
> return (e < 3 * x) ? n : n - 1;
>  }
> +
> +static int mark_for_removal(const char *refname, const struct object_id *oid,
> +   int flag, void *cb_data)
> +{
> +   struct string_list *refs = cb_data;
> +   char *ref = xstrfmt("refs/bisect%s", refname);
> +   string_list_append(refs, ref);
> +   return 0;
> +}
> +
> +int bisect_clean_state(void)
> +{
> +   int result = 0;
> +
> +   /* There may be some refs packed during bisection */
> +   struct string_list refs_for_removal = STRING_LIST_INIT_NODUP;
> +   for_each_ref_in("refs/bisect", mark_for_removal, (void *) 
> _for_removal);
> +   string_list_append(_for_removal, xstrdup("BISECT_HEAD"));
> +   result = delete_refs(_for_removal, REF_NODEREF);
> +   refs_for_removal.strdup_strings = 1;
> +   string_list_clear(_for_removal, 0);
> +   unlink_or_warn(git_path_bisect_expected_rev());
> +   unlink_or_warn(git_path_bisect_ancestors_ok());
> +   unlink_or_warn(git_path_bisect_log());
> +   unlink_or_warn(git_path_bisect_names());
> +   unlink_or_warn(git_path_bisect_run());
> +   unlink_or_warn(git_path_bisect_terms());
> +   /* Cleanup head-name if it got left by an old version of git-bisect */
> +   unlink_or_warn(git_path_head_name());
> +   /*
> +* Cleanup BISECT_START last to support the --no-checkout option
> +* introduced in the commit 4796e823a.
> +*/
> +   unlink_or_warn(git_path_bisect_start());
> +
> +   return result;
> +}
> diff --git a/bisect.h b/bisect.h
> index acd12ef..0ae63d4 100644
> --- a/bisect.h
> +++ b/bisect.h
> @@ -28,4 +28,6 @@ extern int estimate_bisect_steps(int all);
>
>  extern void read_bisect_terms(const char **bad, const char **good);
>
> +extern int bisect_clean_state(void);
> +
>  #endif
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 30e1031..e50934c 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -5,10 +5,15 @@
>  #include "refs.h"
>
>  static GIT_PATH_FUNC(git_path_bisect_terms, "BISECT_TERMS")
> +static GIT_PATH_FUNC(git_path_bisect_expected_rev, "BISECT_EXPECTED_REV")
> +static GIT_PATH_FUNC(git_path_bisect_ancestors_ok, "BISECT_ANCESTORS_OK")
> +static GIT_PATH_FUNC(git_path_bisect_log, "BISECT_LOG")
> +static GIT_PATH_FUNC(git_path_bisect_start, "BISECT_START")
>
>  static const char * const git_bisect_helper_usage[] = {
> N_("git bisect--helper --next-all [--no-checkout]"),
> N_("git bisect--helper --write-terms  "),
> +   N_("git bisect--helper --bisect-clean-state"),
> NULL
>  };
>
> @@ -83,7 +88,8 @@ int cmd_bisect__helper(int argc, const char **argv, const 
> char *prefix)
>  {
> enum {
> NEXT_ALL = 1,
> -   WRITE_TERMS
> +   WRITE_TERMS,
> +   BISECT_CLEAN_STATE
> } cmdmode = 0;
> int no_checkout = 0;
> struct option options[] = {
> @@ -91,6 +97,8 @@ int cmd_bisect__helper(int argc, const char **argv, const 
> char *prefix)
>  N_("perform 'git bisect next'"), NEXT_ALL),
> OPT_CMDMODE(0, "write-terms", ,
> 

Re: [PATCH v13 01/13] bisect--helper: use OPT_CMDMODE instead of OPT_BOOL

[Pranit Bauva]

Hey everyone,

On Sat, Aug 20, 2016 at 2:02 AM, Pranit Bauva  wrote:
> `--next-all` is meant to be used as a subcommand to support multiple
> "operation mode" though the current implementation does not contain any
> other subcommand along side with `--next-all` but further commits will
> include some more subcommands.
>
> Helped-by: Johannes Schindelin 
> Mentored-by: Lars Schneider 
> Mentored-by: Christian Couder 
> Signed-off-by: Pranit Bauva 
> ---
>  builtin/bisect--helper.c | 17 +++--
>  1 file changed, 11 insertions(+), 6 deletions(-)
>
> diff --git a/builtin/bisect--helper.c b/builtin/bisect--helper.c
> index 3324229..8111c91 100644
> --- a/builtin/bisect--helper.c
> +++ b/builtin/bisect--helper.c
> @@ -10,11 +10,11 @@ static const char * const git_bisect_helper_usage[] = {
>
>  int cmd_bisect__helper(int argc, const char **argv, const char *prefix)
>  {
> -   int next_all = 0;
> +   enum { NEXT_ALL = 1 } cmdmode = 0;
> int no_checkout = 0;
> struct option options[] = {
> -   OPT_BOOL(0, "next-all", _all,
> -N_("perform 'git bisect next'")),
> +   OPT_CMDMODE(0, "next-all", ,
> +N_("perform 'git bisect next'"), NEXT_ALL),
> OPT_BOOL(0, "no-checkout", _checkout,
>  N_("update BISECT_HEAD instead of checking out the 
> current commit")),
> OPT_END()
> @@ -23,9 +23,14 @@ int cmd_bisect__helper(int argc, const char **argv, const 
> char *prefix)
> argc = parse_options(argc, argv, prefix, options,
>  git_bisect_helper_usage, 0);
>
> -   if (!next_all)
> +   if (!cmdmode)
> usage_with_options(git_bisect_helper_usage, options);
>
> -   /* next-all */
> -   return bisect_next_all(prefix, no_checkout);
> +   switch (cmdmode) {
> +   case NEXT_ALL:
> +   return bisect_next_all(prefix, no_checkout);
> +   default:
> +   die("BUG: unknown subcommand '%d'", cmdmode);
> +   }
> +   return 0;
>  }


This is the same series (except for patch 04/13) and rebased on v2.10-rc0.

Regards,
Pranit Bauva
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Most recent revision that contains a string

[Josh Triplett]

On Sun, Aug 21, 2016 at 10:13:33AM +0200, Andreas Schwab wrote:
> On Aug 20 2016, Josh Triplett  wrote:
> > If you want to find a change that introduces or removes a particular
> > string, you could use "git log -S".  That doesn't allow regexes,
> 
> It does, actually, see --pickaxe-regex.

Thanks; I found that after looking up "git log -G", which Eric Wong
mentioned in another reply.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Most recent revision that contains a string

[Andreas Schwab]

On Aug 20 2016, Josh Triplett  wrote:

> If you want to find a change that introduces or removes a particular
> string, you could use "git log -S".  That doesn't allow regexes,

It does, actually, see --pickaxe-regex.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html