* Re: Collection of stgit issues and wishes
From: Jakub Narebski @ 2006-12-12 10:02 UTC (permalink / raw)
To: git
In-Reply-To: <b0943d9e0612120143j7d0c1026rab046c8f44ec43ca@mail.gmail.com>
Catalin Marinas wrote:
> On 08/12/06, Yann Dirson <ydirson@altern.org> wrote:
>> - shortcuts (st -> status, etc.), possibly making use of the git alias
>> system ?
>
> Did this last night as it was pretty easy and without the GIT alias
> system (which I am not familiar with). The idea is that if it cannot
> find an exact match, it tries to look for all the commands starting
> with the passed argument. If more than one command is found, it
> reports an "ambiguous command".
Isn't it better to use tab completion for that?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* 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
* 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
* 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
* 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: [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
* 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: 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: [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: 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: [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: 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
* 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: [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
* 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: 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: 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: 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
* 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
* 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
* [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
* 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
* 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: 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: 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
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