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
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-objects:
On Fri, Nov 22, 2013 at 10:58 AM, Jeff King p...@peff.net 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,
[+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
artag...@gmail.com 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
BTW, a workaround is to pass a path to askpass script in the GIT_ASKPASS
environment variable.
Jens Lehmann jens.lehm...@web.de writes:
Am 16.11.2013 22:42, schrieb Thomas Rast:
Dmitry Neverov dmitry.neve...@jetbrains.com writes:
git -c core.askpass=pass.sh clone main-repo
cd main-repo
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 does
Sergey Sharybin wrote:
On Fri, Nov 22, 2013 at 5:16 PM, Ramkumar Ramachandra
artag...@gmail.com 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
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 krzesi...@endocode.com
---
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 the
On Fri, Nov 22, 2013 at 12:24 PM, Jeff King p...@peff.net 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?
It
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-only HEAD
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,
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 just
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().
Yeah,
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 p...@peff.net 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
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
Jeff King p...@peff.net 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
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 the
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, we do
Krzesimir Nowak krzesi...@endocode.com 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/.
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 p...@peff.net 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
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 t...@thomasrast.ch writes:
NAME
+git-cherry - Find commits not applied in upstream
+Determine whether there are commits in `head..upstream` that are
+equivalent to those in the range `limit..head`.
+The equivalence test is based on the diff, after removing
Junio C Hamano gits...@pobox.com 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).
Jeff King p...@peff.net 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
Thomas Rast t...@thomasrast.ch writes:
Junio C Hamano gits...@pobox.com 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
On Fri, Nov 22, 2013 at 6:26 PM, Jeff King p...@peff.net 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
On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano gits...@pobox.com 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
Vicent Martí tan...@gmail.com writes:
On Fri, Nov 22, 2013 at 8:36 PM, Junio C Hamano gits...@pobox.com 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
Vicent Marti vic...@github.com writes:
On Fri, Nov 22, 2013 at 6:26 PM, Jeff King p...@peff.net 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
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 are trying
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
- Neither of
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 the
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 it
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 potentially
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 only one
Jeff King p...@peff.net 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
gits...@pobox.com wrote on Thu, 21 Nov 2013 11:47 -0800:
Crestez Dan Leonard cdleon...@gmail.com 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:
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?
Thanks,
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 the
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 were not all
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 hvo...@hvoigt.net
---
This
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 21 | grep open
open(/etc/ld.so.cache, O_RDONLY|O_CLOEXEC) = 3
Jens Lehmann wrote:
But the question is if that is the right thing to do: should
diff.ignoreSubmodules and submodule.name.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. But
55 matches
Mail list logo
