* Re: stgit 0.13 + git 1.5.3.5 bogus "empty patch" status, and other problems
From: Catalin Marinas @ 2007-11-15 16:37 UTC (permalink / raw)
To: Adam J. Richter; +Cc: git
In-Reply-To: <200711120039.lAC0dgex015049@freya.yggdrasil.com>
On 12/11/2007, Adam J. Richter <adam@yggdrasil.com> wrote:
> So, did repeated "stg pop" commands to get to the point where
> the change to parser.y is applied, did an "stg new", deleted
> y.tab.{c,h}, did "stg rm y.tab.{c,h}" and "stg refresh". So far, so
> good. Then I tried to do an "stg push" to re-integrate the next
> patch, and I got a complaint from stgit about some git object not
> existing. This patch did not touch y.tab.{c,h} or any files touched
> by any of the other patches I had pushed on.
I don't know the exact error but are you sure that changes to
y.tab.{c,h} are not involuntarily included in other patches?
> I don't know stgit well
> enough to recover from the situation gracefully, so I just wiped the
> stgit tree and tried to apply the patches again, which brings me to
> bug #2.
If the error is a conflict, 'stg push --undo' should revert the pushed
patch to its previous state. Otherwise, fix the conflict and run 'stg
refresh'.
> I made a new stgit tree of the program (bash), pulling from a
> local git tree, and attempted to apply the first patch, with usuaul
> "stg new...make changes...stg refresh". Then stg refresh informed
> printed this message ("invalid_multibyte_sequence" is the name of the
> new patch):
>
> Checking for changes in the working directory ... done
> Refreshing patch "invalid_multibyte_sequence" ... done (empty patch)
>
> "stg diff" still shows the changes as if I had not done an
> "stg refresh". Obviously, stg commits have worked for me in the past.
> I suspect that a recent upgrade of git or other system software
> triggered the break.
I haven't seen this type of error before. There might be some
inconsistency between the HEAD and the index. Can you try
'git-read-tree HEAD' and run 'stg refresh' afterwards?
You might also want to try the latest StGIT snapshot. It should be
pretty stable as we are preparing it for a 0.14 release.
--
Catalin
^ permalink raw reply
* Re: [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too
From: Johannes Schindelin @ 2007-11-15 16:37 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0711151611090.30886@racer.site>
Hi,
On Thu, 15 Nov 2007, Johannes Schindelin wrote:
>
> Earlier, builtin commit would implicitly commit also the staged
> changes.
>
> This patch fixes that.
This was only lightly tested. Alas, there is still a subtle bug... the
generated "Untracked/Staged/ToBeCommitted" list seems off. I guess we'd
have to reread the index after resetting it to HEAD and adding the files,
but before generating that commit message.
Ciao,
Dscho
^ permalink raw reply
* Re: How to change a submodue as a subdirectory?
From: Ping Yin @ 2007-11-15 16:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711151322590.16728@wbgn129.biozentrum.uni-wuerzburg.de>
On Nov 15, 2007 8:28 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > 1. move submodule subB outside
> > mv subB /newpath/to/subB
> > git-commit subB
>
> Strictly speaking, you do not have to move it outside.
Hmm, you're right. I can just just remove it after fetch subB as a
branch of superA.
>
> > 2. git-filter-branch to rename all files in subA repository to subB
> > directory (say subB/subB).
> >
> > cd newpath/to/subB &&
> > git filter-branch --index-filter \
> > 'git ls-files -s | sed "s-\t-&subB/-" |
> > GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
> > git update-index --index-info &&
> > mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
>
> No need to play games with GIT_INDEX_FILE, as far as I can tell.
I just follow the example of git-filter-branch manual page. If not
using GIT_INDEX_FILE.new, the GIT_INDEX_FILE will be read and wirtten
at the same time since it is read and writtern at the same in a pipe.
Will this be ok?
>
> > 3. in directory of super project superA, git-fetch repository subB to
> > branch subB
> > cd path/to/superA && git-fetch /newpath/to/subB master:subB
>
> If you plan to do away with subB, you do not need to specify it... Just
> use FETCH_HEAD, directly after the fetch.
Hmm, using FETCH_HEAD is really better.
> The git-cherry call is not really necessary, right? The two repos have no
> common history (not even common patches).
>
> Besides, I think that what you did is just a complicated way of doing a
> rebase.
I tried rebase, wonderful!
>
> Ciao,
> Dscho
>
>
--
Ping Yin
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show submodule commit summary
From: Ping Yin @ 2007-11-15 16:49 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <8c5c35580711120947s246f192coa3796ac6541a28d7@mail.gmail.com>
On Nov 13, 2007 1:47 AM, Lars Hjemli <hjemli@gmail.com> wrote:
> On Nov 12, 2007 5:45 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > Ping Yin schrieb:
> > > On Nov 12, 2007 11:59 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> > >
> > >> But at this time git-commit is about to be made a builtin, and since your
> > >> implementation contains a lot of non-portable constructs ($'', >&) and a new
> > >> dependency on awk (and, hence, has little chances of being accepted), I
> > >> suggest that you stay tuned, and implement this in the forth-coming
> > >> builtin-commit.c.
> > > Implement this in shell scripts is just a piece of cake, but not so
> > > easy in builtin-commit.c.
> >
> > I'm with you. But git-commit.sh is a dead horse, no matter how hard you beat it.
> >
> > BTW, maybe you can keep the log generation in a helper script,
> > git-status--submodulesummary, and invoke that from builtin-commit.c. This
> > way you get both: integration and ease of implementation.
>
> Sorry for repeating myself, but IMVHO this belong in git-submodule.sh:
> It can be useful as a standalone command, we get all submodule-related
> commands isolated in a single place, and builtin-commit.c can of
> course exec git-submodule to get the summary.
>
OK. I'll reconsider it and reimplement it when i have time.
--
Ping Yin
^ permalink raw reply
* Re: [PATCH] builtin-commit: fix "git add x y && git commit y" committing x, too
From: Kristian Høgsberg @ 2007-11-15 17:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0711151611090.30886@racer.site>
On Thu, 2007-11-15 at 16:11 +0000, Johannes Schindelin wrote:
> Earlier, builtin commit would implicitly commit also the staged
> changes.
>
> This patch fixes that.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> The function reset_index_to_head() could be moved to somewhere
> more central and be reused in builtin-reset.c instead of
> reset_index_file() later...
>
> builtin-add.c | 1 +
> builtin-commit.c | 30 +++++++++++++++++++++++++++++-
> t/t7500-commit.sh | 10 ++++++++++
> 3 files changed, 40 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-add.c b/builtin-add.c
> index 77dcde6..017c8f2 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> @@ -100,6 +100,7 @@ static void update_callback(struct diff_queue_struct *q,
> case DIFF_STATUS_UNMERGED:
> case DIFF_STATUS_MODIFIED:
> case DIFF_STATUS_TYPE_CHANGED:
> + case DIFF_STATUS_ADDED:
> add_file_to_cache(path, verbose);
> break;
> case DIFF_STATUS_DELETED:
> diff --git a/builtin-commit.c b/builtin-commit.c
> index 535039c..0dc6e1c 100644
> --- a/builtin-commit.c
> +++ b/builtin-commit.c
> @@ -19,6 +19,7 @@
> #include "strbuf.h"
> #include "utf8.h"
> #include "parse-options.h"
> +#include "unpack-trees.h"
>
> static const char * const builtin_commit_usage[] = {
> "git-commit [options] [--] <filepattern>...",
> @@ -77,6 +78,31 @@ static struct option builtin_commit_options[] = {
> OPT_END()
> };
>
> +static int reset_index_to_head(void)
> +{
> + struct unpack_trees_options opts;
> + struct tree_desc tree_desc;
> + struct tree *tree;
> + unsigned char sha1[20];
> +
> + /* ignore if it is an initial commit */
> + if (get_sha1("HEAD", sha1))
> + return 0;
> + tree = parse_tree_indirect(sha1);
> + if (!tree || parse_tree(tree))
> + return error("Could not get HEAD's tree");
> + init_tree_desc(&tree_desc, tree->buffer, tree->size);
> +
> + memset(&opts, 0, sizeof(opts));
> + opts.index_only = 1;
> + opts.merge = 1;
> + opts.head_idx = 1;
> + opts.fn = oneway_merge;
> + if (unpack_trees(1, &tree_desc, &opts))
> + return error("Could not reset temporary index to HEAD");
> + return 0;
> +}
> +
> static char *prepare_index(const char **files, const char *prefix)
> {
> int fd;
> @@ -120,12 +146,14 @@ static char *prepare_index(const char **files, const char *prefix)
> die("failed to read HEAD tree object");
> }
>
> + if (reset_index_to_head())
> + die ("failed to reset temporary index to HEAD");
> +
If you look just above where you added these lines, there is code to
deal with this case, except it doesn't work. I was trying to fix this
too by adding a discard_cache() call before building the temp index, but
then I couldn't add the files in question because the index was now
newer than those files. Anyway, I don't know if your code is better
that just doing read_tree(), but we should only have one or the other in
there.
Kristian
^ permalink raw reply
* [PATCH] rehabilitate some t5302 tests on 32-bit off_t machines
From: Nicolas Pitre @ 2007-11-15 17:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
Commit 8ed2fca458d085f12c3c6808ef4ddab6aa40ef14 was a bit draconian in
skipping certain tests which should be perfectly valid even on platform
with a 32-bit off_t.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
index d93abc4..2a2878b 100755
--- a/t/t5302-pack-index.sh
+++ b/t/t5302-pack-index.sh
@@ -129,17 +129,15 @@ test_expect_failure \
'[index v1] 6) newly created pack is BAD !' \
'git verify-pack -v "test-4-${pack1}.pack"'
-test "$have_64bits" &&
test_expect_success \
'[index v2] 1) stream pack to repository' \
'rm -f .git/objects/pack/* &&
- git-index-pack --index-version=2,0x40000 --stdin < "test-1-${pack1}.pack" &&
+ git-index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git prune-packed &&
git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
- cmp "test-3-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"'
+ cmp "test-2-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"'
-test "$have_64bits" &&
test_expect_success \
'[index v2] 2) create a stealth corruption in a delta base reference' \
'# this test assumes a delta smaller than 16 bytes at the end of the pack
@@ -152,17 +150,14 @@ test_expect_success \
bs=1 count=20 conv=notrunc &&
git cat-file blob "$delta_sha1" > blob_4 )'
-test "$have_64bits" &&
test_expect_failure \
'[index v2] 3) corrupted delta happily returned wrong data' \
'cmp blob_3 blob_4'
-test "$have_64bits" &&
test_expect_failure \
'[index v2] 4) confirm that the pack is actually corrupted' \
'git fsck --full $commit'
-test "$have_64bits" &&
test_expect_failure \
'[index v2] 5) pack-objects refuses to reuse corrupted data' \
'git pack-objects test-5 <obj-list'
Nicolas
^ permalink raw reply related
* Re: git-clean won't read global ignore
From: Junio C Hamano @ 2007-11-15 17:27 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Pierre Habouzit, shunichi fuji, git
In-Reply-To: <vpqbq9vlt3k.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> At last, I'll be able to write
>
> $ git ls-files -o --exclude-standard >> .gitignore
> $ $EDITOR .gitignore
I think this is a good cookbook material to put somewhere in the
docs.
^ permalink raw reply
* Re: Problem in our test setup
From: Junio C Hamano @ 2007-11-15 17:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711151237400.16728@wbgn129.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Funnily enough, it _is_ the non-dash form that I replaced. What happens
> is this: the git wrapper looks for a builtin named 'runstatus', does not
> find it, then calls out for something like 'git-runstatus', which is found
> in my $HOME/bin.
Yes, but at that point we know we are looking for "git"
subcommand not general command on PATH, so we can only look for
"git-runstatus" in the git_exec_path (initialized by $GIT_EXEC_PATH
or compiled-in) and correctly fail during the test.
^ permalink raw reply
* Re: [PATCH] git-branch --with=commit
From: Jan Hudec @ 2007-11-15 17:27 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <4732D440.2020504@op5.se>
[-- Attachment #1: Type: text/plain, Size: 1144 bytes --]
On Thu, Nov 08, 2007 at 10:17:52 +0100, Andreas Ericsson wrote:
> Junio C Hamano wrote:
>> Johannes Sixt <j.sixt@viscovery.net> writes:
>>
>>> Junio C Hamano schrieb:
>>
>>>> With this patch, I could do this to find out which topic
>>>> branches already contain the faulty commit:
>>>>
>>>> $ git branch --with=maint^ | grep /
>>>> xx/maint-fix-foo
>>> It'd be helpful if you could construct the example in this commit
>>> message such that you don't need the "grep /" here; otherwise, the
>>> reader doesn't know which part of the effect is hidden by the grep.
>>
>> Yeah, in the example sequence, I think only maint itself and
>> xx/maint-fix-foo are shown, so there is no need for grep.
>
> And "maint" could certainly be stripped by the code itself, since the
> user can reasonably be expected to know that plain maint will have
> everything maint^ has.
DWIDNS (Do what I did not say).
Normally one would expect 'git branch --with=maint^' and
'git branch --with=$(git ref-parse maint^)' to be exactly the same. Alas,
with your suggestion, they would not.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [Discussion] cherry-picking a merge
From: Junio C Hamano @ 2007-11-15 17:40 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071115081648.GK14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> When you think about it, as long as the topological relationship
>> between A and B is very similar to that of C and B (iow,
>> "merge-base A B" and "merge-base C B" are the same), the effect
>> should be the same as a real merge between B and C, shouldn't it?
>>
>> ---o---o---C---A---M
>> \ \ /
>> o---o---\---B
>> \ \
>> `---X
>>
>> I am wondering if it makes sense to record the result of
>> "cherry-pick -m" as a real merge between the current HEAD and
>> all the other parents of the cherry-picked merge except the one
>> that is named with the <parent-number>.
>
> Yes.
Actually, this turns to be a trick question ;-)
If there was an accidental clean merge between A and B, and a
part of the duplicated same changes in the accidental clean
merge sits between C and A, replaying the difference from A to M
on top of C would not yield the same result as merging B into C.
^ permalink raw reply
* Re: git-clean won't read global ignore
From: Matthieu Moy @ 2007-11-15 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, shunichi fuji, git
In-Reply-To: <7v7ikj5shd.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> At last, I'll be able to write
>>
>> $ git ls-files -o --exclude-standard >> .gitignore
>> $ $EDITOR .gitignore
>
> I think this is a good cookbook material to put somewhere in the
> docs.
Here it is:
http://git.or.cz/gitwiki/GitTips?action=diff&rev2=217&rev1=216
== How to ignore files which are "Untracked" now? ==
{{{
$ git ls-files -o --exclude-standard >> .gitignore
$ $EDITOR .gitignore
}}}
(note : `--exclude-standard` is not yet in a released version of git
as of november 2007, you'll have to use `--exclude-from=.gitignore
--exclude-from=.git/info/exclude ...` if you don't have it).
--
Matthieu
^ permalink raw reply
* Re: [StGit RFC] A more structured way of calling git
From: Catalin Marinas @ 2007-11-15 18:28 UTC (permalink / raw)
To: Karl Hasselström; +Cc: David Kågedal, Git Mailing List, Yann Dirson
In-Reply-To: <20071026192418.GA19774@diana.vm.bytemark.co.uk>
On 26/10/2007, Karl Hasselström <kha@treskal.com> wrote:
> I wanted to build an StGit command that coalesced adjacent patches to
> a single patch. Because the end result tree would still be the same,
> this should be doable without ever involving HEAD, the index, or the
> worktree. StGit's existing infrastructure for manipulating patches
> didn't lend itself to doing this kind of thing, though: it's not
> modular enough. So I started to design a replacement low-level
> interface to git, and things got slightly out of hand ... and I ended
> up with a much bigger refactoring than I'd planned.
I eventually managed to have a (not so in-depth) look at this and I am
OK with it (but merging after 0.14). As you said the current structure
and the new one will work in parallel for some time. It would even be
possible to implement unit testing.
Some random comments below:
Commitdata maybe should be written as CommitData (as in the e-mail text).
The Repository.head property is not cached and it is probably OK to
avoid some problems I had. We could run profiling afterwards to see
how often it is called.
> Transactions (translib.py)
> ----------------------------------------------------------------------
>
> I started to implement a few StGit commands on top of gitlib.py and
> stacklib.py, and then realized something very appealing:
>
> Just about every StGit command can be accomplished by first creating
> a bunch of new commit objects with gitlib.py, then trying to check
> out the new HEAD, and then rewriting refs with stacklib.py. Only the
> first and second steps can possibly fail, and if they do, they do so
> without leaving any user-visible junk behind. This can be used to
> make all commands either succeed completely, or do nothing at all.
As you said, that's a bit difficult for 'push' as it is made of a
series of separate individual patch pushes. Can we not use a temporary
index by setting GIT_INDEX_FILE during the whole transaction and
freely update the working copy. Only if the transaction fails, we
clean the working copy and check out the default index? This might
slow down some operations though.
In the future, it would be nice to record the stack state before
transactions in a git object (via pickle) together with HEAD id and
provide unlimited undo.
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
From: Johannes Sixt @ 2007-11-15 18:31 UTC (permalink / raw)
To: git; +Cc: Steffen Prohaska, Junio C Hamano
In-Reply-To: <9D2813B9-8E86-4551-94BF-2B04F5FBB141@zib.de>
On Thursday 15 November 2007 07:53, Steffen Prohaska wrote:
> Now I'm wondering if we could make path relocation a bit more
> explicit. How about doing something like.
>
> system_wide = relocate_path(ETC_GITCONFIG);
>
> and relocate_path(const char *) would expand a format
> string in path. At this point I see only a single %s
> that would be expanded with the install prefix. If
> ETC_GITCONFIG is "%s/etc/gitconfig" relocate path will return
> "C:/msysgit/bin/etc/gitconfig" for my above example. It is
> basically a printf with the install prefix path.
I don't see the problem that you are trying to solve.
-- Hannes
^ permalink raw reply
* Re: [PATCH] rehabilitate some t5302 tests on 32-bit off_t machines
From: Johannes Sixt @ 2007-11-15 18:38 UTC (permalink / raw)
To: git; +Cc: Nicolas Pitre, Junio C Hamano
In-Reply-To: <alpine.LFD.0.9999.0711151211330.21255@xanadu.home>
On Thursday 15 November 2007 18:24, Nicolas Pitre wrote:
> Commit 8ed2fca458d085f12c3c6808ef4ddab6aa40ef14 was a bit draconian in
> skipping certain tests which should be perfectly valid even on platform
> with a 32-bit off_t.
>
> Signed-off-by: Nicolas Pitre <nico@cam.org>
> ---
> diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
> index d93abc4..2a2878b 100755
> --- a/t/t5302-pack-index.sh
> +++ b/t/t5302-pack-index.sh
> @@ -129,17 +129,15 @@ test_expect_failure \
> '[index v1] 6) newly created pack is BAD !' \
> 'git verify-pack -v "test-4-${pack1}.pack"'
>
> -test "$have_64bits" &&
> test_expect_success \
> '[index v2] 1) stream pack to repository' \
> 'rm -f .git/objects/pack/* &&
> - git-index-pack --index-version=2,0x40000 --stdin
< "test-1-${pack1}.pack" &&
> + git-index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
git prune-packed &&
> git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
> cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
> - cmp "test-3-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"'
> + cmp "test-2-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"'
Since you changed this test, I assume that the remaining tests that you put
back failed only because this one did something wrong. If so, please mention
that in the commit message.
-- Hannes
^ permalink raw reply
* Re: [PATCH] rehabilitate some t5302 tests on 32-bit off_t machines
From: Nicolas Pitre @ 2007-11-15 18:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <200711151938.29617.johannes.sixt@telecom.at>
On Thu, 15 Nov 2007, Johannes Sixt wrote:
> On Thursday 15 November 2007 18:24, Nicolas Pitre wrote:
> > Commit 8ed2fca458d085f12c3c6808ef4ddab6aa40ef14 was a bit draconian in
> > skipping certain tests which should be perfectly valid even on platform
> > with a 32-bit off_t.
> >
> > Signed-off-by: Nicolas Pitre <nico@cam.org>
> > ---
> > diff --git a/t/t5302-pack-index.sh b/t/t5302-pack-index.sh
> > index d93abc4..2a2878b 100755
> > --- a/t/t5302-pack-index.sh
> > +++ b/t/t5302-pack-index.sh
> > @@ -129,17 +129,15 @@ test_expect_failure \
> > '[index v1] 6) newly created pack is BAD !' \
> > 'git verify-pack -v "test-4-${pack1}.pack"'
> >
> > -test "$have_64bits" &&
> > test_expect_success \
> > '[index v2] 1) stream pack to repository' \
> > 'rm -f .git/objects/pack/* &&
> > - git-index-pack --index-version=2,0x40000 --stdin
> < "test-1-${pack1}.pack" &&
> > + git-index-pack --index-version=2 --stdin < "test-1-${pack1}.pack" &&
> git prune-packed &&
> > git count-objects | ( read nr rest && test "$nr" -eq 1 ) &&
> > cmp "test-1-${pack1}.pack" ".git/objects/pack/pack-${pack1}.pack" &&
> > - cmp "test-3-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"'
> > + cmp "test-2-${pack1}.idx" ".git/objects/pack/pack-${pack1}.idx"'
>
> Since you changed this test, I assume that the remaining tests that you put
> back failed only because this one did something wrong. If so, please mention
> that in the commit message.
It did nothing wrong. It was simply relying on the product of a
previous test that might still be disabled.
Nicolas
^ permalink raw reply
* Re: Odd .gitignore behaviour
From: Linus Torvalds @ 2007-11-15 18:56 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git
In-Reply-To: <80ir431xny.fsf@tiny.isode.net>
On Thu, 15 Nov 2007, Bruce Stephens wrote:
>
> So surely sub1/sub2/foo ought to be included again? Or is the first
> line in sub1/.gitignore not "a previous pattern" in this sense?
Yes.
The negated patterns have to show up *before* the patterns that they
override, because the first pattern that matches is the one that is used.
> If I move the "foo" pattern up a level, creating a .gitignore in base
> just containing "foo", then sub1/sub2/foo is still regarded as
> ignored, even though it surely matches the negating pattern
> sub1/.gitignore, and that should be of higher precedence than the
> pattern in base/.gitignore?
The priority between nested .gitignore files should be that inner files
have higher priority than outer files (since the inner ones "know more",
and the outer ones are "generic").
So what you describe sounds wrong.
But my quick test didn't actually support the behaviour you see. In this
situation:
[torvalds@woody git-test]$ cat .gitignore
a*
[torvalds@woody git-test]$ cat subdir/.gitignore
!a-ok
[torvalds@woody git-test]$ find *
all-files
subdir
subdir/a-ok
[torvalds@woody git-test]$ git ls-files -o --exclude-per-directory=.gitignore
.gitignore
subdir/.gitignore
subdir/a-ok
ie we *do* show "showdir/a-ok" (but we don't show "all-files") because
a-ok is explicitly marked to be not ignored by a higher-priority rule.
Side note: "git status" uses the "--directory" flag, so it will not even
recurse into unknown directories, and will instead apply the gitignore
rules to the directory names, so you get:
[torvalds@woody git-test]$ git ls-files -o --exclude-per-directory=.gitignore --directory
.gitignore
subdir/
which doesn't show "a-ok", but that's for a totally unrelated reason and
has nothing to do with .gitignore!
Linus
^ permalink raw reply
* Re: [PATCH] rehabilitate some t5302 tests on 32-bit off_t machines
From: Junio C Hamano @ 2007-11-15 19:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Johannes Sixt, git
In-Reply-To: <alpine.LFD.0.9999.0711151349480.21255@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Thu, 15 Nov 2007, Johannes Sixt wrote:
>
>> Since you changed this test, I assume that the remaining
>> tests that you put back failed only because this one did
>> something wrong. If so, please mention that in the commit
>> message.
>
> It did nothing wrong. It was simply relying on the product of
> a previous test that might still be disabled.
Thanks for a fix-up and clarification. Hannes, otherwise this
passed in your environment?
^ permalink raw reply
* Re: refining .gitignores
From: Alex Riesen @ 2007-11-15 19:26 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git
In-Reply-To: <807ikj3fge.fsf@tiny.isode.net>
Bruce Stephens, Thu, Nov 15, 2007 12:39:45 +0100:
> Alex Riesen <raa.lkml@gmail.com> writes:
> > Bruce Stephens, Wed, Nov 14, 2007 23:36:06 +0100:
> >> How do I get a list of files (in HEAD, say) that would be ignored by
> >> the .gitignore files (and the other usual settings)?
> >>
> >> It feels like something like this ought to work:
> >>
> >> git ls-files -z | xargs -0 git ls-files --ignored
> >>
> >> But listing its arguments that are ignored by .gitignore (etc.)
> >> doesn't seem to be what "git ls-files --ignored" does. Or at least,
> >> not quite as straightforwardly as that.
> >
> > git ls-files --exclude-per-directory=.gitignore -X .git/info/exclude -i -o
>
> That doesn't seem to work.
>
> For example, if I add '*.c' to .gitignores in git.git, I can't seem to
> get that command to display any .c files.
.gitignore? Without "s"?
Maybe your .c files are already added to index? Otherwise you have to
use the second form. It shows known-to-Git ignored files.
> Run on its own, it displays lots of files, but no .c files. Run with
> an argument (such as builtin-add.c), it displays nothing.
because the *are* in the index. "-o" means "others", as in "not Git".
> >> The motivation is (obviously) that I fear some of the .gitignore
> >> patterns are too broad, and a reasonable check is that none of the
> >> files that are already committed would be caught by the patterns.
> >
> > git ls-files --exclude-per-directory=.gitignore -X .git/info/exclude -i
>
> That also doesn't seem to do quite what I want, and probably in the
> same way. ...
It shows ignored files from the "known-to-Git" fileset.
^ permalink raw reply
* Re: [PATCH] rehabilitate some t5302 tests on 32-bit off_t machines
From: Johannes Sixt @ 2007-11-15 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <7vsl3749hp.fsf@gitster.siamese.dyndns.org>
On Thursday 15 November 2007 20:03, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
> > On Thu, 15 Nov 2007, Johannes Sixt wrote:
> >> Since you changed this test, I assume that the remaining
> >> tests that you put back failed only because this one did
> >> something wrong. If so, please mention that in the commit
> >> message.
> >
> > It did nothing wrong. It was simply relying on the product of
> > a previous test that might still be disabled.
>
> Thanks for a fix-up and clarification. Hannes, otherwise this
> passed in your environment?
Yes, it passes. Ack.
-- Hannes
^ permalink raw reply
* Re: [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
From: Steffen Prohaska @ 2007-11-15 20:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <200711151931.29029.johannes.sixt@telecom.at>
On Nov 15, 2007, at 7:31 PM, Johannes Sixt wrote:
> On Thursday 15 November 2007 07:53, Steffen Prohaska wrote:
>> Now I'm wondering if we could make path relocation a bit more
>> explicit. How about doing something like.
>>
>> system_wide = relocate_path(ETC_GITCONFIG);
>>
>> and relocate_path(const char *) would expand a format
>> string in path. At this point I see only a single %s
>> that would be expanded with the install prefix. If
>> ETC_GITCONFIG is "%s/etc/gitconfig" relocate path will return
>> "C:/msysgit/bin/etc/gitconfig" for my above example. It is
>> basically a printf with the install prefix path.
>
> I don't see the problem that you are trying to solve.
Path relocation would be more explicit:
1) Paths that need to be relocated are filtered through
relocate_path(). That's easy to understand.
2) All the code prefixing the path is in relocate_path().
This avoids code duplication.
3) Path that should be relocated contain "%s" in the Makefile.
This indicates that some string expansion may take place.
(1) and (2) would be useful even if you do not agree with (3).
The code in PATCH 9/11 and PATCH 11/11 looks very similar.
If the prefixing code went into a separate function, we'd
have less code. Also, relocate_path() could be useful at
other places. For example, I'd use it to locate the HTML
documentation relative to the installation directory.
Steffen
^ permalink raw reply
* Re: Odd .gitignore behaviour
From: Bruce Stephens @ 2007-11-15 20:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0711151044150.2786@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
[...]
> So what you describe sounds wrong.
>
> But my quick test didn't actually support the behaviour you see. In this
> situation:
>
> [torvalds@woody git-test]$ cat .gitignore
> a*
> [torvalds@woody git-test]$ cat subdir/.gitignore
> !a-ok
> [torvalds@woody git-test]$ find *
> all-files
> subdir
> subdir/a-ok
> [torvalds@woody git-test]$ git ls-files -o --exclude-per-directory=.gitignore
> .gitignore
> subdir/.gitignore
> subdir/a-ok
>
> ie we *do* show "showdir/a-ok" (but we don't show "all-files") because
> a-ok is explicitly marked to be not ignored by a higher-priority rule.
OK, and if I say "git add subdir/a-ok" I get no error, as expected.
So extend it just a tiny bit, moving a-ok down a directory and using
the negative pattern "!subsubdir/a-ok" to match:
brs% cat .gitignore
a*
brs% cat subdir/.gitignore
!subsubdir/a-ok
brs% find *
all-files
subdir
subdir/.gitignore
subdir/subsubdir
subdir/subsubdir/a-ok
subdir/a-ok
brs% git ls-files -o --exclude-per-directory=.gitignore
.gitignore
subdir/.gitignore
subdir/subsubdir/a-ok
brs% git add subdir/subsubdir/a-ok
The following paths are ignored by one of your .gitignore files:
subdir/subsubdir/a-ok
Use -f if you really want to add them.
fatal: no files added
So I think the output from git-ls-files is as expected (as I interpret
the manpage and your explanation). So is git-add just using some
different code?
[...]
^ permalink raw reply
* Re: refining .gitignores
From: Bruce Stephens @ 2007-11-15 20:28 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20071115192654.GA3552@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
[...]
> .gitignore? Without "s"?
Yes, my mistake. I added '*.c' to ".gitignore".
> Maybe your .c files are already added to index? Otherwise you have to
> use the second form. It shows known-to-Git ignored files.
They are in the index. What I want is a list of files which are known
to git, which are matched by the default rules (in particular the
.gitignore files).
So that should be this?
git ls-files --exclude-per-directory=.gitignore -i
But that shows nothing at all, and it still shows nothing if I add a
"builtin-add.c" as an argument to it (this file exists, and is in the
index).
"git add builtin-add.c" fails, complaining (correctly) that the path
is ignored by one of my .gitignore files.
We're obviously talking past one another somehow, or I have a broken
build of git?
[...]
^ permalink raw reply
* Re: refining .gitignores
From: Linus Torvalds @ 2007-11-15 20:40 UTC (permalink / raw)
To: Bruce Stephens; +Cc: Alex Riesen, git
In-Reply-To: <80ejerdzjd.fsf@tiny.isode.net>
On Thu, 15 Nov 2007, Bruce Stephens wrote:
>
> They are in the index. What I want is a list of files which are known
> to git, which are matched by the default rules (in particular the
> .gitignore files).
Ahh.
*All* the .gitignore rules are purely about files that git does not
already know about. Once git tracks a pathname, the ignore rules simply
do not matter.
Files that are in the index are simply never ignored. There's no way to
ignore them, and in fact, the whole "git add -f" thing is a way to add
files to the index and override the exclude rules - at which point git
then tracks them regardless of any such exclude rules.
Linus
^ permalink raw reply
* [PATCH] Add test that checks diverse aspects of updating remote and tracking branches
From: Alex Riesen @ 2007-11-15 20:46 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20071115042625.GA10094@sigill.intra.peff.net>
Because we haven't settled on what the exit status from
"git push" command itself should be in such a partial
failure case, do not check the exit status from it for
now.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
Jeff King, Thu, Nov 15, 2007 05:26:26 +0100:
> On Tue, Nov 13, 2007 at 06:10:48PM -0500, Jeff King wrote:
>
> > > This one is on top of what is in next. It also include the check for
> > > deleting remote braches I sent before. Regarding this one: if a remote
> > > branch is deleted, shouldn't the matching tracking branch be removed
> > > as well? The code in master seem to do that.
> >
> > Yes, it should (the code in update_tracking_ref seems to handle that
> > case, but I haven't tested, so I may have bungled something). I am
> > literally walking out the door, now, though, so I will be out of touch
> > for at least a day.
>
> After I became disconnected, I looked at my 'next', and the reason for
> the failure to delete the ref seems to be your is_null_sha1
> error-checking patch, which Junio put in next. But maybe you have
> figured that out in the intervening time. :)
I didn't. But Junio already has all your patches in pu, so I activated
the deletion test and rebased it on top of your patches in his tree
(jk/send-pack, according to merge commit). Tried: works.
t/t5404-tracking-branches.sh | 28 +++++++++++++++++++++++++---
1 files changed, 25 insertions(+), 3 deletions(-)
diff --git a/t/t5404-tracking-branches.sh b/t/t5404-tracking-branches.sh
index 20718d4..a6f60ac 100755
--- a/t/t5404-tracking-branches.sh
+++ b/t/t5404-tracking-branches.sh
@@ -10,6 +10,7 @@ test_expect_success 'setup' '
git commit -m 1 &&
git branch b1 &&
git branch b2 &&
+ git branch b3 &&
git clone . aa &&
git checkout b1 &&
echo b1 >>file &&
@@ -19,10 +20,13 @@ test_expect_success 'setup' '
git commit -a -m b2
'
+start_dir="$(pwd)"
+
test_expect_success 'check tracking branches updated correctly after push' '
cd aa &&
b1=$(git rev-parse origin/b1) &&
b2=$(git rev-parse origin/b2) &&
+ b3=$(git rev-parse origin/b3) &&
git checkout -b b1 origin/b1 &&
echo aa-b1 >>file &&
git commit -a -m aa-b1 &&
@@ -32,9 +36,27 @@ test_expect_success 'check tracking branches updated correctly after push' '
git checkout master &&
echo aa-master >>file &&
git commit -a -m aa-master &&
- git push &&
- test "$(git rev-parse origin/b1)" = "$b1" &&
- test "$(git rev-parse origin/b2)" = "$b2"
+ {
+ git push
+ test "$(git rev-parse origin/b1)" = "$b1" &&
+ test "$(git rev-parse origin/b2)" = "$b2" &&
+ test "$(git rev-parse origin/b3)" = "$b3" &&
+ test "$(git rev-parse origin/master)" = \
+ "$(git rev-parse master)"
+ }
+'
+
+test_expect_success 'delete remote branch' '
+ git push origin :refs/heads/b3
+ {
+ git rev-parse --verify origin/b3
+ test $? != 0
+ } &&
+ cd "$start_dir" &&
+ {
+ git rev-parse refs/heads/b3
+ test $? != 0
+ }
'
test_done
--
1.5.3.5.692.ge1737
^ permalink raw reply related
* Re: refining .gitignores
From: Bruce Stephens @ 2007-11-15 21:13 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, git
In-Reply-To: <alpine.LFD.0.9999.0711151237550.4260@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 15 Nov 2007, Bruce Stephens wrote:
>>
>> They are in the index. What I want is a list of files which are known
>> to git, which are matched by the default rules (in particular the
>> .gitignore files).
>
> Ahh.
>
> *All* the .gitignore rules are purely about files that git does not
> already know about. Once git tracks a pathname, the ignore rules simply
> do not matter.
>
> Files that are in the index are simply never ignored. There's no way to
> ignore them, and in fact, the whole "git add -f" thing is a way to add
> files to the index and override the exclude rules - at which point git
> then tracks them regardless of any such exclude rules.
OK. I think I sort of understood that, but it's nice to have it
clearly stated.
I'm not worried so much about files that already exist. I'm worried
that we may in the future create files that we want to store in git
and which are ignored. If we do that there's a chance we'll miss them
(because "git gui", "git status", etc., won't bring attention to
them).
So it seemed valuable to try to make the .gitignore patterns precise:
so that they ignore all the generated files that our builds produce,
while not matching any files that git knows about.
That certainly wouldn't guarantee that new files wouldn't be caught by
the patterns, but it ought to lower the probability of this, since
there's a decent chance that such files will either be not touched by
the patterns (because they're *.java or something), or they'll fit
into one of the already handled exceptions (Doxyfile.local is one:
most *.local files are build products, but Doxyfile.local aren't).
I guess if you're starting off with some project in git then this
isn't such an issue: you evolve the patterns and the build process and
so on in parallel. So maybe there's not such a demand for finding
this information, and those of us who do want to do it are best using
the "git add" loop approach?
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox