* Re: use binmode(STDOUT) in git-status
From: H. Peter Anvin @ 2005-11-28 16:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Alex Riesen, git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.63.0511281700100.11362@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
>
> Of course, here is the problem: git on Windows runs only using cygwin. You
> can specify the line ending behaviour of cygwin (I think it is an env
> variable). Activision Perl, being independent of cygwin, does not care
> about that setting.
>
> So, to be accurate, you'd have to check what *cygwin* expects, and
> depending on that execute binmode(STDOUT) or not.
>
Makes sense, I guess... except if you're running Cygwin, wouldn't
Cygwin's Perl make a lot more sense?
-hpa
^ permalink raw reply
* Re: use binmode(STDOUT) in git-status
From: Johannes Schindelin @ 2005-11-28 16:02 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Alex Riesen, git, Junio C Hamano
In-Reply-To: <438B2859.6060109@zytor.com>
Hi,
On Mon, 28 Nov 2005, H. Peter Anvin wrote:
> Alex Riesen wrote:
> > Activision's Perl generates CRLF unless STDOUT is binmoded, which is
> > inconsistent with other output of git-status.
> >
> > ---
> > I assume none _sane_ can want CRLF as line-ending...
>
> Well, if it's a text file we probably should use platform-native line-ending,
> and at least be tolerant of \r\n.
Of course, here is the problem: git on Windows runs only using cygwin. You
can specify the line ending behaviour of cygwin (I think it is an env
variable). Activision Perl, being independent of cygwin, does not care
about that setting.
So, to be accurate, you'd have to check what *cygwin* expects, and
depending on that execute binmode(STDOUT) or not.
Ciao,
Dscho
^ permalink raw reply
* Re: use binmode(STDOUT) in git-status
From: H. Peter Anvin @ 2005-11-28 15:55 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Junio C Hamano
In-Reply-To: <81b0412b0511272334w393434e7lad3e3b102e6c3e9e@mail.gmail.com>
Alex Riesen wrote:
> Activision's Perl generates CRLF unless STDOUT is binmoded, which is
> inconsistent with other output of git-status.
>
> ---
> I assume none _sane_ can want CRLF as line-ending...
Well, if it's a text file we probably should use platform-native
line-ending, and at least be tolerant of \r\n.
-hpa
^ permalink raw reply
* Re: Generic configuration plumbing (Was: Re: [RFC 2/2] Automatically transform...)
From: Johannes Schindelin @ 2005-11-28 15:26 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git, Andreas Ericsson
In-Reply-To: <200511281532.36054.Josef.Weidendorfer@gmx.de>
Hi,
On Mon, 28 Nov 2005, Josef Weidendorfer wrote:
> On Monday 28 November 2005 14:11, Andreas Ericsson wrote:
> > Josef Weidendorfer wrote:
> > >
> > > To allow for this, git_config() should not be hardcoded to only
> > > read .git/config, but perhaps a list of files in environment variable
> > > GIT_CONFIG_FILES.
> > >
> >
> > $HOME/.gitrc:$GIT_DIR/conf/*
>
> Yes, perhaps with this as default...
>
> > All files could support the freestanding "include" syntax.
>
> Better run cpp on the config files before loading ;-)
> Or provide a hook which returns the config on stdout.
> The default for .git/hooks/config would be
>
> cat $GIT_DIR/config
>
> Hmm... this was only meant to be a joke; but now I actually think
> this is a nice idea as basic configuration mechanism of git plumbing.
The longer I read this thread the more I *positively* *hate* to have
started it.
People, I wanted simplification. And you ask instead for every feature and
his dog, and could I have fries with that?
KISS!
I *don't* want split config files. Why? Because it buys you only confusion
and complication. If you want to group variables, do so with sections (BTW
that's what they were designed for).
I am perfectly okay when somebody says that I should leave things as they
are and not fsck around with configuration. The impression I get is that
you want to force me to admit that I was wrong from the start.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Josef Weidendorfer @ 2005-11-28 15:03 UTC (permalink / raw)
To: git; +Cc: Petr Baudis
In-Reply-To: <20051128134808.GQ22159@pasky.or.cz>
On Monday 28 November 2005 14:48, Petr Baudis wrote:
> Dear diary, on Mon, Nov 28, 2005 at 01:59:04PM CET, I got a letter
> where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> > (2) project config (in .git/project.conf)
>
> What are you going to keep in it? There isn't much of stuff which is not
> per-user or per-instance. I can't think of anything now, but there is no
> list of configuration variables to check yet.
Project global configurations could be:
- .git/info
- .git/hooks
- default for encoding of commit messages
- relationship of public project branches (perhaps access rights)
- project description, maintainers, public branch descriptions
- central repository URL
- ...
> (Upstream maintainer email is interesting, OTOH it alone doesn't seem to
> justify the mechanism by itself; also, the upstreams may be different
> based on where you cloned the project from, etc.)
Hmm.. this even could be seen as another level: origin specific
> > For (2), git-clone should copy some files, e.g. the .git/project.conf
> > or .git/info/exclude. But project config probably should be kept
> > up to date among all repositories for a project, i.e. it should be
> > version controlled itself, but independent from the project.
> > We could use a project config head .git/refs/projectconfig for this;
> > of course post-1.0 material.
>
> If you still want per-project config, why should it be independent from
> the project? Actually, like you have .gitignore, having something like
> .gitconfig
That doesn't work well with configuration which should be global to the
whole history of the original project, e.g. .git/info/exclude, or maintainer
information.
> in project root would be by far the simplest - if you want
> separate head, your merging and stuff gets quite more complicated, as
> well as actually branching the project config, etc.
Project configuration probably always should be up to date, so:
* always update when fetching/pulling project branches
* always push when pushing project branches
Josef
^ permalink raw reply
* rebase problems
From: Sven Verdoolaege @ 2005-11-28 14:58 UTC (permalink / raw)
To: Junio C Hamano, git
Recently, rebasing has stopped working for me.
Here is an example:
bash-3.00$ git-show-branch origin HEAD
! [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
! [HEAD] propagate LinearizationType typo fix.
--
+ [HEAD] propagate LinearizationType typo fix.
+ [HEAD^] LinearizationType: typo
+ [HEAD~2] espam::DecomposeChannels: actually decompose the channel if valid.
+ [HEAD~3] DecomposeChannels: split channel and check whether result is a pair of fifos.
+ [HEAD~4] Use proper class for LinearizationType.
+ [HEAD~5] espam/../DecomposeChannels: partial implementation.
+ [HEAD~6] espam: add flag for channel decomposition.
+ [origin] fix in which we remove the definition of index statements that are *not* used in the control vector
++ [HEAD~7] espam/../IndexVector::toString: include contents of IndexVector.
bash-3.00$ git rebase origin
Applying 'espam::DecomposeChannels: actually decompose the channel if valid.'
error: pa/espam/operations/transformations/DecomposeChannels.java: does not exist in index
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Trying simple merge.
Simple merge failed, trying Automatic merge.
ERROR: pa/espam/operations/transformations/DecomposeChannels.java: Not handling case 09322db769adbc03bfd4f3ac2720c6d1db5a85b1 -> -> 32da8b1de4205c4adb0da50648a0a00d60b67582
fatal: merge program failed
Failed to merge in the changes.
Patch failed at 0007.
0001-espam-add-flag-for-channel-decomposition.txt
I'm not sure what rebase is doing here, but the only change in origin
modified a file untouched by the changes in HEAD, so there shouldn't
be any conflict whatsoever.
Apparently it's trying to apply the change in HEAD~2 without having
applied the earlier changes (which and the file named above).
skimo
PS: I'll try and look into the gitk thing this evening.
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Randal L. Schwartz @ 2005-11-28 14:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051128143428.GS22159@pasky.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> Could you patch cg-push like
[yes]
Here's the result:
localhost:~/Projects/git/Play % rm -rf *git
localhost:~/Projects/git/Play % cg-admin-setuprepo remote.git
localhost:~/Projects/git/Play % mkdir local.git
localhost:~/Projects/git/Play % cd local.git
localhost:..git/Play/local.git % cg-init -minitial
defaulting to local storage area
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed as 06223ad471c4f1c60da364310d1dd71a91310346.
localhost:..git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
localhost:..git/Play/local.git % cg-branch-ls
origin /Users/merlyn/Projects/git/Play/remote.git#master
localhost:..git/Play/local.git % cg-push
using /Users/merlyn/Projects/git/Play/remote.git#master
now using /Users/merlyn/Projects/git/Play/remote.git
matched ':' in '/Users/merlyn/Projects/git/Play/remote.git'?
WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
ssh: \033]2;[zsh] localhost: No address associated with nodename
fatal: unexpected EOF
Well, that's curious, eh?
However, I get this:
localhost:..git/Play/local.git % echo "/Users/merlyn/Projects/git/Play/remote.git" | grep -q ":"
localhost:..git/Play/local.git % echo $status
1
So, perhaps the "bash" on this system is broken for that elif chain?
localhost:..git/Play/local.git % bash --version
GNU bash, version 2.05b.0(1)-release (powerpc-apple-darwin8.0)
Copyright (C) 2002 Free Software Foundation, Inc.
Gah. Yet Another Hidden Dependency.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Petr Baudis @ 2005-11-28 14:34 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86zmno6g3v.fsf@blue.stonehenge.com>
Dear diary, on Mon, Nov 28, 2005 at 02:45:24PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> >>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
>
> Petr> It would sure be bad if this was the case. However I'm really sorry, but
> Petr> I still can't reproduce it.
>
> Reproduce by this:
>
> localhost:~/Projects/Git/Play % cg-admin-setuprepo remote.git
> localhost:~/Projects/Git/Play % mkdir local.git
> localhost:~/Projects/Git/Play % cd local.git
> localhost:..Git/Play/local.git % cg-init -minitial
> defaulting to local storage area
> Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
> Committed as 958ed484382609786ca9ae611cc54802cb7697a9.
> localhost:..Git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
> localhost:..Git/Play/local.git % cg-push
> WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
> WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
> ssh: \033]2;[zsh] localhost: No address associated with nodename
> fatal: unexpected EOF
Still works for me.
Could you patch cg-push like
diff --git a/cg-push b/cg-push
index 1d59422..bdab3b8 100755
--- a/cg-push
+++ b/cg-push
@@ -47,6 +47,7 @@ name=${ARGS[0]}
[ "$name" ] || { [ -s $_git/branches/origin ] && name=origin; }
[ "$name" ] || die "where to push to?"
uri=$(cat "$_git/branches/$name" 2>/dev/null) || die "unknown branch: $name"
+echo "using $uri"
rembranch=master
sprembranch=
@@ -54,6 +55,7 @@ if echo "$uri" | grep -q '#'; then
rembranch=$(echo $uri | cut -d '#' -f 2)
sprembranch=":$rembranch"
uri=$(echo $uri | cut -d '#' -f 1)
+ echo "now using $uri"
fi
if echo "$uri" | grep -q "^http://"; then
@@ -63,6 +65,7 @@ elif echo "$uri" | grep -q "^git+ssh://"
elif echo "$uri" | grep -q "^rsync://"; then
die "pushing over rsync not supported"
elif echo "$uri" | grep -q ":"; then
+ echo "matched ':' in $uri ?!"
echo "WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol."
echo "WARNING: The host:path syntax is evil because it is implicit. Please just use a URI."
send_pack_update "$name" "$uri" $_git_head$sprembranch "${tags[@]}"
please?
(We are a bit careless about quoting here, which I will fix now,
but that shouldn't be the problem.)
--
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 related
* Generic configuration plumbing (Was: Re: [RFC 2/2] Automatically transform...)
From: Josef Weidendorfer @ 2005-11-28 14:32 UTC (permalink / raw)
To: git; +Cc: Andreas Ericsson
In-Reply-To: <438B021F.5030204@op5.se>
On Monday 28 November 2005 14:11, Andreas Ericsson wrote:
> Josef Weidendorfer wrote:
> >
> > To allow for this, git_config() should not be hardcoded to only
> > read .git/config, but perhaps a list of files in environment variable
> > GIT_CONFIG_FILES.
> >
>
> $HOME/.gitrc:$GIT_DIR/conf/*
Yes, perhaps with this as default...
> All files could support the freestanding "include" syntax.
Better run cpp on the config files before loading ;-)
Or provide a hook which returns the config on stdout.
The default for .git/hooks/config would be
cat $GIT_DIR/config
Hmm... this was only meant to be a joke; but now I actually think
this is a nice idea as basic configuration mechanism of git plumbing.
Josef
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Randal L. Schwartz @ 2005-11-28 13:59 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <86zmno6g3v.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> localhost:..Git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
Randal> localhost:..Git/Play/local.git % cg-push
Randal> WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
Randal> WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
Randal> ssh: \033]2;[zsh] localhost: No address associated with nodename
Randal> fatal: unexpected EOF
Oh, and make sure ssh is *off* on your machine. You might be getting
it to work by ssh'ing back to your own box.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Petr Baudis @ 2005-11-28 13:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0511280248020.12343@wbgn013.biozentrum.uni-wuerzburg.de>
Dear diary, on Mon, Nov 28, 2005 at 02:52:08AM CET, I got a letter
where Johannes Schindelin <Johannes.Schindelin@gmx.de> said that...
> On Sun, 27 Nov 2005, Petr Baudis wrote:
>
> > I've tried to explain that branches and remotes are different concepts,
>
> Well, no. They aren't. The "branches" concept is a proper special case of
> the "remotes" concept.
Yes, but precisely what I want to do is to avoid (most of) the "added
value" of the remotes concept, if you will. Also, it really is a
different namespace than branches (while branches share the same
namespace with heads); I can try to make the namespaces match, but when
they suddenly won't, you are in big mess.
> But what the heck, I don't care what you eventually use.
>
> I only realized that we -- in the good tradition of UNIX -- have many
> different formats for different configurations: Some configurations are in
> .gitignore, some are in .git/branches/, some in .git/remotes/, some in
> .git/config, and even some in environment variables!
>
> If everybody says that this should stay so, I'll just shut up.
As I said, I don't care much if this moves to the git configuration
file, but please don't merge it with the remotes.
--
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: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Petr Baudis @ 2005-11-28 13:48 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511281359.04741.Josef.Weidendorfer@gmx.de>
Dear diary, on Mon, Nov 28, 2005 at 01:59:04PM CET, I got a letter
where Josef Weidendorfer <Josef.Weidendorfer@gmx.de> said that...
> (2) project config (in .git/project.conf)
What are you going to keep in it? There isn't much of stuff which is not
per-user or per-instance. I can't think of anything now, but there is no
list of configuration variables to check yet.
(Upstream maintainer email is interesting, OTOH it alone doesn't seem to
justify the mechanism by itself; also, the upstreams may be different
based on where you cloned the project from, etc.)
> For (2), git-clone should copy some files, e.g. the .git/project.conf
> or .git/info/exclude. But project config probably should be kept
> up to date among all repositories for a project, i.e. it should be
> version controlled itself, but independent from the project.
> We could use a project config head .git/refs/projectconfig for this;
> of course post-1.0 material.
If you still want per-project config, why should it be independent from
the project? Actually, like you have .gitignore, having something like
.gitconfig in project root would be by far the simplest - if you want
separate head, your merging and stuff gets quite more complicated, as
well as actually branching the project config, etc.
--
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: lost again on syntax change - local repository?
From: Randal L. Schwartz @ 2005-11-28 13:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051128134111.GP22159@pasky.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> It would sure be bad if this was the case. However I'm really sorry, but
Petr> I still can't reproduce it.
Reproduce by this:
localhost:~/Projects/Git/Play % cg-admin-setuprepo remote.git
localhost:~/Projects/Git/Play % mkdir local.git
localhost:~/Projects/Git/Play % cd local.git
localhost:..Git/Play/local.git % cg-init -minitial
defaulting to local storage area
Committing initial tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
Committed as 958ed484382609786ca9ae611cc54802cb7697a9.
localhost:..Git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
localhost:..Git/Play/local.git % cg-push
WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
ssh: \033]2;[zsh] localhost: No address associated with nodename
fatal: unexpected EOF
I did this with current-of-the-moment git and cogito:
localhost:~ % cd MIRROR/git-GIT
localhost:~/MIRROR/git-GIT % cg-status
Heads:
>master f1f909e3185b5ee366e198042447afe749bfc813
R origin f1f909e3185b5ee366e198042447afe749bfc813
localhost:~ % cd MIRROR/cogito-GIT
localhost:~/MIRROR/cogito-GIT % cg-status
Heads:
>master cec6c5564c6dcc30361f164dce9ac5dc635d202f
R origin cec6c5564c6dcc30361f164dce9ac5dc635d202f
If this indeed works on your machine, then we have a Darwin dependency
somewhere in cg-push or something it calls.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Petr Baudis @ 2005-11-28 13:41 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86d5kk7wbv.fsf@blue.stonehenge.com>
Dear diary, on Mon, Nov 28, 2005 at 02:09:40PM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> >>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
>
> Petr> Dear diary, on Mon, Nov 28, 2005 at 03:01:18AM CET, I got a letter
> Petr> where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> >> localhost:..Git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
>
> Petr> BTW, it should be fine to just say ../remote.git#master.
>
> Maybe this is why yours worked.
>
> Ahh, yes, it did.
>
> So, cg-push treats '../..' differently from '/foo/bar/...'.
>
> This is bad. That's the bug.
Nope, the relative path is resolved at the time of adding the branch.
Check for yourself:
xpasky@machine[0:0]~/git-devel/x/local.git$ cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
xpasky@machine[0:0]~/git-devel/x/local.git$ cg-branch-add origin2 ../remote.git#master
xpasky@machine[0:0]~/git-devel/x/local.git$ cg-branch-ls
origin /home/xpasky/git-devel/x/remote.git#master
origin2 /home/xpasky/git-devel/x/remote.git#master
Pushing to both works fine.
> cg-push treats "../" as a local filesystem, and "/..." as git-ssh.
> This is a change from before.
>
> Please make it recognize "/..." as a local file again.
It would sure be bad if this was the case. However I'm really sorry, but
I still can't reproduce it.
--
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: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Andreas Ericsson @ 2005-11-28 13:11 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511281359.04741.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer wrote:
>
> To allow for this, git_config() should not be hardcoded to only
> read .git/config, but perhaps a list of files in environment variable
> GIT_CONFIG_FILES.
>
$HOME/.gitrc:$GIT_DIR/conf/*
All files could support the freestanding "include" syntax.
> For (2), git-clone should copy some files, e.g. the .git/project.conf
> or .git/info/exclude. But project config probably should be kept
> up to date among all repositories for a project, i.e. it should be
> version controlled itself, but independent from the project.
> We could use a project config head .git/refs/projectconfig for this;
> of course post-1.0 material.
It would be very nifty to have some files that can hold maintainer-like
variables (like upstream email address for patches).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Randal L. Schwartz @ 2005-11-28 13:09 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20051128104831.GN22159@pasky.or.cz>
>>>>> "Petr" == Petr Baudis <pasky@suse.cz> writes:
Petr> Dear diary, on Mon, Nov 28, 2005 at 03:01:18AM CET, I got a letter
Petr> where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
>> localhost:..Git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
Petr> BTW, it should be fine to just say ../remote.git#master.
Maybe this is why yours worked.
Ahh, yes, it did.
So, cg-push treats '../..' differently from '/foo/bar/...'.
This is bad. That's the bug.
cg-push treats "../" as a local filesystem, and "/..." as git-ssh.
This is a change from before.
Please make it recognize "/..." as a local file again.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Randal L. Schwartz @ 2005-11-28 13:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7jat2w6u.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> If it is not absolutely necessary that you need to use Cogito,
Junio> IOW, if git barebone Porcelains are good enough for your use,
Junio> the following may be adequate.
Well, then, you should get rid of cogito/Documentation/introduction.html,
if you don't plan on supporting the interfaces described there.
I'm really just starting out. I see that tutorial, and I want to do it.
Junio> $ echo >.git/remotes/origin <<EOF
Junio> URL: /path/to/remote.git/
Junio> Push: master
Junio> Pull: master:origin
Junio> EOF
Ugh, ugh ugh ugh.
Junio> $ git push origin
Junio> I said "may be" because I do not understand the sequence before
Junio> "At this point"; how your local.git is initially set up to
Junio> relate to the remoge.git. I do not see local.git being created
Junio> by cloning remote.git.
I can't, because I have to do the first push. This is what I was told
last time!
I'm doing what I'm told, and now more things are breaking. This is
frustrating.
I'm not saying that you guys aren't doing a hell of a job. I'm just
coming at this from a user's perspective, and trying to describe it to
others. I'm not comfortable yet, because every time I try to do what
the manuals say, it breaks. Perhaps y'all are secretly working around
every broken thing, but I don't know enough to do that.
Junio> But modulo that the above should work
Junio> fine; I do that as a cheap backup on my local machine.
So, give me the exact steps, using "cg" to:
create a "remote" repo on my disk
create a "local" repo on my disk
set up the linkage between remote and local
push from local to remote
pull from remote to local
And if it ever needs a command like "cat" or "echo", something is
wrong. I'll accept a "git-" command for one or two of the steps, but
that feels like dropping into assembler instead of C.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
From: Josef Weidendorfer @ 2005-11-28 12:59 UTC (permalink / raw)
To: git
In-Reply-To: <438AC32E.5010100@op5.se>
On Monday 28 November 2005 09:43, Andreas Ericsson wrote:
> Junio C Hamano wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >
> >
> >>I only realized that we -- in the good tradition of UNIX -- have many
> >>different formats for different configurations: Some configurations are in
> >>.gitignore, some are in .git/branches/, some in .git/remotes/, some in
> >>.git/config, and even some in environment variables!
> >
> >
> > Can you live with something like this?
> >
> > - we will add new ones to config, now we have it;
It is not really fitting for all purposes (eg. syntax restrictions).
> I'd still like to see git-repo-config and git-user-config. Otherwise
> we'll need to continue having user-based environment variables
> (GIT_COMMITTER_IDENT and friends).
In fact, it would be nice to have different "config levels" supported
by git. I can imagine:
(1) user config (typically in $HOME/.gitrc)
(2) project config (in .git/project.conf)
(3) repository config; i.e. separate for every clone
(in .git/repo.conf instead of .git/config as of now?)
Even for one such level, it would be nice to be able to seperate the
config into multiple files; ie. remote config in a .git/remote.conf,
and a porcelain should be able to have its own config files, but still
using git's config parser.
To allow for this, git_config() should not be hardcoded to only
read .git/config, but perhaps a list of files in environment variable
GIT_CONFIG_FILES.
For (2), git-clone should copy some files, e.g. the .git/project.conf
or .git/info/exclude. But project config probably should be kept
up to date among all repositories for a project, i.e. it should be
version controlled itself, but independent from the project.
We could use a project config head .git/refs/projectconfig for this;
of course post-1.0 material.
Josef
^ permalink raw reply
* Re: keeping remote repo checked out?
From: Petr Baudis @ 2005-11-28 10:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James Cloos, git
In-Reply-To: <7vbr051ad1.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Mon, Nov 28, 2005 at 08:48:26AM CET, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> James Cloos <cloos@jhcloos.com> writes:
>
> > Is it possible to arrange that a push does a checkout on the remote
> > the same way a pull does on the local?
>
> Creative use of hooks/post-update would solve that.
>
> However, you should be very careful if you sometimes edit on
> server and sometimes push from other machine to the server on
> the same branch on the server.
Why? At worst you will get files with conflict markers on the server,
which isn't that huge problem and just what you have to expect when you
do this kind of thing. I could imagine having an option in the config
file describing whether the repository is "raw" or has the working copy
associated, and in the later case have the updating code in the default
post-update hook.
PS: If someone is bored, it would be very useful to have a manual page
for the git configuration file, containing the list of all options.
--
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] ls-tree: Resurrect funny name quoting lost during rewrite.
From: Junio C Hamano @ 2005-11-28 10:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0511272219420.13959@g5.osdl.org>
The rewrite to match ls-files/diff-tree behaviour accidentally
lost the name quoting. I am not proud about this code, but this
would get the test going.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
ls-tree.c | 10 +++++++++-
1 files changed, 9 insertions(+), 1 deletions(-)
applies-to: 4db95789ce3af40091ead2a97a72e75f9a0b8384
e7cdcbbbbd2fd2848244f998a0b92338fc68fe78
diff --git a/ls-tree.c b/ls-tree.c
index 4df5830..df3bcec 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -48,7 +48,15 @@ static int show_tree(unsigned char *sha1
type = "tree";
}
- printf("%06o %s %s\t%.*s%s%c", mode, type, sha1_to_hex(sha1), baselen, base, pathname, line_termination);
+ printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
+ if (1) {
+ /* NEEDSWORK: */
+ char base_[baselen + 1];
+ memcpy(base_, base, baselen);
+ base_[baselen] = 0;
+ write_name_quoted(base_, pathname, line_termination, stdout);
+ }
+ putchar(line_termination);
return 0;
}
---
0.99.9.GIT
^ permalink raw reply related
* Re: [PATCH 6/8] ls-tree: work from subdirectory.
From: Junio C Hamano @ 2005-11-28 10:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <7v64qdyxxx.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> So let's cook this for a while and have Porcelain people holler
> if they find something lacking. I'll put this in the proposed
> updates tonight, and we will plan to push everything in the
> proposed updates branch to the master branch on Wednesday, with
> any fixes and updates necessary.
OK, so I did some tests adjustments (they are in "pu"). Most
differences are easily explained but some are not.
Easy ones:
- With -r, tree entries are not shown.
- Unlike /bin/ls arguments, the paths are now filters, so
no duplicates on the output, nor the output order does not
depend on command line argument order.
- "path" shows the tree if path corresponds to a directory;
say "path/" to get its contents.
However I do not have an easy way to explain how these two work
the way they do. Taken from t/t3101 test.
The first one has both path0/a/b/c and path0/a in the filter,
and path0/a tree entry itself is not shown because it "recurses
through it".
+# I am not so sure about this one after ls-tree doing pathspec match.
+# Having both path0/a and path0/a/b/c makes path0/a redundant, and
+# it behaves as if path0/a/b/c, path1/b/c, path2 and path3 are specified.
test_expect_success \
'ls-tree filter directories' \
'git-ls-tree $tree path3 path2 path0/a/b/c path1/b/c path0/a >current &&
cat >expected <<\EOF &&
-040000 tree X path3
-100644 blob X path3/1.txt
-100644 blob X path3/2.txt
-040000 tree X path2
-100644 blob X path2/1.txt
040000 tree X path0/a/b/c
-100644 blob X path0/a/b/c/1.txt
040000 tree X path1/b/c
-100644 blob X path1/b/c/1.txt
-040000 tree X path0/a
-040000 tree X path0/a/b
+040000 tree X path2
+040000 tree X path3
EOF
test_output'
The second one is the same; since there is path3/, it recurses
through it and path3 itself is not shown but its contents are.
It is showing both path3/1.txt and path3/2.txt not because
path3/1.txt is specified but path3/ was specified.
+# Again, duplicates are filtered away so this is equivalent to
+# having 1.txt and path3/
test_expect_success \
'ls-tree filter odd names' \
'git-ls-tree $tree 1.txt /1.txt //1.txt path3/1.txt /path3/1.txt //path3//1.txt path3 /path3/ path3// >current &&
cat >expected <<\EOF &&
100644 blob X 1.txt
-100644 blob X 1.txt
-100644 blob X 1.txt
-100644 blob X path3/1.txt
-100644 blob X path3/1.txt
-100644 blob X path3/1.txt
-040000 tree X path3
-100644 blob X path3/1.txt
-100644 blob X path3/2.txt
-040000 tree X path3
-100644 blob X path3/1.txt
-100644 blob X path3/2.txt
-040000 tree X path3
100644 blob X path3/1.txt
100644 blob X path3/2.txt
EOF
^ permalink raw reply
* Re: lost again on syntax change - local repository?
From: Petr Baudis @ 2005-11-28 10:48 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <861x118r9t.fsf@blue.stonehenge.com>
Dear diary, on Mon, Nov 28, 2005 at 03:01:18AM CET, I got a letter
where "Randal L. Schwartz" <merlyn@stonehenge.com> said that...
> localhost:..Git/Play/local.git % cg-branch-add origin "$(cd ..; pwd)/remote.git#master"
BTW, it should be fine to just say ../remote.git#master.
> localhost:..Git/Play/local.git % cg-branch-ls
> origin /Users/merlyn/Projects/Git/Play/remote.git#master
> localhost:..Git/Play/local.git %
>
> At this point, I'm where I was before. And this next step worked,
> although I had to say "origin":
>
> localhost:..Git/Play/local.git % cg-push
> WARNING: I guessed the host:path syntax was used and fell back to the git+ssh protocol.
> WARNING: The host:path syntax is evil because it is implicit. Please just use a URI.
> ssh: \033]2;[zsh] localhost: No address associated with nodename
> fatal: unexpected EOF
I did the exact same sequence of commands and everything works just fine
for me with both the latest master and the latest v0.16. What Cogito
version do you use? Are you sure the origin location is just the local
path at the time of cg-push?
--
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: [PATCH] Fix gitk this->selected diffs
From: Paul Mackerras @ 2005-11-28 8:28 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20051127222929.GM3393@nowhere.earth>
Yann Dirson writes:
> This patch changes the two git-diff-tree calls to get the necessary
> two ids in this case. It does so by propagating a "singlecommit" flag
> through all functions involved via an additional argument.
Seems a bit ugly... Why can't we just make the ids list that we pass
around have either 1 or 2 elements instead? I'll have a closer look,
but assuming that works I think it'll be a lot cleaner.
Thanks,
Paul.
^ permalink raw reply
* Re: git-send-mail in sh
From: Junio C Hamano @ 2005-11-28 9:34 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <438AC7A0.7030407@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> By "local" do you mean "local on Junio's laptop" or "local at cox.net"?
>
> "mail" uses the "local on Junio's laptop" SMTP server so he can
> configure it any way he wants.
I am puzzled. What if I do not run any SMTP server on the
laptop and use ISP's SMTP server? Right now my ISP's SMTP
server does not seem to require AUTH, so it is not an issue for
me, though..
^ permalink raw reply
* Re: [PATCH] git-mv: fully detect 'directory moved into itself'
From: Junio C Hamano @ 2005-11-28 9:24 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200511281015.15188.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> This is a corrected version.
>
> On Monday 28 November 2005 07:54, Matthias Urlichs wrote:
>> Hi, Josef Weidendorfer wrote:
>>
>> > + if (($bad eq "") && ($dst =~ /^$src\//)) {
>>
>> That should be
>>
>> > + if (($bad eq "") && ($dst =~ /^\Q$src\E\//)) {
>>
>> otherwise you will mistakenly match "foo-bar" with "foo.bar".
>
> Ah, thanks.
> You never end learning.
Why not use $safesrc you already have for this exact purpose?
^ 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