On Thu, Nov 21, 2013 at 09:19:25PM +0100, Christian Couder wrote:
> Yeah, I think it might report wrong size in case of replaced objects
> for example.
> I looked at that following Junio's comment about the
> sha1_object_info() API, which,
> unlike read_sha1_file() API, does not interact with the
I Have A Project For Charity Which I cannot complete because Of My Illness.
Please Contact Me On: hans-zi...@live.de
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info
On Thu, Nov 21, 2013 at 04:19:43PM -0800, Junio C Hamano wrote:
> * np/pack-v4 (2013-09-18) 90 commits
> . packv4-parse.c: add tree offset caching
> . t1050: replace one instance of show-index with verify-pack
> . index-pack, pack-objects: allow creating .idx v2 with .pack v4
> . unpack-object
On Fri, Nov 22, 2013 at 10:58 AM, Jeff King wrote:
> On Thu, Nov 21, 2013 at 09:19:25PM +0100, Christian Couder wrote:
>
>> Yeah, I think it might report wrong size in case of replaced objects
>> for example.
>> I looked at that following Junio's comment about the
>> sha1_object_info() API, which,
[+CC: Jens, the goto-guy for submodules]
Sergey Sharybin wrote:
> Namely, `git ls-files -m` will show addons as modified, regardless
> ignore=all configuration. In the same time `git diff-index --name-only
> HEAD --` will show no changes at all.
This happens because diff-index handles submodules
On Fri, Nov 22, 2013 at 12:04:01PM +0100, Christian Couder wrote:
> In "sha1_file.c", there is:
>
> void *read_sha1_file_extended(const unsigned char *sha1,
> enum object_type *type,
> unsigned long *size,
>
Hey,
Answers are inlined.
On Fri, Nov 22, 2013 at 5:16 PM, Ramkumar Ramachandra
wrote:
>
> [+CC: Jens, the goto-guy for submodules]
>
> Sergey Sharybin wrote:
> > Namely, `git ls-files -m` will show addons as modified, regardless
> > ignore=all configuration. In the same time `git diff-index --
BTW, a workaround is to pass a path to askpass script in the GIT_ASKPASS
environment variable.
Jens Lehmann writes:
> Am 16.11.2013 22:42, schrieb Thomas Rast:
>> Dmitry Neverov writes:
>>
>>> git -c core.askpass=pass.sh clone main-repo
>>> cd main-repo
>>> git submodule init
>>> git submodule
Hi,
On Thu, Nov 21, 2013 at 09:40:48PM +0100, Torsten Bögershausen wrote:
> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index d87ddf7..9136f2a 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
> @@ -531,5 +531,62 @@ test_expect_success 'shallow fetch with tags doe
Sergey Sharybin wrote:
> On Fri, Nov 22, 2013 at 5:16 PM, Ramkumar Ramachandra
> wrote:
>>
>> [+CC: Jens, the goto-guy for submodules]
>>
>> Sergey Sharybin wrote:
>> > Namely, `git ls-files -m` will show addons as modified, regardless
>> > ignore=all configuration. In the same time `git diff-inde
Running 'make GITWEB_WANTED_REFS="heads wip" gitweb.cgi' will create a
gitweb CGI script showing branches that appear in refs/heads/ and in
refs/wip/. Might be useful for gerrit setups where user branches are
not stored under refs/heads/.
Signed-off-by: Krzesimir Nowak
---
Notes:
I'm actuall
Hi,
I'm usually in a subfolder doing actual work. A very common problem I
have is wanting to do a submodule update, but git really hates that. And
I wonder why?
It wouldn't be hard to cd to the toplevel working directory, do the
update, and cd back. It's what I have to do manually every time now
On Fri, Nov 22, 2013 at 02:22:30PM +0100, Odin Hørthe Omdal wrote:
> I'm usually in a subfolder doing actual work. A very common problem I
> have is wanting to do a submodule update, but git really hates that. And
> I wonder why?
>
> It wouldn't be hard to cd to the toplevel working directory, do
On Fri, Nov 22, 2013 at 12:24 PM, Jeff King wrote:
> On Fri, Nov 22, 2013 at 12:04:01PM +0100, Christian Couder wrote:
>
>> In "sha1_file.c", there is:
>>
>> void *read_sha1_file_extended(const unsigned char *sha1,
>> enum object_type *type,
>>
On Fri, Nov 22, 2013, at 14:47, John Keeping wrote:
> On Fri, Nov 22, 2013 at 02:22:30PM +0100, Odin Hørthe Omdal wrote:
> > I'm usually in a subfolder doing actual work. A very common problem I
> > have is wanting to do a submodule update, but git really hates that. And
> > I wonder why?
> >
> >
On Fri, Nov 22, 2013 at 06:38:47PM +0530, Ramkumar Ramachandra wrote:
> >> Does Arcanist use `git ls-files -m` to check?
> >
> > Yes, Arcanist uses `git ls-files -m` to check whether there're local
> > modifications. We might also contact phab developers asking to change
> > it to `git diff --name
Ramkumar, not actually sure what you mean?
For me `git diff --name-only HEAD --` ignores changes to submodules
hash changes. Also apparently it became a known TODO for phabricator
developers [1].
Jeff, kinda trying to match yes. Just don't want changes to submodules
hash to be included.
So, afte
Jeff King wrote:
>> I just checked it out: it uses `git ls-files -m` to get the list of
>> unstaged changes; `git diff --name-only HEAD --` will list staged
>> changes as well.
>
> That diff command compares the working tree and HEAD; if you are trying
> to match `ls-files -m`, you probably wanted
On Fri, Nov 22, 2013 at 03:23:31PM +0100, Christian Couder wrote:
> > The only site which calls read_sha1_file_extended directly and does not
> > pass the REPLACE flag is in streaming.c. And that looks to be a case of
> > (2), since we resolve the replacement at the start in open_istream().
>
> Y
git-cherry(1)'s "description" section has never really managed to
explain to me what the command does. It contains too much explanation
of the algorithm instead of simply saying what goals it achieves, and
too much terminology that we otherwise do not use (fork-point instead
of merge-base).
Try a
Sergey Sharybin wrote:
> Ramkumar, not actually sure what you mean?
>
> For me `git diff --name-only HEAD --` ignores changes to submodules
> hash changes.
`git diff --name-only HEAD --` compares the worktree to HEAD (listing
both staged and unstaged changes); we want `git diff --name-only --`
to
Jeff King writes:
>> * jk/pack-bitmap (2013-11-18) 22 commits
[...]
>> Borrows the bitmap index into packfiles from JGit to speed up
>> enumeration of objects involved in a commit range without having to
>> fully traverse the history.
>
> Looks like you picked up my latest re-roll with Ramsay'
Ah, didn't notice you're the author of that pull-request Ramkumar :)
So guess issue with arc can be considered solved now. But i'm still
collecting more details about how to manage to commit change addons
hash without arc command even (it happens to Campbell Barton really
often).
Will report back
Jeff King writes:
> I guess we would need to audit all the sha1_object_info callers.
Yup; I agree that was the conclusion of Christian's thread.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http:
On Fri, Nov 22, 2013 at 05:52:37PM +0100, Thomas Rast wrote:
> > Looks like you picked up my latest re-roll with Ramsay's fix on top.
> > There wasn't a lot of review on this past round (I'm not surprised; it's
> > a dauntingly large chunk to review). I outlined a few possible open
> > issues in
Jeff King wrote:
> > BTW, I've also seen git cat-file --batch report wrong sizes for objects,
>
> Hrm. For --batch, I'd think we would open the whole object and notice
> the corruption, even with the current code. But for --batch-check, we
> use sha1_object_info, and for an "experimental" object,
Krzesimir Nowak writes:
> Running 'make GITWEB_WANTED_REFS="heads wip" gitweb.cgi' will create a
> gitweb CGI script showing branches that appear in refs/heads/ and in
> refs/wip/. Might be useful for gerrit setups where user branches are
> not stored under refs/heads/.
>
> Signed-off-by: Krzesim
Ok, got it now.
To reproduce the issue:
- Run git submodule update --recursive to make sure their SHA is
changed. Then `git add /path/to/changed submodule` or just `git add .`
- Modify any file from the parent repository
- Neither of `git status`, `git diff` and `git diff-files --name-only`
will
Jeff King writes:
>> Hmm, maybe I missed something, but AFAICS you (or Vicent) never acted on
>> or responded to my June reviews in this thread:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/228918
[...]
>> Granted, the way I verified this was checking whether you renamed
>> rlw
Sergey Sharybin wrote:
> To reproduce the issue:
>
> - Run git submodule update --recursive to make sure their SHA is
> changed. Then `git add /path/to/changed submodule` or just `git add .`
> - Modify any file from the parent repository
> - Neither of `git status`, `git diff` and `git diff-files -
Thomas Rast writes:
> NAME
>
> +git-cherry - Find commits not applied in upstream
>
> +Determine whether there are commits in `..` that are
> +equivalent to those in the range `..`.
>
> +The equivalence test is based on the diff, after removing whitespace
> +and line numbers. git-cher
Junio C Hamano writes:
> We are listing those that need to be added to the upstream with "+",
> while listing those that can be dropped from yours if you rebase
> with "-". Hinting the rationale behind the choice of "+/-"
> somewhere may help as a mnemonic to the readers (see below).
[...]
> And
Jeff King writes:
> Looks like you picked up my latest re-roll with Ramsay's fix on top.
> There wasn't a lot of review on this past round (I'm not surprised; it's
> a dauntingly large chunk to review). I outlined a few possible open
> issues in the cover letter, but I'd be happy to build those
Thomas Rast writes:
> Junio C Hamano writes:
>
>> We are listing those that need to be added to the upstream with "+",
>> while listing those that can be dropped from yours if you rebase
>> with "-". Hinting the rationale behind the choice of "+/-"
>> somewhere may help as a mnemonic to the rea
On Fri, Nov 22, 2013 at 6:26 PM, Jeff King wrote:
>> Granted, the way I verified this was checking whether you renamed
>> rlw_xor_run_bit() to something more fitting, so perhaps you just forgot
>> that one thing but did all the rest.
>
> I didn't touch that. Vicent, did you have a comment on the n
On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano wrote:
>> Do we want to try this in 'next' post-1.8.5, or should I try to prod an
>> area expert like Shawn into doing another round of review?
>
> Yes ;-).
>
> I recall starting to read the series over and then got sidetracked
> in the middle and ne
Vicent Martí writes:
> On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano wrote:
>
> We are running a slightly older version of the patchset, because we're
> still on 1.8.4 and the current reroll doesn't apply cleanly there.
>
> If this could make it to `next` some time next week, that would work
>
Vicent Marti writes:
> On Fri, Nov 22, 2013 at 6:26 PM, Jeff King wrote:
>> I didn't touch that. Vicent, did you have a comment on the name (it
>> really does look like it is a negation, and the only caller is
>> ewah_not).
>
> Yes, the name was ported straight from the original library and kept
Am 22.11.2013 17:12, schrieb Ramkumar Ramachandra:
> Jeff King wrote:
>>> I just checked it out: it uses `git ls-files -m` to get the list of
>>> unstaged changes; `git diff --name-only HEAD --` will list staged
>>> changes as well.
>>
>> That diff command compares the working tree and HEAD; if you
Am 22.11.2013 19:11, schrieb Ramkumar Ramachandra:
> Sergey Sharybin wrote:
>> To reproduce the issue:
>>
>> - Run git submodule update --recursive to make sure their SHA is
>> changed. Then `git add /path/to/changed submodule` or just `git add .`
>> - Modify any file from the parent repository
>>
> > For some reason, the
> > `git add .` is adding the ignored submodule to the index.
>
> The ignore setting is documented to only affect diff output
> (including what checkout, commit and status show as modified).
> While I agree that this behavior is confusing for Sergey and
> not optimal for th
Hi,
On Fri, Nov 22, 2013 at 10:01:44PM +0100, Jens Lehmann wrote:
> Hmm, looks like git show also needs to be fixed to honor the
> ignore setting from .gitmodules. It already does that for
> diff.ignoreSubmodules from either .git/config or git -c and
> also supports the --ignore-submodules command
Heiko Voigt wrote:
> After that we can discuss whether add should add submodules that are
> tracked but not shown. How about commit -a ? Should it also ignore the
> change? I am undecided here. There does not seem to be any good
> decision. From the users point of view we should probably not add i
On Fri, Nov 22, 2013 at 12:05:25PM -0800, Junio C Hamano wrote:
> > If this could make it to `next` some time next week, that would work
> > out great for us, because we may start considering using `next` as a
> > partial or full deployment on our production machines
>
> I do not think potentiall
On Fri, Nov 22, 2013 at 06:58:55PM +0100, Thomas Rast wrote:
> > I didn't touch that. Vicent, did you have a comment on the name (it
> > really does look like it is a negation, and the only caller is
> > ewah_not).
>
> Hmm, so it really was that one unlucky thing :-)
I don't promise there is onl
Jeff King writes:
> Re-rolling such a big chunk of code _is_ a pain for both me and for
> reviewers, so I wouldn't mind switching to "fixes on top" instead of
> re-rolling at some point. But we can do another round or two of re-roll
> first.
No, actually I think the plan that you sketched in the
gits...@pobox.com wrote on Thu, 21 Nov 2013 11:47 -0800:
> Crestez Dan Leonard writes:
>
> > The output of git format-patch can vary with user preferences. In
> > particular setting diff.noprefix will break the "git apply" that
> > is done as part of "git p4 submit".
> >
> > Signed-off-by: Creste
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Jeff King wrote:
> sha1_file.c| 74
> -
Yay!
> t/t1013-loose-object-format.sh | 66 --
Hmm, not all of these tests are about the "experimental" format. Do
we really want to remove them all?
Than
On Fri, Nov 22, 2013 at 04:24:05PM -0800, Jonathan Nieder wrote:
> > t/t1013-loose-object-format.sh | 66 --
>
> Hmm, not all of these tests are about the "experimental" format. Do
> we really want to remove them all?
I think so. They were not all testing th
Jeff King wrote:
> On Fri, Nov 22, 2013 at 04:24:05PM -0800, Jonathan Nieder wrote:
>>> t/t1013-loose-object-format.sh | 66 --
>>
>> Hmm, not all of these tests are about the "experimental" format. Do
>> we really want to remove them all?
>
> I think so. They
If the value of ignore for submodules is set to "all" we would not show
whats actually committed during status or diff. This can result in the
user committing unexpected submodule references. Lets be nicer and always
show whats in the index.
Signed-off-by: Heiko Voigt
---
This probably needs spli
Hello,
$ mkdir xyz
$ cd xyz
$ rmdir ../xyz
$ git status
fatal: Unable to read current working directory: Kh?ng c? t?p tin ho?c
th? m?c nh? v?y
So, somthing wrong with our charset.
$ strace git status 2>&1 | grep open
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib/i386-linux-gnu/libz
Jens Lehmann wrote:
> But the question is if that is the right thing to do: should
> diff.ignoreSubmodules and submodule..ignore only affect
> the diff family or also git log & friends? That would make
> users blind for submodule history (which they already are
> when using diff & friends, so that
Heiko Voigt wrote:
> What I think needs fixing here first is that the ignore setting should not
> apply to any diffs between HEAD and index. IMO, it should only apply
> to the diff between worktree and index.
>
> When we have that the user does not see the submodule changed when
> normally working.
55 matches
Mail list logo
