* Re: RFC: Subprojects
From: A Large Angry SCM @ 2006-01-16 22:25 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Martin Langhoff, Junio C Hamano, git, Johannes Schindelin,
Simon Richter
In-Reply-To: <Pine.LNX.4.64.0601161414080.25300@iabervon.org>
Daniel Barkalow wrote:
> On Mon, 16 Jan 2006, A Large Angry SCM wrote:
>
>>Daniel Barkalow wrote:
>>[...]
>>>So the problem with handling subprojects with the build system is that it is
>>>too tempting to use the revision control system directly on the subproject,
>>>at which point the thing you're developing and testing isn't at all what
>>>other people will get if they check out your commit. You want "git status"
>>>to report it as an uncommitted change if you have a different revision of
>>>the subproject than your previous commit had, and it can't tell if this
>>>information is buried in the build system.
>>Using "git-status" is the wrong tool to use there. What you should be using is
>>"make project_status". Claiming "that it is too tempting to use the revision
>>control system on the subproject" is wrong; you should use the SCM (of the
>>subproject) to manage the subproject. You use the build system to manage the
>>_entire_ project.
>
> I'm talking about using "git status" on the main project, in case you're
> misunderstanding me. If you can manage the entire project with the build
> system, then you don't need git or any version control at all, aside from
> your build system. But you'd also lose the ability to use webgit, bisect,
> gitk, git log, and so forth on the project as a whole.
When you say "main project", do you mean the top level project and all
of its subprojects? Or just the top level project without any of its
subprojects?
A build system and a SCM working together can be a powerful very tool,
even if one or both of the components is not. Since managing a project
with a build system and no SCM means that you don't have any history and
since you seem to want access to the project's history, I'll ignore you
statement. (Backups and directory snapshots are primitive SCMs.)
Consider the following:
1) For a project to be a sub-project, it must also be a project.
2) So the standard SCM tools will work on the project.
3) The super-project is also a project and the standard SCM tools will
work on it.
4) Projects managed by an SCM are only considered consistent and usable
at specific points in that project's history; it may be every recorded
point in it's history or it may be just a few specific recorded points.
5) A super-project only cares about specific states of its sub-projects,
corresponding to points in the sub-project's history.
6) For each sub-project, the super-project needs to record the
sub-project's state identifier for each recorded point in the
super-project's history.
7) The super-project can record each sub-project's state identifier
somewhere in the build system.
8) If the super-project's SCM is Git then webgit, bisect, gitk, git log,
and so forth all work and will identify when and where the recorded
state identifier of each sub-project is changed.
9) The information is available to the build system to permit using
git-bisect in the super-project and notice that the breakage occurred
when the recorded state identifier of a sub-project changed. If the
sub-project used Git, the build system can automatically start
git-bisect'ing in the sub-project.
10) The information is available to the build system to permit doing
similar things for git-log and so forth.
11) Webgit and gitk are a little more work but by creating a git
repository that contains all of the history and refs of each project in
the entire project, you can navigate and view the history of any project
in the entire project.
12) If the SCM of some of the sub-projects is not Git, the build system
can still do git-bisect, git-log, etc. equivalents for the entire
project (subject to the limitations of the SCMs involved).
>>>The tricky question is whether we should permit the "subproject" objects to
>>>specify a revision that isn't a hash, for use in identifying revisions of
>>>subprojects in other systems.
>>Why would you want to limit how required versions of subprojects are
>>specified? Your project policies and procedures may require that subprojects
>>be specified by a subproject SCM specific immutable revision but the policies
>>and procedures of other projects may not be so restrictive and could accept a
>>tag identifying the latest "stable" (or something) revision.
>
> If you accept a tag identifying the latest stable revision, then you might
> as well not bother. The point of revision controlling a project is to be
> able to reconstruct previous states. If you allow any event, especially
> outside, unrelated, events to change the reconstructed state for a
> revision, then this is not the case. Your normal debugging situation will
> be "It's broken, and I didn't change anything." because someone somewhere
> else changed something, and you have no record of what last worked. And
> you can obviously forget any hope of "git bisect" working.
CVS does not have the concept of "hash" for use in identifying the state
of a particular set of files but it does have tags and CVS tags work
like Git tags. The form of identifier that is used to identify the
particular state of interest of a sub-project is dependent on the
policies and procedures of the super-project, and the SCM of the
sub-project.
The need to reproduce a particular state at sometime in the future is
well understood, even in organizations that use tools that only support
tags. Implying that it's not possible without using Git's immutable
hashes as the state identifier is just wrong.
--
^ permalink raw reply
* Re: Question on empty commit
From: Luben Tuikov @ 2006-01-16 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzhx7ref.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Luben Tuikov <ltuikov@yahoo.com> writes:
>
> > Now the last merge introduced an empty commit, since
> > tree A and tree B had been in sync (only local and
> > remote trunk had been out of sync). While it was expected
> > that no commit would be introduced since they were in sync.
> >
> > Was the empty commit correct behavior?
>
> I do not quite follow you, but immediately before the "empty
> commit" (I presume you mean the last "git merge" that merges
> treeA head in treeB), you say "the treeA and treeB had been in
> sync".
Meaning that merging Tree A into Tree B would introduce 0 changes
to Tree B.
> What do you exactly mean? The tree object in the head
> commits in treeA branch and treeB branch were identical?
They cannot be, since Tree B contains Project B, which is not
present in Tree A, but it depends on Project A in Tree A.
> If that is the case, the commit being empty is the correct
> behaviour, because there is no difference in the set of files
> introduced by that commit. And the commit being made is also
> the correct behaviour, because those two branches have different
> development history, and the commit is what binds them together.
So a new commit object, with 0 files changed was the correct behavior
after all?
I'd expect that there would be no commit object whatsoever since
those trees had been synced before. I.e. the only thing which changed
was the trunk and that trunk was synced to Tree A and Tree B separately.
Thanks,
Luben
^ permalink raw reply
* Re: RFC: Subprojects
From: Junio C Hamano @ 2006-01-16 20:49 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200601161144.48245.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> The suggested "bind" info in commit objects has the same problem
> as the original overlay: if the superproject already has a
> subdirectory kernel/, and there is an additional "bind" specification
> in commits also for kernel/, what should be done?
>
> So the gitlink object seems to be the only solution if we want to
> bind git versions of subprojects into a superproject.
In "pu", I have some of the necessary basic pieces for "bind"
approach, barely enough so that anybody interested could start
prototyping using them as building blocks. It still has very
rough edges; the missing includes rev-list and fsck-objects, so
you cannot do a send-pack or fetch-pack yet.
Yesterday I was working on "gitlink" approach to have similar
core-side support for prototyping. I haven't finished it into a
buildable state yet (it is not in "pu"), and I am pessimistic if
I ever will X-<.
I think the updated "bind" thing makes the two approaches
semantically equivalent (i.e. it does not allow an arbitrary
overlayed setup anymore). We simply do not allow the
conflicting "bind". So neither is the _only_ solution. We
probably could make both to work, but the details differ.
* With "gitlink", the index of containing project never has
subprojects parts of the tree, which I see it as an advantage
compared to what "bind" does. It only has one "gitlink"
entry per each subproject. update-index, read-tree,
ls-files, diff-*, etc. needs to be aware of "gitlink" object.
Especially tricky is read-tree. It needs to treat a
"gitlink" object as a directory for D/F conflict detection
purposes, but treat it similar to blobs in most other aspects
(e.g. results in one entry in the index). The stat
information update-index and diff-files uses for quick
up-to-date check needs to be taught not to worry about the
stat information of the subdirectory a "gitlink" object
points at (e.g. if you do a whole-tree build, the timestamp
of the directory would change, but that does not mean the
subtree is dirty). tree/directory traversal code needs to be
aware of "gitlink" and stop there. This approach involves
quite a lot of code changes, mostly because what is in the
current index never correspond to a directory on the
filesystem but "gitlink" quacks like a directory.
* With "bind", the index of containing project keeps the entire
tree structure, including subproject part. In fact, there is
no other separate index for the subproject part.
An updated write-tree in "pu" can write a tree for only the
subproject part with "write-tree --prefix=<path>/" from such
an index file, and read-tree can read with "read-tree
--prefix=<path>/" to graft a subproject tree on top of the
current index contents. Without the --prefix, write-tree
writes out the whole thing for a commit for the containing
project, so if somebody cloned that superproject, getting the
whole tree out in order to "make" is just the matter of doing
a regular "read-tree && checkout-index".
We could introduce "bind the rest" to make write-tree write
out a tree that contains only the containing project part and
not any of the subproject part (e.g. Makefile, README and
src/ but not linux-2.6/ nor gcc-4.0/ in the earlier example).
Essentially the contents of such a tree object would be the
same as what "gitlink" approach would have had for the
containing project in the index file, minus "gitlink" entries
themselves). This is not so surprising, because the missing
information "gitlink" approach recorded in the tree object
itself is expressed on "bind" lines in the commit object with
this approach.
An advantage with the "bind" approach, from the implementation
point of view, is that none of the "index vs working tree" part
of the core needs to be modified (you would notice that many
issues I had with trying "gitlink" I listed above are "index vs
working tree" issues). "tree object vs index" part needed to be
enhanced somewhat (e.g. the re-rooting read-tree/write-tree with
the --prefix option) but it was not too painful.
^ permalink raw reply
* Re: gitweb on kernel.org broken
From: Greg KH @ 2006-01-16 20:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Kay Sievers, git, H. Peter Anvin, gregkh
In-Reply-To: <7vwth0rlfm.fsf@assigned-by-dhcp.cox.net>
On Mon, Jan 16, 2006 at 12:02:05PM -0800, Junio C Hamano wrote:
> Kay Sievers <kay.sievers@vrfy.org> writes:
>
> >> Junio, seems your "textual symref HEAD" change is causing this?
>
> Yeah, I assumed git_read_head() is called only on a repository
> that was verified to be valid, and the subroutine did not check
> the case where HEAD does not verify. My bad. The attached
> patch should solve this.
>
> The error log says hotplug-ng.git is triggering it. I wonder what
> is so special about that repository. I hope it is transient
> during mirroring that mirrored HEAD before objects, not a
> corrupt repository at the mirroring source.
>
> ... goes to kernel.org mirroring source machine ...
>
> Ugh. It is _not_ a valid git repository. HEAD should be either a symlink
> or a symref pointing somewhere under refs/heads/, but in that
> directory, it instead is a regular file that contains an object
> name. There is nothing under refs/ either:
>
> $ ls -l /pub/scm/linux/hotplug/hotplug-ng.git/HEAD
> -rw-r--r-- 2 gregkh users 41 May 6 2005 /pub/s...ug-ng.git/HEAD
> $ cat /pub/scm/linux/hotplug/hotplug-ng.git/HEAD
> b26bec9f620a969fe5238e8666ab698f197df488
> $ ls -l /pub/scm/linux/hotplug/hotplug-ng.git/refs
> total 0
> $ exit
>
> Greg, could you let me know what is going on with this
> repository, please?
>
> First of all, I am wondering if this repository is still used
> (maintained); a regular file HEAD that contains an object name
> would have stopped working on Aug 27 2005 with this commit at the
> latest, maybe even before that:
That's a very old git tree, and the development tree is pretty much dead
too. I'll just go delete the thing.
Sorry about that.
greg k-h
^ permalink raw reply
* Re: RFC: Subprojects
From: Daniel Barkalow @ 2006-01-16 20:20 UTC (permalink / raw)
To: A Large Angry SCM
Cc: Martin Langhoff, Junio C Hamano, git, Johannes Schindelin,
Simon Richter
In-Reply-To: <43CBEF47.7050607@gmail.com>
On Mon, 16 Jan 2006, A Large Angry SCM wrote:
> Daniel Barkalow wrote:
> [...]
> >
> > So the problem with handling subprojects with the build system is that it is
> > too tempting to use the revision control system directly on the subproject,
> > at which point the thing you're developing and testing isn't at all what
> > other people will get if they check out your commit. You want "git status"
> > to report it as an uncommitted change if you have a different revision of
> > the subproject than your previous commit had, and it can't tell if this
> > information is buried in the build system.
>
> Using "git-status" is the wrong tool to use there. What you should be using is
> "make project_status". Claiming "that it is too tempting to use the revision
> control system on the subproject" is wrong; you should use the SCM (of the
> subproject) to manage the subproject. You use the build system to manage the
> _entire_ project.
I'm talking about using "git status" on the main project, in case you're
misunderstanding me. If you can manage the entire project with the build
system, then you don't need git or any version control at all, aside from
your build system. But you'd also lose the ability to use webgit, bisect,
gitk, git log, and so forth on the project as a whole.
> > The tricky question is whether we should permit the "subproject" objects to
> > specify a revision that isn't a hash, for use in identifying revisions of
> > subprojects in other systems.
>
> Why would you want to limit how required versions of subprojects are
> specified? Your project policies and procedures may require that subprojects
> be specified by a subproject SCM specific immutable revision but the policies
> and procedures of other projects may not be so restrictive and could accept a
> tag identifying the latest "stable" (or something) revision.
If you accept a tag identifying the latest stable revision, then you might
as well not bother. The point of revision controlling a project is to be
able to reconstruct previous states. If you allow any event, especially
outside, unrelated, events to change the reconstructed state for a
revision, then this is not the case. Your normal debugging situation will
be "It's broken, and I didn't change anything." because someone somewhere
else changed something, and you have no record of what last worked. And
you can obviously forget any hope of "git bisect" working.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: gitweb on kernel.org broken
From: Junio C Hamano @ 2006-01-16 20:02 UTC (permalink / raw)
To: Kay Sievers; +Cc: git, H. Peter Anvin, gregkh
In-Reply-To: <20060116190556.GA14184@vrfy.org>
Kay Sievers <kay.sievers@vrfy.org> writes:
>> Junio, seems your "textual symref HEAD" change is causing this?
Yeah, I assumed git_read_head() is called only on a repository
that was verified to be valid, and the subroutine did not check
the case where HEAD does not verify. My bad. The attached
patch should solve this.
The error log says hotplug-ng.git is triggering it. I wonder what
is so special about that repository. I hope it is transient
during mirroring that mirrored HEAD before objects, not a
corrupt repository at the mirroring source.
... goes to kernel.org mirroring source machine ...
Ugh. It is _not_ a valid git repository. HEAD should be either a symlink
or a symref pointing somewhere under refs/heads/, but in that
directory, it instead is a regular file that contains an object
name. There is nothing under refs/ either:
$ ls -l /pub/scm/linux/hotplug/hotplug-ng.git/HEAD
-rw-r--r-- 2 gregkh users 41 May 6 2005 /pub/s...ug-ng.git/HEAD
$ cat /pub/scm/linux/hotplug/hotplug-ng.git/HEAD
b26bec9f620a969fe5238e8666ab698f197df488
$ ls -l /pub/scm/linux/hotplug/hotplug-ng.git/refs
total 0
$ exit
Greg, could you let me know what is going on with this
repository, please?
First of all, I am wondering if this repository is still used
(maintained); a regular file HEAD that contains an object name
would have stopped working on Aug 27 2005 with this commit at the
latest, maybe even before that:
diff-tree 5f5608b... (from 9740d28...
Author: Linus Torvalds <torvalds@osdl.org>
Date: Sat Aug 27 13:54:42 2005 -0700
[PATCH] Make .git directory validation code test HEAD
Inspired by a report by Kalle Valo, this changes git-sh-setup-script and
the "setup_git_directory()" function to test that $GIT_DIR/HEAD is a
symlink, since a number of core git features depend on that these days.
...
The way I expected to see that part of the directory laid out in
a valid git repository would be:
$ cd /pub/scm/linux/hotplug/hotplug-ng.git/
$ mkdir -p refs/heads
$ cat HEAD >refs/heads/master
$ rm -f HEAD
$ ln -s refs/heads/master HEAD
Anyhow, here is a gitweb patch to skip this.
---
diff --git a/gitweb.cgi b/gitweb.cgi
index 986d7da..f3853e7 100755
--- a/gitweb.cgi
+++ b/gitweb.cgi
@@ -404,9 +404,8 @@ sub git_read_head {
if (open my $fd, "-|", "$gitbin/git-rev-parse", "--verify", "HEAD") {
my $head = <$fd>;
close $fd;
- chomp $head;
- if ($head =~ m/^[0-9a-fA-F]{40}$/) {
- $retval = $head;
+ if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
+ $retval = $1;
}
}
$ENV{'GIT_DIR'} = $oENV;
^ permalink raw reply related
* Re: [kernel.org users] [RFC] "clone --naked"?
From: Linus Torvalds @ 2006-01-16 19:17 UTC (permalink / raw)
To: Arjan van de Ven; +Cc: Junio C Hamano, Ulrich Windl, git, users
In-Reply-To: <1137402365.3034.5.camel@laptopd505.fenrus.org>
On Mon, 16 Jan 2006, Arjan van de Ven wrote:
>
> While I don't give a rats bottom about the "21"-ness of naked, "naked"
> is more likely to trigger spam traps than "bare" though... just a side
> consideration but unfortunately needed nowadays ;(
Yeah. I've had spamassassin kill patches to the aic7xxx driver because the
subject said "aic7xxx", and the "xxx" triggered as being a bad word.
Now, "naked" doesn't seem to trigger anything for spamassassin, but I
wouldn't be entirely surprised if some web-content blocker were to be
over-eager at times. So "bare" might be safer.
Linus
^ permalink raw reply
* git-mailinfo: cut lines at ^M
From: Linus Torvalds @ 2006-01-16 19:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
This changes "eatspace()" to cut lines at the first ^M (\r, CR) character.
Normally it should make no difference at all, since even if you have a
non-UNIX CR/LF end-of-line, it would have removed the ^M at the end of the
line as whitespace.
The main reason for this patch is that I seem to have something buggy in
my mail path (possibly fetchmail) which very occasionally causes the mail
headers to have an appended "^M)" line. This silly thing works around it,
and shouldn't hurt anything else.
The alternative would be to simply disallow control characters in the
commit message (so that I would not commit these things by mistake).
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
Junio, feel free to ignore this. It shouldn't hurt, but admittedly it's a
stupid hack for a problem that has nothing to do with git. The "disallow
control characters" fix is probably better, if you prefer that I can do it
that way instead.
Linus
diff --git a/mailinfo.c b/mailinfo.c
index 0265a29..e1c95a9 100644
--- a/mailinfo.c
+++ b/mailinfo.c
@@ -226,9 +226,19 @@ static int is_multipart_boundary(const c
static int eatspace(char *line)
{
- int len = strlen(line);
- while (len > 0 && isspace(line[len-1]))
- line[--len] = 0;
+ int len, idx;
+
+ len = idx = 0;
+ for (;;) {
+ unsigned char c = line[idx++];
+ if (isspace(c)) {
+ if (c == '\n' || c == '\r')
+ break;
+ continue;
+ }
+ len = idx;
+ }
+ line[len] = 0;
return len;
}
^ permalink raw reply related
* Re: RFC: Subprojects
From: A Large Angry SCM @ 2006-01-16 19:08 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Martin Langhoff, Junio C Hamano, git, Johannes Schindelin,
Simon Richter
In-Reply-To: <Pine.LNX.4.64.0601152248030.25300@iabervon.org>
Daniel Barkalow wrote:
[...]
>
> So the problem with handling subprojects with the build system is that it
> is too tempting to use the revision control system directly on the
> subproject, at which point the thing you're developing and testing isn't
> at all what other people will get if they check out your commit. You want
> "git status" to report it as an uncommitted change if you have a different
> revision of the subproject than your previous commit had, and it can't
> tell if this information is buried in the build system.
Using "git-status" is the wrong tool to use there. What you should be
using is "make project_status". Claiming "that it is too tempting to use
the revision control system on the subproject" is wrong; you should use
the SCM (of the subproject) to manage the subproject. You use the build
system to manage the _entire_ project.
> I like Linus's proposal: which revision of which project goes where is
> part of the content, while how you manipulate data for that project is a
> matter of local policy, and is not tracked, although it might be a good
> idea to let project provide overridable defaults (so that, if you're a
> random member of the general public and don't have a special method for
> accessing the repository, you don't have to track it down yourself).
I think Linus' proposal is an attempt to solve the problem in the wrong
place; it encumbers the SCM with features of limited applicability, that
impose a specific methodology on how to handle subprojects, and requires
that the SCM of the subproject be Git.
> The tricky question is whether we should permit the "subproject" objects
> to specify a revision that isn't a hash, for use in identifying revisions
> of subprojects in other systems.
Why would you want to limit how required versions of subprojects are
specified? Your project policies and procedures may require that
subprojects be specified by a subproject SCM specific immutable revision
but the policies and procedures of other projects may not be so
restrictive and could accept a tag identifying the latest "stable" (or
something) revision.
--
^ permalink raw reply
* Re: gitweb on kernel.org broken
From: Kay Sievers @ 2006-01-16 19:05 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <20060116185342.GA14088@vrfy.org>
On Mon, Jan 16, 2006 at 07:53:42PM +0100, Kay Sievers wrote:
> On Mon, Jan 16, 2006 at 10:44:35AM -0800, H. Peter Anvin wrote:
> > It seems that gitweb throws an error every time. This means that
> > nothing gets cached, and therefore the load on the kernel.org machines
> > is driven into the high double digits:
> >
> > [Mon Jan 16 10:42:01 2006] [error] [client 82.181.110.11] [Mon Jan 16
> > 10:42:01 2006] index.cgi: Use of uninitialized value in scalar
> > assignment at /home/httpd/html/git/index.cgi line 411.
> > [Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] fatal: Not a
> > git repository: '/pub/scm/linux/hotplug/hotplug-ng.git'
> > [Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] [Mon Jan 16
> > 10:42:03 2006] index.cgi: Use of uninitialized value in scalar chomp at
> > /home/httpd/html/git/index.cgi line 406.
> > [Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] [Mon Jan 16
> > 10:42:03 2006] index.cgi: Use of uninitialized value in pattern match
> > (m//) at /home/httpd/html/git/index.cgi line 407.
> >
> > This is all very bad...
>
> Junio, seems your "textual symref HEAD" change is causing this?
> http://www.kernel.org/git/?p=git/gitweb.git;a=blob;hb=HEAD;f=gitweb.cgi#l399
I've comment "strict" and "warnings" out, until it's fixed proper.
Kay
^ permalink raw reply
* Re: latest blob date (request)
From: Linus Torvalds @ 2006-01-16 19:00 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Git Mailing List
In-Reply-To: <20060115173100.1134256b.rdunlap@xenotime.net>
On Sun, 15 Jan 2006, Randy.Dunlap wrote:
>
> I would find it helpful (a user optimization) if each tree list
> contained a date-last-modified/updated. This could be used
> to help decide if I (someone) wanted to click on a particular
> blob or history (OK, blobs are quick, but history can be
> very time-consuming, so being able to shortcut or skip
> history would be very helpful IMO).
That's fundamentally a very expensive operation in git.
A "blob" doesn't have a date - and indeed, it cannot have one, since the
same blob may be associated with multiple different pathnames, and
multiple different commits.
If you have a particular pathname, you can ask "when was this pathname
changed last", which is basically
git-rev-list --max-count=1 HEAD -- Makefile
but that's not very cheap either.
Linus
^ permalink raw reply
* Re: gitweb on kernel.org broken
From: Kay Sievers @ 2006-01-16 18:53 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <43CBE993.9060701@zytor.com>
On Mon, Jan 16, 2006 at 10:44:35AM -0800, H. Peter Anvin wrote:
> It seems that gitweb throws an error every time. This means that
> nothing gets cached, and therefore the load on the kernel.org machines
> is driven into the high double digits:
>
> [Mon Jan 16 10:42:01 2006] [error] [client 82.181.110.11] [Mon Jan 16
> 10:42:01 2006] index.cgi: Use of uninitialized value in scalar
> assignment at /home/httpd/html/git/index.cgi line 411.
> [Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] fatal: Not a
> git repository: '/pub/scm/linux/hotplug/hotplug-ng.git'
> [Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] [Mon Jan 16
> 10:42:03 2006] index.cgi: Use of uninitialized value in scalar chomp at
> /home/httpd/html/git/index.cgi line 406.
> [Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] [Mon Jan 16
> 10:42:03 2006] index.cgi: Use of uninitialized value in pattern match
> (m//) at /home/httpd/html/git/index.cgi line 407.
>
> This is all very bad...
Junio, seems your "textual symref HEAD" change is causing this?
http://www.kernel.org/git/?p=git/gitweb.git;a=blob;hb=HEAD;f=gitweb.cgi#l399
Thanks,
Kay
^ permalink raw reply
* gitweb on kernel.org broken
From: H. Peter Anvin @ 2006-01-16 18:44 UTC (permalink / raw)
To: Kay Sievers, Git Mailing List
It seems that gitweb throws an error every time. This means that
nothing gets cached, and therefore the load on the kernel.org machines
is driven into the high double digits:
[Mon Jan 16 10:42:01 2006] [error] [client 82.181.110.11] [Mon Jan 16
10:42:01 2006] index.cgi: Use of uninitialized value in scalar
assignment at /home/httpd/html/git/index.cgi line 411.
[Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] fatal: Not a
git repository: '/pub/scm/linux/hotplug/hotplug-ng.git'
[Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] [Mon Jan 16
10:42:03 2006] index.cgi: Use of uninitialized value in scalar chomp at
/home/httpd/html/git/index.cgi line 406.
[Mon Jan 16 10:42:03 2006] [error] [client 82.181.110.11] [Mon Jan 16
10:42:03 2006] index.cgi: Use of uninitialized value in pattern match
(m//) at /home/httpd/html/git/index.cgi line 407.
This is all very bad...
-hpa
^ permalink raw reply
* Re: gitweb: latest blob date (request)
From: Junio C Hamano @ 2006-01-16 17:55 UTC (permalink / raw)
To: Kay Sievers; +Cc: git
In-Reply-To: <20060116174444.GA13512@vrfy.org>
Kay Sievers <kay.sievers@vrfy.org> writes:
> Hmm, where do I find this information? It is recorded in last commit,
> that changed the file, right? I'm not sure, if we can get this out of
> the git tools?
Yes we can. But it is rather expensive. You would do an
equivalent of "git whatchanged" for each and every path.
Of course commit chain is immutable so you could do this once
and cache the results.
^ permalink raw reply
* Re: gitweb: latest blob date (request)
From: Randy.Dunlap @ 2006-01-16 17:46 UTC (permalink / raw)
To: Kay Sievers; +Cc: Randy.Dunlap, Paul Mackerras, git
In-Reply-To: <20060116174444.GA13512@vrfy.org>
On Mon, 16 Jan 2006, Kay Sievers wrote:
> On Sun, Jan 15, 2006 at 09:10:11PM -0800, Randy.Dunlap wrote:
> > On Mon, 16 Jan 2006 16:07:09 +1100 Paul Mackerras wrote:
> >
> > > Randy,
> > >
> > > > I would find it helpful (a user optimization) if each tree list
> > > > contained a date-last-modified/updated. This could be used
> > > > to help decide if I (someone) wanted to click on a particular
> > > > blob or history (OK, blobs are quick, but history can be
> > > > very time-consuming, so being able to shortcut or skip
> > > > history would be very helpful IMO).
> > >
> > > Are you talking about gitk or gitweb? If you mean gitweb on
> > > kernel.org, Kay Sievers is who you need to talk to.
> >
> > Sheesh, you are correct. Sorry.
>
> Hmm, where do I find this information? It is recorded in last commit,
> that changed the file, right? I'm not sure, if we can get this out of
> the git tools?
I have no idea. Maybe not. If not, that's too bad.
I was just making a request of something that I think would
be very helpful.
--
~Randy
^ permalink raw reply
* Re: gitweb: latest blob date (request)
From: Kay Sievers @ 2006-01-16 17:44 UTC (permalink / raw)
To: Randy.Dunlap; +Cc: Paul Mackerras, git
In-Reply-To: <20060115211011.17b18f60.rdunlap@xenotime.net>
On Sun, Jan 15, 2006 at 09:10:11PM -0800, Randy.Dunlap wrote:
> On Mon, 16 Jan 2006 16:07:09 +1100 Paul Mackerras wrote:
>
> > Randy,
> >
> > > I would find it helpful (a user optimization) if each tree list
> > > contained a date-last-modified/updated. This could be used
> > > to help decide if I (someone) wanted to click on a particular
> > > blob or history (OK, blobs are quick, but history can be
> > > very time-consuming, so being able to shortcut or skip
> > > history would be very helpful IMO).
> >
> > Are you talking about gitk or gitweb? If you mean gitweb on
> > kernel.org, Kay Sievers is who you need to talk to.
>
> Sheesh, you are correct. Sorry.
Hmm, where do I find this information? It is recorded in last commit,
that changed the file, right? I'm not sure, if we can get this out of
the git tools?
Thanks,
Kay
^ permalink raw reply
* Software
From: Shard J. Housekeeper @ 2006-01-16 16:32 UTC (permalink / raw)
To: Git
Looking for cheap high-quality software?
Software taking a bite out of your budget? Try 0EM!
New software on our site:
Quark Xpress 6 Passport Multilanguage - $69.95
After Effects 6 - $69.95
Creative Suite Standard (3 CD) - $129.95
Painter 8 - $59.95
Windows NT 4.0 Server - $49.95
FileMaker 7.0 Professional - $69.95
Visio 2003 Professional - $69.95
Plus! XP - $59.95
Visio 2003 Professional - $69.95
Streets and Trips 2004 North America (2CD) - $69.95
Picture It Premium 9 - $59.95
Photoshop CS $99.95
Windows NT 4.0 Terminal Server - $49.95
Dreamweaver MX 2004 $69.95
Our site:
http://worldyli.com
^ permalink raw reply
* Re: Cancelling certain commits
From: Andreas Ericsson @ 2006-01-16 14:22 UTC (permalink / raw)
To: Bahadir Balban; +Cc: git
In-Reply-To: <7ac1e90c0601160557r78599886nca9be9b6672a1bd7@mail.gmail.com>
Bahadir Balban wrote:
> Hi,
>
> If I'm not happy with the changes I made in certain commits during
> development, how do I cancel those commits and remove them from git
> records most cleanly?
>
As a general rule, it's desirable to do
$ git revert --edit
if you've made some programmatical error which is non-obvious (not a
typo, fe), as you can then make clear why that code wasn't proper for
implementation. It will also hinder others from doing the same mistake.
Enough lessons though.
> For example if I did commits 1 to 10, and want to get rid of commit 3
> and 7, such that, the other commits are irrelevant to changes made in
> 3 and 7, but may involve changes in the same file as 3 and 7 changed,
> how do I handle it?
>
# make sure "git status" doesn't show any changes
$ git branch anchor # to make a safe point to reset to if things go bad
$ git reset --hard HEAD~7 # undo commits 3 - 10
# replay commits 4, 5, 6, 8, 9
$ for i in 6 5 4 2 1; do git cherry-pick -r anchor~$i || break; done
# replay commit 10
$ git cherry-pick -r anchor
# done
Another variant:
$ git format-patch --mbox -k HEAD~7
$ git reset --hard HEAD~7
# remove undesired commits from the files created
$ git am -k 000*
# done
If some commits depend on other commits both of these will fail and
you'll have to fix up by hand.
> Furthermore, how would I handle it if there was a commit 4, that
> depended partially on commit 3? (For example if it uses a type that
> was changed in commit 3?) Would I hand-edit commit 4 to fix it?
>
Some more lecturing then;
You should have used a topic-branch to introduce such changes. This is
always desirable when making a change that requires a series of patches.
If this didn't actually require several commits you should have done
them as one (I always try to make sure my projects at least compile
cleanly, even in topic-branches although they may contain warnings about
static but unused functions and variables).
As for fixing up commits by hand when they're already written to the
object database, you can't really do that (in an easy way, at least).
What you can do is use "git format-patch" to get patches in mbox format
for all the commits you eventually wish to keep, then do
$ git reset --hard <one-committish-*after*-undesired>
$ git cat-file commit HEAD > msg
$ git reset --soft HEAD~1
# edit changed files and msg
$ git commit -F msg changed_file1.c changed_file2.c changed_filen.c
Note that in all cases you should create an anchor branch to get you
back to where you were in case something goes wrong, and never *ever* do
$ git prune
on a repo where you're juggling loose commits like this (although that
should actually be safe when you create 'anchor' as a branch rather than
as a tag, which Junio usually recommends).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Cancelling certain commits
From: Bahadir Balban @ 2006-01-16 13:57 UTC (permalink / raw)
To: git
Hi,
If I'm not happy with the changes I made in certain commits during
development, how do I cancel those commits and remove them from git
records most cleanly?
For example if I did commits 1 to 10, and want to get rid of commit 3
and 7, such that, the other commits are irrelevant to changes made in
3 and 7, but may involve changes in the same file as 3 and 7 changed,
how do I handle it?
Furthermore, how would I handle it if there was a commit 4, that
depended partially on commit 3? (For example if it uses a type that
was changed in commit 3?) Would I hand-edit commit 4 to fix it?
Many thanks,
Bahadir
^ permalink raw reply
* Re: dangling commits
From: Marco Roeland @ 2006-01-16 12:40 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Marco Roeland, Junio C Hamano, git
In-Reply-To: <43CB8BFC.8050900@op5.se>
On Monday January 16th 2006 Andreas Ericsson wrote:
> The blobs are immutable and never change for a rebase, unless the
> file(s) it applies to is changed in master as well. It's the commits
> that do because they get new parents.
Ah, I need to rebase my mental picture of what a "rebase" is. ;-) And
the fact that each commit _does_ have sort of a blob (well in my mind I
called it so, the file under .git/objects, although its proper name is
indeed "commit") in the repository doesn't make it any easier!
Current documentation about git-rebase(1) is technically correct of
course then: "rebases local commits to the new head of the upstream
tree" but rather sparse for the less initiated. In Dutch we have an
expression for this, to "not be able to see the wood because of the
trees", which is rather appropriate here. Perhaps we can introduce
"liana" as an alternative for commit.
<Nice young men in clean white coats come in to take me away>
Seriously, yours and other peoples comments make the picture much
clearer to me and help out enormously to me and hopefully other lurkers
in working with git and more advanced SCM in general. Thanks,
--
Marco Roeland
^ permalink raw reply
* Re: dangling commits
From: Andreas Ericsson @ 2006-01-16 12:05 UTC (permalink / raw)
To: Marco Roeland; +Cc: Junio C Hamano, git
In-Reply-To: <20060116113332.GA5356@fiberbit.xs4all.nl>
Marco Roeland wrote:
> On Monday January 16th 2006 Andreas Ericsson wrote:
>
>
>>Since "pu" = "proposed updates" it only makes sense to keep it on top of
>>the current master, otherwise the effort required for anyone to test it
>>in conjunction with the latest master branch would simply be too great.
>
>
> But couldn't (in theory) the new "rebased" versions of blobs in the "pu"
> branch be first committed as the old not yet rebased version and then
> as the new version.
The blobs are immutable and never change for a rebase, unless the
file(s) it applies to is changed in master as well. It's the commits
that do because they get new parents.
Remember that the blob object is just the (deltified?) file that's the
result of the commit operation. The commit object is an object in its
own rights, holding author info and commit-time and such. Do
$ git cat-file commit HEAD
and you'll see what a commit-object looks like.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: dangling commits
From: Marco Roeland @ 2006-01-16 11:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Marco Roeland, Junio C Hamano, git
In-Reply-To: <43CB753D.2030706@op5.se>
On Monday January 16th 2006 Andreas Ericsson wrote:
> Since "pu" = "proposed updates" it only makes sense to keep it on top of
> the current master, otherwise the effort required for anyone to test it
> in conjunction with the latest master branch would simply be too great.
Certainly. And it probably is a good testbed for testing the rebasing
routines as well.
But couldn't (in theory) the new "rebased" versions of blobs in the "pu"
branch be first committed as the old not yet rebased version and then
as the new version. Not the fact that the blobs in "pu" are constantly
based on the latest master was the problem if I recollect, but the fact
that blobs sometimes disappeared. In comparing this with Linus' recent
explanation how git-bisect works in terms of light cones this might be
understood as the inherent problems with tachyons I think...
Anyway this is now solved I understand. Thanks.
> >I since removed it from the "Pull" list, but understand that "+pu"
> >should do the trick. I'll retry using it one of these days.
>
> It does. I also remember seeing lots of errors on that one when I first
> started with git (around 0.99b), but that was fixed quite some time ago.
Ok, thanks very much for explaining.
--
Marco Roeland
^ permalink raw reply
* Re: What's cooking in git.git
From: Petr Baudis @ 2006-01-16 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhd8al3ae.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Jan 12, 2006 at 01:04:41AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> - Disable USE_SYMLINK_HEAD by default (Pavel Roskin).
>
> This has been on hold for almost two months -- forever in git
> timescale.
>
> One offender that could have been broken by this change was
> fixed recently (gitweb), so this can go in anytime now. Do
> people still care about it? The argument for the change when
> it was proposed was "then we only have to worry about one
> format of .git/HEAD, not two", and it still is a valid
> argument from Porcelain writers' point of view. To be
> honest, since I do not do Porcelain, I am neutral about it.
Yes, I'd still be pleased to see this. Cogito should be ready for this
for long enough, as far as I'm concerned.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: RFC: Subprojects
From: Josef Weidendorfer @ 2006-01-16 10:44 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7vek3ah8f9.fsf@assigned-by-dhcp.cox.net>
On Saturday 14 January 2006 21:16, you wrote:
> Yes, I agree to the above 100%; the serious disadvantages come
> from the fact that we do not have clear separation between
> subprojects -- which new files belong to what subproject. I
> ...
> - Extend "commit" objects for the toplevel project to record
> what subprojects with what head commits are contained at
> which subdirectory.
The suggested "bind" info in commit objects has the same problem
as the original overlay: if the superproject already has a
subdirectory kernel/, and there is an additional "bind" specification
in commits also for kernel/, what should be done?
So the gitlink object seems to be the only solution if we want to
bind git versions of subprojects into a superproject.
But as this seems to make everything quite complex and not-obvious for
a user, I am with Paskys simple subproject idea.
Josef
^ permalink raw reply
* Re: dangling commits
From: Andreas Ericsson @ 2006-01-16 10:28 UTC (permalink / raw)
To: Marco Roeland; +Cc: Junio C Hamano, git
In-Reply-To: <20060116101722.GB5196@fiberbit.xs4all.nl>
Marco Roeland wrote:
> On Monday January 16th Junio C Hamano wrote:
>
>
>>Even when you use git native protocol, the objects the initial
>>clone gives you are kept packed, so when I rewind and rebuild
>>"pu" to make some of these objects orphaned, they will stay in
>>the pack the initial clone gave you. Unpack+repack is needed to
>>get rid of them.
>
>
> Thanks very much for explaining. It makes sense now.
>
> Does it bring many advantages for you to keep rebasing "pu"?
Since "pu" = "proposed updates" it only makes sense to keep it on top of
the current master, otherwise the effort required for anyone to test it
in conjunction with the latest master branch would simply be too great.
> I started
> out following that branch long ago (well in git reckoning anyway) but
> got very scared each time I got a bunch of "errors" on that one.
> I since removed it from the "Pull" list, but understand that "+pu"
> should do the trick. I'll retry using it one of these days.
It does. I also remember seeing lots of errors on that one when I first
started with git (around 0.99b), but that was fixed quite some time ago.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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