* Tips for debugging fast-import front-ends
From: Julian Phillips @ 2007-07-16 12:45 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce
I was wondering if anyone had some handy tips for debugging fast-import
based importers?
I'm trying to import an SVN repository that was initially created by
cvs2svn and, since we started using branches quite heavily _before_
switching to SVN, there is some quite messy history.
At some point in the "messy" phase I get an error from fast-import saying:
fatal: path foo not in branch
This seems to happen when I attempt to copy a file that is also changed in
the same commit. What I would like to do is find out what things look
like just before that point - the problem is that fast-import seems to not
create anything on failure. So, apart restarting the import and stopping
just before the broken commit, is there any way to find out what
fast-import thinks the branch looks like?
Also, does anyone have any handy hints 'n' tips for working with
fast-import?
--
Julian
---
Air pollution is really making us pay through the nose.
^ permalink raw reply
* Re: "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)
From: Thomas Glanzmann @ 2007-07-16 12:39 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86644kaaf1.fsf@lola.quinscape.zz>
Hello David,
as I mentioned and showed in my original e-mail:
git checkout /path/to/repo
triggers the problem also. So no, "cp -a" has nothing todo with it
because root is able to read _all_ files no matter who the files are
owned by and what the permissions of these files are[1]. This happens on
a _local_ fileystem. And what worries me is that git does something that
breaks the _hard link counter_ of a directory.
Thomas
[1] Notes
Of course that doesn't apply to all filesystems. For example AFS
and NFS. But as I said before it happens on a _UFS_ filesystem.
^ permalink raw reply
* Re: "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)
From: Thomas Glanzmann @ 2007-07-16 12:35 UTC (permalink / raw)
To: David Kastrup; +Cc: git, Linus Torvalds, Junio C Hamano
In-Reply-To: <86ejj8aakq.fsf@lola.quinscape.zz>
Hello David,
> Does it help to say export CDPATH="" in your root shell?
no. The problem is triggered by "git-checkout-index -a -f" so my CDPATH has
absolutly _nothing_ todo with it:
(faui04a) [/var/tmp] mkdir -p test-4/.git
(faui04a) [/var/tmp] cd test-4
(faui04a) [/var/tmp/test-4] gcp -a ~/work/repositories/public/easix.git/* .git/
(faui04a) [/var/tmp/test-4] git-read-tree HEAD
(faui04a) [/var/tmp/test-4] git-checkout-index -a -f
(faui04a) [/var/tmp/test-4] git status
fatal: /usr/bin/git-status cannot be used without a working tree.
(faui04a) [/var/tmp/test-4] rm .git/config
(faui04a) [/var/tmp/test-4] git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: profiles/icpc
# deleted: profiles/sithglan
# deleted: sources/boot.msg
# deleted: sources/busybox-config
# deleted: sources/config
# deleted: sources/easix.logo.16
# deleted: sources/easixdm
# deleted: sources/f2
# deleted: sources/home-faumachine.tar.gz
# deleted: sources/home-icpc.tar.gz
# deleted: sources/home-simigern.tar.gz
# deleted: sources/home-sithglan.tar.gz
# deleted: sources/home-sitowert.tar.gz
# deleted: sources/linuxrc
# deleted: sources/rc.local
#
no changes added to commit (use "git add" and/or "git commit -a")
(faui04a) [/var/tmp/test-4] cd ..
(faui04a) [/var/tmp] rm -rf test-4
rm: Unable to remove directory test-4: File exists
(faui04a) [/var/tmp]
Thomas
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Alex Riesen @ 2007-07-16 12:31 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550707160504p52770227l9af66aa750d9efd6@mail.gmail.com>
On 7/16/07, Marco Costalba <mcostalba@gmail.com> wrote:
> Currently the patch just include the log message because the diff
> content (-p option) is not buffered but is written with a combination
> of printf, puts, fputs, fwrite and putchar directly to stdout.
>
> My question is, there is a way to get the quantity of bytes written to
> stdout before they are printed? I'm not an expert of C stdio library,
> so perhaps this is nonsense, but I was thinking of reading the size of
> stout buffer before to fflush() (I don't know if it is possible).
It is not possible. Buffers can be flushed at any time (i.e. they are
flushed when EOL reached and the output is a terminal for stdout).
It is also a bit unclear _why_ do you need the diff output. You don't
show it immediately anyway.
^ permalink raw reply
* Re: [PATCH] Add --show-size to git log to print message size
From: Marco Costalba @ 2007-07-16 12:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vodiehko7.fsf@assigned-by-dhcp.cox.net>
On 7/14/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Marco Costalba" <mcostalba@gmail.com> writes:
>
>
> "size" is a bit vague here. What if we later want to extend
> things so that you can ask for the entire log entry size
> including the patch output part (I am not saying that would be
> an easy change --- I am more worried about the stability of the
> external interface). So is --show-"size". "message-size" would
> have been a bit easier to swallow, but I sense the problem runs
> deeper.
>
I'm rewriting the patch + documentation cleaned up and with a
different option name (--show-log).
Currently the patch just include the log message because the diff
content (-p option) is not buffered but is written with a combination
of printf, puts, fputs, fwrite and putchar directly to stdout.
My question is, there is a way to get the quantity of bytes written to
stdout before they are printed? I'm not an expert of C stdio library,
so perhaps this is nonsense, but I was thinking of reading the size of
stout buffer before to fflush() (I don't know if it is possible).
If it is not possible I have to give up in extending the scope of this
'show me the size' patch to diff content and I will stick to the
proper name --show-log.
Thanks
Marco
^ permalink raw reply
* [PATCH] Fix git-branch documentation when using remote refs
From: Francis Moreau @ 2007-07-16 11:38 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
Signed-off-by: Francis Moreau <francis.moro@gmail.com>
---
Documentation/git-branch.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index bb6b57d..bc6aa88 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -130,8 +130,8 @@ Delete unneeded branch::
------------
$ git clone git://git.kernel.org/.../git.git my.git
$ cd my.git
-$ git branch -d -r todo html man <1>
-$ git branch -D test <2>
+$ git branch -d -r origin/todo origin/html origin/man <1>
+$ git branch -D test <2>
------------
+
<1> delete remote-tracking branches "todo", "html", "man"
^ permalink raw reply related
* Re: git-config: replaces ~/.gitconfig symlink with real file
From: Bradford Smith @ 2007-07-16 11:33 UTC (permalink / raw)
To: Nikolai Weibull; +Cc: git
In-Reply-To: <dbfc82860707160237v6772b5b8o541f2045ccd824d5@mail.gmail.com>
On 7/16/07, Nikolai Weibull <now@bitwi.se> wrote:
> On 7/15/07, Bradford Smith <bradford.carl.smith@gmail.com> wrote:
> > Since the number of dot-files and dot-directories that I have in my
> > home directory these days is somewhat overwhelming, I like to keep
> > those I directly edit all together in an ~/etc directory so I can
> > easily back them up and/or copy them in bulk to new accounts. So,
> > several of my home dot-files are just symlinks to something in ~/etc,
> > including ~/.gitconfig.
>
> How about adding an environment variable telling Git where to find
> user-global .gitconfig instead?
> > home directory these days is somewhat overwhelming, I like to keep
> > those I directly edit all together in an ~/etc directory so I can
> > easily back them up and/or copy them in bulk to new accounts. So,
> > several of my home dot-files are just symlinks to something in ~/etc,
> > including ~/.gitconfig.
>
> How about adding an environment variable telling Git where to find
> user-global .gitconfig instead?
Thanks for suggesting that.
Actually, by looking at the code I discovered I could use the
environment variable GIT_CONFIG to specify where the configuration
file is, and I have already changed my setup to use this.
Unfortunately, I found the documentation for this variable in
git-config(1) confusing or I would have used it before. If I get the
chance, I'll submit a patch for git-config.txt, and maybe for git.txt
as well, since it lists lots of other environment variables but not
GIT_CONFIG or GIT_CONFIG_LOCAL.
Thanks,
Bradford
^ permalink raw reply
* Re: [PATCH] translate bad characters in refnames during git-svn fetch
From: Jan Hudec @ 2007-07-16 11:15 UTC (permalink / raw)
To: Eric Wong; +Cc: git discussion list
In-Reply-To: <20070716033050.GA29521@muzzle>
[-- Attachment #1: Type: text/plain, Size: 1205 bytes --]
On Sun, Jul 15, 2007 at 20:30:50 -0700, Eric Wong wrote:
> The major issue with this is that it doesn't handle odd cases
> where a refname is sanitized into something
> (say "1234~2" sanitizes to "1234=2"), and then another branch
> is created named "1234=2".
>
> git-svn should at least keep track of what it got sanitized to, to
> avoid clobbering branches.
>
> I started working on this a while back but haven't gotten around
> to revisiting it:
> http://thread.gmane.org/gmane.comp.version-control.git/45651
I believe % is safe, right? So what if git-svn just url-escaped stuff in the
branch name it does not like. Of course % would be included in the list of
characters it does not like. Eg. 1234~2 would escape to 1234%7E2 and if the
user ever head 1234%7E2 in svn, it would simply escape too, to 1234%257E2.
Space is rather common, but that's why there is the + rule in url-encoding --
"foo bar" escapes to "foo+bar" and "foo+bar" escapes to "foo%2Bbar". Or you
could use something else to escape space. I can only think of "=", "_" is too
common to have it escaped and anything else would conflict with either git or
shell.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: question about git-submodule
From: VMiklos @ 2007-07-16 11:07 UTC (permalink / raw)
To: skimo; +Cc: Alex Riesen, git
In-Reply-To: <20070716103954.GM999MdfPADPa@greensroom.kotnet.org>
[-- Attachment #1: Type: text/plain, Size: 806 bytes --]
Hello,
Na Mon, Jul 16, 2007 at 12:39:55PM +0200, Sven Verdoolaege <skimo@kotnet.org> pisal(a):
> No. You have to specify the specific revision of the subproject
> that is included in any revision of the superproject.
>
> Imagine someone making an incompatible change to a subproject.
> You do not want to get this change in your copy of the superproject
> unless the superproject has been adapted to this change.
i don't say that the ability to stick to a given commit is bad, but imho
there are scenarios where the ability to stick to a branch is better
ok, i know, probably i should send a patch if i want this, then it can
be discussed if this is useful or not
anyway thanks for all your answers, now i at least know that what i
wanted is currently not supported :)
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)
From: David Kastrup @ 2007-07-16 10:51 UTC (permalink / raw)
To: git
In-Reply-To: <20070716104342.GB24036@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <thomas@glanzmann.de> writes:
> Hello,
> I narrowed it down. It is in "git checkout" if I copy the ".git" dir via
> "cp -a" and type in "git checkout" it breaks. And it _only_ breaks for
> subdirectories:
Another guess: cp -a copies files preserving all permissions and
ownerships (which works only as root). Nominally, the files now don't
belong to you, and some scripts might take you by the word even if
they _could_ just overwrite things if they actually tried. Try
making
chown -R root.root .git
on your tree and see whether this makes git more comfortable.
--
David Kastrup
^ permalink raw reply
* Re: "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)
From: David Kastrup @ 2007-07-16 10:48 UTC (permalink / raw)
To: git
In-Reply-To: <20070716104342.GB24036@cip.informatik.uni-erlangen.de>
Thomas Glanzmann <thomas@glanzmann.de> writes:
> Hello,
> I narrowed it down. It is in "git checkout" if I copy the ".git" dir via
> "cp -a" and type in "git checkout" it breaks. And it _only_ breaks for
> subdirectories:
>
> (faui04a) [/var/tmp/shit] git checkout
> D profiles/icpc
> D profiles/sithglan
> D sources/boot.msg
> D sources/busybox-config
> D sources/config
> D sources/easix.logo.16
> D sources/easixdm
> D sources/f2
> D sources/home-faumachine.tar.gz
> D sources/home-icpc.tar.gz
> D sources/home-simigern.tar.gz
> D sources/home-sithglan.tar.gz
> D sources/home-sitowert.tar.gz
> D sources/linuxrc
> D sources/rc.local
>
> and I also see that _one_ file in each subdirectory is checked out but the
> others are not.
Ok, stupidly trying one of our most frequently encountered problems:
Does it help to say
export CDPATH=""
in your root shell?
--
David Kastrup
^ permalink raw reply
* Re: "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)
From: Thomas Glanzmann @ 2007-07-16 10:43 UTC (permalink / raw)
To: GIT; +Cc: Linus Torvalds, Junio C Hamano
In-Reply-To: <20070716100803.GA24036@cip.informatik.uni-erlangen.de>
Hello,
I narrowed it down. It is in "git checkout" if I copy the ".git" dir via
"cp -a" and type in "git checkout" it breaks. And it _only_ breaks for
subdirectories:
(faui04a) [/var/tmp/shit] git checkout
D profiles/icpc
D profiles/sithglan
D sources/boot.msg
D sources/busybox-config
D sources/config
D sources/easix.logo.16
D sources/easixdm
D sources/f2
D sources/home-faumachine.tar.gz
D sources/home-icpc.tar.gz
D sources/home-simigern.tar.gz
D sources/home-sithglan.tar.gz
D sources/home-sitowert.tar.gz
D sources/linuxrc
D sources/rc.local
and I also see that _one_ file in each subdirectory is checked out but the
others are not.
Thomas
^ permalink raw reply
* Can someone explain this git-blame/git-rev behavior to me?
From: David Kastrup @ 2007-07-16 10:43 UTC (permalink / raw)
To: git
Try the following (assuming you have a clone of the git master):
git-blame tags/v1.4.2-rc1~87 -- contrib/emacs/vc-git.el | grep b5dd
b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 164) (defun vc-git-print-log (file &optional buffer)
b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 167) (vc-do-command buffer 'async "git" name "rev-list" "--pretty" "HEAD" "--")))
b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 169) (defun vc-git-diff (file &optional rev1 rev2 buffer)
b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 170) (let ((name (file-relative-name file))
b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 171) (buf (or buffer "*vc-diff*")))
b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 173) (vc-do-command buf 0 "git" name "diff-tree" "-p" rev1 rev2 "--")
b5dd9d20 (Ville Skyttä 2006-07-05 01:35:52 +0300 174) (vc-do-command buf 0 "git" name "diff-index" "-p" (or rev1 "HEAD") "--"))
Ok, now do
git-name-rev b5dd9d20
b5dd9d20 tags/v1.4.2-rc1~88
So what is it I am doing wrong here? The problem I have is that in
Emacs, one can go to the "next version" in an annotated file, and I
get stuck in a loop here, since tags/v1.4.2-rc1~88 delivers
git-rev-list HEAD --not tags/v1.4.2-rc1~88 --parents contrib/emacs/vc-git.el|tail -1|git-name-rev --stdin
d87b90e47f7430455385edcf8506288b9a73d3b5 (tags/v1.4.2-rc1~87) b5dd9d2027c1bd5758033c7baf6d087752b0263d (tags/v1.4.2-rc1~88) 280242d1cc1fe2847f649d2f16b273e168fcbc48 (tags/v1.4.2-rc1~92)
So we have tags/v1.4.2-rc1~87 listed as successor again, so I get into
a loop of blame.
Is there something I don't understand about merges?
FWIW,
git-fsck --unreachable b5dd9d20
git-fsck --unreachable d87b90e47f
do not return anything.
--
David Kastrup
^ permalink raw reply
* Re: question about git-submodule
From: Sven Verdoolaege @ 2007-07-16 10:39 UTC (permalink / raw)
To: VMiklos; +Cc: Alex Riesen, git
In-Reply-To: <20070715222948.GL7106@genesis.frugalware.org>
On Mon, Jul 16, 2007 at 12:29:48AM +0200, VMiklos wrote:
> 2) is it possible to do this without step b)?
>
> i mean adding something like: "Subproject commit HEAD" or "Subproject
> commit mybranch"
No. You have to specify the specific revision of the subproject
that is included in any revision of the superproject.
Imagine someone making an incompatible change to a subproject.
You do not want to get this change in your copy of the superproject
unless the superproject has been adapted to this change.
skimo
^ permalink raw reply
* Re: [PATCH 6/6] Add git-rewrite-commits
From: Sven Verdoolaege @ 2007-07-16 10:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0707160054340.14781@racer.site>
On Mon, Jul 16, 2007 at 01:38:11AM +0100, Johannes Schindelin wrote:
> On Sun, 15 Jul 2007, Sven Verdoolaege wrote:
> > > > + if (path_pruning &&
> > > > + !(commit->object.flags & (TREECHANGE | UNINTERESTING)))
> > > > + return 1;
> > >
> > > Why only with "path_pruning"? Ah yes. Because otherwise, you would
> > > assume "A" in "A..B" to be pruned.
> >
> > TREECHANGE is only set when path pruning is in effect.
> > If I didn't check for path_pruning, then all commits would be
> > considered to have been pruned. (Or am I missing something?
> > Honestly, I found all that TREECHANGE stuff difficult to follow.)
>
> AFAICT TREECHANGE means that parents were rewritten.
I think you'll find that if all commits touch a path in the
path specifiers then all commits will have TREECHANGE set and
so no parents will be rewritten.
> > revision.c itself is also riddled with "prune_fn && ".
> > Wouldn't it make sense to invert the meaning of this bit and call
> > it, say, PRUNED, so that the default is off and you would only
> > have to check if the bit was set ?
>
> You meant the TREECHANGE bit? No.
Yes. Why?
> BTW what do you plan to do about my objection to UNINTERESTING, given the
> example "git rewrite-commits A..B x/y"?
That was based on an apparent misunderstanding of my code
that I tried to address above. I did not intend to do what
you claim I do and a quick test confirms that my code does
indeed not to what you claim it does.
More specifically, the history will not be cut off at A
because A is marked UNINTERESTING and is therefore not considered
to have been pruned.
A commit is considered pruned if it was either explicitly marked
as such or if TREECHANGE is not set, but the later check (in is_pruned)
is only done on commits that were checked for tree changes.
skimo
^ permalink raw reply
* "git clone" executed as root on solaris 10 shreds UFS (it is possible to create hardlinks for directories as root under solaris)
From: Thomas Glanzmann @ 2007-07-16 10:08 UTC (permalink / raw)
To: GIT; +Cc: Linus Torvalds, Junio C Hamano
Hello,
when I call "git clone ~adglth0/work/scripts whatever" as user
everything works as expected. As soon as I call this command as root it
shreds ufs:
(s092942) [~] git version
git version 1.5.3.GIT
(s092942) [~] git clone ~adglth0/work/scripts nonroot
Initialized empty Git repository in /export/home/adglth0/nonroot/.git/
remote: Generating pack...
Done counting 220 objects.
Deltifying 220 objects...
2% (5/220) doneIndexing 220 objects...
100% (220/220) done20) donedonedone
Total 220 (delta 114), reused 181remote: (delta 88)
100% (220/220) done
Resolving 114 deltas...
100% (114/114) done
(s092942) [~] cd nonroot
./nonroot
(s092942) [~/nonroot] git status
# On branch master
nothing to commit (working directory clean)
(s092942) [~/nonroot] fg
sudo ${SHELL} --rcfile ${HOME}/.bash_profile (wd: ~)
(s092942) [~] git clone ~adglth0/work/scripts root
DO *NOT* RUN GIT AS ROOT clone /export/home/adglth0/work/scripts root
(s092942) [~] unalias git
(s092942) [~] git clone ~adglth0/work/scripts root
Initialized empty Git repository in /export/home/adglth0/root/.git/
remote: Generating pack...
remote: Done counting 220 objects.
Deltifying 220 objects...
3% (7/220) doneIndexing 220 objects...
100% (220/220) done20) done0) done
Total 220 (delta 114), reused 181 (delta 88)
100% (220/220) done
Resolving 114 deltas...
100% (114/114) done
(s092942) [~] cd root
(s092942) [~/root] git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: eclogic/acct_per_host.pl
# deleted: eclogic/check_3ware
# deleted: eclogic/check_ipmi.pl
# deleted: eclogic/check_load.pl
# deleted: eclogic/create_nagios_config.pl
# deleted: eclogic/mailrelay/config-2.6.20
# deleted: eclogic/mailrelay/interfaces
# deleted: eclogic/on_all_hosts.pl
# deleted: lifebook/kernel-config
# deleted: s017241/config-2.6.20
# deleted: s017241/firewall
# deleted: s017241/siemens.conf
# deleted: siemens/aliasupdate-tg
# deleted: siemens/check_raid.sh
# deleted: siemens/create_nagios_config.pl
# deleted: siemens/crontab_client
# deleted: siemens/deploy
# deleted: siemens/generate_password.pl.gpg
# deleted: siemens/mail_verrechnung.pl
# deleted: siemens/oracle_beispiel_client.pl
# deleted: siemens/sar_deploy.pl
# deleted: siemens/t3_check_via_telnet.pl
# deleted: thinkpad/config-2.6.20
# deleted: thinkpad/fglrx.patch
# deleted: thinkpad/network-please
# deleted: thinkpad/xorg/build
# deleted: webfarm/config-2.6.20
#
no changes added to commit (use "git add" and/or "git commit -a")
(s092942) [~/root] git checkout -f HEAD
(s092942) [~/root] git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: eclogic/acct_per_host.pl
# deleted: eclogic/check_3ware
# deleted: eclogic/check_ipmi.pl
# deleted: eclogic/check_load.pl
# deleted: eclogic/create_nagios_config.pl
# deleted: eclogic/mailrelay/config-2.6.20
# deleted: eclogic/mailrelay/interfaces
# deleted: eclogic/sms.pl
# deleted: lifebook/network-please
# deleted: s017241/config-2.6.20
# deleted: s017241/firewall
# deleted: s017241/xorg.conf
# deleted: siemens/aliasupdate-tg
# deleted: siemens/check_raid.sh
# deleted: siemens/create_nagios_config.pl
# deleted: siemens/crontab_client
# deleted: siemens/deploy
# deleted: siemens/generate_password.pl.gpg
# deleted: siemens/mail_verrechnung.pl
# deleted: siemens/oracle_beispiel_client.pl
# deleted: siemens/sar_deploy.pl
# deleted: siemens/tryserver.sh
# deleted: thinkpad/config-2.6.20
# deleted: thinkpad/fglrx.patch
# deleted: thinkpad/network-please
# deleted: thinkpad/xorg/cleanup
# deleted: webfarm/unsplit.pl
#
no changes added to commit (use "git add" and/or "git commit -a")
(s092942) [~/root] ls
eclogic/ leo* lifebook/ s017241/ siemens/ thinkpad/ webfarm/
(s092942) [~/root] ls siemens/
t3_check_via_telnet.pl*
(s092942) [~/root] cd ..
(s092942) [~] rm -rf root/
rm: Unable to remove directory root/: File exists
(s092942) [~] find root/
root/
(s092942) [~] ls -al root/
total 6
drwxr-xr-x 56 root root 512 Jul 16 11:48 ./
drwxr-xr-x 17 adglth0 root 1536 Jul 16 11:48 ../
(s092942) [~] df -h .
Filesystem size used avail capacity Mounted on
/dev/dsk/c0t0d0s7 75G 9.0G 65G 13% /export/home
(s092942) [~] ls -ali root/
total 6
13657 drwxr-xr-x 56 root root 512 Jul 16 11:48 ./
5829 drwxr-xr-x 17 adglth0 root 1536 Jul 16 11:48 ../
(s092942) [~] gfind /export/home -xdev -inum 13657
/export/home/adglth0/root
(s092942) [~]
A few notes and observations I did. Linux _does_ not allow userland to
create hardlinks for directories which makes totally sense. Solaris does
allow the _root_ user to allow hardlinks for directories. There is even
a command that makes that possible:
(faui04a) [/var/tmp] mkdir test
(faui04a) [/var/tmp] /usr/xpg4/bin/link test bla
(faui04a) [/var/tmp] ls -ali
total 13
1639 drwxrwxrwt 4 root sys 9216 Jul 16 11:13 ./
4 drwxr-xr-x 48 root sys 1024 Jan 1 2007 ../
238939 drwx--x--x 3 snalwuer icipguru 512 Jul 5 19:08 1071895580/
238945 drwxr-xr-x 3 root root 512 Jul 16 11:11 bla/
238945 drwxr-xr-x 3 root root 512 Jul 16 11:11 test/
(faui04a) [/var/tmp] find . -inum 238945
Whatever. My first impression was that the filesystem of the solaris is
broken. So I fscked it. And guess what it corrected the error. But after
the reboot I tried it again and you see the result above. So my guess is
that git calls the link system call in a way Solaris thinks it should
itself shoot in the head. This also happens with _remote_ clones as
root:
(s092942) [~] git clone adglth0@157.163.208.106:/home/adglth0/work/scripts second_test_as_root
Initialized empty Git repository in /export/home/adglth0/second_test_as_root/.git/
The authenticity of host '157.163.208.106 (157.163.208.106)' can't be established.
RSA key fingerprint is 72:27:be:82:f7:71:e5:23:a6:b6:57:a9:11:dd:26:26.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '157.163.208.106' (RSA) to the list of known hosts.
remote: Generating pack...
remote: Done counting 220 objects.
remote: Deltifying 220 objects...
remote: 100% (220/220) done
Indexing 220 objects...
remote: Total 220 (delta 115), reused 37 (delta 9)
100% (220/220) done
Resolving 115 deltas...
100% (115/115) done
(s092942) [~] cd second_test_as_root/
./second_test_as_root/
(s092942) [~/second_test_as_root] git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: eclogic/acct_per_host.pl
# deleted: eclogic/check_3ware
# deleted: eclogic/check_ipmi.pl
# deleted: eclogic/check_load.pl
# deleted: eclogic/create_nagios_config.pl
# deleted: eclogic/mailrelay/config-2.6.20
# deleted: eclogic/mailrelay/interfaces
# deleted: eclogic/on_all_hosts.pl
# deleted: lifebook/kernel-config
# deleted: s017241/config-2.6.20
# deleted: s017241/firewall
# deleted: s017241/siemens.conf
# deleted: siemens/aliasupdate-tg
# deleted: siemens/check_raid.sh
# deleted: siemens/create_nagios_config.pl
# deleted: siemens/crontab_client
# deleted: siemens/deploy
# deleted: siemens/generate_password.pl.gpg
# deleted: siemens/mail_verrechnung.pl
# deleted: siemens/oracle_beispiel_client.pl
# deleted: siemens/sar_deploy.pl
# deleted: siemens/t3_check_via_telnet.pl
# deleted: thinkpad/config-2.6.20
# deleted: thinkpad/fglrx.patch
# deleted: thinkpad/network-please
# deleted: thinkpad/xorg/build
# deleted: webfarm/config-2.6.20
#
no changes added to commit (use "git add" and/or "git commit -a")
(s092942) [~/second_test_as_root] uname -a
SunOS s092942 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100
So has anyone a idea what is wrong. I have shareded a second machine in
a complete different domain. With a complete different git version. Same
thing. So it is not the hardware and not the specific git version and
not the Solaris version:
(faui04a) [/var/tmp] git clone ~sithglan/work/sc
screen/ scripts/ scripts_ccbank_what_the_hell/
(faui04a) [/var/tmp] git clone ~sithglan/work/repositories/
private/ public/
(faui04a) [/var/tmp] git clone ~sithglan/work/repositories/public/
blastwave.git/ bs.git/ easix.git/ mutt.git/ nzb.git/ ra.git/ watchdog.git/
(faui04a) [/var/tmp] git clone ~sithglan/work/repositories/public/easix.git/
DO *NOT* RUN GIT AS ROOT clone /home/cip/adm/sithglan/work/repositories/public/easix.git/
(faui04a) [/var/tmp] unalias git
(faui04a) [/var/tmp] git clone ~sithglan/work/repositories/public/easix.git/
Initialized empty Git repository in /var/tmp/easix/.git/
remote: Generating pack...
remote: Done counting 317 objects.
remote: Deltifying 317 objects...
remote: emote: 317/317) done: ) done17) done
Indexing 317 objects...
remote: Total 317 (delta 182), reused 278 (delta 157)
100% (317/317) done
Resolving 182 deltas...
100% (182/182) done
(faui04a) [/var/tmp] cd easix/
./easix/
(faui04a) [/var/tmp/easix] git status
# On branch master
# Changed but not updated:
# (use "git add/rm <file>..." to update what will be committed)
#
# deleted: profiles/icpc
# deleted: profiles/sithglan
# deleted: sources/boot.msg
# deleted: sources/busybox-config
# deleted: sources/config
# deleted: sources/easix.logo.16
# deleted: sources/easixdm
# deleted: sources/f2
# deleted: sources/home-faumachine.tar.gz
# deleted: sources/home-icpc.tar.gz
# deleted: sources/home-simigern.tar.gz
# deleted: sources/home-sithglan.tar.gz
# deleted: sources/home-sitowert.tar.gz
# deleted: sources/linuxrc
# deleted: sources/rc.local
#
no changes added to commit (use "git add" and/or "git commit -a")
(faui04a) [/var/tmp/easix] cd ..
(faui04a) [/var/tmp] rm -rf easix
rm: Unable to remove directory easix: File exists
(faui04a) [/var/tmp] ls -ali easix/
total 10
238947 drwxr-xr-x 17 root root 512 Jul 16 12:01 ./
1639 drwxrwxrwt 5 root sys 9216 Jul 16 12:01 ../
(faui04a) [/var/tmp] git version
git version 1.5.2
(faui04a) [/var/tmp] uname -a
SunOS faui04a 5.10 Generic_118833-24 sun4u sparc SUNW,Sun-Fire-280R
[ I am off the net for 30 mintues ... eating ]
Thomas
^ permalink raw reply
* Re: git-config: replaces ~/.gitconfig symlink with real file
From: Nikolai Weibull @ 2007-07-16 9:37 UTC (permalink / raw)
To: Bradford Smith; +Cc: git
In-Reply-To: <f158199e0707151427h52da3e38rae3be6e44e27e918@mail.gmail.com>
On 7/15/07, Bradford Smith <bradford.carl.smith@gmail.com> wrote:
> Since the number of dot-files and dot-directories that I have in my
> home directory these days is somewhat overwhelming, I like to keep
> those I directly edit all together in an ~/etc directory so I can
> easily back them up and/or copy them in bulk to new accounts. So,
> several of my home dot-files are just symlinks to something in ~/etc,
> including ~/.gitconfig.
How about adding an environment variable telling Git where to find
user-global .gitconfig instead?
nikolai
^ permalink raw reply
* Re: finding the right remote branch for a commit
From: Matthias Lederhofer @ 2007-07-16 9:14 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707160036160.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Mon, 16 Jul 2007, Matthias Lederhofer wrote:
>
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Use
> >
> > $ git --work-tree "$HOME" --git-dir . init
> >
> > instead.
>
> Why _should_ that be necessary at all? I _already_ told git that the
> working tree is somewhere else. It makes _no sense at all_ to treat the
> cwd as anything else than the GIT_DIR, when --work-tree but no --git-dir
> were specified.
>
> > IMHO the --bare flag did not make much sense before the introduction
> > of GIT_WORK_TREE and doesn't after, at least not with the meaning it
> > has: why should 'git --bare' mean to use the repository from cwd?
>
> To the contrary, it makes tons of sense. If you want to initialise a bare
> repository, what _more_ natural way than to say "git init --bare"? And
> what _more_ natural place to pick for GIT_DIR than the cwd, when you did
> not specify --git-dir?
Ah, for git init it makes sense to have the --bare flag and also to
use the cwd as GIT_DIR when GIT_WORK_TREE is specified.
> > > [descriptions of bugs, that have been largely ignored]
The last paragraphs were for the second and fourth one (git status/add
from outside the working tree): it should be possible to fix this but
it might be a bit complicated. And if it is done for a few commands
probably all commands should support this.
For the third one (git picks up another git repository even if it is
inside a 'detached working tree') I have no idea how to fix this. The
working tree cannot be recognized in any way. Maybe you can/should
use a symlink to the real repository named .git in this case? But
this only works as long as you checkout only one repository in the
directory.
> > Up to now you are supposed to be in the working tree all the time when
> > using it. Therefore I'd call these feature requests rather than bugs :)
>
> Feature requests? WTF? What reason is there for the _requirement_ to
> specify a working tree, when git does not make use of it? Hmm?
Sorry, I don't understand what you mean yet. Where does git require
you to specify a working tree?
^ permalink raw reply
* A question about git-rev-list
From: David Kastrup @ 2007-07-16 8:55 UTC (permalink / raw)
To: git
Hi,
if I do
git-rev-list --remove-empty HEAD --not some-commit -- filename | tail -1
do I have any guarantee that the commit id I get (if any) is a direct
descendant of some-commit? I _think_ --remove-empty might be
necessary for that option, but have no idea whether this hunch is
correct. Do I need additional options like --topo-order, or is that
unnecessary?
Thanks,
--
David Kastrup
^ permalink raw reply
* Some questions about git-name-rev
From: David Kastrup @ 2007-07-16 8:20 UTC (permalink / raw)
To: git
Hi, I am working on git support in Emacs. This involves putting
version labels into the mode line and using them for specifying
revisions to diff.
40 digit commit numbers are not really fun for that.
So I need to use git-name-rev. If I call it with the option --tags,
it might return an empty string.
If I don't call it with --tags, _and_ the commit number I feed into it
is the output of some git-rev-list, am I _guaranteed_ to become some
output?
Now is there a way to _abbreviate_ the output to the shortest _valid_
form, namely not have something like ref/remote/heads/branchname (or
similar) when branchname is sufficient?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH 0/6] Introduce commit notes
From: Junio C Hamano @ 2007-07-16 8:11 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Johannes Schindelin, Alberto Bertogli, Johan Herland
In-Reply-To: <200707160857.48725.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Monday 2007 July 16, Johannes Schindelin wrote:
>
>> The biggest obstacle was a thinko about the scalability. Tree objects
>> take free form name entries, and therefore a binary search by name is not
>> possible.
>
> I might be misunderstanding, but in the case of the notes tree objects isn't
> it true that the name entries aren't free form, but are guaranteed to be of a
> fixed length form:
>
> XX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
>
> In which case you can binary search?
Hmph, you are right. In this sequence:
hex = sha1_to_hex(commit->object.sha1);
snprintf(name, sizeof(name), "%s:%.*s/%.*s",
notes_ref_name, 2, hex, 38, hex + 2);
if (get_sha1(name, sha1))
return;
Instead, we could read the tree object by hand in the commit
that is referenced by notes_ref_name, which has uniform two
letter names for subtrees which can be binary searched, open the
tree for that entry, again by hand, and do another binary search
because that tree has uniform 38-letter names. That certainly
could be done.
Sounds like a "fun" project for some definition of the word.
^ permalink raw reply
* Re: [PATCH 0/6] Introduce commit notes
From: Andy Parkins @ 2007-07-16 7:57 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Alberto Bertogli, gitster, Johan Herland
In-Reply-To: <Pine.LNX.4.64.0707152326080.14781@racer.site>
On Monday 2007 July 16, Johannes Schindelin wrote:
> The biggest obstacle was a thinko about the scalability. Tree objects
> take free form name entries, and therefore a binary search by name is not
> possible.
I might be misunderstanding, but in the case of the notes tree objects isn't
it true that the name entries aren't free form, but are guaranteed to be of a
fixed length form:
XX/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
In which case you can binary search?
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* Re: [PATCH] Fix git-p4 on Windows to not use the Posix sysconf
From: Junio C Hamano @ 2007-07-16 7:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Simon Hausmann, Alex Riesen, Marius Storm-Olsen, git
In-Reply-To: <20070716053511.GC32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I'm more than happy to play patch monkey and ship them through the
> fastimport repository, but since I'm not a p4 user that offers little
> value to the process, other than perhaps to save you a little time.
>
> Simon suggested he might setup a git fork on repo.or.cz himself, at
> which point you could pull the patches for git-p4 directly from him.
>
> Simon?
Pulling from Simon sounds the sanest.
How big is the population that can help testing and cheering-on
git-p4 on this list? If we can have git-p4 subgroup that would
be wonderful, as I do not interoperate with p4 myself.
^ permalink raw reply
* Re: [PATCH] git-svn: fix commiting renames over DAV with funky file names
From: Rogan Dawes @ 2007-07-16 6:36 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20070716045350.GA15307@mayonaise>
Eric Wong wrote:
> Renaming files with non-URI friendly characters caused
> breakage when committing to DAV repositories (over http(s)).
>
> Even if I try leaving out the $self->{url} from the return value
> of url_path(), a partial (without host), unescaped path name
> does not work.
>
> Filenames for DAV repos need to be URI-encoded before being
> passed to the library. Since this bug did not affect file://
> and svn:// repos, the git-svn test library needed to be expanded
> to include support for starting Apache with mod_dav_svn enabled.
>
> This new test is not enabled by default, but can be enabled by
> setting SVN_HTTPD_PORT to any available TCP/IP port on
> 127.0.0.1.
>
> Additionally, for running this test, the following variables
> (with defaults shown) can be changed for the suitable system.
> The default values are set for Debian systems:
>
> SVN_HTTPD_MODULE_PATH=/usr/lib/apache2/modules
> SVN_HTTPD_PATH=/usr/sbin/apache2
>
> Signed-off-by: Eric Wong <normalperson@yhbt.net>
> ---
>
> Rogan: the patch should help, a single space anywhere in the
> path causes SVN to screw up the file names. Of course I'm at a
> loss as to why only DAV repositories need it and why the SVN
> libraries don't abstract that away from me.
>
Hi Eric,
Unfortunately, I cannot test this patch, as I have since worked around
the problem, and it has not reappeared.
If it does, I'll be sure to test and let you know. Unless this patch
makes it into the version of git I am using, of course!
Rogan
^ permalink raw reply
* Re: Questions about git-fast-import for cvs2svn
From: Shawn O. Pearce @ 2007-07-16 6:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Michael Haggerty, git
In-Reply-To: <alpine.LFD.0.999.0707151119120.20061@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Sun, 15 Jul 2007, Michael Haggerty wrote:
> > 2. It appears that author/committer require an email address. How
> > important is a valid email address here?
>
> Git itself doesn't really care, and many CVS conversions have just
> converted the username into "user <user>", but from a QoI standpoint it's
> much nicer if you at least were to allow the kind of conversion that
> allows user-name to be associated with an email.
>
> Maybe git-fast-import could be taught to do the kind of user name
> conversion that we already do for CVS imports.. Shawn?
It could, but I'm not sure I want to implement it. ;-)
I pretty much view source->Git translation as the business/policy
of the frontend, not of fast-import. But we have three frontends
that all share the same file format (git-cvsimport, git-svnimport,
git-svn), and are all independent implementations. Maybe pushing
it down into a tool like fast-import would benefit a lot of users,
and thus should be done.
I'll put it on my todo list. Which is much longer than I have
time for.
> > 5. Is there any significance at all to the order that commits are output
> > to git-fast-import? Obviously, blobs have to be defined before they are
> > used, and '<committish>'s have to be defined before they are referenced.
> > But is there any other significance to the order of commits?
>
> Not afaik. Git internally very fundamentally simply doesn't care (there
> simply _is_ no object ordering, there is just objects that point to other
> objects), and I don't think git-fast-import could possibly care either.
> You do need to be "topologically" sorted (since you cannot even point to
> commits without having their SHA1's), but that should be it.
Linus is completely correct here. The only requirement on data
ordering is that all parent commits (from/merge lines) must
come before any child that depends on them. But that's a pretty
reasonable request, as almost all VCS systems want data to come in
at least that order, if not something even more strict.
In theory marks could be used to stub in commits and let you feed
them out of order, but to make that work fast-import would need to
buffer them until it saw everything it needed to produce a SHA-1.
Not exactly a good idea.
--
Shawn.
^ 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