* Re: [PATCH] cg-object-id: comment the alternate id shortcut parsing
From: Petr Baudis @ 2005-12-07 22:05 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: git
In-Reply-To: <20051207213943.GC25890@diku.dk>
Dear diary, on Wed, Dec 07, 2005 at 10:39:43PM CET, I got a letter
where Jonas Fonseca <fonseca@diku.dk> said that...
> - # Short id's must be lower case and at least 4 digits.
> + # Short id's must be lower case and at least 4 digits. git-rev-parse(1)
> + # allows only down to 5 digits and we want to show the list of matched
> + # ids.
Huh. The code in sha1_name.c speaks differently and it works as well:
$ git-rev-parse b1fc
b1fcca45069d4f6b00a9ac7136be4268d09fd6b9
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* server-info dumbing-down
From: Petr Baudis @ 2005-12-07 21:58 UTC (permalink / raw)
To: git
Hello,
I've noticed few commits from Dec 4 landing into the git repository,
which remove various computations and corresponding lines from the
server info (3e15c67 and few ancestors). I'm curious about this - were
the computations that hugely computationally expensive? If not, wouldn't
it be better to leave it in for future use (since it doesn't cost a lot)
rather than making the future deployment of anything using this data
much harder since the server infos won't have it anymore?
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* Re: dotfile support
From: Petr Baudis @ 2005-12-07 21:51 UTC (permalink / raw)
To: Zack Brown; +Cc: Andreas Ericsson, git
In-Reply-To: <20051207161130.GA10924@tumblerings.org>
Dear diary, on Wed, Dec 07, 2005 at 05:11:30PM CET, I got a letter
where Zack Brown <zbrown@tumblerings.org> said that...
> So my question is, why does cg-init ignore dotfiles within the directory when it
> first initializes the repository?
Precisely for Linus' reasons - by default, I believe your VCS shouldn't
care about your hidden files, because they are hidden, and probably not
content but kind of meta-content - the exception is .gitignore, but you
can add more even on cg-init time. I have to admit that cg-init
documentation wasn't sufficiently clear about this autoignoring stuff,
I've tried to improve that now, and cg-init will warn you (post hoc)
that it autoignored some files.
Thanks,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
VI has two modes: the one in which it beeps and the one in which
it doesn't.
^ permalink raw reply
* [PATCH] cg-object-id: use git-rev-parse(1) for date parsing
From: Jonas Fonseca @ 2005-12-07 21:40 UTC (permalink / raw)
To: Petr Baudis, git
Using the --until switch, git-rev-parse(1) will first be given the ID. If it
cannot make sense of the ID fallback to using date(1).
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
The mixing of date parsing behaviours might be a little questionable,
but it's good to stay compatible with git.
commit 41447107236a7d23daa6ab0f40a0829935485bc8
tree 27863684c19e7f129304d2a1573c08f974126e2a
parent f0535e9952f1cace89d03649e8238aca69a6df44
author Jonas Fonseca <fonseca@diku.dk> Wed, 07 Dec 2005 22:16:50 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Wed, 07 Dec 2005 22:16:50 +0100
cg-object-id | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/cg-object-id b/cg-object-id
index ea04dca..baf096e 100755
--- a/cg-object-id
+++ b/cg-object-id
@@ -73,7 +73,14 @@ normalize_id()
fi
if [ "$id" != " " ] && [ ! "$valid" ]; then
- reqsecs=$(date --date="$id" +'%s' 2>/dev/null)
+ curtime=$(date +'%s' 2>/dev/null)
+ reqsecs=$(git-rev-parse --until="$id"); reqsecs=${reqsecs:10}
+
+ # git-rev-parse(1) will output the current time if the ID
+ # doesn't make sense. Workaround it so date(1) can have a try.
+ if [ "$curtime" -le "$reqsecs" ]; then
+ reqsecs=$(date --date="$id" +'%s' 2>/dev/null)
+ fi
if [ "$reqsecs" ]; then
id=$(git-rev-list --min-age=$reqsecs --max-count=1 HEAD)
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] cg-object-id: comment the alternate id shortcut parsing
From: Jonas Fonseca @ 2005-12-07 21:39 UTC (permalink / raw)
To: Petr Baudis, git
Add comment about why Cogito's own 4 digit id shortcut parser is needed.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 3c14cded46e110396127fc5b5e65883eb5cd60b9
tree 593da711de14cfc3f8dc1fd5773990902568b42e
parent 36c0d9fae209ab7fa889333e8eebef22e7f0f55c
author Jonas Fonseca <fonseca@diku.dk> Wed, 07 Dec 2005 08:17:04 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Wed, 07 Dec 2005 08:17:04 +0100
cg-object-id | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/cg-object-id b/cg-object-id
index 56d9f91..ea04dca 100755
--- a/cg-object-id
+++ b/cg-object-id
@@ -52,7 +52,9 @@ normalize_id()
id="$revid"
valid=1
- # Short id's must be lower case and at least 4 digits.
+ # Short id's must be lower case and at least 4 digits. git-rev-parse(1)
+ # allows only down to 5 digits and we want to show the list of matched
+ # ids.
elif [[ "$id" == [0-9a-f][0-9a-f][0-9a-f][0-9a-f]* ]]; then
idpref=${id:0:2}
idpost=${id:2}
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] cg-object-id: cleanup id verifying
From: Jonas Fonseca @ 2005-12-07 21:39 UTC (permalink / raw)
To: Petr Baudis, git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 36c0d9fae209ab7fa889333e8eebef22e7f0f55c
tree 364122ed83e2b920b0f0f5fe18c608a22aea6d07
parent 964e5ec2dd0ff3b073fbb9f3ad6f11c640a96a04
author Jonas Fonseca <fonseca@diku.dk> Wed, 07 Dec 2005 08:11:43 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Wed, 07 Dec 2005 08:11:43 +0100
cg-object-id | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/cg-object-id b/cg-object-id
index c7efa8a..56d9f91 100755
--- a/cg-object-id
+++ b/cg-object-id
@@ -50,6 +50,7 @@ normalize_id()
revid="$(git-rev-parse --verify "$id^0" 2>/dev/null)"
if [ "$revid" ]; then
id="$revid"
+ valid=1
# Short id's must be lower case and at least 4 digits.
elif [[ "$id" == [0-9a-f][0-9a-f][0-9a-f][0-9a-f]* ]]; then
@@ -60,8 +61,8 @@ normalize_id()
idmatch=($_git_objects/$idpref/$idpost*)
if [ ${#idmatch[*]} -eq 1 ] && [ -r "$idmatch" ]; then
- exid=$idpref${idmatch#$_git_objects/$idpref/}
- [ ${#exid} -eq 40 ] && [ "$(git-rev-parse --revs-only "$exid")" ] && id="$exid"
+ id=$idpref${idmatch#$_git_objects/$idpref/}
+ [ ${#id} -eq 40 ] && [ "$(git-rev-parse --revs-only "$id")" ] && valid=1
elif [ ${#idmatch[*]} -gt 1 ]; then
echo "Ambiguous id: $id" >&2
echo "${idmatch[@]}" >&2
@@ -69,13 +70,12 @@ normalize_id()
fi
fi
- valid=; [ ${#id} -eq 40 ] && [ "$(git-rev-parse --revs-only "$id")" ] && valid=1
- if ([ "$id" ] && [ "$id" != " " ]) && [ ! "$valid" ]; then
+ if [ "$id" != " " ] && [ ! "$valid" ]; then
reqsecs=$(date --date="$id" +'%s' 2>/dev/null)
if [ "$reqsecs" ]; then
id=$(git-rev-list --min-age=$reqsecs --max-count=1 HEAD)
- valid=; [ ${#id} -eq 40 ] && [ "$(git-rev-parse --revs-only "$id")" ] && valid=1
+ [ ${#id} -eq 40 ] && [ "$(git-rev-parse --revs-only "$id")" ] && valid=1
fi
fi
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Offload most of cg-object-id to git-rev-parse
From: Jonas Fonseca @ 2005-12-07 21:39 UTC (permalink / raw)
To: Petr Baudis, git
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
commit 964e5ec2dd0ff3b073fbb9f3ad6f11c640a96a04
tree 97f861c24303936f012523a54f3d53f4939ebf52
parent 554014e31b92c98b35f77b80b19f5b21e8a76cfc
author Jonas Fonseca <fonseca@diku.dk> Wed, 07 Dec 2005 07:44:26 +0100
committer Jonas Fonseca <fonseca@antimatter.localdomain> Wed, 07 Dec 2005 07:44:26 +0100
TODO | 2 --
cg-object-id | 29 +++++++++--------------------
2 files changed, 9 insertions(+), 22 deletions(-)
diff --git a/TODO b/TODO
index 0658b39..26bb4d0 100644
--- a/TODO
+++ b/TODO
@@ -27,8 +27,6 @@ cg-*patch should be pre-1.0.)
Includes merge-order cg-log and cg-diff checking for renames.
-* Offload most of cg-object-id to git-rev-parse
-
* Show only first 12 (or so) nibbles of the hashes everywhere
Even this might be too much, but more than this is really useless
for anyone remotely human. And it's less scary, too.
diff --git a/cg-object-id b/cg-object-id
index ec0362a..c7efa8a 100755
--- a/cg-object-id
+++ b/cg-object-id
@@ -40,27 +40,16 @@ deprecated_alias cg-object-id commit-id
normalize_id()
{
local id="$1"
+ local revid=
+ local valid=
- if [ "${id:(-1):1}" = "^" ]; then
- # find first parent
- normalize_id "${id%^}"
- normid=$(git-cat-file commit "$normid" | \
- awk '/^parent/{print $2; exit};/^$/{exit}') || exit 1
- type="commit"
- return
- fi
-
- if [ ! "$id" ] || [ "$id" = "this" ] || [ "$id" = "HEAD" ]; then
- read id < "$_git/$(git-symbolic-ref HEAD)"
-
- elif [ -r "$_git/refs/tags/$id" ]; then
- read id < "$_git/refs/tags/$id"
-
- elif [ -r "$_git/refs/heads/$id" ]; then
- read id < "$_git/refs/heads/$id"
+ if [ ! "$id" ] || [ "$id" = "this" ]; then
+ id=HEAD;
+ fi
- elif [ -r "$_git/refs/$id" ]; then
- read id < "$_git/refs/$id"
+ revid="$(git-rev-parse --verify "$id^0" 2>/dev/null)"
+ if [ "$revid" ]; then
+ id="$revid"
# Short id's must be lower case and at least 4 digits.
elif [[ "$id" == [0-9a-f][0-9a-f][0-9a-f][0-9a-f]* ]]; then
@@ -146,7 +135,7 @@ fi
if [ "$show_parent" ]; then
- git-cat-file commit "$normid" | awk '/^parent/{print $2};/^$/{exit}'
+ git-rev-parse "$normid^"
exit 0
fi
--
Jonas Fonseca
^ permalink raw reply related
* Re: Can GIT_EXEC_PATH behave more like PATH?
From: Junio C Hamano @ 2005-12-07 19:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4q5kra80.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> When users use "git frotz", the git command internally knows
> where the right version of subcommands are stored. When reason
> you would want to override that, you would exactly know one
> directory with which you want to override it. You do not want
> GIT_EXEC_PATH="/usr/lib/git-1.02:/usr/lib/git" in such a case,
> either.
OOPS. That did not parse so well. "... When you would want to
override that for whatever reason, you would..."
^ permalink raw reply
* Re: Can GIT_EXEC_PATH behave more like PATH?
From: Junio C Hamano @ 2005-12-07 19:14 UTC (permalink / raw)
To: Martin Atukunda; +Cc: git
In-Reply-To: <20051207141218.GA721@igloo.ds.co.ug>
Martin Atukunda <matlads@dsmagic.com> writes:
> I've been wondering if GIT_EXEC_PATH shouldn't be able to behave more
> like the PATH env. variable?
I do not think it is useful at all.
I think GIT_EXEC_PATH is useful only in two occasions. (1) When
Porcelains want to bypass "git" to avoid extra forking, it can
ask where the executables are just once to "git --exec-path",
and export GIT_EXEC_PATH with that single path; (2) When you
want to try out a freshly built git without installing, you can
export GIT_EXEC_PATH set, again with the single path that is
where the build directory is. Neither wants a list of
directories.
When users use "git frotz", the git command internally knows
where the right version of subcommands are stored. When reason
you would want to override that, you would exactly know one
directory with which you want to override it. You do not want
GIT_EXEC_PATH="/usr/lib/git-1.02:/usr/lib/git" in such a case,
either.
^ permalink raw reply
* Re: dotfile support
From: Junio C Hamano @ 2005-12-07 19:05 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20051207181924.GA21343@tumblerings.org>
Zack Brown <zbrown@tumblerings.org> writes:
>> You probably have missed it because unfortunately this commit
>> happened after the latest issue of git traffic ;-).
>
> Actually I've started including summaries of git list threads
> in Kernel Traffic as well, for the past few issues. :)
I was just trying to be funny. My apologies.
I do read kernel-traffic and appreciate your helping us keep
current very much.
^ permalink raw reply
* Re: [RFC] Run hooks with a cleaner environment
From: Junio C Hamano @ 2005-12-07 18:57 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0512071236260.25300@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Tue, 6 Dec 2005, Junio C Hamano wrote:
>
>> Daniel Barkalow <barkalow@iabervon.org> writes:
>>
>> > GIT_DIR is set to the repository that got the push,
>>
>> That is done by receive-pack; it chdir()s into the repository
>> and does its thing, and the hooks are called from there; I'd
>> expect cwd to be the repository ('.git'), GIT_DIR to be dot
>> ('.').
>
> I thought I was seeing the full path of the repository as GIT_DIR and I
> didn't check the cwd.
I do not do this myself, but I was wondering what would happen
if somebody has "export GIT_DIR=/var/filfre" in ~/.profile.
Well, I know what would happen, actually --- things would not
work when you do fetch/push because the tools want to use the
path given from the other end but the environment overrides it
with GIT_DIR.
^ permalink raw reply
* Re: Failure in t6021 on Red Hat Enterprise Linux 4
From: Junio C Hamano @ 2005-12-07 18:54 UTC (permalink / raw)
To: Mark Allen; +Cc: git
In-Reply-To: <20051207181225.67737.qmail@web34304.mail.mud.yahoo.com>
Mark Allen <mrallen1@yahoo.com> writes:
> So, basically the problem is that the subprocess.py module is
> in the compat directory, and by default (I think)..
Ah, you are right.
Just like we fix PATH and GIT_EXEC_PATH during the test
execution, we need to do something with PYTHONPATH environment
variable (this one is _without_ underscore), I think.
^ permalink raw reply
* Re: dotfile support
From: Zack Brown @ 2005-12-07 18:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vacfcu7jy.fsf@assigned-by-dhcp.cox.net>
On Wed, Dec 07, 2005 at 09:43:29AM -0800, Junio C Hamano wrote:
> Zack Brown <zbrown@tumblerings.org> writes:
>
> > What's the status of dotfile support? I can only find one thread that really
> > discusses the issue:
> >...
> > So that's my pitch: Leaving out dotfile support seems like it creates an
> > unnecessary limitation that eliminates some valid uses of git.
>
> Valid argument, and resolved thusly quite some time ago, with
> commit 320d3a1b1aa04d75f0aaff3cc7cf582e144a84c6 on May 24th
> 2005.
>
> You probably have missed it because unfortunately this commit
> happened after the latest issue of git traffic ;-).
Actually I've started including summaries of git list threads in Kernel Traffic
as well, for the past few issues. :)
Be well,
Zack
>
--
Zack Brown
^ permalink raw reply
* Re: Failure in t6021 on Red Hat Enterprise Linux 4
From: Mark Allen @ 2005-12-07 18:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfyp4u7rl.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> Are you using git RPM, or building by hand?
> If the latter, "grep -A2 python INSTALL" may be helpful.
Definitely. Thanks for the pointer -- I rebuilt my git installation with the correct
flag, but there's a bootstrapping problem with the test -- and I'm not a good enough
python programmer to fix it very well.
So, basically the problem is that the subprocess.py module is in the compat directory,
and by default (I think) the git-merge-recursive being tested is only looking in
$HOME/git/git.git where it finds and loads gitMergeCommon.py, but gitMergeCommon.py is
not looking in $HOME/git/git.git/compat which is where subprocess.py lives.
So I hacked in to git-merge-recursive this line at the top of the file
sys.path.append('''/home/mallen/git/git.git/compat''')
at the very top and now the test passes.
So maybe this points out a problem in the Makefile or in the substitution the Makefile is
using to put in @@GIT_PYTHON_PATH@@
I'm not sure I've clearly explained the issue, and like I said, I'm kind of a Python
baby, so I'm not sure what the best way to fix this problem might be.
Thanks,
--Mark
^ permalink raw reply
* Re: [RFC] Run hooks with a cleaner environment
From: Daniel Barkalow @ 2005-12-07 17:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7voe3tzqn8.fsf@assigned-by-dhcp.cox.net>
On Tue, 6 Dec 2005, Junio C Hamano wrote:
> Daniel Barkalow <barkalow@iabervon.org> writes:
>
> > GIT_DIR is set to the repository that got the push,
>
> That is done by receive-pack; it chdir()s into the repository
> and does its thing, and the hooks are called from there; I'd
> expect cwd to be the repository ('.git'), GIT_DIR to be dot
> ('.').
I thought I was seeing the full path of the repository as GIT_DIR and I
didn't check the cwd.
> I think doing the "unset GIT_DIR" to be the first thing if you
> want to access some other repository is documented somewhere but
> if not please send a patch to document it.
I didn't see it in the place "grep post-update Documentation/*" returned,
so we need something. (Actually, the main thing is to specify that nothing
else special is set, because the GIT_DIR thing was pretty obvious, but I
then didn't know if my problems were due to something else undocumented.)
> As to file descriptors, I think duping the output to original
> stderr might make sense, but I do not know what breaks, so
> interested parties may want to test it out and submit a tested
> patch for inclusion.
I'll send a patch tonight which works for me, but it should probably be
checked over by people who are good at this sort of stuff. I've got a
"/dev/null" patch; I'll look into a version that tries to find a
controlling tty (which could be really interesting, since you could then
have the hook get input from the user), or at least copy stderr if
possible.
For reference, the error I was getting was a broken pipe writing to stdout
(as git merge does somewhere) when I've pushed locally.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: dotfile support
From: Junio C Hamano @ 2005-12-07 17:43 UTC (permalink / raw)
To: Zack Brown; +Cc: git
In-Reply-To: <20051207145646.GA9207@tumblerings.org>
Zack Brown <zbrown@tumblerings.org> writes:
> What's the status of dotfile support? I can only find one thread that really
> discusses the issue:
>...
> So that's my pitch: Leaving out dotfile support seems like it creates an
> unnecessary limitation that eliminates some valid uses of git.
Valid argument, and resolved thusly quite some time ago, with
commit 320d3a1b1aa04d75f0aaff3cc7cf582e144a84c6 on May 24th
2005.
You probably have missed it because unfortunately this commit
happened after the latest issue of git traffic ;-).
^ permalink raw reply
* Re: Failure in t6021 on Red Hat Enterprise Linux 4
From: Junio C Hamano @ 2005-12-07 17:38 UTC (permalink / raw)
To: Mark Allen; +Cc: git
In-Reply-To: <20051207164909.24221.qmail@web34304.mail.mud.yahoo.com>
Mark Allen <mrallen1@yahoo.com> writes:
> Running t/t6021-crisscross-merge.sh -v -i on Red Hat Enterprise Linux 4 Workstation with
> python 2.3.4 installed, I found a fatal error in the test.
Are you using git RPM, or building by hand?
If the latter, "grep -A2 python INSTALL" may be helpful.
^ permalink raw reply
* Failure in t6021 on Red Hat Enterprise Linux 4
From: Mark Allen @ 2005-12-07 16:49 UTC (permalink / raw)
To: git
Running t/t6021-crisscross-merge.sh -v -i on Red Hat Enterprise Linux 4 Workstation with
python 2.3.4 installed, I found a fatal error in the test.
Apparently, this release of python doesn't have the subprocess module installed. In what
package is that located? How can I fix this error?
Thanks!
--Mark
-- BEGIN --
[mallen@mrhat t]$ rpm -q python
python-2.3.4-14.1
...SNIP...
git commit -m D8 file
Committing initial tree ec103796f9a6ca8367bd90cd88edf39c5dd2ae26
Trying really trivial in-index merge...
fatal: Merge requires file-level merging
Nope.
Traceback (most recent call last):
File "/home/mallen/git/git.git/t/../git-merge-recursive", line 13, in ?
from gitMergeCommon import *
File "/home/mallen/git/git.git/gitMergeCommon.py", line 18, in ?
import subprocess
ImportError: No module named subprocess
Automatic merge failed/prevented; fix up by hand
...SNIP...
--- END ---
^ permalink raw reply
* Re: [ANNOUNCE] GIT 0.99.9l aka 1.0rc4
From: Gerrit Pape @ 2005-12-07 16:20 UTC (permalink / raw)
To: git
In-Reply-To: <7vu0dnb8pm.fsf@assigned-by-dhcp.cox.net>
On Mon, Dec 05, 2005 at 12:16:37PM -0800, Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
> > On Sun, Dec 04, 2005 at 01:21:13AM -0800, Junio C Hamano wrote:
> >> *1* It appears Debian finally has an official maintainer, so I
> >
> > Yes, I've taken over maintainership, and introduced the git-core package
> > into Debian/unstable, the git tools previously were included in the
> > cogito package.
>
> This question is probably relevant only to you and people who
> want to build deb themselves until you package the updated
> upstream, but what is your (and others') preference on debian/
> directory in what _I_ ship?
>
> I see three possibilities:
>
> - Do not care, and keep them as they are as they bitrot.
>
> - Remove debian/ from the upstream tree.
>
> - You feed patches to me, and I promise you not to touch
> debian/ area, except adding a new -0 entry at the top of the
> changelog when bumping the version number up, and perhaps
> adjusting to the main Makefile changes if the solution is
> obvious.
>
> I am neutral between the second and the third.
Normally we suggest upstream to not ship a debian/ directory at all, and
I would prefer that. But I can understand that people may got used to
it, and prefer to build the packages on their own. So I'm also fine
with feeding you with patches, but need to get 0.99.9l into the Debian
archive first (already prepared, waiting in a 'new packages' queue), and
then adapt the build process to use the debian/ directory in the git
tarball, instead of the current tarball-in-tarball approach.
This may take some days, and there are major changes to the debian/
directory as I personally don't use the usual debhelper approach.
Thanks, Gerrit.
^ permalink raw reply
* Re: dotfile support
From: Zack Brown @ 2005-12-07 16:11 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4396FFB0.4040203@op5.se>
OK, I see my mistake.
I should have tested better. I started off with a non-versioned directory
containing dotfiles and regular files. I did a cg-init, only to discover
that the dotfiles were not included in the repository at that time. So I
just assumed they couldn't be added either.
But I just tested, and yes indeed, it is possible to cg-add a dotfile.
So my question is, why does cg-init ignore dotfiles within the directory when it
first initializes the repository?
Be well,
Zack
On Wed, Dec 07, 2005 at 04:28:48PM +0100, Andreas Ericsson wrote:
> Zack Brown wrote:
> >Hi,
> >
> >What's the status of dotfile support? I can only find one thread that
> >really
> >discusses the issue:
> >
>
> What sort of "dotfile support" are you hinting at? git being able to
> handle them, or git being able to ignore them? Both are implemented. The
> former by default and the latter through .gitignore.
>
> Files you want to version-control ofcourse has to be added with "git
> add", but that's not just dotfiles and it's really the only sane behaviour.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
> -
> 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
--
Zack Brown
^ permalink raw reply
* Re: dotfile support
From: Johannes Schindelin @ 2005-12-07 15:43 UTC (permalink / raw)
To: Zack Brown
Cc: David A. Wheeler, Linus Torvalds, Paul Jackson, Morten Welinder,
mj, git
In-Reply-To: <20051207145646.GA9207@tumblerings.org>
Hi,
On Wed, 7 Dec 2005, Zack Brown wrote:
> What's the status of dotfile support?
In the current git repository, ".gitignore" is a versioned file.
Hth,
Dscho
^ permalink raw reply
* Re: dotfile support
From: Andreas Ericsson @ 2005-12-07 15:28 UTC (permalink / raw)
To: git
In-Reply-To: <20051207145646.GA9207@tumblerings.org>
Zack Brown wrote:
> Hi,
>
> What's the status of dotfile support? I can only find one thread that really
> discusses the issue:
>
What sort of "dotfile support" are you hinting at? git being able to
handle them, or git being able to ignore them? Both are implemented. The
former by default and the latter through .gitignore.
Files you want to version-control ofcourse has to be added with "git
add", but that's not just dotfiles and it's really the only sane behaviour.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: dotfile support
From: Zack Brown @ 2005-12-07 14:56 UTC (permalink / raw)
To: David A. Wheeler; +Cc: Linus Torvalds, Paul Jackson, Morten Welinder, mj, git
In-Reply-To: <42628D1B.3000207@dwheeler.com>
Hi,
What's the status of dotfile support? I can only find one thread that really
discusses the issue:
On Sun, Apr 17, 2005 at 12:21:47PM -0400, David A. Wheeler wrote:
> Linus Torvalds wrote:
> >
> >On Sun, 17 Apr 2005, David A. Wheeler wrote:
> >
> ...
> >Also, I made a design decision that git only cares about non-dotfiles. Git
> >literally never sees or looks at _anything_ that starts with a ".". I
> >think that's absolutely the right thing to do for an SCM (if you hide your
> >files, I really don't think you should expect the SCM to see it), but it's
> >obviously not the right thing for a backup thing.
>
> Again, a command line flag or config file entry could change that
> in the future, if desired. So this is a decision that could be
> changed later... the best kind of decision :-).
Personally I like dotfile support, and I compare it to the language encoding
issue for filenames. Linus says we should treat filenames as binary data,
and thus it won't matter what characters someone uses. I agree completely,
but by not supporting dotfiles, we're creating a big exception, in that if
a filename begins with a dot, we treat it in a much different way, in fact
we ignore it completely.
In the above quote, Linus says "if you hide your files, I really don't think
you should expect the SCM to see it". But what about the case where the
user is not the one choosing to create dotfiles? If I want to put a bunch of
config files for various apps into a git repository, I don't get to pick their
names in many cases, at least not without changing the way I invoke my apps
(or the scripts that do it for me). But it's still worthwhile to have those
config files in version control. It makes it much easier to experiment with
new tools, recover from my mistakes, and share my successes with others.
So that's my pitch: Leaving out dotfile support seems like it creates an
unnecessary limitation that eliminates some valid uses of git.
Be well,
Zack
>
> --- David A. Wheeler
> -
> 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
--
Zack Brown
^ permalink raw reply
* Re: ssh removed?
From: Nico -telmich- Schottelius @ 2005-12-07 14:43 UTC (permalink / raw)
To: Petr Baudis; +Cc: git list
In-Reply-To: <20051207142938.GD26574@schottelius.org>
[-- Attachment #1: Type: text/plain, Size: 1252 bytes --]
Nico -telmich- Schottelius [Wed, Dec 07, 2005 at 03:29:39PM +0100]:
> [...]
>
> I am trying to get git with git-0.99.8, is that impossible currently?
>
I upgraded to 0.99.9i and the following happens when I clone:
[15:42] hydrogenium:~nico# ./update-git+cogito.sh
Working on git (in /home/user/nico/build/git) ...
Cloning git
defaulting to local storage area
Fetching head...
Fetching objects...
progress: 3 objects, 6382 bytes
Getting alternates list for http://www.kernel.org/pub/scm/git/git.git/
progress: 33 objects, 82462 bytes
Getting pack list for http://www.kernel.org/pub/scm/git/git.git/
Getting index for pack 46ff81b11ed16ed38caa4aada913cb08c00185b2
Getting pack 46ff81b11ed16ed38caa4aada913cb08c00185b2
which contains 8a6bd02d4ff1628af4c47d8c0c35d835607832d1
error: Unable to find 6ff87c4664981e4397625791c8ea3bbb5f2279a3 under http://www.kernel.org/pub/scm/git/git.git/
Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3
while processing commit e23eff8be92a2a2cb66b53deef020063cff285ed.
cg-fetch: objects fetch failed
cg-clone: fetch failed
Nico
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ permalink raw reply
* Re: ssh removed?
From: Nico -telmich- Schottelius @ 2005-12-07 14:29 UTC (permalink / raw)
To: Petr Baudis; +Cc: git list
In-Reply-To: <20051206232945.GJ22159@pasky.or.cz>
[-- Attachment #1: Type: text/plain, Size: 2724 bytes --]
Petr Baudis [Wed, Dec 07, 2005 at 12:29:45AM +0100]:
> Dear diary, on Tue, Dec 06, 2005 at 10:19:18PM CET, I got a letter
> where Nico -telmich- Schottelius <nico-linux-git@schottelius.org> said that...
> > Did somebody remove git+ssh in git? If I search for ssh in cg-log
> > in the git source I do not see any hint. But I see that when trying to
> > use it:
> ..snip..
> > [22:16] hydrogenium:ccollect.sh% cg-version
> > cogito-0.17pre.GIT (c10cc1d2a99b01ed3bf45d5f2ad6157940a22365)
> > [22:17] hydrogenium:ccollect.sh% git --version
> > git version 0.99.8.GIT
>
> Quite on the contrary, your GIT is too old - at least 0.99.9 is required
> as noted in the INSTALL file.
And I found the problem's source now:
[15:23] hydrogenium:git# cg-update
Recovering from a previously interrupted fetch...
Fetching head...
Fetching objects...
error: The requested URL returned error: 404
Getting pack list
Getting alternates list
error: Unable to find a0adb3dcb345a380e1b6f2208feff4f61499e0d3 under http://www.kern
el.org/pub/scm/git/git.git/
--> git was not updated from update-git+cogito.sh!
Now I try to update it, after I removed the git source direcotry:
[15:24] hydrogenium:build# rm -rf ~nico/build/git
[15:24] hydrogenium:build# ~nico/update-git+cogito.sh
Working on git (in /home/user/nico/build/git) ...
Cloning git
defaulting to local storage area
Fetching head...
Fetching objects...
progress: 3 objects, 6382 bytes
error: The requested URL returned error: 404
Getting pack list
Getting index for pack 46ff81b11ed16ed38caa4aada913cb08c00185b2
Getting pack 46ff81b11ed16ed38caa4aada913cb08c00185b2
which contains 8a6bd02d4ff1628af4c47d8c0c35d835607832d1
error: The requested URL returned error: 404
Getting alternates list
error: Unable to find 6ff87c4664981e4397625791c8ea3bbb5f2279a3 under http://www.kernel.org/pub/scm/git/git.git/
I am trying to get git with git-0.99.8, is that impossible currently?
I am wondering why it gets a 404, the url I use for git is
http://www.kernel.org/pub/scm/git/git.git
for cogito is
http://www.kernel.org/pub/scm/cogito/cogito.git
Nico
--
Latest project: cinit-0.2.1 (http://linux.schottelius.org/cinit/)
Open Source nutures open minds and free, creative developers.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 827 bytes --]
^ 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