* Re: bisect gives strange answer
From: Sanjoy Mahajan @ 2005-08-05 15:38 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Greg KH, Junio C Hamano, git
In-Reply-To: <20050804192838.GB26714@mars.ravnborg.org>
> If you see any sort of evidence that this would hold true I really like
> to know.
I haven't found any evidence. When I rebuilt the kernels from scratch
(exporting them into an empty directory using cg-export), I got
reliable data and bisected down to a patch that probably was a problem.
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.
-Sanjoy
^ permalink raw reply
* [PATCH] Teach rev-list since..til notation.
From: Junio C Hamano @ 2005-08-04 9:34 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
In-Reply-To: <Pine.LNX.4.58.0508032236470.3258@g5.osdl.org>
The King Penguin says:
Now, for extra bonus points, maybe you should make "git-rev-list" also
understand the "rev..rev" format (which you can't do with just the
get_sha1() interface, since it expands into more).
The faithful servant makes it so.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
rev-list.c | 38 ++++++++++++++++++++++++++++++--------
1 files changed, 30 insertions(+), 8 deletions(-)
f22d271a469b65760f73dc483aeb2448619e0ff1
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -457,6 +457,15 @@ static struct commit *get_commit_referen
die("%s is unknown object", name);
}
+static void handle_one_commit(struct commit *com, struct commit_list **lst)
+{
+ if (!com || com->object.flags & SEEN)
+ return;
+ com->object.flags |= SEEN;
+ commit_list_insert(com, lst);
+}
+
+
int main(int argc, char **argv)
{
struct commit_list *list = NULL;
@@ -465,6 +474,7 @@ int main(int argc, char **argv)
for (i = 1 ; i < argc; i++) {
int flags;
char *arg = argv[i];
+ char *dotdot;
struct commit *commit;
if (!strncmp(arg, "--max-count=", 12)) {
@@ -523,21 +533,33 @@ int main(int argc, char **argv)
continue;
}
+ if (show_breaks && !merge_order)
+ usage(rev_list_usage);
+
flags = 0;
+ dotdot = strstr(arg, "..");
+ if (dotdot) {
+ char *next = dotdot + 2;
+ struct commit *exclude = NULL;
+ struct commit *include = NULL;
+ *dotdot = 0;
+ exclude = get_commit_reference(arg, UNINTERESTING);
+ include = get_commit_reference(next, 0);
+ if (exclude && include) {
+ limited = 1;
+ handle_one_commit(exclude, &list);
+ handle_one_commit(include, &list);
+ continue;
+ }
+ *next = '.';
+ }
if (*arg == '^') {
flags = UNINTERESTING;
arg++;
limited = 1;
}
- if (show_breaks && !merge_order)
- usage(rev_list_usage);
commit = get_commit_reference(arg, flags);
- if (!commit)
- continue;
- if (commit->object.flags & SEEN)
- continue;
- commit->object.flags |= SEEN;
- commit_list_insert(commit, &list);
+ handle_one_commit(commit, &list);
}
if (!merge_order) {
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.13
From: Jay Denebeim @ 2005-08-05 17:28 UTC (permalink / raw)
To: git
Um, guys...
If you want to have a dependency on git-core >= 0.99.3 you need to
actually like, you know, put it on-line as well. Just did a yum update,
fails with:
error: Failed dependencies:
git-core >= 0.99.3 is needed by cogito-0.13-1
But on the git repository the git-core == 0.99.1
might wanna fix that. (and man is google fast)
Jay
--
* Jay Denebeim Moderator rec.arts.sf.tv.babylon5.moderated *
* newsgroup submission address: b5mod@deepthot.org *
* moderator contact address: b5mod-request@deepthot.org *
* personal contact address: denebeim@deepthot.org *
^ permalink raw reply
* Re: Template files location
From: Junio C Hamano @ 2005-08-05 17:33 UTC (permalink / raw)
To: Petr Baudis; +Cc: Chris Wright, Linus Torvalds, git
In-Reply-To: <20050805094324.GF29216@pasky.ji.cz>
Petr Baudis <pasky@ucw.cz> writes:
> Any reason why that's not the default destination then?
Inertia, installing things under $HOME, is why it is not the
default. It may be that the project is mature enough that it is
time to move away from default installation in HOME, IOW to
change the Makefile to say prefix=/usr/local (or prefix=/usr)
to match practices of other projects [*1*].
> Or you can try /etc/git-core/ and fall back to /usr/share/git-core :-)
If the template files are to become something that always have
to exist, /etc first and then falling back on /usr/share would
make a lot of sense. But as Johannes Schindelin correctly
argued against the "Use the template mechanism to set up refs/
hierarchy as well." patch [*2*], I think git-init-db should work
when there is no template directory. In other words, its
primary purpose is to help local project administrators ensure
newly created repositories have hooks and probably info/exclude
that they recommend to the project members.
The reason to have a sample one shipped as part of the core
package is just to help newbies --- they would get a boilerplate
hooks/update that explains how they can set it up when they do
git-init-db even when they do not have their own customized set
of templates yet. For this kind of use, I do not think one
default falling back to another is needed.
Come to think of it, GIT_TEMPLATE_DIRECTORY environment variable
does not make _ANY_ sense; I am an idiot. It is used only by
git-init-db and the reason to have it is to override the
default. It should become the command line parameter of it.
I'll fix up this breakage soonish.
[Footnote]
*1* This would probably break Linus, myself and others ---
everybody has to say "make prefix=$HOME", so I do not think I am
actually going to do it any time soon, if ever.
Having prefix=/usr/local as default only helps people who are
installing system-wide from the source, and nobody else. People
who are writing spec.in and/or debian/rules need to override it
to prefix=/usr anyway, and it forces people who are installing
to their home to say prefix=$HOME/. I suspect it is an inertia
from the good old days when nobody used binary distributions.
*2* And I am sure many others shared the same objection but did
not even bother to say anything because what Johannes said made
a lot of sense and what the patch did was obviously wrong.
^ permalink raw reply
* Re: Template files location
From: A Large Angry SCM @ 2005-08-05 17:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Petr Baudis, Chris Wright, Linus Torvalds, git
In-Reply-To: <7vpsssjnld.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
...
> If the template files are to become something that always have
> to exist, /etc first and then falling back on /usr/share would
> make a lot of sense. But as Johannes Schindelin correctly
> argued against the "Use the template mechanism to set up refs/
> hierarchy as well." patch [*2*], I think git-init-db should work
> when there is no template directory. In other words, its
> primary purpose is to help local project administrators ensure
> newly created repositories have hooks and probably info/exclude
> that they recommend to the project members.
So templates are project specific.
> The reason to have a sample one shipped as part of the core
> package is just to help newbies --- they would get a boilerplate
> hooks/update that explains how they can set it up when they do
> git-init-db even when they do not have their own customized set
> of templates yet. For this kind of use, I do not think one
> default falling back to another is needed.
Shipping samples with the plumbing makes sense, especially when the
documentation in is insufficient. But installing the samples as part of
the default install process seems less than desirable. Or, alternately,
install the samples in with the documentation as (non-executable) examples.
...
> *1* This would probably break Linus, myself and others ---
> everybody has to say "make prefix=$HOME", so I do not think I am
> actually going to do it any time soon, if ever.
>
> Having prefix=/usr/local as default only helps people who are
> installing system-wide from the source, and nobody else. People
> who are writing spec.in and/or debian/rules need to override it
> to prefix=/usr anyway, and it forces people who are installing
> to their home to say prefix=$HOME/. I suspect it is an inertia
> from the good old days when nobody used binary distributions.
Rather than changing the default install location in such a way as to
make half the user unhappy, make everybody (un)happy by removing the
default and forcing it to be specified when make is executed.
^ permalink raw reply
* Re: [ANNOUNCE] Cogito-0.13
From: Chris Wright @ 2005-08-05 18:26 UTC (permalink / raw)
To: Jay Denebeim; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508051026010.7809@hotblack.deepthot.org>
* Jay Denebeim (denebeim@deepthot.org) wrote:
> Um, guys...
>
> If you want to have a dependency on git-core >= 0.99.3 you need to
> actually like, you know, put it on-line as well. Just did a yum update,
> fails with:
>
> error: Failed dependencies:
> git-core >= 0.99.3 is needed by cogito-0.13-1
>
> But on the git repository the git-core == 0.99.1
>
> might wanna fix that. (and man is google fast)
I've uploaded the rpms yesterday, but they haven't been staged for
mirroring yet.
thanks,
-chris
^ permalink raw reply
* Re: Terminology
From: Linus Torvalds @ 2005-08-05 18:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.63.0508051655480.8418@wgmdd8.biozentrum.uni-wuerzburg.de>
On Fri, 5 Aug 2005, Johannes Schindelin wrote:
>
> Tutorial says "cache" aka "index". Though technically, a cache
> is the index file _plus_ the related objects in the object database.
> git-update-cache.txt even makes the difference between the "index"
> and the "directory cache".
I think we should globally rename it to "index".
The "directory cache" and later "cache" naming came from when I started
doing the work - before git was even git at all, and had no backing store
what-so-ever, I started out writing "cache.h" and "read-cache.c", and it
was really first a trial at doing a totally SCM-neutral directory cache
front-end.
You don't even see that in the git revision history, because that was
before git was self-hosting - the project was partly started to also work
as possibly just a fast front-end to something that wasn't as fast (ie
think something like a front-end to make "monotone" work better).
So the "directory cache" and "cache" naming comes from that historical
background: it was really started as a front-end cache, and in fact the
".git" directory was called ".dircache" initially. You can see some of
that in the very earliest git releases: by then I had already done the
backing store, and the thing was already called "git", but the "dircache"
naming still remains in places.
For example, here's my "backup" target in the initial checkin:
backup: clean
cd .. ; tar czvf dircache.tar.gz dir-cache
which shows that not only did I call the resulting tar file "dircache",
the directory I was developing stuff in was called "dir-cache" as well ;)
The index obviously ended up doing a lot more, and especially with the
different stages it became much more than just a directory cache thing:
it's integral to how git does the fast part of a merge. So we should call
it "index" and edit out the old "cache" and "director cache" naming
entirely.
> - the directory which corresponds to the top of the hierarchy
> described in the index file; I've seen words like "working
> tree", "working directory", "work tree" used.
>
> The tutorial initially says "working tree", but then "working
> directory". Usually, a directory does not include its
> subdirectories, though. git-apply-patch-script.txt, git-apply.txt,
> git-hash-object.txt, git-read-tree.txt
> use "work tree". git-checkout-cache.txt, git-commit-tree.txt,
> git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain
> "working directory". git-diff-files.txt talks about a "working tree".
I think we should use "working tree" throughout, since "working directory"
is unix-speak for "pwd" and has a totally different meaning.
> - When the stat information a cache entry records matches what
> is in the work tree, the entry is called "clean" or
> "up-to-date". The opposite is "dirty" or "not up-to-date".
>
> - An index file can be in "merged" or "unmerged" state. The
> former is when it does not have anything but stage 0 entries,
> the latter otherwise.
I think the "unmerged" case should be mentioned in the "cache entry"
thing, since it's really a per-entry state, exactly like "dirty/clean".
Then, explaining a "unmerged index" as being an index file with some
entries being unmerged makes more sense.
As it is, the above "explains" an index file as being unmerged by talking
about "stage 0 entries", which in turn haven't been explained at all.
> - A "tree object" can be recorded as a part of a "commit
> object". The tree object is said to be "associated with" the
> commit object.
>
> In diffcore.txt, "changeset" is used in place of "commit".
We really should use "commit" throughout. ex-BK users sometimes lip into
"changeset" (which in turn is probably because BK had these per-file
commits too - deltas), but there's no point in the distinction in git. A
commit is a commit.
> - The following objects are collectively called "tree-ish": a
> tree object, a commit object, a tag object that resolves to
> either a commit or a tree object, and can be given to
> commands that expect to work on a tree object.
>
> We could call this category an "ent".
LOL. You are a total geek.
> - The files under $GIT_DIR/refs record object names, and are
> called "refs". What is under refs/heads/ are called "heads",
> refs/tags/ "tags". Typically, they are either object names
> of commit objects or tag objects that resolve to commit
> objects, but a tag can point at any object.
>
> The tutorial never calls them "refs", but instead "references".
It might be worth saying explicitly that a reference is nothing but the
same thing as a "object name" aka "sha1". And make it very clear that it
can point to any object type, although commits tend to be the most common
thng you want to reference. That then leads naturally into a very specific
_subcase_ of refs, namely a "head":
> - A "head" is always an object name of a commit, and marks the
> latest commit in one line of development. A line of
> development is often called a "branch". We sometimes use the
> word "branch head" to stress the fact that we are talking
> about a single commit that is the latest one in a "branch".
>
> In the tutorial, the latter is used in reverse: it talks about a
> "HEAD development branch" and a "HEAD branch".
>
> I find it a little bit troublesome that $GIT_DIR/branches does not
> really refer to a branch, but rather to a (possibly remote) repository.
Yes, I find the $GIT_DIR/branches naming to be confusing too.
They are really pointers to external repositories, and "branch" is
confusing. But I suspect the confusion is partly due to me, since I used
to think (and argue) that we should aim for a "separate repositories for
separate branches" approach.
That single-branch-multiple-repository mentality came from my BK
background, and from me thinking that local branches would be confusing.
Jeff has been dragging me into the "local branches are good" camp, and
these days I'm obviously a big believer. But the blame for this confusion
falls squarely on me, with Pasky picking it up from there into cogito and
using the "branches" name, and then git pickin git back up from cogito
through trying to compatible.
> - The act of finding out the object names recorded in "refs" a
> different repository records, optionally updating a local
> "refs" with their values, and retrieving the objects
> reachable from them is called "fetching". Fetching immediately
> followed by merging is called "pulling".
>
> In that sense, git-http-pull would be more appropriately named
> git-http-fetch, and analogous git-ssh-pull.
>
> Also, git-pull-script.txt says "Pull and merge", contradicting this
> definition.
To confuse things even more, cogito calls a fetch "pull" and a pull
"update".
I personally think "fetch" is unambigious: it's just the act of fetching,
with no "merge" activity at all. So we should use that.
What to call a "fetch+merge" is a bit ambiguous. I obviously prefer
"pull", but cogito disagrees, and you're right, "git-http-pull" and
"git-ssh-pull" both really do just fetches.
But I think "update" isn't right either: to me, update would be the
non-merging kind (ie I think "update" implies "refresh" which in turn
implies a "fetch"-like behaviour).
So I'd vote for making the suggested definition official: "fetch" means
fetching the data, and "pull" means "fetch + merge".
And "update" would be just something that happens to refs: A "fetch" will
obviously update the reference that we had to the external tree we fetched
from, while a commit/merge/whatever will obviously update the current
branch reference (HEAD).
So "update" would really be just a small technical detail.
> - a "pack" usually consists of two files: a file containing objects
> in a compressed format, and an index to the first file. If the
> pack is uncompressed at once (e.g. when git-clone is called), the
> index is not necessary.
>
> git-pack-objects calls this a "packed archive" first, but then reverts
> to "pack". git-show-index.txt and git-verify-pack.txt call the .pack file
> "packed GIT archive", and the index "idx file". git-unpack-objects.txt
> calls the .pack file "pack archive".
We should just call them packs. An archive can be multiple packs and lots
of non-packed objects too.
> "plumbing", also referred to as "core": the basic set of programs and
> scripts usable to half-gods like Linus.
>
> "porcelain", also referred to as "SCM": a thin layer over the plumbing
> making GIT usage nice to regular people.
>
> "type": one of the identifiers "commit","tree","tag" and "blob" describing
> the type of an object.
Yes. Some old docs may call this type a "tag", since I was really thinking
in not in the SCM meaning at all, but in the _computer_architecture_
meaning, where people usually call objects with enforced types "tagged".
Ie from a computer architecture standpoint you can have "tagged memory" or
"tagged pointers", and LISP machines are often implemented with the
pointers containing the type ("tag") of the thing they point to (for
example, the low two bits might be the "tag" on the pointer). So I was
talking about "tagged objects" when I just meant that the type of the
object was embedded in the object itself, the way tagged memory
architectures work.
In retrospect, that naming _really_ confused some people, I know I had
trouble explaining git concepts to David Wheeler because I used "tagged
objects" _not_ to mean a SCM style "tag", but to mean "typed objects".
If somebody sees an old reference to "object tags", those should all be
fixed to say "object types".
Linus
^ permalink raw reply
* Re: [RFC] git homepage
From: Martin Atukunda @ 2005-08-05 18:41 UTC (permalink / raw)
To: git
In-Reply-To: <20050805012728.GO24479@pasky.ji.cz>
On Friday 05 August 2005 04:27, Petr Baudis wrote:
> etc. And if you don't author any porcelain, send me updates anyway. :-)
>
<from the site>
gitk is a simple GTK GUI for browsing history of GIT repositories easily.
^^^
</from the site>
- Martin -
---
--- index.html 2005-08-05 21:38:20.605324272 +0300
+++ index.html.new 2005-08-05 21:38:44.804645416 +0300
@@ -148,7 +148,7 @@
<dt id="gitk">gitk</dt>
<dd><a href="http://ozlabs.org/~paulus/gitk/">gitk</a> is a simple
-GTK GUI for browsing history of GIT repositories easily.</dd>
+TK GUI for browsing history of GIT repositories easily.</dd>
<dt id="qgit">qgit</dt>
<dd><a href="http://sourceforge.net/projects/qgit">qgit</a> is a QT
^ permalink raw reply
* Re: gitk "hyperlinks" (was Re: Display of merges in gitk)
From: jepler @ 2005-08-05 18:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508050710460.3258@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 2305 bytes --]
On Fri, Aug 05, 2005 at 07:37:41AM -0700, Linus Torvalds wrote:
> For 2.6.13 we've been reverting some stuff lately, to make sure we get a
> stable release. That's fine, and when I revert something I try to mention
> the commit ID of the thing I revert in the message. Apparently others do
> too, as indicated by a patch I just got from Petr Vandovec. So we've got
> for example:
[snipped]
The following code worked for me on a toy commit. I'm not sure the regular
expression in linkcommits is right if the SHA1 is followed by a colon or a comma,
as I noticed it was in your examples. If it doesn, then removing the [[:<:]]
and [[:>:]] will probably fix it.
Things that look like SHA1s are highlighted even if they don't actually exist.
There is probably a "more right" place to do the '$ctext tag bind Commit' commands
but I didn't find it right away.
diff --git a/gitk b/gitk
--- a/gitk
+++ b/gitk
@@ -1753,6 +1753,11 @@ proc selectline {l} {
$ctext conf -state disabled
set commentend [$ctext index "end - 1c"]
+ linkcommits $ctext 0.0 $commentend
+ $ctext tag configure Commit -underline yes -foreground blue
+ $ctext tag bind Commit <Enter> { %W configure -cursor hand2 }
+ $ctext tag bind Commit <Leave> { %W configure -cursor {} }
+ $ctext tag bind Commit <Button-1><ButtonRelease-1> { linkclick %W %x %y }
$cflist delete 0 end
$cflist insert end "Comments"
if {$nparents($id) == 1} {
@@ -1762,6 +1767,30 @@ proc selectline {l} {
}
}
+proc linkclick {w x y} {
+ set index [$w index @$x,$y]
+ set tags [$w tag names $index]
+ foreach c $tags {
+ if {![string match {C_*} $c]} { continue; }
+ global sha1string
+ set sha1string [string range $c 2 end]
+ gotocommit
+ }
+}
+
+proc linkcommits {w start end} {
+ while {1} {
+ set pos [$w search -regexp {[[:<:]][0-9a-fA-F]{40}[[:>:]]} $start $end]
+ if {$pos == {}} {break}
+
+ set commit [$w get $pos "$pos+40c"]
+
+ $w tag add Commit $pos "$pos+40c"
+ $w tag add C_$commit $pos "$pos+40c"
+ set start [$w index "$pos+40c"]
+ }
+}
+
proc selnextline {dir} {
global selectedline
if {![info exists selectedline]} return
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Terminology
From: barkalow @ 2005-08-05 19:53 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508051104510.3258@g5.osdl.org>
On Fri, 5 Aug 2005, Linus Torvalds wrote:
> On Fri, 5 Aug 2005, Johannes Schindelin wrote:
>
> > - The files under $GIT_DIR/refs record object names, and are
> > called "refs". What is under refs/heads/ are called "heads",
> > refs/tags/ "tags". Typically, they are either object names
> > of commit objects or tag objects that resolve to commit
> > objects, but a tag can point at any object.
> >
> > The tutorial never calls them "refs", but instead "references".
>
> It might be worth saying explicitly that a reference is nothing but the
> same thing as a "object name" aka "sha1".
Well, it's an object name stored in a file. This adds a layer of
indirection and a meaningful name.
> So I'd vote for making the suggested definition official: "fetch" means
> fetching the data, and "pull" means "fetch + merge".
So what's the converse of "fetch" (to rename git-ssh-push to)?
Maybe "ship"?
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Terminology
From: Johannes Schindelin @ 2005-08-05 23:08 UTC (permalink / raw)
To: barkalow; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.62.0508051531400.23721@iabervon.org>
Hi,
On Fri, 5 Aug 2005, barkalow@iabervon.org wrote:
> On Fri, 5 Aug 2005, Linus Torvalds wrote:
>
> > On Fri, 5 Aug 2005, Johannes Schindelin wrote:
> >
> > > - The files under $GIT_DIR/refs record object names, and are
> > > called "refs". What is under refs/heads/ are called "heads",
> > > refs/tags/ "tags". Typically, they are either object names
> > > of commit objects or tag objects that resolve to commit
> > > objects, but a tag can point at any object.
> > >
> > > The tutorial never calls them "refs", but instead "references".
> >
> > It might be worth saying explicitly that a reference is nothing but the
> > same thing as a "object name" aka "sha1".
>
> Well, it's an object name stored in a file. This adds a layer of
> indirection and a meaningful name.
Yes.
> > So I'd vote for making the suggested definition official: "fetch" means
> > fetching the data, and "pull" means "fetch + merge".
>
> So what's the converse of "fetch" (to rename git-ssh-push to)?
> Maybe "ship"?
I actually like "push". You know, not everybody agrees that "push" is the
opposite of "pull"...
Ciao,
Dscho
^ permalink raw reply
* Re: Terminology
From: Johannes Schindelin @ 2005-08-05 23:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508051104510.3258@g5.osdl.org>
Hi,
wow! What a long mail! But I probably deserved it, quoting that lengthy
mail from Junio...
On Fri, 5 Aug 2005, Linus Torvalds wrote:
> On Fri, 5 Aug 2005, Johannes Schindelin wrote:
> >
> > Tutorial says "cache" aka "index". Though technically, a cache
> > is the index file _plus_ the related objects in the object database.
> > git-update-cache.txt even makes the difference between the "index"
> > and the "directory cache".
>
> I think we should globally rename it to "index".
Totally agree. The index is a central concept. But let's keep in mind --
and make future Documentation/ readers do the same -- that the index,
without the referenced objects in the objects database, is only a
skeleton.
> The "directory cache" and later "cache" naming came from when I started
> doing the work - before git was even git at all, and had no backing store
> what-so-ever, I started out writing "cache.h" and "read-cache.c", and it
> was really first a trial at doing a totally SCM-neutral directory cache
> front-end.
>
> You don't even see that in the git revision history, because that was
> before git was self-hosting - the project was partly started to also work
> as possibly just a fast front-end to something that wasn't as fast (ie
> think something like a front-end to make "monotone" work better).
>
> So the "directory cache" and "cache" naming comes from that historical
> background: it was really started as a front-end cache, and in fact the
> ".git" directory was called ".dircache" initially. You can see some of
> that in the very earliest git releases: by then I had already done the
> backing store, and the thing was already called "git", but the "dircache"
> naming still remains in places.
>
> For example, here's my "backup" target in the initial checkin:
>
> backup: clean
> cd .. ; tar czvf dircache.tar.gz dir-cache
>
> which shows that not only did I call the resulting tar file "dircache",
> the directory I was developing stuff in was called "dir-cache" as well ;)
>
> The index obviously ended up doing a lot more, and especially with the
> different stages it became much more than just a directory cache thing:
> it's integral to how git does the fast part of a merge. So we should call
> it "index" and edit out the old "cache" and "director cache" naming
> entirely.
I quoted this entirely, for a good reason: Linus, one day you really
should write a Wikibook about all the "small" projects you started. I
still remember the words "I'm doing a (free) operating system (just a
hobby, won't be big...". There's so much to be learnt about good
engineering. And people do want to add there anecdotes to it.
> > - the directory which corresponds to the top of the hierarchy
> > described in the index file; I've seen words like "working
> > tree", "working directory", "work tree" used.
> >
> > The tutorial initially says "working tree", but then "working
> > directory". Usually, a directory does not include its
> > subdirectories, though. git-apply-patch-script.txt, git-apply.txt,
> > git-hash-object.txt, git-read-tree.txt
> > use "work tree". git-checkout-cache.txt, git-commit-tree.txt,
> > git-diff-cache.txt, git-ls-tree.txt, git-update-cache.txt contain
> > "working directory". git-diff-files.txt talks about a "working tree".
>
> I think we should use "working tree" throughout, since "working directory"
> is unix-speak for "pwd" and has a totally different meaning.
I hoped so much.
> > - An index file can be in "merged" or "unmerged" state. The
> > former is when it does not have anything but stage 0 entries,
> > the latter otherwise.
>
> I think the "unmerged" case should be mentioned in the "cache entry"
> thing, since it's really a per-entry state, exactly like "dirty/clean".
>
> Then, explaining a "unmerged index" as being an index file with some
> entries being unmerged makes more sense.
>
> As it is, the above "explains" an index file as being unmerged by talking
> about "stage 0 entries", which in turn haven't been explained at all.
That's right. We probably should copy a bit from git-read-tree.txt, or at
least reference it in the glossary.
> > - A "tree object" can be recorded as a part of a "commit
> > object". The tree object is said to be "associated with" the
> > commit object.
> >
> > In diffcore.txt, "changeset" is used in place of "commit".
>
> We really should use "commit" throughout. ex-BK users sometimes lip into
> "changeset" (which in turn is probably because BK had these per-file
> commits too - deltas), but there's no point in the distinction in git. A
> commit is a commit.
That is, if you don't do "git-update-cache <single-file>" (which is not
possible with some porcelains).
Apart from that: I think that it is quite important to make the
distinction between a "commit" and a "commit object". Newbies (in that
case, people working with CVS are newbies to the concepts of git, too)
tend understand better what you say, if you make that distinction very
clearly, IMHO.
> > - The following objects are collectively called "tree-ish": a
> > tree object, a commit object, a tag object that resolves to
> > either a commit or a tree object, and can be given to
> > commands that expect to work on a tree object.
> >
> > We could call this category an "ent".
>
> LOL. You are a total geek.
I take that as a compliment :-)
> > - The files under $GIT_DIR/refs record object names, and are
> > called "refs". What is under refs/heads/ are called "heads",
> > refs/tags/ "tags". Typically, they are either object names
> > of commit objects or tag objects that resolve to commit
> > objects, but a tag can point at any object.
> >
> > The tutorial never calls them "refs", but instead "references".
>
> It might be worth saying explicitly that a reference is nothing but the
> same thing as a "object name" aka "sha1". And make it very clear that it
> can point to any object type, although commits tend to be the most common
> thng you want to reference. That then leads naturally into a very specific
> _subcase_ of refs, namely a "head":
Do not forget signed tags! Strictly said, these are references to
references which are signed.
> > - A "head" is always an object name of a commit, and marks the
> > latest commit in one line of development. A line of
> > development is often called a "branch". We sometimes use the
> > word "branch head" to stress the fact that we are talking
> > about a single commit that is the latest one in a "branch".
> >
> > In the tutorial, the latter is used in reverse: it talks about a
> > "HEAD development branch" and a "HEAD branch".
Actually, I don't think it a good idea to talk about a "HEAD branch" or
"development branch". I'd prefer "branch".
> > I find it a little bit troublesome that $GIT_DIR/branches does not
> > really refer to a branch, but rather to a (possibly remote) repository.
>
> Yes, I find the $GIT_DIR/branches naming to be confusing too.
I don't know if we can hide it from the users, or if we should bite the
apple and rename it to "remotes/", or even better "repositories/".
> Jeff has been dragging me into the "local branches are good" camp, and
> these days I'm obviously a big believer.
I think that Jeff really deserves the credit for this. Yours truly was
convinced that one repository should hold one branch only. But I was
convinced otherwise, too.
> > - The act of finding out the object names recorded in "refs" a
> > different repository records, optionally updating a local
> > "refs" with their values, and retrieving the objects
> > reachable from them is called "fetching". Fetching immediately
> > followed by merging is called "pulling".
> >
> > In that sense, git-http-pull would be more appropriately named
> > git-http-fetch, and analogous git-ssh-pull.
> >
> > Also, git-pull-script.txt says "Pull and merge", contradicting this
> > definition.
>
> To confuse things even more, cogito calls a fetch "pull" and a pull
> "update".
I really think this should be unified. Pasky?
> I personally think "fetch" is unambigious: it's just the act of fetching,
> with no "merge" activity at all. So we should use that.
Agree.
> What to call a "fetch+merge" is a bit ambiguous. I obviously prefer
> "pull", but cogito disagrees, and you're right, "git-http-pull" and
> "git-ssh-pull" both really do just fetches.
Let's rename them before 1.0.
> But I think "update" isn't right either: to me, update would be the
> non-merging kind (ie I think "update" implies "refresh" which in turn
> implies a "fetch"-like behaviour).
>
> So I'd vote for making the suggested definition official: "fetch" means
> fetching the data, and "pull" means "fetch + merge".
This should be discussed. Obviously, I come from CVS and understand
"update" to be what cogito says it is. But then, it is also true that
CVS's usage of "update" is misleading, because it really does a merge, not
forcing the user to do a commit before merge (because that is not possible
in CVS). So basically, I agree: "pull" is unambiguous as far as I am
concerned.
> > - a "pack" usually consists of two files: a file containing objects
> > in a compressed format, and an index to the first file. If the
> > pack is uncompressed at once (e.g. when git-clone is called), the
> > index is not necessary.
> >
> > git-pack-objects calls this a "packed archive" first, but then reverts
> > to "pack". git-show-index.txt and git-verify-pack.txt call the .pack file
> > "packed GIT archive", and the index "idx file". git-unpack-objects.txt
> > calls the .pack file "pack archive".
>
> We should just call them packs. An archive can be multiple packs and lots
> of non-packed objects too.
And they can have pack indices which do not relate at all to the central
GIT index.
> > "type": one of the identifiers "commit","tree","tag" and "blob" describing
> > the type of an object.
>
> Yes. Some old docs may call this type a "tag", since I was really thinking
> in not in the SCM meaning at all, but in the _computer_architecture_
> meaning, where people usually call objects with enforced types "tagged".
>
> Ie from a computer architecture standpoint you can have "tagged memory" or
> "tagged pointers", and LISP machines are often implemented with the
> pointers containing the type ("tag") of the thing they point to (for
> example, the low two bits might be the "tag" on the pointer). So I was
> talking about "tagged objects" when I just meant that the type of the
> object was embedded in the object itself, the way tagged memory
> architectures work.
>
> In retrospect, that naming _really_ confused some people, I know I had
> trouble explaining git concepts to David Wheeler because I used "tagged
> objects" _not_ to mean a SCM style "tag", but to mean "typed objects".
>
> If somebody sees an old reference to "object tags", those should all be
> fixed to say "object types".
Agree.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use $DESTDIR instead of $dest
From: Junio C Hamano @ 2005-08-05 23:17 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050804235638.GL24479@pasky.ji.cz>
Petr Baudis <pasky@suse.cz> writes:
> $DESTDIR is more usual during the build than $dest and is what is usually
> used in the makefiles, so let's use it too.
While I do not have much preference either way, I do not want to
make this kind of change without making corresponding changes to
the spec.in and debian/rules file in the same commit, or another
commit that immediately follow it. And I wanted to do a 0.99.4
tomorrow, so I hope you would not mind if I placed this on
hold...
^ permalink raw reply
* Re: Terminology
From: linux @ 2005-08-06 0:54 UTC (permalink / raw)
To: barkalow; +Cc: git
> So what's the converse of "fetch" (to rename git-ssh-push to)?
> Maybe "ship"?
The opposite of "fetch" is "throw" or "toss".
(Just avoid tossing cookies or off.)
^ permalink raw reply
* My Itchlist
From: Junio C Hamano @ 2005-08-06 1:52 UTC (permalink / raw)
To: git
Here is a short list of itches I would like to get scratched
before 1.0. I may be forgetting something big, though, so if
your favorite feature request is not included in the list please
speak up.
- Teach send-pack to use get_sha1() on the source side.
In addition to a pattern that matches one reference on the
source side, we should be able to use anything get_sha1() can
grok. Hopefully I'll be looking into this over the weekend.
- Teach fetch-pack reference renaming.
On the push side, send-pack now knows updating arbitrary
remote references from local references. We need something
similar for fetching. I personally do not feel we need it for
cloning but my cursory reading of clone-pack indicates the
command is meant to work reasonably even in an already
populated repository. If somebody have a good use case for
it and a clean patch, I may be tempted to accept it.
- Glossary documentation Johannes Schindelin is working on.
I think coming up with the concensus of terms would come
fairly quickly on the list. Updating docs to match the
concensus may take some time. Help is greatly appreciated.
- Makefile variables updates from Pasky.
While I do not have objections to rename dest to DESTDIR and
such Pasky proposes, I want to have a matching change to RPM
and deb generation. I can speak basic debian/rules, but I am
reluctant to touch RPM side of the things.
Whether we do the dest/DESTDIR rename or not, we need to tweak
binary packaging anyway, or stop installing the default
templates. I can be talked into either way.
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.
These are not 1.0 showstopper items but what I personally would
love to see.
- teach mailsplit/mailinfo basic MIME (attachments and quoted-printable)
Some people send patches in MIME quoted-printable. I could
drop them on the floor and ask the sender to resend, but I've
been being a nice guy, which currently involves manual
intervention.
- teach git-apply "reverse" and possibly "fuzz".
I think this might help Porcelain; currently they have to
interpret git extended diff headers themselves.
- commit template filler discussed with Pasky some time ago.
- "rev-list a...b" should mean "rev-list `merge-base a b`..b"
^ permalink raw reply
* Re: My Itchlist
From: Linus Torvalds @ 2005-08-06 2:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xzfde7t.fsf@assigned-by-dhcp.cox.net>
On Fri, 5 Aug 2005, Junio C Hamano wrote:
>
> - Teach fetch-pack reference renaming.
Well, the fetch side at least needs it less.
Right now the renaming means that you can only really fetch _one_ head at
a time, but that's at least a fairly common and important case, and you
can do the rest from there.
And doing only one means that git-fetch-pack can just return the result
SHA1 of the head it was asked to fetch. In fact, even that could just be
extended to returning multiple heads: just return each SHA1 in order. No
"renaming" necessary, since it's then up to the user what to do with the
results.
In fact, many users don't even want to write the result to a ref _at_all_:
they just use the raw name - no refs - to merge.
So arguably it is _wrong_ to make git-fetch-pack write refs, because that
just leads to the problem with temporary refs etc. "Local variables are
good".
> These are not 1.0 showstopper items but what I personally would
> love to see.
>
> - teach mailsplit/mailinfo basic MIME (attachments and quoted-printable)
>
> Some people send patches in MIME quoted-printable. I could
> drop them on the floor and ask the sender to resend, but I've
> been being a nice guy, which currently involves manual
> intervention.
This really is a nasty problem. People add their own commentary etc, and
the fact is, the maintainer _needs_ to edit it.
Otherwise you'll have people saying "Hi there, I really like this thing,
but I have this problem which this patch fixes" etc, which is all very
nice, but dammit, that's simply not changelog material.
Also, I definitely myself end up editing patches occasionally: fixing
things up. Again, this is simply a major pain if the patch comes in as an
attachment.
So there are tons of reasons to just try to teach people that attachments
are painful. Much better to teach people not to use them than having
people use them and the tools "working" with them.
> - teach git-apply "reverse" and possibly "fuzz".
>
> I think this might help Porcelain; currently they have to
> interpret git extended diff headers themselves.
Reverse would definitely be useful. "fuzz" is really pretty dangerous. I
think that once a a patch doesn't apply, you really want to have helper
tools like a graphical "wiggle" etc, and that really means that it's not
"git-apply", it's something totally different.
And quite frankly, if you have a tool that can handle unified diffs
already, then extending it for the git rename stuff should be pretty easy.
It's not like we haven't wanted renaming patches for at least a _decade_
already, it's just that nobody ever did them.
So I'm hoping that git can act as a impetus for people to just finally
have a standard way of saying "rename". EVERYBODY wants it. Anybody who
ever sees a rename as a patch will always go "damn, it would be nice to
have renames". And dammit, we have them, so let's try to push out the
concept.
And if that means that we should use rename patches and let non-git users
have some pain until they say "ok, ok, it's a good idea, I'll do it.
Uncle, uncle!", then maybe the world will be a better place. It's not like
they can't see how git-apply does it already ;)
Linus
^ permalink raw reply
* Re: gitk "hyperlinks" (was Re: Display of merges in gitk)
From: Kay Sievers @ 2005-08-06 3:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508050710460.3258@g5.osdl.org>
On Fri, Aug 05, 2005 at 07:37:41AM -0700, Linus Torvalds wrote:
>
> [ Also Kay Sievers, because the clickability thing sounds like a
> potentially good thing for webgit too.. ]
...
> For 2.6.13 we've been reverting some stuff lately, to make sure we get a
> stable release. That's fine, and when I revert something I try to mention
> the commit ID of the thing I revert in the message. Apparently others do
> too, as indicated by a patch I just got from Petr Vandovec. So we've got
> for example:
>
> Undo: d8c4b4195c7d664baf296818bf756775149232d3
>
> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
...
> and when I use gitk, it would be just too damn cool for words if I could
> easily follow the SHA1's mentioned in the commit message.
...
Damn cool? No problem. :)
http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=403fe5ae57c831968c3dbbaba291ae825a1c5aaa
Kay
^ permalink raw reply
* [PATCH] Making CFLAGS compilant with GNU Coding Standards
From: Pavel Roskin @ 2005-08-06 5:36 UTC (permalink / raw)
To: git
Hello!
Quoting GNU Coding Standards ("info standards"):
"If there are C compiler options that _must_ be used for proper
compilation of certain files, do not include them in `CFLAGS'. Users
expect to be able to specify `CFLAGS' freely themselves."
This patch renames COPTS to CFLAGS, because it's COPTS that was user
overridable. Also, -Wall is moved there because it's optional. What
was CFLAGS is now ALL_CFLAGS, which users should not override.
Defines are added to DEFINES. Since ALL_CFLAGS is recursively expanded,
it uses the final value of DEFINES.
Implicit rules are made explicit since the implicit rules use CFLAGS
rather than ALL_CFLAGS. I believe that serious projects should not rely
on implicit rules anyway. Percent rules are used because they are used
already and because they don't need the .SUFFIXES target.
Signed-off-by: Pavel Roskin <proski@gnu.org>
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -34,8 +34,8 @@
GIT_VERSION=0.99.3
-COPTS?=-g -O2
-CFLAGS+=$(COPTS) -Wall $(DEFINES)
+CFLAGS ?= -g -O2 -Wall
+ALL_CFLAGS = $(CFLAGS) $(DEFINES)
prefix=$(HOME)
bindir=$(prefix)/bin
@@ -125,7 +125,7 @@ ifndef NO_OPENSSL
LIB_OBJS += epoch.o
OPENSSL_LIBSSL=-lssl
else
- CFLAGS += '-DNO_OPENSSL'
+ DEFINES += '-DNO_OPENSSL'
MOZILLA_SHA1=1
OPENSSL_LIBSSL=
endif
@@ -146,8 +146,8 @@ endif
endif
endif
-CFLAGS += '-DSHA1_HEADER=$(SHA1_HEADER)'
-CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT="$(etcgitdir)/templates"'
+DEFINES += '-DSHA1_HEADER=$(SHA1_HEADER)'
+DEFINES += '-DDEFAULT_GIT_TEMPLATE_ENVIRONMENT="$(etcgitdir)/templates"'
@@ -156,9 +156,15 @@ CFLAGS += '-DDEFAULT_GIT_TEMPLATE_ENVIRO
all: $(PROG)
+%.o: %.c
+ $(CC) -c $(ALL_CFLAGS) $<
+
+%.o: %.S
+ $(CC) -c $(ALL_CFLAGS) $<
+
.PRECIOUS: %.o
git-%: %.o $(LIB_FILE)
- $(CC) $(CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
+ $(CC) $(ALL_CFLAGS) -o $@ $(filter %.o,$^) $(LIBS)
git-http-pull: pull.o
git-local-pull: pull.o
@@ -185,13 +191,13 @@ test: all
$(MAKE) -C t/ all
test-date: test-date.c date.o
- $(CC) $(CFLAGS) -o $@ test-date.c date.o
+ $(CC) $(ALL_CFLAGS) -o $@ test-date.c date.o
test-delta: test-delta.c diff-delta.o patch-delta.o
- $(CC) $(CFLAGS) -o $@ $^
+ $(CC) $(ALL_CFLAGS) -o $@ $^
check:
- for i in *.c; do sparse $(CFLAGS) $(SPARSE_FLAGS) $$i; done
+ for i in *.c; do sparse $(ALL_CFLAGS) $(SPARSE_FLAGS) $$i; done
--
Regards,
Pavel Roskin
^ permalink raw reply
* [PATCH] Fix ref_newer() in send-pack.
From: Junio C Hamano @ 2005-08-06 6:18 UTC (permalink / raw)
To: git
When more than two references need to be checked with
ref_newer() function, the second and later calls did not work
correctly. This was because the later calls found commits
retained by the "struct object" layer that still had smudges
made by earlier calls.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
send-pack.c | 27 ++++++++++++++++++++++-----
1 files changed, 22 insertions(+), 5 deletions(-)
51b0fca012310910783de76f2eacfd10b0f2f9fc
diff --git a/send-pack.c b/send-pack.c
--- a/send-pack.c
+++ b/send-pack.c
@@ -105,12 +105,23 @@ static int pack_objects(int fd, struct r
return 0;
}
+static void unmark_and_free(struct commit_list *list, unsigned int mark)
+{
+ while (list) {
+ struct commit_list *temp = list;
+ temp->item->object.flags &= ~mark;
+ list = temp->next;
+ free(temp);
+ }
+}
+
static int ref_newer(const unsigned char *new_sha1,
const unsigned char *old_sha1)
{
struct object *o;
struct commit *old, *new;
- struct commit_list *list;
+ struct commit_list *list, *used;
+ int found = 0;
/* Both new and old must be commit-ish and new is descendant of
* old. Otherwise we require --force.
@@ -127,14 +138,20 @@ static int ref_newer(const unsigned char
if (parse_commit(new) < 0)
return 0;
- list = NULL;
+
+ used = list = NULL;
commit_list_insert(new, &list);
while (list) {
new = pop_most_recent_commit(&list, 1);
- if (new == old)
- return 1;
+ commit_list_insert(new, &used);
+ if (new == old) {
+ found = 1;
+ break;
+ }
}
- return 0;
+ unmark_and_free(list, 1);
+ unmark_and_free(used, 1);
+ return found;
}
static struct ref *local_refs, **local_tail;
^ permalink raw reply
* Re: My Itchlist
From: Johannes Schindelin @ 2005-08-06 6:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.58.0508051924390.3258@g5.osdl.org>
Hi,
On Fri, 5 Aug 2005, Linus Torvalds wrote:
> On Fri, 5 Aug 2005, Junio C Hamano wrote:
> >
> > - Teach fetch-pack reference renaming.
>
> Well, the fetch side at least needs it less.
>
> Right now the renaming means that you can only really fetch _one_ head at
> a time, but that's at least a fairly common and important case, and you
> can do the rest from there.
>
> And doing only one means that git-fetch-pack can just return the result
> SHA1 of the head it was asked to fetch. In fact, even that could just be
> extended to returning multiple heads: just return each SHA1 in order. No
> "renaming" necessary, since it's then up to the user what to do with the
> results.
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.
Ciao,
Dscho
^ permalink raw reply
* Re: New script: cg-clean
From: Pavel Roskin @ 2005-08-06 7:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20050710154618.GF24249@pasky.ji.cz>
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 <proski@gnu.org> told me that...
> > Hello, Petr!
>
> Hello,
>
> > Please consider this script for Cogito.
> >
> > Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> 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 <proski@gnu.org>
#!/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 "${stdignores[@]}"; 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.XXXXXX)
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 "$file"
done
rm -f "$filelist"
--
Regards,
Pavel Roskin
^ permalink raw reply
* Re: gitk "hyperlinks" (was Re: Display of merges in gitk)
From: Paul Mackerras @ 2005-08-06 13:16 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kay Sievers, Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508050710460.3258@g5.osdl.org>
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 <n> 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.
^ permalink raw reply
* Re: gitk "hyperlinks" (was Re: Display of merges in gitk)
From: Linus Torvalds @ 2005-08-06 15:44 UTC (permalink / raw)
To: Kay Sievers; +Cc: Paul Mackerras, Git Mailing List
In-Reply-To: <20050806033654.GA27953@vrfy.org>
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
^ permalink raw reply
* Re: gitk "hyperlinks" (was Re: Display of merges in gitk)
From: Linus Torvalds @ 2005-08-06 16:20 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Kay Sievers, Git Mailing List
In-Reply-To: <17140.47152.672091.474748@cargo.ozlabs.ibm.com>
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
^ 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