* Re: git-format-patch + git-applymbox small issue
From: Johannes Schindelin @ 2005-08-17 17:32 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050817171844.57566.qmail@web26301.mail.ukl.yahoo.com>
Hi,
On Wed, 17 Aug 2005, Marco Costalba wrote:
> P.S: I say 'revision', and 'git archive' but are very common also
> 'commit' and 'git repository'. This is just a silly example where a
> common dictionary should be useful.
How about the glossary, which I posted a few hours ago?
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-17 17:35 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Catalin Marinas wrote:
>
>Once you want a subset of these patches merged into MAIN, just pop
>everything from the stack and only push those you want merged, in the
>order you want (if there are some dependencies, the push will fail and
>you can correct them or the order). When you are happy with the
>patches pushed on the stack, just do a 'git pull <HEAD>' in the MAIN
>repository. After this, doing a 'stg pull <MAIN>' in the HEAD one will
>mark the patches already integrated into MAIN as empty and you can
>safely remove them ('stg clean' does this automatically).
>
>This way I found StGIT useful for maintainers as well, not only for
>contributors.
>
Sorry if the answer is silly, but I still don't know well StGIT .
What you describe it's an asymmetrical or one way scenario, new code
goes always from HEAD to MAIN. But how is the workflow if:
1) There is more then one contributor feeding MAIN and you need to update
the StGIT patch stack from MAIN.
2) You made something terribly wrong with HEAD (I don't know what can be
'terribly wrong') and you need to recreate a clean base from MAIN.
In this cases, if I understand correctly, you need to clone a new StGIT archive from
MAIN and push the interesting stuff from old/broken HEAD.
Or you can always merge back pulling from MAIN as in case of two pure git archives?
Thanks
Marco
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Jeff Garzik @ 2005-08-17 17:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In-Reply-To: <7vk6il2jz8.fsf_-_@assigned-by-dhcp.cox.net>
If someone is thus motivated, I have two requests in this area:
1) Fix applymbox such that it understands RFC822-valid Subject lines
which wrap across multiple text lines.
2) Teach it to understand MIME, and not treat the MIME headers like part
of the message.
^ permalink raw reply
* Re: git-format-patch + git-applymbox small issue
From: Marco Costalba @ 2005-08-17 17:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
Johannes Schindelin wrote:
>Hi,
>
>On Wed, 17 Aug 2005, Marco Costalba wrote:
>
>>P.S: I say 'revision', and 'git archive' but are very common also
>>'commit' and 'git repository'. This is just a silly example where a
>>common dictionary should be useful.
>
>
>How about the glossary, which I posted a few hours ago?
>
>Ciao,
>Dscho
>
>
Yeah, I missed it.
Sorry for the noise.
By the way, a very good and useful job.
>
>revision::
> A particular state of files and directories which was stored in
> the object database. It is referenced by a commit object.
>
>
>commit object::
> An object which contains the information about a particular
> revision, such as parents, committer, author, date and the
> tree object which corresponds to the top directory of the
> stored revision.
>
So 'revision' is the struct and 'commit object' the pointer ;-)
>
>repository::
> A collection of refs together with an object database containing
> all objects, which are reachable from the refs. A repository can
> share an object database with other repositories.
>
In a lot of git documentation, starting from the tutorial, it is used 'git archive'
but peraphs 'repository' is more a standard definition for an SCM archive.
Just archive peraphs is too generic, also a tarball is an archive :-)
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Marco Costalba @ 2005-08-17 18:03 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
Marco Costalba wrote:
>>
>>This way I found StGIT useful for maintainers as well, not only for
>>contributors.
>>
>
>Sorry if the answer is silly, but I still don't know well StGIT .
>
'question' not 'answer' !!!!
I don't now if the question is silly, but the typo it is for sure!
Sorry
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: First stab at glossary
From: Daniel Barkalow @ 2005-08-17 19:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508171655250.13502@wgmdd8.biozentrum.uni-wuerzburg.de>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 6425 bytes --]
On Wed, 17 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> long, long time. Here´s my first stab at the glossary, attached the
> alphabetically sorted, asciidoc marked up txt file (Comments?
> Suggestions? Pizzas?):
>
> object::
> The unit of storage in GIT. It is uniquely identified by
> the SHA1 of its contents. Consequently, an object can not
> be changed.
>
> SHA1::
> A 20-byte sequence (or 41-byte file containing the hex
> representation and a newline). It is calculated from the
> contents of an object by the Secure Hash Algorithm 1.
It's also often 40-character string (with whatever termination) in places
like commit objects, tag objects, command-line arguments, listings, and so
forth.
> object database::
> Stores a set of "objects", and an individial object is identified
> by its SHA1 (its ref). The objects are either stored as single
> files, or live inside of packs.
>
> object name::
> Synonym for SHA1.
Have we killed the use of the third term "hash" for this? I'd say that
"object name" is the standard term, and "SHA1" is a nickname, if only
because "object name" is more descriptive of the particular use of the
term.
> blob object::
> Untyped object, i.e. the contents of a file.
This "i.e." should be "e.g.", since symlink targets are also stored as
blobs, and any other bulk data stored by itself would be. (IIRC, Junio has
a tagged blob to hold his public key, for example)
> tree object::
> An object containing a list of blob and/or tree objects.
> (A tree usually corresponds to a directory without
> subdirectories).
>
> tree::
> Either a working tree, or a tree object together with the
> dependent blob and tree objects (i.e. a stored representation
> of a working tree).
>
> cache::
> A collection of files whose contents are stored as objects.
> The cache is a stored version of your working tree. Well, can
> also contain a second, and even a third version of a working
> tree, which are used when merging.
>
> cache entry::
> The information regarding a particular file, stored in the index.
> A cache entry can be unmerged, if a merge was started, but not
> yet finished (i.e. if the cache contains multiple versions of
> that file).
>
> index::
> Contains information about the cache contents, in particular
> timestamps and mode flags ("stat information") for the files
> stored in the cache. An unmerged index is an index which contains
> unmerged cache entries.
I think we might want to entirely kill the "cache" term, and talk only
about the "index" and "index entries". Of course, a bunch of the code will
have to be renamed to make this completely successful, but we could change
the glossary and documentation, and mention "cache" and "cache entry" as
old names for "index" and "index entry" respectively.
> working tree::
> The set of files and directories currently being worked on.
> Think "ls -laR"
This is where the data is actually in the filesystem, and you can edit and
compile it (as opposed to a tree object or the index, which semantically
have the same contents, but aren't presented in the filesystem that way).
> directory::
> The list you get with "ls" :-)
>
> checkout::
> The action of updating the working tree to a revision which was
> stored in the object database.
Move after "revision"?
> revision::
> A particular state of files and directories which was stored in
> the object database. It is referenced by a commit object.
>
> commit::
> The action of storing the current state of the cache in the
> object database. The result is a revision.
>
> commit object::
> An object which contains the information about a particular
> revision, such as parents, committer, author, date and the
> tree object which corresponds to the top directory of the
> stored revision.
Move "parent" around here.
> changeset::
> BitKeeper/cvsps speak for "commit". Since git does not store
> changes, but states, it really does not make sense to use
> the term "changesets" with git.
>
> ent::
> Favorite synonym to "tree-ish" by some total geeks.
Move after "tree-ish".
> head::
> The top of a branch. It contains a ref to the corresponding
> commit object.
>
> branch::
> A non-cyclical graph of revisions, i.e. the complete history of
> a particular revision, which does not (yet) have children, which
> is called the branch head. The branch heads are stored in
> $GIT_DIR/refs/heads/.
A branch head might have children, if they're in another branch. (E.g., I
pull mainline, make a new branch based on it, and commit a change; the
head of mainline is still a branch head, even though it's the parent of my
new commit, because my new commit isn't in mainline.)
> ref::
> A 40-byte hex representation of a SHA1 pointing to a particular
> object. These are stored in $GIT_DIR/refs/.
>
> head ref::
> A ref pointing to a head. Often, this is abbreviated to "head".
> Head refs are stored in $GIT_DIR/refs/heads/.
>
> tree-ish::
> A ref pointing to either a commit object, a tree object, or a
> tag object pointing to a commit or tree object.
>
> tag object::
> An object containing a ref pointing to another object. It can
> contain a (PGP) signature, in which case it is called "signed
> tag object".
>
> tag::
> A ref pointing to a tag or commit object. In contrast to a head,
> a tag is not changed by a commit. Tags (not tag objects) are
> stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
> a Lisp tag (which is called object type in git's context).
As above, only the head for the branch being committed to is changed by a
commit. A tag, not being the head of a branch, is therefore never changed
by a commit.
> merge::
> To merge branches means to try to accumulate the changes since a
> common ancestor and apply them to the first branch. An automatic
> merge uses heuristics to accomplish that. Evidently, an automatic
> merge can fail.
>
> resolve::
> The action of fixing up manually what a failed automatic merge
> left behind.
"Resolve" is also used for the automatic case (e.g., in
"git-resolve-script", which goes from having two commits and a message to
having a new commit). I'm not sure what the distinction is supposed to be.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git-format-patch + git-applymbox small issue
From: Junio C Hamano @ 2005-08-17 19:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508171931130.8623@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Hi,
>
> On Wed, 17 Aug 2005, Marco Costalba wrote:
>
>> P.S: I say 'revision', and 'git archive' but are very common also
>> 'commit' and 'git repository'. This is just a silly example where a
>> common dictionary should be useful.
I think 'commit' and 'repository' are more commonly seen here.
> How about the glossary, which I posted a few hours ago?
Which is very good. Thanks. Mind if I put it under
Documentation/ in its current shape?
^ permalink raw reply
* Re: git-format-patch + git-applymbox small issue
From: Junio C Hamano @ 2005-08-17 19:26 UTC (permalink / raw)
To: Marco Costalba, Johannes Schindelin; +Cc: git
In-Reply-To: <20050817175452.84541.qmail@web26306.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
>>revision::
>> A particular state of files and directories which was stored in
>> the object database. It is referenced by a commit object.
>>
>>commit object::
>> An object which contains the information about a particular
>> revision, such as parents, committer, author, date and the
>> tree object which corresponds to the top directory of the
>> stored revision.
> So 'revision' is the struct and 'commit object' the pointer ;-)
It would be more like "revision" is a concept represented (not
"referenced") by a commit object.
>>repository::
>> A collection of refs together with an object database containing
>> all objects, which are reachable from the refs. A repository can
>> share an object database with other repositories.
>>
>
> In a lot of git documentation, starting from the tutorial, it is used 'git archive'
> but peraphs 'repository' is more a standard definition for an SCM archive.
> Just archive peraphs is too generic, also a tarball is an archive :-)
Agreed. I personally think the word "archive" on this list came
from people who have some degree of tla background. CVS and SVN
people would have said repository.
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Junio C Hamano @ 2005-08-17 19:26 UTC (permalink / raw)
To: Jeff Garzik; +Cc: git
In-Reply-To: <430375B3.3050307@pobox.com>
Jeff Garzik <jgarzik@pobox.com> writes:
> 1) Fix applymbox such that it understands RFC822-valid Subject lines
> which wrap across multiple text lines.
I thought I did this in mailinfo (read_one_header() function)
some time ago. I'd appreciate it if you could point me at a
sample message that fails to get processed correctly.
> 2) Teach it to understand MIME, and not treat the MIME headers like part
> of the message.
I share the same gripe; I always end up running applymbox -q and
hand-fixing things for this reason.
^ permalink raw reply
* Re: [PATCH] Change git-branch to list branches
From: Kalle Valo @ 2005-08-17 19:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslx98ua0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> I do not think we have agreed to limit ourselves to a flat
> namespace under refs/heads without subdirectories. Something
> like what git-show-branches-script does when $# == 0, perhaps?
I didn't realise this. I'll send a revised patch soon.
--
Kalle Valo
^ permalink raw reply
* Re: git-format-patch + git-applymbox small issue
From: Johannes Schindelin @ 2005-08-17 19:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsscweou.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 17 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Wed, 17 Aug 2005, Marco Costalba wrote:
> >
> >> P.S: I say 'revision', and 'git archive' but are very common also
> >> 'commit' and 'git repository'. This is just a silly example where a
> >> common dictionary should be useful.
>
> I think 'commit' and 'repository' are more commonly seen here.
>
> > How about the glossary, which I posted a few hours ago?
>
> Which is very good. Thanks. Mind if I put it under
> Documentation/ in its current shape?
I'd be honoured! Though I think that peu a peu, useful suggestions trickle
in. But I can handle these as a patch, right?
Ciao,
Dscho
^ permalink raw reply
* Re: git-format-patch + git-applymbox small issue
From: Johannes Schindelin @ 2005-08-17 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Marco Costalba, git
In-Reply-To: <7vll30wejs.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 17 Aug 2005, Junio C Hamano wrote:
> Marco Costalba <mcostalba@yahoo.it> writes:
>
> > So 'revision' is the struct and 'commit object' the pointer ;-)
>
> It would be more like "revision" is a concept represented (not
> "referenced") by a commit object.
Actually, I think it is "referenced", because the commit object contains a
little metadata, and then only refs (pointers).
> Agreed. I personally think the word "archive" on this list came
> from people who have some degree of tla background. CVS and SVN
> people would have said repository.
I'll add it anyway.
Ciao,
Dscho
^ permalink raw reply
* Re: git-format-patch + git-applymbox small issue
From: Johannes Schindelin @ 2005-08-17 19:55 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050817175452.84541.qmail@web26306.mail.ukl.yahoo.com>
Hi,
On Wed, 17 Aug 2005, Marco Costalba wrote:
> Johannes Schindelin wrote:
>
> > [...]
> >
> By the way, a very good and useful job.
Thank you! While I think it is one of the less-fun and less-think jobs, it
might be good to have it for people o look it up all the time.
> So 'revision' is the struct and 'commit object' the pointer ;-)
As I said in another mail: Yes!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Linus Torvalds @ 2005-08-17 19:56 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Junio C Hamano, git
In-Reply-To: <430375B3.3050307@pobox.com>
On Wed, 17 Aug 2005, Jeff Garzik wrote:
>
> 1) Fix applymbox such that it understands RFC822-valid Subject lines
> which wrap across multiple text lines.
It already should do this.
> 2) Teach it to understand MIME, and not treat the MIME headers like part
> of the message.
But this one I really realyl disagree with.
The fact is, anybody who doesn't edit the emails that come in is BROKEN.
There are two kinds of emails:
- the nicely formatted ones where the author follows all the rules
This kind of email doesn't need MIME decoding anyway.
- the others
This kind might need MIME decoding, but since it _also_ needs
hand-editing to remove all the "Hi, please apply this patch" etc crud
that inevitably go along with this kind of patch, trying to handle it
automatically is WRONG WRONG WRONG.
And if it's mime-encoded you often have trouble editing it anyway.
Ergo: if somebody sends you mime-encoded patches, hit them with a baseball
bat (politely) and teach them not to do that. "Fixing" the tools really
will just make things worse if it means that you apply raw emails without
having edited them.
Linus
^ permalink raw reply
* Re: First stab at glossary
From: Johannes Schindelin @ 2005-08-17 20:05 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508171341380.23242@iabervon.org>
Hi,
On Wed, 17 Aug 2005, Daniel Barkalow wrote:
> On Wed, 17 Aug 2005, Johannes Schindelin wrote:
>
> > SHA1::
> > A 20-byte sequence (or 41-byte file containing the hex
> > representation and a newline). It is calculated from the
> > contents of an object by the Secure Hash Algorithm 1.
>
> It's also often 40-character string (with whatever termination) in places
> like commit objects, tag objects, command-line arguments, listings, and so
> forth.
Okay.
> > object name::
> > Synonym for SHA1.
>
> Have we killed the use of the third term "hash" for this? I'd say that
> "object name" is the standard term, and "SHA1" is a nickname, if only
> because "object name" is more descriptive of the particular use of the
> term.
Okay for "hash". What is the consensus on "object name" being more
standard than "SHA1"?
> > blob object::
> > Untyped object, i.e. the contents of a file.
>
> This "i.e." should be "e.g.", since symlink targets are also stored as
> blobs, and any other bulk data stored by itself would be. (IIRC, Junio has
> a tagged blob to hold his public key, for example)
Agree.
> I think we might want to entirely kill the "cache" term, and talk only
> about the "index" and "index entries". Of course, a bunch of the code will
> have to be renamed to make this completely successful, but we could change
> the glossary and documentation, and mention "cache" and "cache entry" as
> old names for "index" and "index entry" respectively.
For me, "index" is just the file named "index" (holding stat data and a
ref for each cache entry). That is why I say an "index" contains "cache
entries", not "index entries" (wee, that sounds wrong :-).
> > working tree::
> > The set of files and directories currently being worked on.
> > Think "ls -laR"
>
> This is where the data is actually in the filesystem, and you can edit and
> compile it (as opposed to a tree object or the index, which semantically
> have the same contents, but aren't presented in the filesystem that way).
Maybe I was too cautious. Linus very new idea was to think of the lowest
level of an SCM as a file system. But I did not want to mention that.
Thinking of it again, maybe I should.
> > checkout::
>
> Move after "revision"?
Ultimately, the glossary terms will be sorted alphabetically. If you look
at the file attached to my original mail, this is already sorted and
marked up using asciidoc. However, I wanted you and the list to understand
how I grouped terms. The asciidoc'ed file is generated by a perl script.
> Move "parent" around here.
See above.
> Move after "tree-ish".
Ditto.
> > branch::
> > A non-cyclical graph of revisions, i.e. the complete history of
> > a particular revision, which does not (yet) have children, which
> > is called the branch head. The branch heads are stored in
> > $GIT_DIR/refs/heads/.
>
> A branch head might have children, if they're in another branch. (E.g., I
> pull mainline, make a new branch based on it, and commit a change; the
> head of mainline is still a branch head, even though it's the parent of my
> new commit, because my new commit isn't in mainline.)
Well noted! I'll just delete that part.
> > tag::
> > A ref pointing to a tag or commit object. In contrast to a head,
> > a tag is not changed by a commit. Tags (not tag objects) are
> > stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
> > a Lisp tag (which is called object type in git's context).
>
> As above, only the head for the branch being committed to is changed by a
> commit. A tag, not being the head of a branch, is therefore never changed
> by a commit.
I tried to say that.
> > resolve::
> > The action of fixing up manually what a failed automatic merge
> > left behind.
>
> "Resolve" is also used for the automatic case (e.g., in
> "git-resolve-script", which goes from having two commits and a message to
> having a new commit). I'm not sure what the distinction is supposed to be.
I did not like that naming anyway. In reality, git-resolve-script does not
resolve anything, but it merges two revisions, possibly leaving something
to resolve.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Change git-branch to list branches
From: Kalle Valo @ 2005-08-17 20:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <87br3w73at.fsf@litku.valo.iki.fi>
Kalle Valo <Kalle.Valo@iki.fi> writes:
> Junio C Hamano <junkio@cox.net> writes:
>
>> I do not think we have agreed to limit ourselves to a flat
>> namespace under refs/heads without subdirectories. Something
>> like what git-show-branches-script does when $# == 0, perhaps?
>
> I didn't realise this. I'll send a revised patch soon.
Ah, but you fixed it already. Thanks!
--
Kalle Valo
^ permalink raw reply
* Re: [PATCH] Add git-branches-script
From: Miguel Bazdresch @ 2005-08-17 20:37 UTC (permalink / raw)
To: git
In-Reply-To: <20050815204430.GA77829@rossby.metr.ou.edu>
* Amos Waterland <apw@rossby.metr.ou.edu> [2005-08-16 00:48]:
> For people whose workflow involves switching back and forth between a
> lot of branches, it can be really helpful to be able to quickly tell
> which branch you are on and which ones are available. This patch
> introduces a small script that when invoked as `git branches' prints a
> list of available branches with a star in front of the one you are on:
>
> $ cd linux-2.6/
> $ git checkout -b ppc64-cleanups
> $ git checkout -b ppc64-new-devel
> $ git checkout -b ppc64-all-merge
> $ git branches
> master
> * ppc64-all-merge
> ppc64-cleanups
> ppc64-new-devel
Some might find it useful to put Amos' script in a bash function and
then put the current branch in the prompt. What I did was to put this
function in my .bashrc:
gitbranch () {
. git-sh-setup-script &&
branch=$(basename $(readlink $GIT_DIR/HEAD)) &&
echo -n "" $branch ""
}
Then I modified my bash prompt:
export PS1='\[\033[1;31m\]\j$(gitbranch)[\w]\$ \[\033[0m\]'
^^^^^^^^^^^
Now, if my current dir is not a git repo, I have my regular prompt. As
soon as I cd into a git repo, I get the current branch in the prompt, as
follows:
0[~]$ cd gitrepo
0 master [~/gitrepo]$ git checkout branch1
0 branch1 [~/gitrepo]$ cd ..
0[~]$
--
Miguel Bazdresch
http://thewizardstower.org/
^ permalink raw reply
* [PATCH 1/2] Export relative path handling "prefix_path()" function
From: Linus Torvalds @ 2005-08-17 20:31 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Not all programs necessarily have a pathspec array of pathnames, some of
them (like git-update-cache) want to do things one file at a time. So
export the single-path interface too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
cache.h | 1 +
setup.c | 2 +-
2 files changed, 2 insertions(+), 1 deletions(-)
c06157a36e49182c34e1e92aa7b329bde5dca3f9
diff --git a/cache.h b/cache.h
--- a/cache.h
+++ b/cache.h
@@ -142,6 +142,7 @@ extern char *get_graft_file(void);
extern const char **get_pathspec(const char *prefix, char **pathspec);
extern const char *setup_git_directory(void);
+extern char *prefix_path(const char *prefix, int len, char *path);
#define alloc_nr(x) (((x)+16)*3/2)
diff --git a/setup.c b/setup.c
--- a/setup.c
+++ b/setup.c
@@ -1,6 +1,6 @@
#include "cache.h"
-static char *prefix_path(const char *prefix, int len, char *path)
+char *prefix_path(const char *prefix, int len, char *path)
{
char *orig = path;
for (;;) {
^ permalink raw reply
* [PATCH 2/2] Make git-update-cache take relative pathnames
From: Linus Torvalds @ 2005-08-17 20:32 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This also makes "./filename" acceptable as a side effect, since the
pathname normalization handles that too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
update-cache.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
ece92eeda777c3141f5692132ccc2ba7e4e801a2
diff --git a/update-cache.c b/update-cache.c
--- a/update-cache.c
+++ b/update-cache.c
@@ -321,6 +321,7 @@ int main(int argc, char **argv)
{
int i, newfd, entries, has_errors = 0;
int allow_options = 1;
+ const char *prefix = setup_git_directory();
newfd = hold_index_file_for_update(&cache_file, get_index_file());
if (newfd < 0)
@@ -381,6 +382,7 @@ int main(int argc, char **argv)
}
die("unknown option %s", path);
}
+ path = prefix_path(prefix, prefix ? strlen(prefix) : 0, path);
if (!verify_path(path)) {
fprintf(stderr, "Ignoring path %s\n", argv[i]);
continue;
^ permalink raw reply
* Re: symlinked directories in refs are now unreachable
From: Junio C Hamano @ 2005-08-17 20:41 UTC (permalink / raw)
To: Matt Draisey; +Cc: git-list
In-Reply-To: <1124246082.776.54.camel@della.draisey.ca>
Matt Draisey <mattdraisey@sympatico.ca> writes:
> Having thus been forced to read the mailing list, I see a slight problem
> in .git/objects/info/alternates mechanism. Using the original
> ALTERNATE_DB_ENVIRONMENT variable you assert to the git programmes that
> you know all the repositories to search for objects. In
> the .git/objects/info/alternates mechanism you implicitly defer to other
> repositories, which might also implicitly defer to yet another
> repository. To ensure an object is truly available you need to compute
> a transitive closure on all .git/objects/info/alternates --- you can't
> really rely on .git/objects/info/alternates being transitively closed
> already.
No, "git clone -l -s" not copying the objects/info/alternates of
the repository being cloned was simply a bug; by doing so the
transitive closure can be set up "initially".
Both the environment variable and objects/info/alternates share
the same problem if the cloned/borrowed from repository suddenly
starts to borrow from another repository, losing objects it used
to have from itself. You just shouldn't do it.
With objects/info/alternates, you _could_ do the transitive
closure at runtime and do not have to worry about this issue
(but you now need to worry about cycles), which you cannot do
with the environment variable approach.
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Junio C Hamano @ 2005-08-17 20:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, git
In-Reply-To: <Pine.LNX.4.58.0508171253190.3553@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> The fact is, anybody who doesn't edit the emails that come in is BROKEN.
> There are two kinds of emails:
>
> - the nicely formatted ones where the author follows all the rules
>
> This kind of email doesn't need MIME decoding anyway.
That depends on what the rules are, but I consider detecting B
encodings in the header fields and transliterating it into UTF-8
a good idea (although that sometimes is a lossy conversion
depending on the original charset).
Remember this one that prompted me to do the header folding?
From: YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=
<yoshfuji@linux-ipv6.org>
> - the others
> ..., trying to handle it
> automatically is WRONG WRONG WRONG.
> And if it's mime-encoded you often have trouble editing it anyway.
>
> Ergo: if somebody sends you mime-encoded patches, hit them with a baseball
> bat (politely) and teach them not to do that. "Fixing" the tools really
> will just make things worse if it means that you apply raw emails without
> having edited them.
I agree with you in principle and that is why I always run
applymbox with the -q flag. Maybe I should start trying the
baseball bat approach to see what happens.
^ permalink raw reply
* Re: First stab at glossary
From: Junio C Hamano @ 2005-08-17 20:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508172156090.17234@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Okay for "hash". What is the consensus on "object name" being more
> standard than "SHA1"?
The tutorial uses the term "object name", so does README
(implicitly, by saying "All objects are named by their content,
which is approximated by the SHA1 hash of the object itself").
I think it is pretty safe to assume the list agrees with this
term.
> For me, "index" is just the file named "index" (holding stat data and a
> ref for each cache entry). That is why I say an "index" contains "cache
> entries", not "index entries" (wee, that sounds wrong :-).
I think Linus already commented on using "index file" and "index
entries" as the canonical terms. It would be a good idea to
mention "cache" as a historical synonym in the documentation, so
that we do not have to rename the symbols in the code.
> Ultimately, the glossary terms will be sorted alphabetically. If you look
> at the file attached to my original mail, this is already sorted and
> marked up using asciidoc. However, I wanted you and the list to understand
> how I grouped terms. The asciidoc'ed file is generated by a perl script.
Then we should put the text version under Documentation, along
with that script and a Makefile entry to do asciidoc and another
to go to html. No rush for the script and Makefile entries, but
it would make things easier to manage if we put the text version
in the tree soonish. I've pushed out the one from your original
"First stab" message.
>> > branch::
>> > A non-cyclical graph of revisions, i.e. the complete history of
>> > a particular revision, which does not (yet) have children, which
>> > is called the branch head. The branch heads are stored in
>> > $GIT_DIR/refs/heads/.
I wonder if there is a math term for a non-cyclical graph that
has a single "greater than anything else in the graph" node (but
not necessarily a single but possibly more "lesser than anything
else in the graph" nodes)?
>> > tag::
>> > A ref pointing to a tag or commit object. In contrast to a head,
>> > a tag is not changed by a commit. Tags (not tag objects) are
>> > stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
>> > a Lisp tag (which is called object type in git's context).
I think this is good already, but maybe mention why you would
use a tag in a sentence? "Most typically used to mark a
particular point in the commit ancestry chain," or something.
>> > resolve::
>> > The action of fixing up manually what a failed automatic merge
>> > left behind.
>>
>> "Resolve" is also used for the automatic case (e.g., in
>> "git-resolve-script", which goes from having two commits and a message to
>> having a new commit). I'm not sure what the distinction is supposed to be.
>
> I did not like that naming anyway. In reality, git-resolve-script does not
> resolve anything, but it merges two revisions, possibly leaving something
> to resolve.
I am sure this would break people's script, but I am not against
renaming git-resolve-script to say git-merge-script.
Anyway, thanks for doing this less-fun and not-so-glorious job.
^ permalink raw reply
* Re: First stab at glossary
From: Johannes Schindelin @ 2005-08-17 21:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtmks2m1.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 17 Aug 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Okay for "hash". What is the consensus on "object name" being more
> > standard than "SHA1"?
>
> The tutorial uses the term "object name", so does README
> (implicitly, by saying "All objects are named by their content,
> which is approximated by the SHA1 hash of the object itself").
> I think it is pretty safe to assume the list agrees with this
> term.
Okay, I'll give in, then.
>
> > For me, "index" is just the file named "index" (holding stat data and a
> > ref for each cache entry). That is why I say an "index" contains "cache
> > entries", not "index entries" (wee, that sounds wrong :-).
>
> I think Linus already commented on using "index file" and "index
> entries" as the canonical terms. It would be a good idea to
> mention "cache" as a historical synonym in the documentation, so
> that we do not have to rename the symbols in the code.
>
If the king penguin speaketh, the little blue penguin followeth.
> > Ultimately, the glossary terms will be sorted alphabetically. If you look
> > at the file attached to my original mail, this is already sorted and
> > marked up using asciidoc. However, I wanted you and the list to understand
> > how I grouped terms. The asciidoc'ed file is generated by a perl script.
>
> Then we should put the text version under Documentation, along
> with that script and a Makefile entry to do asciidoc and another
> to go to html. No rush for the script and Makefile entries, but
> it would make things easier to manage if we put the text version
> in the tree soonish. I've pushed out the one from your original
> "First stab" message.
Okay. Then I follow the advice of the large and angry Saucer Crunching
Monster, and shuffle the entries into a more logical order.
> >> > branch::
> >> > A non-cyclical graph of revisions, i.e. the complete history of
> >> > a particular revision, which does not (yet) have children, which
> >> > is called the branch head. The branch heads are stored in
> >> > $GIT_DIR/refs/heads/.
>
> I wonder if there is a math term for a non-cyclical graph that
> has a single "greater than anything else in the graph" node (but
> not necessarily a single but possibly more "lesser than anything
> else in the graph" nodes)?
Yes, there is. Although git itself is an example that there are two
"greater than almost anything else in the graph" nodes.
Also, let's not be overzealous with our math degrees, okay? :-)
> >> > tag::
> >> > A ref pointing to a tag or commit object. In contrast to a head,
> >> > a tag is not changed by a commit. Tags (not tag objects) are
> >> > stored in $GIT_DIR/refs/tags/. A git tag has nothing to do with
> >> > a Lisp tag (which is called object type in git's context).
>
> I think this is good already, but maybe mention why you would
> use a tag in a sentence? "Most typically used to mark a
> particular point in the commit ancestry chain," or something.
Done.
> >> > resolve::
> >> > The action of fixing up manually what a failed automatic merge
> >> > left behind.
> >>
> >> "Resolve" is also used for the automatic case (e.g., in
> >> "git-resolve-script", which goes from having two commits and a message to
> >> having a new commit). I'm not sure what the distinction is supposed to be.
> >
> > I did not like that naming anyway. In reality, git-resolve-script does not
> > resolve anything, but it merges two revisions, possibly leaving something
> > to resolve.
>
> I am sure this would break people's script, but I am not against
> renaming git-resolve-script to say git-merge-script.
I do not mind changing the description if the consensus is to keep
git-resolve-script.
> Anyway, thanks for doing this less-fun and not-so-glorious job.
The little blue penguin says: Thanks for all the fish!
^ permalink raw reply
* Re: [RFC] Patches exchange is bad?
From: Catalin Marinas @ 2005-08-17 21:27 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050817173522.14386.qmail@web26305.mail.ukl.yahoo.com>
On Wed, 2005-08-17 at 10:35 -0700, Marco Costalba wrote:
> Sorry if the answer is silly, but I still don't know well StGIT .
It's probably because there is no document really explaining the
concepts. The Quilt documentation would be a good starting point since
StGIT uses the same ideas but implemented on top if GIT instead of a
series of GNU diff files.
> What you describe it's an asymmetrical or one way scenario, new code
> goes always from HEAD to MAIN. But how is the workflow if:
It is asymmetrical since HEAD uses StGIT and MAIN uses plain GIT but it
is a two way data flow: 'git pull HEAD' in MAIN and 'stg pull MAIN' in
HEAD.
> 1) There is more then one contributor feeding MAIN and you need to update
> the StGIT patch stack from MAIN.
The base of the StGIT stack in the HEAD repository (branch) should
always be the head of the MAIN repository. You update it via the 'stg
pull' command, which takes care of updating the patches so that they are
seen as individual commits on top of the base.
That's how you would normally do development on Linux using StGIT -
clone the mainline kernel, create patches in your StGIT tree and submit
them either via e-mail or ask the gatekeeper to pull directly from your
tree (assuming that you only push those patches that need to be merged).
Doing a 'stg pull' would retrieve the latest changes from the mainline
kernel (including the changes made by your patches which were merged
upstream).
> 2) You made something terribly wrong with HEAD (I don't know what can be
> 'terribly wrong') and you need to recreate a clean base from MAIN.
>
> In this cases, if I understand correctly, you need to clone a new StGIT archive from
> MAIN and push the interesting stuff from old/broken HEAD.
This is not clear for me. What do you mean by 'terribly wrong'? Broken
HEAD because of a bug in StGIT or GIT? Quite unlikely but in this case
the repository would be corrupt. I would recommend periodically doing a
'stg export' to keep the series of patches in GNU diff files.
If you refer to a patch which breaks the code, you can simply pop it
from the stack and even delete it with 'stg delete'. Popping it removes
the changes it makes to HEAD and the corresponding commit won't be seen
with 'git log'. You don't need to clone a new repository since StGIT
allows you to choose which of your patches (commits) are included in
HEAD (via 'stg push' and visible with 'stg applied').
> Or you can always merge back pulling from MAIN as in case of two pure git archives?
The base of the StGIT stack is identical to MAIN. Doing a 'stg pop -a'
makes the HEAD and MAIN identical.
Please let me know if this needs further clarification.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Teach applymbox to keep the Subject: line.
From: Johannes Schindelin @ 2005-08-17 21:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Garzik, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508171253190.3553@g5.osdl.org>
Hi,
On Wed, 17 Aug 2005, Linus Torvalds wrote:
> On Wed, 17 Aug 2005, Jeff Garzik wrote:
> >
> > 2) Teach it to understand MIME, and not treat the MIME headers like part
> > of the message.
>
> [...]
>
> Ergo: if somebody sends you mime-encoded patches, hit them with a baseball
> bat (politely) and teach them not to do that. "Fixing" the tools really
> will just make things worse if it means that you apply raw emails without
> having edited them.
I'd say that QP and the MIME/alternate formats are not really the fault of
the sender, but rather the mailer. So there might be value in supporting
at least these, to make the life of maintainers easier.
Ciao,
Dscho
^ 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