On Thu, Feb 16, 2017 at 11:17 PM, Jeff King wrote:
> This isn't difflame's fault; that's what "git blame" tells you about
> that line. But since I already told difflame "v2.6.5..HEAD", it would
> probably make sense to similarly limit the blame to that range. That
> turns up a boundary commit for
On Tue, Feb 14, 2017 at 11:19:05PM -0600, Edmundo Carmona Antoranz wrote:
> I've been working on detecting revisions where a "real" deletion was
> made and I think I advanced a lot in that front. I still have to work
> on many scenarios (renamed files, for example... also performance) but
> at lea
On Thu, Feb 16, 2017 at 01:40:00PM +0100, Christian Couder wrote:
> > I started to add some tests, but I had second thoughts. It _is_ nice
> > to show off the fix, but as far as regressions go, this specific case is
> > unlikely to come up again. What would be more valuable, I think, is a
> > test
On Fri, Feb 17, 2017 at 02:51:36AM +0100, Luna Kid wrote:
> tl;dr; --> Please add --no-diff (or --msg-only) to git show. We'll
> love you for that. :)
I think it is already spelled "--no-patch", or "-s" for short.
> Please note that "show" is such a profoundly generic command verb,
> probably al
When the current branch is renamed with 'git branch -m/-M' or deleted
with 'git update-ref -m -d', the event is recorded in HEAD's log
with an empty message.
In preparation for adding a more meaningful message to HEAD's log in
these cases, update delete_ref() to take a message argument and pass
it
Now that delete_refs() accepts a reflog message, pass the
user-provided message to delete_refs() rather than silently dropping
it. The doesn't matter for the deleted ref's log because the log is
deleted along with the ref, but this entry will show up in HEAD's
reflog when deleting a checked out br
When the current branch is renamed, the deletion of the old ref is
recorded in HEAD's log with an empty message. Now that delete_refs()
accepts a reflog message, provide a more descriptive message. This
message will not be included in the reflog of the renamed branch, but
its log already covers t
[Sorry for the slow response.]
Jeff King writes:
> On Mon, Jan 16, 2017 at 06:17:29PM -0500, Kyle Meyer wrote:
[...]
>>$ cat .git/logs/refs/heads/new-master
>>0... 68730... Kyle Meyer 1484607020 -0500 commit
>> (initial): Add file.txt
>>68730... 68730... Kyle Meyer 1484607
Hello,
tl;dr; --> Please add --no-diff (or --msg-only) to git show. We'll
love you for that. :)
Expanded:
(I've been a casual git user for 2-3 years; "casual" means using a
small subset, nowadays daily, with some less trivial things at times,
like per-commit patching for post-hoc auto-versioning
Jeff King writes:
> On Thu, Feb 16, 2017 at 11:30:28AM +0100, Lars Schneider wrote:
>
>>
>> > On 16 Feb 2017, at 00:48, Junio C Hamano wrote:
>> >
>> > The "git -c = cmd" mechanism is to pretend that a
>>
>> The problem is also present for gitconfig variables e.g.
>> git config --local submod
Unknown writes:
> В Чт, 16/02/2017 в 15:33 -0800, Junio C Hamano пишет:
>>
>> Thanks. Queued with minor log message fixes and pushed out.
>
> If is not too late, please check the version 3.
I already squashed in the change s/bufp/buf/ in the version I queued
and pushed out on 'pu', so we shoul
Dear Friend,
I would like to discuss a very important issue with you. I am writing to find
out if this is your valid email. Please, let me know if this email is valid
Kind regards
Adrien Saif
Attorney to Qatif Group of Companies
В Чт, 16/02/2017 в 15:33 -0800, Junio C Hamano пишет:
> Maxim Moseychuk writes:
>
> > In some places static size buffers can't store formatted string.
> > If it be happen then git die.
> >
> > Jonathan Tan: Thanks a lot for your help.
> >
> > Maxim Moseychuk (2):
> > bisect_next_all: convert
Maxim Moseychuk writes:
> In some places static size buffers can't store formatted string.
> If it be happen then git die.
>
> Jonathan Tan: Thanks a lot for your help.
>
> Maxim Moseychuk (2):
> bisect_next_all: convert xsnprintf to xstrfmt
> stop_progress_msg: convert xsnprintf to xstrfmt
>
stop_progress_msg() is rarely used and is not demanding to
performance. Use dynamically allocates memory.
Signed-off-by: Maxim Moseychuk
---
progress.c | 11 ---
1 file changed, 4 insertions(+), 7 deletions(-)
diff --git a/progress.c b/progress.c
index 76a88c573..29378caa0 100644
--- a/
In some places fixed-size buffers can't store formatted string.
If it be happen then git die.
Jonathan Tan, Jeff King thanks a lot for your help.
This is really my first patches. Your help is invaluable.
Maxim Moseychuk (2):
bisect_next_all(): fix bisect crash when used the gettext translation
The buffer steps_msg[32] is too small.
Translated "(roughly %d step)" string can not be located in the buffer.
Solution: using xstrfmt which dynamically allocates memory.
Dummy solution: just increase steps_msg size but is not safe.
That feels pretty hacky, though. In practice the set of translat
On Thu, Feb 16, 2017 at 11:30:28AM +0100, Lars Schneider wrote:
>
> > On 16 Feb 2017, at 00:48, Junio C Hamano wrote:
> >
> > The "git -c = cmd" mechanism is to pretend that a
>
> The problem is also present for gitconfig variables e.g.
> git config --local submodule.UPPERSUB.update none
Hrm,
On Thu, Feb 16, 2017 at 2:56 PM, Stefan Beller wrote:
> On Thu, Feb 16, 2017 at 2:54 PM, Jacob Keller wrote:
>> On Thu, Feb 16, 2017 at 2:00 PM, Junio C Hamano wrote:
>>> Stefan Beller writes:
>>>
Integrate updating the submodules into git checkout,...
>>>
>>> It was more or less a pleasan
On Wed, Feb 15, 2017 at 03:37:37PM -0800, Junio C Hamano wrote:
> Stefan Beller writes:
>
> > Yes; though I'd place it in strbuf.{c,h} as it is operating
> > on the internals of the strbuf. (Do we make any promises outside of
> > strbuf about the internals? I mean we use .buf all the time, so ma
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
I'd like to get pull requests for
On Thu, Feb 16, 2017 at 02:36:10PM -0800, Jacob Keller wrote:
> > Whenever I run "git push --force(-with-lease)" I get a variation of
> >
> > Counting objects: 187, done.
> > Delta compression using up to 12 threads.
> > Compressing objects: 100% (126/126), done.
> > Writing objects: 100% (187/187
On Thu, Feb 16, 2017 at 2:54 PM, Jacob Keller wrote:
> On Thu, Feb 16, 2017 at 2:00 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> Integrate updating the submodules into git checkout,...
>>
>> It was more or less a pleasant read, once I decided to pretend that
>> I were a machine who
This series looks good to me.
Thanks,
Stefan
On Thu, Feb 16, 2017 at 2:00 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> Integrate updating the submodules into git checkout,...
>
> It was more or less a pleasant read, once I decided to pretend that
> I were a machine who uses identifiers only to identify locations in
> the program ;
On Thu, Feb 16, 2017 at 1:58 PM, Hilco Wijbenga
wrote:
> Hi all,
>
> Whenever I run "git push --force(-with-lease)" I get a variation of
>
> Counting objects: 187, done.
> Delta compression using up to 12 threads.
> Compressing objects: 100% (126/126), done.
> Writing objects: 100% (187/187), 21.3
On Wed, Feb 15, 2017 at 4:38 PM, Stefan Beller wrote:
> +int touch_submodules_in_worktree(void)
> +{
> + /*
> +* Update can't be "none", "merge" or "rebase",
> +* treat any value as OFF, except an explicit ON.
> +*/
> + return config_update_recurse_submodules ==
Stefan Beller writes:
> Integrate updating the submodules into git checkout,...
It was more or less a pleasant read, once I decided to pretend that
I were a machine who uses identifiers only to identify locations in
the program ;-) IOW, for human consumption, the new names introduced
were someti
Hi all,
Whenever I run "git push --force(-with-lease)" I get a variation of
Counting objects: 187, done.
Delta compression using up to 12 threads.
Compressing objects: 100% (126/126), done.
Writing objects: 100% (187/187), 21.35 KiB | 0 bytes/s, done.
Total 187 (delta 78), reused 71 (delta 20)
wa
Dear Friend,
My name is Dr.Kabo Uago, I have an inheritance fund for you, contact
me for more fund details.
Regards,
Dr.Kabo Uago
On Thu, Feb 16, 2017 at 1:15 PM, Junio C Hamano wrote:
> [administrivia: I've been seeing "unlisted-recipients:; (no To-header on
> input)"
> for all of your recent patches. Can it be corrected on your end, please?]
I cc'd everyone and had no to field, actually. Maybe git-send-email should
comp
Stefan Beller writes:
The title was ungrokkable to me, but after reading the code I think
you are teaching the normal codepath where removal of working tree
is done to match what is done to the index that submodules are also
in the working tree and need to be removed when the corresopnding ce
is
On Thu, Feb 16, 2017 at 11:43:59AM -0500, Jeff King wrote:
> On Thu, Feb 16, 2017 at 11:10:18AM +0100, Andreas Schwab wrote:
>
> > >> int xfclose(FILE *fp)
> > >> {
> > >> return ferror(fp) | fclose(fp);
> > >> }
> > >
> > > Yes, that's exactly what I had in mind (might be worth calli
On Thu, Feb 16, 2017 at 11:49 AM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Jacob Keller writes:
>>
>>> The interdiff between v2 and v3 is not really worth showing since I
>>> basically re-wrote the entire section a bit.
>>
>> Could this be made into an incremental, now that v2 has bee
Stefan Beller writes:
>> The above does somewhat more than advertised and was a bit hard to
>> grok. Initially I thought the reason why pathdup()s were delayed
>> was perhaps because you pathdup() something potentially different
>> from the given parameter to the function (i.e. new code before
>
Stefan Beller writes:
> +
> + /* ERROR_WOULD_LOSE_UNTRACKED_SUBMODULE */
> + "Submodule '%s' cannot be deleted as it contains untracked files.",
OK.
> + msgs[ERROR_WOULD_LOSE_UNTRACKED_SUBMODULE] =
> + _("Submodule '%s' cannot be deleted as it contains untracked
> files
Stefan Beller writes:
> The check (which uses the old oid) is yet to be implemented, but this part
> is just a refactor, so it can go separately first.
If this didn't pass an unused parameter, then the change is just a
refactor, and I do think such a "just a refactor" can be a good step
on its o
On Thu, Feb 16, 2017 at 12:54 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> In a later patch we'll use connect_work_tree_and_git_dir when the
>> directory for the gitlink file doesn't exist yet. Safely create
>> the directory first.
>>
>> One of the two users of 'connect_work_tree_and_gi
Stefan Beller writes:
[administrivia: I've been seeing "unlisted-recipients:; (no To-header on input)"
for all of your recent patches. Can it be corrected on your end, please?]
> In later patches we introduce the options and flag for commands
> that modify the working directory, e.g. git-checko
Stefan Beller writes:
> In later patches we introduce the --recurse-submodule flag for commands
> that modify the working directory, e.g. git-checkout.
>
> It is potentially expensive to check if a submodule needs an update,
> because a common theme to interact with submodules is to spawn a child
On 16 February 2017 at 19:02, Jeff King wrote:
> Try the "Quoted Text" section of the original asciidoc user manual:
>
> http://www.methods.co.nz/asciidoc/userguide.html#X51
>
> Asciidoctor has introduced some new syntax (almost certainly because the
> original asymmetric formulations have a bun
Stefan Beller writes:
> In a later patch we'll use connect_work_tree_and_git_dir when the
> directory for the gitlink file doesn't exist yet. Safely create
> the directory first.
>
> One of the two users of 'connect_work_tree_and_git_dir' already checked
> for the directory being there, so we can
Stefan Beller writes:
> Currently lib-submodule-update.sh provides 2 functions
> test_submodule_switch and test_submodule_forced_switch that are used by a
> variety of tests to ensure that submodules behave as expected. The current
> expected behavior is that submodules are not touched at all (se
Junio C Hamano writes:
> Jacob Keller writes:
>
>> The interdiff between v2 and v3 is not really worth showing since I
>> basically re-wrote the entire section a bit.
>
> Could this be made into an incremental, now that v2 has been in
> 'next' for about 10 days, please?
Nah, I think it is easie
Hey Junio and Matthieu,
On 17 February 2017 at 00:19, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Siddharth Kannan writes:
>>
>>> This is as per our discussion[1]. The patches and commit messages are based
>>> on
>>> Junio's patches that were posted as a reply to
>>> <20170212184132.1237
Hey Matthieu,
On 16 February 2017 at 23:52, Matthieu Moy wrote:
>
> Indeed, I misread the patch. The explanation could be a little bit more
> "tired-reviewer-proof" by not using a past tone, perhaps
>
> 1. setup_revision, which is changed to ...
Oh, okay! Sorry about the confusion!
Yes, I used
Stefan Beller writes:
> On Wed, Feb 15, 2017 at 9:05 PM, David Pursehouse
> wrote:
>> From: David Pursehouse
>>
>> Add missing `::` after the title.
>>
>> Signed-off-by: David Pursehouse
>
> Thanks!
> Stefan
Thanks, both.
Jacob Keller writes:
> The interdiff between v2 and v3 is not really worth showing since I
> basically re-wrote the entire section a bit.
Could this be made into an incremental, now that v2 has been in
'next' for about 10 days, please?
> +Split a commit apart into a sequence of commits::
> ++
>
Siddharth Kannan writes:
> Instead of replacing the whole string, we would expand it accordingly using:
>
> if (*name == '-') {
> if (len == 1) {
> name = "@{-1}";
> len = 5;
> } else {
> struct strbuf changed_argument = STRBUF_INIT;
>
> strbuf_addstr(&changed_argument, "@{-1}
On Thu, Feb 16, 2017 at 06:41:26PM +, Fabrizio Cucci wrote:
> On 15 February 2017 at 21:56, Jeff King wrote:
> > Grep for "``" in Git's documentation directory, and you will see many
> > examples (asciidoc only accepts the double-quote form, not singles).
> >
> > You can also try:
> >
> > e
Matthieu Moy writes:
> Siddharth Kannan writes:
>
>> This is as per our discussion[1]. The patches and commit messages are based
>> on
>> Junio's patches that were posted as a reply to
>> <20170212184132.12375-1-gits...@pobox.com>.
>>
>> As per Matthieu's comments, I have updated the tests, but
Jonathan Tan writes:
> On 02/15/2017 03:11 PM, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> Perhaps something like this?
>
> This looks good. I was hoping to unify the processing logic between
> this CLI parsing and the usual stream parsing, but this approach is
> probably simpler.
I l
On Wed, Feb 15, 2017 at 9:05 PM, David Pursehouse
wrote:
> From: David Pursehouse
>
> Add missing `::` after the title.
>
> Signed-off-by: David Pursehouse
Thanks!
Stefan
On 15 February 2017 at 21:56, Jeff King wrote:
> Grep for "``" in Git's documentation directory, and you will see many
> examples (asciidoc only accepts the double-quote form, not singles).
>
> You can also try:
>
> echo "this is \`\`quoted'' text" >foo.txt
> asciidoc foo.txt
>
> and then open
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Siddharth Kannan writes:
>>
>>> handle_revision_opt() tries to recognize and handle the given argument. If
>>> an
>>> option was unknown to it, it used to add the option to unkv[(*unkc)++].
>>> This
>>> increment of unkc causes the variable
Johan Hovold writes:
> Hi,
>
> I recently noticed that after an upgrade, git-send-email (2.10.2)
> started aborting when trying to send patches that had a linux-kernel
> stable-tag in its body. For example,
>
> Cc: # 4.4
>
> was now parsed as
>
> "sta...@vger.kernel.org#4.4"
>
> w
On Thu, Feb 16, 2017 at 09:59:25AM -0800, Junio C Hamano wrote:
> Johan Hovold writes:
>
> > I recently noticed that after an upgrade, git-send-email (2.10.2)
> > started aborting when trying to send patches that had a linux-kernel
> > stable-tag in its body. For example,
> >
> > Cc: # 4.
Am 13.02.2017 um 18:16 schrieb Johannes Schindelin:
On Sat, 11 Feb 2017, Johannes Sixt wrote:
Am 10.02.2017 um 00:41 schrieb Junio C Hamano:
Johannes Schindelin writes:
From: Jeff Hostetler
Use OpenSSL's SHA-1 routines rather than builtin block-sha1
routines. This improves performance on
Matthieu Moy writes:
> Siddharth Kannan writes:
>
>> handle_revision_opt() tries to recognize and handle the given argument. If an
>> option was unknown to it, it used to add the option to unkv[(*unkc)++]. This
>> increment of unkc causes the variable in the caller to change.
>>
>> Teach handle
Johannes Sixt writes:
> Am 16.02.2017 um 18:10 schrieb Johannes Schindelin:
>> On Wed, 15 Feb 2017, Johannes Sixt wrote:
>>> I do not see how dup2() causes a change in stdio state. I
>>> must be missing something (and that may be a basic misunderstanding of how
>>> stdio is initialized).
>>
>> It
On 02/15, Stefan Beller wrote:
> +static void reload_gitmodules_file(struct index_state *index,
> +struct checkout *state)
> +{
> + int i;
> + for (i = 0; i < index->cache_nr; i++) {
> + struct cache_entry *ce = index->cache[i];
> + if
Johan Hovold writes:
> I recently noticed that after an upgrade, git-send-email (2.10.2)
> started aborting when trying to send patches that had a linux-kernel
> stable-tag in its body. For example,
>
> Cc: # 4.4
>
> was now parsed as
>
> "sta...@vger.kernel.org#4.4"
> ...
It sou
Am 16.02.2017 um 18:10 schrieb Johannes Schindelin:
On Wed, 15 Feb 2017, Johannes Sixt wrote:
I do not see how dup2() causes a change in stdio state. I
must be missing something (and that may be a basic misunderstanding of how
stdio is initialized).
It appears that dup2()ing fd 2 resets that s
Hi,
I recently noticed that after an upgrade, git-send-email (2.10.2)
started aborting when trying to send patches that had a linux-kernel
stable-tag in its body. For example,
Cc: # 4.4
was now parsed as
"sta...@vger.kernel.org#4.4"
which resulted in
Died at /usr/l
On Thu, Feb 16, 2017 at 02:28:26PM +0300, Maxim Moseychuk wrote:
> In some places static size buffers can't store formatted string.
> If it be happen then git die.
>
> Maxim Moseychuk (3):
> add git_psprintf helper function
> bisect_next_all: convert xsnprintf to git_psprintf
> stop_progres
On Thu, Feb 16, 2017 at 02:28:29PM +0300, Maxim Moseychuk wrote:
> Replace local safe string buffer allocation by git_psprintf.
Hmm. Is this one actually broken in practice?
I see:
> @@ -243,21 +243,18 @@ void stop_progress_msg(struct progress **p_progress,
> const char *msg)
> *p_progre
On Thu, Feb 16, 2017 at 02:28:28PM +0300, Maxim Moseychuk wrote:
> Git can't run bisect between 2048+ commits if use russian translation.
> Reproduce "LANG=ru_RU.UTF8 git bisect start v4.9 v4.8" on linux sources.
>
> Dummy solution: just increase buffer size but is not safe.
> Size gettext string
René Scharfe writes:
> Am 14.02.2017 um 23:59 schrieb Junio C Hamano:
>> * rs/ls-files-partial-optim (2017-02-13) 2 commits
>> - ls-files: move only kept cache entries in prune_cache()
>> - ls-files: pass prefix length explicitly to prune_cache()
>>
>> "ls-files" run with pathspec has been mic
Hi Hannes,
On Wed, 15 Feb 2017, Johannes Sixt wrote:
> Am 15.02.2017 um 13:32 schrieb Johannes Schindelin:
> > On Tue, 14 Feb 2017, Johannes Sixt wrote:
> > > Am 14.02.2017 um 15:47 schrieb Johannes Schindelin:
> > > > On Mon, 13 Feb 2017, Junio C Hamano wrote:
> > > > > Johannes Schindelin writ
In some places static size buffers can't store formatted string.
If it be happen then git die.
Jonathan Tan: Thanks a lot for your help.
Maxim Moseychuk (2):
bisect_next_all: convert xsnprintf to xstrfmt
stop_progress_msg: convert xsnprintf to xstrfmt
bisect.c | 9 +
progress.c |
Git can't run bisect between 2048+ commits if use russian translation.
Reproduce "LANG=ru_RU.UTF8 git bisect start v4.9 v4.8" on linux sources.
Dummy solution: just increase buffer size but is not safe.
Size gettext string is a runtime value.
Signed-off-by: Maxim Moseychuk
---
bisect.c | 9
Replace local safe string buffer allocation by xstrfmt.
Signed-off-by: Maxim Moseychuk
---
progress.c | 9 +++--
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/progress.c b/progress.c
index 76a88c573..29d0dad58 100644
--- a/progress.c
+++ b/progress.c
@@ -243,21 +243,18 @@ voi
On Thu, Feb 16, 2017 at 07:51:14AM -0800, Jonathan Tan wrote:
> On 02/16/2017 03:28 AM, Maxim Moseychuk wrote:
> > There are a number of places in the code where we call
> > xsnprintf(), with the assumption that the output will fit into
> > the buffer. If the buffer is small, then git die.
> > In
Lars Schneider writes:
>> On 16 Feb 2017, at 00:48, Junio C Hamano wrote:
>>
>> The "git -c = cmd" mechanism is to pretend that a
>
> The problem is also present for gitconfig variables e.g.
> git config --local submodule.UPPERSUB.update none
Yuck.
> But your patch below fixes that, too!
Heh
Siddharth Kannan writes:
> handle_revision_opt() tries to recognize and handle the given argument. If an
> option was unknown to it, it used to add the option to unkv[(*unkc)++]. This
> increment of unkc causes the variable in the caller to change.
>
> Teach handle_revision_opt to not update unk
On Thu, Feb 16, 2017 at 11:10:18AM +0100, Andreas Schwab wrote:
> >>int xfclose(FILE *fp)
> >>{
> >>return ferror(fp) | fclose(fp);
> >>}
> >
> > Yes, that's exactly what I had in mind (might be worth calling out the
> > bitwise-OR, though, just to make it clear it's not a
Siddharth Kannan writes:
> This is as per our discussion[1]. The patches and commit messages are based on
> Junio's patches that were posted as a reply to
> <20170212184132.12375-1-gits...@pobox.com>.
>
> As per Matthieu's comments, I have updated the tests, but there is still one
> thing that is
On 02/16/2017 03:28 AM, Maxim Moseychuk wrote:
There are a number of places in the code where we call
xsnprintf(), with the assumption that the output will fit into
the buffer. If the buffer is small, then git die.
In many places buffers have compile-time size, but generated string
depends from c
This is as per our discussion[1]. The patches and commit messages are based on
Junio's patches that were posted as a reply to
<20170212184132.12375-1-gits...@pobox.com>.
As per Matthieu's comments, I have updated the tests, but there is still one
thing that is not working: log -@{yesterday} or log
handle_revision_opt() tries to recognize and handle the given argument. If an
option was unknown to it, it used to add the option to unkv[(*unkc)++]. This
increment of unkc causes the variable in the caller to change.
Teach handle_revision_opt to not update unknown arguments inside unkc anymore.
setup_revisions used to consider any argument starting with "-" to be either a
valid or an unknown option.
Teach setup_revisions to check if an argument is a revision before adding it as
an unknown option (something that setup_revisions didn't understand) to argv,
and moving on to the next argumen
This patch introduces "-" as a method to refer to a revision, and adds tests to
test that git-log works with this shorthand.
This change will touch the following commands (through
revision.c:setup_revisions):
* builtin/blame.c
* builtin/diff.c
* builtin/diff-files.c
* builtin/diff-index.c
* built
Swap the condition and bodies of an "if (A) do_A else do_B" in
setup_revisions() to "if (!A) do_B else do_A", to make the change in
the the next step easier to read.
No behaviour change is intended in this step.
Signed-off-by: Siddharth Kannan
---
revision.c | 6 +++---
1 file changed, 3 insert
On Wed, Feb 15, 2017 at 10:40 PM, Jeff King wrote:
> On Tue, Feb 14, 2017 at 10:29:46PM +0100, Christian Couder wrote:
>
>> > I notice Christian's patch added a few tests. I don't know if we'd want
>> > to squash them in (I didn't mean to override his patch at all; I was
>> > about to send mine ou
70999e9cec (branch -m: update all per-worktree HEADs - 2016-03-27)
added this function in order to update HEADs of all relevant
worktrees, when a branch is renamed.
It, as a public ref api, kind of breaks abstraction when it uses
internal functions of files backend. With the introduction of
refs_c
files-backend at this point is still aware of the per-repo/worktree
separation in refs, so it can handle a linked worktree.
Note: accessing a worktree of a submodule remains unaddressed. Perhaps
after get_worktrees() can access submodule (or rather a new function
get_submodule_worktrees(), that li
The manual parsing code is replaced with a call to refs_resolve_ref_unsafe().
The manual parsing code must die because only refs/files-backend.c
should do that.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
branch.c | 3 +-
worktree.c | 102 -
Surprise surprise. This is just rename and introduce
resolve_ref_recursively() to the public.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 9 +
refs.h | 6 ++
refs/files-backend.c | 2 +-
refs/refs-internal.h | 5 -
4 files changed, 12 insertions(+
v2 still kills parse_ref(), but the series now depends on my other
series [1] and as a result does not make any confusing "submodule"
calls any more.
It also kills another function, introduced for multi-worktree, that
should not have been there to begin with. Good riddance.
Again, the naming conv
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 22 +-
refs.h | 4
2 files changed, 21 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index e0e191107..23e0a8eda 100644
--- a/refs.c
+++ b/refs.c
@@ -1535,13 +1535,25 @@ int peel_ref(const char *refname, unsig
Since submodule or not is irrelevant to files-backend after the last
patch, remove the parameter from files_downcast() and kill
files_assert_main_repository().
PS. This implies that all ref operations are allowed for submodules. But
we may need to look more closely to see if that's really true...
files-backend is now initialized with a $GIT_DIR. Converting a submodule
path to where real submodule gitdir is located is done in get_ref_store().
The new code in init_submodule_ref_store() is basically a copy of
strbuf_git_path_submodule().
This gives a slight performance improvement for submod
This function is intended to replace *_submodule() refs API. It provides
a ref store for a specific submodule, which can be operated on by a new
set of refs API.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 12
refs.h | 11 +++
refs/files-back
get_ref_store() will soon be renamed to get_submodule_ref_store().
Together with future get_worktree_ref_store(), the three functions
provide an appropriate ref store for different operation modes. New APIs
will be added to operate directly on ref stores.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs is learning to avoid path rewriting that is done by
strbuf_git_path_submodule(). Factor out this code so it could be reused
by refs*
Signed-off-by: Nguyễn Thái Ngọc Duy
---
path.c | 34 +++---
submodule.c | 31 +++
submodule.h |
This is the last function in this code (besides public API) that takes
submodule argument and handles both main/submodule cases. Break it down,
move main store registration in get_main_ref_store() and keep the rest
in register_submodule_ref_store().
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index 7a474198e..10994d992 100644
--- a/refs.c
+++ b/refs.c
@@ -1445,15 +1445,23 @@ static struct ref_store *ref_store_init(const char
*submodule)
With get_main_ref_store() being used inside get_ref_store(),
lookup_ref_store() is only used for submodule code path. Rename to
reflect that and delete dead code.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/refs
This helps the future changes in this code. And because get_ref_store()
is destined to become get_submodule_ref_store(), the "get main store"
code path will be removed eventually. After this the patch to delete
that code will be cleaner.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
refs.c | 19 ++
Given $GIT_DIR and $GIT_COMMON_DIR, files-backend is now in charge of
deciding what goes where. The end goal is to pass $GIT_DIR only. A
refs "view" of a linked worktree is a logical ref store that combines
two files backends together.
(*) Not entirely true since strbuf_git_path_submodule() still
1 - 100 of 113 matches
Mail list logo