* Empty directories...
From: David Kastrup @ 2007-07-18 0:13 UTC (permalink / raw)
To: git
GIT(7) -- 03/05/2007
NAME
git - the stupid content tracker
Well, I use git for tracking contents. That means, for example,
installation trees for some application. Let's take a typical TeXlive
tree as an example. Those trees contain, among other things,
directories where new fonts/formats/whatever get placed as things run.
Quite a few of them start out empty, but their permissions have to
correspond to their purpose (for example, some are world-writable).
I see little chance to get this achieved without doing something like
find -type d -empty -execdir touch {}/.git-this-is-empty +
before every checkin and
find -name .git-this-is-empty -exec rm -- {} +
after every checkout. Which is pretty stupid.
As some anecdotal stuff, I did something like
mkdir test
cd test
git-init
touch README
git-add README # another peeve: why is no empty reference point possible?
git-commit -a -m "Initial branch"
git checkout -b newbranch master
unzip ../somearchive -d subdir
git add subdir
git commit -a -m "Add subdir"
git checkout -b newbranch2 master
and expect to have a clean slate. No such luck: without warning, all
empty directories in the zip file are still remaining within subdir,
which as a consequence has not been cleaned up.
So even if one is of the opinion that empty directories are not worth
putting into the repository: if I check in an entire subdirectory
hierarchy and then switch to a branch where this subdirectory is not
existent, I expect the subdirectory to be _gone_, and not have some
littering of empty directories lying around.
And that git-diff can see nothing wrong with that does not really
improve things.
So if git is supposed to be a content tracker, I can't see a way
around it actually being able to track content, and empty directories
_are_ content. It can't let them flying around with arbitrary
permissions on them when I switch branches or tags. And the
workaround using "touch" mentioned above is really awful to do
manually all the time.
Could git technically track a file with a zero-length filename in
empty directories if one tells it explicitly to include it, like with
git-add \! -x "" subdir
or has somebody a better idea or interface or rationale? I understand
that there are use cases where one does not bother about empty
directories, but for a _content_ tracker, not tracking directories
because they are empty seems quite serious.
Ok, kill me. This must likely be the most common FAQ/rant/whatever
concerning git.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Empty directories...
From: Johannes Schindelin @ 2007-07-18 0:35 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85lkdezi08.fsf@lola.goethe.zz>
Hi,
On Wed, 18 Jul 2007, David Kastrup wrote:
> This must likely be the most common FAQ/rant/whatever concerning git.
If you had the idea already, I wonder why you did not find it. It's not
really anything like hard to find:
http://git.or.cz/gitwiki/GitFaq#head-1fbd4a018d45259c197b169e87dafce2a3c6b5f9
Ciao,
Dscho
^ permalink raw reply
* Re: Empty directories...
From: Matthieu Moy @ 2007-07-18 0:39 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85lkdezi08.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> or has somebody a better idea or interface or rationale? I understand
> that there are use cases where one does not bother about empty
> directories, but for a _content_ tracker, not tracking directories
> because they are empty seems quite serious.
,----[ http://www.spinics.net/lists/git/msg30730.html ]
| From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
|
| I wouldn't personally mind if somebody taught git to just track empty
| directories too.
|
| There is no fundamental git database reason not to allow them: it's in
| fact quite easy to create an empty tree object. The problems with
| empty directories are in the *index*, and they shouldn't be
| insurmountable.
|
| [...]
`----
--
Matthieu
^ permalink raw reply
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
From: Shawn O. Pearce @ 2007-07-18 1:48 UTC (permalink / raw)
To: Jason Sewall; +Cc: Brian Downing, Julian Phillips, git
In-Reply-To: <31e9dd080707171449r26c430f1vacfb58eb00f578e5@mail.gmail.com>
Jason Sewall <jasonsewall@gmail.com> wrote:
> On 7/17/07, Brian Downing <bdowning@lavos.net> wrote:
> >I take it this means that keeping your home directory under git
> >/directly/ as I have chosen to do is a bad idea...
>
> Interesting, because this is something I've wanted to do - I use
> several machines (work, work laptop, home, home laptop) and I'm always
> tweaking my various dotfiles... I could really use a way to keep them
> all synchronized.
>
> Just out of curiosity, what do you people do?
I have a regular git directory in ~/cgwork/HomeDir, with its
associated .git directory in ~/cgwork/HomeDir/.git. In other
words standard Git repository setup in a location that isn't my
actual home directory.
My dotfiles in ~/ are actually symlinks back to that Git repository.
To update the symlinks I run the script below. Its pretty simple,
it just merges to directories from the Git repository into my ~/
as dotfiles (the dot-* items) and into my ~/bin (the bin/* items).
So my Git repository looks like this:
$ git ls-tree --abbrev=4 HEAD
040000 tree 0d35 common
040000 tree e033 host-asimov
040000 tree 21c4 host-spearce-pb15.local
100755 blob 0f2d relink.sh
$ git ls-tree --abbrev=4 HEAD:common/
040000 tree cc76 bin
100644 blob 371e dot-bash_profile
100644 blob e675 dot-bashrc
100644 blob 1f0a dot-gitconfig
100644 blob 3d02 dot-ldaprc
100644 blob 1d42 dot-vilerc
$ git ls-tree --abbrev=4 HEAD:common/bin/
100755 blob 7322 cherry-kill
100755 blob 9ed5 fp
100755 blob 89f2 genbibtex
100755 blob 68be newrepo
100755 blob 3759 tkbibtex
$ ls -l ~/.bashrc ~/bin/fp
lrwxr-xr-x 1 spearce spearce 41 Feb 3 23:05 /Users/spearce/.bashrc -> cgwork/HomeDir-DotFiles/common/dot-bashrc
lrwxr-xr-x 1 spearce spearce 40 Feb 3 23:05 /Users/spearce/bin/fp -> ../cgwork/HomeDir-DotFiles/common/bin/fp
Yea, it relies on the fact that I never use `git config --global`,
which apparently I've done recently as the damn thing isn't a symlink
like its supposed to be. Uggh. Its the *only* program on my system
that doesn't resolve the symlink and edit the file it points at.
-->--
#!/bin/sh
root=`dirname "$0"`
[ -d "$root" ] || {
echo "error: Can't locate $0 in filesystem." >&2
exit 1
}
cd "$root"
root=$(pwd)
root=$(echo "$root" | sed s:^$HOME/::)
if [ "X$HOSTTYPE" = Xpowerpc ]
then
HOSTNAME=spearce-pb15.local
fi
dot_sources="common/dot-* host-$HOSTNAME/dot-*"
bin_sources="common/bin/* host-$HOSTNAME/bin/*"
echo "Linking from $dot_sources"
for src in $dot_sources
do
if [ -e "$src" ]
then
dot_file=$(basename "$src" | sed s/^dot-/./)
targ="$root/$src"
dest="$HOME/$dot_file"
if [ -L "$dest" ]
then
echo " U $dest -> $targ"
rm -f "$dest"
ln -s "$targ" "$dest"
continue
fi
if [ ! -e "$dest" ]
then
echo " N $dest -> $targ"
ln -s "$targ" "$dest"
continue
fi
if [ -e "$dest" -a ! -e "$dest.bak" ]
then
echo " O $dest -> $targ"
mv "$dest" "$dest.bak"
ln -s "$targ" "$dest"
continue
fi
echo " ! $dest -> $targ"
fi
done
echo "done."
echo
echo "Linking from $bin_sources"
for src in $bin_sources
do
if [ -e "$src" ]
then
bin_file=$(basename "$src")
case "$root" in
/*) targ="$root/$src";;
*) targ="../$root/$src"
esac
dest="$HOME/bin/$bin_file"
mkdir -p "$HOME/bin"
if [ -L "$dest" ]
then
echo " U $dest -> $targ"
rm -f "$dest"
ln -s "$targ" "$dest"
continue
fi
if [ ! -e "$dest" ]
then
echo " N $dest -> $targ"
ln -s "$targ" "$dest"
continue
fi
if [ -e "$dest" -a ! -e "$dest.bak" ]
then
echo " O $dest -> $targ"
mv "$dest" "$dest.bak"
chmod a-x "$dest.bak"
ln -s "$targ" "$dest"
continue
fi
echo " ! $dest -> $targ"
fi
done
echo "done."
-->--
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
From: Shawn O. Pearce @ 2007-07-18 1:51 UTC (permalink / raw)
To: Julian Phillips; +Cc: git
In-Reply-To: <20070717212103.11950.10363.julian@quantumfyre.co.uk>
Julian Phillips <julian@quantumfyre.co.uk> wrote:
> > 'Error in startup script: expected version number but got "1.5.3.GIT"'
> >
> > followed by what I assume is a code snippet where it failed (I wouldn't
> > know tcl if it hit me with a large brick).
> >
> > Is this expected? driver error? or maybe a bug?
Bug in git-gui. *sigh*
> Well, whichever it is, this seems to fix it for me ... with the proviso that I
> still no nothing about tcl. I am also not sure if it is correct to do the
> patch against the git repo?
>
> git-gui/git-gui.sh | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
Many thanks for the fix. I was about to do this myself but found
your message in my inbox instead. Happy days.
Fortunately git-am -3 does wonders, and it didn't matter:
$ git am -s -3 jp
Applying git-gui: Handle git versions of the form n.n.n.GIT
error: git-gui/git-gui.sh: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Renamed git-gui/git-gui.sh => git-gui.sh
Wrote tree 1909733645c3bd167b1b28a98ee66c0a95f357f1
Committed: 91464dfb102d6143182d8f312b68486e9dceb103
I've extolled the virtues of -3 and merge-recursive's rename detector
before on the mailing list, for exactly this reason. Despite the
patch coming in with the wrong path it still applies just fine.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
From: Shawn O. Pearce @ 2007-07-18 1:52 UTC (permalink / raw)
To: Brian Downing; +Cc: Julian Phillips, git
In-Reply-To: <20070717214011.GU19073@lavos.net>
Brian Downing <bdowning@lavos.net> wrote:
> Can we handle versions with '-dirty' at the end as well, or is this
> ill-advised? For some reason when I build my hacked-up personal debian
> packages it usually winds up:
>
> :; git --version
> git version 1.5.3.GIT-dirty
>
> and I haven't bothered to find out why.
Already fixed. Please get the latest version of git-gui...
--
Shawn.
^ permalink raw reply
* Re: Character set for the HTML documentation
From: Junio C Hamano @ 2007-07-18 2:02 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List
In-Reply-To: <469D516B.6030806@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> Can we switch the documentation over to UTF-8, this is 2007
> after all...?
By all means, yes.
I do not think we particularly wanted to use 8859-1, but nothing
in Documentation/ tells the asciidoc toolchain that the document
should come out in UTF-8 either.
^ permalink raw reply
* Re: Empty directories...
From: Junio C Hamano @ 2007-07-18 2:23 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85lkdezi08.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> or has somebody a better idea or interface or rationale? I understand
> that there are use cases where one does not bother about empty
> directories, but for a _content_ tracker, not tracking directories
> because they are empty seems quite serious.
No objections as long as a patch is cleanly made without
regression. It's just nobody agreed that it is "quite serious"
yet so far, and no fundamental reason against it.
^ permalink raw reply
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
From: Martin Langhoff @ 2007-07-18 2:32 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Julian Phillips, git
In-Reply-To: <20070718015138.GR32566@spearce.org>
On 7/17/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> Applying git-gui: Handle git versions of the form n.n.n.GIT
>
I'm far from an authority on things TCL, but I don't think this patch
should be merged as is. Julian is reporting it as a "fixes my symptom"
patch, and that's barely what it does.
The regex should be more liberal, imho. With this superficial fix:
- Builds from a dirty tree have a broken git gui
- Builds from a repo with a nonstandard (local) tagname tagname have
a broken git gui
cheers,
martin
^ permalink raw reply
* Re: [PATCH 1/3] Move bundle specific stuff into bundle.[ch]
From: Daniel Barkalow @ 2007-07-18 2:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707172346450.14781@racer.site>
On Tue, 17 Jul 2007, Johannes Schindelin wrote:
> The transport specific stuff was moved into libgit.a, and the
> bundle specific stuff will not be left behind.
>
> This is a big code move, with one exception: the function
> unbundle() no longer outputs the list of refs. You have to call
> list_bundle_refs() yourself for that.
You should use -C on this sort of thing, so that the interesting aspects
of the patch are easier to see. (It actually comes out longer in this
case, but it's far easier to tell that the code in the new file is the
same as the old code.) Can you tell I've been rearranging a lot of code
lately and trying to make the patches not look really scary?
Aside from presentation, it looks good to me. Shall I stick the bundle
changes into my series? I'd like to have them come before the patch to
switch to builtin-fetch, so that there aren't any revisions where "git
fetch" doesn't have bundle support.
And I think it would be best to take part 3 as a review fix to my final
patch.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] git-gui: Handle git versions of the form n.n.n.GIT
From: Shawn O. Pearce @ 2007-07-18 2:54 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Julian Phillips, git
In-Reply-To: <46a038f90707171932m67c51388jb2304f0b1873e3a6@mail.gmail.com>
Martin Langhoff <martin.langhoff@gmail.com> wrote:
> On 7/17/07, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Applying git-gui: Handle git versions of the form n.n.n.GIT
> >
>
> I'm far from an authority on things TCL, but I don't think this patch
> should be merged as is.
Too late, already applied and pushed. ;-)
> Julian is reporting it as a "fixes my symptom"
> patch, and that's barely what it does.
>
> The regex should be more liberal, imho. With this superficial fix:
I think we are now cleaning up the Git version as best we can:
regsub -- {-dirty$} $_git_version {} _git_version
regsub {\.[0-9]+\.g[0-9a-f]+$} $_git_version {} _git_version
regsub {\.rc[0-9]+$} $_git_version {} _git_version
regsub {\.GIT$} $_git_version {} _git_version
The first fixes the -dirty build problem. The second drops off
the extra information that git-describe throws into the mix when
it generates output for a non-tagged commit. The third kills the
rc* component if this is a release candidate. Note that the rc*
killer must come after the git-describe killer, as the rc* part is
actually in the real tag. The last one fixes the weird case where
the user has somehow bungled his git software distribution so it
cannot generate a git version via git-describe *and* they have no
`version` file in the source code directory. Such people really
should fix their git. But anyway we do support it now.
> - Builds from a repo with a nonstandard (local) tagname tagname have
> a broken git gui
This I cannot do anything about, other than maybe to warn the user
that they are about to run with a version of Git that we cannot
verify and hence we have no idea if git-gui will work correctly,
or fall flat on its face.
I'll add in a confirmation dialog for this case. That way the
user can make the decision. User always knows best.
--
Shawn.
^ permalink raw reply
* git svn dcommit seg fault
From: Perrin Meyer @ 2007-07-18 2:51 UTC (permalink / raw)
To: git
I'm able to clone svn repo's fine with
$ git svn clone https://svn.eng.msli.com/perrin/trunk/TESTGIT/ .
and I'm then able to use git commit to commit local changes, but
when I try
$ git svn dcommit
I get
[perrin@whisper TESTGIT]$ git svn dcommit
M test.c
Committed r717
Segmentation fault
As far as I can tell, the commit worked fine (verified by trying 'svn update' on another box).
I've tried git version 1.5.2.3, 1.5.3-rc2, and the latest build, and all give the seg fault.
I'm guessing it has something to do with using the https connection to svn?
Thanks,
Perrin Meyer
^ permalink raw reply
* Re: [PATCH 1/3] Move bundle specific stuff into bundle.[ch]
From: Daniel Barkalow @ 2007-07-18 3:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707172216420.14596@iabervon.org>
On Tue, 17 Jul 2007, Daniel Barkalow wrote:
> On Tue, 17 Jul 2007, Johannes Schindelin wrote:
>
> > The transport specific stuff was moved into libgit.a, and the
> > bundle specific stuff will not be left behind.
> >
> > This is a big code move, with one exception: the function
> > unbundle() no longer outputs the list of refs. You have to call
> > list_bundle_refs() yourself for that.
>
> You should use -C on this sort of thing, so that the interesting aspects
> of the patch are easier to see. (It actually comes out longer in this
> case, but it's far easier to tell that the code in the new file is the
> same as the old code.) Can you tell I've been rearranging a lot of code
> lately and trying to make the patches not look really scary?
Actually, I ended up touching this up a tiny bit, too: I ordered the
functions in bundle.c the way they were in builtin-bundle.c (so that the
patch is more trivial) and removed the blank lines at the end of the file.
This makes the "git diff -C" output really obvious.
(Someday, I'd like to have a diff that can show that a substantial block
of '+' lines matches a block of lines from somewhere in the "before"
content, so reviewers can verify that the patch reorders code but doesn't
change it, or changes it in certain ways. But, of course, that's both hard
to generate and hard to display usefully.)
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 1/3] Move bundle specific stuff into bundle.[ch]
From: Shawn O. Pearce @ 2007-07-18 3:29 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Johannes Schindelin, git
In-Reply-To: <Pine.LNX.4.64.0707172302560.14596@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> (Someday, I'd like to have a diff that can show that a substantial block
> of '+' lines matches a block of lines from somewhere in the "before"
> content, so reviewers can verify that the patch reorders code but doesn't
> change it, or changes it in certain ways. But, of course, that's both hard
> to generate and hard to display usefully.)
I just moved a huge block in git-gui so I have a great example...
What about a patch format like this? I doubt people move more than
26 blocks in the same patch of the same file, so using a single
character block prefix when the before/after images are identical
might work OK.
diff --git a/git-gui.sh b/git-gui.sh
index 0443129..f13fa80 100755
--- a/git-gui.sh
+++ b/git-gui.sh
a@@ -632,6 +632,43 a@@ You are using [git-version]:
######################################################################
##
a+## feature option selection
a+
a+if {[regexp {^git-(.+)$} [appname] _junk subcommand]} {
a+ unset _junk
a+} else {
a+ set subcommand gui
a+}
a+if {$subcommand eq {gui.sh}} {
a+ set subcommand gui
a+}
a+if {$subcommand eq {gui} && [llength $argv] > 0} {
a+ set subcommand [lindex $argv 0]
a+ set argv [lrange $argv 1 end]
a+}
a+
a+enable_option multicommit
a+enable_option branch
a+enable_option transport
a+
a+switch -- $subcommand {
a+browser -
a+blame {
a+ disable_option multicommit
a+ disable_option branch
a+ disable_option transport
a+}
a+citool {
a+ enable_option singlecommit
a+
a+ disable_option multicommit
a+ disable_option branch
a+ disable_option transport
a+}
a+}
a+
a+######################################################################
a+##
## repository setup
if {[catch {
a@@ -1598,43 +1635,6 a@@ apply_config
######################################################################
##
a-## feature option selection
a-
a-if {[regexp {^git-(.+)$} [appname] _junk subcommand]} {
a- unset _junk
a-} else {
a- set subcommand gui
a-}
a-if {$subcommand eq {gui.sh}} {
a- set subcommand gui
a-}
a-if {$subcommand eq {gui} && [llength $argv] > 0} {
a- set subcommand [lindex $argv 0]
a- set argv [lrange $argv 1 end]
a-}
a-
a-enable_option multicommit
a-enable_option branch
a-enable_option transport
a-
a-switch -- $subcommand {
a-browser -
a-blame {
a- disable_option multicommit
a- disable_option branch
a- disable_option transport
a-}
a-citool {
a- enable_option singlecommit
a-
a- disable_option multicommit
a- disable_option branch
a- disable_option transport
a-}
a-}
a-
a-######################################################################
a-##
## ui construction
set ui_comm {}
--
1.5.3.rc1.818.g84b7
--
Shawn.
^ permalink raw reply
* Re: Character set for the HTML documentation
From: Geoff Richards @ 2007-07-18 5:26 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <469D516B.6030806@zytor.com>
On Tue, Jul 17, 2007 at 04:31:55PM -0700, H. Peter Anvin wrote:
> I just got the following email:
>
> > The Git documentation at
> > <http://www.kernel.org/pub/software/scm/git/docs/user-manual.html> is
> > encoded in ISO 8859-1, but it is being served with a content-type header
> > of "text/plain; charset=UTF-8".
> >
> > The content-type header overrides the value declared in the <meta> tag
> > of the HTML document, so this causes browsers to render the
> > documentation incorrectly.
> >
> > Apologies if this is a well known issue and you get a lot of mail like
> > this BTW, just don't LART me too hard. ;)
>
> The fact that browsers behave this way is of course a bug, but it's a
> common one. Can we switch the documentation over to UTF-8, this is 2007
> after all...?
Unfortunately, it's not a bug. The correct thing for a browser to do is
give the 'Content-Type' HTTP header priority over the <meta> element.
It's defined in an RFC somewhere.
Best thing to do is tell Apache (or whatever) not to send the HTTP
header ("AddDefaultCharset off"), and make sure all the HTML has a
correct <meta> element specifying the encoding.
And yes, putting everything in UTF-8 unless you've got a specific reason
not to is probably going to make life simpler as well.
HTH,
geoff
^ permalink raw reply
* Re: Empty directories...
From: David Kastrup @ 2007-07-18 5:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8x9ea1rg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <gitster@pobox.com> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> or has somebody a better idea or interface or rationale? I understand
>> that there are use cases where one does not bother about empty
>> directories, but for a _content_ tracker, not tracking directories
>> because they are empty seems quite serious.
>
> No objections as long as a patch is cleanly made without
> regression. It's just nobody agreed that it is "quite serious"
> yet so far, and no fundamental reason against it.
Thanks. It certainly is not serious for the Linux kernel source, but
seems awkward for quite a few situations. Anyway, what is your take
on the situation I described?
That creating some directory hierarchy (happening to contain empty
directories) with some external program, adding and committing it,
then switching to a different branch (or maybe doing a git-reset
--hard) leaves a skeleton of empty directories around?
I find this almost worse than not being able to put them into the
repository: you can't get rid of them anymore either!
I'd be tempted to propose that git should remove empty subdirectories
when cleaning up a removed tree in the working directory, even though
that violates the principle to not delete anything it isn't tracking.
But since you can't get it to track the stuff in the first place...
But the real fix would be to track them.
Does some trick work possibly at checkin time, like putting an empty
file into every empty directory, adding to the index, then removing
all empty files explicitly from the index and then checking in, or is
this hopeless to work around with from the user side without affecting
the repository itself?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Empty directories...
From: David Kastrup @ 2007-07-18 6:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0707180135200.14781@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 18 Jul 2007, David Kastrup wrote:
>
>> This must likely be the most common FAQ/rant/whatever concerning git.
>
> If you had the idea already, I wonder why you did not find it. It's not
> really anything like hard to find:
>
> http://git.or.cz/gitwiki/GitFaq#head-1fbd4a018d45259c197b169e87dafce2a3c6b5f9
The FAQ answer is weazeling on several accounts:
a) No, git only cares about files, or rather git tracks content and
empty directories have no content.
In the same manner as empty regular files have no contents, and git
tracks those. Existence and permissions are important.
b) The problem is not just that empty directories don't get added into
the repository. They also don't get removed again when switching to a
different checkout. When git-diff returns zero, I expect a subsequent
checkout to not leave complete empty hierarchies around because git
can't delete any empty leaves which it chose not to track.
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: [PATCH 1/3] Move bundle specific stuff into bundle.[ch]
From: Junio C Hamano @ 2007-07-18 6:13 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <20070718032907.GY32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> What about a patch format like this? I doubt people move more than
> 26 blocks in the same patch of the same file, so using a single
> character block prefix when the before/after images are identical
> might work OK.
>
> diff --git a/git-gui.sh b/git-gui.sh
> index 0443129..f13fa80 100755
> --- a/git-gui.sh
> +++ b/git-gui.sh
> a@@ -632,6 +632,43 a@@ You are using [git-version]:
>
> ######################################################################
> ##
> a+## feature option selection
> ...
> a+
> a+######################################################################
> a+##
> ## repository setup
>
> if {[catch {
> a@@ -1598,43 +1635,6 a@@ apply_config
>
> ######################################################################
> ##
> a-## feature option selection
> ....
> a-##
> ## ui construction
>
> set ui_comm {}
Gaah, my eyes, my *eyes*!!
runs, stays in bathroom for 10 minutes and washes, and
comes back...
It might not be actually so bad. But I wonder if it would be
more obvious if you do not show the whole "a-" lines but leave
just a marker there. That is (ugliness of "a@@" and "a-" that
made me wash my eyes needs to be fixed, though -- but that is
only the syntax):
a@@ -1598,43 +1635,6 a@@ apply_config
######################################################################
##
a-<<< Block a was originally here >>>
## ui construction
set ui_comm {}
You are coming up with a new output format that is only used
when it is a straight move and nothing else, so by definition
there is really no need to show both removal and addition.
^ permalink raw reply
* Re: Empty directories...
From: David Kastrup @ 2007-07-18 6:16 UTC (permalink / raw)
To: git
In-Reply-To: <vpqfy3m7dex.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> David Kastrup <dak@gnu.org> writes:
>
>> or has somebody a better idea or interface or rationale? I understand
>> that there are use cases where one does not bother about empty
>> directories, but for a _content_ tracker, not tracking directories
>> because they are empty seems quite serious.
>
> ,----[ http://www.spinics.net/lists/git/msg30730.html ]
> | From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> |
> | I wouldn't personally mind if somebody taught git to just track empty
> | directories too.
> |
> | There is no fundamental git database reason not to allow them:
> | it's in fact quite easy to create an empty tree object.
> | The problems with empty directories are in the *index*, and they
> | shouldn't be insurmountable.
Stop right here: does that mean that I can script some "put empty
directories into the last commit manually" procedure bypassing the
index?
--
David Kastrup, Kriemhildstr. 15, 44793 Bochum
^ permalink raw reply
* Re: Empty directories...
From: Shawn O. Pearce @ 2007-07-18 6:30 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85zm1uxmmw.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> wrote:
> > ,----[ http://www.spinics.net/lists/git/msg30730.html ]
> > | From: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx>
> > |
> > | I wouldn't personally mind if somebody taught git to just track empty
> > | directories too.
> > |
> > | There is no fundamental git database reason not to allow them:
> > | it's in fact quite easy to create an empty tree object.
> > | The problems with empty directories are in the *index*, and they
> > | shouldn't be insurmountable.
>
> Stop right here: does that mean that I can script some "put empty
> directories into the last commit manually" procedure bypassing the
> index?
Yes. But when you read that tree into the index later (by say
checking out a branch that points to it) the empty directories
will not be created, as they have no files to cause their creation.
Committing changes on that branch will remove the empty directories.
;-)
Oh, and the above question from you sounds like you think you can
modify the last commit to include new directories that weren't
there before. You cannot do that without changing the tree SHA-1,
which will cause the commit SHA-1 to change. That in turns means you
are not actually adding to the last commit but instead are creating
an entirely different commit. History in Git is always immutable.
--
Shawn.
^ permalink raw reply
* Re: Empty directories...
From: Wincent Colaiuta @ 2007-07-18 6:34 UTC (permalink / raw)
To: David Kastrup; +Cc: Junio C Hamano, git
In-Reply-To: <85d4yqz24s.fsf@lola.goethe.zz>
El 18/7/2007, a las 7:56, David Kastrup escribió:
> That creating some directory hierarchy (happening to contain empty
> directories) with some external program, adding and committing it,
> then switching to a different branch (or maybe doing a git-reset
> --hard) leaves a skeleton of empty directories around?
>
> I find this almost worse than not being able to put them into the
> repository: you can't get rid of them anymore either!
>
> I'd be tempted to propose that git should remove empty subdirectories
> when cleaning up a removed tree in the working directory, even though
> that violates the principle to not delete anything it isn't tracking.
> But since you can't get it to track the stuff in the first place...
>
> But the real fix would be to track them.
Although I haven't yet been "bitten" by this issue I understand where
you're coming from. This could confuse users and appear inconsistent
to them (seeing as empty *files* can be tracked). I think it's
probably worth tackling for that reason alone, but it will have the
additional benefit of enabling other workflows like the one you
describe ("installation trees for some application").
> Does some trick work possibly at checkin time, like putting an empty
> file into every empty directory, adding to the index, then removing
> all empty files explicitly from the index and then checking in, or is
> this hopeless to work around with from the user side without affecting
> the repository itself?
I wouldn't recommend any "tricks" here. I think the real solution is
to allow the tracking of empty trees; everything else seems like a
kludge. And then, as you've noted already that will allow Git to
handle the "skeleton of empty directories" left behind problem that
you describe.
Cheers,
Wincent
^ permalink raw reply
* Re: Empty directories...
From: Junio C Hamano @ 2007-07-18 6:53 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <85d4yqz24s.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> No objections as long as a patch is cleanly made without
>> regression. It's just nobody agreed that it is "quite serious"
>> yet so far, and no fundamental reason against it.
>
> Thanks. It certainly is not serious for the Linux kernel source, but
> seems awkward for quite a few situations. Anyway, what is your take
> on the situation I described?
Didn't I say I do not have an objection for somebody who wants
to track empty directories, already? I probably would not do
that myself but I do not see a reason to forbid it, either.
The right approach to take probably would be to allow entries of
mode 040000 in the index. Traditionally, we allowed only 100644
(blobs as regular files) and 120000 (blobs as symlinks). We
recently added 160000 (commit from outer space, aka subproject).
And we do that for all directories, not just empty ones. So if
you have fileA, empty/, sub/fileB tracked, your index would
probably have these four entries, immediately after read-tree
of an existing tree object:
100644 15db6f1f27ef7a... 0 fileA
040000 4b825dc642cb6e... 0 empty
040000 e125e11d3b63e3... 0 sub
100644 52054201c2a872... 0 sub/fileB
Making sure that empty/ directory exists in the working tree is
probably done in entry.c; we have been touching that area in an
unrelated thread in the past few days.
If you add sub/fileC, with "update-index" (and "add"), you
invalidate the SHA-1 object name you stored for "sub" (because
there is no point recomputing the tree object until you know you
need a subtree for "sub" part, which does not happen until the
next "write-tree"), and end up with something like:
100644 15db6f1f27ef7a... 0 fileA
040000 4b825dc642cb6e... 0 empty
040000 00000000000000... 0 sub
100644 52054201c2a872... 0 sub/fileB
100644 705bf16c546f32... 0 sub/fileC
These "missing" SHA-1 would need to be recomputed on-demand.
We have had necessary infrastructure to do this "keeping
untouched tree object names in the index" for quite some time,
but it is not a part of the index proper (it is stored in an
extension section in the index file, to keep the index
compatible with older versions of git).
Having made it sound so easy, here are the issues I would expect
to be nontrivial (but probably not rocket surgery either).
* unpack-trees, which is the workhorse for twoway merge (aka
"switching branches") and threeway merge, has a convoluted
logic to avoid D/F conflicts; it can probably be cleaned up
once we do the above conversion so that the index starts
saying "Hey, I have a directory here" more explicitly. The
end result would probably be a code easier to follow.
* status, update-index --refresh, and diff-files cares about
the information cached in the index from the last time
lstat(2) is run on each entry. What we should store there
for "tree" entries is very unclear to me, but probably we
should teach them to ignore the stat-matching logic for
these entries.
* diff-index walks the index and a tree in parallel but does
not currently expect to see a tree object in the index. It
needs to be taught to ignore these "tree" entries.
* merge-recursive and merge-index walk the index, coming up
with the merge results one path at a time. They also need to
be taught to ignore these "tree" entries.
* diff-index and "read-tree -m" should be taught to take
advantage of the "tree" entries in the index. For example,
if diff-index finds the "tree" entry in the index and the
subtree found from the tree object exactly match, it does not
even have to descend into the tree, which would be a huge
performance win (because you do not have to open the subtree
and its subtrees from the tree side; you already have read
everything on the index side, and still have to skip the
entries in the directory). "read-tree -m" also should be
able to optimize two identical subtrees in the 2 or 3 trees
involved.
Even if we follow the "lazy invalidate" strategy to maintain
the "tree" entries in the normal codepath, we could have a
special operation that says "now update all the tree entries
by recomputing the tree object names as needed". Perhaps we
might want to initiate such an operation before "read-tree
-m" automatically.
^ permalink raw reply
* [PATCH] Rename read_pipe() with read_fd() and make its buffer nul-terminated.
From: Carlos Rica @ 2007-07-18 7:08 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin, Kristian Høgsberg
The new name is closer to the purpose of the function.
The other change just makes things easier for callers needing a
NUL-terminated buffer.
Since the function returns only the memory written with data,
almost always allocating more space than needed because final
size is unknown, an extra NUL terminating the buffer is harmless.
It is not included in the returned size, so the function
remains working as before.
Also, now the function allows the buffer passed to be NULL at first,
and alloc_nr is now used for growing the buffer, instead size=*2.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
builtin-stripspace.c | 4 +++-
cache.h | 2 +-
mktag.c | 2 +-
sha1_file.c | 17 ++++++++++++++---
4 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/builtin-stripspace.c b/builtin-stripspace.c
index 0c970aa..5571687 100644
--- a/builtin-stripspace.c
+++ b/builtin-stripspace.c
@@ -79,8 +79,10 @@ int cmd_stripspace(int argc, const char **argv, const char *prefix)
size = 1024;
buffer = xmalloc(size);
- if (read_pipe(0, &buffer, &size))
+ if (read_fd(0, &buffer, &size)) {
+ free(buffer);
die("could not read the input");
+ }
size = stripspace(buffer, size, 0);
write_or_die(1, buffer, size);
diff --git a/cache.h b/cache.h
index 328c1ad..ec9b43d 100644
--- a/cache.h
+++ b/cache.h
@@ -265,7 +265,7 @@ extern int ie_match_stat(struct index_state *, struct cache_entry *, struct stat
extern int ie_modified(struct index_state *, struct cache_entry *, struct stat *, int);
extern int ce_path_match(const struct cache_entry *ce, const char **pathspec);
extern int index_fd(unsigned char *sha1, int fd, struct stat *st, int write_object, enum object_type type, const char *path);
-extern int read_pipe(int fd, char** return_buf, unsigned long* return_size);
+extern int read_fd(int fd, char** return_buf, unsigned long* return_size);
extern int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object);
extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
diff --git a/mktag.c b/mktag.c
index b82e377..38acd5a 100644
--- a/mktag.c
+++ b/mktag.c
@@ -120,7 +120,7 @@ int main(int argc, char **argv)
setup_git_directory();
- if (read_pipe(0, &buffer, &size)) {
+ if (read_fd(0, &buffer, &size)) {
free(buffer);
die("could not read from stdin");
}
diff --git a/sha1_file.c b/sha1_file.c
index 1efd9ae..563ec07 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2304,27 +2304,38 @@ int has_sha1_file(const unsigned char *sha1)
*
* returns 0 if anything went fine and -1 otherwise
*
+ * The buffer is always NUL-terminated, not including it in returned size.
+ *
* NOTE: both buf and size may change, but even when -1 is returned
* you still have to free() it yourself.
*/
-int read_pipe(int fd, char** return_buf, unsigned long* return_size)
+int read_fd(int fd, char** return_buf, unsigned long* return_size)
{
char* buf = *return_buf;
unsigned long size = *return_size;
ssize_t iret;
unsigned long off = 0;
+ if (!buf || size <= 1) {
+ size = alloc_nr(size);
+ buf = xrealloc(buf, size);
+ }
+
do {
iret = xread(fd, buf + off, size - off);
if (iret > 0) {
off += iret;
if (off == size) {
- size *= 2;
+ size = alloc_nr(size);
buf = xrealloc(buf, size);
}
}
} while (iret > 0);
+ if (off == size)
+ buf = xrealloc(buf, size + 1);
+ buf[off] = '\0';
+
*return_buf = buf;
*return_size = off;
@@ -2339,7 +2350,7 @@ int index_pipe(unsigned char *sha1, int fd, const char *type, int write_object)
char *buf = xmalloc(size);
int ret;
- if (read_pipe(fd, &buf, &size)) {
+ if (read_fd(fd, &buf, &size)) {
free(buf);
return -1;
}
--
1.5.0
^ permalink raw reply related
* Re: [PATCH] Do _not_ call unlink on a directory
From: Johannes Sixt @ 2007-07-18 7:24 UTC (permalink / raw)
To: git
In-Reply-To: <20070717202754.GB25037@cip.informatik.uni-erlangen.de>
Thomas Glanzmann wrote:
> and as you can see by the
> pastes that I provided to track down the bug I have
>
> if [ $UID -eq 0 ]; then
> export PS1="(${PROMPT_RED}\h${PROMPT_END}) [${PROMPT_BLUE}\w${PROMPT_END}] ";
> alias bk='echo DO *NOT* RUN BK AS ROOT'
> alias git='echo DO *NOT* RUN GIT AS ROOT'
> alias links='echo DO *NOT* RUN LINKS AS ROOT'
> alias elinks='echo DO *NOT* RUN ELINKS AS ROOT'
And if you have a file NOTES in $pwd, it will tell you:
DO NOTES RUN GIT AS ROOT
;-P
-- Hannes
^ permalink raw reply
* Re: [PATCH 1/3] Move bundle specific stuff into bundle.[ch]
From: Junio C Hamano @ 2007-07-18 7:26 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <20070718061931.GZ32566@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Yea, this I like even better than what I posted. Now we just need
> a suck^H^H^H^Hprogrammer to implement a working prototype and see
> how folks like more realistic diffs generated with it. ;-)
I have to disgree.
We on the git list *live* in pretty much git-only world (ok, I
am ignoring git-svn people for now ;-)), so it might feel it
beneficial to add a new output format to git-diff.
But many users of git generated patch needs to interact with
patches that are not generated by git. I think an additional
postprocessor in patchutils/interdiff toolchest would probably
make much more sense. Then a person who reviews a patch that is
supposed to be line movement can use the filter to verify the
parts that should be only line movements are indeed are
movements and nothing else.
Speaking of "diff" output, what I would like to see is a support
of 'copied context' (i.e. traditional 'context diff' format you
would get from "diff -c"), in addition to the 'unified context'
we support. Generating copied context may help people who need
to give patches to others that accept only copied context format
patches (are there important projects that take only cpied
context format patches?). Being able to accept copied context
format patches in 'git-apply' would also be handy.
Of course, we could use interdiff to mangle copied context
format into unified context format, so 'git-apply' is not a big
deal, though.
^ 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