* Re: [PATCH 3/3] update a few Porcelain-ish for ref lock safety.
From: Andy Whitcroft @ 2006-09-26 18:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu02uqzaj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> This updates the use of git-update-ref in git-branch, git-tag
> and git-commit to make them safer in a few corner cases as
> demonstration.
>
> - git-tag makes sure that the named tag does not exist, allows
> you to edit tag message and then creates the tag. If a tag
> with the same name was created by somebody else in the
> meantime, it used to happily overwrote it. Now it notices
> the situation.
>
> - git-branch -d and git-commit (for the initial commit) had the
> same issue but with smaller race window, which is plugged
> with this.
>
> Signed-off-by: Junio C Hamano <junkio@cox.net>
> ---
>
> * Obviously I would need to update this on top of Linus's
> packed-refs, but this 3-patch series applies on top of the
> current "master".
>
> git-branch.sh | 9 ++++++---
> git-commit.sh | 2 +-
> git-tag.sh | 9 ++++++---
> 3 files changed, 13 insertions(+), 7 deletions(-)
>
> diff --git a/git-branch.sh b/git-branch.sh
> index e0501ec..2b58d20 100755
> --- a/git-branch.sh
> +++ b/git-branch.sh
> @@ -42,8 +42,7 @@ If you are sure you want to delete it, r
> esac
> ;;
> esac
> - rm -f "$GIT_DIR/logs/refs/heads/$branch_name"
> - rm -f "$GIT_DIR/refs/heads/$branch_name"
> + git update-ref -d "refs/heads/$branch_name" "$branch"
> echo "Deleted branch $branch_name."
> done
> exit 0
> @@ -112,6 +111,7 @@ rev=$(git-rev-parse --verify "$head") ||
> git-check-ref-format "heads/$branchname" ||
> die "we do not like '$branchname' as a branch name."
>
> +prev=0000000000000000000000000000000000000000
> if [ -e "$GIT_DIR/refs/heads/$branchname" ]
> then
> if test '' = "$force"
> @@ -121,10 +121,13 @@ then
> then
> die "cannot force-update the current branch."
> fi
> + prev=`git rev-parse --verify "refs/heads/$branchname"`
> fi
> if test "$create_log" = 'yes'
> then
> mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
> touch "$GIT_DIR/logs/refs/heads/$branchname"
> fi
> -git update-ref -m "branch: Created from $head" "refs/heads/$branchname" $rev
> +git update-ref -m "branch: Created from $head" \
> + "refs/heads/$branchname" $rev $prev
> +
> diff --git a/git-commit.sh b/git-commit.sh
> index 5a4c659..87b13ef 100755
> --- a/git-commit.sh
> +++ b/git-commit.sh
> @@ -554,8 +554,8 @@ else
> exit 1
> fi
> PARENTS=""
> - current=
> rloga='commit (initial)'
> + current=0000000000000000000000000000000000000000
> fi
>
> if test -z "$no_edit"
> diff --git a/git-tag.sh b/git-tag.sh
> index a0afa25..2bde3c0 100755
> --- a/git-tag.sh
> +++ b/git-tag.sh
> @@ -63,8 +63,11 @@ done
>
> name="$1"
> [ "$name" ] || usage
> -if [ -e "$GIT_DIR/refs/tags/$name" -a -z "$force" ]; then
> - die "tag '$name' already exists"
> +prev=0000000000000000000000000000000000000000
It seems a little odd to need to use such a large 'none' thing. Will
linus' updates start returning this when there is no tag? If so then it
makes sense. Else perhaps it would be nice to have a short cut for it.
Such as 'none'.
-apw
^ permalink raw reply
* Re: git packing leaves unpacked files
From: Jakub Narebski @ 2006-09-26 18:10 UTC (permalink / raw)
To: git
In-Reply-To: <45196BC8.8060608@shadowen.org>
Andy Whitcroft wrote:
> I was just looking at my kernel repository and noticed that even after a
> git repack -a -d I have some loose files. A quick look at repack
> doesn't seem to explain why some are either not packed or are kept unpacked.
>
> Is this something I should be expecting?
Try git-fsck-objects. Perhaps those loose files are the ones which will
be pruned.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] git-svn: Fix fetch --no-ignore-externals with GIT_SVN_NO_LIB=1
From: Eric Wong @ 2006-09-26 18:14 UTC (permalink / raw)
To: Sergey Vlasov; +Cc: git
In-Reply-To: <1159263775639-git-send-email-vsu@altlinux.ru>
Sergey Vlasov <vsu@altlinux.ru> wrote:
> When using Subversion 1.3.1 without Perl bindings (GIT_SVN_NO_LIB=1),
> "git-svn fetch --no-ignore-externals" fails with errors like:
>
> Tree (.../.git/svn/git-svn/tree) is not clean:
> X directory_with_external
>
> In this case the 'X' lines in the "svn status" output are not a sign
> of unclean tree, and therefore should be ignored.
>
> Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: git packing leaves unpacked files
From: Linus Torvalds @ 2006-09-26 18:28 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Git Mailing List
In-Reply-To: <45196BC8.8060608@shadowen.org>
On Tue, 26 Sep 2006, Andy Whitcroft wrote:
>
> I was just looking at my kernel repository and noticed that even after a
> git repack -a -d I have some loose files. A quick look at repack
> doesn't seem to explain why some are either not packed or are kept unpacked.
>
> Is this something I should be expecting?
Depending on what you're doing, yes.
You can often get a hint of what is going on by just running
"git-fsck-objects" and seeing the "dangling" objects - objects that exist,
but are not reachable.
There are a few things that cause dangling objects quite normally:
- If you use "git update-index" to update the index half-way, and then do
more work, and use "git update-index" again (or commit), then the
half-way work will visible be in the form of dangling blobs. You can
just do a "git cat-file -p <blobname>" and see it, and maybe you'll
recognize that it was something you were about to commit, but never
did, because you did further development.
- if you ever rebase any branch in the project, or do "git reset" to set
it to some old point, or delete a branch, dangling commits are very
much to be expected.
- Even if _you_ didn't rebase anything, if the project you track rebases
itself, you'll get dangling objects because you had commits that became
unreachable when they were replaced by new history.
My kernel tree doesn't do that, but some other ones occasionally do,
and git itself (in the "pu" branch) obviously does all the time.
This is often the most common reason, especially if you follow
Junio's git tree.
The most common sign of this is that there's a few dangling commits,
and when you use gitk to examine them, you see old valid commits that
just aren't reachable any more.
- if you do any merges at all, and they've conflicted or they have had
more than one parent and the recursive merger has generated an
intermediate version of the tree, you'll have the merge process leave
the objects of those intermediate merges around as dangling left-overs
that aren't actually reachable from the end result of the merge.
The most common form of this is that you see a few pending "blob"s, and
when you do "git cat-file -p <sha1> | less -S" on the blob-file, you'll
generally find a conflict marker in it (ie the "<<<<" "====" ">>>>"
things that a three-way merge leaves behind). You might also have a
whole dangling tree due to this.
- if you use the rsync:// protocol, you'll often end up getting objects
that aren't reachable from the heads _you_ have, because you got the
whole object database from somebody else that had other heads (or, you
might get the dangling objects that they had due to any of the reasons
above).
The rsync:// protocol simply doesn't do any git-level reachability
analysis, so it just gets everything, regardless.
Hmm. Those are tha main reasons I can think of. There may be other cases,
but I think these are the main ones, and I think any other cases end up
being just variations on the same kind of theme.
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: "raw" links to blobs at HEAD
From: Luben Tuikov @ 2006-09-26 18:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xk7rup3.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> This does not feel right. Go to summary view, pick the tree
> link of a non-head commit from the shortlog list, and the raw
> links on the resulting page all say hb=HEAD.
I see your point.
> Doesn't this make clicking the entry itself (blob view) and
> clicking on the raw link (blob-plain view) inconsistent?
It this exactly this consistency which the patch used to de-couple
it and use the "raw" to point to HEAD.
> The former goes to the blob from that revision while the latter
> always goes to the HEAD.
Yes, I completely understand the conundrum.
Ideally, hb would equal HEAD from the _context_, but
1) hb and h != HEAD for any "raw" link,
2) one can set hb=HEAD in the context only when the "blob page"
can be loaded, which is impossible for binary blobs.
So the fix would be that, unless the user had selected a hb/h
explicitly, set "raw" to HEAD (i.e. by default), but leave the entry
with hb/h in SHA. This way, one can take a reference to HEAD or
SHA of the head depending on what is needed. And if they had
selected a hb/h explicitly then both the entry and the "raw"
would point to the SHA.
Such a patch can go on top of those two.
Luben
^ permalink raw reply
* [PATCH] gitweb: Remove redundant "tree" link
From: Luben Tuikov @ 2006-09-26 19:45 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 276 bytes --]
In "tree" view, remove redundant "tree" link in the tree
listing. It is identical to simply clicking on the tree
entry itself.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 16 ++++++----------
1 files changed, 6 insertions(+), 10 deletions(-)
[-- Attachment #2: 1207600725-p1.txt --]
[-- Type: text/plain, Size: 1210 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 959e3f9..8e9c827 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1631,18 +1631,14 @@ sub git_print_tree_entry {
print "</td>\n";
} elsif ($t->{'type'} eq "tree") {
- print "<td class=\"list\">" .
- $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
- file_name=>"$basedir$t->{'name'}", %base_key)},
- esc_html($t->{'name'})) .
- "</td>\n" .
- "<td class=\"link\">" .
- $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
+ print "<td class=\"list\">";
+ print $cgi->a({-href => href(action=>"tree", hash=>$t->{'hash'},
file_name=>"$basedir$t->{'name'}", %base_key)},
- "tree");
+ esc_html($t->{'name'}));
+ print "</td>\n";
+ print "<td class=\"link\">";
if (defined $hash_base) {
- print " | " .
- $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
+ print $cgi->a({-href => href(action=>"history", hash_base=>$hash_base,
file_name=>"$basedir$t->{'name'}")},
"history");
}
--
1.4.2.1.g893b0
^ permalink raw reply related
* [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Luben Tuikov @ 2006-09-26 19:47 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 350 bytes --]
In tree view, by default, hash_base is HEAD and hash is the
entry equivalent. Else the user had selected a hash_base or
hash, say by clicking on a revision or commit, in which case
those values are used.
Signed-off-by: Luben Tuikov <ltuikov@yahoo.com>
---
gitweb/gitweb.perl | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
[-- Attachment #2: 1908141687-p2.txt --]
[-- Type: text/plain, Size: 1075 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8e9c827..56638f2 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1625,7 +1625,7 @@ sub git_print_tree_entry {
"history");
}
print " | " .
- $cgi->a({-href => href(action=>"blob_plain", hash_base=>"HEAD",
+ $cgi->a({-href => href(action=>"blob_plain", hash_base=>$hash_base,
file_name=>"$basedir$t->{'name'}")},
"raw");
print "</td>\n";
@@ -2713,14 +2713,14 @@ sub git_tree {
my ($ctype, $suffix, $command) = gitweb_check_feature('snapshot');
my $have_snapshot = (defined $ctype && defined $suffix);
+ if (!defined $hash_base) {
+ $hash_base = "HEAD";
+ }
if (!defined $hash) {
- $hash = git_get_head_hash($project);
if (defined $file_name) {
- my $base = $hash_base || $hash;
- $hash = git_get_hash_by_path($base, $file_name, "tree");
- }
- if (!defined $hash_base) {
- $hash_base = $hash;
+ $hash = git_get_hash_by_path($hash_base, $file_name, "tree");
+ } else {
+ $hash = $hash_base;
}
}
$/ = "\0";
--
1.4.2.1.g893b0
^ permalink raw reply related
* Re: your mail
From: Linus Torvalds @ 2006-09-26 19:56 UTC (permalink / raw)
To: Zhao, Jing; +Cc: Andy Whitcroft, Git Mailing List
In-Reply-To: <C8DBC54F2A9BAD4FA7F445CC7ADD963B0232474F@sslmexchange1.paymentech.us>
On Tue, 26 Sep 2006, Zhao, Jing wrote:
>
> I subscribed git emailing list (git@vger.kernel.org). I don't know for
> what reason, my post emails all have been rejected. Could you post this
> for me and shed some light on this issue? thanks,
The vger.kernel.org lists have various spam detectors, and I suspect a
combination of your email address and the signature you use just triggers
that system to believe that you are trying to sell us house payment plans
or something..
So I would suggest removing your signature in particular, that points to a
web-site that is associated with an industry that has over-used the email
medium for selling their services...
> I tried to port git to VOS system (Stratus). When i compiled it, i
> found it did not have 'regex.h' and its library. Do you know any
> workaround for this problem? Or which package contains these code i can
> port at first?
I do not know if stratus has regex libraries anywhere, but googling for
"VOS Stratus regex" seems to be saying that this isn't the first time that
platform has had problems compiling various programs.
I suspect you'd just have to compile one of the regex libraries that are
out there as source. I think Henry Spencer's libraries are likely the
canonical ones, but there's a "GNU regex" too, and that's probably the
basis for the ones that are used in glibc. Dunno.
Google for either of those, you'll find them. It's not new code, but I
doubt it needs to be ;)
Linus
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Luben Tuikov @ 2006-09-26 20:14 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <efapsl$e65$1@sea.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> I'd rather not. The fact that the file name and tree name is link,
> and the fact that commit title and tag title is link is a _convenience_.
> Not always it is visible (without mouseover) that it is link.
> And it is _not_ visible in the case of files!
>
> And for example for commits and heads there are two possible
> views, commit and commitdiff for commit, shortlog and log for head,
> of which we arbitrary chose one for the subject link. So in that
> case the additional self link is needed. I'd rather have both.
> And for consistency I'd rather always have visible form default
> self link/
>
> I'd rather have additional link, than cause confusion to the users.
> Perhaps we could separate the self link ("blob" for files, "tree"
> for directories) into separate column?
>
> Besides, you have to mouse over the name of file, or name of
> directory to see to what view it would lead on.
Jakub,
I understand your argument completely. Underlining/coloring/etc
entities which are "links" themselves was very cool circa 1993 when
I took an HTML course (NSA Mosaic or rather...), transitioning from
"gopher" to the WWW.
Over the years I've seen a transition where web content is more and
more context sensitive, i.e. everything you can see is in some way
"clickable". Be it letters, words, sentences, graphical objects of
some sort, etc. If you could imagine: any web content being a "wiki
on steroids".
Generally, this WEB Development argument goes as follows:
"There is no reason for anything to not be clickable."
Thus, I like the fact that gitweb is on the forefront of WEB development.
We should keep it like that.
Luben
>
> Nak.
> --
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] gitweb: "raw" links to blobs at HEAD
From: Luben Tuikov @ 2006-09-26 20:20 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <efaq3h$e65$2@sea.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> Luben Tuikov wrote:
>
> > Currently there is no HTML interface which references (or
> > can be externally referenced) to yield a _binary_ blob at
> > HEAD. There is one for non-binary blobs, but none for
> > binary ones.
>
> You can in the same number of steps. First go to _tree_
> at head, then click on "raw" link.
Jakub,
For binary only files, there is no HTML interface to refer
to, such that, hb=HEAD for _binary_ only files. Unless of course
one types that on the URL line manually.
That is, I'd like to externally reference binary only blobs
at "HEAD", s.t. no matter _when_ the reference is used, it would
refer to the latest "version" of that file.
E.g. a PDF spec file.
My recent patches on the subject enable this capability.
Luben
> It's true that decision that binary files are automatically
> redirected to "plain" ("raw") format, so they don't have "html"
> output caused that there is no link for binary blob at head.
> But I don't think that changing "raw" link to link to HEAD
> version, while all other links are to current version is
> a good idea...
> --
> Jakub Narebski
> Warsaw, Poland
> ShadeHawk on #git
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Johannes Schindelin @ 2006-09-26 20:25 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <45196628.9010107@gmail.com>
Hi,
On Tue, 26 Sep 2006, A Large Angry SCM wrote:
> 20060926.1715
You forgot the time zone ;-)
> Notes on Using Git with Subprojects
> ===================================
> Copyright (C) 2006 by Raymond S Brand
>
>
> Git does not have native support for subprojects and this is a good
> thing because managing subprojects is better handled by the project
> build machinery. Managing subprojects with the project build machinery
> is more flexible than the native support from an SCM and allows the use
> of different SCMs by different subprojects. However, there is a lot of
> interest in using Git for the SCM of a project with subprojects.
>
> Git, unfortunately, does not make it easy.
After skimming your text, I imagine that it should be possible (read:
easy) to write a really simple script which does what you describe,
storing the relevant information about root or sub projects in the config.
However, you left out one of the most important aspects of subprojects:
the ability to manage the state of the root project: you can add, update
and remove subprojects.
A while ago, Junio started playing with a new object type for subprojects
so that you could have tree objects containing subprojects in addition
to tree objects and blobs.
Of course, the difficult thing about this is to teach all tools to behave
sensibly with the new object type.
Now, your approach of having multiple clones (sharing the object pool) is
more simple than Junio's approach: no need to introduce a new object type,
or adapt existing tools.
Taking this a step further, how about managing the root project in this
manner:
A root project is a branch containing just one special file,
"root-project". This file consists of lines like these:
-- snip --
f80a17bf3da1e24ac904f9078f68c3bf935ff250 next
03adf42c988195b50e1a1935ba5fcbc39b2b029b todo
-- snap --
The meaning: subdirectory "next" contains subproject "next" which is also
tracked in the branch "next" of the root project. Likewise for "todo". The
root project could even contain some administrative files like a Makefile,
a license, README, etc.
You could even handle the update of root-project with each commit in a
subproject by a hook in that subproject's .git/hooks/post-commit, so that
you'd only need a script "git-checkout-root-project.sh" to initialize them
all, and probably a script "git-update-root-project.sh".
Thoughts?
Ciao,
Dscho
P.S.: Is it just me, or do other people also find it confusing that
--shared means different things for git-init-db and git-clone? (I know I
am the sinner...)
^ permalink raw reply
* Re: [PATCH] gitweb: Remove redundant "tree" link
From: Jakub Narebski @ 2006-09-26 20:27 UTC (permalink / raw)
To: git
In-Reply-To: <20060926194538.46031.qmail@web31809.mail.mud.yahoo.com>
Luben Tuikov wrote:
> In "tree" view, remove redundant "tree" link in the tree
> listing. It is identical to simply clicking on the tree
> entry itself.
I'd rather have this redundancy.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Luben Tuikov @ 2006-09-26 20:33 UTC (permalink / raw)
To: Petr Baudis, Jakub Narebski; +Cc: git
In-Reply-To: <20060926160729.GH20017@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> And directories should have trailing slash in their name in the tree
> listing, for people with non-UNIX background who don't understand the
> ls -l like output.
In the non-UNIX environment, there is "folders", not "directories".
Also, in the non-UNIX environment, the path separator is '\'.
The point is that it is not unreasonable to draw the line somewhere.
A 'd' at the front of directories is easy enough to understand,
plus the fact that directory entries are underlined and blue, wlg.
Luben
>
> > And for example for commits and heads there are two possible
> > views, commit and commitdiff for commit, shortlog and log for head,
> > of which we arbitrary chose one for the subject link. So in that
> > case the additional self link is needed. I'd rather have both.
>
> For commits and heads, I agree. But that's not what this patch does.
>
> > And for consistency I'd rather always have visible form default
> > self link/
>
> A parse error kicked me off here, sorry.
>
>
> (I'm personally kind of ambivalent to the change.)
>
> --
> Petr "Pasky" Baudis
> Stuff: http://pasky.or.cz/
> #!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
> $/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
> lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Jakub Narebski @ 2006-09-26 20:31 UTC (permalink / raw)
To: git
In-Reply-To: <20060926201433.46979.qmail@web31810.mail.mud.yahoo.com>
Luben Tuikov wrote:
> Jakub,
>
> I understand your argument completely. Underlining/coloring/etc
> entities which are "links" themselves was very cool circa 1993 when
> I took an HTML course (NSA Mosaic or rather...), transitioning from
> "gopher" to the WWW.
>
> Over the years I've seen a transition where web content is more and
> more context sensitive, i.e. everything you can see is in some way
> "clickable". Be it letters, words, sentences, graphical objects of
> some sort, etc. If you could imagine: any web content being a "wiki
> on steroids".
>
> Generally, this WEB Development argument goes as follows:
> "There is no reason for anything to not be clickable."
>
> Thus, I like the fact that gitweb is on the forefront of WEB development.
> We should keep it like that.
This is example of where forefront has it wrong. I'm all for "list" entry
to be link to default view, but I'm all against removing clearly marked
link to "plain"/"tree" view.
And "invisible links" _especially_ if the link is not convenience only
(i.e. it is not provided clearly as link somewhere else) is so called
"mystery meat navigation" and is one of the most common mistakes in
web development.
And is not as if "plain |" takes much space...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Jakub Narebski @ 2006-09-26 20:34 UTC (permalink / raw)
To: git
In-Reply-To: <20060926194706.32255.qmail@web31804.mail.mud.yahoo.com>
Luben Tuikov wrote:
> In tree view, by default, hash_base is HEAD and hash is the
> entry equivalent. Else the user had selected a hash_base or
> hash, say by clicking on a revision or commit, in which case
> those values are used.
I think that this need some thinking over. For blob we have two
"base" objects: tree which have specified blob, and commit which
have tree which have specified blob. We might want to specify
that all hash*base are to the commit-ish.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Luben Tuikov @ 2006-09-26 21:17 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <efc2t8$eti$3@sea.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> I think that this need some thinking over. For blob we have two
> "base" objects: tree which have specified blob, and commit which
> have tree which have specified blob. We might want to specify
> that all hash*base are to the commit-ish.
Agreed, we should always refer to the commit-ish, for obvious
reasons.
This patch doesn't make this decision though. It simply
sets hash_base to HEAD if not defined.
Now, since "git-ls-tree" works on both commit-ish and
tree-ish, we are ok.
Luben
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Daniel Barkalow @ 2006-09-26 21:23 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <45196628.9010107@gmail.com>
On Tue, 26 Sep 2006, A Large Angry SCM wrote:
> Git, unfortunately, does not make it easy. What is wanted is to put all
> of the subprojects in one repository and be able to checkout the various
> parts from a local copy of the repository. The problem is, with Git, a
> repository can have at most one working directory associated with it at
> a time. This is because Git stores a lot of information about the
> contents of the working directory in the repository. In fact, the usual
> situation is that the repository, itself, is in the working directory.
There are a bunch of use cases which people see as subprojects, with
slightly different desires. For example, I personally don't think there's
any point to subprojects if a commit of the parent project doesn't specify
the embedded commits of each subproject (so, for example, you can use
bisect on the parent project to figure out which act of updating a
subproject broke the resulting system). AFAICT, your design doesn't handle
that, but uses the most recently fetched versions of all subprojects, with
the revision control of the parent only handling revisions in the
arrangement and membership of subprojects in the parent.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Shawn Pearce @ 2006-09-26 21:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: A Large Angry SCM, git
In-Reply-To: <Pine.LNX.4.64.0609261629160.9789@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> wrote:
> On Tue, 26 Sep 2006, A Large Angry SCM wrote:
>
> > Git, unfortunately, does not make it easy. What is wanted is to put all
> > of the subprojects in one repository and be able to checkout the various
> > parts from a local copy of the repository. The problem is, with Git, a
> > repository can have at most one working directory associated with it at
> > a time. This is because Git stores a lot of information about the
> > contents of the working directory in the repository. In fact, the usual
> > situation is that the repository, itself, is in the working directory.
>
> There are a bunch of use cases which people see as subprojects, with
> slightly different desires. For example, I personally don't think there's
> any point to subprojects if a commit of the parent project doesn't specify
> the embedded commits of each subproject (so, for example, you can use
> bisect on the parent project to figure out which act of updating a
> subproject broke the resulting system). AFAICT, your design doesn't handle
> that, but uses the most recently fetched versions of all subprojects, with
> the revision control of the parent only handling revisions in the
> arrangement and membership of subprojects in the parent.
I agree entirely.
I have about 30 "subprojects" tacked into one large Git repository
for this exact reason. In at least 5 of these cases they shouldn't
be sharing a Git repository as by all rights they are different
projects.
What I'm doing is sort of like tacking both the Linux kernel and
glibc into the same Git repository because you might need to change
and bisect over updates to the system call layer. Insane, yes.
Probably shouldn't be done; but right now that interface layer
between several subprojects is still in flux and it makes it rather
easy to keep everything in sync.
Its annoying to perform commits to the "root project" every time the
subproject changes. And it brings some complexity when you want to
talk about merging that root project. But if its automated as part
of "git commit" and "git merge" (either directly in those tools or
by hooks users can install) then its probbaly a non issue.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Luben Tuikov @ 2006-09-26 21:32 UTC (permalink / raw)
To: Jakub Narebski, git
In-Reply-To: <efc2no$eti$2@sea.gmane.org>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> This is example of where forefront has it wrong. I'm all for "list" entry
> to be link to default view, but I'm all against removing clearly marked
> link to "plain"/"tree" view.
>
> And "invisible links" _especially_ if the link is not convenience only
> (i.e. it is not provided clearly as link somewhere else) is so called
> "mystery meat navigation" and is one of the most common mistakes in
> web development.
>
> And is not as if "plain |" takes much space...
I think you would agree that gitweb is quite different than what is
commonly defined as "mystery meat navigation".
Gitweb is very well thought out interface, and self-contained.
There isn't much pondering about what and where to click, have newbies
too.
Think about the removal of the redundant "blob" and "tree" as database
schema normalization if you will. The redundancy is so well defined that
even applying a simple algorithm to gitweb.perl will discover it.
Either that or you can think of it as "shortening" the line.
Wlg, suppose that I have a file called "blob" and a directory
called "tree":
mode blob blob | blame | history | raw
mode tree tree | history
Is equivalent to
mode blob blame | history | raw
mode tree history
For any name "blob" and any name "tree".
Plus the code (gitweb.perl) has less redundancy and overhead.
Luben
^ permalink raw reply
* Re: [PATCH] Clarified documentation of --exclude-per-directory.
From: Shawn Pearce @ 2006-09-26 21:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3baftdp0.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Tommi Virtanen noted on #git today that
> >
> > git ls-files --exclude-per-directory
> >
> > doesn't appear to work as advertised by the documentation unless
> > --others is also used. According to the current source code this
> > is the case as the --exclude-per-directory file isn't read unless
> > we are iterating over the working directory, which only happens
> > with --others.
>
> I am puzzled by this problem description.
>
> If we _were_ to read --exclude-per-directory file when we are
> not doing --others, what better behaviour would we get out of
> the command?
From what I was able to gather on #git Tommi was trying to do:
mkdir foo ; cd foo ; git init-db
echo foo >foo
echo foo >ignore
git add foo ignore
git commit -a -m create
rm *
git ls-files --exclude-per-directory=ignore \
| git checkout-index
and not see "foo" come back into the working directory. I don't
know what circumstances lead him to want to create an exclude file
pattern on a per-directory basis for use with checkout-index but
that seems to be what he was trying to do.
I don't really see a problem with applying --exclude-per-directory
all of time (like we apply --exclude=.git/info/exclude all of
time), its just not what the code does today. I just personally
don't need that and don't have the time to fix ls-files to do so.
So I took the shorter approach and updated the documentation. :)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Introduce git-mirror, a tool for exactly mirroring another repository.
From: Shawn Pearce @ 2006-09-26 21:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Petr Baudis
In-Reply-To: <7vpsdjtew4.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Shawn Pearce <spearce@spearce.org> writes:
>
> > Sometimes its handy to be able to efficiently backup or mirror one
> > Git repository to another Git repository by employing the native
> > Git object transfer protocol. But when mirroring or backing up a
> > repository you really want:
> >
> > 1) Every object in the source to go to the mirror.
> > 2) Every ref in the source to go to the mirror.
> > 3) Any ref removed from the source to be removed from the mirror.
> > 4) Automatically repack and prune the mirror when necessary.
> >
> > and since git-fetch doesn't do 2, 3, and 4 here's a tool that does.
>
> Just a note. I usually use git-push the other way for backups,
> and I believe that is how Linus does it, too.
I do the same thing right now but it doesn't get all topic branches
unless I name them on the push line or put them into my remotes
file, and when I delete a topic branch it doesn't remove it from
the remote during the next push... :-)
> > diff --git a/git-mirror.perl b/git-mirror.perl
> > new file mode 100755
> > index 0000000..bff2003
> > --- /dev/null
> > +++ b/git-mirror.perl
> > @@ -0,0 +1,111 @@
> > +#!/usr/bin/env perl
>
> Please don't. "#!/usr/bin/env perl" is a disease.
I entirely blame git-svn.perl. I copied that line from there.
> > +# This file is licensed under the GPL v2, or a later version
> > +# at the discretion of Linus.
>
> Heh ;-).
Yea, I thought you'd get a kick out of that, especially after the
recent discussion. :)
> > +use warnings;
> > +use strict;
> > +use Git;
> > +
> > +sub ls_refs ($$);
>
> I wonder why people like line-noise prototypes. Do you ever
> call ls_refs with parameters that benefit from this? Otherwise
> I prefer not to see them.
Perl is line noise. I've gotten into the habit of prototyping
most of my functions but clearly this one could be omitted without
any problems.
> > +my $remote = shift || 'origin';
> > +my $repo = Git->repository();
> > +
> > +# Verify its OK to execute in this repository.
> > +#
> > +my $mirror_ok = $repo->config('mirror.allowed') || 0;
> > +unless ($mirror_ok =~ /^(?:true|t|yes|y|1)$/i) {
>
> This _is_ ugly. Doesn't $repo->config() know how to drive
> underlying "git-repo-config" with specific type argument?
Agreed. No it doesn't according to Git.pm. I probably should have
fixed Git.pm first.
> > +# Execute the fetch for any refs which differ from our own.
> > +# We don't worry about trying to optimize for rewinds or
> > +# exact branch copies as they are rather uncommon.
>
> If we need to support only git-native protocols, all of this
> optimization is not needed at all. It's kind of sad that we
> need to support commit walkers...
Hmm. I tested this by mirroring a local Git clone ("../git") and
found it was MUCH faster even when only one head was different.
The large number of tags really made it take a lot longer. And that
was local/local though the native protocols. I figured it was
worth the few lines of Perl code.
> > +if (@to_fetch) {
> > + git_cmd_try {
> > + $repo->command_noisy('fetch',
> > + '--force',
> > + '--update-head-ok',
> > + $remote, sort @to_fetch);
> > + } '%s failed w/ code %d';
>
> Why sort (no objection, just curious)?
I'm a freak. I typically don't like things that have a "randomness"
to them. Since I'm pulling from keys %foo the order I'm getting refs
back in is "unknown" (up to Perl's hash function). Sorting them
before using them cleans up that randomness. Although its not
really random here as the hash function is deterministic.
Maybe its because I work with SQL databases all of the time and
you pretty much can't rely on anything coming back in any sort of
order unless you explicitly force it. So I tend to do the same
with a lot of other systems.
> > +# Repack if we have a large number of loose objects.
> > +#
> > +if (@to_fetch) {
> > + my $count_output = $repo->command('count-objects');
> > + my ($cur_loose) = ($count_output =~ /^(\d+) objects/);
> > + my $max_loose = $repo->config('mirror.maxlooseobjects') || 100;
> > + if ($cur_loose >= $max_loose) {
> > + git_cmd_try {
> > + $repo->command_noisy('repack', '-a', '-d');
> > + $repo->command_noisy('prune');
> > + } '%s failed w/ code %d';
> > + }
> > +}
>
> If we truly have a large number of objects (in pack and loose),
> you do not want to do "repack -a -d", do you?
Yes. Because then I want to get your new --unpacked= option
into git-repack.sh. The -a should then repack all active packs,
omitting the archive packs. Which are the larger packs that are
costly to repack.
In my opinion mirroring should be a no-brain require activity.
This script is designed for exactly tracking another repository
without any additional intervention from the user. Carrying a
huge number of loose objects is not ideal, except for maybe the
HTTP commit walker.
--
Shawn.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-26 22:01 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609262203510.25371@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> Hi,
>
> On Tue, 26 Sep 2006, A Large Angry SCM wrote:
>
>> 20060926.1715
>
> You forgot the time zone ;-)
UTC of course. ;-)
[...]
>
> After skimming your text, I imagine that it should be possible (read:
> easy) to write a really simple script which does what you describe,
> storing the relevant information about root or sub projects in the config.
>
> However, you left out one of the most important aspects of subprojects:
> the ability to manage the state of the root project: you can add, update
> and remove subprojects.
Since each project can have subprojects, the root project is special
_only_ in that the initial checkout is _not_ handled by the build
machinery (make in my example). This means that adding and removing
subprojects should be no different for the root project. A subproject
should be able to stand on its own (with its subprojects); otherwise,
it's not a project but instead a directory tree versioned separately.
> A while ago, Junio started playing with a new object type for subprojects
> so that you could have tree objects containing subprojects in addition
> to tree objects and blobs.
Which I though was awful. Subprojects are really much better managed by
the build machinery; it's more flexible and doesn't require all the
separate projects to use the same VCS.
> Of course, the difficult thing about this is to teach all tools to behave
> sensibly with the new object type.
And teach all the tools to gracefully handle subprojects using a
different VCS ...
> Now, your approach of having multiple clones (sharing the object pool) is
> more simple than Junio's approach: no need to introduce a new object type,
> or adapt existing tools.
>
> Taking this a step further, how about managing the root project in this
> manner:
>
> A root project is a branch containing just one special file,
> "root-project". This file consists of lines like these:
>
> -- snip --
> f80a17bf3da1e24ac904f9078f68c3bf935ff250 next
> 03adf42c988195b50e1a1935ba5fcbc39b2b029b todo
> -- snap --
>
> The meaning: subdirectory "next" contains subproject "next" which is also
> tracked in the branch "next" of the root project. Likewise for "todo". The
> root project could even contain some administrative files like a Makefile,
> a license, README, etc.
How the state (subproject list, branch names, etc.) is recorded in a
parent project is only important to the parent project. The parent
project must also know how to interact with with each of its subprojects.
For instance, if you were building some kind of internet appliance, it
could have a very large number of subprojects (kernel, various servers
and daemons, etc) with no common build tool or target set used by all of
them. What each parent project does in this situation is to "interface"
to the build machinery of each subproject so that when you command "make
appliance image" at the top level project, all the subprojects _and_ the
top level project do what is need to create the appliance image. The
appliance can depend on projects using many VCS'; Git for the kernel,
SVN for the web server, CVS for the SMTP daemon, Monotone for some other
part, etc.
> You could even handle the update of root-project with each commit in a
> subproject by a hook in that subproject's .git/hooks/post-commit, so that
> you'd only need a script "git-checkout-root-project.sh" to initialize them
> all, and probably a script "git-update-root-project.sh".
For _full_ subproject support, handling a tree of projects is required.
So treating the root project differently that any other parent project
(except of the initial checkout of the root project), means that you
can't work a subproject independent of its parent projects.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-26 22:07 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609261629160.9789@iabervon.org>
Daniel Barkalow wrote:
> There are a bunch of use cases which people see as subprojects, with
> slightly different desires. For example, I personally don't think there's
> any point to subprojects if a commit of the parent project doesn't specify
> the embedded commits of each subproject (so, for example, you can use
> bisect on the parent project to figure out which act of updating a
> subproject broke the resulting system). AFAICT, your design doesn't handle
> that, but uses the most recently fetched versions of all subprojects, with
> the revision control of the parent only handling revisions in the
> arrangement and membership of subprojects in the parent.
That isn't that much different than what I outlined. Instead of
recording the branch name and directory in the parent project, you could
record the commit SHA1 ID for each subproject and directory. The
machinery changes but the idea is the same.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Johannes Schindelin @ 2006-09-26 22:13 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git
In-Reply-To: <4519A321.4010507@gmail.com>
Hi,
On Tue, 26 Sep 2006, A Large Angry SCM wrote:
> How the state (subproject list, branch names, etc.) is recorded in a
> parent project is only important to the parent project. The parent
> project must also know how to interact with with each of its
> subprojects.
Granted, if you mix VCSes, this is most pragmatic.
But it is also wrong: The whole point in bundling the subprojects together
is (IMHO) to get the benefits of a VCS for the root project, i.e. for the
combined states of the subprojects. After all, you want to say "I know
that this collection of projects at these states compiled and worked
fine."
And if you let a build system handle the stitching of the subprojects, you
completely lose these benefits.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: eliminate redundant "blob"
From: Jakub Narebski @ 2006-09-26 22:24 UTC (permalink / raw)
To: git
In-Reply-To: <20060926213236.79160.qmail@web31815.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Jakub Narebski <jnareb@gmail.com> wrote:
>> This is example of where forefront has it wrong. I'm all for "list" entry
>> to be link to default view, but I'm all against removing clearly marked
>> link to "plain"/"tree" view.
>>
>> And "invisible links" _especially_ if the link is not convenience only
>> (i.e. it is not provided clearly as link somewhere else) is so called
>> "mystery meat navigation" and is one of the most common mistakes in
>> web development.
>>
>> And is not as if "blob |" takes much space...
>
> I think you would agree that gitweb is quite different than what is
> commonly defined as "mystery meat navigation".
If you need to mouseover to discover that a part of webpage is link, it is
mystery meat navigation. Not in it's worst kind (it is quite obvious on
mouseover that that part is link), but still.
> Gitweb is very well thought out interface, and self-contained.
> There isn't much pondering about what and where to click, have newbies
> too.
But some links are hidden. But there is always (or should be always)
visible, i.e. in default link colors (blue for unvisited), and default
decoration (underline not only on mouseover - that's mystery meat
navigation).
> Think about the removal of the redundant "blob" and "tree" as database
> schema normalization if you will. The redundancy is so well defined that
> even applying a simple algorithm to gitweb.perl will discover it.
Redundancy is not always bad. Especially in interface.
> Either that or you can think of it as "shortening" the line.
> Wlg, suppose that I have a file called "blobname" and a directory
> called "treename":
> mode blobname blob | blame | history | raw
> mode treename tree | history
> Is equivalent to
> mode blobname blame | history | raw
> mode treename history
> For any name "blob" and any name "tree".
But then we _must_ (to not have mystery meat navigation) mark "blobname"
and "treename" _clearly_ as links, while using different visual (e.g.
different colors) to clearly distinguish between "blob" entry and "tree"
entry. And no, mode and remaining links (well, "raw") is not enough.
Which is somewhat contradictory. And makes interface somewhat inconsistent
(although removing both "blob" link for blobs and "tree" link for trees is
a step towards consistency).
> Plus the code (gitweb.perl) has less redundancy and overhead.
Redundancy in _interface_ is not always bad. We have a lot of redundancy
(mostly via hidden _convenience_ links) in gitweb interface.
Overhead? What overhead? Creating the page? It's negligible. Size of the
page? It is small enough for current net bandwidths; creation time is
bottleneck (not for "tree" view though), not the bandwidth.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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