* Simulating an empty git repository without having said repository on disk
From: Richard Hartmann @ 2012-01-16 18:34 UTC (permalink / raw)
To: Git List
Hi all,
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 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.
Any and all help appreciated, even if it's just a "no, this is not possible"
Thanks,
Richard
[1] https://github.com/RichiH/vcsh
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-16 18:50 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: git, Jeff King, Carlos Martín Nieto
In-Reply-To: <4F1404E7.9040805@ira.uka.de>
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? On Windows,
file names are case-insensitive (as on MacOS X) and both names refer to
the absolute same file. 'git status' has the very same listing with that
same file twice.
What else is now broken in my repository?
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?
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: The shared Git repo used by git-new-workdir
From: Hilco Wijbenga @ 2012-01-16 18:57 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: Git Users
In-Reply-To: <4F1467C1.504@ira.uka.de>
On 16 January 2012 10:09, Holger Hellmuth <hellmuth@ira.uka.de> wrote:
> On 14.01.2012 21:59, Hilco Wijbenga wrote:
> Take a look at the rather simple script git-new-workdir (everything
> important happens in the last 20 lines). It just makes logical links to all
> files (mostly directories) under .git except three files that relate to the
> index (mainly the index file itself and HEAD)
Yes, I did that but I cannot figure out from that why I see lots of
files and such staged for commit on master when I almost never work on
master. I only use master to pull in upstream and to merge in one of
my branches and push. So unless I'm doing that, I would expect "git
status" to not output anything.
> That would suggest that normal git operations operating on files in those
> directories happen identical whether you are in the root repo or in any of
> the satellites. Only where the whole repo is acted upon (git clone, cp/rsync
> or deletion of the whole repo) the root repo would be "special".
That all makes sense to me and is what I was expecting. So why is "git
status" on master displaying anything?
Here is what I see:
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 ...
Is this related to my use of a symlink? I have a symlink
"~/workspaces" pointing to /mnt/lacie/workspaces/. Is that somehow
affecting things?
^ permalink raw reply
* Re: [PATCH 2/3] git-p4: Search for parent commit on branch creation
From: Pete Wyckoff @ 2012-01-16 18:57 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <1326674360-2771-3-git-send-email-vitor.hda@gmail.com>
vitor.hda@gmail.com wrote on Mon, 16 Jan 2012 00:39 +0000:
> To find out which is its parent the commit of the new branch is applied
> sequentially to each blob of the parent branch from the newest to the
> oldest. The first blob which results in a zero diff is considered the
> parent commit. If none is found, then the commit is applied to the top
> of the parent branch.
>
> A fast-import "checkpoint" call is required for each comparison because
> diff-tree is only able to work with blobs on disk. But most of these
> commits will not be part of the final imported tree, making fast-import
> fail. To avoid this, the temporary branches are tracked and then removed
> at the end of the import process.
This looks much better without the need for "--force". It'll be
great to fix this major branch detection problem. Can you make a
couple of further minor changes?
> diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
> @@ -2012,7 +2014,28 @@ class P4Sync(Command, P4UserMap):
> - self.commit(description, filesForCommit, branch, [branchPrefix], parent)
> + parentFound = 0
> + if len(parent) > 0:
> + self.checkpoint()
> + for blob in read_pipe_lines("git rev-list --reverse --no-merges %s" % parent):
> + blob = blob.strip()
> + tempBranch = self.tempBranchLocation + os.sep + "%d-%s" % (change, blob)
> + if self.verbose:
> + print "Creating temporary branch: " + tempBranch
> + self.commit(description, filesForCommit, tempBranch, [branchPrefix], blob)
> + self.tempBranches.append(tempBranch)
> + self.checkpoint()
> + if len( read_pipe("git diff-tree %s %s" % (blob, tempBranch)) ) == 0:
> + parentFound = 1
> + if self.verbose:
> + print "Found parent of %s in commit %s" % (branch, blob)
> + break
> + if parentFound:
> + self.commit(description, filesForCommit, branch, [branchPrefix], blob)
> + else:
> + if self.verbose:
> + print "Parent of %s not found. Committing into head of %s" % (branch, parent)
> + self.commit(description, filesForCommit, branch, [branchPrefix], parent)
1. Move the tempBranch commit outside of the "for blob" loop.
It can have no parent, and the diff-tree will still tell you
if you found the same contents. Instead of a ref for
each blob inspected for each change, you'll just have one ref
per change. Only one checkpoint() after the tempBranch
commit should be needed.
2. Nit. parentFound is boolean, use True/False, not 1/0.
> @@ -2347,6 +2370,12 @@ class P4Sync(Command, P4UserMap):
> + # Cleanup temporary branches created during import
> + if self.tempBranches != []:
> + for branch in self.tempBranches:
> + os.remove(".git" + os.sep + branch)
> + os.rmdir(".git" + os.sep + self.tempBranchLocation)
> +
3. Deleting refs should probably use "git update-ref -d"
just in case GIT_DIR is not ".git". I think you could just
leave the "git-p4-tmp" directory around, but use
os.environ["GIT_DIR"] instead of ".git" if you want to
delete it.
4. Paths are best manipulated with os.path.join(dir, file), to handle
weirdnesses like drive letters.
Eventually if the fast-import protocol learns to delete the refs
it creates, we can clean up a bit more nicely. I think there was
agreement this was a good idea, just needs someone to do it
sometime.
-- Pete
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Yves Goergen @ 2012-01-16 18:58 UTC (permalink / raw)
To: Holger Hellmuth; +Cc: git, Jeff King, Carlos Martín Nieto
In-Reply-To: <4F1404E7.9040805@ira.uka.de>
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.
I've read (and seen) bad things about Git and Windows, and I knew the
Great Failure Day would eventually come. And I've read that Mercurial
would be better suitable for Windows. You don't know anything about
that, do you?
--
Yves Goergen "LonelyPixel" <nospam.list@unclassified.de>
Visit my web laboratory at http://beta.unclassified.de
^ permalink raw reply
* Re: Cannot push a commit
From: Matthias Fechner @ 2012-01-16 18:59 UTC (permalink / raw)
To: git
In-Reply-To: <4F1297E0.1060703@fechner.net>
Am 15.01.2012 10:09, schrieb Matthias Fechner:
> Dear List,
>
> I have a big problem with a file which I cannot push to my central git
> repository.
> The file can be found here:
> http://dl.fechner.net/APP_UD.sch
where should I raise a bug report for this?
Bye
Matthias
^ permalink raw reply
* Re: Bug? Git checkout fails with a wrong error message
From: Jeff King @ 2012-01-16 19:09 UTC (permalink / raw)
To: Yves Goergen; +Cc: Holger Hellmuth, git, Carlos Martín Nieto
In-Reply-To: <4F14718B.80209@unclassified.de>
On Mon, Jan 16, 2012 at 07:50:51PM +0100, Yves Goergen wrote:
> 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? On Windows,
> file names are case-insensitive (as on MacOS X) and both names refer to
> the absolute same file. 'git status' has the very same listing with that
> same file twice.
What is the output of "git config core.ignorecase" in your repository?
> 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?
If you delete your index, it will appear to git as if you have staged
all files for deletion (if you run "git status", for example). You can
then run "git reset" to regenerate it based on the last commit.
But I doubt that will help your problem. It seems unlikely to me that
the source of the problem is a corrupted index, but rather is some
corner case in case-insensitive comparisons between the index and the
working tree.
-Peff
^ permalink raw reply
* Re: [PATCH 3/3] git-p4: Add test case for complex branch import
From: Pete Wyckoff @ 2012-01-16 19:12 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <1326674360-2771-4-git-send-email-vitor.hda@gmail.com>
vitor.hda@gmail.com wrote on Mon, 16 Jan 2012 00:39 +0000:
> diff --git a/t/t9801-git-p4-branch.sh b/t/t9801-git-p4-branch.sh
> +test_expect_success 'git-p4 add complex branches' '
> + test_when_finished cleanup_git &&
> + test_create_repo "$git" &&
> + (
> + cd "$cli" &&
> + changelist=$(p4 changes -m1 //depot/... | cut -d" " -f2) &&
> + changelist=$((changelist - 5)) &&
> + p4 integrate //depot/branch1/...@$changelist //depot/branch4/... &&
> + p4 submit -d "branch4" &&
> + changelist=$((changelist + 2)) &&
> + p4 integrate //depot/branch1/...@$changelist //depot/branch5/... &&
> + p4 submit -d "branch5" &&
> + cd "$TRASH_DIRECTORY"
> + )
> +'
Sorry: I think I wanted the "$"s removed from inside $((..)).
Turns out that some shells don't grok that. The above should be:
changelist=$(($changelist - 5)) &&
You can drop the last cd to $TRASH_DIRECTORY since you're inside
a subshell. (Nice addition of the subshells.)
> +
> +# Configure branches through git-config and clone them. git-p4 will only be able
> +# to clone the original structure if it is able to detect the origin changelist
> +# of each branch.
> +test_expect_success 'git-p4 clone complex branches' '
> + test_when_finished cleanup_git &&
> + test_create_repo "$git" &&
> + (
> + test_when_finished cleanup_git &&
> + test_create_repo "$git" &&
These two lines can go; you already did it outside the subshell.
> + cd "$git" &&
> + git config git-p4.branchList branch1:branch2 &&
> + git config --add git-p4.branchList branch1:branch3 &&
> + git config --add git-p4.branchList branch1:branch4 &&
> + git config --add git-p4.branchList branch1:branch5 &&
> + "$GITP4" clone --dest=. --detect-branches //depot@all &&
> + git log --all --graph --decorate --stat &&
> + git reset --hard p4/depot/branch1 &&
> + test -f file1 &&
> + test -f file2 &&
> + test -f file3 &&
There are preferred functions for these tests, I learned recently:
test_path_is_file file1 &&
> + grep -q update file2 &&
> + git reset --hard p4/depot/branch2 &&
> + test -f file1 &&
> + test -f file2 &&
> + test ! -f file3 &&
Similarly
test_path_is_missing file3 &&
> + ! grep -q update file2 &&
> + git reset --hard p4/depot/branch3 &&
> + test -f file1 &&
> + test -f file2 &&
> + test -f file3 &&
> + grep -q update file2 &&
> + git reset --hard p4/depot/branch4 &&
> + test -f file1 &&
> + test -f file2 &&
> + test ! -f file3 &&
> + ! grep -q update file2 &&
> + git reset --hard p4/depot/branch5 &&
> + test -f file1 &&
> + test -f file2 &&
> + test -f file3 &&
> + ! grep -q update file2 &&
> + test ! -d .git/git-p4-tmp
> + )
> +'
^ permalink raw reply
* 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
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