* Re: gitk "hyperlinks"
From: Paul Mackerras @ 2005-08-07 12:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpssr9gd1.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano writes:
> I did, and will push it out shortly, but I think you need this
> patch. To make later merges from you easier, I will not put
> this in my "master" branch.
I have committed this plus the hand cursor for the links plus a small
change to make gitk display commit messages correctly according to the
current locale.
Paul.
^ permalink raw reply
* Re: gitk SHA link hovers
From: Paul Mackerras @ 2005-08-07 12:04 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff Epler, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508061056200.3258@g5.osdl.org>
Linus Torvalds writes:
> This makes the cursor change when you hover over a SHA1 link with the new
> "hypertext" gitk commit ID linking feature.
I committed something based on this but with extra stuff to make the
cursor changes work with the change from the normal cursor to the
watch cursor and back.
Paul.
^ permalink raw reply
* Re: qgit-0.81
From: Ryan Anderson @ 2005-08-07 14:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Marco Costalba, git
In-Reply-To: <Pine.LNX.4.58.0508061711230.3258@g5.osdl.org>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
> Oh, and do people really care _that_ much when the change happened? That's
> a lot of screen real estate wasted on the date stamp of "last change". At
> least I can drag it to the right and hide it that way..
I fixed that here by manually dragging the "date" column to the left.
That had the bonus effect of moving the graph away from the edge of the
window, so it was easier to see the left-most line.
You can also just resize the column if it bugs you. (Though I think
swapping the default order of the two columns is probably worthwhile
anyway.)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFC9h3rfhVDhkBuUKURAjUHAKDoT4YVE+RDMHJouSjoMUwE67feJQCg03yZ
FWWb37PawiNBKkkgb0Ap9no=
=qTOy
-----END PGP SIGNATURE-----
^ permalink raw reply
* qgit-0.82 (was Re: qgit-0.81)
From: Marco Costalba @ 2005-08-07 15:05 UTC (permalink / raw)
To: torvalds; +Cc: git
Marco Costalba wrote:
>Linus Torvalds wrote:
>
>
>>- Any chance of having a git archive of qgit? I realize that sourceforge
>> doesn't have git archives, but (a) maybe you can ask and (b) maybe
>> there are alternate places you could put it. It's just sad having to
>> download tar-balls.
>>
>
>I will try to proceed from (a) to, eventually, (b).
>
>
Apart from using a public git archive, (I already use my private one ;-))
the other points should be fixed now by a fresh qgit-0.82
Download link (still tarball for now) is:
http://prdownloads.sourceforge.net/qgit/qgit-0.82.tar.bz2?download
Changelog:
- replaced jump-over-bumps with horizontal lines
- set graph bullets a bit smaller
- no more word wrapping in diff and file viewers
- fixed display of e-mail addresses in commit messages
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: bisect gives strange answer
From: Junio C Hamano @ 2005-08-07 17:06 UTC (permalink / raw)
To: Sanjoy Mahajan; +Cc: git
In-Reply-To: <E1E14Hj-0001Nt-00@skye.ra.phy.cam.ac.uk>
Sanjoy Mahajan <sanjoy@mrao.cam.ac.uk> writes:
> I will redo those tests but rebuilding in place after each bisection
> (with -f added to all the git checkout uses in git-bisect-script) and
> see whether I get the same results. If I don't, it could be due to
> git or git-bisect (but not so likely with the -f switch) or to the
> build system. Will keep you and Junio posted.
I thought the lack of '-f' was a plausible explanation, but here
is what I just did. The same bisect sequence in your example,
making sure the state of working tree matches what the commit
being tested:
$ git bisect start
$ git bisect good 17af691cd19765b782d891fc50c1568d0f1276b3
$ git bisect bad c101f3136cc98a003d0d16be6fab7d0d950581a6
Bisecting: 42 revisions left to test after this
$ cat .git/HEAD
b2f571026594884e7a2a3f8bc6ad5c92e0703330
$ git bisect good; cat .git/HEAD; git-diff-cache -r bisect
Bisecting: 30 revisions left to test after this
450008b5a62bb09445ae05c4d01d510386c9435d
$ git bisect good; cat .git/HEAD; git-diff-cache -r bisect
Bisecting: 15 revisions left to test after this
a9df3597fec5472d0840fbfdc2a3fac5268f7d08
$ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect
Bisecting: 8 revisions left to test after this
28e8c3ad9464de54a632f00ab3df88fa5f4652d1
$ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect
Bisecting: 4 revisions left to test after this
c774e93e2152d0be2612739418689e6e6400f4eb
$ git bisect bad; cat .git/HEAD; git-diff-cache -r bisect
Bisecting: 2 revisions left to test after this
b4634484815e1879512a23e4f59eef648135c30a
So it does not appear to me that lack of '-f' is a problem.
Without the flag, checkout does "read-tree -m -u" which means to
update the working tree to match the new tree being read (this
includes the removal of files from the working tree that were
registered in the original index file that are not in the next
tree).
^ permalink raw reply
* Re: git-format-patch-script bug?
From: Junio C Hamano @ 2005-08-07 17:21 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1d5oqxkqm.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> I was trying to help someone track down a bug that
> occurred between linux-2.6.12 and linux-2.6.13-rc1.
> Since it was very much an unknown where the problem
> was introduced I decided to run git format-patch
> so I could see what all of the differences were.
> Then to be certain the patch series worked I started
> applying them in order.
Sorry, I offhand do not have a good re-design of what
format-patch should do for this purpose; the current design does
not try to deal with anything but a linear sequence of commits,
primarily because the command was done for preparing individual
developer's patch submission.
I find your trying to find where the problem was introduced by
reading every single change very laudable. However, for the
purpose of "this one was good but somewhere before this one the
things got broken, where is it?", I suspect that bisect would be
a better fit.
The way to use bisect is very simple. First you make sure you
do not have unrecorded changes in your working tree, because
bisect procedure would check out sequences of commits for you to
test there. Then, you give it two "known to be good" and "known
to be bad" commits. The order you give them does not matter,
but "good" one _must_ be ancestor of "bad" one (the code
currently does not check this):
$ git bisect start
$ git bisect good v2.6.12
$ git bisect bad v2.6.13-rc1
Bisecting: 1035 revisions left to test after this
As soon as ou give these two pair, bisect starts thinking, and
checks out one revision that is roughly in the halfway between
these two good and bad commits. You can, if you feel like, see
which one is the first one it wants you to test, like this:
$ git log --max-count=1 --pretty=short bisect
commit 15d20bfd606c4b4454aeaa05fc86f77994e48c92
Author: Domen Puncer <domen@coderock.org>
[PATCH] ptrace_h8300: condition bugfix
At this point, your working tree has this commit checked out.
Compile and test to see if this one is good or bad. If it is
good, then you say "good":
$ git bisect good
Bisecting: 517 revisions left to test after this
Bisect eliminated about half commits from the original 1000+
suspects to be innocent, and checked out which one it wants you
to check next. Compile and test to see if this one is good or
bad. If it turns out to be bad, then you say "bad":
$ git bisect bad
Bisecting: 266 revisions left to test after this
You go on eliminating about half every time you run one test,
and eventually it would find one commit that you may want to
examine more deeply by code inspection.
^ permalink raw reply
* Re: git-format-patch-script bug?
From: Eric W. Biederman @ 2005-08-07 18:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhde1y85y.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> ebiederm@xmission.com (Eric W. Biederman) writes:
>
>> I was trying to help someone track down a bug that
>> occurred between linux-2.6.12 and linux-2.6.13-rc1.
>> Since it was very much an unknown where the problem
>> was introduced I decided to run git format-patch
>> so I could see what all of the differences were.
>> Then to be certain the patch series worked I started
>> applying them in order.
>
> Sorry, I offhand do not have a good re-design of what
> format-patch should do for this purpose; the current design does
> not try to deal with anything but a linear sequence of commits,
> primarily because the command was done for preparing individual
> developer's patch submission.
What format-patch does is currently is fine. If format-patch would
simply notice the case and fail gracefully that would be sufficient to
avoid giving false impressions.
Depending on the quality of the list from git-rev-list --merge-order
I should even be able to achieve what I was attempting, by
running git-diff-tree with an ordered list of revisions and
two parents on the tree.
Essentially I was attempting an export to quilt operation, which
implies a linearization of the changes. As I recall a linearization
of the changes is what BK export to CVS was built on. So that
case may be worth returning to as there are a lot of interesting
cases out there for it.
The other interest tid bit about my experiment was that
git-format-patch-script on 2000 diffs was sluggish, certainly slower
that the time to perform the write operations. Why it was slow
I don't know but it may be worth looking into.
> I find your trying to find where the problem was introduced by
> reading every single change very laudable. However, for the
> purpose of "this one was good but somewhere before this one the
> things got broken, where is it?", I suspect that bisect would be
> a better fit.
If you can teach the user how to use bisect, and git.
If we could get gitweb to perform the bisect it would be helpful,
or possibly when git settles down and everyone can be counted on
to have git on their machine already, bisect would be a help.
Had I been thinking a little more clearly I would have suggested
walking through the daily git snapshots as those are at least
fairly big steps.
For the moment I think the unexpected behavior I found in git
is more interesting then the problem I was actually trying to solve.
Eric
^ permalink raw reply
* use of temporary refs in resolve
From: Junio C Hamano @ 2005-08-07 19:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
As promised I was looking into the fetching side today, but I
ended up trying to figure out the current operation of resolve
first.
Here is my understanding of various "temporary heads" left
directly underneath $GIT_DIR:
HEAD : updated only after successful auto merge.
ORIG_HEAD : records the head value before resolve started.
if automerge fails, this is the same as HEAD,
but after successful automerge, this can be used
to see what the previous head was. This is the
first parent of the resulting commit.
MERGE_HEAD: present if auto merge is unsuccessful and
records the other head being merged.
LAST_MERGE: present if merge is unsuccessful or impossible and
records the other head being merged.
Whenever resolve fails, LAST_MERGE would be there, while
MERGE_HEAD exists only when we attempted and failed an
automerge. I would propose to change this to leave LAST_MERGE
only when we did not even attempt to automerge.
Also ORIG_HEAD is probably redundant. After a successful
automerge, the same information can be had by HEAD^1, and after
a failure, it is HEAD. We do not use the existence of that file
to detect if we are in a middle of the merge (MERGE_HEAD is used
for that purpose by git-commit). We may want stop writing to it
in git-resolve.
What do you think?
Another thing I was thinking was to give git-resolve an ability
to take more than two commits to do octopus ;-). Instead of
using the third argument as a merge commit message, we would say
(for backward compatibilities' sake) the last one is the
message. When we fail halfway, things would probably become messy,
so this needs be postponed until some more thought.
^ permalink raw reply
* Re: git-format-patch-script bug?
From: Junio C Hamano @ 2005-08-07 19:55 UTC (permalink / raw)
To: Eric W. Biederman; +Cc: git
In-Reply-To: <m1y87dwpak.fsf@ebiederm.dsl.xmission.com>
ebiederm@xmission.com (Eric W. Biederman) writes:
> What format-patch does is currently is fine. If format-patch would
> simply notice the case and fail gracefully that would be sufficient to
> avoid giving false impressions.
Hmph. Since it uses merge-order, We should be able to change it
use the tagged output format of rev-list to detect the revision
list discontinuity and skip generating diff for such. Or as you
suggest just run "diff-tree with the first parent".
I've been wanting to update format-patch to take the commit
begin-end pair in the rev-parse format, that is:
$ git format-patch his..mine
I am reluctant to actually do this right away, because this is
an incompatible change from the current format:
$ git format-patch his mine
The same goes for rebase (and therefore cherry). I could use an
ugly heuristics for backward compatibility like "if invoked with
exactly two parameters, and there is no prefix ^ nor .. in these
two, then use the old interpretation, otherwise give them to
rev-parse", but I think this is ugly.
So my question to the list is: do people mind this change?
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Linus Torvalds @ 2005-08-07 20:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3bplwmzg.fsf@assigned-by-dhcp.cox.net>
On Sun, 7 Aug 2005, Junio C Hamano wrote:
>
> Also ORIG_HEAD is probably redundant. After a successful
> automerge, the same information can be had by HEAD^1
Absolutely not.
You forgot about one of the most common merge cases: fast-forward.
In fact, ORIG_HEAD is _the_ most common head I use explicitly. Almost all
operations take HEAD as default, but doing a
gitk ORIG_HEAD..
is extremely useful after a pull.
Linus
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Junio C Hamano @ 2005-08-07 20:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508071256140.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> In fact, ORIG_HEAD is _the_ most common head I use explicitly.
Ahhhh. You are right.
How about LAST_MERGE?
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Linus Torvalds @ 2005-08-07 20:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5opv74u.fsf@assigned-by-dhcp.cox.net>
On Sun, 7 Aug 2005, Junio C Hamano wrote:
>
> How about LAST_MERGE?
I don't think it matters. I kind of saw it as the "other side" of
ORIG_HEAD, but since we now clean it up and since I've never used it, I
think it falls under the status of "well-intentioned but useless".
Linus
^ permalink raw reply
* Re: git-format-patch-script bug?
From: Marco Costalba @ 2005-08-07 20:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric W. Biederman, git
Junio C Hamano wrote:
>
>I am reluctant to actually do this right away, because this is
>an incompatible change from the current format:
>
> $ git format-patch his mine
>
Of course this breaks qgit interface to git-format-patch-script
but if you think it's better this way....
>The same goes for rebase (and therefore cherry). I could use an
>ugly heuristics for backward compatibility like "if invoked with
>exactly two parameters, and there is no prefix ^ nor .. in these
>two, then use the old interpretation, otherwise give them to
>rev-parse", but I think this is ugly.
>
>So my question to the list is: do people mind this change?
>
I think it's ugly too, in this early phase of git development
better go with proper solution then compatibility compromises.
A suggestion I would like to present is if can be useful a
kind of scheduling/list of planned compatibility break features so
that developers can know in advance when and what will break
their stuff and users can know when they will need to upgrade.
____________________________________________________
Start your day with Yahoo! - make it your home page
http://www.yahoo.com/r/hs
^ permalink raw reply
* gitk "parent information" in commit window
From: Linus Torvalds @ 2005-08-07 20:58 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
This adds a useful "Parent:" line to the git commit information window.
It looks something like this (from the infamous octopus merge):
Author: Junio C Hamano <junkio@cox.net> 2005-05-05 16:16:54
Committer: Junio C Hamano <junkio@cox.net> 2005-05-05 16:16:54
Parent: fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc (Update git-apply-patch-script ...)
Parent: 9e30dd7c0ecc9f10372f31539d0122db97418353 (Make git-prune-script executa ...)
Parent: c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a (Do not write out new index if ...)
Parent: 660265909fc178581ef327076716dfd3550e6e7b (diff-cache shows differences ...)
Parent: b28858bf65d4fd6d8bb070865518ec43817fe7f3 (Update diff engine for symlin ...)
Octopus merge of the following five patches.
Update git-apply-patch-script for symbolic links.
Make git-prune-script executable again.
Do not write out new index if nothing has changed.
diff-cache shows differences for unmerged paths without --cache.
Update diff engine for symlinks stored in the cache.
Signed-off-by: Junio C Hamano <junkio@cox.net>
where all the parent commit ID's are clickable, because the new lines are
added as part of the "comment" string, and thus the regular clickability
thing will match them automatically.
I think this is good. And my random-tcl-monkey-skills are clearly getting
better (although it's perfectly possible that somebody who actually knows
what he is doing would have done things differently).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
[ Btw, the patch was generated against a tree that had Paul's hovering
patches merged. Junio, I don't think you've merged that yet, so this may
apply better to Paul's tree than to standard git. But I _think_ it will
apply cleanly to either one ]
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1799,9 +1799,21 @@ proc selectline {l isnew} {
}
$ctext insert end "\n"
}
- $ctext insert end "\n"
+
set commentstart [$ctext index "end - 1c"]
- set comment [lindex $info 5]
+ set comment {}
+ foreach p $parents($id) {
+ set l "..."
+ if {[info exists commitinfo($p)]} {
+ set l [lindex $commitinfo($p) 0]
+ if {[string length $l] > 32} {
+ set l "[string range $l 0 28] ..."
+ }
+ }
+ append comment "Parent: $p ($l)\n"
+ }
+ append comment "\n"
+ append comment [lindex $info 5]
$ctext insert end $comment
$ctext insert end "\n"
^ permalink raw reply
* Re: gitk "parent information" in commit window
From: Junio C Hamano @ 2005-08-07 21:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508071351150.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> [ Btw, the patch was generated against a tree that had Paul's hovering
> patches merged. Junio, I don't think you've merged that yet, so this may
> apply better to Paul's tree than to standard git. But I _think_ it will
> apply cleanly to either one ]
Thanks. Since Paul seems to be quite responsive, I'd prefer to
keep pulling from his tree. I just pulled the hovering patches
from his tree and was about to push things out.
^ permalink raw reply
* backward compatible changes to format-patch, rebase, cherry and fetch
From: Junio C Hamano @ 2005-08-07 21:54 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050807205342.8497.qmail@web26304.mail.ukl.yahoo.com>
Marco Costalba <mcostalba@yahoo.it> writes:
> A suggestion I would like to present is if can be useful a
> kind of scheduling/list of planned compatibility break features so
> that developers can know in advance when and what will break
> their stuff and users can know when they will need to upgrade.
Yes, that is a valid concern. Fortunately this is the only
backward incompatible thing I currently see on the horizon.
Here are the list of things I am currently thinking about
updating.
- The format-patch, rebase and cherry parameters you already
know about. I do not think the "ugly" two parameter
compromise is too much baggage to keep around, so my original
plan was not to break the backward compatibility.
- Fetch and pull. Currently git fetch (and git pull) takes the
following forms:
$ git fetch <remote>
$ git fetch <remote> <head>
$ git fetch <remote> tag <tag>
I am planning to update it to take:
$ git fetch <remote> <refspec>...
but in a backward compatible way.
<refspec> can take the following forms:
- A <refspec> of form "<src>:<dst>" is to fetch the objects
needed for the remote ref that matches <src>, and if <dst>
is not empty, store it to the local that matches <dst>.
The same rule as "git push" applies for <dst>. <src> can
be either a ref pattern or the SHA1 object name. If <src>
is not an SHA1 object name, and it does not match exactly
one remote ref, it is an error.
- "tag" followed by <next> is just an old way of saying
"refs/tags/<next>:refs/tags/<next>"; this mimics the
current behaviour of the third form above and means "fetch
that tag and store it under the same name".
- A single token <refspec> without colon is a shorthand for
"<refspec>:" That is, "fetch that ref but do not store
anywhere".
- when there is no <refspec> specified
- if <remote> is the name of a file under
$GIT_DIR/branches/ (i.e. a shorthand without trailing
path), then it is the same as giving a single <refspec>
"<remote-name>:refs/heads/<remote>" on the command line,
where <remote-name> is the remote branch name (defaults
to HEAD, but can be overridden by .git/branches/<remote>
file having the URL fragment notation). That is, "fetch
that branch head and store it in refs/heads/<remote>".
- otherwise, it is the same as giving a single <refspec>
that is "HEAD:".
The SHA1 object names of fetched refs are stored in FETCH_HEAD
[*1*], one name per line. There will be an empty line for the
ref that was not available on the remote end.
I have pull enhancements that takes more than one remote refs
in mind, but that will not be in the immediate future. What
will happen when the above fetch enhancement happens is that
pull will accept the same set of parameters as the updated
fetch does, runs the fetch, but refuses to run resolve when
more than one remote ref is involved. When resolve is updated
to do an octopus (or a king ghidorah), this restriction can be
lifted without breaking backward compatibility.
[Footnote]
*1* git-fetch-pack most likely will just output SHA1 to its
standard output like Linus suggested earlier.
^ permalink raw reply
* Re: gitk "parent information" in commit window
From: Paul Mackerras @ 2005-08-07 22:52 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508071351150.3258@g5.osdl.org>
Linus Torvalds writes:
> This adds a useful "Parent:" line to the git commit information window.
Cool! Applied and pushed out.
I have been thinking about adding dialog windows to allow the user to
select which repository and which range of commits they want to look at.
Do you think that would be useful for you?
Regards,
Paul.
^ permalink raw reply
* Re: gitk "parent information" in commit window
From: A Large Angry SCM @ 2005-08-08 0:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <17142.37044.108962.189983@cargo.ozlabs.ibm.com>
Paul Mackerras wrote:
...
> I have been thinking about adding dialog windows to allow the user to
> select which repository and which range of commits they want to look at.
> Do you think that would be useful for you?
Yes!
^ permalink raw reply
* Re: gitk "parent information" in commit window
From: Junio C Hamano @ 2005-08-08 0:29 UTC (permalink / raw)
To: git
In-Reply-To: <17142.37044.108962.189983@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Linus Torvalds writes:
>
>> This adds a useful "Parent:" line to the git commit information window.
>
> Cool! Applied and pushed out.
Thanks. Merged and pushed out.
> I have been thinking about adding dialog windows to allow the user to
> select which repository and which range of commits they want to look at.
> Do you think that would be useful for you?
"Which repository to look at" would be like restarting if you
need to lose history information, in which case it would not be
so useful at least for me (an extra command line option to limit
the range with specifying GIT_DIR environment variable would
work equally well). If you can do that without losing history
when the new repository to look at is the same as the old one,
or similar to the old one, then that would be useful.
After starting up, without losing history information, if I can
tell it to re-read the refs, because I made some changes to the
repository while gitk was not looking, that would be very
useful. But I hope your "switching repository" logic would do
exactly that when I tell it to switch to the same repository.
If there was an option, either runtime configurable or command
line, to cause gitk slurp not just refs/heads and refs/tags but
everything under refs/* recursively, that would help visualizing
the bisect status. bisect creates bunch of commit object names
in refs/bisect.
If you can pop-up a transient window that shows the tag object
comments when I hover over a tag icon for 2 seconds, and remove
that transient window when stepping outside, that would be a
useful addition. I do not currently see any way to inspect the
tag itself, not the commit that is pointed at by the tag.
^ permalink raw reply
* Re: gitk "parent information" in commit window
From: A Large Angry SCM @ 2005-08-08 3:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508071351150.3258@g5.osdl.org>
Linus Torvalds wrote:
> This adds a useful "Parent:" line to the git commit information window.
>
> It looks something like this (from the infamous octopus merge):
>
> Author: Junio C Hamano <junkio@cox.net> 2005-05-05 16:16:54
> Committer: Junio C Hamano <junkio@cox.net> 2005-05-05 16:16:54
> Parent: fc54a9c30ccad3fde5890d2c0ca2e2acc0848fbc (Update git-apply-patch-script ...)
> Parent: 9e30dd7c0ecc9f10372f31539d0122db97418353 (Make git-prune-script executa ...)
> Parent: c4b83e618f1df7d8ecc9392fa40e5bebccbe6b5a (Do not write out new index if ...)
> Parent: 660265909fc178581ef327076716dfd3550e6e7b (diff-cache shows differences ...)
> Parent: b28858bf65d4fd6d8bb070865518ec43817fe7f3 (Update diff engine for symlin ...)
>
> Octopus merge of the following five patches.
>
> Update git-apply-patch-script for symbolic links.
> Make git-prune-script executable again.
> Do not write out new index if nothing has changed.
> diff-cache shows differences for unmerged paths without --cache.
> Update diff engine for symlinks stored in the cache.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
>
> where all the parent commit ID's are clickable, because the new lines are
> added as part of the "comment" string, and thus the regular clickability
> thing will match them automatically.
This new functionality is great except when it truncates the commit
description needlessly.
When running gitk full-screen on a large display, I have a commit
information window that is much wider than needed for the truncated
parent information. Leaving me with a lot of whitespace that should be
used for the commit descriptions.
On a related nit: some of the diffs I'm viewing have lines longer than
the width of the commit information window and it's annoying that gitk
wraps the line rather than providing horizontal scrolling.
How about implementing horizontal scrolling in the commit information
window when the commit text or the diffs are wider than the window and
not truncating the commit descriptions?
^ permalink raw reply
* Re: GIT 0.99.4 (preview)
From: Horst von Brand @ 2005-08-08 3:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr7d6z3pn.fsf@assigned-by-dhcp.cox.net>
My proposed patch, the description as is is misleading.
The rest of the .spec file looks sane (yes, I've built my share of RPMs
over the years).
diff --git a/git-core.spec.in b/git-core.spec.in
--- a/git-core.spec.in
+++ b/git-core.spec.in
@@ -2,7 +2,7 @@
Name: git-core
Version: @@VERSION@@
Release: 1
-Vendor: Linus Torvalds <torvalds@osdl.org>
+Vendor: Junio C Hamano <junkio@cox.net>
Summary: Git core and tools
License: GPL
Group: Development/Tools
@@ -13,22 +13,23 @@ BuildRoot: %{_tmppath}/%{name}-%{version
Prereq: sh-utils, diffutils, rsync, rcs, mktemp >= 1.5
%description
-GIT comes in two layers. The bottom layer is merely an extremely fast
-and flexible filesystem-based database designed to store directory trees
-with regard to their history. The top layer is a SCM-like tool which
-enables human beings to work with the database in a manner to a degree
-similar to other SCM tools (like CVS, BitKeeper or Monotone).
+This is a stupid (but extremely fast) directory content manager. It
+doesn't do a whole lot, but what it _does_ do is track directory
+contents efficiently. It is intended to be the base of an efficient,
+distributed source code management system. This package includes
+rudimentary tools that can be used as a SCM, but you should look
+elsewhere for tools for ordinary humans layered on top of this.
%prep
%setup -q
%build
-
make prefix=%{_prefix} all %{!?_without_docs: doc}
%install
rm -rf $RPM_BUILD_ROOT
-make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} install install-tools %{!?_without_docs: install-doc}
+make dest=$RPM_BUILD_ROOT prefix=%{_prefix} mandir=%{_mandir} \
+ install install-tools %{!?_without_docs: install-doc}
%clean
rm -rf $RPM_BUILD_ROOT
@@ -43,7 +44,13 @@ rm -rf $RPM_BUILD_ROOT
%{!?_without_docs: %{_mandir}/man7/*.7.gz}
%changelog
+* Sun Aug 07 2005 Horst H. von Brand <vonbrand@inf.utfsm.cl>
+- Redid the description
+- Cut overlong make line, loosened changelog a bit
+- I think Junio (or perhaps OSDL?) should be vendor...
+
* Thu Jul 14 2005 Eric Biederman <ebiederm@xmission.com>
- Add the man pages, and the --without docs build option
+
* Wed Jul 7 2005 Chris Wright <chris@osdl.org>
- initial git spec file
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
^ permalink raw reply
* [PATCH] Stash away the original head in ORIG_HEAD when resetting.
From: Junio C Hamano @ 2005-08-08 6:06 UTC (permalink / raw)
To: git; +Cc: torvalds
When rewinding the head, stash away the value of the original
HEAD in ORIG_HEAD, just like git-resolve-script does.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Since rewinding the head is a dangerous operation, saving it
somewhere just in case would make life a bit safer. This also
lets you do:
$ git commit
... "oops, I forgot to include that fix."
$ git reset HEAD^1
... edit away and update-cache
$ git commit -m ORIG_HEAD
to reuse the old commit message.
git-reset-script | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
87aced8864d926cf870ddfb2ca7ac5784fccb911
diff --git a/git-reset-script b/git-reset-script
--- a/git-reset-script
+++ b/git-reset-script
@@ -2,6 +2,12 @@
. git-sh-setup-script || die "Not a git archive"
rev=$(git-rev-parse --revs-only --verify --default HEAD "$@") || exit
rev=$(git-rev-parse --revs-only --verify $rev^0) || exit
-git-read-tree --reset "$rev" && echo "$rev" > "$GIT_DIR/HEAD"
+git-read-tree --reset "$rev" && {
+ if orig=$(git-rev-parse --verify HEAD 2>/dev/null)
+ then
+ echo "$orig" >"$GIT_DIR/ORIG_HEAD"
+ fi
+ echo "$rev" > "$GIT_DIR/HEAD"
+}
git-update-cache --refresh
rm -f "$GIT_DIR/MERGE_HEAD"
^ permalink raw reply
* [PATCH] Teach format-patch, rebase and cherry a..b format
From: Junio C Hamano @ 2005-08-08 6:09 UTC (permalink / raw)
To: git; +Cc: Marco Costalba
In-Reply-To: <20050807205342.8497.qmail@web26304.mail.ukl.yahoo.com>
Although these commands take only begin and end, not necessarily
generic SHA1 expressions rev-parse supports, supporting a..b
notation is good for consistency. This commit adds such without
breaking backward compatibility.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Unlike the outline I suggested in an earlier message, this adds
support for only a single parameter "a..b" format, while
retaining the original code which takes two parameters. Meant
to be fully backward compatible not to break qgit and friends.
git-cherry | 25 +++++++++++++++++--------
git-format-patch-script | 21 +++++++++++++++------
git-rebase-script | 23 +++++++++++++++--------
3 files changed, 47 insertions(+), 22 deletions(-)
c67e91fad243565423b08a55f63947bd3e36c5a3
diff --git a/git-cherry b/git-cherry
--- a/git-cherry
+++ b/git-cherry
@@ -3,6 +3,8 @@
# Copyright (c) 2005 Junio C Hamano.
#
+. git-sh-setup-script || die "Not a git archive."
+
usage="usage: $0 "'<upstream> [<head>]
__*__*__*__*__> <upstream>
@@ -18,8 +20,8 @@ upstream, it is shown on the standard ou
The output is intended to be used as:
OLD_HEAD=$(git-rev-parse HEAD)
- git-rev-parse linus >${GIT_DIR-.}/HEAD
- git-cherry linus OLD_HEAD |
+ git-rev-parse upstream >${GIT_DIR-.}/HEAD
+ git-cherry upstream $OLD_HEAD |
while read commit
do
GIT_EXTERNAL_DIFF=git-apply-patch-script git-diff-tree -p "$commit" &&
@@ -27,20 +29,27 @@ The output is intended to be used as:
done
'
+case "$#,$1" in
+1,*..*)
+ upstream=$(expr "$1" : '\(.*\)\.\.') ours=$(expr "$1" : '.*\.\.\(.*\)$')
+ set x "$upstream" "$ours"
+ shift ;;
+esac
+
case "$#" in
-1) linus=`git-rev-parse --verify "$1"` &&
- junio=`git-rev-parse --verify HEAD` || exit
+1) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify HEAD` || exit
;;
-2) linus=`git-rev-parse --verify "$1"` &&
- junio=`git-rev-parse --verify "$2"` || exit
+2) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify "$2"` || exit
;;
*) echo >&2 "$usage"; exit 1 ;;
esac
# Note that these list commits in reverse order;
# not that the order in inup matters...
-inup=`git-rev-list ^$junio $linus` &&
-ours=`git-rev-list $junio ^$linus` || exit
+inup=`git-rev-list ^$ours $upstream` &&
+ours=`git-rev-list $ours ^$upstream` || exit
tmp=.cherry-tmp$$
patch=$tmp-patch
diff --git a/git-format-patch-script b/git-format-patch-script
--- a/git-format-patch-script
+++ b/git-format-patch-script
@@ -3,6 +3,8 @@
# Copyright (c) 2005 Junio C Hamano
#
+. git-sh-setup-script || die "Not a git archive."
+
usage () {
echo >&2 "usage: $0"' [-n] [-o dir] [--mbox] [--check] [-<diff options>...] upstream [ our-head ]
@@ -60,13 +62,20 @@ do
shift
done
+revpair=
case "$#" in
-2) linus="$1" junio="$2" ;;
-1) linus="$1" junio=HEAD ;;
-*) usage ;;
+2)
+ revpair="$1..$2" ;;
+1)
+ case "$1" in
+ *..*)
+ revpair="$1";;
+ *)
+ revpair="$1..HEAD";;
+ esac ;;
+*)
+ usage ;;
esac
-junio=`git-rev-parse --verify "$junio"`
-linus=`git-rev-parse --verify "$linus"`
me=`git-var GIT_AUTHOR_IDENT | sed -e 's/>.*/>/'`
@@ -108,7 +117,7 @@ _x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
stripCommitHead='/^'"$_x40"' (from '"$_x40"')$/d'
-git-rev-list --merge-order "$junio" "^$linus" >$series
+git-rev-list --merge-order $(git-rev-parse --revs-only "$revpair") >$series
total=`wc -l <$series | tr -dc "[0-9]"`
i=$total
while read commit
diff --git a/git-rebase-script b/git-rebase-script
--- a/git-rebase-script
+++ b/git-rebase-script
@@ -3,25 +3,32 @@
# Copyright (c) 2005 Junio C Hamano.
#
+. git-sh-setup-script || die "Not a git archive."
+
usage="usage: $0 "'<upstream> [<head>]
Uses output from git-cherry to rebase local commits to the new head of
upstream tree.'
-: ${GIT_DIR=.git}
+case "$#,$1" in
+1,*..*)
+ upstream=$(expr "$1" : '\(.*\)\.\.') ours=$(expr "$1" : '.*\.\.\(.*\)$')
+ set x "$upstream" "$ours"
+ shift ;;
+esac
case "$#" in
-1) linus=`git-rev-parse --verify "$1"` &&
- junio=`git-rev-parse --verify HEAD` || exit
+1) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify HEAD` || exit
;;
-2) linus=`git-rev-parse --verify "$1"` &&
- junio=`git-rev-parse --verify "$2"` || exit
+2) upstream=`git-rev-parse --verify "$1"` &&
+ ours=`git-rev-parse --verify "$2"` || exit
;;
*) echo >&2 "$usage"; exit 1 ;;
esac
-git-read-tree -m -u $junio $linus &&
-echo "$linus" >"$GIT_DIR/HEAD" || exit
+git-read-tree -m -u $ours $upstream &&
+echo "$upstream" >"$GIT_DIR/HEAD" || exit
tmp=.rebase-tmp$$
fail=$tmp-fail
@@ -29,7 +36,7 @@ trap "rm -rf $tmp-*" 0 1 2 3 15
>$fail
-git-cherry $linus $junio |
+git-cherry $upstream $ours |
while read sign commit
do
case "$sign" in
^ permalink raw reply
* [PATCH] Teach git push .git/branches shorthand
From: Junio C Hamano @ 2005-08-08 6:12 UTC (permalink / raw)
To: git
Although it is uncertain if we would keep .git/branches for
long, the shorthand stored there can be used for pushing if it
is host:path/to/git format, so let's make use of it. This does
not use git-parse-remote because that script will be rewritten
quite a bit for updated pulling.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
I hear a lot of people mention $GIT_DIR/branches/ is confusing.
Maybe we should rename it to $GIT_DIR/remote/ directory?
git-push-script | 63 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 62 insertions(+), 1 deletions(-)
c781a84b5204fb294c9ccc79f8b3baceeb32c061
diff --git a/git-push-script b/git-push-script
--- a/git-push-script
+++ b/git-push-script
@@ -1,3 +1,64 @@
#!/bin/sh
. git-sh-setup-script || die "Not a git archive"
-git-send-pack "$@"
+
+# Parse out parameters and then stop at remote, so that we can
+# translate it using .git/branches information
+has_all=
+has_force=
+has_exec=
+remote=
+
+while case "$#" in 0) break ;; esac
+do
+ case "$1" in
+ --all)
+ has_all=--all ;;
+ --force)
+ has_force=--force ;;
+ --exec=*)
+ has_exec="$1" ;;
+ -*)
+ die "Unknown parameter $1" ;;
+ *)
+ remote="$1"
+ shift
+ set x "$@"
+ shift
+ break ;;
+ esac
+ shift
+done
+
+case "$remote" in
+*:* | /* | ../* | ./* )
+ # An URL, host:/path/to/git, absolute and relative paths.
+ ;;
+* )
+ # Shorthand
+ if expr "$remote" : '..*/..*' >/dev/null
+ then
+ # a short-hand followed by a trailing path
+ shorthand=$(expr "$remote" : '\([^/]*\)')
+ remainder=$(expr "$remote" : '[^/]*\(/.*\)$')
+ else
+ shorthand="$remote"
+ remainder=
+ fi
+ remote=$(sed -e 's/#.*//' "$GIT_DIR/branches/$remote") &&
+ expr "$remote" : '..*:' >/dev/null &&
+ remote="$remote$remainder" ||
+ die "Cannot parse remote $remote"
+ ;;
+esac
+
+case "$remote" in
+http://* | https://* | git://* | rsync://* )
+ die "Cannot push to $remote" ;;
+esac
+
+set x "$remote" "$@"; shift
+test "$has_all" && set x "$has_all" "$@" && shift
+test "$has_force" && set x "$has_force" "$@" && shift
+test "$has_exec" && set x "$has_exec" "$@" && shift
+
+exec git-send-pack "$@"
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Catalin Marinas @ 2005-08-08 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v3bplwmzg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Here is my understanding of various "temporary heads" left
> directly underneath $GIT_DIR:
>
> HEAD : updated only after successful auto merge.
>
> ORIG_HEAD : records the head value before resolve started.
> if automerge fails, this is the same as HEAD,
> but after successful automerge, this can be used
> to see what the previous head was. This is the
> first parent of the resulting commit.
>
> MERGE_HEAD: present if auto merge is unsuccessful and
> records the other head being merged.
>
> LAST_MERGE: present if merge is unsuccessful or impossible and
> records the other head being merged.
Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
It should be, unless, git-pull-script removes it or it is changed to
do the fetch as well.
In a repository managed with StGIT (i.e. updated with 'stg pull'), the
base of the stack is always the same with FETCH_HEAD and StGIT uses
this file. I also find it quite useful for:
gitk ORIG_HEAD..FETCH_HEAD
to only see the remote commits since the local StGIT patches are
always seen as commits on top of the FETCH_HEAD. It's also useful for
people using 'git rebase'.
--
Catalin
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox