* Re: Using GIT to store /etc (Or: How to make GIT store all file permission bits)
From: Kyle Moffett @ 2006-12-12 13:49 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0612111837210.20138@iabervon.org>
On Dec 11, 2006, at 22:45:25, Daniel Barkalow wrote:
> The first thing you'd want to do is correct the fact that the index
> doesn't keep full permissions. We decided long ago that we don't
> want to track more than 0100, but we're discarding the rest between
> the filesystem and the index, rather than between the index and the
> tree. (This is weird of us, since we keep gid and uid in the index,
> as changedness heuristics, but don't keep permissions; of course,
> we'd have to apply umask to the index when we check it out to sync
> what we expect to be there with what has actually been created.)
>
> I think that would be the only change needed to the index and index/
> working directory connection, although it might be necessary to
> support longer values for uid/gid/etc, since they'd be important
> data now.
Hmm, ok. It would seem to be a reasonable requirement that if you
want to change any of the "preserve_*_attributes" config options you
need to blow away and recreate your index, no? I would probably
change the underlying index format pretty completely and stick a new
version tag inside it.
> Note that git only stores content, not incidental information. But
> a lot of information which is incidental in a source tree is
> content in /etc. This implies that /etc and working/linux-2.6 are
> fundamentally different sorts of things, because different aspects
> of them are content.
Ahh, I hadn't thought of it that way before but that makes a lot of
sense. Thanks!
> I'd suggest a new object type for a directory with permissions,
> ACLs, and so forth. It should probably use symbolic owner and
> group, too. My guess is that you'll want to use "commit"s, the new
> object type, and "blob"s. Everything that uses trees would need to
> have a version that uses the new type. But I think that you
> generally want different behavior anyway, so that's not a major issue.
Ok, seems straightforward enough. One other thing that crossed my
mind was figuring out how to handle hardlinks. The simplest solution
would be to add an extra layer of indirection between the "file
inode" and the "file data". Instead of your directory pointing to a
"file-data" blob and "file-attributes" object, it would point to an
"file-inode" object with embedded attribute data and a pointer to the
file contents blob.
I remember reading some discussions from the early days of GIT about
how that was considered and discarded because the extra overhead
wouldn't give any real tangible benefit. On the other hand for
something like /etc the added benefits of tracking extended
attributes and hardlinks might outweigh the cost of a bunch of extra
objects in the database. A bit of care with the construction of the
index file should make it sufficiently efficient for day-to-day usage.
If you're interested in some random musings about using GIT concepts
to version whole filesystems (think checkpointing your disk drive and
instantly restoring when you screw up), read on below, otherwise
don't bother.
Cheers,
Kyle Moffett
<Random Tangential Off-the-Wall Thought Experiment>
NOTE: This probably belongs in it's own thread but it's such a
random, undeveloped, and off-the-wall concept that I threw it in here
just for kicks.
Combining extensions like those described above with something like
the Ext3 block-allocation, inode-management and journalling code to
produce a "versioned filesystem". With the exponential growth of
storage density over the last several years we've gotten to the point
where we can many many hours of extremely realistic video and audio
on your average small-computer drive. Versioning your home
directory, or even your entire computer, even with fairly steady
modifications to multimedia files, installation of software programs,
etc, doesn't seem like such an impossible undertaking anymore.
One predefined inode would contain a list of tags/heads and their
current hashes. Mount the filesystem with a "tag=$TAG" option to
specify the initial tree object used for the root directory (with
syscalls to navigate the history). Allocate an inode per-mount to
represent any changes from the last commit.
For efficiency purposes (no need to revision the entire system when I
commit a change in my home directory) add a "subtree" object type
which can specify either a particular hash or a symbolic tag/head
name as a pseudo sub-mountpoint. Trap traversal of the sub-
mountpoint node to mount the filesystem with "tag=$SUBTAG" on the sub-
mountpoint, expiring it some time after the last traversal.
The only remaining issue would be properly navigating through the
history, preserving or discarding changes. Since the kernel could
easily manage copy-on-write semantics for underlying disk blocks you
wouldn't need a separate "working copy" except where it's modified
from the original, and discarding changes is as simple as unlinking
any files referenced by the per-mount delta inode.
Committing changes would get tricky, you would need to hot-remap
memory-mapped pages read-only while you checksum and store them. The
next write attempt would then separate the page from the freshly-
committed on-disk version. Would need a mechanism for applications
to "trap" the commit so they could make databases consistent, with
the ability for root or the mountpoint owner to commit without
waiting for synchronization. Only needs to synchronize files
belonging to the new commit. Merges would be managed from userspace,
as long as there is a way to browse through objects by hash given
sufficient permissions.
Make sure it's really easy to make a new atomic commit and/or reset
to a known state every time the computer is rebooted (whether soft-
rebooted or via crash/powerkill). With journalling and the write-
once nature of GIT it would be trivial to never require an fsck run.
Also needs a way to move data between filesystems. Makes LVM largely
irrelevant; it doesn't matter how many disks you have if they're all
treated as a shared storage pool for your GITfs data. Make sure it's
possible to archive data onto slower disks/media and purge older
commits from the archive (missing parent commit references are
tolerable in many situations). Needs a way to notice hash collisions
and take action to avoid them.
</Random Tangential Off-the-Wall Thought Experiment>
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: Tracking a repository for content instead of history
From: Andy Parkins @ 2006-12-12 13:26 UTC (permalink / raw)
To: git
In-Reply-To: <elm993$rf1$1@sea.gmane.org>
On Tuesday 2006 December 12 13:04, Jakub Narebski wrote:
> > Is it even sensible to want that? It strikes me that it's possible that
> > there isn't that much space/bandwidth saving to be made. Should I just
> > clone the repository and shut up? :-)
>
> I've had similar idea: search for "sparse clone" keyword. But no code.
While the functionality might not be built into git in terms of clone, would
there be a way to pull a particular commit from another repository?
The way I would do it given nothing else is to simply extract snapshots into a
working directory; and create a repository from scratch. I was just
wondering if a method existed that could reduce the size of the download.
I think the best way is going to be to use the patches published at kernel.org
and apply them one at a time with git-apply.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Andreas Ericsson @ 2006-12-12 13:20 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612121226.32772.andyparkins@gmail.com>
Andy Parkins wrote:
> On Tuesday 2006 December 12 11:32, Bahadir Balban wrote:
>
>> If I don't know which files I may be touching in the future for
>> implementing some feature, then I am obliged to add all the files even
>> if they are irrelevant. I said "performance reasons" assuming all the
>> file hashes need checked for every commit -a to see if they're
>> changed, but I just tried on a PIII and it seems not so slow.
>
> Here's a handy rule of thumb I've learned in my use of git:
>
> "git is fast. Really fast."
>
Almost alarmingly so. When I started using git (back in May/June last
year, when git was 2 - 3 months old), I was worried at first because it
didn't seem to actually *do* anything, but just returned me to the
prompt immediately.
>
> As to your direct concern: git doesn't hash every file at every commit. There
> is no need. git has an "index" that is used to prepare a commit; at the time
> you do the actual commit, git already knows which files are being checked in.
>
> In short - don't worry about making life easy for git - it's a workhorse and
> does a grand job.
>
Yup. Now I've gone the other way around and think other scm's are broken
when they chew disk for 10 seconds whenever I try to do anything with
them. I usually end up importing the other repo into git and do my work
there.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
^ permalink raw reply
* Re: Tracking a repository for content instead of history
From: Jakub Narebski @ 2006-12-12 13:04 UTC (permalink / raw)
To: git
In-Reply-To: <200612121235.09984.andyparkins@gmail.com>
Andy Parkins wrote:
> For interests sake I'd like to track the kernel.org linux repository.
> However, I'm not that bothered about tracking the history - it's more that I
> like to have the latest kernel release lying around.
>
> Is there a way that I could just pull individual commits from a git
> repository? In particular - could I make a repository (obviously not a
> clone, because it wouldn't have all the history) that contained only the
> tagged commits from an upstream repository?
As of beta (in 'next') you can do 'shallow clone'm i.e. clone/fetch
only N commits depth history.
> Is it even sensible to want that? It strikes me that it's possible that there
> isn't that much space/bandwidth saving to be made. Should I just clone the
> repository and shut up? :-)
I've had similar idea: search for "sparse clone" keyword. But no code.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Uninstall rule for top level Makefile
From: Andy Parkins @ 2006-12-12 12:51 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612121325000.2807@wbgn013.biozentrum.uni-wuerzburg.de>
On Tuesday 2006 December 12 12:25, Johannes Schindelin wrote:
> see http://article.gmane.org/gmane.comp.version-control.git/8682 for a
> discussion about an uninstall target.
I read that thread, but don't see its relevance. Have I missed something?
In summary:
"uninstall" is not useful in lieu of a package manager, but for developer
types (like those on this mailing list) it is useful when you install in the
wrong place (as I did just before I felt the need for an uninstall recipe).
The thread you linked to seemed to want the uninstall to not have hard-coded
filenames. That's what I did.
I assume I've missed something in the linked thread - what was it you wanted
me to pick up from it?
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* [RFC] E-mail aliases
From: Catalin Marinas @ 2006-12-12 12:49 UTC (permalink / raw)
To: GIT list
Hi,
I added a feature to StGIT (not released yet) so that one can specify
an alias instead of a complete e-mail address on the command line (or
in the template file), i.e.:
stg mail --to=lkml
sets the "To:" header to "linux-kernel@vger.kernel.org".
The aliases are read from the [aliases] section in the gitconfig files
("git repo-config aliases.lkml" in this case). I just want to make
sure than there isn't any other intended use for the [aliases] section
in the config files.
Thanks.
--
^ permalink raw reply
* git-cvsimport feature request
From: Nguyen Thai Ngoc Duy @ 2006-12-12 12:42 UTC (permalink / raw)
To: git
Well it's not really a feature but just for convenience. I suggest
after git-cvsimport successfully imports from CVS, it creates cvsup
alias with given arguments. Later if I want to update from CVS, I only
need to "git cvsup" instead of typing the the same command with full
of arguments again.
--
^ permalink raw reply
* Tracking a repository for content instead of history
From: Andy Parkins @ 2006-12-12 12:35 UTC (permalink / raw)
To: git
Hello,
For interests sake I'd like to track the kernel.org linux repository.
However, I'm not that bothered about tracking the history - it's more that I
like to have the latest kernel release lying around.
Is there a way that I could just pull individual commits from a git
repository? In particular - could I make a repository (obviously not a
clone, because it wouldn't have all the history) that contained only the
tagged commits from an upstream repository?
Is it even sensible to want that? It strikes me that it's possible that there
isn't that much space/bandwidth saving to be made. Should I just clone the
repository and shut up? :-)
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Jakub Narebski @ 2006-12-12 12:36 UTC (permalink / raw)
To: git
In-Reply-To: <7ac1e90c0612120205k38b2fc14jbfd8ea682406efb2@mail.gmail.com>
Bahadir Balban wrote:
> When I initialise a git repository, I use a subset of files in the
> project and leave out irrelevant files for performance reasons. Then
> when I need to make changes to a file not yet in the repository, the
> file is treated as new, and if I reset the change or change branches
> the file is gone.
>
> Is there a good way of adding new files to git as if they had existed
> from the initial commit (or even better, since a particular commit)?
> This way I would only track the new changes I made to an existing
> file.
Generally, it is not possible without rewriting history. In git (in any
sane SCM) commits are atomic; there is no CVS-like bunch of per-file
histories. You can use cg-admin-rewritehist from Cogito (alternate UI
for git)... but as it was said somewhere else git is fast. And the rule
of thumb: check first, then optimize.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: trouble with git cvsimport
From: Ian Molton @ 2006-12-12 12:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <457E6774.20707@op5.se>
Andreas Ericsson wrote:
> Does linux/kernel26/.git/.git exists? I managed to get something similar
> once and it had me confused a loong time.
^ permalink raw reply
* Re: stgit: stg mail
From: Catalin Marinas @ 2006-12-12 12:32 UTC (permalink / raw)
To: Bahadir Balban; +Cc: git
In-Reply-To: <7ac1e90c0612120412i1297ce05uecbeea1107b8c704@mail.gmail.com>
"Bahadir Balban" <bahadir.balban@gmail.com> wrote:
> I couldn't succeed in getting stg mail produce an mbox file with a
> Signed-off-by line (using stgit 0.11).
>
> stg mail -m --to=user@mail.com patchname > patchname.diff
>
> works OK. If I add the template with Signed-off-by I get:
>
> stg mail -m --to=user@mail.com -t ~/patch.tmpl patchname > patchname.diff
> stg mail: No "From" address
Your template is wrong since it doesn't have a "From:" line. You would
have to use the templates/patchmail.tmpl as a starting point.
BTW, I prefer to add the "signed-off-by" line in the patch description
rather than automatically (blindly) append it to every e-mailed patch.
--
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Andy Parkins @ 2006-12-12 12:26 UTC (permalink / raw)
To: git
In-Reply-To: <7ac1e90c0612120332o20d6778bsa16a788fdc04a3a1@mail.gmail.com>
On Tuesday 2006 December 12 11:32, Bahadir Balban wrote:
> If I don't know which files I may be touching in the future for
> implementing some feature, then I am obliged to add all the files even
> if they are irrelevant. I said "performance reasons" assuming all the
> file hashes need checked for every commit -a to see if they're
> changed, but I just tried on a PIII and it seems not so slow.
Here's a handy rule of thumb I've learned in my use of git:
"git is fast. Really fast."
That'll hold you in good stead. In my experience there is no operation in git
that is slow. I've got some trees that are for embedded work and hold the
whole linux kernel, often more than once. Subversion, which I used
previously, took literally hours to import the whole tree. Git takes
minutes.
As to your direct concern: git doesn't hash every file at every commit. There
is no need. git has an "index" that is used to prepare a commit; at the time
you do the actual commit, git already knows which files are being checked in.
Obviously, Linus uses git for managing the linux kernel, he's said before
that he wanted a version control system that can do multiple commits /per
second/. git can do that.
In short - don't worry about making life easy for git - it's a workhorse and
does a grand job.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* Re: [PATCH] Uninstall rule for top level Makefile
From: Johannes Schindelin @ 2006-12-12 12:25 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612112214.09735.andyparkins@gmail.com>
Hi,
see http://article.gmane.org/gmane.comp.version-control.git/8682 for a
discussion about an uninstall target.
Ciao,
Dscho
^ permalink raw reply
* stgit: stg mail
From: Bahadir Balban @ 2006-12-12 12:12 UTC (permalink / raw)
To: git
Hi,
I couldn't succeed in getting stg mail produce an mbox file with a
Signed-off-by line (using stgit 0.11).
stg mail -m --to=user@mail.com patchname > patchname.diff
works OK. If I add the template with Signed-off-by I get:
stg mail -m --to=user@mail.com -t ~/patch.tmpl patchname > patchname.diff
stg mail: No "From" address
Also tried -c with same result.
Config file:
[stgit]
# Default author/committer details
authname: name surname
authemail: user@mail.com
commname: user@mail.com
commemail: user@mail.com
I guess it expects to find everything in the template? How do you
normally supply signoff field?
Thanks,
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Johannes Schindelin @ 2006-12-12 12:07 UTC (permalink / raw)
To: Bahadir Balban; +Cc: git
In-Reply-To: <7ac1e90c0612120332o20d6778bsa16a788fdc04a3a1@mail.gmail.com>
Hi,
On Tue, 12 Dec 2006, Bahadir Balban wrote:
> On 12/12/06, Junio C Hamano <junkio@cox.net> wrote:
> > No.
> >
> > I do not understand why not adding all the files you care about
> > eventually anyway in the initial commit is needed for
> > "performance reasons", if you do not touch majority of them for
> > a long time. Care to explain?
>
> If I don't know which files I may be touching in the future for
> implementing some feature,
When I use an SCM, it is to track the revisions of a project. It seems you
are content to have only parts of a revision? That does not make sense to
me.
> I said "performance reasons" assuming all the file hashes need checked
> for every commit -a to see if they're changed, but I just tried on a
> PIII and it seems not so slow.
Bingo!
You just felt the consequences of the "index".
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Allow building GIT in a different directory from the source directory
From: Han-Wen Nienhuys @ 2006-12-12 11:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbqm9xz8z.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano escreveu:
> Han-Wen Nienhuys <hanwen@xs4all.nl> writes:
>
>> GIT can now be built in a separate builddirectory. This is done as
>> follows:
>>
>> mkdir build
>> cd build
>> $my_git_dir/configure
>> make
>
> Somehow making this depend on the use of configure feels wrong,
> since we tried to keep that config.mak.gen built by configure
> strictly optional. In other words, I think the result of your
> patch should be buildable with or without ./configure in a
> separate directory if we are going to do this.
>
> Care to explain why it is too cumbersome to handle without
> ./configure magic?
I already tried to explain in a previous thread on the list.
See
http://article.gmane.org/gmane.comp.version-control.git/33487
you can still build git in the same directory as source
without using autoconf, and plain make.
If you insist, I can create a separate
setup-builddir.sh
to setup the build directory; according to the principle of least
surprise, it should happen in the configure script though.
I still don't understand the problem with autoconf; there are already
plenty of baroque shell scripts in GIT. I hate writing m4 macros as
well, but that's not a problem for GIT users (ie. people who compile
GIT).
For them,
./configure ; make ; make check ; make install
is actually the standard way to compile stuff.
--
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Bahadir Balban @ 2006-12-12 11:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vhcw1whfx.fsf@assigned-by-dhcp.cox.net>
On 12/12/06, Junio C Hamano <junkio@cox.net> wrote:
> No.
>
> I do not understand why not adding all the files you care about
> eventually anyway in the initial commit is needed for
> "performance reasons", if you do not touch majority of them for
> a long time. Care to explain?
If I don't know which files I may be touching in the future for
implementing some feature, then I am obliged to add all the files even
if they are irrelevant. I said "performance reasons" assuming all the
file hashes need checked for every commit -a to see if they're
changed, but I just tried on a PIII and it seems not so slow.
^ permalink raw reply
* Re: [RFC/PATCH] runstatus: restructure visual appearance
From: Lars Hjemli @ 2006-12-12 11:30 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
In-Reply-To: <11650882251452-git-send-email-hjemli@gmail.com>
On 12/2/06, Lars Hjemli <hjemli@gmail.com> wrote:
> This is a rather subjective 'improvement', but I think it makes the commit
> message easier to comprehend and I hope that goes for both new and
> experienced users.
Just wondering if this patch got dropped or simply overlooked...
If dropped, sorry for the noise
--
^ permalink raw reply
* Re: index manipulation quickref
From: Santi Béjar @ 2006-12-12 11:28 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf0612120257p35dc9483ob65eea9ae21b5f7b@mail.gmail.com>
On 12/12/06, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> Hi,
>
> I'm trying to collect all operations related to index from user
> perspective and corresponding commands. The list may be put to git
> wiki if people think it can help newbies:
Cool. But for "index-newbies" not "git-newbies" :)
We could add (if exists) the porcelain-ish equivalent as:
update file content to index:
git update-index file
git add file (the development version)
add a file to index:
git update-index --add file
git add file
delete a file from index:
git update-index --remove [--force-remove] file
git rm file
read a tree to index:
git read-tree treeish
git reset commit-ish # It changes also the HEAD
read a file from a tree to index:
git ls-tree treeish file | git update-index --index-info --stdin
N/A
copy a file from index to workdir:
git checkout-index file
git checkout file
refresh index:
git update-index --refresh
git status # It does more things
copy entire index to workdir:
git checkout-index
git checkout -f
output a file from index to stdout:
git cat-file blob :file (or :n:file, where n=0,1,2,3 are the unmerged stage)
??
list files in index:
git ls-files
??
compare index and workdir file listing:
git ls-files (with lots of options here)
git status?
diff between workdir and index:
git diff-files
git diff
diff between index and a tree:
git diff-index --cached treeish
git diff --cached treeish
^ permalink raw reply
* Re: index manipulation quickref
From: Jakub Narebski @ 2006-12-12 11:16 UTC (permalink / raw)
To: git
In-Reply-To: <fcaeb9bf0612120257p35dc9483ob65eea9ae21b5f7b@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> I'm trying to collect all operations related to index from user
> perspective and corresponding commands. The list may be put to git
> wiki if people think it can help newbies:
>
> update file content to index: git update-index file
Or "git add file" woth new git.
> add a file to index: git add file
> delete a file from index: git update-index --remove --force-remove
> (or remove that file in workdir and do git update-index --remove)
Or "git rm file" (old version did remove only from index, new version
is to remove also from working directory if it matches HEAD)
> read a tree to index: git read-tree treeish, git reset treeish
> read a file from a tree to index: git ls-tree <tree-ish> file|git
> update-index --index-info --stdin
> copy a file from index to workdir: git checkout-index file
Or just "git checkout -- file"
> refresh index: git update-index --refresh
> copy entire index to workdir: git checkout-index
Or just "git checkout"
> output a file from index to stdout: ?? (is there a command for this?)
"git cat-file -p ::<filename>"
> list files in index: git ls-files
> compare index and workdir file listing:
> git ls-files (with lots of options here)
> diff between workdir and index: git diff
> diff between index and a tree: git diff --cached <tree-ish>
diff between workdir and tree: git diff <tree-ish>
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Andy Parkins @ 2006-12-12 11:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vpsapwhl2.fsf@assigned-by-dhcp.cox.net>
On Tuesday 2006 December 12 10:10, Junio C Hamano wrote:
> Even without red-green blindness issue, I think that makes
> sense. colored-diff uses green/red for added/deleted but that
I certainly don't have any objection. For me, the use of colour is not to
make things look pretty it's to give visual queues.
> is shown against the context in plain. A sane thing to do for
> branch listing would be to show the usual case (i.e. local) in
> plain and show the remote ones differently.
The only reason I picked red and green was to indicate "can be checked out"
and "cannot be checked out". However, when git eventually allows arbitrary
commits to be checked out that green/red, can/can't distinction will be
meaningless anyway.
> + "", /* LOCAL (normal) */
> + "\033[32m", /* CURRENT (green) */
In keeping with the "don't use green" idea - can I suggest just bold normal
for the CURRENT? That way there is the most minimal use of colour for the
default git-branch output, but still retaining a visual indicator.
Andy
--
Dr Andy Parkins, M Eng (hons), MIEE
^ permalink raw reply
* index manipulation quickref
From: Nguyen Thai Ngoc Duy @ 2006-12-12 10:57 UTC (permalink / raw)
To: git
Hi,
I'm trying to collect all operations related to index from user
perspective and corresponding commands. The list may be put to git
wiki if people think it can help newbies:
update file content to index: git update-index file
add a file to index: git add file
delete a file from index: git update-index --remove --force-remove (or
remove that file in workdir and do git update-index --remove)
read a tree to index: git read-tree treeish, git reset treeish
read a file from a tree to index: git ls-tree treeish file|git
update-index --index-info --stdin
copy a file from index to workdir: git checkout-index file
refresh index: git update-index --refresh
copy entire index to workdir: git checkout-index
output a file from index to stdout: ?? (is there a command for this?)
list files in index: git ls-files
compare index and workdir file listing: git ls-files (with lots of options here)
diff between workdir and index: git diff
diff between index and a tree: git diff --cached treeish
Am I missing any operation here?
--
^ permalink raw reply
* Re: Adding a new file as if it had existed
From: Junio C Hamano @ 2006-12-12 10:13 UTC (permalink / raw)
To: Bahadir Balban; +Cc: git
In-Reply-To: <7ac1e90c0612120205k38b2fc14jbfd8ea682406efb2@mail.gmail.com>
"Bahadir Balban" <bahadir.balban@gmail.com> writes:
> Is there a good way of adding new files to git as if they had existed
> from the initial commit (or even better, since a particular commit)?
> This way I would only track the new changes I made to an existing
> file.
No.
I do not understand why not adding all the files you care about
eventually anyway in the initial commit is needed for
"performance reasons", if you do not touch majority of them for
a long time. Care to explain?
^ permalink raw reply
* Re: [PATCH] Colourise git-branch output
From: Junio C Hamano @ 2006-12-12 10:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Andy Parkins
In-Reply-To: <457E6C65.4B6D131@eudaptics.com>
Johannes Sixt <J.Sixt@eudaptics.com> writes:
> Andy Parkins wrote:
>> This patch chooses green for local, red for remote and bold green for
>> current.
>
> Sorry for chiming in so late, but red and green are usually poor choices
> since red-green color-blindness is surprisingly frequent...
>
> Maybe its sufficient to have just the remote branches (dark-)red, and
> the rest in the default color, with the current branch bold?
Even without red-green blindness issue, I think that makes
sense. colored-diff uses green/red for added/deleted but that
is shown against the context in plain. A sane thing to do for
branch listing would be to show the usual case (i.e. local) in
plain and show the remote ones differently.
Something like this on top of Andy's?
If we keep '*' prefix for the current one, I do not see a reason
to show it in a different color from other local branches, by
the way, but I did not go that far in this patch.
---
diff --git a/builtin-branch.c b/builtin-branch.c
index 7c87b8d..d1c243d 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -23,8 +23,8 @@ static char branch_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
"", /* PLAIN (normal) */
"\033[31m", /* REMOTE (red) */
- "\033[32m", /* LOCAL (green) */
- "\033[1;32m", /* CURRENT (boldgreen) */
+ "", /* LOCAL (normal) */
+ "\033[32m", /* CURRENT (green) */
};
enum color_branch {
COLOR_BRANCH_RESET = 0,
^ permalink raw reply related
* Adding a new file as if it had existed
From: Bahadir Balban @ 2006-12-12 10:05 UTC (permalink / raw)
To: git
Hi,
When I initialise a git repository, I use a subset of files in the
project and leave out irrelevant files for performance reasons. Then
when I need to make changes to a file not yet in the repository, the
file is treated as new, and if I reset the change or change branches
the file is gone.
Is there a good way of adding new files to git as if they had existed
from the initial commit (or even better, since a particular commit)?
This way I would only track the new changes I made to an existing
file.
Thanks,
^ 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