* Re: url.<base>.insteadOf vs. submodules
From: Junio C Hamano @ 2017-02-21 23:59 UTC (permalink / raw)
To: Stefan Beller; +Cc: Jeff King, Toolforger, git@vger.kernel.org
In-Reply-To: <xmqqo9xvdsji.fsf@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> So I would think it is entirely reasonable if "git submodule init
> sub" that is run in the superproject to initialize "sub" writes
> something in "sub/.git" to tell that "sub" is used in the context of
> that particular toplevel superproject and customize its behavour
> accordingly. Perhaps it may want to add the url.*.insteadOf that is
> useful for updating the submodule repository when it does "submodule
> init", for example.
Of course, "copying" is usually not very desirable, as it invites
one of the copies to go stale. An actual implementation may just
say "the name of submodule the superproject uses this as is 'foo'".
That way, if such a configuration exists, Git can first do cd-up to
the root of the working tree, go one level up, verify that it is in
a worktree of its superproject, verify that the root of the working
tree it came from was indeed bound to the submodule called 'foo' and
then do the selective/filtered "config-include" Peff outlined. That
would allow superproject to move submodules around (as opposed to
recording "this submodule is used at this/path of the superproject"
or "the superproject of this submodule is at ../../that/path"), and
does not penalize repositories that are not used as submodules of
any superproject (because the "cd-up, up, verify and include" won't
be done for them). As opposed to "I am used as a submodule" bit,
recording the name the superproject uses to call the submodule would
also serve as a sanity check measure.
^ permalink raw reply
* Re: url.<base>.insteadOf vs. submodules
From: Stefan Beller @ 2017-02-22 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Toolforger, git@vger.kernel.org
In-Reply-To: <xmqqo9xvdsji.fsf@gitster.mtv.corp.google.com>
On Tue, Feb 21, 2017 at 3:37 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Stefan Beller <sbeller@google.com> writes:
>
>> On Tue, Feb 21, 2017 at 3:00 PM, Jeff King <peff@peff.net> wrote:
>> ...
>>> I guess one answer is that this is the wrong approach entirely, and the
>>> right one is something like: submodules should understand that they are
>>> part of a superproject, and respect some whitelisted set of config from
>>> the superproject .git/config file.
>>
>> This would break one of the core assumptions that submodules
>> are "independent" repos.
>>
>> The way of action is a one way street:
>> * The superproject is aware of the submodule and when you invoke a
>> command on the superproject, you may mess around with the submodule,
>> e.g. update/remove it; absorb its git directory.
>> * The submodule is "just" a repository with weird .git link file and a
>> respective core.worktree setup. Currently it doesn't know if it is
>> guided by a superproject.
>
> While that is a good discipline to follow, I think you need to
> differenciate the project that is bound as a submodule to a
> superproject, and a specific instance of a submodule repository,
> i.e. a clone of such a project.
>
> It is true that the Linux kernel project should *NEVER* know your
> appliance project only because you happen to use it as a component
> of your appliance that happens to use the kernel as one of its
> submodules. But that does not mean your copy of the kernel that
> sits in your recursive checkout of your appliance project should
> not know anything about your superproject.
Oh, I see. For this use case as well as the prompt indicator that
I mentioned in the previous email, the most basic question is
* Do we have a superproject? [yes/no]
The next level of awareness would be
* Where is the superproject? [ <relative path?>]
These questions may not be interesting for a user (they ought to know
about that appliance;) ), but rather for scripted usage, which I think
hints at the lack of a submodule plumbing command.
Currently we only have git-submodule that is a helper used to somehow
cope with submodules. It is used by humans directly and it is listed
under "Main porcelain commands" in our man page.
Probably we'd also do not want to cram this stuff into the already bloated
rev-parse (that has --show-toplevel, which has nothing to do with
parsing revs, but as Jeff put it it is the kitchen sink of Git).
>
> This is true even without any submodules. The Git project itself
> does not even care you are Stefan, but you still can and do add
> [user] name = "Stefan Beller" to .git/config of your clone of the
> Git project. A clone of the project may want to know more than the
> data project itself keeps track of to describe the context in which
> the particular clone is being used. And .git/config is a good place
> to keep such pieces of information.
This analogy is less clear to me than the kernel& appliance.
When applying it to you (user.name=Junio) that has write powers
over the blessed repository, the project cares a lot about you. ;)
> So I would think it is entirely reasonable if "git submodule init
> sub" that is run in the superproject to initialize "sub" writes
> something in "sub/.git" to tell that "sub" is used in the context of
> that particular toplevel superproject and customize its behavour
> accordingly. Perhaps it may want to add the url.*.insteadOf that is
> useful for updating the submodule repository when it does "submodule
> init", for example.
Do we want to invent a special value for url.*.insteadOf to mean
"look up in superproject, so I don't have to keep
a copy that may get stale" ?
^ permalink raw reply
* Re: url.<base>.insteadOf vs. submodules
From: Stefan Beller @ 2017-02-22 0:10 UTC (permalink / raw)
To: Jeff King; +Cc: Toolforger, git@vger.kernel.org
In-Reply-To: <20170221234037.ga44u3birwd5whab@sigill.intra.peff.net>
On Tue, Feb 21, 2017 at 3:40 PM, Jeff King <peff@peff.net> wrote:
>> > One other caveat: I'm not sure if we do insteadOf recursively, but it
>> > may be surprising to the child "git clone" that we've already applied
>> > the insteadOf rewriting (especially if the rules are coming from
>> > ~/.gitconfig and may be applied twice).
>>
>> When a rule is having effect twice the rule sounds broken. (the outcome
>> ought to be sufficiently different from the original?)
>
> If you have:
>
> url.bar.insteadOf=foo
> url.baz.insteadOf=bar
>
> do we convert "foo" to "baz"? If so, then I think applying the rules
> again shouldn't matter. But if we don't, and only do a single level,
> then having the caller rewrite the URL before it hands it to "git clone"
> means we may end up unexpectedly doing two levels of rewriting.
>
I see. Thanks for the example. So really what we want is to record the
unencumbered URL (with no rewriting) and then at run time lookup various
places of url.*.insteadOf (which might change with the git version
that you use)
Thanks,
Stefan
^ permalink raw reply
* Re: [PATCH 12/15] unpack-trees: check if we can perform the operation for submodules
From: Jacob Keller @ 2017-02-22 0:31 UTC (permalink / raw)
To: Stefan Beller
Cc: Git mailing list, brian m. carlson, Jonathan Nieder,
Brandon Williams, Junio C Hamano
In-Reply-To: <CAGZ79kbVr5uqwJmzXJxUn0bpe=d_pgnW3_pYW-q0W0iO0KSRtw@mail.gmail.com>
On Tue, Feb 21, 2017 at 3:44 PM, Stefan Beller <sbeller@google.com> wrote:
> On Tue, Feb 21, 2017 at 3:35 PM, Jacob Keller <jacob.keller@gmail.com> wrote:
>> On Tue, Feb 21, 2017 at 2:16 PM, Stefan Beller <sbeller@google.com> wrote:
>>> On Fri, Feb 17, 2017 at 10:42 AM, Jacob Keller <jacob.keller@gmail.com> wrote:
>>>> On Wed, Feb 15, 2017 at 4:38 PM, Stefan Beller <sbeller@google.com> wrote:
>>>>> + if (is_active_submodule_with_strategy(ce, SM_UPDATE_UNSPECIFIED))
>>>>
>>>> Here, and in other cases where we use
>>>> is_active_submodule_with_strategy(), why do we only ever check
>>>> SM_UPDATE_UNSPECIFIED? It seems really weird that we're only going to
>>>> check submodules who's strategy is unspecified, when that defaults to
>>>> checkout if I recall correctly? Shouldn't we check both? This applies
>>>> to pretty much everywhere that you call this function that I noticed,
>>>> which is why I removed the context.
>>>
>>> I am torn between this.
>>>
>>> submodule.<name>.update = {rebase, merge, checkout, none !command}
>>> is currently documented in GIT-CONFIG(1) as
>>>
>>> submodule.<name>.update
>>> The default update procedure for a submodule. This variable is
>>> populated by git submodule init from the gitmodules(5) file. See
>>> description of update command in git-submodule(1).
>>>
>>> and in GIT-SUBMODULE(1) as
>>>
>>> update
>>> [...] can be done in several ways
>>> depending on command line options and the value of
>>> submodule.<name>.update configuration variable. Supported update
>>> procedures are:
>>>
>>> checkout
>>> [...] or no option is given, and
>>> submodule.<name>.update is unset, or if it is set to checkout.
>>>
>>> So the "update" config clearly only applies to the "submodule update"
>>> command, right?
>>>
>>> Well no, "checkout --recurse-submodules" is very similar
>>> to running "submodule update", except with a bit more checks, so you could
>>> think that such an option applies to checkout as well. (and eventually
>>> rebase/merge etc. are supported as well.)
>>>
>>> So initially I assumed both "unspecified" as well as "checkout"
>>> are good matches to support in the first round.
>>>
>>> Then I flip flopped to think that we should not interfere with these
>>> settings at all (The checkout command does checkout and checkout only;
>>> no implicit rebase/merge ever in the future, because that would be
>>> confusing). So ignoring that option seemed like the way to go.
>>
>> Hmm. So it's a bit complicated.
>>
>>>
>>> But ignoring that option is also not the right approach.
>>> What if you have set it to "none" and really *expect* Git to not touch
>>> that submodule?
>>
>> Or set it to "rebase" and suddenly git-checkout is ignoring you and
>> just checking things out anyways.
>>
>>>
>>> So I dunno. Maybe it is a documentation issue, we need to spell out
>>> in the man page for checkout that --recurse-submodules is
>>> following one of these models. Now which is the best default model here?
>>
>> Personally, I would go with that the config option sets the general
>> strategy used by the submodule whenever its updated, regardless of
>> how.
>>
>> So, for example, setting it to none, means that recurse-submoduls will
>> ignore it when checking out. Setting it to rebase, or merge, and the
>> checkout will try to do those things?
>
> That is generally a sound idea when it comes to git-checkout.
>
> What about other future things like git-revert?
> (Ok I already brought up this example too many times; it should have
> a revert-submodules as well switch, which is neither of the current strategies,
> so we'd have to invent a new strategy and make that the default for
> revert. That strategy would make no sense in any other command though)
>
This is where things get tricky, IMHO. The problem is that the
strategy now wants to encompass more things.
> What about "git-rebase --recurse-submodules"?
> Should git-rebase merge the submodules when it is configured to "merge"
> Or just "checkout" (the possibly non-fast-forward-y old sha1) ?
>
> The only sane option IMO is "rebase" as well in the submodules, rewriting
> the submodule pointers in the rebased commits in the superproject.
>
I'm not even really sure what rebase should do here at all. I assume
by this you mean "what would a git-rebase that also rebased submodules
do"
Ofcourse the sane answer might be something like "uhh you have to
decide that for yourself manually" I think this is a really complex
problem to solve, and in this case I do not think rebase should even
rely on the strategy. a "recurse-submodules rebase" would do something
like:
rebase parent as normal, but if a commit changes the submodule, then
it needs to re-create that submodule change using its own rebase
inside the submodule based on the (new) parent from the parent
projects history change, and then commit that as the committed change?
But I don't even know if that really makes sense in all cases either.
I think you could check strategy, and then have rebase go "uhhh here's
what I found, you fix this manually"?
That's quite complicated.
>>
>> Or, if that's not really feasible, have the checkout go "hey.. you
>> asked me to recurse, but uhhh these submodules don't allow me to do
>> checkout, so I'm gonna fail"? I think that's the best approach for
>> now.
>
> So you'd propose to generally use the submodule.<name>.update
> strategies with aggressive error-out but also keeping in mind
> that the strategies might grow by a lot in the future (well only revert
> comes to mind here).
>
> ok, let's do that then.
>
I think that's the safest option. If we add a new strategy, each
command can decide what it should do for that strategy, and we can
decide that in the future. I'm not sure what users expect, but I think
if we start by erroring out on things we can't support, and then if we
decide we can later ,it's not a backwards compatibility hurdle. Where
as if we decide "this works now" but later discover that it cannot,
then,... we have to figure out a lot more backwards compat issues.
> Thanks,
> Stefan
^ permalink raw reply
* Fwd: Typo in worktree man page
From: Casey Rodarmor @ 2017-02-22 0:52 UTC (permalink / raw)
To: git
In-Reply-To: <CANLPe+NVs9sJ7XQqvMabPBLg3DxS2Fyrrg3AzvZPBoWTPpnFzQ@mail.gmail.com>
Hi there,
The git worktree man page mentions the `--detached` flag in the
section on `add`, but the flag is actually called `--detach`.
Best,
Casey
^ permalink raw reply
* Re: Git trademark status and policy
From: G. Sylvie Davies @ 2017-02-22 1:01 UTC (permalink / raw)
To: G. Sylvie Davies, git; +Cc: Git Users, Jeff King
In-Reply-To: <CAAj3zPzrD+R6kDdqR3C7aYTDjaE+Y5zN+MfoXe5EuH4ZPxroHA@mail.gmail.com>
On Tue, Feb 21, 2017 at 7:55 AM, G. Sylvie Davies
<sylvie@bit-booster.com> wrote:
> On Wed, Feb 1, 2017 at 6:26 PM, Jeff King <peff@peff.net> wrote:
>> As many of you already know, the Git project (as a member of Software
>> Freedom Conservancy) holds a trademark on "Git". This email will try to
>> lay out a bit of the history and procedure around the enforcement of
>> that trademark, along with some open questions about policy.
>>
>> I'll use "we" in the text below, which will generally mean the Git
>> Project Leadership Committee (PLC). I.e., the people who represent the
>> Git project as part of Conservancy -- me, Junio Hamano, and Shawn
>> Pearce.
>>
>> We approached Conservancy in Feb 2013 about getting a trademark on Git
>> to ensure that anything calling itself "Git" remained interoperable with
>> Git. Conservancy's lawyer drafted the USPTO application and submitted it
>> that summer. The trademark was granted in late 2014 (more on that delay
>> in a moment).
>>
>> Concurrently, we developed a written trademark policy, which you can
>> find here:
>>
>> https://git-scm.com/trademark
>>
>> This was started from a template that Conservancy uses and customized by
>> Conservancy and the Git PLC.
>>
>> While the original idea was to prevent people from forking the
>> software, breaking compatibility, and still calling it Git, the policy
>> covers several other cases.
>>
>> One is that you can't imply successorship. So you also can't fork the
>> software, call it "Git++", and then tell everybody your implementation
>> is the next big thing.
>>
>> Another is that you can't use the mark in a way that implies association
>> with or endorsement by the Git project. To some degree this is necessary
>> to prevent dilution of the mark for other uses, but there are also cases
>> we directly want to prevent.
>>
>> For example, imagine a software project which is only tangentially
>> related to Git. It might use Git as a side effect, or might just be
>> "Git-like" in the sense of being a distributed system with chained
>> hashes. Let's say as an example that it does backups. We'd prefer it
>> not call itself GitBackups. We don't endorse it, and it's just using the
>> name to imply association that isn't there. You can come up with similar
>> hypotheticals: GitMail that stores mailing list archives in Git, or
>> GitWiki that uses Git as a backing store.
>>
>> Those are all fictitious examples (actually, there _are_ real projects
>> that do each of those things, but they gave themselves much more unique
>> names). But they're indicative of some of the cases we've seen. I'm
>> intentionally not giving the real names here, because my point isn't to
>> shame any particular projects, but to discuss general policy.
>>
>> Careful readers among you may now be wondering about GitHub, GitLab,
>> Gitolite, etc. And now we get back to why it took over a year to get the
>> trademark granted.
>>
>> The USPTO initially rejected our application as confusingly similar to
>> the existing trademark on GitHub, which was filed in 2008. While one
>> might imagine where the "Git" in GitHub comes from, by the time we
>> applied to the USPTO, both marks had been widely used in parallel for
>> years. So we worked out an agreement with GitHub which basically says
>> "we are mutually OK with the other trademark existing".
>>
>> (There was another delay caused by a competing application from a
>> proprietary version control company that wanted to re-brand portions of
>> their system as "GitFocused" (not the real name, but similar in spirit).
>> We argued our right to the name and refused to settle; they eventually
>> withdrew their application).
>>
>> So GitHub is essentially outside the scope of the trademark policy, due
>> to the history. We also decided to explicitly grandfather some major
>> projects that were using similar portmanteaus, but which had generally
>> been good citizens of the Git ecosystem (building on Git in a useful
>> way, not breaking compatibility). Those include GitLab, JGit, libgit2,
>> and some others. The reasoning was generally that it would be a big pain
>> for those projects, which have established their own brands, to have to
>> switch names. It's hard to hold them responsible for picking a name that
>> violated a policy that didn't yet exist.
>>
>> If the "libgit2" project were starting from scratch today, we'd probably
>> ask it to use a different name (because the name may imply that it's an
>> official successor). However, we effectively granted permission for this
>> use and it would be unfair to disrupt that.
>>
>> There's one other policy point that has come up: the written policy
>> disallows the use of "Git" or the logo on merchandise. This is something
>> people have asked about it (e.g., somebody made some Git stress balls,
>> and another person was printing keycaps with a Git logo). We have always
>> granted it, but wanted to reserve the right in case there was some use
>> that we hadn't anticipated that would be confusing or unsavory.
>>
>> Enforcement of the policy is done as cases are brought to the attention
>> of Conservancy and the Git PLC. Sometimes people mail Conservancy
>> directly, and sometimes a use is noticed by the Git PLC, which mails
>> Conservancy. In either case, Conservancy's lawyer pings the Git PLC,
>> and we decide what to do about it, with advice from the lawyer. The end
>> result is usually a letter from the lawyer politely asking them to stop
>> using the trademark.
>>
>> So how does the Git PLC make decisions? We generally try to follow the
>> policy in an equitable way, but there are a lot of corner cases. Here
>> are some rules of thumb we've worked out:
>>
>> - Things that are only tangentially related to Git are out of policy
>> (e.g., if you had a service which rewards bitcoin for people's
>> commits, we'd prefer it not be branded GitRewards).
>>
>> - Anything that claims to be Git but does not interoperate is out.
>> We haven't had to use that one yet.
>>
>> - Portmanteaus ("GitFoo" or "FooGit") are out. Most of the cases run
>> into this rule. For instance, we asked GitHub to not to use "DGit"
>> to refer to their replicated Git solution, and they[1] rebranded.
>> We also asked "GitTorrent" not to use that name based on this rule.
>>
>> - Commands like "git-foo" (so you run "git foo") are generally OK.
>> This is Git's well-known extension mechanism, so it doesn't really
>> imply endorsement (on the other hand, you do not get to complain if
>> you choose too generic a name and conflict with somebody else's use
>> of the same git-foo name).
>>
>> - When "git-foo" exists, we've approved "Git Foo" as a matching
>> project name, but we haven't decided on a general rule to cover this
>> case. The only example here is "Git LFS".
>>
>> So that's more or less where we're at now. In my opinion, a few open
>> questions are:
>>
>> 1. Is the portmanteau clause a good idea? GitTorrent is a possibly
>> interesting case there. It's an open source project trying to
>> make a torrent-like protocol for Git. That's something we'd like to
>> have happen. But does the name imply more endorsement than we're
>> willing to give (especially at an early stage)?
>>
>> 2. Is it a problem that the grandfathering of some names may create a
>> branding advantage? Under the policy today, we wouldn't grant
>> "GitHub" or "GitLab". Does that give an unfair advantage to the
>> incumbents?
>>
>> I think the answer is "yes", but the Git PLC is also not sure that
>> there is a good solution. If we'd thought about trademark issues
>> much earlier, we would have been in different circumstances and
>> probably would have made different decisions. But we didn't, so we
>> have to live with how things developed in the meantime.
>>
>> Loosening now would be a mistake as it would cause a lot of
>> confusion around the trademark and make it harder for us to stop
>> the uses that we really care about stopping now.
>>
>> 3. Was granting "Git LFS" the right call? I think the project is a good
>> one and has worked well with the greater Git community. But I think
>> the name has implied some level of "officialness". We obviously
>> need to allow "git-lfs" as a name. But should the policy have said
>> "you can call this LFS, and the command is git-lfs, but don't say
>> 'Git LFS'". I'm not sure.
>>
>> One option would have been to ask "git-foo" to prefer "Foo for Git"
>> instead of "Git Foo" in their branding (it's too late now for "Git
>> LFS", so this is a hypothetical question for future requests now).
>>
>> 4. I think the merchandise clause has worked fine, and in general the
>> plan is to grant it in most cases. I have trouble thinking of an
>> item I _wouldn't_ want the Git logo on, and I'd rather err on the
>> side of permissiveness than be the arbiter of taste. And having the
>> Git logo on merchandise generally raises awareness of Git.
>>
>> But perhaps people have stronger opinions (either about the type of
>> item, or perhaps the practices of the manufacturer producing it).
>> It's hard to predict how a particular item would impact how people
>> see the Git brand.
>>
>> -Peff
>>
>> [1] I used "they" to refer to GitHub, but as many of you know, I am also
>> employed by GitHub. If you are wondering how that works, I generally
>> abstain from any decisions regarding GitHub (and that includes the
>> "Git LFS" decision, which was a project started by GitHub). That
>> leaves two voting PLC members for those decisions; Conservancy gets
>> a tie-breaking vote, but it has never come up.
>
>
>
> Is "Gitter" allowed? (https://gitter.im/).
>
> More info here:
>
> https://en.wikipedia.org/wiki/Gitter
>
> Also, their twitter handle is @gitchat.
>
> Not sure I'd even classify "gitter" as a portmanteau.
>
As per Junio's earlier email today, "Re: Partnership with Git", sounds
like questions of this sort go to git@sfconservancy.org. CC'ing them.
- Sylvie
^ permalink raw reply
* Re: [PATCH v2] config: reject invalid VAR in 'git -c VAR=VAL command'
From: Junio C Hamano @ 2017-02-22 1:06 UTC (permalink / raw)
To: git@vger.kernel.org; +Cc: Stefan Beller
In-Reply-To: <xmqqd1ebfd9l.fsf_-_@gitster.mtv.corp.google.com>
Junio C Hamano <gitster@pobox.com> writes:
> /* find the last dot (we start from the first dot we just found) */
> - for (last_dot = cp; *cp; cp++)
> + for (; *cp; cp++)
> if (*cp == '.')
> last_dot = cp;
This line probably needs this fix-up on top.
-- >8 --
Subject: [PATCH] config: squelch stupid compiler warnings
Some compilers do not realize that *cp is always '.' when the loop
to find the last dot begins, and instead gives a useless warning
that says last_dot may be uninitialized.
Squelch it by being a bit more explicit if stupid.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
config.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config.c b/config.c
index e7f7ff1938..90de27853f 100644
--- a/config.c
+++ b/config.c
@@ -239,7 +239,7 @@ static int canonicalize_config_variable_name(char *varname)
return -1; /* no section? */
/* find the last dot (we start from the first dot we just found) */
- for (; *cp; cp++)
+ for (last_dot = cp; *cp; cp++)
if (*cp == '.')
last_dot = cp;
--
2.12.0-rc2-231-g83a1c8597c
^ permalink raw reply related
* Re: [PATCH] Documentation: Link git-ls-files to core.quotePath variable.
From: Andreas Heiduk @ 2017-02-22 1:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqh93nfeyj.fsf@gitster.mtv.corp.google.com>
Am 21.02.2017 um 21:48 schrieb Junio C Hamano:
>
> I was waiting for others to comment on this patch but nobody seems
> to be interested. Which is a bit sad, as this may not be a bad
> idea.
>
> If we refer to core.quotePath, the mention of control characters
> being quoted can also be omitted, I think, as that is part of what
> appears in the description of core.quotePath variable.
>
> Alternatively, instead of referring to another page, we can spend
> the additional lines to say what is more interesting to most of the
> readers from that page, e.g.
>
> When `-z` option is not used, a pathname with "unusual" characters
> in it is quoted by enclosing it in a double-quote pair and with
> backslashes the same way strings in C source code are quoted. By
> setting core.quotePath configuration to false, the bytes whose
> values are higher than 0x80 are output verbatim.
>
Without `-z` but with core.quotePath=false the path may still be
surrounded with double-quotes if it contains control characters (and
some more). The documentation in `core.quotePath` mentions this, your
"inline" alternative does not.
I will send second patch. :-)
^ permalink raw reply
* Re: [PATCH] Documentation: Link git-ls-files to core.quotePath variable.
From: Andreas Heiduk @ 2017-02-22 1:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <xmqqh93nfeyj.fsf@gitster.mtv.corp.google.com>
[PATCH] Documentation: Clarify core.quotePath, remove cruft in
git-ls-files.
Signed-off-by: Andreas Heiduk <asheiduk@gmail.com>
---
I have merged the best parts about quoting into the core.quotePath
description and cleaned up the text in git-ls-files.txt regarding the
control characters.
Documentation/config.txt | 22 ++++++++++++----------
Documentation/git-ls-files.txt | 11 ++++++-----
2 files changed, 18 insertions(+), 15 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index f4721a0..25e65ae 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -340,16 +340,18 @@ core.checkStat::
all fields, including the sub-second part of mtime and ctime.
core.quotePath::
- The commands that output paths (e.g. 'ls-files',
- 'diff'), when not given the `-z` option, will quote
- "unusual" characters in the pathname by enclosing the
- pathname in a double-quote pair and with backslashes the
- same way strings in C source code are quoted. If this
- variable is set to false, the bytes higher than 0x80 are
- not quoted but output as verbatim. Note that double
- quote, backslash and control characters are always
- quoted without `-z` regardless of the setting of this
- variable.
+ Commands that output paths (e.g. 'ls-files', 'diff'), will
+ quote "unusual" characters in the pathname by enclosing the
+ pathname in double-quotes and escaping those characters with
+ backslashes in the same way C escapes control characters (e.g.
+ `\t` for TAB, `\n` for LF, `\\` for backslash) or bytes with
+ values larger than 0x80 (e.g. octal `\265` for "micro"). If
+ this variable is set to false, bytes higher than 0x80 are not
+ considered "unusual" any more. Double-quotes, backslash and
+ control characters are always escaped regardless of the
+ setting of this variable. Many commands can output pathnames
+ completely verbatim using the `-z` option. The default value is
+ true.
core.eol::
Sets the line ending type to use in the working directory for
diff --git a/Documentation/git-ls-files.txt b/Documentation/git-ls-files.txt
index d2b17f2..88df561 100644
--- a/Documentation/git-ls-files.txt
+++ b/Documentation/git-ls-files.txt
@@ -76,7 +76,8 @@ OPTIONS
succeed.
-z::
- \0 line termination on output.
+ \0 line termination on output and do not quote filenames.
+ See OUTPUT below for more information.
-x <pattern>::
--exclude=<pattern>::
@@ -192,10 +193,10 @@ the index records up to three such pairs; one from
tree O in stage
the user (or the porcelain) to see what should eventually be recorded
at the
path. (see linkgit:git-read-tree[1] for more information on state)
-When `-z` option is not used, TAB, LF, and backslash characters
-in pathnames are represented as `\t`, `\n`, and `\\`,
-respectively. The path is also quoted according to the
-configuration variable `core.quotePath` (see linkgit:git-config[1]).
+Without the `-z` option pathnamens with "unusual" characters are
+quoted as explained for the configuration variable `core.quotePath`
+(see linkgit:git-config[1]). Using `-z` the filename is output
+verbatim and the line is terminated by a NUL byte.
Exclude Patterns
--
2.7.4
^ permalink raw reply related
* [PATCH] git svn branch fails with authenticaton failures
From: Hiroshi Shirosaki @ 2017-02-22 2:37 UTC (permalink / raw)
To: git; +Cc: Hiroshi Shirosaki
I have the following authentication failure while svn rebase and
svn dcommit works fine without authentication failures.
$ git svn branch v7_3
Copying https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx at r27519
to https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/v7_3...
Can't create session: Unable to connect to a repository at URL
'https://xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx': No more
credentials or we tried too many times.
Authentication failed at
C:\Program Files\Git\mingw64/libexec/git-core\git-svn line 1200.
I can workaround the issue to add auth configuration to
SVN::Client->new().
---
git-svn.perl | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index fa42364..13fa4ad 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1175,10 +1175,10 @@ sub cmd_branch {
::_req_svn();
require SVN::Client;
+ my ($config, $baton, $callbacks) = Git::SVN::Ra::prepare_config_once();
my $ctx = SVN::Client->new(
- config => SVN::Core::config_get_config(
- $Git::SVN::Ra::config_dir
- ),
+ auth => $baton,
+ config => $config,
log_msg => sub {
${ $_[0] } = defined $_message
? $_message
--
2.7.4
^ permalink raw reply related
* Re: url.<base>.insteadOf vs. submodules
From: Junio C Hamano @ 2017-02-22 2:59 UTC (permalink / raw)
To: Stefan Beller; +Cc: Jeff King, Toolforger, git@vger.kernel.org
In-Reply-To: <CAGZ79ka2S=V1x2fSQq+E-yE0Ao36-4tuTvnD6uXpPXJPLFN3JA@mail.gmail.com>
Stefan Beller <sbeller@google.com> writes:
>> This is true even without any submodules. The Git project itself
>> does not even care you are Stefan, but you still can and do add
>> [user] name = "Stefan Beller" to .git/config of your clone of the
>> Git project. A clone of the project may want to know more than the
>> data project itself keeps track of to describe the context in which
>> the particular clone is being used. And .git/config is a good place
>> to keep such pieces of information.
>
> This analogy is less clear to me than the kernel& appliance.
> When applying it to you (user.name=Junio) that has write powers
> over the blessed repository, the project cares a lot about you. ;)
The name that is recorded in the project history "Stefan Beller"
matters and the project cares about it, when the commit created in
that repository is pulled (or exported and imported via the e-mail
to "git am" route). But what name you have configured in your
repository's .git/config, or the presense of your particular
repository for that matter, is much less significant (and that
applies to my primary working area as well). The point is that the
project and a particular clone of it are entities at conceptually
different levels.
>> So I would think it is entirely reasonable if "git submodule init
>> sub" that is run in the superproject to initialize "sub" writes
>> something in "sub/.git" to tell that "sub" is used in the context of
>> that particular toplevel superproject and customize its behavour
>> accordingly. Perhaps it may want to add the url.*.insteadOf that is
>> useful for updating the submodule repository when it does "submodule
>> init", for example.
>
> Do we want to invent a special value for url.*.insteadOf to mean
> "look up in superproject, so I don't have to keep
> a copy that may get stale" ?
My gut feeling is that we should do the selective/filtered include
Peff mentioned when a repository is known to be used as a submodule
of somebody else.
^ permalink raw reply
* Re: [PATCH 4/4 v4] sha1_name.c: teach get_sha1_1 "-" shorthand for "@{-1}"
From: Siddharth Kannan @ 2017-02-22 6:27 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git List, Matthieu Moy, Pranit Bauva, Jeff King, pclouds,
brian m. carlson
In-Reply-To: <xmqqshn8ip0j.fsf@gitster.mtv.corp.google.com>
On 21 February 2017 at 02:00, Junio C Hamano <gitster@pobox.com> wrote:
> Siddharth Kannan <kannan.siddharth12@gmail.com> writes:
> > So, is it okay to stop with just supporting "-" and not support things
> > like "-@{yesterday}"?
>
> If the approach to turn "-" into "@{-1}" at that spot you did will
> cause "-@{yesterday}" to barf, then I'd say so be it for now ;-).
> We can later spread the understanding of "-" to functions deeper in
> the callchain and add support for that, no?
Yes, this can be done later. I will send these patches again, with
only the changes that are discussed here.
I will keep the tests for "-@{yesterday}" as failing tests, if that
would help in finding this again and fixing it later.
Thanks for your review, Junio!
--
Best Regards,
- Siddharth Kannan.
^ permalink raw reply
* Re: Partnership with Git
From: Nikita Malikov @ 2017-02-22 9:06 UTC (permalink / raw)
To: Junio C Hamano, Dov Grobgeld; +Cc: Konstantin Khomoutov, git
In-Reply-To: <xmqqy3wzfjrq.fsf@gitster.mtv.corp.google.com>
Dov, Junio, Konstantin
Thank you for answering. Your information helped me!
And thank you Git Community for so quick and clear replies. We wish you all
the best from Devart team =)
Best regards
Nikita Malikov
Best regards
Nikita Malikov
--------------------------------------------------
From: "Junio C Hamano" <gitster@pobox.com>
Sent: 21 February, 2017 21:04
To: "Dov Grobgeld" <dov.grobgeld@gmail.com>
Cc: "Nikita Malikov" <nikitam@devart.com>; "Konstantin Khomoutov"
<kostix+git@007spb.ru>; <git@vger.kernel.org>
Subject: Re: Partnership with Git
> Dov Grobgeld <dov.grobgeld@gmail.com> writes:
>
>> As git is free software, you are free to use it in any way you see fit,
>> as
>> long as you adhere to its licensing terms, and to the copyright
>> restrictions on using the term "git". Thus there is no need to ask
>> permission and there does not on the git side exist any entity interested
>> in "cross marketing activities".
>
> s/copyright/trademark/.
>
> As one of Software Freedom Conservancy projects, I suspect that the
> Git PLC git@sfconservancy.org may be the closest to such "entity"
> that represents open source Git community's interest to the outside
> world with help from lawyers.
>
> Not that I think Git PLC is interested in such a cross marketting
> arrangement, but if Devart wants to advertise on their webpage
> saying "we support Git by making contributions to SFC" or something
> like that, they are the people to talk to.
>
^ permalink raw reply
* [RFC][Git GUI] Make Commit message field in git GUI re sizable.
From: Jessie Hernandez @ 2017-02-22 9:27 UTC (permalink / raw)
To: git
Hi all,
I have been using git for a few years now and really like the software.
I have a small annoyance and was wondering if I could get the communities
view on this.
When using git GUI I find it handy to be able to re-size the "Unstaged
Changes" and the "Staged Changed" fields.
I would like the same thing for the "Commit Message" field, or to have it
re-size with the git GUI window.
I can re-size the "Commit Message" vertically when making the "Modified"
panel smaller.
Does this make sense?
I would be happy to get into more detail if that is necessary or if
something is not clear.
Thank you.
-----------------
Jessie Hernandez
^ permalink raw reply
* Re: [RFC][Git GUI] Make Commit message field in git GUI re sizable.
From: Bert Wesarg @ 2017-02-22 9:50 UTC (permalink / raw)
To: Jessie Hernandez; +Cc: Git Mailing List, Pat Thoyts
In-Reply-To: <44fd4dce451fb0783de02c0a8c4a14aa.squirrel@mail.jessiehernandez.com>
HI,
the reason why it is fixed, is because commit messages should be
wrapped at 76 characters to be used in mails. So it helps you with the
wrapping.
Bert
On Wed, Feb 22, 2017 at 10:27 AM, Jessie Hernandez
<jessie@jessiehernandez.com> wrote:
> Hi all,
>
> I have been using git for a few years now and really like the software.
> I have a small annoyance and was wondering if I could get the communities
> view on this.
>
> When using git GUI I find it handy to be able to re-size the "Unstaged
> Changes" and the "Staged Changed" fields.
>
> I would like the same thing for the "Commit Message" field, or to have it
> re-size with the git GUI window.
>
> I can re-size the "Commit Message" vertically when making the "Modified"
> panel smaller.
>
> Does this make sense?
> I would be happy to get into more detail if that is necessary or if
> something is not clear.
>
> Thank you.
>
> -----------------
> Jessie Hernandez
>
>
^ permalink raw reply
* Re: [RFC][Git GUI] Make Commit message field in git GUI re sizable.
From: Jessie Hernandez @ 2017-02-22 11:59 UTC (permalink / raw)
To: Bert Wesarg; +Cc: Jessie Hernandez, Git Mailing List, Pat Thoyts
In-Reply-To: <CAKPyHN3f0NwMt1aXx6keSrhaiqRqH6s_xQFdKv5rZ+pL7fmXFw@mail.gmail.com>
> HI,
>
> the reason why it is fixed, is because commit messages should be
> wrapped at 76 characters to be used in mails. So it helps you with the
> wrapping.
>
> Bert
Right ok. I understand.
Knowing this I think I might start writing my commit messages differently
then.
Thank you for this.
Regards
-----------------
Jessie Hernandez
>
>
> On Wed, Feb 22, 2017 at 10:27 AM, Jessie Hernandez
> <jessie@jessiehernandez.com> wrote:
>> Hi all,
>>
>> I have been using git for a few years now and really like the software.
>> I have a small annoyance and was wondering if I could get the
>> communities
>> view on this.
>>
>> When using git GUI I find it handy to be able to re-size the "Unstaged
>> Changes" and the "Staged Changed" fields.
>>
>> I would like the same thing for the "Commit Message" field, or to have
>> it
>> re-size with the git GUI window.
>>
>> I can re-size the "Commit Message" vertically when making the "Modified"
>> panel smaller.
>>
>> Does this make sense?
>> I would be happy to get into more detail if that is necessary or if
>> something is not clear.
>>
>> Thank you.
>>
>> -----------------
>> Jessie Hernandez
>>
>>
>
^ permalink raw reply
* [PATCH] Documentation: use brackets for optional arguments
From: brian m. carlson @ 2017-02-22 12:25 UTC (permalink / raw)
To: git
The documentation for git blame used vertical bars for optional
arguments to -M and -C, which is unusual and potentially confusing.
Since most man pages use brackets for optional items, and that's
consistent with how we document the same options for git diff and
friends, use brackets here, too.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
---
Documentation/blame-options.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/blame-options.txt b/Documentation/blame-options.txt
index 2669b87c9d..dc41957afa 100644
--- a/Documentation/blame-options.txt
+++ b/Documentation/blame-options.txt
@@ -77,7 +77,7 @@ include::line-range-format.txt[]
terminal. Can't use `--progress` together with `--porcelain`
or `--incremental`.
--M|<num>|::
+-M[<num>]::
Detect moved or copied lines within a file. When a commit
moves or copies a block of lines (e.g. the original file
has A and then B, and the commit changes it to B and then
@@ -93,7 +93,7 @@ alphanumeric characters that Git must detect as moving/copying
within a file for it to associate those lines with the parent
commit. The default value is 20.
--C|<num>|::
+-C[<num>]::
In addition to `-M`, detect lines moved or copied from other
files that were modified in the same commit. This is
useful when you reorganize your program and move code
^ permalink raw reply related
* Re: Fwd: Typo in worktree man page
From: brian m. carlson @ 2017-02-22 12:32 UTC (permalink / raw)
To: Casey Rodarmor; +Cc: git
In-Reply-To: <CANLPe+OaSnNb1jhAnFtMsOCfho0H7mHVHiXs7rqo6ZHNvRe3-w@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
On Tue, Feb 21, 2017 at 04:52:11PM -0800, Casey Rodarmor wrote:
> Hi there,
>
> The git worktree man page mentions the `--detached` flag in the
> section on `add`, but the flag is actually called `--detach`.
Thanks for reporting this. I'll send a patch.
--
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 868 bytes --]
^ permalink raw reply
* [PATCH] Documentation: correctly spell git worktree --detach
From: brian m. carlson @ 2017-02-22 12:34 UTC (permalink / raw)
To: git; +Cc: Casey Rodarmor
In-Reply-To: <CANLPe+OaSnNb1jhAnFtMsOCfho0H7mHVHiXs7rqo6ZHNvRe3-w@mail.gmail.com>
The option is “--detach”, but we accidentally spelled it “--detached” at
one point in the man page.
Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net>
Reported-by: Casey Rodarmor <casey@rodarmor.com>
---
Documentation/git-worktree.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-worktree.txt b/Documentation/git-worktree.txt
index e257c19ebe..553cf8413f 100644
--- a/Documentation/git-worktree.txt
+++ b/Documentation/git-worktree.txt
@@ -52,7 +52,7 @@ is linked to the current repository, sharing everything except working
directory specific files such as HEAD, index, etc. `-` may also be
specified as `<branch>`; it is synonymous with `@{-1}`.
+
-If `<branch>` is omitted and neither `-b` nor `-B` nor `--detached` used,
+If `<branch>` is omitted and neither `-b` nor `-B` nor `--detach` used,
then, as a convenience, a new branch based at HEAD is created automatically,
as if `-b $(basename <path>)` was specified.
^ permalink raw reply related
* feature request: user email config per domain
From: Tushar Kapila @ 2017-02-22 13:12 UTC (permalink / raw)
To: git
I can set my email via:
git config --global user.email tgkprog@xyz.dom
this is dangerous when I use this my office or in a multi repository
provider environment where my email is different for a few (like
tgkprog@search.com for github and tushar@mycompany.com for my company
private repo). I know I can over ride it per repository, but sometimes
forget to do that. And even if I unset it, it inadvertantly gets set
elsewhere when I make a repo and the site 'helps' me by showing me the
commands to init and clone my new repo.
I did an analysis on a bunch of company git repositories using jgit
(only master branch), and we have 57 emails out of 346 which are not
the company email. Also in there are cases when name is the same but
some commits are by email 1 and others by email 2, because of this
global config. As some of us work on open source and company repos on
the same computer.
Feature request : can we have a config for email per repo domain ?
Something like:
git config --global domain.user.email tgkprog@test.xyz.com
testing.abc.doman:8080
git config --global domain.user.email tgkprog@xyz.com abc.doman:80
git config --global domain.user.email tgkprog@search.com github.com
So when remote URL has github.com push as tgkprog@search.com but for
testing.abc.doman:8080 use tgkprog@test.xyz.com ?
For me one name is enough. But can do the same for name if others need it?
Thank you.
Regards
Tushar Kapila
^ permalink raw reply
* Re: feature request: user email config per domain
From: Pranit Bauva @ 2017-02-22 13:51 UTC (permalink / raw)
To: Tushar Kapila; +Cc: Git List
In-Reply-To: <CAN0Skmmjd5Y0uWz_WC69mAStucZ6nR0mjdp4-ODJz2UnTaB-eQ@mail.gmail.com>
Hey Tushar,
When you run `git config --global user.email abc@xyz.com` it writes
out this setting in ~/.gitconfig which is then considered to be
"global" ie. this same email will be used for every repo, but ...
You can always override this. Let's say there is a repo named "foo" in
which you want the email "xyz@abc.com", then you go inside that folder
and type `git config user.email xyz@abc.com`. Note: the option
`--global` is skipped here. This creates a file `.gitconfig` in the
folder "foo" and now whenever you commit, the .gitconfig file inside
the repo will get the first preference and then the global
~/.gitconfig.
This will work for you assuming that you have different repos for your
company and for your open source work. Will this solve your problem?
Regards,
Pranit Bauva
^ permalink raw reply
* [PATCH v5 00/24] Remove submodule from files-backend.c
From: Nguyễn Thái Ngọc Duy @ 2017-02-22 14:04 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Michael Haggerty, Johannes Schindelin,
Ramsay Jones, Stefan Beller, novalis,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20170218133303.3682-1-pclouds@gmail.com>
v5 goes a bit longer than v4, basically:
- files_path() is broken down into three smaller functions,
files_{packed_refs,reflog,refname}_path().
- most of store-based api is added because..
- test-ref-store.c is added with t1405 and t1406 for some basic tests
I'm not aimimg for complete ref store coverage. But we can continue
to improve from there.
- refs_store_init() now takes a "permission" flag, like open().
Operations are allowed or forbidden based on this flag. The
submodule_allowed flag is killed. files_assert_main.. remains.
- get_*_ref_store() remain public api because it's used by
test-ref-store.c and pack-refs.c.
- files-backend.c should now make no function calls that implicitly
target the main store. But this will have to be tested more to be
sure. I'm tempted to add a tracing backend just for this purpose.
Junio, if you take this on 'pu', you'll have to kick my other two
series out (they should not even compile). I'm not resending them
until I get a "looks mostly ok" from Michael. No point in updating
them when this series keeps moving.
This series is also available on my github repo. branch
files-backend-git-dir-2.
Nguyễn Thái Ngọc Duy (24):
refs.h: add forward declaration for structs used in this file
files-backend: make files_log_ref_write() static
files-backend: add and use files_packed_refs_path()
files-backend: convert git_path() to strbuf_git_path()
files-backend: move "logs/" out of TMP_RENAMED_LOG
files-backend: add and use files_reflog_path()
files-backend: add and use files_refname_path()
files-backend: remove the use of git_path()
refs.c: introduce get_main_ref_store()
refs: rename lookup_ref_store() to lookup_submodule_ref_store()
refs.c: flatten get_ref_store() a bit
refs.c: kill register_ref_store(), add register_submodule_ref_store()
refs.c: make get_main_ref_store() public and use it
path.c: move some code out of strbuf_git_path_submodule()
refs: move submodule code out of files-backend.c
files-backend: replace submodule_allowed check in files_downcast()
refs: rename get_ref_store() to get_submodule_ref_store() and make it public
refs: add new ref-store api
refs: new transaction related ref-store api
files-backend: avoid ref api targetting main ref store
refs: delete pack_refs() in favor of refs_pack_refs()
t/helper: add test-ref-store to test ref-store functions
t1405: some basic tests on main ref store
t1406: new tests for submodule ref store
Makefile | 1 +
builtin/pack-refs.c | 2 +-
path.c | 34 +--
refs.c | 411 ++++++++++++++++++--------
refs.h | 100 ++++++-
refs/files-backend.c | 509 +++++++++++++++++++++-----------
refs/refs-internal.h | 64 +---
submodule.c | 31 ++
submodule.h | 1 +
t/helper/.gitignore | 1 +
t/helper/test-ref-store.c (new) | 274 +++++++++++++++++
t/t1405-main-ref-store.sh (new +x) | 123 ++++++++
t/t1406-submodule-ref-store.sh (new +x) | 95 ++++++
13 files changed, 1269 insertions(+), 377 deletions(-)
create mode 100644 t/helper/test-ref-store.c
create mode 100755 t/t1405-main-ref-store.sh
create mode 100755 t/t1406-submodule-ref-store.sh
--
2.11.0.157.gd943d85
^ permalink raw reply
* [PATCH v5 01/24] refs.h: add forward declaration for structs used in this file
From: Nguyễn Thái Ngọc Duy @ 2017-02-22 14:04 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Michael Haggerty, Johannes Schindelin,
Ramsay Jones, Stefan Beller, novalis,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20170222140450.30886-1-pclouds@gmail.com>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
refs.h | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/refs.h b/refs.h
index 9fbff90e7..c494b641a 100644
--- a/refs.h
+++ b/refs.h
@@ -1,6 +1,11 @@
#ifndef REFS_H
#define REFS_H
+struct object_id;
+struct ref_transaction;
+struct strbuf;
+struct string_list;
+
/*
* Resolve a reference, recursively following symbolic refererences.
*
@@ -144,7 +149,6 @@ int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
* `ref_transaction_commit` is called. So `ref_transaction_verify`
* won't report a verification failure until the commit is attempted.
*/
-struct ref_transaction;
/*
* Bit values set in the flags argument passed to each_ref_fn() and
--
2.11.0.157.gd943d85
^ permalink raw reply related
* [PATCH v5 02/24] files-backend: make files_log_ref_write() static
From: Nguyễn Thái Ngọc Duy @ 2017-02-22 14:04 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Michael Haggerty, Johannes Schindelin,
Ramsay Jones, Stefan Beller, novalis,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20170222140450.30886-1-pclouds@gmail.com>
Created in 5f3c3a4e6f (files_log_ref_write: new function - 2015-11-10)
but probably never used outside refs-internal.c
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
refs/files-backend.c | 3 +++
refs/refs-internal.h | 4 ----
2 files changed, 3 insertions(+), 4 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index db3bd42a9..1ebd59ec0 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -165,6 +165,9 @@ static struct ref_entry *create_dir_entry(struct files_ref_store *ref_store,
const char *dirname, size_t len,
int incomplete);
static void add_entry_to_dir(struct ref_dir *dir, struct ref_entry *entry);
+static int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
+ const unsigned char *new_sha1, const char *msg,
+ int flags, struct strbuf *err);
static struct ref_dir *get_ref_dir(struct ref_entry *entry)
{
diff --git a/refs/refs-internal.h b/refs/refs-internal.h
index fa93c9a32..f732473e1 100644
--- a/refs/refs-internal.h
+++ b/refs/refs-internal.h
@@ -228,10 +228,6 @@ struct ref_transaction {
enum ref_transaction_state state;
};
-int files_log_ref_write(const char *refname, const unsigned char *old_sha1,
- const unsigned char *new_sha1, const char *msg,
- int flags, struct strbuf *err);
-
/*
* Check for entries in extras that are within the specified
* directory, where dirname is a reference directory name including
--
2.11.0.157.gd943d85
^ permalink raw reply related
* [PATCH v5 03/24] files-backend: add and use files_packed_refs_path()
From: Nguyễn Thái Ngọc Duy @ 2017-02-22 14:04 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Michael Haggerty, Johannes Schindelin,
Ramsay Jones, Stefan Beller, novalis,
Nguyễn Thái Ngọc Duy
In-Reply-To: <20170222140450.30886-1-pclouds@gmail.com>
Keep repo-related path handling in one place. This will make it easier
to add submodule/multiworktree support later.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
refs/files-backend.c | 29 ++++++++++++++++++-----------
1 file changed, 18 insertions(+), 11 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 1ebd59ec0..4676525de 100644
--- a/refs/files-backend.c
+++ b/refs/files-backend.c
@@ -923,6 +923,8 @@ struct files_ref_store {
*/
const char *submodule;
+ char *packed_refs_path;
+
struct ref_entry *loose;
struct packed_ref_cache *packed;
};
@@ -985,7 +987,14 @@ static struct ref_store *files_ref_store_create(const char *submodule)
base_ref_store_init(ref_store, &refs_be_files);
- refs->submodule = xstrdup_or_null(submodule);
+ if (submodule) {
+ refs->submodule = xstrdup(submodule);
+ refs->packed_refs_path = git_pathdup_submodule(
+ refs->submodule, "packed-refs");
+ return ref_store;
+ }
+
+ refs->packed_refs_path = git_pathdup("packed-refs");
return ref_store;
}
@@ -1153,19 +1162,18 @@ static void read_packed_refs(FILE *f, struct ref_dir *dir)
strbuf_release(&line);
}
+static const char *files_packed_refs_path(struct files_ref_store *refs)
+{
+ return refs->packed_refs_path;
+}
+
/*
* Get the packed_ref_cache for the specified files_ref_store,
* creating it if necessary.
*/
static struct packed_ref_cache *get_packed_ref_cache(struct files_ref_store *refs)
{
- char *packed_refs_file;
-
- if (refs->submodule)
- packed_refs_file = git_pathdup_submodule(refs->submodule,
- "packed-refs");
- else
- packed_refs_file = git_pathdup("packed-refs");
+ const char *packed_refs_file = files_packed_refs_path(refs);
if (refs->packed &&
!stat_validity_check(&refs->packed->validity, packed_refs_file))
@@ -1184,7 +1192,6 @@ static struct packed_ref_cache *get_packed_ref_cache(struct files_ref_store *ref
fclose(f);
}
}
- free(packed_refs_file);
return refs->packed;
}
@@ -2160,7 +2167,7 @@ static int lock_packed_refs(struct files_ref_store *refs, int flags)
}
if (hold_lock_file_for_update_timeout(
- &packlock, git_path("packed-refs"),
+ &packlock, files_packed_refs_path(refs),
flags, timeout_value) < 0)
return -1;
/*
@@ -2426,7 +2433,7 @@ static int repack_without_refs(struct files_ref_store *refs,
return 0; /* no refname exists in packed refs */
if (lock_packed_refs(refs, 0)) {
- unable_to_lock_message(git_path("packed-refs"), errno, err);
+ unable_to_lock_message(files_packed_refs_path(refs), errno, err);
return -1;
}
packed = get_packed_refs(refs);
--
2.11.0.157.gd943d85
^ permalink raw reply related
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