Re: [PATCH] Teach parse_commit_buffer about grafting.

[Linus Torvalds]

On Thu, 18 Aug 2005, Paul Mackerras wrote:
> 
> I added support for grafts to gitk just yesterday, and it should be on
> kernel.org by now.  I also committed the changes to send lines into
> hyperspace.

Paul, I hate to tell you about yet another flag to git-rev-list, but did 
you realize that in addition to all the other magic flags, there's a flag 
called "--parents"?

Right now you use "git-rev-list --header --topo-order", which gives you 
both the commit ID's and the header. Add a "--parents" there, and you'll 
notice that the first line of each NUL-terminated record changes from just 
the commit ID to the "commit ID + parent list".

That way gitk wouldn't need to actually know about grafts, because it 
would just pick it up from the git-rev-list output which gets it from the 
regular commit parsing code.

Umm. git-rev-list really does everything. Rule of thumb: if you _ever_
need to look at any other internal git information, you're probably doing
something wrong, or you've missed yet another flag ;)

Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Small team cogito/git setup

[Martin Langhoff]

We have a small team of 3, and our main activity is to run local
branches of upstream projects, plus some local development. In that
context, I am designing our cogito/git usage strategy, and I'm
interested in comments.

My intention is to use cogito as much as possible, and insulate our
team from git internals. I find that using cogito is actually easier
than cvs, and a mile easier than Arch (the two tools we use currently)
and I rather keep it that way: simple.

The upstream projects run on CVS, so I am setting up a repo fed by
git-cvsimport for each of those. We all pull from that repo
(cg-clone), so we can all see the upstream in its git representation.
Now, we are going to run a few branches off that, and I want to have
those branches _teamwide_ with the same name, so it is trivial for us
to keep synching.

All our work directories on our LAN will available via HTTP, so we can
pull from the team repositories easily. Is there a good technique with
cogito to have a team pull from each other, so that a single cg-update
or cg-pull when working on a branch pulls from all my teammembers.

Or are we forced to run an 'integration' repo so that we work with a
'star' arrangement? I am actually trying to avoid needing a central
repo if possible.

How should branch creation be handled for team-wide branches? I'd like
to have branches use the same name across the team to avoid confusion.

Phew. Every time I think I understand how things go with git, I find I
don't know sh*t about it yet ;)

martin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Paul Mackerras]

Junio C Hamano writes:

> My Tcl/Tk is really rusty, and I do not like this patch, but
> here is my stab at teaching the code that reads commit objects
> how to use grafts as well.

I added support for grafts to gitk just yesterday, and it should be on
kernel.org by now.  I also committed the changes to send lines into
hyperspace.

Regards,
Paul.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Junio C Hamano]

Wolfgang Denk <[EMAIL PROTECTED]> writes:

> The display in gitk --all gets changed a bit (before the  branch  was
> the  leftmost  line,  now  it's  the rightmost one), but it's still a
> dangling head, and the selected  "merge  point"  (commit  24ee89)  is
> still  displayed  with  just  one parent (de180e) - I would expect to
> also see d9af3c listed as parent, and the branch merging in here?
>
> Am I missing something?

The graft info is not used by anything other than those that use
parse_commit() to figure out the commit ancestry information.

The list of commits that appear in the top pane of the gitk is
generated by git-rev-list which knows how to do it, but the
parent and child links, and the lines between nodes are drawn by
gitk using the information it reads directly from the commit
objects.

My Tcl/Tk is really rusty, and I do not like this patch, but
here is my stab at teaching the code that reads commit objects
how to use grafts as well.


[PATCH] Teach gitk to use grafts info

Finding commits to draw is done by git-rev-list which knows how
to do the grafts, but the lines between commits and the
parent / child links needs to be drawn by reading from the
commit objects.  Teach that part of the code how to grok grafts
info so that "fake" ancestry is shown sensibly in gitk.

Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]>
---

 gitk |   36 +++-
 1 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -155,7 +155,7 @@ proc readcommit {id} {
 }
 
 proc parsecommit {id contents listed} {
-global commitinfo children nchildren parents nparents cdate ncleft
+global commitinfo children nchildren parents nparents cdate ncleft grafts
 
 set inhdr 1
 set comment {}
@@ -171,6 +171,23 @@ proc parsecommit {id contents listed} {
 }
 set parents($id) {}
 set nparents($id) 0
+set has_graft [array get grafts $id]
+if {"" != $has_graft} {
+   set parents($id) $grafts($id)
+   set nparents($id) [llength $parents($id)]
+   foreach p $parents($id) {
+   if {![info exists nchildren($p)]} {
+   set children($p) {}
+   set nchildren($p) 0
+   set ncleft($p) 0
+   }
+   if {$listed && [lsearch -exact $children($p) $id] < 0} {
+   lappend children($p) $id
+   incr nchildren($p)
+   incr ncleft($p)
+   }
+   }
+}
 foreach line [split $contents "\n"] {
if {$inhdr} {
if {$line == {}} {
@@ -178,6 +195,9 @@ proc parsecommit {id contents listed} {
} else {
set tag [lindex $line 0]
if {$tag == "parent"} {
+   if {"" != $has_graft} {
+   continue
+   }
set p [lindex $line 1]
if {![info exists nchildren($p)]} {
set children($p) {}
@@ -3194,6 +3214,20 @@ foreach arg $argv {
 
 set history {}
 set historyindex 0
+set grafts('') nothing
+array unset grafts ''
+if {![catch { set graft [exec cat [gitdir]/info/grafts] }]} {
+global grafts
+foreach line [split $graft "\n"] {
+   set commit [lindex $line 0]
+   set llen [llength $line]
+   set pp {}
+   for {set i 1} {$i < $llen} {incr i} {
+   lappend pp [lindex $line $i]
+   }
+   set grafts($commit) $pp
+}
+}
 
 set stopped 0
 set redisplaying 0

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Subject: [PATCH] Assorted changes to glossary

[Johannes Schindelin]

Based on the discussion on the git list, here are some important changes
to the glossary. (There is no cache, but an index. Use "object name"
rather than "SHA1". Reorder. Clarify.)

Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---

 Documentation/glossary.txt |  104 ++--
 1 files changed, 61 insertions(+), 43 deletions(-)

8d8a819f8f1d93c460c0b76a006f1a3830fb1f06
diff --git a/Documentation/glossary.txt b/Documentation/glossary.txt
--- a/Documentation/glossary.txt
+++ b/Documentation/glossary.txt
@@ -3,21 +3,27 @@ object::
the SHA1 of its contents. Consequently, an object can not
be changed.
 
+object name::
+   The unique identifier of an object. The hash of the object's contents
+   using the Secure Hash Algorithm 1 and usually represented by the 40
+   character hexadecimal encoding of the hash of the object (possibly
+   followed by a white space).
+
 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.
+   Synonym for object name.
+
+object identifier::
+   Synonym for object name.
+
+hash::
+   In git's context, synonym to object name.
 
 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.
+   by its object name. The object usually live in $GIT_DIR/objects/.
 
 blob object::
-   Untyped object, i.e. the contents of a file.
+   Untyped object, e.g. the contents of a file.
 
 tree object::
An object containing a list of blob and/or tree objects.
@@ -29,42 +35,43 @@ tree::
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.
+index::
+   A collection of files with stat information, whose contents are
+   stored as objects. The cache is a stored version of your working
+   tree. Truth be told, it can also contain a second, and even a third
+   version of a working tree, which are used when merging.
 
-cache entry::
+index entry::
The information regarding a particular file, stored in the index.
-   A cache entry can be unmerged, if a merge was started, but not
+   An index 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.
+unmerged index:
+   An index which contains unmerged index entries.
+
+cache::
+   Obsolete for: index.
 
 working tree::
-   The set of files and directories currently being worked on.
-   Think "ls -laR"
+   The set of files and directories currently being worked on,
+   i.e. you can work in your working tree without using git at all.
 
 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.
-
 revision::
A particular state of files and directories which was stored in
the object database. It is referenced by a commit object.
 
+checkout::
+   The action of updating the working tree to a revision which was
+   stored in the object database.
+
 commit::
-   The action of storing the current state of the cache in the
+   As a verb: The action of storing the current state of the cache in the
object database. The result is a revision.
+   As a noun: Short hand for commit object.
 
 commit object::
An object which contains the information about a particular
@@ -72,14 +79,15 @@ commit object::
tree object which corresponds to the top directory of the
stored revision.
 
+parent::
+   A commit object contains a (possibly empty) list of the logical
+   predecessor(s) in the line of development, i.e. its parents.
+
 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.
-
 clean::
A working tree is clean, if it corresponds to the revision
referenced by the current head.
@@ -94,13 +102,12 @@ head::
 
 branch::
A non-cyclical graph of revisio

Re: [PATCH] Teach parse_commit_buffer about grafting.

[Wolfgang Denk]

In message <[EMAIL PROTECTED]> you wrote:
> Introduce a new file $GIT_DIR/info/grafts (or $GIT_GRAFT_FILE)
> which is a list of "fake commit parent records".  Each line of
> this file is a commit ID, followed by parent commit IDs, all
> 40-byte hex SHA1 separated by a single SP in between.  The
> records override the parent information we would normally read
> from the commit objects, allowing both adding "fake" parents
> (i.e. grafting), and pretending as if a commit is not a child of
> some of its real parents (i.e. cauterizing).

How exactly is this used?

I gave up trying to have CVS  merges  autimatically  recognized  upon
import, and tried to follow Matthias Urlichs' advice to fake it using
the grafts file.

I have this situation:

Branch point (actually this is the inital import into CVS):

Commit: 0b666f81da14bf46cada222856762f7fd6641c26
Child:  9956b03b956994bb4e2cee4161f3626bcfd71924 (Das U-Boot: Universal Boot 
Loader)
Child:  7309612797ed5e6b3b20027e28bca970b4f6b8fd (Initial revision)


End of branch to merge (in CVS 1.1.1.1):

Commit: d9af3c87df93e1a8126b1a52adf8db978e9a0d40
Parent: 0bb9c6d97b195bd0efcdda02f109e6d1519074a9 (Das U-Boot: Universal Boot 
Loader)



This is the commit where I would like to show the  branch  merged  in
(before; this is the first real commit in CVS):

Commit: 24ee89b97a49826ea800b4a6c0d5c0769328e317
Parent: de180e6daa529dc78668c99bdf17a9cdd440782d (Initial revision)
Child:  699b13a6064e642280caffaa83c10b359a6c1114 (* Fix mdelay() on TRAB - this 
was still the debugging version with)


I tried with a grafts file like this:

24ee89b97a49826ea800b4a6c0d5c0769328e317 
de180e6daa529dc78668c99bdf17a9cdd440782d 
d9af3c87df93e1a8126b1a52adf8db978e9a0d40


The display in gitk --all gets changed a bit (before the  branch  was
the  leftmost  line,  now  it's  the rightmost one), but it's still a
dangling head, and the selected  "merge  point"  (commit  24ee89)  is
still  displayed  with  just  one parent (de180e) - I would expect to
also see d9af3c listed as parent, and the branch merging in here?

Am I missing something?

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Programmer's Lament: (Shakespeare, Macbeth, Act I, Scene vii)
"That we but teach bloody instructions,
which, being taught, return to plague the inventor..."
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with hyperspace support

[Junio C Hamano]

Paul Mackerras <[EMAIL PROTECTED]> writes:

> OK, you're the second person to ask for that, so I'll see what I can
> do about it.  I can think of 3 possible behaviors when you click on
> the arrowhead:
>
> 1. scroll to bring the other arrowhead on-screen and briefly make it
>larger or something similar to draw attention to it
>
> 2. scroll to bring the other arrowhead on-screen and warp the pointer
>to it
>
> 3. select the next commit in the indicated direction which is a child
>or parent that the line connects (scroll to make it visible,
>highlight it, show its diff).
>
> Which do you think would be best?

Hmph.  I think, aside from being color challenged, the primary
source of confusion for me was that the lines with arrowheads
were too long, and the node and the arrowhead did not fit within
the height of the graphical pane, at least with my window
configuration.

I wonder if not having downward or upward arrows for a long
stretch would work better.  Lose the vertical line for such
hyperspace links, and instead have a horizonal short line with
arrowheads to denote that there are also hyperspace lines coming
into or out of that node.  That way you can save one column for
a vertical line, and my preference for clicking on such an
arrowhead would be #3 from the above.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: First stab at glossary

[Johannes Schindelin]

Hi,

On Wed, 17 Aug 2005, Daniel Barkalow wrote:

> On Wed, 17 Aug 2005, Johannes Schindelin wrote:
> 
> > On Wed, 17 Aug 2005, Daniel Barkalow wrote:
> > > [...]
> > Okay for "hash".
> 
> I think we only need at most two names for this, so this is more a matter
> of fixing old usage than documenting it.

It's short enough to keep it in the glossary _and_ fix the old 
documentation.

> > [blabla] index [blable] cache [bliblo]
>
> Well, it often contains information not present anywhere else (the status
> of a merge; the set of files being committed, added, or removed), so it
> isn't really a cache at all.

Okay, okay. I stand corrected.

> > 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.
> 
> You probably don't need to mention that tree objects and index files can
> be thought of as filesystems, but you should specify that the working tree
> really is in the Unix filesystem, in case people have heard of the idea.
> 
> It should be clear to say 'You can "cd" there and "ls" to list your
> files.', rather than 'Think "ls -laR"' which makes my think of the output,
> which is like the output from git-ls-files.

How about this:

working tree::
The set of files and directories currently being worked on,
i.e. you can work in your working tree without using git at all.


> > > > 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.
> 
> Ah, okay.

Sorry, I attributed these "moving suggestions" to the large and angry SCM, 
while those were your comments. Since Junio decided to keep the "topic 
ordered" form in his repository, I moved them around according to your 
mail.

> > > > 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.
> 
> Right; I think we should change the name of the script.

How many users are there? Probably many call git-pull-script anyway, 
right?

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: First stab at glossary

[Daniel Barkalow]

On Wed, 17 Aug 2005, Johannes Schindelin wrote:

> Hi,
>
> On Wed, 17 Aug 2005, Daniel Barkalow wrote:
>
> > On Wed, 17 Aug 2005, Johannes Schindelin wrote:
> >
> > > 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".

I think we only need at most two names for this, so this is more a matter
of fixing old usage than documenting it.

> > 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 :-).

Well, it often contains information not present anywhere else (the status
of a merge; the set of files being committed, added, or removed), so it
isn't really a cache at all.

> > > 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.

You probably don't need to mention that tree objects and index files can
be thought of as filesystems, but you should specify that the working tree
really is in the Unix filesystem, in case people have heard of the idea.

It should be clear to say 'You can "cd" there and "ls" to list your
files.', rather than 'Think "ls -laR"' which makes my think of the output,
which is like the output from git-ls-files.

> > > 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.

Ah, okay.

> > > 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.

Right; I think we should change the name of the script.

-Daniel
*This .sig left intentionally blank*
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Patches exchange is bad?

[Johannes Schindelin]

Hi Catalin,

maybe it is time for a quick run through the typical jobs you do with 
StGIT, much like what Jeff sent the other day?

Ciao,
Dscho


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach applymbox to keep the Subject: line.

[Johannes Schindelin]

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Patches exchange is bad?

[Catalin Marinas]

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: First stab at glossary

[Johannes Schindelin]

Hi,

On Wed, 17 Aug 2005, Junio C Hamano wrote:

> Johannes Schindelin <[EMAIL PROTECTED]> 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!

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: First stab at glossary

[Junio C Hamano]

Johannes Schindelin <[EMAIL PROTECTED]> 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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach applymbox to keep the Subject: line.

[Junio C Hamano]

Linus Torvalds <[EMAIL PROTECTED]> 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=?= 
<[EMAIL PROTECTED]>

>  - 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.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: symlinked directories in refs are now unreachable

[Junio C Hamano]

Matt Draisey <[EMAIL PROTECTED]> 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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2/2] Make git-update-cache take relative pathnames

[Linus Torvalds]

This also makes "./filename" acceptable as a side effect, since the
pathname normalization handles that too.

Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---

 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;
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 1/2] Export relative path handling "prefix_path()" function

[Linus Torvalds]

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 <[EMAIL PROTECTED]>
---

 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 (;;) {
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Change git-branch to list branches

[Kalle Valo]

Kalle Valo <[EMAIL PROTECTED]> writes:

> Junio C Hamano <[EMAIL PROTECTED]> 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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: First stab at glossary

[Johannes Schindelin]

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach applymbox to keep the Subject: line.

[Linus Torvalds]

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
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-format-patch + git-applymbox small issue

[Johannes Schindelin]

Hi,

On Wed, 17 Aug 2005, Junio C Hamano wrote:

> Marco Costalba <[EMAIL PROTECTED]> 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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-format-patch + git-applymbox small issue

[Johannes Schindelin]

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-format-patch + git-applymbox small issue

[Johannes Schindelin]

Hi,

On Wed, 17 Aug 2005, Junio C Hamano wrote:

> Johannes Schindelin <[EMAIL PROTECTED]> 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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Change git-branch to list branches

[Kalle Valo]

Junio C Hamano <[EMAIL PROTECTED]> 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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach applymbox to keep the Subject: line.

[Junio C Hamano]

Jeff Garzik <[EMAIL PROTECTED]> 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.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-format-patch + git-applymbox small issue

[Junio C Hamano]

Marco Costalba <[EMAIL PROTECTED]> 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.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-format-patch + git-applymbox small issue

[Junio C Hamano]

Johannes Schindelin <[EMAIL PROTECTED]> 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?

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: First stab at glossary

[Daniel Barkalow]

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 SHA

Re: [RFC] Patches exchange is bad?

[Marco Costalba]

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 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-format-patch + git-applymbox small issue

[Marco Costalba]

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 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach applymbox to keep the Subject: line.

[Jeff Garzik]

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.



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Patches exchange is bad?

[Marco Costalba]

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 ' in the MAIN
>repository. After this, doing a 'stg pull ' 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 
 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: git-format-patch + git-applymbox small issue

[Johannes Schindelin]

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

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Add merge detection to git-cvsimport

[Matthias Urlichs]

Hi, Martin Langhoff wrote:

> this one is the
> most likely one to be from a bug in cvsps or the cvsimport logic.

That's not a bug in the import logic, just a failure of the CVS-merging
person to be consistent. (Which is hardly news. :-/ )

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Reason:
Bad, toxic entity, that foolish people use when they ought to use
their inner voice, or angels, or intuition, or a gut feeling, or
their hearts, or the I Ching.
-- Fashionable Dictionary (www.butterfliesandwheels.com)


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git-format-patch + git-applymbox small issue

[Marco Costalba]

Hi, 

the round trip 

1)  git-format-patch --mbox --keep-subject

2)  git-applymbox -k

is not perfect for revisions where there is only the subject.

An example is c35a7b8d806317dc1762e36561cbd31c2530dd9c in git archive

Original text is:

   Skip merges in format-patch.


After round trip:

 Skip merges in format-patch.

   
git-format-patch-script |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
   
   c35a7b8d806317dc1762e36561cbd31c2530dd9c



I know I'm a bit annoying ;-)

Marco

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.


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Patches exchange is bad?

[Catalin Marinas]

Marco Costalba <[EMAIL PROTECTED]> wrote:
> Suppose a possible scenario involves using a couple of git archives, one 
> for releases and stable code, say MAIN, and one for experimental stuff  
> or new development, say HEAD.
>
> Suppose there is stuff in HEAD you don't want merged in MAIN, more,
> you need to update MAIN with only a subset of patches in HEAD, peraphs 
> in different order. Or simply, you are not interested to see the history 
> of the HEAD tree when looking MAIN. All this points could keep you 
> from merging.

As others already recommended StGIT, I will just add a simple usage
scenario (I do this with my StGIT repository).

The MAIN/stable repository (or branch) is only managed with GIT, not
StGIT. The HEAD one is managed with StGIT (only, you can use 'stg
clone'). You can create patches, modify them etc. (I updated the
README in the latest snapshot and it contains some kind of tutorial).

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 ' in the MAIN
repository. After this, doing a 'stg pull ' 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.

-- 
Catalin

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

rc6-git8 Makefile from cg-export and bz2 patch don't agree

[Sanjoy Mahajan]

I wanted to get a clean 2.6.12-rc6-git8 tree, so I looked up the commit
id (3edea4833a1efcd43e1dff082bc8001fdfe74b34) at
, updated my .git
repository with

rsync -a --delete --verbose --stats --progress \
   rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/ \
   .git/

then did 
  cg-export /tmp/xyz 

Strangely, the Makefile doesn't match what I would get by applying
patch-2.6.13-rc6-git8.bz2.  In the exported Makefile,

EXTRAVERSION =-rc6

whereas from the patch, Makefile (line 151 of the diff) has 

EXTRAVERSION = -rc6-git8

Was this a case of hand-editing the diff or did I not use the cg/git
commands correctly?

-Sanjoy

`A society of sheep must in time beget a government of wolves.'
   - Bertrand de Jouvenal
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with hyperspace support

[Matthias Urlichs]

Hi, Sean wrote:

> The line flowing from this commit extends ~200 more commits downward
> before it is finally terminated with an arrowhead.   It would be nice if
> this line could be made shorter, such that the arrowhead was drawn much
> closer to commit in question.

Good point. The arrowheads tend to get lost otherwise; in my tree, the
problem is even worse since the downward-pointing arrow (drawn in grey) is
directly below a horizontal line connecting two unrelated changes -- which
is *also* grey.  That makes the actual arrowhead perceptually invisible.

If the arrow appears directly below a node, you don't get that problem.

Another point I just noticed: The arrows should be directly below
each other, if at all possible; i.e. the one pointing up should be in the
same column as the corresponding arrow pointing down.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Money is the root of all evil, and man needs roots.


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Teach applymbox to keep the Subject: line.

[Linus Torvalds]

On Tue, 16 Aug 2005, Junio C Hamano wrote:
>
> This is a companion patch to the previous format-patch fix.
> With "-k", format-patch can be told not to remove the [PATCH] in
> the original commit, nor to add the [PATCH] on its own.

I think this might be the point in time to just make the "[PATCH]" prefix 
go away.

It made much more sense with BK than it does with git: since git keeps 
track of "author" and "committer" separately, you can always see when the 
committer wasn't the author of the change, which is what the "[PATCH]" 
thing was all about. 

In other words, at least for the kernel, [PATCH] was a marker that said 
"the author didn't commit this directly". Git already has that information 
explicitly in the git data.

(Also, with proper "Signed-off-by:" lines it's also always clear that 
there were other people involved, and that the author of the patch is 
different from the person who applied it).

So I would personally not mind if we just made the "[PATCH]" prefix go 
away entirely, or perhaps had a separate flag to "git-applymbox" that told 
it to prepend a specific prefix to the Subject: line (which might not be 
"[PATCH] " at all) defaulting to "no prefix".

Linus

PS. Another historical reason for marking patches explicitly was that
people were worried that introducing BK would somehow make the old
patch-based submissions be "second-class citizens". It was easy to make
statistics and show that at least half the real changes (as opposed to
merges) were still patch-based. So again, the "PATCH" marker had some 
historical relevance, but I don't think it matters any more.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

First stab at glossary

[Johannes Schindelin]

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.

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.

blob object::
Untyped object, i.e. the contents of a file.

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.

working tree::
The set of files and directories currently being worked on.
Think "ls -laR"

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.

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.

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.

clean::
A working tree is clean, if it corresponds to the revision
referenced by the current head.

dirty::
A working tree is said to be dirty if it contains modifications
which have not been committed to the current branch.

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/.

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).

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.

repository::
A collection of refs together with an object database containing
all objects, which are reachable from the refs. A repository can
share a

Re: gitk with hyperspace support

[Matthias Urlichs]

Hi, Paul Mackerras wrote:

> http://ozlabs.org/~paulus/gitk/gitk.hs
> 
Unfortunately, this fails on my git-plus-assorted-crap archive:

can't read "mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283)": no such 
element in array
can't read "mainlinearrow(c1a9ddb1e9f30029384bd687d90af5796a280283)": no such 
element in array
while executing
"if {$mainlinearrow($id) ne "none"} {
set mainline($id) [trimdiagstart $mainline($id)]
}"
(procedure "drawcommitline" line 44)
invoked from within
"drawcommitline $dlevel"
(procedure "drawmore" line 65)
invoked from within
"drawmore 1"
(procedure "drawcommit" line 33)
invoked from within
"drawcommit $id"
(procedure "getcommitlines" line 50)
invoked from within
"getcommitlines file23"


Another problem: when I click on a line, I get the parent and *all* its
children, not just the child(ren) on the other end of the segment I was
clicking on.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
There are some micro-organisms that exhibit characteristics of both plants
and animals.  When exposed to light they undergo photosynthesis; and when
the lights go out, they turn into animals.  But then again, don't we all?


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] Let git-format-patch-script write on stdout

[Marco Costalba]

Avoid that git-format-patch writes out patch series
information on stderr when there are no errors

Signed-off-by: Marco Costalba <[EMAIL PROTECTED]>
---

 git-format-patch-script |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

47238497f48d19a0bf44eb9b23875bbb8e8a12aa
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -146,7 +146,7 @@ do
 
 file=`printf '%04d-%stxt' $i "$title"`
 i=`expr "$i" - 1`
-echo >&2 "* $file"
+echo >&1 "* $file"
 {
mailScript='
/./d



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fixed two bugs in git-cvsimport-script.

[David Kågedal]

Junio C Hamano <[EMAIL PROTECTED]> writes:

> Junio C Hamano <[EMAIL PROTECTED]> writes:
>
>> Yes, the patch had some context conflicts with some other patch
>> so the patch application was done by hand, and I did a quick and
>> dirty cut & paste of the commit message from "cat mbox" output.
>>
>> I will probably drop future patches encoded in QP.
>
> This was totally inappropriate; sorry, but I was in a bad mood.
>
> A more serious response.
>
>  - I personally consider commit message encoding a per project
>issue (so is blob contents encoding).

Agreed.  And your response is probably good enough for now.  I also
think that having UTF-8 as the standard convention is the way to go.

-- 
David Kågedal

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fixed two bugs in git-cvsimport-script.

[David Kågedal]

Junio C Hamano <[EMAIL PROTECTED]> writes:

>> Apparently, my mail was encoded as QP, which is not very popular
>> around here.  But it seems that the diff part was decoded properly
>> before applying.  Was that done manually?
>
> Yes, the patch had some context conflicts with some other patch
> so the patch application was done by hand, and I did a quick and
> dirty cut & paste of the commit message from "cat mbox" output.
>
> I will probably drop future patches encoded in QP.

Ok, but do you have an answer to my real question?  What is the
character encoding for commit objects in your git repository?

It is obviously one that is compatible with ASCII, which probably
leaves you with the alternatives ASCII, Latin1, and UTF-8.  And plain
ASCII obviously doesn't work very well for me.

-- 
David Kågedal

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fixed two bugs in git-cvsimport-script.

[Junio C Hamano]

Junio C Hamano <[EMAIL PROTECTED]> writes:

> Yes, the patch had some context conflicts with some other patch
> so the patch application was done by hand, and I did a quick and
> dirty cut & paste of the commit message from "cat mbox" output.
>
> I will probably drop future patches encoded in QP.

This was totally inappropriate; sorry, but I was in a bad mood.

A more serious response.

 - I personally consider commit message encoding a per project
   issue (so is blob contents encoding).  If for example a
   project is Japanese only, MS-DOS^WWindows programming
   project, I do not think it is unreasonable if all the commit
   messages and source files are encoded in Shift-JIS.  More
   Unixy projects over there might use EUC-JP in source files
   and maybe ISO-2022 in the log messages (because the latter is
   the standard way to exchange e-mails there).  As long as
   project participants agree to use the same encodings, things
   should work just fine within a project.

 - However, weird people are known to merge projects that
   started out as totally separate into one.  It would be a
   disaster for the commit log viewer when this happens.  For
   this reason, some people recommend using a common deniminator
   encoding, namely UTF-8, for commit logs from day one, even if
   you do not envision such a merge may happen in the future.

   This recommendation also goes to author and committer
   identification (but not blob contents).  But this is just an
   recommendation, and it is still up to the individual project
   what encoding to use in the log messages, and the low-level
   GIT should not dictate nor interfere; "git-commit-tree" and
   "git-cat-file commit" are 8-bit clean.

 - The e-mail patch acceptance machinery found in tools/
   directory is tuned for the established patch exchange
   practice used in the linux-kernel mailing list.  No MIME, no
   QP, no guarantee to pass things outside ASCII.

 - Eventually, tools/mailinfo.c should be taught about MIME to
   do at least:

   - detect whitespace corrupted patch via sending MUA using
 flowed-text and reject it;

   - detect multipart PGP signed message, discard the attached
 signature which is often useless, and unwrap the payload;

   - decode QP and B encodings as necessary, and after splitting
 the message to the info, msg and patch part, transliterate
 the info and msg part from original encoding to UTF-8 (when
 '--utf8' flag is given, perhaps).

   One of the requirement there is that it still needs to be
   _fast_.  Linus needs to be able to make 5 commits per second
   out of his mailbox.

So that is the technical part of the response.  There is one
Project policy part of the response: I would endorse the
application of that UTF-8 recommendation to the git project
itself, at least in principle.

But that in practice would happen only after the above mailinfo
update takes place.  Until then, it is very likely that I will
occasionally fail to spot and to hand-correct people's name left
undecoded the way the patch acceptance machinery passed through
in the log message.  Please live with it (or send such patches
to mailinfo ;-).


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with hyperspace support

[Paul Mackerras]

Junio C Hamano writes:

> The new output looks a lot less cluttering and I like it very
> much, but it is confusing to me on one count.  I clicked one
> arrowhead pointing downward, expecting that the pane would jump
> scroll to show the counterpart arrowhead, and was dissapointed

OK, you're the second person to ask for that, so I'll see what I can
do about it.  I can think of 3 possible behaviors when you click on
the arrowhead:

1. scroll to bring the other arrowhead on-screen and briefly make it
   larger or something similar to draw attention to it

2. scroll to bring the other arrowhead on-screen and warp the pointer
   to it

3. select the next commit in the indicated direction which is a child
   or parent that the line connects (scroll to make it visible,
   highlight it, show its diff).

Which do you think would be best?

> > http://ozlabs.org/~paulus/gitk/gitk.hs
> 
> I first thought you rewrote it in Haskell ;-).

Hmmm, maybe it's apache on ozlabs.org that is under that
misapprehension?

Thanks,
Paul.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fixed two bugs in git-cvsimport-script.

[Junio C Hamano]

> Apparently, my mail was encoded as QP, which is not very popular
> around here.  But it seems that the diff part was decoded properly
> before applying.  Was that done manually?

Yes, the patch had some context conflicts with some other patch
so the patch application was done by hand, and I did a quick and
dirty cut & paste of the commit message from "cat mbox" output.

I will probably drop future patches encoded in QP.



-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 2nd try] Also handle CVS branches with a '/' in their name

[Johannes Schindelin]

I track a CVS project which has a branch with a '/' in the branch name.
Since git wants the branch name to be a file name at the same time,
substitute that character to a '-' by default (override with "-s ").
This should work well, despite the fact that a division and a difference
are completely different :-)

Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---

 Documentation/git-cvsimport-script.txt |6 +-
 git-cvsimport-script   |8 +---
 2 files changed, 10 insertions(+), 4 deletions(-)

b4327595f6cd2a0a4e573ceb12983765321f4790
diff --git a/Documentation/git-cvsimport-script.txt 
b/Documentation/git-cvsimport-script.txt
--- a/Documentation/git-cvsimport-script.txt
+++ b/Documentation/git-cvsimport-script.txt
@@ -11,7 +11,8 @@ SYNOPSIS
 
 'git-cvsimport-script' [ -o  ] [ -h ] [ -v ]
[ -d  ] [ -p  ]
-   [ -C  ] [ -i ] [ -k ] [  ]
+   [ -C  ] [ -i ] [ -k ]
+   [ -s  ] [  ]
 
 
 DESCRIPTION
@@ -69,6 +70,9 @@ OPTIONS
 -z ::
 Pass the timestamp fuzz factor to cvsps.
 
+-s ::
+   Substitute the character "/" in branch names with 
+
 OUTPUT
 --
 If '-v' is specified, the script reports what it is doing.
diff --git a/git-cvsimport-script b/git-cvsimport-script
--- a/git-cvsimport-script
+++ b/git-cvsimport-script
@@ -28,19 +28,19 @@ use POSIX qw(strftime dup2);
 $SIG{'PIPE'}="IGNORE";
 $ENV{'TZ'}="UTC";
 
-our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i);
+our($opt_h,$opt_o,$opt_v,$opt_k,$opt_d,$opt_p,$opt_C,$opt_z,$opt_i,$opt_s);
 
 sub usage() {
print STDERR <) {
$state = 4;
} elsif($state == 4 and s/^Branch:\s+//) {
s/\s+$//;
+   s/[\/]/$opt_s/g;
$branch = $_;
$state = 5;
} elsif($state == 5 and s/^Ancestor branch:\s+//) {

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Patches exchange is bad?

[Martin Langhoff]

On 8/17/05, Marco Costalba <[EMAIL PROTECTED]> wrote:
> Of course I can feed proper subject and description to git-commit but I would 
> like
> to find something less intrusive

I don't know if it helps, but I think that StGIT is what you are
looking for, not only because you have more tools to deal with
patches, but also because patches that are in the 'stack' are actually
really malleable. You can edit and reedit the patch w its commit msg
and all, commit it to the stack, and reedit it again later. It only
becomes immutable when you commit to the underlying git repo.

cheers,


martin
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] git-format-patch fix

[Marco Costalba]

Junio C Hamano wrote:

>Introduces --keep-subjects flag to tell it not to munge the
>first line of the commit message.  Running "git applymbox" on
>the output from "git format-patch -m -k" would preserve the
>original commit information better this way.
>


>Opinions?  Objections?
>

This is exaclty what I was looking for. This indirectly answer also to my 
concerns about the method.

Thanks
Marco


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC] Patches exchange is bad?

[Marco Costalba]

Daniel Barkalow wrote:

>>2) Practical: The round trip git-format-patch + git-applymbox is the logical 
>>and
>>natural way to reach this goal or, also in this case, I intend to stretch 
>>some tools,
>>designed for one thing, for something else?
>
>
>I'd guess that git-diff-tree + git-apply (without the rest of the
>scripting) would be more effective when you're not doing anything with the
>intermediate files, since it saves doing a bunch of formatting and
>parsing.
>
>
It would be surely better, but I need to import also the original subject and
description. I can use git-diff-tree --pretty -p for the patch creation, but 
this
format is not compatible with git-apply* scripts, and the git command git-apply 
does
not import subject + description info.

Of course I can feed proper subject and description to git-commit but I would 
like 
to find something less intrusive as possible, ie. one command for patch export, 
one 
command for patch import.

Thanks
Marco


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: gitk with hyperspace support

[Sean]

On Wed, August 17, 2005 2:58 am, Junio C Hamano said:
> Paul Mackerras <[EMAIL PROTECTED]> writes:
>
>> My reasoning is that it is the local short-range connections which are
>> interesting and informative.  The long-range connections aren't really
>> visually informative; if you want to know about the long-range
>> connections, the parent and child lists in the details pane are much
>> more useful.
>
> Correct.
>
> The new output looks a lot less cluttering and I like it very
> much, but it is confusing to me on one count.  I clicked one
> arrowhead pointing downward, expecting that the pane would jump
> scroll to show the counterpart arrowhead, and was dissapointed
> that it did not happen.  I could click the "Parent" link at that
> point, but then the upward arrow was above and outside the
> visible portion of that pane, which broke visual continuity and
> I lost track at that point.  I think my being color challenged
> exacerbated the resulting confusion; otherwise I could have
> probably found the line with the same color as the color of the
> downarrow I clicked.

This change looks really good in gitk and clicking on an arrowhead to hop
to the corresponding arrowhead would sure be great too.  There's may be a
way to further reduce the line clutter too; once a line is terminated with
an arrowhead, it could often be trimmed back much further.

For instance looking at Linus' tree:

  03938c3f1062b0f279a0ef937a471d4db83702ed
  powernow-k8 requires that a data structure for

The line flowing from this commit extends ~200 more commits downward
before it is finally terminated with an arrowhead.   It would be nice if
this line could be made shorter, such that the arrowhead was drawn much
closer to commit in question.

Cheers,
Sean


-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Fixed two bugs in git-cvsimport-script.

[David Kågedal]

David Kågedal <[EMAIL PROTECTED]> writes:

> The git-cvsimport-script had a copule of small bugs that prevented me
> from importing a big CVS repository.
>
> The first was that it didn't handle removed files with a multi-digit
> primary revision number.

I noticed that this patch was accepted, which is great.  But there is
a problem with the character encoding in the commit message.

The commit in question is b0921331030d52febf52839753eee1b2b9ca1f24

The "author" field is written as "iso-8859-1?Q?David_K=E5gedal
<[EMAIL PROTECTED]>", which is taken from the "From:" line in my
email.  This should be decoded by the patch import script before
generating the commit message.

But the trickier question is what encoding to use in the commit
message.

This is the signed-off line in my mail:

  Signed-off-by: David Kågedal <[EMAIL PROTECTED]>

This is what appears in the commit:

  Signed-off-by: David K?5gedal <[EMAIL PROTECTED]>

Using ISO-8859-15 or UTF-8 would probably have made more sense here.

Apparently, my mail was encoded as QP, which is not very popular
around here.  But it seems that the diff part was decoded properly
before applying.  Was that done manually?

Since my name contains a character that is not part of ASCII, it isn't
really an option to send the mails encoded as ASCII.  I could probably
convince my mailer (Gnus) to send it as "8bit" or "binary", but that
is a pretty limited solution.  An it isn't even legal to use anything
but ASCII in the mail header.

-- 
David Kågedal

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] When copying or renaming, keep the mode, please

[Junio C Hamano]

Good catch.  Thanks.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Also handle CVS branches with a '/' in their name

[Junio C Hamano]

Johannes Schindelin <[EMAIL PROTECTED]> writes:

> That may be true, but CVS branches being named "H.ANdnsel/Gretel" do not 
> logically denote hierarchies. I never ever saw hierarchical CVS branch 
> names with a "/" separator. I saw some with a "." separator.
>
> My feeling is that it would be wrong to map CVS branch names to a 
> hierarchy.

Although I've used / in CVS branch names to denote hierarchy,
I now agree with you for a different reason.  A CVS repository
can have branches "Hnsel" and "Hnsel/Gretel" at the same time,
which we cannot express it with '/'.

However, this may make CVS tags Hnsel/Gretel and Hnsel-Gretel
clash, so maybe the name mangling should be made somehow
configurable?

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Also handle CVS branches with a '/' in their name

[Johannes Schindelin]

Hi,

On Wed, 17 Aug 2005, Junio C Hamano wrote:

> Johannes Schindelin <[EMAIL PROTECTED]> writes:
> 
> > I track a CVS project which has a branch with a '/' in the branch name.
> > Since git wants the branch name to be a file name at the same time,
> > translate that character to a '-'. This should work well, despite the
> > fact that a division and a difference are completely different :-)
> 
> My feeling is that there should be nothing to prevent you from
> having a non-flat namespace in .git/refs/heads; i.e. we should
> allow ".git/refs/heads/foo/bar".

That may be true, but CVS branches being named "Hänsel/Gretel" do not 
logically denote hierarchies. I never ever saw hierarchical CVS branch 
names with a "/" separator. I saw some with a "." separator.

My feeling is that it would be wrong to map CVS branch names to a 
hierarchy.

Ciao,
Dscho

Re: [PATCH] Also handle CVS branches with a '/' in their name

[Junio C Hamano]

Johannes Schindelin <[EMAIL PROTECTED]> writes:

> I track a CVS project which has a branch with a '/' in the branch name.
> Since git wants the branch name to be a file name at the same time,
> translate that character to a '-'. This should work well, despite the
> fact that a division and a difference are completely different :-)

My feeling is that there should be nothing to prevent you from
having a non-flat namespace in .git/refs/heads; i.e. we should
allow ".git/refs/heads/foo/bar".  Some of the existing tools may
be forgetting to call either "mkdir -p $(dirname $ref)" if they
are written in shell, or safe_create_leading_directories(ref) in
C, but I consider that is a bug.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] When copying or renaming, keep the mode, please

[Johannes Schindelin]

Without this patch, git-apply does not retain the mode when renaming or
copying files.

Signed-off-by: Johannes Schindelin <[EMAIL PROTECTED]>
---

 apply.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

8dca30668d7077fa9b9157c3685b3ace8598a514
diff --git a/apply.c b/apply.c
--- a/apply.c
+++ b/apply.c
@@ -1043,8 +1043,12 @@ static int check_patch(struct patch *pat
return error("%s: already exists in working directory", 
new_name);
if (errno != ENOENT)
return error("%s: %s", new_name, strerror(errno));
-   if (!patch->new_mode)
-   patch->new_mode = S_IFREG | 0644;
+   if (!patch->new_mode) {
+   if (patch->is_new)
+   patch->new_mode = S_IFREG | 0644;
+   else
+   patch->new_mode = patch->old_mode;
+   }
}
 
if (new_name && old_name) {
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html