GIT 0.99.4 (preview)
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. - 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 "hyperlinks" (was Re: Display of merges in gitk)
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 - 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: gitweb "tag" display
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 <[EMAIL PROTECTED]> 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 - 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-local-pull?
Petr Baudis <[EMAIL PROTECTED]> 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. - 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: Extend "git reset" to take a reset point
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". - 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
Extend "git reset" to take a reset point
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 <[EMAIL PROTECTED]> --- 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" - 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: qgit-0.81
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 - 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: cogito - how to drop a commit
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 - 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
cogito - how to drop a commit
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 - 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
qgit-0.81
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 - 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: My Itchlist
Johannes Schindelin <[EMAIL PROTECTED]> 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. - 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: gitweb "tag" display
Junio C Hamano <[EMAIL PROTECTED]> 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. - 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: [ANNOUNCE] Cogito-0.13
Dear diary, on Fri, Aug 05, 2005 at 07:49:37PM CEST, I got a letter where Dirk Behme <[EMAIL PROTECTED]> 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 - 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
gitweb "tag" display
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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. - 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
gitk SHA link hovers
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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 { %W configure -cursor hand2 }
+$ctext tag bind link { %W configure -cursor {} }
$ctext tag delete Comments
$ctext tag remove found 1.0 end
-
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] send-pack: allow the same source to be pushed more than once.
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 <[EMAIL PROTECTED]>
---
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.",
-
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] send-pack: allow generic sha1 expression on the source side.
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] [...]
- When no 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 s are specified:
- a single token (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.
- : can have different cases. 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, 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 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, 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 <[EMAIL PROTECTED]>
---
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;
-
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: Make git-sh-setup-script do what it was supposed to do
Linus Torvalds <[EMAIL PROTECTED]> 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. - 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 "hyperlinks" (was Re: Display of merges in gitk)
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. and 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 { %W configure -cursor hand2 }
+$ctext tag bind Commit { %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
pgpTyavkb8S8o.pgp
Description: PGP signature
Make git-sh-setup-script do what it was supposed to do
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 <[EMAIL PROTECTED]>
---
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" ]
-
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 "hyperlinks"
Paul Mackerras <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
---
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]
-
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 "hyperlinks" (was Re: Display of merges in gitk)
On Sat, 6 Aug 2005, Paul Mackerras wrote: > Linus Torvalds writes: > > > > - "clickable" SHA1's in commit messages would be really really cool if > >something like that is even possible with tcl/tk. > > Done, and it was even pretty easy. It took only about a dozen lines. Looks good also. I assume the mouse can't change when it hovers? > Good idea. Also done. :) It's on master.kernel.org now in my gitk.git > directory. Hopefully Junio will pull it into git soon. The current > version also squishes the graph horizontally if it gets too wide > (i.e. more than half the width of the top-left pane). Yeah, that looks weird when the lines start turning soft ans squiggly. 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: gitk "hyperlinks" (was Re: Display of merges in gitk)
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? But yes, works well. Thanks, 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: gitk "hyperlinks" (was Re: Display of merges in gitk)
Linus Torvalds writes: > - "clickable" SHA1's in commit messages would be really really cool if >something like that is even possible with tcl/tk. Done, and it was even pretty easy. It took only about a dozen lines. > - I'd like to have a "back button". Not just for the above kind of thing, >but in general too: when searching for something, it would just be very >nice if gitk just kept a list of the last commits that have >been selected, and there was a web-browser-like button that went >back/forward in history. Good idea. Also done. :) It's on master.kernel.org now in my gitk.git directory. Hopefully Junio will pull it into git soon. The current version also squishes the graph horizontally if it gets too wide (i.e. more than half the width of the top-left pane). 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: New script: cg-clean
Hello, Petr!
Sorry for delay.
On Sun, 2005-07-10 at 17:46 +0200, Petr Baudis wrote:
> Dear diary, on Sat, Jul 09, 2005 at 12:34:44AM CEST, I got a letter
> where Pavel Roskin <[EMAIL PROTECTED]> told me that...
> > Hello, Petr!
>
> Hello,
>
> > Please consider this script for Cogito.
> >
> > Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
>
> the script is definitively interesting, but I have couple of notes
> about it first:
>
> (i) -i sounds wrong for anything but being interactive here ;-) What
> about -A?
I agree that -i could be confusing, but -A would seem to imply "All", so
let it be -x from "exclude".
> (ii) I'm confused - if -a is all of the above, how do I clean _only_
> regular files, and only those not ignored by cg-status?
cg-clean without options. I'm changing the description to avoid
confusion.
> (iii) Makes it any sense to remove only special files?
I thought it would make sense to have an option to remove them in
addition to regular files, but now I think it's not worth the trouble to
distinguish between them.
> (iv) -r implies being recursive, but it has nothing to do with that
> here.
Renamed to -d. Other confusing options have been removed. "-a" is
retired because it's not hard to type "-dx". Explicit arguments are not
accepted - one can easily use "rm" instead. That should make cg-clean
much simpler.
> (v) Semantically, I think it's quite close to cg-reset. What about
> making it part of cg-reset instead of a separate command? I tend to be
> careful about command inflation. (That's part of being careful about the
> usability in general.) That's just an idea and possibly a bad one, what
> do you think?
I understand your concern, but cg-reset does other things. cg-reset
changes the branch. cg-clean allows to start the build from scratch
without changing the branch.
It's not uncommon for me to revert patches one-by-one looking for the
patch that breaks something. I could make minor changes e.g for
debugging or to fix breakage in certain revisions. I would revert such
by cg-clean before going to another revision. cg-reset would be an
overkill - it would move me to the latest release.
I can imagine that cg-reset would call cg-clean (optionally) to allow
fresh start on the main branch. The opposite would be wrong.
Here's the simplified cg-clean script. Note that the "-d" option is not
working with the current version of git of a bug in git-ls-files. I can
work it around by scanning all directories in bash, but I think it's
easier to fix git (remove "continue" before DT_REG in ls-files.c).
Processing of .gitignore was taken from cg-status, and I don't really
understand it. But I think it's important to keep that code in sync.
It could later go to cg-Xlib.
Signed-off-by: Pavel Roskin <[EMAIL PROTECTED]>
#!/usr/bin/env bash
#
# Clean unknown files from the working tree.
# Copyright (c) Pavel Roskin, 2005
#
# Cleans file and directories that are not under version control.
# When run without arguments, files ignored by cg-status and directories
# are not removed.
#
# OPTIONS
# ---
# -d::
# Also clean directories.
#
# -x::
# Also clean files ignored by cg-status, such as object files.
USAGE="cg-clean [-d] [-x]"
. ${COGITO_LIB}cg-Xlib
cleanexclude=
cleandir=
while optparse; do
if optparse -d; then
cleandir=1
elif optparse -x; then
cleanexclude=1
else
optfail
fi
done
# Good candidate for cg-Xlib
# Put exclude options for git-ls-files to EXCLUDE
set_exclude() {
EXCLUDE=
stdignores=('*.[ao]' '.*' tags '*~' '#*' ',,merge*')
for ign in "[EMAIL PROTECTED]"; do
EXCLUDE="$EXCLUDE --exclude=$ign"
done
EXCLUDEFILE=$_git/exclude
if [ -f "$EXCLUDEFILE" ]; then
EXCLUDE="$EXCLUDE --exclude-from=$EXCLUDEFILE"
fi
{
path="$_git_relpath"
dir=
[ -r .gitignore ] && EXCLUDE="$EXCLUDE
--exclude-from=.gitignore"
while [[ "$path" == */* ]]; do
dir="${dir:-.}/${path%%/*}"
path="${path#*/}"
[ -r $dir/.gitignore ] && EXCLUDE="$EXCLUDE
--exclude-from=$dir/.gitignore"
done
}
}
if [ -z "$cleanexclude" ]; then
set_exclude
else
EXCLUDE=
fi
git-update-cache --refresh > /dev/null
# Need to use temporary file so that changing IFS doesn't affect $EXCLUDE
# expansion.
filelist=$(mktemp -t gitlsfiles.XX)
git-ls-files --others $EXCLUDE >"$filelist"
save_IFS="$IFS"
IFS=$'\n'
for file in $(cat "$filelist"); do
IFS="$save_IFS"
if [ -d "$file" ]; then
if [ "$cleandir" ]; then
# Try really hard by changing permissions
chmod -R 700 "$file"
rm -rf "$file"
fi
return
fi
rm -f "$
