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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
| David Miller | [GIT]: Networking |
| Fred . | Please add ZFS support (from GPL sources) |
| Krzysztof Halasa | [PATCH 0/3] Intel IXP4xx network drivers |
| Jon Ivar Rykkelid | sata_nv issues with MCP51 SATA controller |
git: | |
| Thomas Glanzmann | GIT Packages for Debian Etch |
| Paolo Ciarrocchi | UI and git-completion.sh |
| Shawn Pearce | Error writing loose object on Cygwin |
| Nicolas Pitre | Re: If you would write git from scratch now, what would you change? |
| Marco Peereboom | Re: Real men don't attack straw men |
| Brandon Lee | DELL PERC 5iR slow performance |
| GVG GVG | ssh_exchange_identification: Connection closed by remote host |
| Marco Peereboom | Re: how to undelete? |
| Jim Winstead Jr. | Re: Root Disk/Book Disk Compatibility |
| Doug Evans | Re: Stabilizing Linux |
| Desmond A. Kirkpatrick | ATI GUP bug with Linux 'tickler' |
| H.J. Lu | Re: ksh has no 'up arrow' command recall |
