* [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
* Can GIT_EXEC_PATH behave more like PATH?
From: Martin Atukunda @ 2005-12-07 14:12 UTC (permalink / raw)
To: git
Hi,
I've been wondering if GIT_EXEC_PATH shouldn't be able to behave more
like the PATH env. variable?
it would allow for instance something like:
GIT_EXEC_PATH=/git/core:/usr/local/git/potty:/usr/lib/git
and naturally git <command> would do the correct thing given.
if so, definetly post 1.0 stuff.
any ideas?
- Martin -
--
Due to a shortage of devoted followers, the production of great leaders has been discontinued.
^ permalink raw reply
* [PATCH 3/3] update-index: allow --index-info to add higher stages.
From: Junio C Hamano @ 2005-12-07 10:01 UTC (permalink / raw)
To: git; +Cc: Fredrik Kuivinen
In-Reply-To: <20051202083652.GA4824@c165.ib.student.liu.se>
The new merge world order tells the merge strategies to leave
the cache unmerged and store the automerge result in the working
tree if automerge is not clean. This was done for the resolve
strategy and recursive strategy when no rename is involved, but
recording a conflicting merge in the rename case could not
easily be done by the recursive strategy.
This commit adds a new input format, in addition to the exsting
two, to "update-index --index-info".
(1) mode SP sha1 TAB path
The first format is what "git-apply --index-info"
reports, and used to reconstruct a partial tree
that is used for phony merge base tree when falling
back on 3-way merge.
(2) mode SP type SP sha1 TAB path
The second format is to stuff git-ls-tree output
into the index file.
(3) mode SP sha1 SP stage TAB path
This format is to put higher order stages into the
index file and matches git-ls-files --stage output.
To place a higher stage entry to the index, the path should
first be removed by feeding a mode=0 entry for the path, and
then feeding necessary input lines in the (3) format.
For example, starting with this index:
$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz
$ git update-index --index-info ;# interactive session -- input follows...
0 0000000000000000000000000000000000000000 frotz
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
The first line of the input feeds 0 as the mode to remove the
path; the SHA1 does not matter as long as it is well formatted.
Then the second and third line feeds stage 1 and stage 2 entries
for that path. After the above, we would end up with this:
$ git ls-files -s
100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
This completes the groundwork for the new merge world order.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-update-index.txt | 57 +++++++++++++++++++++++++++++++++
update-index.c | 63 ++++++++++++++++++++++++++----------
2 files changed, 103 insertions(+), 17 deletions(-)
d23748a6af3e3db2b239090553f92c3a779b3578
diff --git a/Documentation/git-update-index.txt b/Documentation/git-update-index.txt
index e4678cd..c74311d 100644
--- a/Documentation/git-update-index.txt
+++ b/Documentation/git-update-index.txt
@@ -136,6 +136,63 @@ in the database but the file isn't avail
useful when the file is available, but you do not wish to update the
object database.
+
+Using --index-info
+------------------
+
+`--index-info` is a more powerful mechanism that lets you feed
+multiple entry definitions from the standard input, and designed
+specifically for scripts. It can take inputs of three formats:
+
+ . mode SP sha1 TAB path
++
+The first format is what "git-apply --index-info"
+reports, and used to reconstruct a partial tree
+that is used for phony merge base tree when falling
+back on 3-way merge.
+
+ . mode SP type SP sha1 TAB path
++
+The second format is to stuff git-ls-tree output
+into the index file.
+
+ . mode SP sha1 SP stage TAB path
++
+This format is to put higher order stages into the
+index file and matches git-ls-files --stage output.
+
+To place a higher stage entry to the index, the path should
+first be removed by feeding a mode=0 entry for the path, and
+then feeding necessary input lines in the third format.
+
+For example, starting with this index:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 0 frotz
+------------
+
+you can feed the following input to `--index-info`:
+
+------------
+$ git update-index --index-info
+0 0000000000000000000000000000000000000000 frotz
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
+------------
+
+The first line of the input feeds 0 as the mode to remove the
+path; the SHA1 does not matter as long as it is well formatted.
+Then the second and third line feeds stage 1 and stage 2 entries
+for that path. After the above, we would end up with this:
+
+------------
+$ git ls-files -s
+100644 8a1218a1024a212bb3db30becd860315f9f3ac52 1 frotz
+100755 8a1218a1024a212bb3db30becd860315f9f3ac52 2 frotz
+------------
+
+
Examples
--------
To update and refresh only the files already checked out:
diff --git a/update-index.c b/update-index.c
index 11b7f6a..be87b99 100644
--- a/update-index.c
+++ b/update-index.c
@@ -256,35 +256,30 @@ inside:
}
}
-static int add_cacheinfo(const char *arg1, const char *arg2, const char *arg3)
+static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
+ const char *path, int stage)
{
int size, len, option;
- unsigned int mode;
- unsigned char sha1[20];
struct cache_entry *ce;
- if (sscanf(arg1, "%o", &mode) != 1)
- return -1;
- if (get_sha1_hex(arg2, sha1))
- return -1;
- if (!verify_path(arg3))
+ if (!verify_path(path))
return -1;
- len = strlen(arg3);
+ len = strlen(path);
size = cache_entry_size(len);
ce = xmalloc(size);
memset(ce, 0, size);
memcpy(ce->sha1, sha1, 20);
- memcpy(ce->name, arg3, len);
- ce->ce_flags = htons(len);
+ memcpy(ce->name, path, len);
+ ce->ce_flags = create_ce_flags(len, stage);
ce->ce_mode = create_ce_mode(mode);
option = allow_add ? ADD_CACHE_OK_TO_ADD : 0;
option |= allow_replace ? ADD_CACHE_OK_TO_REPLACE : 0;
if (add_cache_entry(ce, option))
return error("%s: cannot add to the index - missing --add option?",
- arg3);
- report("add '%s'", arg3);
+ path);
+ report("add '%s'", path);
return 0;
}
@@ -342,7 +337,24 @@ static void read_index_info(int line_ter
char *path_name;
unsigned char sha1[20];
unsigned int mode;
+ int stage;
+ /* This reads lines formatted in one of three formats:
+ *
+ * (1) mode SP sha1 TAB path
+ * The first format is what "git-apply --index-info"
+ * reports, and used to reconstruct a partial tree
+ * that is used for phony merge base tree when falling
+ * back on 3-way merge.
+ *
+ * (2) mode SP type SP sha1 TAB path
+ * The second format is to stuff git-ls-tree output
+ * into the index file.
+ *
+ * (3) mode SP sha1 SP stage TAB path
+ * This format is to put higher order stages into the
+ * index file and matches git-ls-files --stage output.
+ */
read_line(&buf, stdin, line_termination);
if (buf.eof)
break;
@@ -354,9 +366,19 @@ static void read_index_info(int line_ter
tab = strchr(ptr, '\t');
if (!tab || tab - ptr < 41)
goto bad_line;
+
+ if (tab[-2] == ' ' && '1' <= tab[-1] && tab[-1] <= '3') {
+ stage = tab[-1] - '0';
+ ptr = tab + 1; /* point at the head of path */
+ tab = tab - 2; /* point at tail of sha1 */
+ }
+ else {
+ stage = 0;
+ ptr = tab + 1; /* point at the head of path */
+ }
+
if (get_sha1_hex(tab - 40, sha1) || tab[-41] != ' ')
goto bad_line;
- ptr = tab + 1;
if (line_termination && ptr[0] == '"')
path_name = unquote_c_style(ptr, NULL);
@@ -382,7 +404,7 @@ static void read_index_info(int line_ter
* ptr[-41] is at the beginning of sha1
*/
ptr[-42] = ptr[-1] = 0;
- if (add_cacheinfo(buf.buf, ptr-41, path_name))
+ if (add_cacheinfo(mode, sha1, path_name, stage))
die("git-update-index: unable to update %s",
path_name);
}
@@ -449,10 +471,17 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(path, "--cacheinfo")) {
+ unsigned char sha1[20];
+ unsigned int mode;
+
if (i+3 >= argc)
die("git-update-index: --cacheinfo <mode> <sha1> <path>");
- if (add_cacheinfo(argv[i+1], argv[i+2], argv[i+3]))
- die("git-update-index: --cacheinfo cannot add %s", argv[i+3]);
+
+ if ((sscanf(argv[i+1], "%o", &mode) != 1) ||
+ get_sha1_hex(argv[i+2], sha1) ||
+ add_cacheinfo(mode, sha1, argv[i+3], 0))
+ die("git-update-index: --cacheinfo"
+ " cannot add %s", argv[i+3]);
i += 3;
continue;
}
--
0.99.9.GIT
^ permalink raw reply related
* [PATCH 1/3] checkout-index: allow checking out from higher stages.
From: Junio C Hamano @ 2005-12-07 10:01 UTC (permalink / raw)
To: git
The new option, --stage=<n>, lets you copy out from an unmerged,
higher stage. This is to help the new merge world order during
a nontrivial merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
Documentation/git-checkout-index.txt | 6 +++
checkout-index.c | 61 ++++++++++++++++++++++++----------
2 files changed, 48 insertions(+), 19 deletions(-)
3bd348aeea24709cd9be4b9d741f79b6014cd7e3
diff --git a/Documentation/git-checkout-index.txt b/Documentation/git-checkout-index.txt
index 97eef22..9f32c65 100644
--- a/Documentation/git-checkout-index.txt
+++ b/Documentation/git-checkout-index.txt
@@ -9,7 +9,7 @@ git-checkout-index - Copy files from the
SYNOPSIS
--------
'git-checkout-index' [-u] [-q] [-a] [-f] [-n] [--prefix=<string>]
- [--] <file>...
+ [--stage=<number>] [--] <file>...
DESCRIPTION
-----------
@@ -40,6 +40,10 @@ OPTIONS
When creating files, prepend <string> (usually a directory
including a trailing /)
+--stage=<number>::
+ Instead of checking out unmerged entries, copy out the
+ files from named stage. <number> must be between 1 and 3.
+
--::
Do not interpret any more arguments as options.
diff --git a/checkout-index.c b/checkout-index.c
index f1e716d..1e1c972 100644
--- a/checkout-index.c
+++ b/checkout-index.c
@@ -36,6 +36,7 @@
static const char *prefix;
static int prefix_length;
+static int checkout_stage; /* default to checkout stage0 */
static struct checkout state = {
.base_dir = "",
@@ -48,20 +49,36 @@ static struct checkout state = {
static int checkout_file(const char *name)
{
- int pos = cache_name_pos(name, strlen(name));
- if (pos < 0) {
- if (!state.quiet) {
- pos = -pos - 1;
- fprintf(stderr,
- "git-checkout-index: %s is %s.\n",
- name,
- (pos < active_nr &&
- !strcmp(active_cache[pos]->name, name)) ?
- "unmerged" : "not in the cache");
- }
- return -1;
+ int namelen = strlen(name);
+ int pos = cache_name_pos(name, namelen);
+ int has_same_name = 0;
+
+ if (pos < 0)
+ pos = -pos - 1;
+
+ while (pos < active_nr) {
+ struct cache_entry *ce = active_cache[pos];
+ if (ce_namelen(ce) != namelen &&
+ memcmp(ce->name, name, namelen))
+ break;
+ has_same_name = 1;
+ if (checkout_stage == ce_stage(ce))
+ return checkout_entry(ce, &state);
+ pos++;
+ }
+
+ if (!state.quiet) {
+ fprintf(stderr, "git-checkout-index: %s ", name);
+ if (!has_same_name)
+ fprintf(stderr, "is not in the cache");
+ else if (checkout_stage)
+ fprintf(stderr, "does not exist at stage %d",
+ checkout_stage);
+ else
+ fprintf(stderr, "is unmerged");
+ fputc('\n', stderr);
}
- return checkout_entry(active_cache[pos], &state);
+ return -1;
}
static int checkout_all(void)
@@ -70,11 +87,11 @@ static int checkout_all(void)
for (i = 0; i < active_nr ; i++) {
struct cache_entry *ce = active_cache[i];
- if (ce_stage(ce))
+ if (ce_stage(ce) != checkout_stage)
continue;
if (prefix && *prefix &&
- ( ce_namelen(ce) <= prefix_length ||
- memcmp(prefix, ce->name, prefix_length) ))
+ (ce_namelen(ce) <= prefix_length ||
+ memcmp(prefix, ce->name, prefix_length)))
continue;
if (checkout_entry(ce, &state) < 0)
errs++;
@@ -88,7 +105,7 @@ static int checkout_all(void)
}
static const char checkout_cache_usage[] =
-"git-checkout-index [-u] [-q] [-a] [-f] [-n] [--prefix=<string>] [--] <file>...";
+"git-checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]] [--prefix=<string>] [--] <file>...";
static struct cache_file cache_file;
@@ -138,11 +155,19 @@ int main(int argc, char **argv)
die("cannot open index.lock file.");
continue;
}
- if (!memcmp(arg, "--prefix=", 9)) {
+ if (!strncmp(arg, "--prefix=", 9)) {
state.base_dir = arg+9;
state.base_dir_len = strlen(state.base_dir);
continue;
}
+ if (!strncmp(arg, "--stage=", 8)) {
+ int ch = arg[8];
+ if ('1' <= ch && ch <= '3')
+ checkout_stage = arg[8] - '0';
+ else
+ die("stage should be between 1 and 3");
+ continue;
+ }
if (arg[0] == '-')
usage(checkout_cache_usage);
break;
--
0.99.9.GIT
^ permalink raw reply related
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