Junio C Hamano writes:
>> - If our submodule is bound at path sub/dir in the superproject,
>>the relative-path thing above would get "dir" and this ls-tree
>>ends up asking what is at "dir", but the question you really want
>>to ask is what is at "sub/dir", isn't
Junio C Hamano writes:
>> +dirname = relative_path(xgetcwd(), one_up, );
>
> So, the idea is we start at the root level of the current project's
> working tree, and we go up one level, then we know the last component
> of the path our submodule is bound at in the
Stefan Beller writes:
> diff --git a/submodule.c b/submodule.c
> index 3b98766a6b..a63aef2c6b 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -1514,3 +1514,90 @@ void absorb_git_dir_into_superproject(const char
> *prefix,
> strbuf_release();
> }
> }
Signed-off-by: Stefan Beller
---
Marking this as RFC as documentation and tests are missing.
builtin/rev-parse.c | 7 +
submodule.c | 87 +
submodule.h | 8 +
3 files changed, 102 insertions(+)
previous work:
https://public-inbox.org/git/20170302004759.27852-1-sbel...@google.com
https://public-inbox.org/git/20161203003022.29797-1-sbel...@google.com/
v7:
* addressed Erics comment by fixing the bashism in t/lib-submodule-update.sh
diff to v6:
diff --git a/t/lib-submodule-update.sh
In later patches we introduce the options and flag for commands
that modify the working directory, e.g. git-checkout.
Have a central place to store such settings whether we want to update
a submodule.
Signed-off-by: Stefan Beller
---
submodule.c | 6 ++
submodule.h | 1
On Tue, Jan 31, 2017 at 1:41 PM, Jeff King wrote:
> On Mon, Jan 30, 2017 at 08:28:30PM -0600, Edmundo Carmona Antoranz wrote:
>
>> +static void pretty_info(char* revid, struct blame_entry *ent, struct strbuf
>> *rev_buffer)
>> +{
>> + struct pretty_print_context ctx = {0};
>>
On Mon, Mar 6, 2017 at 4:08 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> "tag -s" also has the benefit of being retroactive. You can create
>>> commit, think about it for a week and then later tag it. And ask
>>> others to also tag the same
Junio C Hamano writes:
> Stefan Beller writes:
>
>> What is the difference between signed commits and tags?
>> (Not from a technical perspective, but for the end user)
> ...
>> A signed push can certify that a given payload (consisting
>> of multiple
We need the gentle version in a later patch. As we have just one caller,
migrate the caller.
Signed-off-by: Stefan Beller
---
builtin/grep.c | 2 +-
submodule.c| 7 ++-
submodule.h| 8 +++-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git
Being late to the review party here.
> +static int include_condition_is_true(const char *cond, size_t cond_len)
> +{
...
> +
> + error(_("unrecognized include condition: %.*s"), (int)cond_len, cond);
> + /* unknown conditionals are always false */
> + return 0;
> +}
Thanks for
Jakub Narębski writes:
> Also from what I remember signed commits came before mergetags, that
> is the result of merging a signed tag (storing the signature of
> one of parents of the merge commit to not pollute tag namespace).
>
> And this workflow, from what I know, is quite
On Mon, Mar 06, 2017 at 03:40:30PM -0800, Jonathan Nieder wrote:
> David Lang wrote:
>
> >> Translation table
> >> ~
> >> A fast bidirectional mapping between sha1-names and sha256-names of
> >> all local objects in the repository is kept on disk. The exact format
> >> of that
Linus Torvalds wrote:
> On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder wrote:
>> This document is still in flux but I thought it best to send it out
>> early to start getting feedback.
>
> This actually looks very reasonable if you can implement it cleanly
> enough.
Thanks
Stefan Beller writes:
>> "tag -s" also has the benefit of being retroactive. You can create
>> commit, think about it for a week and then later tag it. And ask
>> others to also tag the same one. You cannot do so with "commit -s".
>
> ok, so there is *no* advantage of
W dniu 06.03.2017 o 23:13, Junio C Hamano pisze:
> Stefan Beller writes:
>
>> What is the difference between signed commits and tags?
>> (Not from a technical perspective, but for the end user)
[...]
>> Off list I was told gpg-signed commits are a "checkbox feature",
>> i.e.
David Lang wrote:
>> Translation table
>> ~
>> A fast bidirectional mapping between sha1-names and sha256-names of
>> all local objects in the repository is kept on disk. The exact format
>> of that mapping is to be determined.
>>
>> All operations that make new objects (e.g.,
When using the --recurse-submodules flag with a relative pathspec which
includes "..", an error is produced inside the child process spawned for
a submodule. When creating the pathspec struct in the child, the ".."
is interpreted to mean "go up a directory" which causes an error stating
that the
On Mon, Mar 6, 2017 at 2:13 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> What is the difference between signed commits and tags?
>> (Not from a technical perspective, but for the end user)
>
> When you "commit -s", you are signing the bytes in the
Hi Junio,
Thanks for taking the time to reply. I apologize if there was a
misunderstanding in my previous email; I'm relatively new to dealing with some
of the more advanced features of git, and did not describe my situation as
clearly as possible.
I am using the pre-receive hook to determine
On Wed, Mar 1, 2017 at 6:11 PM, Eric Wong wrote:
> Stefan Beller wrote:
>> test_submodule_content () {
>> + if test "$1" == "-C"
>
> Use a single '=' for portability in sh. It's also a good idea
> to prefix variables with 'x' or some such, since "$1"
Lars Schneider writes:
>> On 04 Mar 2017, at 00:26, Junio C Hamano wrote:
>>
>>
>> * ls/filter-process-delayed (2017-01-08) 1 commit
>> . convert: add "status=delayed" to filter process protocol
>>
>> Ejected, as does not build when merged to
Stefan Beller writes:
> Signed-off-by: Stefan Beller
> ---
> t/lib-submodule-update.sh | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
> index c0d6325133..00128f28b5 100755
> ---
Stefan Beller writes:
> What is the difference between signed commits and tags?
> (Not from a technical perspective, but for the end user)
When you "commit -s", you are signing the bytes in the commit
object, which means that you are attesting the fact that the tree
you
Similar to b33a15b08 (push: add recurseSubmodules config option,
2015-11-17) and 027771fcb1 (submodule: allow erroneous values for the
fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code
that is later used to parse whether we are interested in updating
submodules.
We need the
Linus Torvalds writes:
> So *if* the new object format uses a git header line like
>
> "blob \0"
>
> then it would inherently contain that mapping from 256-bit hash to the
> SHA1, but it would actually also protect against attacks on the new
> hash.
This is
Mike Lewis writes:
> I’m having some issues with using server-side hooks when pushing
> to a non-bare repository. In my git config, I have
> `receive.denyCurrentBranch` set to `updateInstead`, which behaves
> as expected, and updates the current working tree when the current
>
A new known failure mode is introduced[1], which is actually not
a failure but a feature in read-tree. Unlike checkout for which
the recursive submodule tests were originally written, read-tree does
warn about ignored untracked files that would be overwritten.
For the sake of keeping the test
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 (see
42639d2317a for the exact
Signed-off-by: Stefan Beller
---
unpack-trees.c | 131 +
unpack-trees.h | 1 +
2 files changed, 123 insertions(+), 9 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 616a0ae4b2..8333da2cc9 100644
---
Cleaning up code by generalising it.
Currently the mailing list discusses yet again how
to migrate away from sha1.
Signed-off-by: Stefan Beller
---
t/lib-submodule-update.sh | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/t/lib-submodule-update.sh
In a later patch we need to prepare the submodule environment with
another git directory, so split up the function.
Also move it up in the file such that we do not need to declare the
function later before using it.
Signed-off-by: Stefan Beller
---
submodule.c | 29
Signed-off-by: Stefan Beller
---
entry.c | 30 ++
1 file changed, 30 insertions(+)
diff --git a/entry.c b/entry.c
index c6eea240b6..d2b512da90 100644
--- a/entry.c
+++ b/entry.c
@@ -2,6 +2,7 @@
#include "blob.h"
#include "dir.h"
#include
In later patches we introduce the options and flag for commands
that modify the working directory, e.g. git-checkout.
This piece of code will be used universally for
all these working tree modifications as it
* supports dry run to answer the question:
"Is it safe to change the submodule to this
Signed-off-by: Stefan Beller
---
read-cache.c | 27 +--
1 file changed, 25 insertions(+), 2 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index 9054369dd0..9a2abacf7a 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -18,6 +18,8 @@
#include
Adding the repository itself as a submodule does not make sense in the
real world. In our test suite we used to do that out of convenience in
some tests as the current repository has easiest access for setting up
'just a submodule'.
However this doesn't quite test the real world, so let's do not
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.
Signed-off-by: Stefan Beller
---
unpack-trees.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/unpack-trees.c
This exposes a flag to recurse into submodules
in builtin/checkout making use of the code implemented
in prior patches.
A new failure mode is introduced in the submodule
update library, as the directory/submodule conflict
is not solved in prior patches.
Signed-off-by: Stefan Beller
Redraw the ASCII art describing the setup using more space, such that
it is easier to understand. The leaf commits are now ordered the same
way the actual code is ordered.
Add empty lines to the setup code separating each of the leaf commits,
each starting with a "checkout -b".
Signed-off-by:
In a later patch we'll use connect_work_tree_and_git_dir when the
directory for the gitlink file doesn't exist yet. This patch makes
connect_work_tree_and_git_dir safe to use for both cases of
either the git dir or the working dir missing.
To do so, we need to call
Signed-off-by: Stefan Beller
---
t/lib-submodule-update.sh | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
index c0d6325133..00128f28b5 100755
--- a/t/lib-submodule-update.sh
+++ b/t/lib-submodule-update.sh
@@
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
process for each interaction.
On Mon, Mar 6, 2017 at 12:30 PM, Stefan Beller wrote:
>
> as well as another fix in git-submodule.sh
>
I spoke too early, that seems like a false positive.
"Philip Oakley" writes:
> The study of human error is quite interesting
Yes ;-)
Christian Couder writes:
> I think I just copy pasted the code from cmd_rev_list() in
> builtin-rev-list.c and probably didn't realize that revs->tree_objects
> would always be false.
>
> Thanks for spotting this and removing the dead code.
Thanks for a quick
On Mon, Mar 6, 2017 at 11:16 AM, Jonathan Tan wrote:
> [1] <20170113155253.1644-1-benpe...@microsoft.com> (you can search for
> emails by Message ID in online archives like https://public-inbox.org/git if
> you don't already have them)
Not just search, but the
On 03/06, Linus Torvalds wrote:
> On Mon, Mar 6, 2017 at 10:39 AM, Jonathan Tan
> wrote:
> >
> > I think "nohash" can be explained in 2 points:
>
> I do think that that was my least favorite part of the suggestion. Not
> just "nohash", but all the special "hash" lines
When discussing migrating to a new hashing function, I tried to learn
about the subtleties of the different things that can be gpg-signed in
Git.
What is the difference between signed commits and tags?
(Not from a technical perspective, but for the end user)
Both of them certify that a given
Mark Thomas writes:
> This is a proof-of-concept, so it is in no way complete. It contains a
> few hacks to make it work, but these can be ironed out with a bit more
> work. What I have so far is sufficient to try out the idea.
Two things that immediately come to mind
On 03/04/2017 11:18 AM, Mark Thomas wrote:
I was inspired a bit by Microsoft's announcement of their Git VFS. I
saw that people have talked in the past about making git fetch objects
from remotes as they are needed, and decided to give it a try.
For reference, one such conversation is [1].
On Mon, Mar 6, 2017 at 10:39 AM, Jonathan Tan wrote:
>
> I think "nohash" can be explained in 2 points:
I do think that that was my least favorite part of the suggestion. Not
just "nohash", but all the special "hash" lines too.
I would honestly hope that the design
Lars Schneider writes:
> when I looked into the 32-bit/line-log issue [1], I realized that my
> proposed docker setup is not ideal for local debugging. Here is an
> approach that I think is better. I changed the following:
> - disable sudo as it is not required for
On 03/01, Stefan Beller wrote:
Sorry I've been slow at rerolling this. I'll send out a reroll today.
> IIRC most of the series is actually refactoring, i.e.
> providing a central function that answers
> "is this submodule active/initialized?" and then making use of this
> function.
>
> Maybe
On 03/06/2017 12:43 AM, Jeff King wrote:
Overall the basics of the conversion seem sound to me. The "nohash"
things seems more complicated than I think it ought to be, which
probably just means I'm missing something. I left a few related
comments on the google doc, so I won't repeat them here.
Jeff King writes:
>> You can use the doc URL
>>
>> https://goo.gl/gh2Mzc
>
> I'd encourage anybody following along to follow that link. I almost
> didn't, but there are a ton of comments there (I'm not sure how I feel
> about splitting the discussion off the list, though).
I am
On 03/06, brian m. carlson wrote:
> On Sat, Mar 04, 2017 at 06:35:38PM -0800, Linus Torvalds wrote:
> > On Fri, Mar 3, 2017 at 5:12 PM, Jonathan Nieder wrote:
> > >
> > > This document is still in flux but I thought it best to send it out
> > > early to start getting feedback.
On 03/04, Jeff King wrote:
> On Sat, Mar 04, 2017 at 08:36:45AM +, Eric Wong wrote:
>
> > I also think the security implications for relative alternates
> > on the same host would not matter, since the smart HTTP will
> > take them into account on the server side.
>
> It depends on the host
On Sat, Mar 4, 2017 at 6:15 AM, Valery Tolstov wrote:
> Looking for microproject ideas for GSoC.
> Would this issue be suitable as the microproject?
It would be a good project, but not as 'micro' I would assume. ;)
Why it is not a micro project:
To fix this issue we'd want to
OS: FreeBSD 10.3-STABLE
Story:
I was trying to install openproject using this manual
https://www.openproject.org/open-source/download/manual-installation-guide/
Everything was fine till command
$ bundle install --deployment --without postgres sqlite development test
therubyracer docker
works
On Mon, Mar 06, 2017 at 09:38:33AM -0600, Christian7573 wrote:
> Is there a way for git to push to a server using the dumb protocol?
> Perhaps using the PUT method to upload files?
> Just wondering cause I just set up a dumb server and pushing to it
> doesn't work.
Git dumb-http push protocol
Is there a way for git to push to a server using the dumb protocol?
Perhaps using the PUT method to upload files?
Just wondering cause I just set up a dumb server and pushing to it
doesn't work. If that isn't an option, where can I get a smart server?
On 3/5/2017 19:14, Linus Torvalds wrote:
On Sat, Mar 4, 2017 at 12:27 AM, Marius Storm-Olsen wrote:
I guess you could do the printout a bit earlier (on the
"to_pack.objects[]" array - to_pack.nr_objects is the count there).
That should show all of them. But the small objects
On Fri, Mar 3, 2017 at 11:43 PM, Michael Haggerty wrote:
> It's notable that these tests grep around the filesystem, so they won't
> be applicable to future refs backends. Of course, "pack-refs" is
> intrinsically only applicable to the files backend, so for this test
> it's
This new function will be used in a following commit to know
if we want to use the split index feature or not.
Signed-off-by: Christian Couder
---
cache.h | 1 +
config.c | 10 ++
2 files changed, 11 insertions(+)
diff --git a/cache.h b/cache.h
index
Signed-off-by: Christian Couder
---
config.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/config.c b/config.c
index c6b874a7bf..2ac1aa19b0 100644
--- a/config.c
+++ b/config.c
@@ -1728,8 +1728,8 @@ int git_config_get_untracked_cache(void)
Goal
We want to make it possible to use the split-index feature
automatically by just setting a new "core.splitIndex" configuration
variable to true.
This can be valuable as split-index can help significantly speed up
`git rebase` especially along with the work to libify `git apply`
that
This will make us use the split-index feature or not depending
on the value of the "core.splitIndex" config variable.
Signed-off-by: Christian Couder
---
read-cache.c | 17 +
1 file changed, 17 insertions(+)
diff --git a/read-cache.c b/read-cache.c
Signed-off-by: Christian Couder
---
t/t1700-split-index.sh | 72 ++
1 file changed, 72 insertions(+)
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index 9d7c01c3e1..00a64bed97 100755
---
This function will be used in a following commit to get the expiration
time of the shared index files from the config, and it is generic
enough to be put in "config.c".
Signed-off-by: Christian Couder
---
builtin/gc.c | 18 +++---
cache.h | 3 +++
Signed-off-by: Christian Couder
---
t/t1700-split-index.sh | 37 +
1 file changed, 37 insertions(+)
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index 5ea227e6a1..aa2aff1778 100755
--- a/t/t1700-split-index.sh
+++
Signed-off-by: Christian Couder
---
Documentation/config.txt | 4
1 file changed, 4 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 47603f5484..f102879261 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@
Signed-off-by: Christian Couder
---
Documentation/config.txt | 12
1 file changed, 12 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index b64aa7db2d..2afd5d982b 100644
--- a/Documentation/config.txt
+++
This improves test indentation by getting rid of the outdated
here document style.
Signed-off-by: Christian Couder
---
t/t1700-split-index.sh | 170 -
1 file changed, 85 insertions(+), 85 deletions(-)
diff --git
Also use the functions in cmd_update_index() in
builtin/update-index.c.
These functions will be used in a following commit to tweak
our use of the split-index feature depending on the setting
of a configuration variable.
Signed-off-by: Christian Couder
---
When a split-index file is created, let's update the mtime of the
shared index file that the split-index file is referencing.
In a following commit we will make shared index file expire
depending on their mtime, so updating the mtime makes sure that
the shared index file will not be deleted soon.
When users are using `git update-index --(no-)split-index`, they
may expect the split-index feature to be used or not according to
the option they just used, but this might not be the case if the
new "core.splitIndex" config variable has been set. In this case
let's warn about what will happen and
Signed-off-by: Christian Couder
---
t/t1700-split-index.sh | 44
1 file changed, 44 insertions(+)
diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh
index 00a64bed97..f5a95a6c28 100755
--- a/t/t1700-split-index.sh
This way a share index file will not be garbage collected if
we still read from an index it is based from.
As we need to read the current index before creating a new
one, the tests have to be adjusted, so that we don't expect
an old shared index file to be deleted right away when we
create a new
It looks better and is simpler to review when we don't compute
the same things many times in the function.
It will also help make the following commit simpler.
Signed-off-by: Christian Couder
---
read-cache.c | 14 --
1 file changed, 8 insertions(+), 6
This new function will be used in a following commit to get the
value of the "splitIndex.maxPercentChange" config variable.
Signed-off-by: Christian Couder
---
cache.h | 1 +
config.c | 15 +++
2 files changed, 16 insertions(+)
diff --git a/cache.h
Signed-off-by: Christian Couder
---
Documentation/config.txt | 13 +
1 file changed, 13 insertions(+)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index f102879261..b64aa7db2d 100644
--- a/Documentation/config.txt
+++
Signed-off-by: Christian Couder
---
Documentation/git-update-index.txt | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/git-update-index.txt
b/Documentation/git-update-index.txt
index 7386c93162..e091b2a409 100644
---
Everytime split index is turned on, it creates a "sharedindex."
file in the git directory. This change makes sure that shared index
files that haven't been used for a long time are removed when a new
shared index file is created.
The new "splitIndex.sharedIndexExpire" config variable is
Signed-off-by: Christian Couder
---
Documentation/config.txt | 2 +-
Documentation/git-update-index.txt | 37 +
2 files changed, 30 insertions(+), 9 deletions(-)
diff --git a/Documentation/config.txt
This function will be used in a commit soon, so let's make
it available globally.
Signed-off-by: Christian Couder
---
cache.h | 3 +++
sha1_file.c | 2 +-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/cache.h b/cache.h
index 0bb9adcd31..a35e9d5187
When writing a new split-index and there is a big number of cache
entries in the split-index compared to the shared index, it is a
good idea to regenerate the shared index.
By default when the ratio reaches 20%, we will push back all
the entries from the split-index into a new shared index file
On Mon, Mar 06, 2017 at 10:29:33AM +0100, ankostis wrote:
> On 5 March 2017 at 12:02, David Lang wrote:
> >> Translation table
> >> ~
> >> A fast bidirectional mapping between sha1-names and sha256-names of
> >> all local objects in the repository is kept on disk.
On Fri, Mar 03, 2017 at 05:12:51PM -0800, Jonathan Nieder wrote:
> This past week we came up with this idea for what a transition to a new
> hash function for Git would look like. I'd be interested in your
> thoughts (especially if you can make them as comments on the document,
> which makes it
88 matches
Mail list logo