Re: [PATCH] Teach parse_commit_buffer about grafting.

2005-08-18 Thread Paul Mackerras
Linus Torvalds writes:

 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?

Cool.  I didn't realize that.  The current version uses it now.

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

I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what
flag have I missed? :)  Junio wants me to look at everything under
[gitdir]/refs, in fact.  Or are the refs not considered internal git
information?

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.

2005-08-18 Thread Johannes Schindelin
Hi,

On Fri, 19 Aug 2005, Paul Mackerras wrote:

 Linus Torvalds writes:
 
  Paul, I hate to tell you about yet another flag [...]

But why? You're doing such a fine job telling people about flags :-)

  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 ;)
 
 I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what
 flag have I missed? :)  Junio wants me to look at everything under
 [gitdir]/refs, in fact.  Or are the refs not considered internal git
 information?

Time for git-ref-list?

Joking. But there may be a use for a --refs flag to git-rev-list, which 
just lists all the refs' names together with their object name (SHA1).

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 parse_commit_buffer about grafting.

2005-08-18 Thread Linus Torvalds

On Fri, 19 Aug 2005, Paul Mackerras wrote:
 
  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 ;)
 
 I still look in [gitdir]/refs/tags/* and [gitdir]/refs/heads/*, what
 flag have I missed? :)  Junio wants me to look at everything under
 [gitdir]/refs, in fact.  Or are the refs not considered internal git
 information?

Ahh, ok, fair enough. git-rev-list won't give you that. 

And yes, the general rule is that anything under .git/refs/ is potentially 
a reference. If it's under heads/ or tags/ it's a branch/tag, and then 
the prefix heads/ or tags/ shouldn't be part of the name - you already 
show the difference with colors. Anything else is unusual, but bisection 
puts refs in the .git/refs/bisect directory for example, and if gitk 
were to show those, it should probably show them in yet another color, and 
_with_ the bisect/ prefix..

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: [PATCH] Teach parse_commit_buffer about grafting.

2005-08-17 Thread 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)
no child


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: [PATCH] Teach parse_commit_buffer about grafting.

2005-08-17 Thread 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


Re: [PATCH] Teach parse_commit_buffer about grafting.

2005-08-17 Thread 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.

2005-08-17 Thread 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


Re: [PATCH] Teach parse_commit_buffer about grafting.

2005-07-30 Thread Matthias Urlichs
Hi, Junio C Hamano wrote:

 Introduce a new file $GIT_DIR/info/grafts

Nice work.

Has anybody git-imported the old tarfile+patch history yet?
If not, I'll do it over the weekend.

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
 - -
Whatever occurs from love is always beyond good and evil.
-- Friedrich Nietzsche


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

2005-07-30 Thread Johannes Schindelin
Hi,

is it possible that you forgot to initialize commit_graft_nr to 0?

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