Stefan Beller writes:
> Jonathan brought up the following very long term vision:
> Eventually the everyday git commands do not treat submodules
> any special than trees, even the submodules git directory
> may be non existent (everything is absorbed into the superproject);
> so it really feels li
Stefan Beller writes:
> From: Lars Schneider
>
> Do not override the submodule configuration in the call to update
> the submodules, but give a weaker default.
>
> Reported-by: Lars Schneider
> Signed-off-by: Stefan Beller
> ---
>
> Personally I dislike this patch, but I have no better idea
Stefan Beller writes:
> On Fri, Aug 18, 2017 at 3:04 PM, Stefan Beller wrote:
>> From: Lars Schneider
>
> eh, that is what I get for amending to Lars patch.
Sorry, I do not understand this remark.
If you started from a patch by Lars (I do not recall seeing it but
the list is high volume so
Reject directories with the attribute export-ignore already while
queuing them. This prevents read_tree_recursive() from descending into
them and this avoids write_archive_entry() rejecting them later on,
which queue_or_write_archive_entry() is not prepared for.
Borrow the existing strbuf to buil
When read_tree_recursive() encounters a directory excluded by a pathspec
then it enters it anyway because it might contain included entries. It
calls the callback function before it is able to decide if the directory
is actually needed.
For that reason git archive adds directories to a queue and
Add helpers for accessing attributes that encapsulate the details of how
to retrieve their values.
Signed-off-by: Rene Scharfe
---
archive.c | 31 +++
1 file changed, 23 insertions(+), 8 deletions(-)
diff --git a/archive.c b/archive.c
index 557dd2db85..8e5f632912 100
Demonstrate mishandling of the attribute export-ignore by git archive
when used together with pathspecs. Wildcard pathspecs can even cause it
to abort. And a directory excluded without a wildcard is still included
as an empty folder in the archive.
Test-case-by: David Adam
Signed-off-by: Rene S
Am 14.08.2017 um 18:43 schrieb René Scharfe:
> The real solution is probably to teach tree-walk.c::do_match() how to
> handle attributes and then inject ":(attr:-export-ignore)" as a default
> internal pathspec in archive.c::parse_pathspec_arg() instead of handling
> it in archive.c::write_archive_
On Fri, 11 Aug 2017 15:41:28 -0400
Ben Peart wrote:
> Nice to see the pack file functions being refactored out. I looked at
> the end result and it looked good to me.
Thanks.
> Do you have the energy to do a similar refactoring for the remaining
> public functions residing in sha1_file.c? P
On Fri, 18 Aug 2017 10:18:37 -0400
Ben Peart wrote:
> > But if there was a good way to refer to the "anti-projection" in a
> > virtualized system (that is, the "real" thing or "object" behind the
> > "virtual" thing or "image"), then maybe the "virtualized" language is
> > the best. (And I would
While merging if I do certain actions then the merge commit is made
with the merge message but as a normal (non-merge) commit.
Repro steps:
- Set GIT_MERGE_AUTOEDIT=yes (set other than "no") in .bashrc
- Make a merge commit with no conflicts.
(external text editor shows the generated merge messa
Mike Hommey wrote[1]:
> On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
>> Mike Hommey wrote:
>>> The reason for the :: prefix is that it matches the ::
>>> prefix used for remote helpers.
>>>
>>> Now, there are a few caveats:
[...]
>>> - msys likes to completely fuck up command l
alloc_packed_git() in packfile.c is duplicated from sha1_file.c. In a
subsequent commit, alloc_packed_git() will be removed from sha1_file.c.
Signed-off-by: Jonathan Tan
---
builtin/count-objects.c | 1 +
builtin/fsck.c | 1 +
builtin/pack-objects.c | 1 +
cache.h
Signed-off-by: Jonathan Tan
---
cache.h | 1 -
packfile.c | 9 +
packfile.h | 1 +
sha1_file.c | 9 -
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/cache.h b/cache.h
index a27018210..0313b0b8d 100644
--- a/cache.h
+++ b/cache.h
@@ -1645,7 +1645,6 @@ extern
Signed-off-by: Jonathan Tan
---
cache.h | 1 -
connected.c | 1 +
packfile.c | 53 +
packfile.h | 1 +
sha1_file.c | 61 -
5 files changed, 55 insertions(+), 62 deletions(-)
d
This function needs to be global as it is used by sha1_file.c and will
be used by packfile.c.
Signed-off-by: Jonathan Tan
---
packfile.c | 53 +
packfile.h | 2 ++
sha1_file.c | 53 -
3 fil
Signed-off-by: Jonathan Tan
---
cache.h | 1 -
packfile.c | 11 ++-
packfile.h | 2 ++
sha1_file.c | 9 -
4 files changed, 12 insertions(+), 11 deletions(-)
diff --git a/cache.h b/cache.h
index 3625509f9..c4d8bee52 100644
--- a/cache.h
+++ b/cache.h
@@ -1619,7 +1619,6 @@
Signed-off-by: Jonathan Tan
---
cache.h | 1 -
packfile.c | 25 +
packfile.h | 2 ++
sha1_file.c | 25 -
4 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/cache.h b/cache.h
index 63765d481..75cc0c497 100644
--- a/cache.h
+++ b
Signed-off-by: Jonathan Tan
---
builtin/gc.c | 1 +
bulk-checkin.c | 1 +
cache.h| 15
connected.c| 2 +-
fetch-pack.c | 1 +
http-backend.c | 1 +
packfile.c | 217 +
packfile.h | 16 -
path.c
The function unuse_one_window() needs to be temporarily made global. Its
scope will be restored to static in a subsequent commit.
Signed-off-by: Jonathan Tan
---
git-compat-util.h | 2 --
packfile.c| 49 +
packfile.h| 4
sha1
Signed-off-by: Jonathan Tan
---
cache.h | 8 ---
packfile.c | 76 -
packfile.h | 9 ++--
sha1_file.c | 73 --
4 files changed, 82 insertions(+), 84 deletions(-)
dif
Signed-off-by: Jonathan Tan
---
cache.h | 2 --
packfile.c | 24
packfile.h | 2 ++
sha1_file.c | 24
4 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/cache.h b/cache.h
index aa2b4d390..a0497d469 100644
--- a/cache.h
+++ b/
Signed-off-by: Jonathan Tan
---
cache.h | 3 ---
http-push.c | 1 +
http-walker.c | 1 +
packfile.c| 13 +
packfile.h| 3 +++
sha1_file.c | 13 -
6 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/cache.h b/cache.h
index 9297d078a..1e90b
Signed-off-by: Jonathan Tan
---
builtin/prune-packed.c | 1 +
cache.h| 2 --
diff.c | 1 +
packfile.c | 6 ++
packfile.h | 2 ++
revision.c | 1 +
sha1_file.c| 6 --
7 files changed, 11 insertions(+), 8 deleti
Signed-off-by: Jonathan Tan
---
cache.h | 1 -
packfile.c | 26 ++
packfile.h | 1 +
sha1_file.c | 26 --
4 files changed, 27 insertions(+), 27 deletions(-)
diff --git a/cache.h b/cache.h
index 87f65aeea..7adbc587d 100644
--- a/cache.h
+++
Both sha1_file.c and packfile.c now need read_object(), so a copy of
read_object() was created in packfile.c.
This patch makes both mark_bad_packed_object() and has_packed_and_bad()
global. Unlike most of the other patches in this series, these 2
functions need to remain global.
Signed-off-by: Jo
Signed-off-by: Jonathan Tan
---
cache.h | 2 --
packfile.c | 8
packfile.h | 2 ++
sha1_file.c | 8
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/cache.h b/cache.h
index 286891df4..dcbe37a3f 100644
--- a/cache.h
+++ b/cache.h
@@ -1233,8 +1233,6 @@ extern
Signed-off-by: Jonathan Tan
---
cache.h | 16
packfile.c | 33 +
packfile.h | 16
sha1_file.c | 33 -
4 files changed, 49 insertions(+), 49 deletions(-)
diff --git a/cache.h b/cache.h
index 83
Signed-off-by: Jonathan Tan
---
cache.h | 1 -
packfile.c | 40
packfile.h | 1 +
sha1_file.c | 39 ---
4 files changed, 41 insertions(+), 40 deletions(-)
diff --git a/cache.h b/cache.h
index 75cc0c497..87f65aee
Signed-off-by: Jonathan Tan
---
cache.h | 14 --
packfile.c | 31 +++
packfile.h | 16 +++-
sha1_file.c | 31 ---
4 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/cache.h b/cache.h
index 11aa18e6
Signed-off-by: Jonathan Tan
---
builtin/cat-file.c | 1 +
cache.h| 7 +--
packfile.c | 40
packfile.h | 11 +++
reachable.c| 1 +
sha1_file.c| 40
6 files c
sha1_file.c declares some static variables that store packfile-related
state. Move them to packfile.c.
They are temporarily made global, but subsequent commits will restore
their scope back to static.
Signed-off-by: Jonathan Tan
---
packfile.c | 14 ++
packfile.h | 9 +
s
The function close_pack_fd() needs to be temporarily made global. Its
scope will be restored to static in a subsequent commit.
Signed-off-by: Jonathan Tan
---
builtin/am.c | 1 +
builtin/clone.c| 1 +
builtin/fetch.c| 1 +
builtin/merge.c| 1 +
builtin/recei
The function open_packed_git() needs to be temporarily made global. Its
scope will be restored to static in a subsequent commit.
Signed-off-by: Jonathan Tan
---
cache.h | 1 -
packfile.c | 303 ++--
packfile.h | 14 +--
sha1_file.c
Currently, sha1_file.c and cache.h contain many functions, both related
to and unrelated to packfiles. This makes both files very large and
causes an unclear separation of concerns.
Create a new file, packfile.c, to hold all packfile-related functions
currently in sha1_file.c. It has a correspondi
> You'd need to double check, but I think the topics that cause
> trouble are rs/find-apck-entry-bisection and jk/drop-sha1-entry-pos;
> you can start from v2.14.1 and merge these topics on top and then
> build your change on top. That would allow you to start cooking
> before both of them graduat
On Fri, Aug 18, 2017 at 03:06:37PM -0700, Jonathan Nieder wrote:
> Hi,
>
> Mike Hommey wrote:
>
> > My thought is that a string like :: could be used
> > wherever a committish is expected. That would call some helper
> > and request to resolve revision, and the helper would provide a git
> > comm
Hi,
Mike Hommey wrote:
> My thought is that a string like :: could be used
> wherever a committish is expected. That would call some helper
> and request to resolve revision, and the helper would provide a git
> commit as a response.
I like this idea.
> The reason for the :: prefix is that it m
On Fri, Aug 18, 2017 at 3:04 PM, Stefan Beller wrote:
> From: Lars Schneider
eh, that is what I get for amending to Lars patch.
From: Lars Schneider
Do not override the submodule configuration in the call to update
the submodules, but give a weaker default.
Reported-by: Lars Schneider
Signed-off-by: Stefan Beller
---
Personally I dislike this patch, but I have no better idea for the time
being.
Thanks,
Stefan
bu
On Fri, Aug 18, 2017 at 08:15:09AM -0400, Jeff King wrote:
> On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote:
>
> > I was thinking it could be useful to have a special syntax for revisions
> > that would query a helper program. The helper program could use a
> > similar protocol to tha
On Fri, Aug 18, 2017 at 3:38 PM, Jonathan Nieder wrote:
> Hi,
>
> R0b0t1 wrote:
>
>> The issue is as follows:
>>
>> R0b0t1@host:~/devel/project$ git submodule add
>> https://github.com/user/project -f
>> Cloning into '/home/R0b0t1/devel/project/-f'...
>
> Thanks for reporting. Confusingly, I thin
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.
The top part of the draft release
Hi,
R0b0t1 wrote:
> The issue is as follows:
>
> R0b0t1@host:~/devel/project$ git submodule add
> https://github.com/user/project -f
> Cloning into '/home/R0b0t1/devel/project/-f'...
Thanks for reporting. Confusingly, I think this is intended behavior.
"git help submodule" explains:
ad
Patryk Obara writes:
> Actually, I don't think I needed to remove free(graft) line, but I don't
> know if freeing NULL is considered ok in git code. Let me know if I
> should bring it back, please.
Either free(graft) or assert(!graft) is fine, but we should have one
of them there. I'll add asse
Hello,
I wish to seek for your assistance in a deal that will be of mutual benefit for
the both of us from Camp Stanley in Uijeongbu. Please contact me for details,
God bless you.
Ok, so that's an option - in this instance free is not actually needed
because it can be triggered only in phase 0, but it would add a bit of
robustness.
--
| ← Ceci n'est pas une pipe
Patryk Obara
On Thu, Aug 17, 2017 at 10:16 PM, R0b0t1 wrote:
> The issue is as follows:
>
> R0b0t1@host:~/devel/project$ git submodule add
> https://github.com/user/project -f
> Cloning into '/home/R0b0t1/devel/project/-f'...
>
> My .gitignore's first line is *, and then I explicitly allow things.
> Despite th
Patryk Obara writes:
> Actually, I don't think I needed to remove free(graft) line, but I don't
> know if freeing NULL is considered ok in git code. Let me know if I
> should bring it back, please.
Calling free(var) when var may or may not be NULL is perfectly fine.
We even discourage people fr
Stefan Beller writes:
>> In the past "submodule..update=none" was an easy way
>> to selectively disable certain Submodules.
>>
>> How would I do this with Git 2.14?
>
> submodule..active = false
>
>> My gut feeling is that all commands should respect the
>> "submodule..update=none" setting.
>
On Fri, Aug 18, 2017 at 9:50 AM, Junio C Hamano wrote:
> I am not sure if I follow. Submodules are not trees and one of the
> reasons people may want to separate things into different modules is
> so that they can treat them differently. If submodules allow you
> a richer set of operations than
> I just copied the shortcut that they were adding themselfes as submodule
> in 'setup submodule'. The whole setup of submodules in this test is like
> this. This way we already had a nested submodule structure which I could
> just add.
>
> I agree that this is unrealistic so I can change that in t
Actually, I don't think I needed to remove free(graft) line, but I don't
know if freeing NULL is considered ok in git code. Let me know if I
should bring it back, please.
--
| ← Ceci n'est pas une pipe
Patryk Obara
Changes since v3:
- Commit replacing raw buffer does not store temporary pointer to
strbuf internals any more.
- Commit message of patch 4 explains all alternative approaches
considered so far.
- Patch 4 uses two-phases to parse graft line, without code repetition.
I have my reservations ab
Old implementation determined number of hashes by dividing length of
line by length of hash, which works only if all hash representations
have same length.
New graft line parser works in two phases:
1. In first phase line is scanned to verify correctness and compute
number of hashes, then
The array is declared in cache.h as:
extern const unsigned char null_sha1[GIT_MAX_RAWSZ];
Definition in sha1_file.c must match.
Signed-off-by: Patryk Obara
---
sha1_file.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sha1_file.c b/sha1_file.c
index b60ae15..f5b5bec 100
struct commit_graft aggregates an array of object_id's, which have
size >= GIT_MAX_RAWSZ bytes. This change prevents memory allocation
error when size of object_id is larger than GIT_SHA1_RAWSZ.
Signed-off-by: Patryk Obara
---
commit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
dif
This simplifies function declaration and allows for use of strbuf_rtrim
instead of modifying buffer directly.
Signed-off-by: Patryk Obara
---
builtin/blame.c | 2 +-
commit.c| 23 +++
commit.h| 2 +-
3 files changed, 13 insertions(+), 14 deletions(-)
diff -
Patryk Obara writes:
> Ah! I presumed two separate loops, one throwing away oids and second
> one actually filling a table - this makes more sense. I was just about
> to send v4, but will rewrite the last patch and we'll see how it looks
> like.
Yeah, it is understandable if you missed my "a loo
On Thu, Aug 17, 2017 at 12:05:56PM -0700, Stefan Beller wrote:
> On Thu, Aug 17, 2017 at 3:34 AM, Heiko Voigt wrote:
> > When using git-mv with a submodule it will detect that and update the
> > paths for its configurations (.gitmodules, worktree and gitfile). This
> > does not work for nested sub
> In the past "submodule..update=none" was an easy way
> to selectively disable certain Submodules.
>
> How would I do this with Git 2.14?
submodule..active = false
> My gut feeling is that all commands should respect the
> "submodule..update=none" setting.
Well my gut feeling was that the "
Ah! I presumed two separate loops, one throwing away oids and second
one actually filling a table - this makes more sense. I was just about
to send v4, but will rewrite the last patch and we'll see how it looks
like.
--
| ← Ceci n'est pas une pipe
Patryk Obara
On 18 August 2017 at 18:30, Junio C Hamano wrote:
> Kaartic Sivaraam writes:
>
>> On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote:
>>> Martin Ågren writes:
>>>
On 17 August 2017 at 04:54, Kaartic Sivaraam
wrote:
> Helped-by: Martin Ågren , Junio C Hamano
>
> Sig
Michael J Gruber writes:
> `*` in format strings means peeling of tag objects so that object field
> names refer to the object that the tag object points at, instead of the
> tag object itself.
>
> Currently, this is documented using grammar that is clearly inspired by
> classical latin, though m
Stefan Beller writes:
> On Thu, Aug 17, 2017 at 7:13 PM, Junio C Hamano wrote:
>> Stefan Beller writes:
>>
>>> Are you saying this might be a design mistake and
>>> the .update ought to be respected by all the other
>>> commands? For example
>>> git reset --recurse-submodules
>>> should ign
Patryk Obara writes:
> Junio C Hamano wrote:
>>
>> If I were doing the two-pass thing, I'd probably write a for loop
>> that runs exactly twice, where the first iteration parses into a
>> single throw-away oid struct only to count, and the second iteration
>> parses the same input into the alloc
On Thu, Aug 17, 2017 at 10:20:13AM -0700, Stefan Beller wrote:
> On Thu, Aug 17, 2017 at 3:53 AM, Heiko Voigt wrote:
> > We store the changed submodules paths to calculate which submodule needs
> > fetching. This does not work for moved submodules since their paths do
> > not stay the same in case
Kaartic Sivaraam writes:
> On Monday 14 August 2017 02:20 PM, Kaartic Sivaraam wrote:
>>
>> On Wednesday 09 August 2017 12:03 AM, Martin Ågren wrote:
>>>
>>> Maybe the final note could be removed? Someone who is looking up
>>> --set-upstream because Git just "crashed" on them will only want to kn
Kaartic Sivaraam writes:
> On Friday 18 August 2017 01:25 AM, Junio C Hamano wrote:
>> Martin Ågren writes:
>>
>>> On 17 August 2017 at 04:54, Kaartic Sivaraam
>>> wrote:
Helped-by: Martin Ågren , Junio C Hamano
Signed-off-by: Kaartic Sivaraam
>>> I didn't expect a "Helped-by
On Thu, Aug 17, 2017 at 10:50:07AM -0700, Brandon Williams wrote:
> On 08/17, Stefan Beller wrote:
> > On Thu, Aug 17, 2017 at 4:00 AM, Heiko Voigt wrote:
> > > To make extending this logic later easier.
> > >
> > > Signed-off-by: Heiko Voigt
> > > ---
> > > I am quite sure I replicated the same
`*` in format strings means peeling of tag objects so that object field
names refer to the object that the tag object points at, instead of the
tag object itself.
Currently, this is documented using grammar that is clearly inspired by
classical latin, though missing more than an article in order t
Various commands list refs and allow to use a format string for the
output that interpolates from the ref as well as the object it points
at (for-each-ref; branch and tag in list mode).
Currently, the documentation talks about interpolating from the object.
This is confusing because a ref points t
On 8/17/2017 5:39 PM, Jonathan Tan wrote:
Thanks for your comments. I'll reply to both your e-mails in this one
e-mail.
This illustrates another place we need to resolve the
naming/vocabulary. We should at least be consistent to make it easier
to discuss/explain. We obviously went with "vir
> On 17 Aug 2017, at 23:55, Stefan Beller wrote:
>
> On Thu, Aug 17, 2017 at 2:21 PM, Lars Schneider
> wrote:
>>
>>> Oh, wait.
>>> $ git log --oneline v2.13.0..v2.14.1 -- builtin/pull.c
>>> c9c63ee558 Merge branch 'sb/pull-rebase-submodule'
>>> a6d7eb2c7a pull: optionally rebase submodules (re
On Fri, Aug 18, 2017 at 03:42:08PM +0900, Mike Hommey wrote:
> I was thinking it could be useful to have a special syntax for revisions
> that would query a helper program. The helper program could use a
> similar protocol to that of the remote helpers.
That sounds like a reasonable thing to want
On Fri, Aug 18, 2017 at 08:56:03AM +0200, Michael J Gruber wrote:
> > The idea being that users could run "git lint" if they suspect something
> > funny is going on. I dunno. It may be a dead-end. Most such
> > oddities are better detected and handled during actual git operations if
> > we can. So
On Fri, Aug 18, 2017 at 12:12:37PM +0200, Patryk Obara wrote:
> Jeff King wrote:
>
> > AFAICT this is only here to avoid having to s/buf/line->buf/ in the rest
> > of the function. But I think we should just make that change (you
> > already did in some of the spots). And IMHO we should do the s
On Fri, Aug 18, 2017 at 01:30:23PM +0200, Patryk Obara wrote:
> > We'd reject such an input totally (though as an interesting side effect,
> > you can convince the parser to allocate 20x as much RAM as you send it;
> > one oid for each space).
>
> Grafts are not populated during clone operation,
Jeff King wrote:
>
> So we're probably fine. The two parsing passes are right next to each
> other and are sufficiently simple and strict that we don't have to
> worry about them diverging.
That was my conclusion as well. I added comment before the first pass and
avoided any "cleverness" to make
Jeff King wrote:
> AFAICT this is only here to avoid having to s/buf/line->buf/ in the rest
> of the function. But I think we should just make that change (you
> already did in some of the spots). And IMHO we should do the same for
> line->len. When there are two names for the same value, it incr
On Wed, Aug 16, 2017 at 12:47 AM, Shawn Pearce wrote:
> On Mon, Aug 14, 2017 at 5:13 AM, Michael Haggerty
> wrote:
>> On 08/07/2017 03:47 AM, Shawn Pearce wrote:
>>> 6th iteration of the reftable storage format.
> [...]
>>> index record
>>>
>>> An index record describes the last entry in an
Jeff King writes:
> I _do_ think it's a misfeature to put it in check-ref-format. It should
> be part of rev-parse. Which admittedly is a kitchen sink, but this kind
> of resolving is one of the main things it should be doing. And in fact
> you can already do:
>
> git rev-parse --symbolic-full-
Jeff King writes:
> So we're probably fine. The two parsing passes are right next to each
> other and are sufficiently simple and strict that we don't have to
> worry about them diverging.
If I were doing the two-pass thing, I'd probably write a for loop
that runs exactly twice, where the first
On Thu, Aug 17, 2017 at 10:35:54PM +0200, Torsten Bögershausen wrote:
> On Wed, Aug 16, 2017 at 10:16:12PM +0200, Martin Koegler wrote:
> > From: Martin Koegler
> >
> > This patchset is for next [24db08a6e8fed761d3bace7f2d5997806e20b9f7].
>
> I applied it succesfully, and run the test suite on a
84 matches
Mail list logo
