* 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
* Re: [TopGit PATCH] tg patch: disable pager and colors for git-diff
From: Jonas Fonseca @ 2008-11-20 14:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: madduck, git
In-Reply-To: <20081120143455.GH10544@machine.or.cz>
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.
> Good point with the --no-pager, but in that case, tg patch itself should
> by default invoke the pager, since it really is very desirable.
Yes, probably.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Allow help/--help/-h to be run outside of a TopGit repo
From: martin f krafft @ 2008-11-20 14:55 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20081120142702.GG10491@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
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.
> 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?
Cheers,
--
.''`. 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
this space intentionally left occupied.
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git and mtime
From: Andreas Ericsson @ 2008-11-20 14:50 UTC (permalink / raw)
To: Roger Leigh; +Cc: Christian MICHON, git
In-Reply-To: <20081120141533.GC6023@codelibre.net>
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.
>>>>>
>>>> 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?
>> No, it's because git is *snapshot* based and doesn't care about anything
>> but contents. Storing filestate information in the tree would be a
>> backwards incompatible change that would require a major version change.
>
> It's not strictly true that it's only caring about contents. The
> contents are of course in the blobs, but the tree is already
> effectively storing inode data, since it's a directory of
> filenames/subtrees, just one that only cares to store the
> permissions part of the total inode data.
>
> I understand that git stored the permissions tacked onto the hash;
> would it be feasable to tack on the other bits as well.
No, that would break backwards compatibility with cross-repo
transfers.
> If I understand correctly, it's binary encoded in the pack format,
> and that would require updating the format to hold the additional
> data?
>
>> 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.
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.
That's what I'd do anyways.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2] Updated Swedish translation (514t0f0u).
From: Andreas Ericsson @ 2008-11-20 14:43 UTC (permalink / raw)
To: Peter Krefting; +Cc: Shawn O. Pearce, Git Mailing List, Mikael Magnusson
In-Reply-To: <Pine.LNX.4.64.0811201423291.1606@ds9.cixit.se>
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?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [TopGit PATCH] tg patch: disable pager and colors for git-diff
From: Petr Baudis @ 2008-11-20 14:34 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: madduck, git
In-Reply-To: <20081120135710.GA16303@diku.dk>
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.
Good point with the --no-pager, but in that case, tg patch itself should
by default invoke the pager, since it really is very desirable.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: [PATCH] Allow help/--help/-h to be run outside of a TopGit repo
From: Petr Baudis @ 2008-11-20 14:27 UTC (permalink / raw)
To: martin f. krafft; +Cc: git
In-Reply-To: <1227181594-15123-1-git-send-email-madduck@debian.org>
On Thu, Nov 20, 2008 at 12:46:34PM +0100, martin f. krafft wrote:
> The user ought to be able to call `tg help` from anywhere in the filesystem,
> not just Git repositories, so the help parsing has to happen before the calls
> to git git binary.
>
> Debian bug: #501982
>
> Signed-off-by: martin f. krafft <madduck@debian.org>
>
> ---
> tg.sh | 28 +++++++++++++++++++++++++---
> 1 files changed, 25 insertions(+), 3 deletions(-)
>
> diff --git a/tg.sh b/tg.sh
> index 4dcc15e..258f8ce 100644
> --- a/tg.sh
> +++ b/tg.sh
> @@ -235,12 +235,37 @@ do_help()
> fi
> }
>
> +# Check whether we are supposed to output the help message
> +should_do_help()
> +{
> + # we are being sourced for utility functions, never run help
> + [ -z "$tg__include" ] || return 1
> +
> + local prev
> + while [ -n "$1" ]; do
> + case "$1" in
> + help|--help|-h)
> + shift
> + echo "${1:-$prev}"
> + return 0
> + esac
> + prev="$1"
> + shift
> + done
> +
> + # run help when there was no previous topic, meaning that there where
> + # no arguments at all
> + test -z "$prev"
> +}
>
> ## Startup
>
> [ -d "@cmddir@" ] ||
> die "No command directory: '@cmddir@'"
>
> +# check if we should run help and get the topic while we're at it
> +help_topic="$(should_do_help "$@")" && { do_help "$help_topic"; exit 0; }
> +
Why is this so complicated? Can't you just do_help from
should_do_help()? The overall semantics seems strange anyway, though -
it seems that 'tg mail --help -r' will try to show help for '-r' instead
of 'mail'.
--
Petr "Pasky" Baudis
People who take cold baths never have rheumatism, but they have
cold baths.
^ permalink raw reply
* Re: [TopGit PATCH] README: Fix spelling
From: Jonas Fonseca @ 2008-11-20 14:23 UTC (permalink / raw)
To: martin f krafft; +Cc: git
In-Reply-To: <20081120141725.GB25425@piper.oerlikon.madduck.net>
On Thu, Nov 20, 2008 at 15:17, martin f krafft <madduck@debian.org> wrote:
> also sprach Jonas Fonseca <jonas.fonseca@gmail.com> [2008.11.20.1452 +0100]:
>> Oops sorry about this one!!! :-/
>
> What about it? The patch seems perfectly alright. Only the quoted
> version is broken, which I think is your fault.
Well, it looks very broken in Gmail ...
> Should I apply the README patch?
Yes, if you can salvage it. Else it is also available in branch
jf/readme-update at
git://repo.or.cz/topgit/fonseca.git
--
Jonas Fonseca
^ permalink raw reply
* Re: git and mtime
From: Roger Leigh @ 2008-11-20 14:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: martin f krafft, git
In-Reply-To: <alpine.DEB.1.00.0811201506390.30769@pacific.mpi-cbg.de>
On Thu, Nov 20, 2008 at 03:07:46PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 20 Nov 2008, Roger Leigh wrote:
>
> > They are optional build depdendencies. They are provided pre-built, and
> > won't be rebuilt unless they get outdated. In the release tarball, the
> > timestamps are correct, ensuring this never happens. When checking out
> > with git, the timestamps are incorrect, and it attempts to rebuild
> > something that's *already built*.
>
> I'll try just one more time. Why don't you teach your build process to
> check if the generated files can be generated, and if not, fall back to
> the committed ones?
Well, it's definitely not a good idea to try rebuilding when the tools
aren't available, and I'll update the Makefiles to only attempt a
rebuild when this is the case. So yes, making the build a bit more
intelligent is definitely something to do. However, this is really
a separate issue, since the repo dates back eight years, and I don't
want to break older stuff. This will only fix things for the future.
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: [TopGit PATCH] README: Fix spelling
From: martin f krafft @ 2008-11-20 14:17 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <2c6b72b30811200552h46004299w881ad61134ec5555@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 663 bytes --]
also sprach Jonas Fonseca <jonas.fonseca@gmail.com> [2008.11.20.1452 +0100]:
> Oops sorry about this one!!! :-/
What about it? The patch seems perfectly alright. Only the quoted
version is broken, which I think is your fault.
Should I apply the README patch?
--
.''`. 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
a Hooloovoo is a superintelligent shade of the color blue.
-- douglas adams, "the hitchhiker's guide to the galaxy"
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git and mtime
From: Roger Leigh @ 2008-11-20 14:15 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Christian MICHON, git
In-Reply-To: <492560C5.5070308@op5.se>
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.
>>>>
>>> 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?
>
> No, it's because git is *snapshot* based and doesn't care about anything
> but contents. Storing filestate information in the tree would be a
> backwards incompatible change that would require a major version change.
It's not strictly true that it's only caring about contents. The
contents are of course in the blobs, but the tree is already
effectively storing inode data, since it's a directory of
filenames/subtrees, just one that only cares to store the
permissions part of the total inode data.
I understand that git stored the permissions tacked onto the hash;
would it be feasable to tack on the other bits as well.
If I understand correctly, it's binary encoded in the pack format,
and that would require updating the format to hold the additional
data?
> 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.
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.
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: git and mtime
From: martin f krafft @ 2008-11-20 13:59 UTC (permalink / raw)
To: Roger Leigh, git
In-Reply-To: <20081120133546.GA6023@codelibre.net>
[-- Attachment #1: Type: text/plain, Size: 848 bytes --]
also sprach Roger Leigh <rleigh@codelibre.net> [2008.11.20.1435 +0100]:
> By end user, I mean person downloading and building the sources.
>
> They are optional build depdendencies. They are provided pre-built,
> and won't be rebuilt unless they get outdated. In the release
> tarball, the timestamps are correct, ensuring this never happens.
> When checking out with git, the timestamps are incorrect, and it
> attempts to rebuild something that's *already built*.
I know you will hate me, but I think the solution here is to fix the
toolchain and make those build dependencies required.
--
martin | http://madduck.net/ | http://two.sentenc.es/
"first get your facts; then you can distort them at your leisure."
-- mark twain
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git and mtime
From: Johannes Schindelin @ 2008-11-20 14:07 UTC (permalink / raw)
To: Roger Leigh; +Cc: martin f krafft, git
In-Reply-To: <20081120133546.GA6023@codelibre.net>
Hi,
On Thu, 20 Nov 2008, Roger Leigh wrote:
> They are optional build depdendencies. They are provided pre-built, and
> won't be rebuilt unless they get outdated. In the release tarball, the
> timestamps are correct, ensuring this never happens. When checking out
> with git, the timestamps are incorrect, and it attempts to rebuild
> something that's *already built*.
I'll try just one more time. Why don't you teach your build process to
check if the generated files can be generated, and if not, fall back to
the committed ones?
Ciao,
Dscho
^ permalink raw reply
* [TopGit PATCH] Add Vim modelines for consistent spacing
From: martin f. krafft @ 2008-11-20 13:59 UTC (permalink / raw)
To: git, pasky; +Cc: martin f. krafft
TopGit shell scripts use sw=8:ts=8:noet and to ensure that everyone complies,
these modelines configure Vim on open.
Signed-off-by: martin f. krafft <madduck@debian.org>
---
create-help.sh | 1 +
tg-create.sh | 2 ++
tg-delete.sh | 2 ++
tg-depend.sh | 2 ++
tg-export.sh | 2 ++
tg-import.sh | 2 ++
tg-info.sh | 2 ++
tg-mail.sh | 2 ++
tg-patch.sh | 2 ++
tg-remote.sh | 2 ++
tg-summary.sh | 2 ++
tg-update.sh | 2 ++
tg.sh | 2 ++
13 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/create-help.sh b/create-help.sh
index 766e8d4..8324b2a 100755
--- a/create-help.sh
+++ b/create-help.sh
@@ -15,3 +15,4 @@ fi
{ if (incommand) { print $0; } }
' > tg-"$1".txt
+# vim:sw=8:ts=8:noet
diff --git a/tg-create.sh b/tg-create.sh
index 6ee3f02..677c19d 100644
--- a/tg-create.sh
+++ b/tg-create.sh
@@ -141,3 +141,5 @@ git add -f "$root_dir/.topmsg"
info "Topic branch $name set up. Please fill .topmsg now and make initial commit."
info "To abort: git rm -f .top* && git checkout ${deps%% *} && $tg delete $name"
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-delete.sh b/tg-delete.sh
index 7f7ede7..37f4bac 100644
--- a/tg-delete.sh
+++ b/tg-delete.sh
@@ -44,3 +44,5 @@ branch_empty "$name" || nonempty=1
git update-ref -d "refs/top-bases/$name" "$baserev"
git update-ref -d "refs/heads/$name" "$branchrev"
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-depend.sh b/tg-depend.sh
index ff4541c..4539188 100644
--- a/tg-depend.sh
+++ b/tg-depend.sh
@@ -47,3 +47,5 @@ echo "$name" >>"$root_dir/.topdeps"
git add -f "$root_dir/.topdeps"
git commit -m"New TopGit dependency: $name"
$tg update
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-export.sh b/tg-export.sh
index 52af88d..73a6ec8 100644
--- a/tg-export.sh
+++ b/tg-export.sh
@@ -199,3 +199,5 @@ elif [ "$driver" = "quilt" ]; then
depcount="$(cat "$output/series" | wc -l)"
echo "Exported topic branch $name (total $depcount topics) to directory $output"
fi
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-import.sh b/tg-import.sh
index b036b86..5c0484c 100644
--- a/tg-import.sh
+++ b/tg-import.sh
@@ -116,3 +116,5 @@ do
esac
done
done
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-info.sh b/tg-info.sh
index 9076247..6ae55c3 100644
--- a/tg-info.sh
+++ b/tg-info.sh
@@ -73,3 +73,5 @@ else
echo "Up-to-date."
fi
rm "$depcheck"
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-mail.sh b/tg-mail.sh
index 7b8f7ff..4d23a0e 100644
--- a/tg-mail.sh
+++ b/tg-mail.sh
@@ -55,3 +55,5 @@ people=
eval git send-email $send_email_args "$people" "$patchfile"
rm "$patchfile"
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-patch.sh b/tg-patch.sh
index 97338ab..220a0b0 100644
--- a/tg-patch.sh
+++ b/tg-patch.sh
@@ -44,3 +44,5 @@ echo '-- '
echo "tg: ($base_rev..) $name (depends on: $(git cat-file blob "$name:.topdeps" | paste -s -d' '))"
branch_contains "$name" "$base_rev" ||
echo "tg: The patch is out-of-date wrt. the base! Run \`$tg update\`."
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-remote.sh b/tg-remote.sh
index 4f60c73..2a9c4a0 100644
--- a/tg-remote.sh
+++ b/tg-remote.sh
@@ -59,3 +59,5 @@ git for-each-ref "refs/remotes/$name/top-bases" |
git config "topgit.remote" "$name"
info "The remote '$name' is now the default source of topic branches."
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-summary.sh b/tg-summary.sh
index 3c90a6b..c165d19 100644
--- a/tg-summary.sh
+++ b/tg-summary.sh
@@ -98,3 +98,5 @@ git for-each-ref refs/top-bases |
if [ -n "$graphviz" ]; then
echo '}'
fi
+
+# vim:sw=8:ts=8:noet
diff --git a/tg-update.sh b/tg-update.sh
index 040800d..1114b7d 100644
--- a/tg-update.sh
+++ b/tg-update.sh
@@ -142,3 +142,5 @@ if ! git merge "$merge_with"; then
fi
exit 3
fi
+
+# vim:sw=8:ts=8:noet
diff --git a/tg.sh b/tg.sh
index 4dcc15e..137fef4 100644
--- a/tg.sh
+++ b/tg.sh
@@ -283,3 +283,5 @@ help|--help|-h)
}
. "@cmddir@"/tg-$cmd;;
esac
+
+# vim:sw=8:ts=8:noet
--
tg: (f17218e..) features/vim-modelines (depends on: upstream)
^ permalink raw reply related
* [TopGit PATCH] tg patch: disable pager and colors for git-diff
From: Jonas Fonseca @ 2008-11-20 13:57 UTC (permalink / raw)
To: madduck; +Cc: git
In-Reply-To: <1227189062-11951-1-git-send-email-fonseca@diku.dk>
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>
---
tg-patch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Jonas Fonseca <fonseca@diku.dk> wrote Thu, Nov 20, 2008:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> ---
> README^[[m | 11 ^[[32m+++++^[[m^[[31m------^[[m
> 1 files changed, 5 insertions(+), 6 deletions(-)^[[m
>
> ^[[1mdiff --git a/README b/README^[[m
> ^[[1mindex 5bfe3ee..9e291da 100644^[[m
> ^[[1m--- a/README^[[m
> ^[[1m+++ b/README^[[m
I hope this demonstrates the point of this patch. ;)
diff --git a/tg-patch.sh b/tg-patch.sh
index 97338ab..c2f1b56 100644
--- a/tg-patch.sh
+++ b/tg-patch.sh
@@ -34,7 +34,7 @@ git diff-tree --name-only "$base_rev" "$name" |
fgrep -vx ".topdeps" |
fgrep -vx ".topmsg" >"$git_is_stupid" || : # fgrep likes to fail randomly?
if [ -s "$git_is_stupid" ]; then
- cat "$git_is_stupid" | xargs git diff --patch-with-stat "$base_rev" "$name" --
+ cat "$git_is_stupid" | xargs git --no-pager diff --no-color --patch-with-stat "$base_rev" "$name" --
else
echo "No changes."
fi
--
tg: (f17218e..) jf/patch-no-pager-and-color (depends on: master)
--
Jonas Fonseca
^ permalink raw reply related
* Re: [TopGit PATCH] README: Fix spelling
From: Jonas Fonseca @ 2008-11-20 13:52 UTC (permalink / raw)
To: madduck; +Cc: git
In-Reply-To: <1227189062-11951-1-git-send-email-fonseca@diku.dk>
Oops sorry about this one!!! :-/
On Thu, Nov 20, 2008 at 14:51, Jonas Fonseca <fonseca@diku.dk> wrote:
> Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
>
> ---
> README [m | 11 [32m+++++ [m [31m------ [m
> 1 files changed, 5 insertions(+), 6 deletions(-) [m
>
> [1mdiff --git a/README b/README [m
> [1mindex 5bfe3ee..9e291da 100644 [m
> [1m--- a/README [m
> [1m+++ b/README [m
> [36m@@ -22,7 +22,7 @@ version control of patches (reordering of patches is not [m
> version-controlled at all). But there are several disadvantages - [m
> for one, these tools (especially StGIT) do not actually fit well [m
> with plain Git at all: it is basically impossible to take advantage [m
> [31m-of the index efectively when using StGIT. But more importantly, [m
> [32m+ [m [32mof the index effectively when using StGIT. But more importantly, [m
> these tools horribly fail in the face of distributed environment. [m
> [m
> TopGit has been designed around three main tenets: [m
> [36m@@ -45,7 +45,7 @@ them. [m
> [m
> As mentioned above, the main intended use-case for TopGit is tracking [m
> third-party patches, where each patch is effectively a single topic [m
> [31m-branch. In order to flexibly accomodate even complex scenarios when [m
> [32m+ [m [32mbranch. In order to flexibly accommodate even complex scenarios when [m
> you track many patches where many are independent but some depend [m
> on others, TopGit ignores the ancient Quilt heritage of patch series [m
> and instead allows the patches to freely form graphs (DAGs just like [m
> [36m@@ -222,7 +222,7 @@ tg create [m
> [m
> After `tg create`, you should insert the patch description [m
> to the '.topmsg' file, which will already contain some [m
> [31m- pre-filled bits. You can set topgit.to, topgit.cc and topgit.bcc [m
> [32m+ [m [32mprefilled bits. You can set topgit.to, topgit.cc and topgit.bcc [m
> configuration variables in order to have `tg create` [m
> add these headers with given default values to '.topmsg'. [m
> [m
> [36m@@ -350,7 +350,7 @@ tg export [m
> in the cleaned up history (corresponding basically exactly [m
> to `tg patch` output for the topic branch). [m
> [m
> [31m- The command has two posible outputs now - either a Git branch [m
> [32m+ [m [32mThe command has two possible outputs now - either a Git branch [m
> with the collapsed history, or a quilt series in new directory. [m
> [m
> In case of producing collapsed history in new branch, [m
> [36m@@ -455,7 +455,6 @@ tg update [m
> [m
> TODO: tg update -a for updating all topic branches [m
> [m
> [31m-TODO: tg depend for adding/removing dependencies smoothly [m
> TODO: tg rename [m
> [m
> [m
> [36m@@ -485,7 +484,7 @@ whatever Cc headers you choose or the post-three-dashes message. [m
> When mailing out your patch, basically only few extra headers [m
> mail headers are inserted and the patch itself is appended. [m
> Thus, as your patches evolve, you can record nuances like whether [m
> [31m-the paricular patch should have To-list/Cc-maintainer or vice [m
> [32m+ [m [32mthe particular patch should have To-list/Cc-maintainer or vice [m
> versa and similar nuances, if your project is into that. [m
> From is prefilled from your current GIT_AUTHOR_IDENT, other headers [m
> can be prefilled from various optional topgit.* config options. [m
> --
> tg: (f17218e..) jf/readme-update (depends on: master)
>
--
Jonas Fonseca
^ permalink raw reply
* [TopGit PATCH] README: Fix spelling
From: Jonas Fonseca @ 2008-11-20 13:51 UTC (permalink / raw)
To: madduck; +Cc: git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
README^[[m | 11 ^[[32m+++++^[[m^[[31m------^[[m
1 files changed, 5 insertions(+), 6 deletions(-)^[[m
^[[1mdiff --git a/README b/README^[[m
^[[1mindex 5bfe3ee..9e291da 100644^[[m
^[[1m--- a/README^[[m
^[[1m+++ b/README^[[m
^[[36m@@ -22,7 +22,7 @@ version control of patches (reordering of patches is not^[[m
version-controlled at all). But there are several disadvantages -^[[m
for one, these tools (especially StGIT) do not actually fit well^[[m
with plain Git at all: it is basically impossible to take advantage^[[m
^[[31m-of the index efectively when using StGIT. But more importantly,^[[m
^[[32m+^[[m^[[32mof the index effectively when using StGIT. But more importantly,^[[m
these tools horribly fail in the face of distributed environment.^[[m
^[[m
TopGit has been designed around three main tenets:^[[m
^[[36m@@ -45,7 +45,7 @@ them.^[[m
^[[m
As mentioned above, the main intended use-case for TopGit is tracking^[[m
third-party patches, where each patch is effectively a single topic^[[m
^[[31m-branch. In order to flexibly accomodate even complex scenarios when^[[m
^[[32m+^[[m^[[32mbranch. In order to flexibly accommodate even complex scenarios when^[[m
you track many patches where many are independent but some depend^[[m
on others, TopGit ignores the ancient Quilt heritage of patch series^[[m
and instead allows the patches to freely form graphs (DAGs just like^[[m
^[[36m@@ -222,7 +222,7 @@ tg create^[[m
^[[m
After `tg create`, you should insert the patch description^[[m
to the '.topmsg' file, which will already contain some^[[m
^[[31m- pre-filled bits. You can set topgit.to, topgit.cc and topgit.bcc^[[m
^[[32m+^[[m ^[[32mprefilled bits. You can set topgit.to, topgit.cc and topgit.bcc^[[m
configuration variables in order to have `tg create`^[[m
add these headers with given default values to '.topmsg'.^[[m
^[[m
^[[36m@@ -350,7 +350,7 @@ tg export^[[m
in the cleaned up history (corresponding basically exactly^[[m
to `tg patch` output for the topic branch).^[[m
^[[m
^[[31m- The command has two posible outputs now - either a Git branch^[[m
^[[32m+^[[m ^[[32mThe command has two possible outputs now - either a Git branch^[[m
with the collapsed history, or a quilt series in new directory.^[[m
^[[m
In case of producing collapsed history in new branch,^[[m
^[[36m@@ -455,7 +455,6 @@ tg update^[[m
^[[m
TODO: tg update -a for updating all topic branches^[[m
^[[m
^[[31m-TODO: tg depend for adding/removing dependencies smoothly^[[m
TODO: tg rename^[[m
^[[m
^[[m
^[[36m@@ -485,7 +484,7 @@ whatever Cc headers you choose or the post-three-dashes message.^[[m
When mailing out your patch, basically only few extra headers^[[m
mail headers are inserted and the patch itself is appended.^[[m
Thus, as your patches evolve, you can record nuances like whether^[[m
^[[31m-the paricular patch should have To-list/Cc-maintainer or vice^[[m
^[[32m+^[[m^[[32mthe particular patch should have To-list/Cc-maintainer or vice^[[m
versa and similar nuances, if your project is into that.^[[m
From is prefilled from your current GIT_AUTHOR_IDENT, other headers^[[m
can be prefilled from various optional topgit.* config options.^[[m
--
tg: (f17218e..) jf/readme-update (depends on: master)
^ permalink raw reply
* Re: [PATCH v2] Updated Swedish translation (514t0f0u).
From: Alexander Gavrilov @ 2008-11-20 13:41 UTC (permalink / raw)
To: Peter Krefting
Cc: Andreas Ericsson, Shawn O. Pearce, Git Mailing List,
Mikael Magnusson
In-Reply-To: <Pine.LNX.4.64.0811201423291.1606@ds9.cixit.se>
On Thu, Nov 20, 2008 at 4:26 PM, Peter Krefting <peter@softwolves.pp.se> 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...
>
It is about the menu item called "Show History Context".
Alexander
^ permalink raw reply
* Re: git and mtime
From: Roger Leigh @ 2008-11-20 13:40 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Christian MICHON, git
In-Reply-To: <86iqqizgng.fsf@blue.stonehenge.com>
On Thu, Nov 20, 2008 at 05:11:15AM -0800, Randal L. Schwartz wrote:
> >>>>> "Roger" == Roger Leigh <rleigh@codelibre.net> writes:
>
> Roger> Except in this case I'm storing the content of *tarballs* (along with
> Roger> pristine-tar). I'm committing exactly what's in the tarball with
> Roger> no changes (this is a requirement). I can't change the source prior
> Roger> to commit.
>
> If you're not doing distributed source code development, why are you using
> git? It's hard to be angry at a screwdriver for not pounding in nails
> properly.
Err, it *is* being used for distributed development... of Debian
packaging. We track upstream releases on one branch, merge this
periodically onto the master branch containing the Debian packaging
infrastructure, and also have other bits such as a
continually-rebased patches branch to generate quilt patch series
from. I think you'll find we do actually need to use git.
> Sounds like you want rsync or something.
I think not! Perhaps if you read my original mail, you might
understand the reasoning behind this (whether you consider that
valid reasoning or not is another matter).
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
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