* 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: 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: qgit-0.81
From: Marco Costalba @ 2005-08-07 7:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
Linus Torvalds wrote:
>Ok, this is nicer than gitk, with the parents showing up in the commit
>message and thus easy to go to. You might add children too: it's not
>something git itself knows about intrisically, but since you've already
>built the graph, at least you see what children are part of that graph..
>
I don't know if this is what you mean, but if you right click on a free
lane (i.e. not a bullet but a vertical line) on the graph you should see a
pop-up with selectable childs and parent.
> - 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).
> - The qgit graph is not as pretty as the gitk one. Any chance of making
> the bullets a bit smaller, and having an option to not do the
> "jump-over-bumps"?
>
Ok, I will try to use straight horizontal lines instead of jump-over-bumps. If
this seems not enough clear I will add an option to switch visualization.
> - the "file annotation" window is nice, but it _really_ shouldn't do line
> wrapping. If you make the window narrower, you'll see it wrap and look
> horrible.. Are all text windows always wrapped in QT?
>
No, just a setting. Not a problem to set "No wrap" behaviour. I will set this
also in diff viewer window.
> - You edit the commit comments heavily, and have no options to unedit.
> For example, I need the emails in the sign-offs if I ever cut-and-paste
> to an email client when I sent a "hey, this commit broke so-and-so.."
>
You discover a real bug ;-). I never intended to modify commit comments in any way.
> - the "format a patch to be sent as email" thing says "at least two
> revisions needed" when you only have one. Why? One of my more common
> cases is that I send one commit as a patch, and now I do
>
> git-diff-tree -p --pretty [commit-id] > ~/diff
>
> and then just send that. A single commit _does_ describe a valid patch,
> after all.
>
The logic here is to specify a range. As example if you have following commits
A
B
C
D
E
F
and you select B and E then 3 patches will be created:
patch_1(diff between D-E)
patch_2(diff between C-D)
patch_3(diff between B-C)
So you need at least 2 selected revs. Put in other words, the base is always explicit.
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* git-format-patch-script bug?
From: Eric W. Biederman @ 2005-08-07 7:35 UTC (permalink / raw)
To: git
I haven't had a chance to investigate this much
yet but I have ran into a peculiar problem.
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.
I didn't get very far when I had a patch conflict.
Looking deeper git-diff-tree is always making the diffs
against the parent instead of against the next commit
in the series. Which is largely sane. However it does
not warn or fail when the parents and the next commit are different,
which seems nonintuitive.
Eric
^ permalink raw reply
* GIT 0.99.4 (preview)
From: Junio C Hamano @ 2005-08-07 6:00 UTC (permalink / raw)
To: git
In-Reply-To: <7v8xzfde7t.fsf@assigned-by-dhcp.cox.net>
I said:
> My tentative plan is for 0.99.4 to finish send-pack, 0.99.5
> to enhance fetch-pack, 0.99.6 to finish the first pass for the
> documentation updates and stabilizing the binary packaging.
Ok, I am almost ready to push 0.99.4 out. Here is what I have
in the public repository.
- The branches master & pu are as usual. Modulo bugs, I
consider send-pack enhancement finished.
- There is an "rc" branch whose Makefile already says 0.99.4.
I've been working on Debian and RPM packaging issues today,
with help from Chris Wright and H Peter Anvin, in this
branch.
The plan is to stabilize the binary packaging issues in the "rc"
branch, and ordinary feature updates and bugfixes in "master" or
"pu" branch as usual. When things are ready, "rc" and "master"
will be merged, 0.99.4 gets created and tagged, and "master" and
"pu" will continue from there.
I would appreciate if folks familiar with binary packaging,
especially RPM, give final sanity checks on what is currently in
"rc" branch.
^ permalink raw reply
* Re: gitk "hyperlinks" (was Re: Display of merges in gitk)
From: Kay Sievers @ 2005-08-07 5:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508060839500.3258@g5.osdl.org>
On Sat, Aug 06, 2005 at 08:44:10AM -0700, Linus Torvalds wrote:
>
>
> On Sat, 6 Aug 2005, Kay Sievers wrote:
> >
> > Damn cool? No problem. :)
> > http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=403fe5ae57c831968c3dbbaba291ae825a1c5aaa
>
> Goodie. Although when I looked at it first, it wasn't obvious - the link
> is same font, same color as the rest. Maybe make them stand out a _bit_
> more?
It's blue now, to invite you to click on it. :)
Kay
^ permalink raw reply
* Re: gitweb "tag" display
From: Kay Sievers @ 2005-08-07 5:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacju9az9.fsf_-_@assigned-by-dhcp.cox.net>
On Sat, Aug 06, 2005 at 11:27:54AM -0700, Junio C Hamano wrote:
> A git tag object can have its own text contents, but I do not
> see how I can get to it from gitweb.
>
> For example, I have "junio-gpg-pub" tag in my git.git
> repository. This is a tag to a "blob" which is my public GPG
> key. The "tag" object itself says:
>
> object b92c9c07fe2d0d89c4f692573583c4753b5355d2
> type blob
> tag junio-gpg-pub
> tagger Junio C Hamano <junkio@cox.net> 1123226972 -0700
>
> This is the GPG key I use to sign GIT releases.
Check it out. But it still has no "picture tag" support. :)
Thanks,
Kay
^ permalink raw reply
* Re: git-local-pull?
From: Junio C Hamano @ 2005-08-07 5:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050804201230.GC24479@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
>> I can probably fix it if anyone cares, but it's not something I use
>> personally, so I don't know if it's worthwhile. It should probably be
>> removed if we don't fix it, since it will fail on any popular repository
>> at this point.
>
> I want to use it in Cogito again, since copying everything obviously
> sucks and I want to hardlink, so repacking is not a solution either.
Me too.
^ permalink raw reply
* Re: Extend "git reset" to take a reset point
From: Junio C Hamano @ 2005-08-07 1:42 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List, Sam Ravnborg
In-Reply-To: <Pine.LNX.4.58.0508061746530.3258@g5.osdl.org>
How about saving the current HEAD to $GIT_DIR/OLD_HEAD just in
case? Then after fixing up the files in the working tree, you
could say "git commit -m OLD_HEAD".
^ permalink raw reply
* Extend "git reset" to take a reset point
From: Linus Torvalds @ 2005-08-07 1:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Sam Ravnborg
This was triggered by a query by Sam Ravnborg, and extends "git reset" to
reset the index and the .git/HEAD pointer to an arbitrarily named point.
For example
git reset HEAD^
will just reset the current HEAD to its own parent - leaving the working
directory untouched, but effectively un-doing the top-most commit. You
might want to do this if you realize after you committed that you made a
mistake that you want to fix up: reset your HEAD back to its previous
state, fix up the working directory and re-do the commit.
If you want to totally un-do the commit (and reset your working directory
to that point too), you'd first use "git reset HEAD^" to reset to the
parent, and then do a "git checkout -f" to reset the working directory
state to that point in time too.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
This is potentially a dangerous command, so maybe we should make it
ask for confirmation first?
On the other hand, it definitely is convenient: I often end up doing this
by hand, and clearly other people have hit the "oops, I want to undo and
then re-do those last five commits, I was just a bit too drunk"
The old "git reset" only reset the index to the current HEAD, which is
really only useful if you've tried to do a "merge" that failed and that
you're giving up on. This one is more useful, but also potentially more
dangerous - doing a
git reset v0.99.3
git checkout -f
will basically revert a tree to some old state, and if you didn't save the
old point, you may not be able to get back to it (git-fsck-cache will help
you, but..)
Not hugely tested, btw. That strange extra "git-rev-parse" is _meant_ to
make sure that if you reset to a tag, it will always extract the commit ID
from that tag and not reset the HEAD to a tag object.
diff --git a/git-reset-script b/git-reset-script
--- a/git-reset-script
+++ b/git-reset-script
@@ -1,5 +1,7 @@
#!/bin/sh
. git-sh-setup-script || die "Not a git archive"
-git-read-tree --reset HEAD
+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-update-cache --refresh
rm -f "$GIT_DIR/MERGE_HEAD"
^ permalink raw reply
* Re: cogito - how to drop a commit
From: Linus Torvalds @ 2005-08-07 0:42 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: git
In-Reply-To: <20050806223436.GA6495@mars.ravnborg.org>
On Sun, 7 Aug 2005, Sam Ravnborg wrote:
>
> I accidently commited too many files to my tree today, and now I want to
> drop the commit so I have logically separate commits.
>
> What is the right way to do this - in cogito hopefully.
Not cogito, and this needs to be scripted, but if what you _want_ to do is
undo the commit (in order to re-do it as several commits), here are the
raw git commands necessary (you could make this "git-fix-script", and then
"git fix" basically does the git equivalent of what "bk fix -C" did)
# Set up
#
. git-sh-setup-script || die "Not a git archive"
# Figure out the parent.
#
parent=$(git-rev-parse --verify HEAD^) || exit
#
# Update the index to be at that point in time and make HEAD
# point to it, but don't update the working tree contents (ie
# the changes remain in the working tree, to be re-committed).
#
git-read-tree -f -m $parent && echo $parent > .git/HEAD
NOTE! The commit still _exists_, but the HEAD reference to it is now lost.
If you want to save that as a broken branch, you can precede this with
git branch broken-branch
which means that the broken point got saved off as "broken-branch".
And if you didn't do that (or if you _did_ do that, and later end up
deciding to throw that branch away with a
rm .git/refs/heads/broken-branch
or similar) then you can get rid of the stale and unreachable objects with
a simple "git prune".
Be careful! "git prune" _will_ throw away all the objects that it can't
find references to. You might want to run "git-fsck-cache --full
--unreachable" first to get an idea of what it's going to throw away.
Linus
^ permalink raw reply
* Re: qgit-0.81
From: Linus Torvalds @ 2005-08-07 0:26 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
In-Reply-To: <20050806215323.86191.qmail@web26303.mail.ukl.yahoo.com>
On Sat, 6 Aug 2005, Marco Costalba wrote:
>
> Some little new stuff too, complete changelog below:
>
> - added move back/forward in selection history
>
> - added "hyperlinks" SHA1's in commit messages
Ok, this is nicer than gitk, with the parents showing up in the commit
message and thus easy to go to. You might add children too: it's not
something git itself knows about intrisically, but since you've already
built the graph, at least you see what children are part of that graph..
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..
A couple of quick comments:
- 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.
- The qgit graph is not as pretty as the gitk one. Any chance of making
the bullets a bit smaller, and having an option to not do the
"jump-over-bumps"?
- the "file annotation" window is nice, but it _really_ shouldn't do line
wrapping. If you make the window narrower, you'll see it wrap and look
horrible.. Are all text windows always wrapped in QT?
- You edit the commit comments heavily, and have no options to unedit.
For example, I need the emails in the sign-offs if I ever cut-and-paste
to an email client when I sent a "hey, this commit broke so-and-so.."
- the "format a patch to be sent as email" thing says "at least two
revisions needed" when you only have one. Why? One of my more common
cases is that I send one commit as a patch, and now I do
git-diff-tree -p --pretty [commit-id] > ~/diff
and then just send that. A single commit _does_ describe a valid patch,
after all.
No biggie,
Linus
^ permalink raw reply
* cogito - how to drop a commit
From: Sam Ravnborg @ 2005-08-06 22:34 UTC (permalink / raw)
To: git
I accidently commited too many files to my tree today, and now I want to
drop the commit so I have logically separate commits.
What is the right way to do this - in cogito hopefully.
I do not mind to execute a few git commands, but for my daily usage I
expect cogito to hanle everything and dropping a commit has proved
useful for me from time to time, so I expect it be be implemented in the
porcelain somehow.
I have read the help for cg-seek - but it di not convince me to be what
I seeked.
Sam
^ permalink raw reply
* qgit-0.81
From: Marco Costalba @ 2005-08-06 21:53 UTC (permalink / raw)
To: git
Hi all,
this is a fix release, mainly to accomodate the new 'A' flag instead of 'N'
in git-diff-tree format.
Some little new stuff too, complete changelog below:
- added move back/forward in selection history
- added "hyperlinks" SHA1's in commit messages
- fix cursor position in in commit messages when changing rev
- use GIT_DIR when available to fetch refs
- accomodate new git-diff-tree 'A' insted of 'N' flag format
- added save/restore of diff and file window's geometry
First two ideas, that I read today from the list,
are very cool, were fun to implement ;-).
Download link is:
http://prdownloads.sourceforge.net/qgit/qgit-0.81.tar.bz2?download
Marco
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: My Itchlist
From: Junio C Hamano @ 2005-08-06 19:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Linus Torvalds, git
In-Reply-To: <Pine.LNX.4.63.0508060846050.12882@wgmdd8.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> I think that we need a method to do a push in reverse: If a central
> repository has several branches, I might want to pull just those branches
> where the local head is a strict parent of the remote side, and get
> complains for the others. And maybe reference naming comes as a freebie
> with that.
I can first run "git ls-remote" to discover what are available
heads and tags, and choose to "git fetch" without actually
merging nor touching my references if I did not want to. I
could then attempt to "git resolve" offline, and if it results
in a real merge, not fast forward, and if I am in a hurry and do
not want to risk merging without thinking, I can just keep my
head and defer the merging part. I think that is what you are
getting at by "pull only when local is a strict parent of the
remote".
It is really the matter of where the ancestry computation
happens. You seem to think you would want to do it on the
central server side, but I tend to think that should be done on
the puller's side, like I outlined above. There are two
reasons:
(1) as you mentioned in a separate topic, the current
upload-pack/fetch-pack protocol pair seems to put a
nontrivial burden on the server side. I'd prefer to have
the client side do more work.
(2) You are interested in that remote branch, so while you may
not want to merge the upstream changes into the branch you
have your local modifications right away, it is likely you
eventually will. Fetching the objects would not be a
wasted traffic.
What Linus said makes a lot of sense to me. While the current
"git fetch" user interface captures a commonly used pattern of
fetching a single remote reference and optionally storing that
remote reference as a local reference under refs/heads, it is
cumbersome to use when you want to slurp objects needed for
multiple remote references and not store the references
themselves anywhere.
^ permalink raw reply
* Re: gitweb "tag" display
From: Junio C Hamano @ 2005-08-06 18:49 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <7vacju9az9.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> A git tag object can have its own text contents, but I do not
> see how I can get to it from gitweb.
I just realized that this is also unavailable in gitk, so please
consider this as a feature request to gitk as well.
If you can pop-up a temporary window that shows the tag contents
when I hover over a tag icon for 2 seconds, and remove that
temporary window when step outside it would be ideal. It is up
to you to implement the part to show my wife's picture, reading
"object-content-type: image/jpeg" thing ;-). That one was not a
serious request.
I have two more requests to gitk, which are related to each
other but not related to the "tag contents" one above:
- if "gitk --all" slurped 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.
- I have not looked at the code closely enough, but I cannot
find how to re-read references. I would appreciate it if it
allowed it. This relates to the bisect status visualization,
where the set of references changes _after_ the user started
gitk.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.13
From: Petr Baudis @ 2005-08-06 18:30 UTC (permalink / raw)
To: Dirk Behme; +Cc: git
In-Reply-To: <42F3A6B1.1060605@de.bosch.com>
Dear diary, on Fri, Aug 05, 2005 at 07:49:37PM CEST, I got a letter
where Dirk Behme <dirk.behme@de.bosch.com> told me that...
> Hi Petr,
>
> Petr Baudis wrote:
> > I'm happy to announce release 0.13 of the Cogito SCMish layer over the
> >GIT Tree History Storage tool. As usual, get it at:
> >
> > http://www.kernel.org/pub/software/scm/cogito
>
> Any plans to switch cogito (cg-pull) to curl only as well? As I
> understand it, git has already moved from wget to curl only.
>
> http://marc.theaimsgroup.com/?l=git&m=112292041713192&w=2
>
> For using cogito & git behind a firewall and http proxy which needs
> special authentication I think this is the only option. Unfortunately,
> wget and curl have different understandig how to get proxy user &
> password and therefore this doesn't work at the moment.
Cogito needs recursive download in order to pull patches. If you can
make curl do that, it would be cool.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
^ permalink raw reply
* gitweb "tag" display
From: Junio C Hamano @ 2005-08-06 18:27 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In-Reply-To: <20050806033654.GA27953@vrfy.org>
A git tag object can have its own text contents, but I do not
see how I can get to it from gitweb.
For example, I have "junio-gpg-pub" tag in my git.git
repository. This is a tag to a "blob" which is my public GPG
key. The "tag" object itself says:
object b92c9c07fe2d0d89c4f692573583c4753b5355d2
type blob
tag junio-gpg-pub
tagger Junio C Hamano <junkio@cox.net> 1123226972 -0700
This is the GPG key I use to sign GIT releases.
...
to tell people that they can use it to verify the tags signed by
me. I would appreciate that this description is visible
somewhere from gitweb. Clicking on the link just spews out the
blob contents, which is the ascii armored public key.
Of course I _could_ add textual description outside the ascii
armor in this particular case, but that approach would not work
in general --- my next funky tag _could_ point to a JPEG picture
with the tag description that says "my beautiful wife" ;-).
I realize that I am going tangent, but it would be very cool if
gitweb understood a tag payload that said something like this:
object b02c0c07fe2d0d80c4f602573583c4753b5355d2
type blob
tag my-beautiful-wife
tagger Junio C Hamano <junkio@cox.net> 1123226072 -0700
object-content-type: image/jpeg
Here is a textual description of the blob being pointed at
by this tag. For this example, it should say "this is my
wife's picture" or something like that.
No, I am not going to create that tag.
^ permalink raw reply
* gitk SHA link hovers
From: Linus Torvalds @ 2005-08-06 17:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Jeff Epler, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508060919150.3258@g5.osdl.org>
This makes the cursor change when you hover over a SHA1 link with the new
"hypertext" gitk commit ID linking feature.
All credit goes to Jeff Epler <jepler@unpythonic.net> and bugs are mine.
I don't actually know any tcl/tk, I'm just acting as a random monkey that
looks at what others do and mix it up.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1802,10 +1802,13 @@ proc selectline {l isnew} {
set linkid [string range $comment $s $e]
if {![info exists idline($linkid)]} continue
incr e
- $ctext tag conf link$i -foreground blue -underline 1
+ $ctext tag add link "$commentstart + $s c" "$commentstart + $e c"
$ctext tag add link$i "$commentstart + $s c" "$commentstart + $e c"
$ctext tag bind link$i <1> [list selectline $idline($linkid) 1]
}
+ $ctext tag conf link -foreground blue -underline 1
+ $ctext tag bind link <Enter> { %W configure -cursor hand2 }
+ $ctext tag bind link <Leave> { %W configure -cursor {} }
$ctext tag delete Comments
$ctext tag remove found 1.0 end
^ permalink raw reply
* [PATCH] send-pack: allow the same source to be pushed more than once.
From: Junio C Hamano @ 2005-08-06 17:25 UTC (permalink / raw)
To: git
The revised code accidentally inherited the restriction that a
reference can be pushed only once, only because the original did
not allow renaming. This is no longer necessary so lift it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
connect.c | 7 -------
1 files changed, 0 insertions(+), 7 deletions(-)
db27ee63929fa4a161c321daf52df5635fd4828c
diff --git a/connect.c b/connect.c
--- a/connect.c
+++ b/connect.c
@@ -190,13 +190,6 @@ static int match_explicit_refs(struct re
}
if (errs)
continue;
- if (matched_src->peer_ref) {
- errs = 1;
- error("src ref %s is sent to more than one dst.",
- matched_src->name);
- }
- else
- matched_src->peer_ref = matched_dst;
if (matched_dst->peer_ref) {
errs = 1;
error("dst ref %s receives from more than one src.",
^ permalink raw reply
* [PATCH] send-pack: allow generic sha1 expression on the source side.
From: Junio C Hamano @ 2005-08-06 17:24 UTC (permalink / raw)
To: git; +Cc: torvalds
As promised earlier. I will shortly push this out with another
send-pack fix, initially in the proposed updates branch.
------------
This extends the source side semantics to match what Linus
suggested.
An example:
$ git-send-pack kernel.org:/pub/scm/git/git.git pu^^:master pu
would allow me to push the current pu into pu, and the
commit two commits before it into master, on my public
repository.
The revised rule for updating remote heads is as follows.
$ git-send-pack [--all] <remote> [<ref>...]
- When no <ref> is specified:
- with '--all', it is the same as specifying the full refs/*
path for all local refs;
- without '--all', it is the same as specifying the full
refs/* path for refs that exist on both ends;
- When one or more <ref>s are specified:
- a single token <ref> (i.e. no colon) must be a pattern that
tail-matches refs/* path for an existing local ref. It is
an error for the pattern to match no local ref, or more
than one local refs. The matching ref is pushed to the
remote end under the same name.
- <src>:<dst> can have different cases. <src> is first tried
as the tail-matching pattern for refs/* path.
- If more than one matches are found, it is an error.
- If one match is found, <dst> must either match no remote
ref and start with "refs/", or match exactly one remote
ref. That remote ref is updated with the sha1 value
obtained from the <src> sha1.
- If no match is found, it is given to get_extended_sha1();
it is an error if get_extended_sha1() does not find an
object name. If it succeeds, <dst> must either match
no remote ref and start with "refs/" or match exactly
one remote ref. That remote ref is updated with the sha1
value.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
connect.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
15e02b372ddebd2aac829707786462798f91d509
diff --git a/connect.c b/connect.c
--- a/connect.c
+++ b/connect.c
@@ -133,6 +133,20 @@ static void link_dst_tail(struct ref *re
**tail = NULL;
}
+static struct ref *try_explicit_object_name(const char *name)
+{
+ unsigned char sha1[20];
+ struct ref *ref;
+ int len;
+ if (get_sha1(name, sha1))
+ return NULL;
+ len = strlen(name) + 1;
+ ref = xcalloc(1, sizeof(*ref) + len);
+ memcpy(ref->name, name, len);
+ memcpy(ref->new_sha1, sha1, 20);
+ return ref;
+}
+
static int match_explicit_refs(struct ref *src, struct ref *dst,
struct ref ***dst_tail, struct refspec *rs)
{
@@ -145,6 +159,12 @@ static int match_explicit_refs(struct re
case 1:
break;
case 0:
+ /* The source could be in the get_sha1() format
+ * not a reference name.
+ */
+ matched_src = try_explicit_object_name(rs[i].src);
+ if (matched_src)
+ break;
errs = 1;
error("src refspec %s does not match any.");
break;
^ permalink raw reply
* Re: Make git-sh-setup-script do what it was supposed to do
From: Junio C Hamano @ 2005-08-06 17:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508061002370.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> Duh. A missing && meant that half the tests that git-sh-setup-script were
> _meant_ to do were actually totally ignored.
>
> In particular, the git sanity checking ended up only testing that the
> GIT_OBJECT_DIRECTORY was sane, not that GIT_DIR itself was..
Ouch. Thanks.
^ permalink raw reply
* Re: gitk "hyperlinks" (was Re: Display of merges in gitk)
From: jepler @ 2005-08-06 17:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, Kay Sievers, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508060919150.3258@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 756 bytes --]
On Sat, Aug 06, 2005 at 09:20:16AM -0700, Linus Torvalds wrote:
> Looks good also. I assume the mouse can't change when it hovers?
In gitk? This is be possible. My patch[1] does it. The way it's done stinks a
little bit, though. <Enter> and <Leave> are bound on a tag common to all the
"hyperlinks", and change the -cursor of the whole widget---either to hand2 or
the empty string.
+ $ctext tag bind Commit <Enter> { %W configure -cursor hand2 }
+ $ctext tag bind Commit <Leave> { %W configure -cursor {} }
My patch also underlines links, as requested in a different message in this thread.
+ $ctext tag configure Commit -underline yes -foreground blue
Jeff
[1] http://www.gelato.unsw.edu.au/archives/git/0508/7253.html
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Make git-sh-setup-script do what it was supposed to do
From: Linus Torvalds @ 2005-08-06 17:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Duh. A missing && meant that half the tests that git-sh-setup-script were
_meant_ to do were actually totally ignored.
In particular, the git sanity checking ended up only testing that the
GIT_OBJECT_DIRECTORY was sane, not that GIT_DIR itself was..
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
diff --git a/git-sh-setup-script b/git-sh-setup-script
--- a/git-sh-setup-script
+++ b/git-sh-setup-script
@@ -12,6 +12,6 @@ die() {
}
[ -d "$GIT_DIR" ] &&
-[ -d "$GIT_DIR/refs" ]
+[ -d "$GIT_DIR/refs" ] &&
[ -d "$GIT_OBJECT_DIRECTORY" ] &&
[ -d "$GIT_OBJECT_DIRECTORY/00" ]
^ permalink raw reply
* Re: gitk "hyperlinks"
From: Junio C Hamano @ 2005-08-06 16:31 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17140.47152.672091.474748@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> Good idea. Also done. :) It's on master.kernel.org now in my gitk.git
> directory. Hopefully Junio will pull it into git soon.
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.
------------
[PATCH] gitk proposed fix: handle more than one SHA1 links.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
gitk | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
c423b62a66d4c4f2a7856cada507f973e9140590
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1802,6 +1802,7 @@ proc selectline {l isnew} {
set linkid [string range $comment $s $e]
if {![info exists idline($linkid)]} continue
incr e
+ incr i
$ctext tag conf link$i -foreground blue -underline 1
$ctext tag add link$i "$commentstart + $s c" "$commentstart + $e c"
$ctext tag bind link$i <1> [list selectline $idline($linkid) 1]
^ 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