* Re: Diffs from CVS keyword expansion
From: Uwe Kleine-Koenig @ 2006-12-06 10:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Randal L. Schwartz, Jon Smirl, Git Mailing List
In-Reply-To: <Pine.LNX.4.63.0612052048230.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Hi,
Johannes Schindelin wrote:
> On Tue, 5 Dec 2006, Randal L. Schwartz wrote:
>
> > >>>>> "Uwe" == Uwe Kleine-Koenig <zeisberg@informatik.uni-freiburg.de> writes:
> >
> > Uwe> #! /bin/sh
> > Uwe> exec perl -i -p -e 's/\$(Id|Revision):.*?\$/\$$1: \$/' "$@";
> >
> > Ow. My eyes hurt from that. How about we rewrite that as a native Perl
> > script:
I don't like that either, just because it's Perl :-)
> > #!/usr/bin/perl
> > $^I = ""; # this is -i
> > while (<>) {
> > s/\$(Id|Revision):.*?\$/\$$1: \$/;
> > print;
> > }
>
> Hey, that's better! All of a sudden, I understand everything!
I'm not fluent in Perl, and didn't know $^I. Actually, that's better,
yes. (And my script is already rewritten.)
One thing I don't like about both scripts is, that the timestamp of
a file changes with that, even if there are no changes. Anyone knows
another predefined variable/trick that doesn't hurt performance (and
readability) too much?
timtowtdi
Uwe
--
Uwe Kleine-Koenig
^ permalink raw reply
* Re: Diffs from CVS keyword expansion
From: Randal L. Schwartz @ 2006-12-06 10:08 UTC (permalink / raw)
To: Uwe Kleine-Koenig; +Cc: Johannes Schindelin, Jon Smirl, Git Mailing List
In-Reply-To: <20061206100514.GA7126@informatik.uni-freiburg.de>
>>>>> "Uwe" == Uwe Kleine-Koenig <zeisberg@informatik.uni-freiburg.de> writes:
Uwe> One thing I don't like about both scripts is, that the timestamp of
Uwe> a file changes with that, even if there are no changes. Anyone knows
Uwe> another predefined variable/trick that doesn't hurt performance (and
Uwe> readability) too much?
You have to do two passes, or a pass-and-a-half, and do the rename/rewrite
based on whether anything changed.
"Just a few more lines of code." :) If it's really important, I can
be coaxed to dig it up.
--
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.
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Junio C Hamano @ 2006-12-06 10:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612061058360.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Originally, I thought that building in git-merge-one-file, and enhancing
> it to recognize by the parameters if it should act as a merge replacement,
> would be the way to go. Should I do this, or rather add
> builtin-merge-file?
All in-tree users of git-merge-one-file is of this pattern:
git merge-index -o git-merge-one-file -a
so I was hoping we can capture this whole thing as a single
command (merge-index would fork+exec a merge-one-file per
unmerged path), instead of doing merge-one-file as a built-in.
In any case, the way your xdl-merge engine is done, it should be
almost trivial to write a pure 'RCS merge replacement' as a
totally separate program -- the bulk of the new code would be
parsing parameters, opening the three input files, populating
mmfile structures and writing the result out, and there would be
almost no "smart" in that part of the code you would want to
share with the git-aware version.
^ permalink raw reply
* Re: git pull and merging.
From: Johannes Schindelin @ 2006-12-06 10:14 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrnend551.arq.Peter.B.Baumann@xp.machine.xx>
Hi,
On Wed, 6 Dec 2006, Peter Baumann wrote:
> On 2006-12-06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > You can have the same effect as what Junio wrote with the config:
> >
> > $ git repo-config remote.origin.url git://git.kernel.org/pub/scm/git/git.git
> > $ git repo-config remote.origin.fetch \
> > refs/heads/master:refs/remotes/origin/master
> > $ git repo-config remote.origin.fetch \
> > refs/heads/next:refs/remotes/origin/next ^$
> > $ git repo-config remote.origin.fetch \
> > +refs/heads/pu:refs/remotes/origin/pu ^$
> >
>
> What's that ^$ for?
We misuse the "nice" ini format a little bit in git: we allow multiple
values for certain keys, like "remote.origin.fetch".
The normal mode for repo-config is to replace the value for the given key.
By appending a regular expression, you can limit the replacement to
certain matching _values_. And since "^$" means empty string, it does not
match any, ensuring an append instead of a replace.
Ciao,
Dscho
^ permalink raw reply
* Re: git newbie problems
From: Jakub Narebski @ 2006-12-06 10:17 UTC (permalink / raw)
To: Han-Wen Nienhuys, Graham Percival; +Cc: git
In-Reply-To: <45768FE8.2030202@xs4all.nl>
Han-Wen Nienhuys wrote:
> Jakub Narebski escreveu:
>
>> Graham Percival wrote:
>>
>>> 84219bb don't have input/templates/ any longer.
>>> fatal: Entry '.gitignore' would be overwritten by merge. Cannot merge.
>>> No merge strategy handled the merge.
>>>
>>> As a git newbie, I'm quite confused. OK, there's no merge strategy...
There is no merge strategy used, because problem (conflict) doesn't stem
from what was committed, but from what was in working directory.
>>> so what do I do now? With cvs, the changes would be dumped into the
>>> file. I look at the file, found the conflict, and tried it again. I
>>> got the same error message, and then it occurred to me that although I
>>> changed the files in my ~/usr/src/lilypond, git might be storing these
>>> files somewhere else.
>>
>> Yes, the git error messages certainly needs to be made more user-friendly.
>> What git says here that one version has '.gitignore' file handled by version
>> control, and second has it outside version control. At least I think what
>> it does.
>
> Which is actually not true. .gitignore has been in the repo since we
> started using git. I have also seen this message pop up a few times
> in the beginning, but I can't recall why they happened.
I don't know if git allows to pull into dirty tree with impunity. If I
remeber correctly Cogito (alternate UI for git) allows this[*1*], there is
currently work on this in git (but it is not as far as I remember in
git 1.4.4.1). So another possibility is induced by CVS "update then commit"
mentality pulling changes _before_ commiting changes.
If this is the case, committing changes _then_ pulling would solve this
problem.
Footnotes:
----------
[*1*] This is a bit error prone.
--
Jakub Narebski
^ permalink raw reply
* Re: how to revert changes in working tree?
From: Jakub Narebski @ 2006-12-06 10:20 UTC (permalink / raw)
To: git
In-Reply-To: <45769417.70601@gmail.com>
Liu Yubao wrote:
>> Do a "git repo-config core.filemode false" to almost
>> disable the checks for exec bit.
>>
>
> It has been set. I guess the cause is a interrupted merge
> operation that leads to textual difference.
Try also "git repo-config core.ignoreStat true". Perhaps it would help.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: how to revert changes in working tree?
From: Alex Riesen @ 2006-12-06 10:20 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <45769417.70601@gmail.com>
On 12/6/06, Liu Yubao <yubao.liu@gmail.com> wrote:
> Alex Riesen wrote:
> > On 12/6/06, Liu Yubao <yubao.liu@gmail.com> wrote:
> >> I'm confused how to revert changes in working tree:
> >>
> >> $ git fetch
> >> $ git merge "sync with origin" HEAD origin
> >> ....conflict....
> >
> > You may want to consider git pull. It'd do exactly the same
>
> It's said somewhere "git pull" has strange behaviour and fetch+pull
> is recommended.
So why do you use fetch+merge?
> sorry, I made a mistake, that should come from "git merge",
so, you just have an unresolved merge.
It was discussed on this mailing list very recently
(and actually is being discussed), so just look at
the archives.
> > They problem is the exec-bit which windows does not
> > have and cygwin failed to correctly workaround the
> > limitation.
> >
> > Do a "git repo-config core.filemode false" to almost
> > disable the checks for exec bit.
> >
>
> It has been set. I guess the cause is a interrupted merge
> operation that leads to textual difference.
yes, though what I can't understand is why don't you have
unmerged entries... Maybe it comes from playing with
all these commands you mentioned in the original mail.
> After run "git reset --hard", all deleted files come back, but I reach
> the old state:
> $ git status
When? Immediately after git reset --hard? Then you very
likely have no permission to write (or lost it somehow) into
the working directory, otherwise I don't see could this be
possible. git reset --hard rewrites everything.
> HEAD: commit 088406bcf66d6c7fd8a5c04c00aa410ae9077403
> master: commit 088406bcf66d6c7fd8a5c04c00aa410ae9077403
> origin: commit ff51a98799931256b555446b2f5675db08de6229
> "git diff --cached" shows nothing;
which is correct.
> "git diff" shows many diffs:
and this is not. You do have changes, which could not be reset.
I fail to see why. Are you sure you haven't accidentally repeated
the merge after doing git reset --hard? And what was _exactly_
^ permalink raw reply
* Re: git newbie problems
From: Han-Wen Nienhuys @ 2006-12-06 10:21 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200612061117.32903.jnareb@gmail.com>
Jakub Narebski escreveu:
> I don't know if git allows to pull into dirty tree with impunity. If I
> remeber correctly Cogito (alternate UI for git) allows this[*1*], there is
> currently work on this in git (but it is not as far as I remember in
> git 1.4.4.1). So another possibility is induced by CVS "update then commit"
> mentality pulling changes _before_ commiting changes.
it is quite possibly a side-effect of cvs-habits. Note that in the beginning
I have wrestled to make git update the HEAD , eg. trying --update-head-ok
--
^ permalink raw reply
* Re: git pull and merging.
From: Peter Baumann @ 2006-12-06 10:23 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter Baumann, git
In-Reply-To: <Pine.LNX.4.63.0612061111340.28348@wbgn013.biozentrum.uni-wuerzburg.de>
On Wed, Dec 06, 2006 at 11:14:01AM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 6 Dec 2006, Peter Baumann wrote:
>
> > On 2006-12-06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > > You can have the same effect as what Junio wrote with the config:
> > >
> > > $ git repo-config remote.origin.url git://git.kernel.org/pub/scm/git/git.git
> > > $ git repo-config remote.origin.fetch \
> > > refs/heads/master:refs/remotes/origin/master
> > > $ git repo-config remote.origin.fetch \
> > > refs/heads/next:refs/remotes/origin/next ^$
> > > $ git repo-config remote.origin.fetch \
> > > +refs/heads/pu:refs/remotes/origin/pu ^$
> > >
> >
> > What's that ^$ for?
>
> We misuse the "nice" ini format a little bit in git: we allow multiple
> values for certain keys, like "remote.origin.fetch".
>
> The normal mode for repo-config is to replace the value for the given key.
> By appending a regular expression, you can limit the replacement to
> certain matching _values_. And since "^$" means empty string, it does not
> match any, ensuring an append instead of a replace.
>
> Ciao,
> Dscho
>
Another new thing learned today!
Thanks for the info.
^ permalink raw reply
* Re: git patch
From: Jakub Narebski @ 2006-12-06 10:22 UTC (permalink / raw)
To: git; +Cc: lilypond-devel
In-Reply-To: <4576937D.1070402@xs4all.nl>
Han-Wen Nienhuys wrote:
> I think it would be more logical to show those diffs as part of
> git-status and perhaps git-commit, eg.
>
> git-commit --dry-run <commitoptions>
>
> shows the diff of what would be committed
>
> git-status --diff
>
> shows diffs of modified files in the working tree.
>
> This makes it more clear what each diff means.
I'd rather say
git-commit --diff
or
git-diff --commit
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git pull and merging.
From: Jakub Narebski @ 2006-12-06 10:28 UTC (permalink / raw)
To: git
In-Reply-To: <cc723f590612060205p1fd26cd7u3c7efc723b0177de@mail.gmail.com>
Aneesh Kumar wrote:
> [branch "devel"]
> remote = origin
> merge = devel
Does
[branch "refs/heads/devel"]
remote = origin
merge = refs/remotes/origin/devel
works?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: git newbie problems
From: Johannes Schindelin @ 2006-12-06 10:42 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: Jakub Narebski, git
In-Reply-To: <457699C1.3060400@xs4all.nl>
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
> Note that in the beginning I have wrestled to make git update the HEAD ,
> eg. trying --update-head-ok
Ah! That would explain many of the problems! BTW where did you see that
option mentioned? We should hide this option as deep in the technical
lores of the documentation, fast.
Ciao,
Dscho
^ permalink raw reply
* Re: using xdl_merge(), was Re: Resolving conflicts
From: Johannes Schindelin @ 2006-12-06 10:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vlkll72no.fsf@assigned-by-dhcp.cox.net>
Hi,
On Wed, 6 Dec 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Originally, I thought that building in git-merge-one-file, and enhancing
> > it to recognize by the parameters if it should act as a merge replacement,
> > would be the way to go. Should I do this, or rather add
> > builtin-merge-file?
>
> All in-tree users of git-merge-one-file is of this pattern:
>
> git merge-index -o git-merge-one-file -a
>
> so I was hoping we can capture this whole thing as a single
> command (merge-index would fork+exec a merge-one-file per
> unmerged path), instead of doing merge-one-file as a built-in.
Yes, this was also my thinking. But notice how git-merge-one-file does
much more than just merge? So, you end up rewriting it in C anyway, if you
want to make merge-index not fork unless "-o cmd" is passed.
> In any case, the way your xdl-merge engine is done, it should be almost
> trivial to write a pure 'RCS merge replacement' as a totally separate
> program -- the bulk of the new code would be parsing parameters, opening
> the three input files, populating mmfile structures and writing the
> result out, and there would be almost no "smart" in that part of the
> code you would want to share with the git-aware version.
Actually, I just did that. I will add some test cases (to reflect your
option (3) in another thread), and submit.
Ciao,
Dscho
^ permalink raw reply
* Fwd: git pull and merging.
From: Aneesh Kumar @ 2006-12-06 10:48 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <cc723f590612060248y6f730a54l3a2aadfa6500d36d@mail.gmail.com>
After printing some debug echo i got this one which seems to be working for me
[branch "devel"]
remote = origin
^ permalink raw reply
* Re: how to revert changes in working tree?
From: Liu Yubao @ 2006-12-06 11:14 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <81b0412b0612060220n11fb7e19hc6ed202759962bd3@mail.gmail.com>
Alex Riesen wrote:
> On 12/6/06, Liu Yubao <yubao.liu@gmail.com> wrote:
>> Alex Riesen wrote:
>> > On 12/6/06, Liu Yubao <yubao.liu@gmail.com> wrote:
>> >> I'm confused how to revert changes in working tree:
>> >>
>> >> $ git fetch
>> >> $ git merge "sync with origin" HEAD origin
>> >> ....conflict....
>> >
>> > You may want to consider git pull. It'd do exactly the same
>>
>> It's said somewhere "git pull" has strange behaviour and fetch+pull
>> is recommended.
>
> So why do you use fetch+merge?
>
Oh, another mistake, I have heard fetch+merge is recommended.
> so, you just have an unresolved merge.
> It was discussed on this mailing list very recently
> (and actually is being discussed), so just look at
> the archives.
>
Thanks, I will dig it.
>> > They problem is the exec-bit which windows does not
>> > have and cygwin failed to correctly workaround the
>> > limitation.
>> >
>> > Do a "git repo-config core.filemode false" to almost
>> > disable the checks for exec bit.
>> >
>>
>> It has been set. I guess the cause is a interrupted merge
>> operation that leads to textual difference.
>
> yes, though what I can't understand is why don't you have
> unmerged entries... Maybe it comes from playing with
> all these commands you mentioned in the original mail.
>
>> After run "git reset --hard", all deleted files come back, but I reach
>> the old state:
>> $ git status
>
> When? Immediately after git reset --hard? Then you very
> likely have no permission to write (or lost it somehow) into
> the working directory, otherwise I don't see could this be
> possible. git reset --hard rewrites everything.
>
Yes, immediately after git reset --hard. I'm sure I have write
permission because all deleted files come back and no "permission
denied" like message appears.
I will try to run git in debugger, wish I can get the reason.
>> HEAD: commit 088406bcf66d6c7fd8a5c04c00aa410ae9077403
>> master: commit 088406bcf66d6c7fd8a5c04c00aa410ae9077403
>> origin: commit ff51a98799931256b555446b2f5675db08de6229
>> "git diff --cached" shows nothing;
>
> which is correct.
>
>> "git diff" shows many diffs:
>
> and this is not. You do have changes, which could not be reset.
> I fail to see why. Are you sure you haven't accidentally repeated
> the merge after doing git reset --hard? And what was _exactly_
> git merge told you, when it failed?
>
I didn't run "git merge" after "git reset --hard" indeed. To get the message
from "git merge", now I run it like this:
$ git merge "sync from origin" HEAD origin
Updating 088406b..ff51a98
include/linux/netfilter/xt_CONNMARK.h: needs update
include/linux/netfilter/xt_DSCP.h: needs update
include/linux/netfilter/xt_MARK.h: needs update
include/linux/netfilter_ipv4/ipt_CONNMARK.h: needs update
include/linux/netfilter_ipv4/ipt_DSCP.h: needs update
include/linux/netfilter_ipv4/ipt_ECN.h: needs update
include/linux/netfilter_ipv4/ipt_MARK.h: needs update
include/linux/netfilter_ipv4/ipt_TCPMSS.h: needs update
include/linux/netfilter_ipv4/ipt_TOS.h: needs update
include/linux/netfilter_ipv4/ipt_TTL.h: needs update
include/linux/netfilter_ipv6/ip6t_HL.h: needs update
include/linux/netfilter_ipv6/ip6t_MARK.h: needs update
net/ipv4/netfilter/ipt_ECN.c: needs update
net/ipv4/netfilter/ipt_TOS.c: needs update
net/ipv4/netfilter/ipt_TTL.c: needs update
net/ipv6/netfilter/ip6t_HL.c: needs update
net/netfilter/xt_CONNMARK.c: needs update
net/netfilter/xt_DSCP.c: needs update
net/netfilter/xt_MARK.c: needs update
fatal: Entry 'net/ipv4/netfilter/ipt_ECN.c' not uptodate. Cannot merge.
^ permalink raw reply
* Re: git patch
From: Han-Wen Nienhuys @ 2006-12-06 11:27 UTC (permalink / raw)
To: git; +Cc: lily-devel
In-Reply-To: <Pine.LNX.4.63.0612061147540.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
>> shows the diff of the change that he just introduced
>
> Okay. But you mean
>
> $ git commit --dry file1 file2...
>
> or
>
> $ git commit --dry -a
Well, --dry would be usable both with -a and file1, file2.
I agree with Jakub that --diff might be a better name, but it should
be part of git-commit command, rather than the git-diff.
> Or, you use the script git-hunk-commit.bash which I posted. Which reminds
> me: I wanted to rewrite it for you so it is more non-brand-new-bash
> friendly.
:)
that's really nice, but actually recording separate hunks is a bit of
a headache if you have to do it over the command line. Under darcs, I
always use darcsum in emacs. In git, I always use git-status.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Andy Parkins @ 2006-12-06 12:07 UTC (permalink / raw)
To: git
Without any specification in the .git/config file, git-pull will execute
"git-pull origin"; which in turn defaults to pull from the first "pull"
definition for the remote, "origin".
This is a difficult set of defaults to track for a new user, and it's
difficult to see what tells git to do this (especially when it is
actually hard-coded behaviour). To ameliorate this slightly, this patch
explicitly specifies the default behaviour during a clone using the
"branch" section of the config.
For example, a clone of a typical repository would create a .git/config
containing:
[remote "origin"]
url = proto://host/repo.git
fetch = refs/heads/master:refs/remotes/origin/master
[branch "master"]
remote = origin
merge = refs/heads/master
The [branch "master"] section is such that there is no change to the
functionality of git-pull, but that functionality is now explicitly
documented.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
---
This is really to help newbies. By explicitly documenting the default
behaviour, it makes it clearer what is going on. It also means no routing
through documentation to find out what config option needs changing.
It's possible that we would want to remove the default behaviour entirely
if there is no "branch" definition in the config. That would prevent
accidents by users who don't know what pull does fully yet.
git-clone.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-clone.sh b/git-clone.sh
index 826fdda..992cb7c 100755
--- a/git-clone.sh
+++ b/git-clone.sh
@@ -413,7 +413,9 @@ then
rm -f "refs/remotes/$origin/HEAD"
git-symbolic-ref "refs/remotes/$origin/HEAD" \
"refs/remotes/$origin/$head_points_at"
- esac
+ esac &&
+ git-repo-config branch."$head_points_at".remote "$origin" &&
+ git-repo-config branch."$head_points_at".merge "refs/heads/$head_points_at"
esac
case "$no_checkout" in
--
1.4.4.1.g3ece-dirty
^ permalink raw reply related
* bug: git-sh-setup should not be in $PATH
From: Han-Wen Nienhuys @ 2006-12-06 12:14 UTC (permalink / raw)
To: git
Hello,
I often install tools locally so I can run SVN/CVS/etc versions
in my own account. To do this, I install into
$HOME/usr/pkg/PACKAGE
and a script that generates scripts in $HOME/usr/bin/ (which is in my $PATH)
like
#!/bin/sh
exec /home/lilydev/usr/pkg/git/bin/git-prune "$@"
# generated: update-pkgs
this breaks with git-sh-setup; all sh scripts are broken with this
setup.
git-sh-setup isn't a 'normal' binary, in that it should be called by
bash only and not run in a subshell. Therefore I propose that it
- be installed in <prefix>/share/git/
- be invoked with an explicit path, i.e.
. <prefix>/share/git/
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Johannes Schindelin @ 2006-12-06 12:20 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200612061207.23437.andyparkins@gmail.com>
Hi,
On Wed, 6 Dec 2006, Andy Parkins wrote:
> This is really to help newbies. By explicitly documenting the default
> behaviour, it makes it clearer what is going on. It also means no
> routing through documentation to find out what config option needs
> changing.
Melikes.
Ciao,
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Johannes Schindelin @ 2006-12-06 12:23 UTC (permalink / raw)
To: Han-Wen Nienhuys; +Cc: git
In-Reply-To: <el6c6o$oa7$1@sea.gmane.org>
Hi,
On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
> I often install tools locally so I can run SVN/CVS/etc versions
> in my own account. To do this, I install into
>
> $HOME/usr/pkg/PACKAGE
Why not just set
$ export GIT_EXEC_PATH=$HOME/usr/pkg/git
$ export PATH=$PATH:$GIT_EXEC_PATH
?
Ciao,
^ permalink raw reply
* Re: [PATCH] Explicitly add the default "git pull" behaviour to .git/config on clone
From: Jakub Narebski @ 2006-12-06 12:27 UTC (permalink / raw)
To: git
In-Reply-To: <200612061207.23437.andyparkins@gmail.com>
Andy Parkins wrote:
> Without any specification in the .git/config file, git-pull will execute
> "git-pull origin"; which in turn defaults to pull from the first "pull"
> definition for the remote, "origin".
>
> This is a difficult set of defaults to track for a new user, and it's
> difficult to see what tells git to do this (especially when it is
> actually hard-coded behaviour). To ameliorate this slightly, this patch
> explicitly specifies the default behaviour during a clone using the
> "branch" section of the config.
>
> For example, a clone of a typical repository would create a .git/config
> containing:
> [remote "origin"]
> url = proto://host/repo.git
> fetch = refs/heads/master:refs/remotes/origin/master
> [branch "master"]
> remote = origin
> merge = refs/heads/master
>
> The [branch "master"] section is such that there is no change to the
> functionality of git-pull, but that functionality is now explicitly
> documented.
This doesn't help newbies if they do "git pull" on branch other than
"master". Git would fetch (a) from default remote "origin" (which can
be unexpected a bit) (b) into current branch (which can be very
unexpected for newbie) (c) the first branch in remote (which can be
very unexpected).
The part (c) could be ameliorated (especially when globbing/regexp
matching would get into 'master') with "Merge:" line in remotes file
and equivalent remote.<name>.merge which would specify explicitely
the branch to be merged, instead of using first branch.
> Signed-off-by: Andy Parkins <andyparkins@gmail.com>
> ---
> This is really to help newbies. By explicitly documenting the default
> behaviour, it makes it clearer what is going on. It also means no routing
> through documentation to find out what config option needs changing.
Very nice.
> It's possible that we would want to remove the default behaviour entirely
> if there is no "branch" definition in the config. That would prevent
> accidents by users who don't know what pull does fully yet.
Perhaps protected by config option and/or pull option... or perhaps not.
Refuse pulling into current branch if it doesn.t have branch.<name>.remote
matching current remote and doesn't have branch.<name>.merge entry, unless
of course refspec is provided.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] cvs-migration document: make the need for "push" more obvious
From: Johannes Schindelin @ 2006-12-06 12:27 UTC (permalink / raw)
To: Werner LEMBERG; +Cc: gpermus, hanwen, git
In-Reply-To: <20061206.105251.144349770.wl@gnu.org>
It really is an important concept to grasp for people coming
from CVS. Even if it is briefly mentioned, it is not obvious
enough to sink in.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Wed, 6 Dec 2006, Werner LEMBERG wrote:
> It took me a while to realize that a git repository, as soon as
> you've cloned it, is *self-contained*, and that commiting to the
> repository and synchronizing with a different git repository are
> two completely different things (contrary to CVS). This should
> be pronounced more in the CVS->git guide.
Documentation/cvs-migration.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/cvs-migration.txt b/Documentation/cvs-migration.txt
index 6812683..8e610c7 100644
--- a/Documentation/cvs-migration.txt
+++ b/Documentation/cvs-migration.txt
@@ -24,6 +24,11 @@ First, note some ways that git differs from CVS:
single shared repository which people can synchronize with; see below
for details.
+ * Since every working tree contains a repository, a commit will not
+ publish your changes; it will only create a revision. You have to
+ "push" your changes to a public repository to make them visible
+ to others.
+
Importing a CVS archive
-----------------------
--
^ permalink raw reply related
* Re: how to revert changes in working tree?
From: Alex Riesen @ 2006-12-06 12:30 UTC (permalink / raw)
To: Liu Yubao; +Cc: git
In-Reply-To: <4576A60A.3060003@gmail.com>
On 12/6/06, Liu Yubao <yubao.liu@gmail.com> wrote:
> >> > They problem is the exec-bit which windows does not
> >> > have and cygwin failed to correctly workaround the
> >> > limitation.
> >> >
> >> > Do a "git repo-config core.filemode false" to almost
> >> > disable the checks for exec bit.
> >> >
> >>
> >> It has been set. I guess the cause is a interrupted merge
> >> operation that leads to textual difference.
> >
> > yes, though what I can't understand is why don't you have
> > unmerged entries... Maybe it comes from playing with
> > all these commands you mentioned in the original mail.
> >
> >> After run "git reset --hard", all deleted files come back, but I reach
> >> the old state:
> >> $ git status
> >
> > When? Immediately after git reset --hard? Then you very
> > likely have no permission to write (or lost it somehow) into
> > the working directory, otherwise I don't see could this be
> > possible. git reset --hard rewrites everything.
> >
> Yes, immediately after git reset --hard. I'm sure I have write
> permission because all deleted files come back and no "permission
> denied" like message appears.
Maybe you have the files open in some editor?
Otherwise something is broken. Could you try current git
(I mean something like ba988a83f0cfdafdcfdc7ed44253840ea83578fb?
> I will try to run git in debugger, wish I can get the reason.
don't think It'd be as simple as step-by-step in debugger.
Try to instrument builtin-read-tree.c or unpack-trees.c and
see if it actually updates the files...
> $ git merge "sync from origin" HEAD origin
> Updating 088406b..ff51a98
just for fun, what does following print:
git read-tree --reset -u HEAD && git update-index --refresh
^ permalink raw reply
* Re: bug: git-sh-setup should not be in $PATH
From: Han-Wen Nienhuys @ 2006-12-06 12:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0612061322140.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin escreveu:
> Hi,
>
> On Wed, 6 Dec 2006, Han-Wen Nienhuys wrote:
>
>> I often install tools locally so I can run SVN/CVS/etc versions
>> in my own account. To do this, I install into
>>
>> $HOME/usr/pkg/PACKAGE
>
> Why not just set
>
> $ export GIT_EXEC_PATH=$HOME/usr/pkg/git
> $ export PATH=$PATH:$GIT_EXEC_PATH
>
> ?
Because it requires brain cycles from my part. I rather spend those
constructively.
GIT is the only package I've seen in a long time that breaks this
setup.
Here is the patch that I proposed
From 988813912c4c7b310c489bfffa1b81e2663b7b6f Mon Sep 17 00:00:00 2001
From: Han-Wen Nienhuys <hanwen@xs4all.nl>
Date: Wed, 6 Dec 2006 13:27:16 +0100
Subject: [PATCH] Install git-sh-setup.sh into $(prefix)/share/git-core. Call with
explicit path.
Signed-off-by: Han-Wen Nienhuys <hanwen@xs4all.nl>
---
Makefile | 10 ++++++++--
git-am.sh | 2 +-
git-applymbox.sh | 2 +-
git-applypatch.sh | 2 +-
git-bisect.sh | 2 +-
git-checkout.sh | 2 +-
git-clean.sh | 2 +-
git-commit.sh | 2 +-
git-fetch.sh | 2 +-
git-instaweb.sh | 2 +-
git-lost-found.sh | 2 +-
git-merge.sh | 2 +-
git-pull.sh | 2 +-
git-quiltimport.sh | 2 +-
git-rebase.sh | 2 +-
git-repack.sh | 2 +-
git-request-pull.sh | 2 +-
git-reset.sh | 2 +-
git-resolve.sh | 2 +-
git-revert.sh | 2 +-
git-tag.sh | 2 +-
git-verify-tag.sh | 2 +-
22 files changed, 29 insertions(+), 23 deletions(-)
diff --git a/Makefile b/Makefile
index a1861de..cb9b745 100644
--- a/Makefile
+++ b/Makefile
@@ -116,8 +116,10 @@ STRIP ?= strip
prefix = $(HOME)
bindir = $(prefix)/bin
+datadir = $(prefix)/share
+GIT_datadir = $(datadir)/git-core
gitexecdir = $(bindir)
-template_dir = $(prefix)/share/git-core/templates/
+template_dir = $(GIT_datadir)/templates/
# DESTDIR=
# default configuration for gitweb
@@ -166,7 +168,7 @@ SCRIPT_SH = \
git-merge-one-file.sh git-parse-remote.sh \
git-pull.sh git-rebase.sh \
git-repack.sh git-request-pull.sh git-reset.sh \
- git-resolve.sh git-revert.sh git-sh-setup.sh \
+ git-resolve.sh git-revert.sh \
git-tag.sh git-verify-tag.sh \
git-applymbox.sh git-applypatch.sh git-am.sh \
git-merge.sh git-merge-stupid.sh git-merge-octopus.sh \
@@ -550,6 +552,7 @@ endif
# Shell quote (do not use $(call) to accommodate ancient setups);
SHA1_HEADER_SQ = $(subst ','\'',$(SHA1_HEADER))
+GIT_datadir_SQ = $(subst ','\'',$(GIT_datadir))
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
@@ -604,6 +607,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
-e 's|@@PERL@@|$(PERL_PATH_SQ)|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's!@@GIT_datadir@@!$(GIT_datadir)!g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
$@.sh >$@+
chmod +x $@+
@@ -816,6 +820,8 @@ install: all
'$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X'; \
fi
$(foreach p,$(BUILT_INS), rm -f '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' && ln '$(DESTDIR_SQ)$(gitexecdir_SQ)/git$X' '$(DESTDIR_SQ)$(gitexecdir_SQ)/$p' ;)
+ $(INSTALL) -d -m755 '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
+ $(INSTALL) -m755 git-sh-setup.sh '$(DESTDIR_SQ)$(GIT_datadir_SQ)'
install-doc:
$(MAKE) -C Documentation install
diff --git a/git-am.sh b/git-am.sh
index afe322b..b9dfcf0 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -5,7 +5,7 @@
USAGE='[--signoff] [--dotest=<dir>] [--utf8] [--binary] [--3way]
[--interactive] [--whitespace=<option>] <mbox>...
or, when resuming [--skip | --resolved]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
git var GIT_COMMITTER_IDENT >/dev/null || exit
diff --git a/git-applymbox.sh b/git-applymbox.sh
index 5569fdc..eaab50d 100755
--- a/git-applymbox.sh
+++ b/git-applymbox.sh
@@ -19,7 +19,7 @@
## git-am is supposed to be the newer and better tool for this job.
USAGE='[-u] [-k] [-q] [-m] (-c .dotest/<num> | mbox) [signoff]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
git var GIT_COMMITTER_IDENT >/dev/null || exit
diff --git a/git-applypatch.sh b/git-applypatch.sh
index 8df2aee..7ddf5d3 100755
--- a/git-applypatch.sh
+++ b/git-applypatch.sh
@@ -12,7 +12,7 @@
##
USAGE='<msg> <patch> <info> [<signoff>]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
case "$#" in 3|4) ;; *) usage ;; esac
diff --git a/git-bisect.sh b/git-bisect.sh
index 6da31e8..6fa92e2 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -10,7 +10,7 @@ git bisect visualize show bisect status in gitk.
git bisect replay <logfile> replay bisection log
git bisect log show bisect log.'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
sq() {
@@PERL@@ -e '
diff --git a/git-checkout.sh b/git-checkout.sh
index 737abd0..beea113 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -2,7 +2,7 @@
USAGE='[-f] [-b <new_branch>] [-m] [<branch>] [<paths>...]'
SUBDIRECTORY_OK=Sometimes
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
old_name=HEAD
old=$(git-rev-parse --verify $old_name 2>/dev/null)
diff --git a/git-clean.sh b/git-clean.sh
index 3834323..7a7ce6e 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -13,7 +13,7 @@ LONG_USAGE='Clean untracked files from the working directory
When optional <paths>... arguments are given, the paths
affected are further limited to those that match them.'
SUBDIRECTORY_OK=Yes
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
ignored=
ignoredonly=
diff --git a/git-commit.sh b/git-commit.sh
index 81c3a0c..5a388f5 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -5,7 +5,7 @@
USAGE='[-a] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit>] [-u] [--amend] [-e] [--author <author>] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
git-rev-parse --verify HEAD >/dev/null 2>&1 || initial_commit=t
branch=$(GIT_DIR="$GIT_DIR" git-symbolic-ref HEAD)
diff --git a/git-fetch.sh b/git-fetch.sh
index 4eecf14..efe44ea 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -2,7 +2,7 @@
#
USAGE='<fetch-options> <repository> <refspec>...'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
. git-parse-remote
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 16cd351..ae9fbc1 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -6,7 +6,7 @@ USAGE='[--start] [--stop] [--restart]
[--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
[--module-path=<path> (for Apache2 only)]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
case "$GIT_DIR" in
/*)
diff --git a/git-lost-found.sh b/git-lost-found.sh
index b928f2c..5f612f2 100755
--- a/git-lost-found.sh
+++ b/git-lost-found.sh
@@ -2,7 +2,7 @@
USAGE=''
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
if [ "$#" != "0" ]
then
diff --git a/git-merge.sh b/git-merge.sh
index 272f004..07ceaf0 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -5,7 +5,7 @@
USAGE='[-n] [--no-commit] [--squash] [-s <strategy>] [--reflog-action=<action>] [-m=<merge-message>] <commit>+'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
LF='
'
diff --git a/git-pull.sh b/git-pull.sh
index e23beb6..8c0f292 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -6,7 +6,7 @@
USAGE='[-n | --no-summary] [--no-commit] [-s strategy]... [<fetch-options>] <repo> <head>...'
LONG_USAGE='Fetch one or more remote refs and merge it/them into the current HEAD.'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
strategy_args= no_summary= no_commit= squash=
while case "$#,$1" in 0) break ;; *,-*) ;; *) break ;; esac
diff --git a/git-quiltimport.sh b/git-quiltimport.sh
index 10135da..2f1e7b7 100755
--- a/git-quiltimport.sh
+++ b/git-quiltimport.sh
@@ -1,7 +1,7 @@
#!/bin/sh
USAGE='--dry-run --author <author> --patches </path/to/quilt/patch/directory>'
SUBDIRECTORY_ON=Yes
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
dry_run=""
quilt_author=""
diff --git a/git-rebase.sh b/git-rebase.sh
index 25530df..3220291 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -27,7 +27,7 @@ Example: git-rebase master~1 topic
/ --> /
D---E---F---G master D---E---F---G master
'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
RESOLVEMSG="
When you have resolved this problem run \"git rebase --continue\".
diff --git a/git-repack.sh b/git-repack.sh
index f150a55..e85f0b6 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -5,7 +5,7 @@
USAGE='[-a] [-d] [-f] [-l] [-n] [-q] [--window=N] [--depth=N]'
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
no_update_info= all_into_one= remove_redundant=
local= quiet= no_reuse_delta= extra=
diff --git a/git-request-pull.sh b/git-request-pull.sh
index 4eacc3a..fd02d55 100755
--- a/git-request-pull.sh
+++ b/git-request-pull.sh
@@ -8,7 +8,7 @@ USAGE='<commit> <url> [<head>]'
LONG_USAGE='Summarizes the changes since <commit> to the standard output,
and includes <url> in the message generated.'
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
revision=$1
url=$2
diff --git a/git-reset.sh b/git-reset.sh
index 3133b5b..9e3dd5b 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -1,7 +1,7 @@
#!/bin/sh
USAGE='[--mixed | --soft | --hard] [<commit-ish>]'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
update=
reset_type=--mixed
diff --git a/git-resolve.sh b/git-resolve.sh
index 36b90e3..4c2d7da 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -10,7 +10,7 @@ echo 'WARNING: Please use git-merge or git-pull instead.' >&2
sleep 2
USAGE='<head> <remote> <merge-message>'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
dropheads() {
rm -f -- "$GIT_DIR/MERGE_HEAD" \
diff --git a/git-revert.sh b/git-revert.sh
index 6eab3c7..8a30297 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -18,7 +18,7 @@ case "$0" in
* )
die "What are you talking about?" ;;
esac
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
no_commit=
while case "$#" in 0) break ;; esac
diff --git a/git-tag.sh b/git-tag.sh
index d53f94c..a7d6223 100755
--- a/git-tag.sh
+++ b/git-tag.sh
@@ -3,7 +3,7 @@
USAGE='-l [<pattern>] | [-a | -s | -u <key-id>] [-f | -d] [-m <msg>] <tagname> [<head>]'
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
message_given=
annotate=
diff --git a/git-verify-tag.sh b/git-verify-tag.sh
index 36f171b..d265150 100755
--- a/git-verify-tag.sh
+++ b/git-verify-tag.sh
@@ -2,7 +2,7 @@
USAGE='<tag>'
SUBDIRECTORY_OK='Yes'
-. git-sh-setup
+. @@GIT_datadir@@/git-sh-setup.sh
verbose=
while case $# in 0) break;; esac
--
1.4.4.1.gc9922-dirty
--
^ permalink raw reply related
* Re: [PATCH] cvs-migration document: make the need for "push" more obvious
From: Jakub Narebski @ 2006-12-06 12:32 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0612061325320.28348@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin wrote:
> + * Since every working tree contains a repository, a commit will not
> + publish your changes; it will only create a revision. You have to
> + "push" your changes to a public repository to make them visible
> + to others.
> +
I'm not sure about context of this addition, but it is simply not
true if you publish your working repository. Granted, usually one
sets up bare public publishing repository...
By publish I mean set up http(s):// or git://, or ssh+git://, or local
transport.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ 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