* Re: fatal: did you run git update-server-info on the server? mv post-update.sample post-update
From: Gary Yang @ 2008-11-20 21:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0811201204300.30769@pacific.mpi-cbg.de>
I ran the command, git update-server-info at the public repository machine. But, I still got the same error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
The file /pub/git/u-boot.git/info/refs do exist.
cat /pub/git/u-boot.git/info/refs
87ee4576c4c31b7046fe2bbbdf309eaba5c3f346 refs/heads/master
My question:
Is the contet of /pub/git/u-boot.git/hooks/post-update correct? Should I change "exec git-update-server-info" to "exec git update-server-info"?
cat /pub/git/u-boot.git/hooks/post-update
#!/bin/sh
#
# An example hook script to prepare a packed repository for use over
# dumb transports.
#
# To enable this hook, rename this file to "post-update".
exec git-update-server-info
I tried and changed "exec git-update-server-info" to "exec git update-server-info" in /pub/git/u-boot.git/hooks/post-update. But, I still got same error.
git pull http://git.mycompany.com/pub/git/u-boot.git HEAD
fatal: http://git.mycompany.com/pub/git/u-boot.git/info/refs not found: did you run git update-server-info on the server?
Which one is correct? "exec git-update-server-info" or "exec git update-server-info"? Eventhogh none of them working.
Below are my settings:
grep 9418 /etc/services
git 9418/tcp # Git Version Control System
grep git /etc/inetd.conf
git stream tcp nowait nobody /usr/local/libexec/git-core/git-daemon git-daemon --inetd --export-all /pub/git
cat /etc/xinetd.d/git-daemon
# default: off
# description: The git server offers access to git repositories
service git
{
disable = no
type = UNLISTED
port = 9418
socket_type = stream
wait = no
user = nobody
server = /usr/local/libexec/git-core/git-daemon
server_args = --inetd --export-all --base-path=/pub/git
log_on_failure += USERID
}
I am running git at Linux box:
uname -a
Linux svdclw004 2.6.9-67.ELsmp #1 SMP Wed Nov 7 13:56:44 EST 2007 x86_64 GNU/Linux
Are there anything wrong? Please let me know.
--- On Thu, 11/20/08, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Subject: Re: fatal: did you run git update-server-info on the server? mv post-update.sample post-update
> To: "Gary Yang" <garyyang6@yahoo.com>
> Cc: git@vger.kernel.org
> Date: Thursday, November 20, 2008, 3:05 AM
> Hi,
>
> On Wed, 19 Nov 2008, Gary Yang wrote:
>
> > I did not run post-update at public repository
> manually. Do I need to
> > run it for the very first time?
>
> You need to run it when you installed the hook _after_
> seeing the message
> "did you run...".
>
> Ciao,
> Dscho
> --
> 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 v2] Updated Swedish translation (514t0f0u).
From: Shawn O. Pearce @ 2008-11-20 19:33 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Peter Krefting, Git Mailing List, Mikael Magnusson
In-Reply-To: <49257790.5010105@op5.se>
Andreas Ericsson <ae@op5.se> wrote:
> Peter Krefting wrote:
>>
>>>> +msgid "Blame History Context Radius (days)"
>>>> +msgstr "Historikkontextradie för klandring (dagar)"
>>> At least a 100 points in scrabble for "historikkontextradie". How about
>>> "Historikradie för klandring (dagar)"?
>>
>> I struggled with this one. I still haven't got the faintest clue what
>> it is all about, but I have changed it as you suggested...
>
> I *think* it's about how many days to go back when viewing blame output
> for the selected file. Shawn, can you enlighten us here?
Yes, exactly. It tells git-gui what to pass to gitk. When you are in
the blame viewer you can open a "gitk --since=$d.days $commit -- $path"
window and $d is the property this message names.
--
Shawn.
^ permalink raw reply
* Re: git and mtime
From: Joey Hess @ 2008-11-20 19:24 UTC (permalink / raw)
To: git
In-Reply-To: <alpine.LNX.1.00.0811201223300.19665@iabervon.org>
[-- Attachment #1: Type: text/plain, Size: 1373 bytes --]
On Thu, 20 Nov 2008, Roger Leigh wrote:
> Except in this case I'm storing the content of *tarballs* (along with
> pristine-tar). I'm committing exactly what's in the tarball with
> no changes (this is a requirement). I can't change the source prior
> to commit.
Note that pristine-tar will work no matter what the mtimes or other file
metadata are, none of that affects generation of deltas or regeneration
of tarballs from them.
Also, the source you commit does not really have to be identical to
what's in the tarball. (Despite what it may say in the man page. ;-)
A larger delta will be generated if something is different.
So, three possible approaches:
1. Run make or whatever you need to do before running pristine-tar,
and put up with a larger delta.
2. Before building, you could use pristine-tar to extract the original
tarball, and then have a program examine that tarball, and reset the
mtimes in your build tree to match the mtimes of files in it.
(Or you could duplicate the info with metastore -m, which could be
restored quicker.)
3. Store uncompressed tarballs in git, so that they will pack
efficiently, and use pristine-gz to regenerate the pristine .tar.gz.
Only mentioned because this could be more space efficient than option
#1, if the pristine-tar deltas get too large.
--
see shy jo
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] sha1_file: avoid bogus "file exists" error message
From: Joey Hess @ 2008-11-20 18:56 UTC (permalink / raw)
To: Git List
This avoids the following misleading error message:
error: unable to create temporary sha1 filename ./objects/15: File exists
mkstemp can fail for many reasons, one of which, ENOENT, can occur if
the directory for the temp file doesn't exist. create_tmpfile tried to
handle this case by always trying to mkdir the directory, even if it
already existed. This caused errno to be clobbered, so one cannot tell
why mkstemp really failed, and it truncated the buffer to just the
directory name, resulting in the strange error message shown above.
Note that in both occasions that I've seen this failure, it has not been
due to a missing directory, or bad permissions, but some other, unknown
mkstemp failure mode that did not occur when I ran git again. This code
could perhaps be made more robust by retrying mkstemp, in case it was a
transient failure.
Signed-off-by: Joey Hess <joey@kitenet.net>
---
sha1_file.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..927fb64 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2231,7 +2231,7 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename)
memcpy(buffer, filename, dirlen);
strcpy(buffer + dirlen, "tmp_obj_XXXXXX");
fd = mkstemp(buffer);
- if (fd < 0 && dirlen) {
+ if (fd < 0 && dirlen && errno == ENOENT) {
/* Make sure the directory exists */
memcpy(buffer, filename, dirlen);
buffer[dirlen-1] = 0;
--
1.5.6.5
^ permalink raw reply related
* Re: New converstion tool: svn2git.py
From: Daniel Barkalow @ 2008-11-20 18:49 UTC (permalink / raw)
To: Neil Schemenauer; +Cc: git
In-Reply-To: <20081119191320.GA20870@arctrix.com>
On Wed, 19 Nov 2008, Neil Schemenauer wrote:
> Hi,
>
> I'm working on a tool to do conversions from SVN to git using a SVN
> dump. It's in early development but perhaps some people would be
> interested in it:
>
> http://python.ca/nas/python/svn2git.py
>
> I would like to improve it so that it intelligently converts SVN
> branches and tags into git branches (when possible). The basic idea
> is to map SVN paths into git branches, e.g. trunk -> master,
> branches/foo -> branch-foo, tags/bar -> tags-bar. Next, specific
> SVN dump actions like:
>
> Node-path: branches/foo
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk
>
> need to be detected and the commit needs to performed with the
> correct parent. One complication is that SVN can create a branch or
> tag from anywhere, for example, the action
>
> Node-path: tags/bar
> Node-kind: dir
> Node-action: add
> Node-copyfrom-rev: 3
> Node-copyfrom-path: trunk/subdir
>
> would create tags/bar based on revision 3 of trunk/subdir. There
> doesn't seem to be a good way to convert that into git. I was
> thinking that the tags-bar branch in that case would have no parent.
Probably the best thing in git would be to have the parent of the initial
commit on that branch be revision 3 of trunk; it will look like a big
rename of everything from subdir/* into the project root directory, which
is essentially what happened.
> Would git still efficently pack that or would you end up with extra
> blobs?
git will only ever store a single copy of identical file contents,
regardless of anything at all. Furthermore, when making a pack, git
compresses everything in the pack against everything else in the pack. Its
heuristics also ignore the leading directory names in guessing which blobs
are likely to help in compression (because there's a good chance that
anything named "Makefile" anywhere is useful in compressing anything else
named "Makefile").
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: git and mtime
From: Matthias Kestenholz @ 2008-11-20 18:36 UTC (permalink / raw)
To: Roger Leigh; +Cc: Andreas Ericsson, Christian MICHON, git
In-Reply-To: <20081120151925.GE6023@codelibre.net>
On 20.11.2008, at 16:19, Roger Leigh wrote:
>>
>> Then write a hook for it. You agree that for most users this will be
>> totally insane, and yet you request that it's added in a place where
>> everyone will have to pay the performance/diskspace penalty for it
>> but only a handful will get any benefits. That's patently absurd.
>
> The cost is tiny. The extra space would be smaller than a single
> SHA1 hash.
No, the cost is huge. The SHA-1 for the tree with _exactly the same
contents_ will be different, just because f.e you applied a patch one
second earlier than I did, and that's completely insane. Git is purely
a content tracker as has been said numerous times on this mailing
list, and that is for good reasons. If the tree entries change just
because some timestamps are different, the CPU time needed to
generate a diff will grow by a big amount of time.
Atempts to add additional information to the basic git objects have
failed several times, and yours will probably fail too since there are
numerous reasons why you do _not_ want a timestamp in the tree
_and_ there are several workarounds for your problem, which at
least in my opinion seem much less insane than adding timestamps...
>> Especially since there are such easy workarounds that you can put in
>> place yourself instead.
>
^ permalink raw reply
* Re: [PATCH v2] Document levenshtein.c
From: Johannes Schindelin @ 2008-11-20 18:31 UTC (permalink / raw)
To: Jon Loeliger; +Cc: Samuel Tardieu, Junio C Hamano, Git List
In-Reply-To: <1227201710.22668.2.camel@ld0161-tx32>
Hi,
On Thu, 20 Nov 2008, Jon Loeliger wrote:
> On Thu, 2008-11-20 at 14:27 +0100, Johannes Schindelin wrote:
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> > + * This implementation allows the costs to be weighted:
> > + *
> > + * - w (as in "sWap")
> > + * - s (as in "Substition")
> > + * - a (for insertion, AKA "Add")
> > + * - d (as in "Deletion")
> > + *
>
> I'm not sure what "Substition" is besides a misspelling.
It is a msipeling.
Thanks,
Dscho
^ permalink raw reply
* Re: git and mtime
From: Daniel Barkalow @ 2008-11-20 17:59 UTC (permalink / raw)
To: Roger Leigh; +Cc: Christian MICHON, git
In-Reply-To: <20081120112708.GC22787@ravenclaw.codelibre.net>
On Thu, 20 Nov 2008, Roger Leigh wrote:
> On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
> > On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
> > > Would it be possible for git to store the mtime of files in the tree?
> > >
> > > This would make it possible to do this type of work in git, since it's
> > > currently a bit random as to whether it works or not. This only
> > > started when I upgraded to an amd64 architecture from powerpc32,
> > > I guess it's maybe using high-resolution timestamps.
> > >
> >
> > beside the obvious answer it comes back often as a request, it is
> > possible in theory to create a shell script which, for each file
> > present in the sandbox in the current branch, would find the mtime of
> > the last commit on that file (quite an expensive operation) and apply
> > it.
>
> Surely this is only expensive because you're not already storing the
> information in the tree; if it was there, it would be (relatively)
> cheap? You could even compare the old and new trees to see if you
> needed to touch a file at all.
>
> > You should store mostly content of source files. You should do a make
> > in your first cloned repo at least once before committing anything to
> > the repo. That's what I did and I saved days...
>
> Except in this case I'm storing the content of *tarballs* (along with
> pristine-tar). I'm committing exactly what's in the tarball with
> no changes (this is a requirement). I can't change the source prior
> to commit.
Can you store the tarballs in the repository, instead of the contents of
the tarballs? The tarballs will contain the dates you want, and you can
obviously get tar to set the timestamps the way you want. (Then you add a
higher-level Makefile that knows how to unpack the tarball to a directory,
maintaining the timestamps, patch anything you're changing, and run make
in that directory.)
That is to say, from your perspective, the sources include the upstream
distributed tarballs, but the individual files in upstream tarballs aren't
source files for you, since you can't (by policy) modify them (within the
pristine tarball). If you want to change the sources of the packaged
project, you add a patch file to do it, rather than simply changing the
source (which, as you say, you're required not to do).
Git really wants to store the inputs to your workflow, each of which might
change independently. That's why the files in your work tree have
timestamps based on when they came to be in your work tree (get set to the
current time whenever git puts different content there, and leaves them
unchanged if their contents don't change when moving from commit to
commit). The "sources" in your workflow are a different set of files from
the sources in the project, and git really wants *your* repository to
match *your* workflow and not the workflow of the upstream project, when
you're acting as a packager rather than an upstream developer.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH v2] Document levenshtein.c
From: Sverre Rabbelier @ 2008-11-20 17:48 UTC (permalink / raw)
To: Jon Loeliger
Cc: Johannes Schindelin, Samuel Tardieu, Junio C Hamano, Git List
In-Reply-To: <1227201710.22668.2.camel@ld0161-tx32>
On Thu, Nov 20, 2008 at 18:21, Jon Loeliger <jdl@freescale.com> wrote:
> Were these supposed to be examples or definitions?
> The first looks like a definition by example.
> I'm not sure what "Substition" is besides a misspelling.
> Is it the definition "Substitution"? Or was it an
> example "Substitition" poorly spelled?
> The final two look like straight definitions.
Err, I'm pretty sure it's documenting the parameters?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git to libgit2 code relicensing
From: René Scharfe @ 2008-11-20 17:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <491DE6CC.6060201@op5.se>
Andreas Ericsson schrieb:
> The license decided for libgit2 is "GPL with gcc exception".
> Those who are OK with relicensing their contributions under
> that license for the purpose of libgit2, can you please say
> so?
Fine with me.
Thanks,
René
^ permalink raw reply
* Re: [PATCH v2] Document levenshtein.c
From: Jon Loeliger @ 2008-11-20 17:21 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Samuel Tardieu, Junio C Hamano, Git List
In-Reply-To: <alpine.DEB.1.00.0811201426100.30769@pacific.mpi-cbg.de>
On Thu, 2008-11-20 at 14:27 +0100, Johannes Schindelin wrote:
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> + * This implementation allows the costs to be weighted:
> + *
> + * - w (as in "sWap")
> + * - s (as in "Substition")
> + * - a (for insertion, AKA "Add")
> + * - d (as in "Deletion")
> + *
Were these supposed to be examples or definitions?
The first looks like a definition by example.
I'm not sure what "Substition" is besides a misspelling.
Is it the definition "Substitution"? Or was it an
example "Substitition" poorly spelled?
The final two look like straight definitions.
Thanks,
jdl
^ permalink raw reply
* Re: Whats happening with git-notes?
From: Jeff King @ 2008-11-20 16:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Tim Ansell, git
In-Reply-To: <alpine.DEB.1.00.0811201410320.30769@pacific.mpi-cbg.de>
On Thu, Nov 20, 2008 at 02:12:54PM +0100, Johannes Schindelin wrote:
> The same goes on here. I wanted to take Peff's idea -- that hadn't
> occurred to me back when I tried to help Johan with his notes idea --
> which is to read in the whole notes tree into a singleton when needed, and
> incorporate it into my existing test framework.
>
> Maybe I'll find time later today.
In case you do work on it, let me quickly communicate the two thoughts I
have had since the GitTogether (and you can feel free to ignore them,
but I want to try to say them before you code something differently,
so you at least have the _choice_ of ignoring them. :) ).
One is some thoughts on naming, which I already articulated here:
http://article.gmane.org/gmane.comp.version-control.git/100402
The other is on speeding up tree lookup. I think the "notes as a git
tree" is sound, but as we obviously realized, somewhat slow. So the
"speeding up notes" code is really about "speeding up tree lookup". And
while it would be nice for pack v4 to fix this for free, I don't think
we want to wait for that. And I think the "build a hash on the fly"
approach that I posted earlier is a sensible way to go.
_But_ where I think we should differ from that patch is that any notes
speedup should really be about a generic interface for speeding up tree
lookup. That is, it should come in the generic form of:
void tree_study(struct tree_study_context *c, struct tree *tree);
void tree_study_lookup(struct tree_study_context *c, const char *name);
where "tree_study" spends some cycles to make "tree_study_lookup" much
faster. And obviously most tree lookups wouldn't want to make this
tradeoff, but there may be a few other places that look in the same tree
several times, and we can benchmark them to see if they benefit. And if
and when faster non-studied tree lookup comes about, we can adjust the
tree studying algorithm easily.
-Peff
^ permalink raw reply
* Re: Whats happening with git-notes?
From: Jeff King @ 2008-11-20 16:39 UTC (permalink / raw)
To: Tim Ansell; +Cc: git
In-Reply-To: <1227183162.23155.32.camel@vaio>
On Thu, Nov 20, 2008 at 11:12:42PM +1100, Tim Ansell wrote:
> I was just wondering what is happening with git notes stuff? I really
> like the idea of being able to annotate commits with various
> information.
It's on my todo list, but I doubt I will get to it for at least another
week. For what was said since then, try this thread:
http://thread.gmane.org/gmane.comp.version-control.git/100533
and this message from another thread:
http://article.gmane.org/gmane.comp.version-control.git/100402
-Peff
^ permalink raw reply
* Media repositories and memory usage
From: Nguyen Thai Ngoc Duy @ 2008-11-20 16:19 UTC (permalink / raw)
To: Git Mailing List, Tim Ansell
Hi,
There is another aspect I did not see Tim mention in his slides:
memory usage with large blobs. Git has tradition of loading the whole
blob in memory for easy manipulation. It could consume a lot of memory
in large blob case (and particularly worse in mingw port because it
does not support mmap).
I see these operations that need access to blobs:
1. checkout blobs
2. checkin blobs
3. diff/delta blobs
Diffing blobs should be avoided any way for large blobs. Checking in
blobs does not require lots of memory. I'm working on checkout case to
reduce memory footprint. Is there any other case that will need full
blob in memory?
PS. For checkout/checkin case, if you do any conversion, full blob in
memory is still needed. But I guess that is rare for large blobs.
--
Duy
^ permalink raw reply
* Re: git and mtime
From: Samuel Tardieu @ 2008-11-20 15:56 UTC (permalink / raw)
To: martin f krafft; +Cc: Roger Leigh, git
In-Reply-To: <20081120135956.GA29789@piper.oerlikon.madduck.net>
>>>>> "martin" == martin f krafft <madduck@madduck.net> writes:
martin> I know you will hate me, but I think the solution here is to
martin> fix the toolchain and make those build dependencies required.
I agree with martin here. Your planned solution of not rebuilding the
files if the tools are not present may lead to serious problems if the
user modifies the source files and happens not to have the tools
around.
Moreover, requiring the build dependencies would allow you to drop the
generated files from the repository and rebuild them in your packaging
(source or binary) process.
Sam
--
Samuel Tardieu -- sam@rfc1149.net -- http://www.rfc1149.net/
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Nguyen Thai Ngoc Duy @ 2008-11-20 15:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20081120153252.GA7374@coredump.intra.peff.net>
On 11/20/08, Jeff King <peff@peff.net> wrote:
> On Thu, Nov 20, 2008 at 10:26:48PM +0700, Nguyen Thai Ngoc Duy wrote:
>
> > Thanks for catching. The last half also has the same problem. Another
>
>
> I'm not sure what you mean by "the last half also has the same problem";
> with the patch I posted (or Junio's patch) the test works fine for me.
Sorry for the confusion. I meant the second half of the series,
implementing UI interface for sparce checkout, which is not in pu yet.
--
Duy
^ permalink raw reply
* Re: git and mtime
From: Andreas Ericsson @ 2008-11-20 15:37 UTC (permalink / raw)
To: Roger Leigh; +Cc: Christian MICHON, git
In-Reply-To: <20081120151925.GE6023@codelibre.net>
Roger Leigh wrote:
> On Thu, Nov 20, 2008 at 03:50:49PM +0100, Andreas Ericsson wrote:
>> Roger Leigh wrote:
>>> On Thu, Nov 20, 2008 at 02:06:13PM +0100, Andreas Ericsson wrote:
>>>> Roger Leigh wrote:
>>>>> On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
>>>>>> On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
>>>>>>> Would it be possible for git to store the mtime of files in the tree?
>>>>>>>
>>>>>>> This would make it possible to do this type of work in git, since it's
>>>>>>> currently a bit random as to whether it works or not. This only
>>>>>>> started when I upgraded to an amd64 architecture from powerpc32,
>>>>>>> I guess it's maybe using high-resolution timestamps.
>>>>>>>
>>>> Caring about meta-data the way you mean it would mean that
>>>>
>>>> git add foo.c; git commit -m "kapooie"; touch foo.c; git status
>>>>
>>>> would show "foo.c" as modified. How sane is that?
>>> I've never come close to suggesting we do anything so insane.
>>>
>>> What I am suggesting is that on add/commit, the inode metadata
>>> be recorded in the tree (like we already store perms), so that
>>> it can be (**optionally**) reused/restored on checkout.
>>>
>>> Whether it's stored in the tree or not is a separate concern from
>>> whether to *use* it or not. For most situations, it won't be
>>> useful, as has been made quite clear from all of the replies, and I
>>> don't disagree with this. However, for some, the ability to have
>>> this information to hand to make use of would be invaluable.
>>>
>> Then write a hook for it. You agree that for most users this will be
>> totally insane, and yet you request that it's added in a place where
>> everyone will have to pay the performance/diskspace penalty for it
>> but only a handful will get any benefits. That's patently absurd.
>
> The cost is tiny. The extra space would be smaller than a single
> SHA1 hash.
>
>> Especially since there are such easy workarounds that you can put in
>> place yourself instead.
>
>
>>> There have been quite a few suggestions to look into using hooks,
>>> and I'll investigate this. However, I do have some concerns
>>> about *where* I would store this "extended tree" data, since it
>>> is implicitly tied to a single tree object, and I wouldn't
>>> want to store it directly as content.
>> Store it as a blob targeted by a lightweight tag named
>> "metadata.$sha1" and you'll have the easiest time in the world when
>> writing the hooks. Also, the tags won't be propagated by default,
>> which is a good thing since your timestamps/uid's whatever almost
>> certainly will not work well on other developers repositories.
>
> And yet the fact that it won't propagate makes it totally useless:
> all the other people using the repo won't get the extra metadata
> that will prevent build failures. Having the extra data locally
> is nice, but not exactly what I'd call a solution. The whole point
> of what I want is to have it as an integral part of the repo.
>
Then make it signed tags and ship them along.
Or do this properly and simply put in your buildsystem that some
targets never need to be rebuilt. That's (by far) the simplest
solution.
On a sidenote, I fail to see how the pre-generated stuff can avoid
getting updated unless also the sources for that stuff was updated,
in which case either of the following is true:
a) You really do need to rebuild, because upstream fucked up.
b) The pre-generated stuff should *also* be checked out and get new
timestamps.
Either way, to me it sounds like your buildsystem needs some love.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git and mtime
From: Kyle Moffett @ 2008-11-20 15:33 UTC (permalink / raw)
To: Roger Leigh; +Cc: Andreas Ericsson, Christian MICHON, git
In-Reply-To: <20081120151925.GE6023@codelibre.net>
On Thu, Nov 20, 2008 at 10:19 AM, Roger Leigh <rleigh@codelibre.net> wrote:
> And yet the fact that it won't propagate makes it totally useless:
> all the other people using the repo won't get the extra metadata
> that will prevent build failures. Having the extra data locally
> is nice, but not exactly what I'd call a solution. The whole point
> of what I want is to have it as an integral part of the repo.
Easiest way is typically something like this in the makefile:
docbook_version = $(shell docbook2man --version 2>/dev/null)
ifneq "$docbook_version",""
mymanpage.1:
## Real docbook build rules here
else
mymanpage.1:
if [ -e $@ ]; then \
echo "No 'docbook' installed, using pregenerated man
pages" >&2 ; \
else \
echo "Pregenerated manpages are missing and no docbook
found!" >&2 ; \
exit 1 ; \
fi
endif
Such stuff will take an order of magnitude less time than trying to
patch GIT to preserve metadata that most projects don't want
preserved. You may also find it's easier to just comment out the
documentation build rules if you are always guaranteeing that the docs
have been compiled.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Jeff King @ 2008-11-20 15:32 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <fcaeb9bf0811200726x1f2956c6k6f2ca16543a0fbc@mail.gmail.com>
On Thu, Nov 20, 2008 at 10:26:48PM +0700, Nguyen Thai Ngoc Duy wrote:
> Thanks for catching. The last half also has the same problem. Another
I'm not sure what you mean by "the last half also has the same problem";
with the patch I posted (or Junio's patch) the test works fine for me.
> way is maybe just stay away for those numbers, naming the files by
> alphabet. Just wonder if we could have some ways to automatically
> catch this kind of bug in the future.
Dscho suggested something similar. I would be happy if somebody wrote a
portability lint that found problems in shell constructs and calling
conventions of tools. In practice, though, I think it ends up being
quite hard to catalog all of the quirks of every platform (and
certainly, I would never have thought that this would break -- as it
was, after it _did_ break I had to sit scratching my head wondering how
that piece of code could be wrong).
So I think a simpler approach makes sense: write tests that make sure
the system is doing what you want, and then run those tests periodically
in the environments that you care about checking. When it breaks, you
know there is a problem. :) And that is exactly how this bug was caught.
-Peff
^ permalink raw reply
* Re: [PATCH 5/9] update-index: add --checkout/--no-checkout to update CE_NO_CHECKOUT bit
From: Nguyen Thai Ngoc Duy @ 2008-11-20 15:26 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Shawn O. Pearce
In-Reply-To: <20081119130223.GA27893@segfault.peff.net>
On 11/19/08, Jeff King <peff@peff.net> wrote:
> On Tue, Nov 18, 2008 at 06:18:10PM -0800, Junio C Hamano wrote:
>
> > Having said all that, I wouldn't suggest redoing the patch using >>
> > redirection. But change from "touch 1 nondigit" to "touch nondigit 1"
> > is a bit too subtle to my taste. Let's write it this way instead:
>
>
> Yes, I also dislike the subtlety, but my "obvious" idea was something
> like:
>
> for i in 1 2 sub/1 sub/2; do
> touch $i
> done
>
> which just seemed clunky. But:
>
>
> > - touch 1 2 sub/1 sub/2 &&
> > + touch ./1 ./2 sub/1 sub/2 &&
>
>
> this is less clunky, and I have confirmed that it solves the problem. I
> just wasn't clever enough to think of it in the first place. ;)
Thanks for catching. The last half also has the same problem. Another
way is maybe just stay away for those numbers, naming the files by
alphabet. Just wonder if we could have some ways to automatically
catch this kind of bug in the future.
--
Duy
^ permalink raw reply
* Re: git commit -v does not removes the patch
From: Jeff King @ 2008-11-20 15:20 UTC (permalink / raw)
To: SZEDER Gábor; +Cc: Junio C Hamano, Santi Béjar, Git Mailing List
In-Reply-To: <20081120130851.GA17608@neumann>
On Thu, Nov 20, 2008 at 02:09:28PM +0100, SZEDER Gábor wrote:
> I always want to see the diff while editing a commit message, even if
> it's the commit message of a merge, a revert, a squash in rebase.
> Since these commands do not have an option equivalent to 'git commit
> -v', I wrote a little prepare-commit-msg hook to always append the
> appropriate diff to the end of the appropriate commit message file.
> This worked pretty well for the last couple of months, until 5/5 got
> into maint.
Hmm. I am sad that this change has broken somebody's existing workflow.
OTOH, I'm not convinced that workflow wasn't a little crazy to begin
with, depending on this undocumented munging.
> So, what is the/is there a preferred way to always include the diff in
> the commit message template and get it removed automatically? Are
> there any workarounds other than revert that commit locally?
How about:
$ cat .git/hooks/prepare-commit-msg
#!/bin/sh
git diff --cached >>"$1"
$ cat .git/hooks/commit-msg
#!/bin/sh
sed -i '/^diff --git/Q' "$1"
which is more or less the original behavior. The only downside I see is
that "--no-verify" will turn off the commit-msg hook, but not the
prepare-commit-msg hook.
-Peff
^ permalink raw reply
* Re: git and mtime
From: Roger Leigh @ 2008-11-20 15:19 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Christian MICHON, git
In-Reply-To: <49257949.4070308@op5.se>
On Thu, Nov 20, 2008 at 03:50:49PM +0100, Andreas Ericsson wrote:
> Roger Leigh wrote:
>> On Thu, Nov 20, 2008 at 02:06:13PM +0100, Andreas Ericsson wrote:
>>> Roger Leigh wrote:
>>>> On Wed, Nov 19, 2008 at 05:18:16PM +0100, Christian MICHON wrote:
>>>>> On Wed, Nov 19, 2008 at 12:37 PM, Roger Leigh <rleigh@codelibre.net> wrote:
>>>>>> Would it be possible for git to store the mtime of files in the tree?
>>>>>>
>>>>>> This would make it possible to do this type of work in git, since it's
>>>>>> currently a bit random as to whether it works or not. This only
>>>>>> started when I upgraded to an amd64 architecture from powerpc32,
>>>>>> I guess it's maybe using high-resolution timestamps.
>>>>>>
>>> Caring about meta-data the way you mean it would mean that
>>>
>>> git add foo.c; git commit -m "kapooie"; touch foo.c; git status
>>>
>>> would show "foo.c" as modified. How sane is that?
>>
>> I've never come close to suggesting we do anything so insane.
>>
>> What I am suggesting is that on add/commit, the inode metadata
>> be recorded in the tree (like we already store perms), so that
>> it can be (**optionally**) reused/restored on checkout.
>>
>> Whether it's stored in the tree or not is a separate concern from
>> whether to *use* it or not. For most situations, it won't be
>> useful, as has been made quite clear from all of the replies, and I
>> don't disagree with this. However, for some, the ability to have
>> this information to hand to make use of would be invaluable.
>>
>
> Then write a hook for it. You agree that for most users this will be
> totally insane, and yet you request that it's added in a place where
> everyone will have to pay the performance/diskspace penalty for it
> but only a handful will get any benefits. That's patently absurd.
The cost is tiny. The extra space would be smaller than a single
SHA1 hash.
> Especially since there are such easy workarounds that you can put in
> place yourself instead.
>> There have been quite a few suggestions to look into using hooks,
>> and I'll investigate this. However, I do have some concerns
>> about *where* I would store this "extended tree" data, since it
>> is implicitly tied to a single tree object, and I wouldn't
>> want to store it directly as content.
>
> Store it as a blob targeted by a lightweight tag named
> "metadata.$sha1" and you'll have the easiest time in the world when
> writing the hooks. Also, the tags won't be propagated by default,
> which is a good thing since your timestamps/uid's whatever almost
> certainly will not work well on other developers repositories.
And yet the fact that it won't propagate makes it totally useless:
all the other people using the repo won't get the extra metadata
that will prevent build failures. Having the extra data locally
is nice, but not exactly what I'd call a solution. The whole point
of what I want is to have it as an integral part of the repo.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
^ permalink raw reply
* Re: [PATCH] Allow help/--help/-h to be run outside of a TopGit repo
From: martin f krafft @ 2008-11-20 15:11 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20081120150832.GI10491@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 1003 bytes --]
also sprach Petr Baudis <pasky@suse.cz> [2008.11.20.1608 +0100]:
> What is that?
http://en.wikipedia.org/wiki/Law_of_Demeter
In the context of our discussion, it basically means that if
should_do_help calls do_help, then we cannot test should_do_help
independently (without mocking out do_help, which is plain ugly).
Not that we have a testing infrastructure (yet) anyway, but...
> > True, but then we are parsing command lines. Would you be opposed to
> > a getopt (POSIX) approach to normalising/parsing the command line?
>
> No. :-)
Good. I will see what I can do about this. In the mean time, I will
just leave things as they are.
--
.''`. martin f. krafft <madduck@debian.org>
: :' : proud Debian developer, author, administrator, and user
`. `'` http://people.debian.org/~madduck - http://debiansystem.info
`- Debian - when you have better things to do than fixing systems
windoze nt crashed.
i am the blue screen of death.
no one hears your screams.
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Allow help/--help/-h to be run outside of a TopGit repo
From: Petr Baudis @ 2008-11-20 15:08 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20081120145511.GD29789@piper.oerlikon.madduck.net>
On Thu, Nov 20, 2008 at 03:55:11PM +0100, martin f krafft wrote:
> also sprach Petr Baudis <pasky@suse.cz> [2008.11.20.1527 +0100]:
> > Why is this so complicated? Can't you just do_help from
> > should_do_help()?
>
> Yes, I could, but that would be in conflict with my understanding of
> the Law of Demeter.
What is that?
> > The overall semantics seems strange anyway, though - it seems that
> > 'tg mail --help -r' will try to show help for '-r' instead of
> > 'mail'.
>
> True, but then we are parsing command lines. Would you be opposed to
> a getopt (POSIX) approach to normalising/parsing the command line?
No. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [TopGit PATCH] tg patch: disable pager and colors for git-diff
From: Petr Baudis @ 2008-11-20 15:07 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: madduck, git
In-Reply-To: <2c6b72b30811200655o770efd63u4101f44683f2bc0d@mail.gmail.com>
On Thu, Nov 20, 2008 at 03:55:47PM +0100, Jonas Fonseca wrote:
> On Thu, Nov 20, 2008 at 15:34, Petr Baudis <pasky@suse.cz> wrote:
> > On Thu, Nov 20, 2008 at 02:57:10PM +0100, Jonas Fonseca wrote:
> >> When output is not redirected to a file, git brings up the pager for
> >> only the diff, which can be confusing, so disable with --no-pager.
> >> git-diff is a porcelain command and thus subject to color options. Use
> >> --no-color, to avoid the patch being corrupted with terminal escape
> >> characters when color.diff=always.
> >>
> >> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
> >
> > I still don't understand how did that color thing happen - shouldn't
> > git diff avoid spewing out colors when the output is not a tty? And when
> > it is, I want the colors myself, too.
>
> As I wrote in the commit message, git diff always spews out colors
> with color.diff=always. This was what I for experimental reasons had
> in my .git/config (and forgotten all about) before sending the README
> update patch. Topgit could check the git color configuration but that
> seems more hacky.
This shows just that color.diff=always is asking for trouble. ;-)
I think we shouldn't try to outsmart the user if they _force_ that they
really always want the colors.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ 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