* Re: The shared Git repo used by git-new-workdir
From: Holger Hellmuth @ 2012-01-16 19:15 UTC (permalink / raw)
To: Hilco Wijbenga; +Cc: Git Users
In-Reply-To: <CAE1pOi3JocCoDGAmpCYdGdJN4E1nz8O4_i0MtLhwhP_axmH-uw@mail.gmail.com>
On 16.01.2012 19:57, Hilco Wijbenga wrote:
> In my working directory:
> hilco@centaur /mnt/lacie/workspaces/my-project-master
> my-project-master (master $ u=)$ git status
> # On branch master
> nothing to commit (working directory clean)
>
> In the shared repo:
> hilco@centaur ~/git-clones/my-project my-project (master +$ u=)$ git status
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD<file>..." to unstage)
> #
> # deleted: .gitattributes
> # modified: .gitignore
> # new file: ...
> ... hundreds more ...
This is related to your using two repos with the same branch
(irrespective of root repo or not).
There is nothing wrong with that per se, but if you add/commit/merge etc
in one of those two, the working directory and index of the other repo
doesn't get updated automatically. You would have to do "git reset
--hard" in that repo to get it up-to-date
If you want to avoid this just don't check out the same branch in any
two repos, root or not.
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Thomas Rast @ 2012-01-16 19:17 UTC (permalink / raw)
To: Yves Goergen; +Cc: Holger Hellmuth, git, Jeff King, Carlos Martín Nieto
In-Reply-To: <4F14718B.80209@unclassified.de>
Yves Goergen <nospam.list@unclassified.de> writes:
> It's getting more weird. I believe that (msys)Git doesn't really know
> how the filesystem on its operating system works. I have made some more
> changes now and want to commit them. TortoiseGit reports the files
> Form1.Designer.cs and Form1.designer.cs (note the case difference) as
> modified and ready to commit. How is that supposed to work?
Depends.
If you work together with developers who have a case-sensitive FS (such
as Linux, or with the right options OS X), it's entirely possible that
this file exists in both spellings within the repository.
Otherwise, because Git needs to have the ability to store such
spellings, there are some ways of introducing them (e.g.,
git-update-index).
I suspect the adoption rate of TortoiseGit across this list is about 0%,
partly because it is a Windows-only tool, partly because it was written
almost entirely without interacting with the Git list. So speaking in
TortoiseGit terms here will most likely get you nowhere.
> If the index is such a problem child, how can I safely delete it
> completely and maybe have it regenerated if Git can't live without it?
The index is not only, as its name might imply, a throw-away cache. It
is also used as the area where you prepare the contents of the next
commit, and thus might hold data you do not want to lose. Nevertheless,
you can discard and reset it to the contents of HEAD with
rm -f .git/index
git reset
> Great, I have the same file with an equal name twice in my repository
> (with 'git ls-files').
>
> How stupid! Git, go learn file names.
Please cut&paste (!) actual command invocations (!) and outputs.
To see why this is important, consider
"I have the same file with an equal name twice in my repository"
Judging by how this thread is going, there are at least four ways this
could be interpreted:
* You have the byte-for-byte identical file name listed twice in the
index. That would be a pretty bad bug.
* Ditto, but in a commit.
* You have two filenames in the index that differ only by case, which
makes them identical to your OS.
* Ditto, but in a commit.
See what I mean?
So please, let's be precise. You could start by cut&pasting the outputs
of the following commands:
git ls-tree -r HEAD
git ls-files --debug
git status -s
Otherwise, you can keep throwing around fuzzy complaints all you want
but nobody will be able to help you because we cannot determine the
exact state that your repository is in.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH] test_interactive: interactive debugging in test scripts
From: Jens Lehmann @ 2012-01-16 20:01 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Jeff King, Git Mailing List, Junio C Hamano
In-Reply-To: <20120116154953.GA21238@padd.com>
Am 16.01.2012 16:49, schrieb Pete Wyckoff:
> Between mine and Jens' there is hopefully something widely useful
> here.
Just while I was planning a v2 and thought about renaming "test_bash"
to "test_interactive", let it take a command to run as optional
argument and document it better you came up with this :-)
So I vote for your patch as it takes my initial idea even further. I
really like that HOME, TERM and SHELL are honored in your version
leaving the user with a fully functional shell of his choice.
^ permalink raw reply
* Re: [PATCH] test_interactive: interactive debugging in test scripts
From: Jeff King @ 2012-01-16 20:11 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Pete Wyckoff, Git Mailing List, Junio C Hamano
In-Reply-To: <4F148211.70106@web.de>
On Mon, Jan 16, 2012 at 09:01:21PM +0100, Jens Lehmann wrote:
> So I vote for your patch as it takes my initial idea even further. I
> really like that HOME, TERM and SHELL are honored in your version
> leaving the user with a fully functional shell of his choice.
I'm actually mildly negative on this feature, as it interferes with the
tests themselves. Probably TERM and SHELL don't matter. But $HOME means
git will read your personal .gitconfig, not any config (or lack thereof)
in the trash directory.
I've personally been left head-scratching in the past by:
$ ./tXXXX-foo -v -i
...
expecting success: git foo
not ok - 1 git foo
$ cd trash\ directory.tXXXX-foo
$ git foo ;# and it works!
where the culprit was a non-clean environment caused by my personal git
config (or very occasionally, something else in $HOME).
-Peff
^ permalink raw reply
* Re: [PATCH] test_interactive: interactive debugging in test scripts
From: Jeff King @ 2012-01-16 20:19 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Jens Lehmann, Git Mailing List, Junio C Hamano
In-Reply-To: <20120116154953.GA21238@padd.com>
On Mon, Jan 16, 2012 at 10:49:53AM -0500, Pete Wyckoff wrote:
> And it is necessary to export any test variables you want to use
> in the debug shell. I often cut-n-paste lines containing
> TEST_DIRECTORY and TRASH_DIRECTORY; there could be others,
> in test scripts and helper libraries too.
Yeah, exporting a few common ones would be helpful. I really wish there
was a way to ask a shell to stop running the script and start doing
interactive things in the current shell context, but no such thing
exists AFAIK (you can hack it with a read-eval loop, but you are missing
many of the useful input-handling bits like tab completion. Hmm, I
wonder if bash's "read -e" would be enough, though).
I kind of wonder if that is over-engineering, though. I'd like a perfect
debugging environment, but the fact of the matter is that writing,
maintaining, and making it work in every case that comes up is probably
a lot more work than just fiddling with the scripts now and then. This
code isn't even meant to be run except in such fiddling circumstances.
> While it would be nice to use:
>
> test_interactive gdb --args git ...
>
> the path is setup to invoke the script in bin-wrappers/git,
> requiring either --with-dashes or something like
>
> test_interactive gdb --args "$GIT_EXEC_PATH"/git ...
Yeah. I have before patched the bin-wrappers script to accept a
GIT_WRAPPER_PREFIX variable, so you can just set that and have it run
gdb on your invocation. But even that's not enough for externals. I've
been tempted to actually carry around a run-time option to exec
externals via gdb, but I didn't want to pollute the regular code base
(and you can usually get by with just running "gdb git-foo" directly).
-Peff
^ permalink raw reply
* Re: Simulating an empty git repository without having said repository on disk
From: Jeff King @ 2012-01-16 20:41 UTC (permalink / raw)
To: Richard Hartmann; +Cc: Git List
In-Reply-To: <CAD77+gR=txp8sKrA57ztQX0a1-QZM7wwR6ThBq77c=c+AbsS0w@mail.gmail.com>
On Mon, Jan 16, 2012 at 07:34:04PM +0100, Richard Hartmann wrote:
> for vcsh[1], I need a rather hackish feature: List all files untracked
> by vcsh. The plan to achieve this is:
>
> Get lists of all files by all repos which' GIT_WORK_TREE is in one
> directory ($HOME, by default), merge all lists into one and use that
> as a .gitignore or exclude. Then run `git status` with $GIT_WORK_TREE
> pointing to $HOME while using said ignore/exclude. That will give me a
> list of all files & directories which are not tracked by any of the
> git repos managed by vcsh.
I don't use vcsh, but I seem to recall that it works by overlaying the
working trees of different repositories on each other, right? So you
can't just say "oh, files in foo/ belong to repository 'bar'". You must
take the union of the set of tracked files from all repos, then find the
difference of that from the set of all files.
Can individual repos mark things as excluded, too? Or do you have a
master exclusion list? I.e., if I decide that I don't want "foo" tracked
at all, how do I tell vcsh?
> I could create an empty git repo to run this operation in, but that
> seems wasteful. Thus, I would prefer to run this command against a
> non-existing, empty git repo. Problem is, I could not find a way to do
> this.
>
> I know the empty tree's SHA is hard-coded into git so I was hoping
> there would be a way to trick git using this, but I couldn't find a
> way.
I'm not sure why you care about the empty tree if you are only looking
at untracked files. Or perhaps the problem is that you are using "git
status", which fundamentally cares about looking at differences between
HEAD and the index, even though you don't care in this case. In that case,
maybe "git ls-files -o" would be more appropriate?
The most straightforward way in git would be to generate a temporary
index that mentions all of the tracked files, like this:
tmp=/some/tmp/index
rm -f $tmp
for i in repo; do
git --git-dir=$repo ls-files -z |
GIT_INDEX_FILE=$tmp xargs -0 git update-index --add
done
GIT_INDEX_FILE=$tmp git ls-files -o
but that is very close to your "create an empty git repo" (in fact, you
might even need to in order for update-index to be happy). But it would
give you a place to put a master exclusion list (you would use it as
--exclude=... in the final ls-files).
If you have per-repo exclusion lists, then you could take a different
approach, and simply run "git ls-files -o" for each repository. Any
files which appeared in _every_ output would be untracked (since tracked
files or individually-excluded files would be omitted from at least one
repo). Like:
# get the list of untracked files from each repo's perspective
count=0
for i in repo; do
count=$(($count + 1))
git --git-dir=$repo ls-files -o
done >output
# now count how many times each entry appears. Truly untracked things
# appear $count times.
sort <output |
uniq -c |
perl -lne "/^\s*$count (.*)/ and print \$1"
The downside is that you are doing $count traversals of the untracked
directories. On an OS with a reasonable lstat and a directory structure
that fits into cache, that is probably not too big a deal, though.
> Any and all help appreciated, even if it's just a "no, this is not possible"
I took a lot of guesses at exactly what you want. It might be more clear
if you gave us an example situation along with the output you expect.
-Peff
^ permalink raw reply
* Re: [PATCH] test_interactive: interactive debugging in test scripts
From: Jens Lehmann @ 2012-01-16 20:48 UTC (permalink / raw)
To: Jeff King; +Cc: Pete Wyckoff, Git Mailing List, Junio C Hamano
In-Reply-To: <20120116201123.GA18699@sigill.intra.peff.net>
Am 16.01.2012 21:11, schrieb Jeff King:
> On Mon, Jan 16, 2012 at 09:01:21PM +0100, Jens Lehmann wrote:
>
>> So I vote for your patch as it takes my initial idea even further. I
>> really like that HOME, TERM and SHELL are honored in your version
>> leaving the user with a fully functional shell of his choice.
>
> I'm actually mildly negative on this feature, as it interferes with the
> tests themselves. Probably TERM and SHELL don't matter. But $HOME means
> git will read your personal .gitconfig, not any config (or lack thereof)
> in the trash directory.
Good point, I haven't thought of that ... so yes, at least $HOME should
go.
^ permalink raw reply
* Bug in git svn fetch
From: Chris Cinelli @ 2012-01-16 21:04 UTC (permalink / raw)
To: git
In-Reply-To: <CAM1GFk0bXTC2YUigJnB2wa4EKHOJ8oO8Sk=8+dApqkXH2_SP+Q@mail.gmail.com>
We are trying to move from SVN to GIT but we are having problems
git --version
git version 1.7.9.rc1
I updated because I had the same problem also with version 1.7.5 (just
different line number)
Running command: git svn fetch
Found possible branch point: http://our_server/svn/FUL/trunk =>
http://our_server/svn/FUL/tags/2011_11_26_1223AM, 822
Use of uninitialized value $u in substitution (s///) at
/usr/libexec/git-core/git-svn line 2097.
Use of uninitialized value $u in concatenation (.) or string at
/usr/libexec/git-core/git-svn line 2097.
refs/remotes/svn/trunk: 'http://our_server/svn/FUL' not found in ''
The folder tags/2011_11_26_1223AM was created with SVN copy. It may
also be deleted and recreated above with the same name.
I hope it is an easy fix.
Best,
Chris
--Everything should be made as simple as possible, but not simpler
(Albert Einstein)
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Erik Faye-Lund @ 2012-01-16 21:18 UTC (permalink / raw)
To: Yves Goergen; +Cc: Holger Hellmuth, git, Jeff King, Carlos Martín Nieto
In-Reply-To: <4F14718B.80209@unclassified.de>
On Mon, Jan 16, 2012 at 7:50 PM, Yves Goergen
<nospam.list@unclassified.de> wrote:
> It's getting more weird. I believe that (msys)Git doesn't really know
> how the filesystem on its operating system works.
Git for Windows know how the file-system works, and tries to prevent
you from shooting yourself in the leg by being case-insensitive when
matching the index and the working copy. But there is an opt-out for
this, which is controlled by the configuration option core.ignorecase,
which Peff already asked about. This option is supposed to be enabled
by default on Windows.
What you are describing sounds like that option might have gotten
disabled somehow. But it might be something else, see below.
> I have made some more
> changes now and want to commit them. TortoiseGit reports the files
> Form1.Designer.cs and Form1.designer.cs (note the case difference) as
> modified and ready to commit. How is that supposed to work?
Very speculative comment: This might be a bug in TortoiseGit. Looking
at the sources, it seems they are using libgit2 to mess around with
the index; perhaps it's case-sensitivity code isn't as well tested as
Git for Windows'?
For instance, they do their own index and tree sorting, in an attempt
to be case sensitive:
http://code.google.com/p/tortoisegit/source/diff?spec=svnf151c0ddf205fa1fc1ff886b8cfc4af87d373b26&r=f151c0ddf205fa1fc1ff886b8cfc4af87d373b26&format=side&path=/src/Git/GitIndex.cpp
^ permalink raw reply
* Re: Cannot push a commit
From: Jeff King @ 2012-01-16 21:20 UTC (permalink / raw)
To: Matthias Fechner; +Cc: git
In-Reply-To: <4F1297E0.1060703@fechner.net>
On Sun, Jan 15, 2012 at 10:09:52AM +0100, Matthias Fechner wrote:
> git.exe push --progress "origin" master:master
>
> Counting objects: 4, done.
> Compressing objects: 100% (3/3)
> Writing objects: 100% (3/3), 80.00 KiB | 137 KiB/s
> Writing objects: 100% (3/3), 91.63 KiB | 137 KiB/s, done.
> Total 3 (delta 0), reused 0 (delta 0)
> fatal: early EOF
> error: unpack failed: unpack-objects abnormal exit
> To idefix@fechner.net:git-test
> ! [remote rejected] master -> master (n/a (unpacker error))
> error: failed to push some refs to 'idefix@fechner.net:git-test'
Odd. The unpacking process on the other end claims that it didn't get
the whole input (it knows how much to expect based on the earlier parts
of what is sent) . Yet the connection is still going (because we see the
error messages coming from the remote), so it wasn't simply that the
connection was dropped. So either:
1. Something in the connection cut out but only in a half-duplex way.
I guess I could see ssh doing that if its input pipe closed, but
that would mean the local pack-objects failed, and I believe git
already detects and reports that case.
2. The packfile sent indicated that it should have more bytes than it
does (i.e., either git indicated there were more objects than there
actually are, or zlib failed to give a stream-end marker in the
middle of an object). This is one of:
a. A bug in git or zlib.
b. Something in the connection corrupting the data (e.g., a
transport that is not 8-bit clean).
But in either 2a or 2b, I would expect us to have seen this before, and
I don't recall seeing anything like it.
You could try generating a bundle with this pack, like:
git bundle create foo.bundle master ^origin/master
and then shipping the resulting foo.bundle to the other side, and
pulling from it like:
git pull /path/to/foo.bundle master
That should use (roughly) the same pack generation code as the
push, but avoid the transport. If it works, then it's either a problem
with the transport, or there is something really subtle going on
inside git.
If it does fail, then that will be a much easier case to repeat and
diagnose from there.
-Peff
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-16 21:20 UTC (permalink / raw)
To: Jeff King; +Cc: Holger Hellmuth, git, Carlos Martín Nieto
In-Reply-To: <20120116190956.GA13802@sigill.intra.peff.net>
On 16.01.2012 20:09 CE(S)T, Jeff King wrote:
> What is the output of "git config core.ignorecase" in your repository?
None, i.e. an empty line.
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Jeff King @ 2012-01-16 21:27 UTC (permalink / raw)
To: Yves Goergen; +Cc: Holger Hellmuth, git, Carlos Martín Nieto
In-Reply-To: <4F1494AA.1000004@unclassified.de>
On Mon, Jan 16, 2012 at 10:20:42PM +0100, Yves Goergen wrote:
> On 16.01.2012 20:09 CE(S)T, Jeff King wrote:
> > What is the output of "git config core.ignorecase" in your repository?
>
> None, i.e. an empty line.
That's odd. When the repository is first created, git will do a test to
see whether the filesystem supports case-sensitivity, and will set
core.ignorecase if it does not. Might this repository have been created
on a different filesystem, and then moved onto the case-insensitive
filesystem?
Or might it have been created by something other than core git? I don't
know whether one can create a repo in TortoiseGit, or if so how it does
so.
In any case, try doing:
git config core.ignorecase true
and see if that clears up your problems.
-Peff
^ permalink raw reply
* Re: Bug in git svn fetch
From: Chris Cinelli @ 2012-01-16 21:29 UTC (permalink / raw)
To: git
In-Reply-To: <CAM1GFk2zioi10M4HjyOF3a8_Ec23V9URPAAnRzp4xABSjKxZ+g@mail.gmail.com>
More details:
The previous commands were (I am using svn2git):
git svn init --prefix=svn/ --username=chris --no-metadata
--trunk=trunk --tags=tags --branches=branches
http://our_server/svn/FL/trunk/
git config --local svn.authorsfile authors_file
The process failed before using http://our_server/svn/FL (instead of
http://our_server/svn/FL/trunk)
We are not sure but it is very likely that on SVN we did a SVN copy,
then and SVN delete and again an SVN copy on the same folder.
I hope this help.
Best,
Chris
http://www.mail-archive.com/git@vger.kernel.org/
On Mon, Jan 16, 2012 at 1:04 PM, Chris Cinelli
<chris.cinelli@formativelearning.com> wrote:
> We are trying to move from SVN to GIT but we are having problems
>
> git --version
> git version 1.7.9.rc1
>
> I updated because I had the same problem also with version 1.7.5 (just
> different line number)
>
> Running command: git svn fetch
> Found possible branch point: http://our_server/svn/FUL/trunk =>
> http://our_server/svn/FUL/tags/2011_11_26_1223AM, 822
> Use of uninitialized value $u in substitution (s///) at
> /usr/libexec/git-core/git-svn line 2097.
> Use of uninitialized value $u in concatenation (.) or string at
> /usr/libexec/git-core/git-svn line 2097.
> refs/remotes/svn/trunk: 'http://our_server/svn/FUL' not found in ''
>
> The folder tags/2011_11_26_1223AM was created with SVN copy. It may
> also be deleted and recreated above with the same name.
>
> I hope it is an easy fix.
>
> Best,
> Chris
>
> --Everything should be made as simple as possible, but not simpler
> (Albert Einstein)
--
--Everything should be made as simple as possible, but not simpler
(Albert Einstein)
^ permalink raw reply
* Re: [PATCH] test_interactive: interactive debugging in test scripts
From: Pete Wyckoff @ 2012-01-16 22:07 UTC (permalink / raw)
To: Jens Lehmann; +Cc: Jeff King, Git Mailing List, Junio C Hamano
In-Reply-To: <4F148D3B.4070206@web.de>
Jens.Lehmann@web.de wrote on Mon, 16 Jan 2012 21:48 +0100:
> Am 16.01.2012 21:11, schrieb Jeff King:
> > On Mon, Jan 16, 2012 at 09:01:21PM +0100, Jens Lehmann wrote:
> >
> >> So I vote for your patch as it takes my initial idea even further. I
> >> really like that HOME, TERM and SHELL are honored in your version
> >> leaving the user with a fully functional shell of his choice.
> >
> > I'm actually mildly negative on this feature, as it interferes with the
> > tests themselves. Probably TERM and SHELL don't matter. But $HOME means
> > git will read your personal .gitconfig, not any config (or lack thereof)
> > in the trash directory.
>
> Good point, I haven't thought of that ... so yes, at least $HOME should
> go.
I, too, have stumbled over differences that are due to picking up
something in $HOME. It takes a minute to realize what's going
on.
TERM can interfere with at least one test: c2116a1 (test-lib: fix TERM
to dumb for test repeatability, 2008-03-06). SHELL can cause
issues when it is more feature-ful than SHELL_PATH.
On the other hand, it's frustrating to work in an environment
without my shell aliases, git aliases, readline customizations,
personal path, and assorted environment variables.
I'm comfortable with the (rare?) possibility of confusion. But
perhaps it is unwise to support a feature with so many caveats,
even if it is only for debugging.
-- Pete
^ permalink raw reply
* Re: [PATCH v2 2/2] tree_entry_interesting: make recursive mode default
From: Junio C Hamano @ 2012-01-16 22:15 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git, Jonathan Nieder, Linus Torvalds
In-Reply-To: <20120115100327.GA10735@do>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> On Sat, Jan 14, 2012 at 07:12:03PM -0800, Junio C Hamano wrote:
>> That makes my head hurt and makes me suspect there is something
>> fundamentally wrong in the patch. Sigh...
>
> I'll need to think about it. In the meantime perhaps the following
> bandage patch would suffice, rather than revert 2f88c19 (diff-index:
> pass pathspec down to unpack-trees machinery)
Yeah, the logic of this correction is very clear. Because diff_cache is
about walking a flat index, the "recursive pathspec" that allows us to
look into deeper levels in directory hierarchy should be set, and also we
should not be limiting the depth of the match in any way by setting the
max_depth to "unlimited".
Thanks.
> -- 8< --
> Subject: [PATCH] diff-index: enable recursive pathspec matching in unpack_trees
>
> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
> ---
> diff-lib.c | 2 ++
> t/t4010-diff-pathspec.sh | 8 ++++++++
> 2 files changed, 10 insertions(+), 0 deletions(-)
>
> diff --git a/diff-lib.c b/diff-lib.c
> index 62f4cd9..fc0dff3 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -469,6 +469,8 @@ static int diff_cache(struct rev_info *revs,
> opts.src_index = &the_index;
> opts.dst_index = NULL;
> opts.pathspec = &revs->diffopt.pathspec;
> + opts.pathspec->recursive = 1;
> + opts.pathspec->max_depth = -1;
>
> init_tree_desc(&t, tree->buffer, tree->size);
> return unpack_trees(1, &t, &opts);
> diff --git a/t/t4010-diff-pathspec.sh b/t/t4010-diff-pathspec.sh
> index fbc8cd8..af5134b 100755
> --- a/t/t4010-diff-pathspec.sh
> +++ b/t/t4010-diff-pathspec.sh
> @@ -48,6 +48,14 @@ test_expect_success \
> compare_diff_raw current expected'
>
> cat >expected <<\EOF
> +:100644 100644 766498d93a4b06057a8e49d23f4068f1170ff38f 0a41e115ab61be0328a19b29f18cdcb49338d516 M path1/file1
> +EOF
> +test_expect_success \
> + '"*file1" should show path1/file1' \
> + 'git diff-index --cached $tree -- "*file1" >current &&
> + compare_diff_raw current expected'
> +
> +cat >expected <<\EOF
> :100644 100644 766498d93a4b06057a8e49d23f4068f1170ff38f 0a41e115ab61be0328a19b29f18cdcb49338d516 M file0
> EOF
> test_expect_success \
> --
> 1.7.8.36.g69ee2
>
> -- 8< --
^ permalink raw reply
* Re: git grep doesn't follow symbolic link
From: Junio C Hamano @ 2012-01-16 22:44 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Pang Yan Han, Thomas Rast, Ramkumar Ramachandra, Bertrand BENOIT,
git
In-Reply-To: <CACsJy8CaBAEJo_LuvjYhb2kfofH83cbR5DFDffmmCU3uJFqk+g@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> It's not wrong per se. It's an implication that users have to take
> when they choose to use it. We may help make it clear that the
> symlinks point to untracked files by putting some indication in the
> diff.
>
> When I do "git log -Sfoo -- '*.cxx'" I don't really care if bar.cxx is
> a symlink. Neither does my compiler. It may be a symlink's target
> change that makes "foo" appear. Git could help me detect that quickly
> instead of sticking with tracked contents only.
As there is nothing in Git that tells that whatever is pointed at by
bar.cxx that happens to be in your filesystem today had "foo" in it when
that historical version of the commit whose bar.cxx symlink was updated to
point to that file. It is *WRONG* to show the commit as something that
changes bar.cxx to contain "foo" (or more precisely, changes the count of
"foo" in it).
Why is it so hard to understand?
^ permalink raw reply
* Re: [PATCH] bash-completion: don't add quoted space for ZSH (fix regression)
From: Junio C Hamano @ 2012-01-16 22:47 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqhazv3m17.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> but is that the right thing to do if suffix came from "$4"?
>>
>> As far as I can see, "$4" is used to append "." in very limited cases, and
>> nobody explicitly passes SP as "$4" when calling this, so it may be easier
>> to read if you moved this before that "if we have 3 or more args, use the
>> fourth one as the suffix" block, i.e. something like this?
>
> Why not, but in case someone explicitely passes " " as $4 in the future,
> it's likely to be better to strip it for the same reason we strip it here.
I doubt that would be sufficent or appropriate. If some caller _WANTS_ to
add a SP, shouldn't we be devising a way to tell zsh to add it without
quoting, instead of silently stripping?
> I don't care much either way in this case.
>
>> + # Because we use '-o nospace' under bash, we need to compensate
>> + # for it by appending SP after completed word ourselves.
>> + local suffix="${BASH_VERSION+ }"
>
> Not sure why you reworded the comment, but I don't think it's a good
> idea to remove the "ZSH would quote the trailing space added with -S"
> that I had added, because this is really the reason we do a special case
> here. Your version is misleading, because we use -o nospace for ZSH too.
Ok, use of "-o nospace" in Zsh is what I missed. I thought the issue was
about the nospace emulation.
So does that mean we would be forcing zsh users to add SP themselves? I
wonder if we can do better than that.
^ permalink raw reply
* Re: Signed tags in octopus merge..
From: Junio C Hamano @ 2012-01-16 22:49 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <CA+55aFzRN2F5PZDZPRmbj9occZwA6E6Pi+S+M_Qq2EfS6sctyA@mail.gmail.com>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Just a heads-up and congrats: octopus merges of signed tags work well,
> and did exactly the RightThing(tm), both at merge time and with
> "--show-signature".
>
> I knew it was supposed to work, but I have to admit that I was a bit
> apprehensive about it when I tried.
>
> Current top-of-head (commit 81d48f0aee54) in the kernel, in case you care.
I looked at it again, and it makes me wonder if we should further reword
it to say "side branch #1, tagged 'devicetree-for-linus'" instead of the
current "parent #2, tagged 'devicetree-for-linus'". It looks very weird to
start counting from #2, when we know we will never show #1 there.
^ permalink raw reply
* Re: [PATCH] test-lib: add the test_bash convenience function
From: Junio C Hamano @ 2012-01-16 22:51 UTC (permalink / raw)
To: Jeff King; +Cc: Jens Lehmann, Git Mailing List
In-Reply-To: <20120115232413.GA14724@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Nice. Many times I have added such a "bash" or "gdb" invocation then
> forgotten "-v", only to scratch my head at why the test seemed to be
> hanging.
>
> Two minor nits on the patch itself:
> ...
> 1. It may be worth putting a warning in the comment that this is never
> to be used in a real test, but only temporarily inserted.
>
> 2. I do this not just with bash, but with "gdb". I wonder if it is worth
> making this "test_foo bash", for some value of "foo" (the ones that
> occur to me are "debug" and "run", but of course they are taken).
>
> Actually, I wonder if the existing test_debug could handle this
> already (though you do have to remember to add "--debug" to your
> command line, then).
I wondered the same thing from a different angle. My first reaction was
"Why is this called 'bash' not 'sh'?" which naturally led to the same
direction as yours "why not an arbitrary command 'test_debug xxx'?"
test_pause perhaps?
^ permalink raw reply
* Re: Signed tags in octopus merge..
From: Jacob Helwig @ 2012-01-16 22:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Git Mailing List
In-Reply-To: <7vobu3uusw.fsf@alter.siamese.dyndns.org>
On Mon, Jan 16, 2012 at 2:49 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> Just a heads-up and congrats: octopus merges of signed tags work well,
>> and did exactly the RightThing(tm), both at merge time and with
>> "--show-signature".
>>
>> I knew it was supposed to work, but I have to admit that I was a bit
>> apprehensive about it when I tried.
>>
>> Current top-of-head (commit 81d48f0aee54) in the kernel, in case you care.
>
> I looked at it again, and it makes me wonder if we should further reword
> it to say "side branch #1, tagged 'devicetree-for-linus'" instead of the
> current "parent #2, tagged 'devicetree-for-linus'". It looks very weird to
> start counting from #2, when we know we will never show #1 there.
>
My immediate thought regarding the "side branch #1" version is not
wanting to have to do the math (even though it's a simple n+1), if I
decide to convert that text into ^ parent selection notation.
--
Jacob Helwig
http://technosorcery.net/about/me
^ permalink raw reply
* Re: Signed tags in octopus merge..
From: Linus Torvalds @ 2012-01-16 23:06 UTC (permalink / raw)
To: Jacob Helwig; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <CAJ8aY1Hi47uyYSjAmtXfDEqgyc8T21WqXdEA0kGS7SQKxQ5b5g@mail.gmail.com>
On Mon, Jan 16, 2012 at 2:58 PM, Jacob Helwig <jacob@technosorcery.net> wrote:
>
> My immediate thought regarding the "side branch #1" version is not
> wanting to have to do the math (even though it's a simple n+1)
"Math is hard, let's go shopping".
But I think even barbie could do the "add one" thing. That said, I
think the current thing is already more than good enough, and I don't
think it's at all confusing to talk about "parent #2". In fact, I
think it's more obvious than "side branch #1".
Linus
^ permalink raw reply
* Re: Simulating an empty git repository without having said repository on disk
From: Richard Hartmann @ 2012-01-16 23:09 UTC (permalink / raw)
To: Jeff King; +Cc: Git List
In-Reply-To: <20120116204131.GC18699@sigill.intra.peff.net>
On Mon, Jan 16, 2012 at 21:41, Jeff King <peff@peff.net> wrote:
> I don't use vcsh, but I seem to recall that it works by overlaying the
> working trees of different repositories on each other, right?
In parallel, but yes.
> So you
> can't just say "oh, files in foo/ belong to repository 'bar'". You must
> take the union of the set of tracked files from all repos, then find the
> difference of that from the set of all files.
Correct.
> Can individual repos mark things as excluded, too? Or do you have a
> master exclusion list? I.e., if I decide that I don't want "foo" tracked
> at all, how do I tell vcsh?
That's something I am still contemplating as there are several ways:
* excludes
* pre-/appends to the gitignore of every repo
* runtime magic
Feedback welcome :)
> I'm not sure why you care about the empty tree if you are only looking
> at untracked files. Or perhaps the problem is that you are using "git
> status", which fundamentally cares about looking at differences between
> HEAD and the index, even though you don't care in this case. In that case,
> maybe "git ls-files -o" would be more appropriate?
--others does not work as I need to look at several repos. I tried to
get the union of --others, but that creates 'argument too large' very
quickly.
Initially, I tried with find, but as that is depth-first, it takes
ages when compared to git's early stopping at directories.
> The most straightforward way in git would be to generate a temporary
> index that mentions all of the tracked files, like this:
>
> tmp=/some/tmp/index
> rm -f $tmp
> for i in repo; do
> git --git-dir=$repo ls-files -z |
> GIT_INDEX_FILE=$tmp xargs -0 git update-index --add
> done
> GIT_INDEX_FILE=$tmp git ls-files -o
>
> but that is very close to your "create an empty git repo" (in fact, you
> might even need to in order for update-index to be happy). But it would
> give you a place to put a master exclusion list (you would use it as
> --exclude=... in the final ls-files).
>
> If you have per-repo exclusion lists, then you could take a different
> approach, and simply run "git ls-files -o" for each repository. Any
> files which appeared in _every_ output would be untracked (since tracked
> files or individually-excluded files would be omitted from at least one
> repo). Like:
See above, but I will try yours as well.
> perl -lne "/^\s*$count (.*)/ and print \$1"
I know I sound picky, but I would also like to avoid any third-party
dependencies if possible. Perl is common, but not installed
everywhere.
> The downside is that you are doing $count traversals of the untracked
> directories. On an OS with a reasonable lstat and a directory structure
> that fits into cache, that is probably not too big a deal, though.
With cold cache, it can take ages. Especially once you have a few
git-annex repos in $HOME.
> I took a lot of guesses at exactly what you want. It might be more clear
> if you gave us an example situation along with the output you expect.
repo foo tracks .foo and .foo.d, bar .bar, etc
% vcsh list #lists repos
foo
bar
baz
% ls -aR
.foo
.foo.d/
.bar
.baz.d/
.quux.d/
.quux.d/foo
.quux.d/quux.d/quux
.quux.d/quux.d/quuux
.quux.d/quux.d/quuuux
.quux.d/quuuux.d/quuuux
pants
shirts
% vcsh run foo git ls-files # run command in context of repo foo
.foo
.foo.d
.quux.d/foo
% vcsh list-untracked # with the code I want in it
.quux.d/quux.d/
.quux.d/quuuux.d/
pants
shirts
%
I hope that makes sense.
The only part that does not already work today is list-untracked.
For failed attempts look at
https://github.com/RichiH/vcsh/tree/list-untracked
https://github.com/RichiH/vcsh/tree/list-untracked-2
Thanks,
Richard
^ permalink raw reply
* [PATCHv3 0/4] git-p4: small fixes to branches and labels
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
This is the third version of some small fixes to git-p4 branch and
label handling.
It was suggested for the earlier version that the author handling
could be simplified to use the 'author' variable. The code can
be simplified, but the author is the wrong value to use - it is
just the author of the commit, not the tag. Use the creator of the
label, or, if that does not exist ("p4 tag ..."), the p4 user.
This change does not fix the other problems with git-p4 labels:
- two p4 labels on the same changelist will fall over
- labels must match exactly the list of files imported
- you can't import a label without a p4 commit
Luke Diamand (4):
git-p4: handle p4 branches and labels containing shell chars
git-p4: cope with labels with empty descriptions
git-p4: importing labels should cope with missing owner
git-p4: add test for p4 labels
contrib/fast-import/git-p4 | 79 ++++++++++++++++++++----------------
t/t9803-git-p4-shell-metachars.sh | 48 ++++++++++++++++++++++
t/t9804-git-p4-label.sh | 73 ++++++++++++++++++++++++++++++++++
3 files changed, 165 insertions(+), 35 deletions(-)
create mode 100755 t/t9804-git-p4-label.sh
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply
* [PATCH 1/4] git-p4: handle p4 branches and labels containing shell chars
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-1-git-send-email-luke@diamand.org>
Don't use shell expansion when detecting branches, as it will
fail if the branch name contains a shell metachar. Similarly
for labels.
Add additional test for branches with shell metachars.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 8 +++---
t/t9803-git-p4-shell-metachars.sh | 48 +++++++++++++++++++++++++++++++++++++
2 files changed, 52 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 3e1aa27..822e6f1 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -799,7 +799,7 @@ class P4Submit(Command, P4UserMap):
def canChangeChangelists(self):
# check to see if we have p4 admin or super-user permissions, either of
# which are required to modify changelists.
- results = p4CmdList("protects %s" % self.depotPath)
+ results = p4CmdList(["protects", self.depotPath])
for r in results:
if r.has_key('perm'):
if r['perm'] == 'admin':
@@ -1758,7 +1758,7 @@ class P4Sync(Command, P4UserMap):
def getLabels(self):
self.labels = {}
- l = p4CmdList("labels %s..." % ' '.join (self.depotPaths))
+ l = p4CmdList(["labels", "%s..." % ' '.join (self.depotPaths)])
if len(l) > 0 and not self.silent:
print "Finding files belonging to labels in %s" % `self.depotPaths`
@@ -1800,7 +1800,7 @@ class P4Sync(Command, P4UserMap):
command = "branches"
for info in p4CmdList(command):
- details = p4Cmd("branch -o %s" % info["branch"])
+ details = p4Cmd(["branch", "-o", info["branch"]])
viewIdx = 0
while details.has_key("View%s" % viewIdx):
paths = details["View%s" % viewIdx].split(" ")
@@ -1938,7 +1938,7 @@ class P4Sync(Command, P4UserMap):
sourceRef = self.gitRefForBranch(sourceBranch)
#print "source " + sourceBranch
- branchParentChange = int(p4Cmd("changes -m 1 %s...@1,%s" % (sourceDepotPath, firstChange))["change"])
+ branchParentChange = int(p4Cmd(["changes", "-m", "1", "%s...@1,%s" % (sourceDepotPath, firstChange)])["change"])
#print "branch parent: %s" % branchParentChange
gitParent = self.gitCommitByP4Change(sourceRef, branchParentChange)
if len(gitParent) > 0:
diff --git a/t/t9803-git-p4-shell-metachars.sh b/t/t9803-git-p4-shell-metachars.sh
index db04375..db67020 100755
--- a/t/t9803-git-p4-shell-metachars.sh
+++ b/t/t9803-git-p4-shell-metachars.sh
@@ -57,6 +57,54 @@ test_expect_success 'deleting with shell metachars' '
)
'
+# Create a branch with a shell metachar in its name
+#
+# 1. //depot/main
+# 2. //depot/branch$3
+
+test_expect_success 'branch with shell char' '
+ test_when_finished cleanup_git &&
+ test_create_repo "$git" &&
+ (
+ cd "$cli" &&
+
+ mkdir -p main &&
+
+ echo f1 >main/f1 &&
+ p4 add main/f1 &&
+ p4 submit -d "main/f1" &&
+
+ p4 integrate //depot/main/... //depot/branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ echo f1 >branch\$3/shell_char_branch_file &&
+ p4 add branch\$3/shell_char_branch_file &&
+ p4 submit -d "branch\$3/shell_char_branch_file" &&
+
+ p4 branch -i <<-EOF &&
+ Branch: branch\$3
+ View: //depot/main/... //depot/branch\$3/...
+ EOF
+
+ p4 edit main/f1 &&
+ echo "a change" >> main/f1 &&
+ p4 submit -d "a change" main/f1 &&
+
+ p4 integrate -b branch\$3 &&
+ p4 resolve -am branch\$3/... &&
+ p4 submit -d "integrate main to branch\$3" &&
+
+ cd "$git" &&
+
+ git config git-p4.branchList main:branch\$3 &&
+ "$GITP4" clone --dest=. --detect-branches //depot@all &&
+ git log --all --graph --decorate --stat &&
+ git reset --hard p4/depot/branch\$3 &&
+ test -f shell_char_branch_file &&
+ test -f f1
+ )
+'
+
test_expect_success 'kill p4d' '
kill_p4d
'
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
* [PATCH 3/4] git-p4: importing labels should cope with missing owner
From: Luke Diamand @ 2012-01-16 23:14 UTC (permalink / raw)
To: git; +Cc: Pete Wyckoff, Luke Diamand
In-Reply-To: <1326755689-3344-1-git-send-email-luke@diamand.org>
In p4, the Owner field is optional. If it is missing,
construct something sensible rather than crashing.
Signed-off-by: Luke Diamand <luke@diamand.org>
---
contrib/fast-import/git-p4 | 63 ++++++++++++++++++++++++-------------------
1 files changed, 35 insertions(+), 28 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index f7707f2..efb2dad 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -563,6 +563,26 @@ class Command:
class P4UserMap:
def __init__(self):
self.userMapFromPerforceServer = False
+ self.myP4UserId = None
+
+ def p4UserId(self):
+ if self.myP4UserId:
+ return self.myP4UserId
+
+ results = p4CmdList("user -o")
+ for r in results:
+ if r.has_key('User'):
+ self.myP4UserId = r['User']
+ return r['User']
+ die("Could not find your p4 user id")
+
+ def p4UserIsMe(self, p4User):
+ # return True if the given p4 user is actually me
+ me = self.p4UserId()
+ if not p4User or p4User != me:
+ return False
+ else:
+ return True
def getUserCacheFilename(self):
home = os.environ.get("HOME", os.environ.get("USERPROFILE"))
@@ -700,7 +720,6 @@ class P4Submit(Command, P4UserMap):
self.verbose = False
self.preserveUser = gitConfig("git-p4.preserveUser").lower() == "true"
self.isWindows = (platform.system() == "Windows")
- self.myP4UserId = None
def check(self):
if len(p4CmdList("opened ...")) > 0:
@@ -808,25 +827,6 @@ class P4Submit(Command, P4UserMap):
return 1
return 0
- def p4UserId(self):
- if self.myP4UserId:
- return self.myP4UserId
-
- results = p4CmdList("user -o")
- for r in results:
- if r.has_key('User'):
- self.myP4UserId = r['User']
- return r['User']
- die("Could not find your p4 user id")
-
- def p4UserIsMe(self, p4User):
- # return True if the given p4 user is actually me
- me = self.p4UserId()
- if not p4User or p4User != me:
- return False
- else:
- return True
-
def prepareSubmitTemplate(self):
# remove lines in the Files section that show changes to files outside the depot path we're committing into
template = ""
@@ -1664,6 +1664,12 @@ class P4Sync(Command, P4UserMap):
if self.stream_file.has_key('depotFile'):
self.streamOneP4File(self.stream_file, self.stream_contents)
+ def make_email(self, userid):
+ if userid in self.users:
+ return self.users[userid]
+ else:
+ return "%s <a@b>" % userid
+
def commit(self, details, files, branch, branchPrefixes, parent = ""):
epoch = details["time"]
author = details["user"]
@@ -1687,10 +1693,7 @@ class P4Sync(Command, P4UserMap):
committer = ""
if author not in self.users:
self.getUserMapFromPerforceServer()
- if author in self.users:
- committer = "%s %s %s" % (self.users[author], epoch, self.tz)
- else:
- committer = "%s <a@b> %s %s" % (author, epoch, self.tz)
+ committer = "%s %s %s" % (self.make_email(author), epoch, self.tz)
self.gitStream.write("committer %s\n" % committer)
@@ -1735,11 +1738,15 @@ class P4Sync(Command, P4UserMap):
self.gitStream.write("from %s\n" % branch)
owner = labelDetails["Owner"]
- tagger = ""
- if author in self.users:
- tagger = "%s %s %s" % (self.users[owner], epoch, self.tz)
+
+ # Try to use the owner of the p4 label, or failing that,
+ # the current p4 user id.
+ if owner:
+ email = self.make_email(owner)
else:
- tagger = "%s <a@b> %s %s" % (owner, epoch, self.tz)
+ email = self.make_email(self.p4UserId())
+ tagger = "%s %s %s" % (email, epoch, self.tz)
+
self.gitStream.write("tagger %s\n" % tagger)
description = labelDetails["Description"]
--
1.7.8.rc1.209.geac91.dirty
^ permalink raw reply related
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