* Re: [PATCH] Invoke git-repo-config directly.
From: Andreas Ericsson @ 2006-03-16 14:39 UTC (permalink / raw)
To: Timo Hirvonen; +Cc: git
In-Reply-To: <20060316162709.6f383f95.tihirvon@gmail.com>
Timo Hirvonen wrote:
> On Thu, 16 Mar 2006 12:53:20 +0000 (UTC)
> Mark Wooding <mdw@distorted.org.uk> wrote:
>
>
>>By the way, am I the only person who /likes/ having all the git-*
>>programs on his path? It makes shell completion work fairly well
>>without having to install strange completion scripts which get out of
>>date for one thing.
>
>
> I like git-* for the same reason. But if git potty had aliases for long
> commands then git-* commands would become irrelevant. Especially
> "git co" would be nice. It even would be faster to type than
> git-ch<tab>c<tab>o<tab> ;)
>
It would indeed, and it should also be fairly trivial. However, adding
short-hands that are identical with cvs and svn but does a totally
different thing (well, not really different, but cvs users will be
surprised) is not necessarily a good thing.
It would be better, imo, to add ambiguity detection for commands that
lacks an exact match. That way "git br" and "git branch" would be
identical and the logic only needs doing once. I'm not terribly excited
about it though, so...
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-reset and clones
From: Andreas Ericsson @ 2006-03-16 14:53 UTC (permalink / raw)
To: Paul Jakma; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org>
Paul Jakma wrote:
> Hi,
>
> Next dumb question:
>
> If a git repository has a reset HEAD~X done, then any later pulls in
> clone repositories get /really/ upset, with:
>
> $ git pull
> * refs/heads/origin: does not fast forward to branch 'master' of
> /home/paul/foo-git/;
>
> Type of thing. This seems to be a similar issue to:
>
> http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
>
> The question is has this improved at all since last year? Is there
> anything the origin repository maintainer (the one who did reset) can do
> to recover from this?
>
> I'm guessing the answer is:
>
> Yes:
>
> 1. where git-reset has already been done, manually update the
> refs back to the previous HEAD
> 2. then use git-revert, and continue to use git-revert only.
>
> My question then would be, presuming some innocent repository maintainer
> has already done 1, what's the easiest way to accomplish 1?
>
> (they shouldn't have done it obviously, but assume they're git newbies,
> made an honest mistake and now need to recover, preferably without
> having to involve those who pull).
>
I *think* this should work. Get a backup before trying. Note that I'm
assuming "git reset" hasn't been run several times, or you'll have to
replace ORIGIN with whatever HEAD pointed to before the first reset.
In mothership-repo:
git checkout master
git branch next-master ORIGIN
git rebase next-master; # fix conflicts and commit
git branch -d master
git checkout -b master next-master
git -d next-master
git revert (the bad commits)
Some shortcuts can be taken if we're not to use git commands the entire
way, but this is easier to explain to those newbie-ish people you mentioned.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-reset and clones
From: sean @ 2006-03-16 14:52 UTC (permalink / raw)
To: Paul Jakma; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org>
On Thu, 16 Mar 2006 14:34:42 +0000 (GMT)
Paul Jakma <paul@clubi.ie> wrote:
> If a git repository has a reset HEAD~X done, then any later pulls in
> clone repositories get /really/ upset, with:
>
> $ git pull
> * refs/heads/origin: does not fast forward to branch 'master' of
> /home/paul/foo-git/;
>
> Type of thing. This seems to be a similar issue to:
>
> http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
>
> The question is has this improved at all since last year? Is there
> anything the origin repository maintainer (the one who did reset) can
> do to recover from this?
It's still not a recommended operation on a repository that is pulled
by others. If you realize you made a mistake by resetting the head,
you can undo the operation afterward with:
$ git reset ORIG_HEAD
Sean
^ permalink raw reply
* Re: git-reset and clones
From: Andreas Ericsson @ 2006-03-16 14:59 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Paul Jakma, git list
In-Reply-To: <44197C04.5080400@op5.se>
Andreas Ericsson wrote:
>
> git branch next-master ORIGIN
s/ORIGIN/ORIG_HEAD/
otherwise the advice still applies.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-reset and clones
From: sean @ 2006-03-16 15:21 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: paul, git
In-Reply-To: <44197C04.5080400@op5.se>
On Thu, 16 Mar 2006 15:53:56 +0100
Andreas Ericsson <ae@op5.se> wrote:
> In mothership-repo:
> git checkout master
> git branch next-master ORIGIN
> git rebase next-master; # fix conflicts and commit
> git branch -d master
> git checkout -b master next-master
> git -d next-master
> git revert (the bad commits)
Downstream repos may still be broken afterward though; not much
you can do about that unfortunately.
Sean
^ permalink raw reply
* Re: git-reset and clones
From: Paul Jakma @ 2006-03-16 15:48 UTC (permalink / raw)
To: sean; +Cc: git
In-Reply-To: <BAYC1-PASMTP09E59C4F23C4CDF45B1C42AEE70@CEZ.ICE>
On Thu, 16 Mar 2006, sean wrote:
> $ git reset ORIG_HEAD
Ah, of course :).
Thanks.
regards,
--
Paul Jakma paul@clubi.ie paul@jakma.org Key ID: 64A2FF6A
Fortune:
There's no such thing as pure pleasure; some anxiety always goes with it.
^ permalink raw reply
* First dumb question to the list :)
From: Paolo Ciarrocchi @ 2006-03-16 17:49 UTC (permalink / raw)
To: git
Hi all,
I just installed git and cogito from Ubuntu Drapper,
performed a simple cg-clone git://URItoLinus2.6 linux2.6
and aftwer more or less one hour I had a clone of Linus 2.6 tree.
So far so good.
What I want to do is to simply keep my repository aligned with Linus
so I simply have to do:
cd linus2.6
cg-fetch
How can I confg git in order to, by default, use git instead of rsync ?
Now my dumb question is... since I want to build that kernel do I have
to locally clone/copy it in order to don't modify any file on my local
tree?
If I don't do so, I guess git/cogito will not be happy when I run
cg-fetch, right?
Thanks!
--
Paolo
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Jon Loeliger @ 2006-03-16 19:27 UTC (permalink / raw)
To: Git List
In-Reply-To: <7vmzfq8zmr.fsf@assigned-by-dhcp.cox.net>
On Thu, 2006-03-16 at 04:14, Junio C Hamano wrote:
> And the second issue is the last point in the "implications"
> list above. You are right, and I stand corrected. Our scripts
> should consistently use dash form.
>
> One thing that bothers me is that we need to keep encouraging
> users to use dashless form from the command line, while we
> update our scripts to use dash form. What a contradicting and
> confusing situation X-<.
I think it has a philosophical rationale, though.
While we want to proved an abstraction layer to the
user through the "git" wrapper, we still want to be
precise internally within the scripts themselves.
Or so.
jdl
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Jon Loeliger @ 2006-03-16 19:32 UTC (permalink / raw)
To: Git List
In-Reply-To: <1142537257.17536.137.camel@cashmere.sps.mot.com>
On Thu, 2006-03-16 at 13:27, Jon Loeliger wrote:
> While we want to proved an abstraction layer to the
> user through the "git" wrapper, we still want to be
> precise internally within the scripts themselves.
Hey! Nice English there, Jon!
s/proved/provide
jdl
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Qingning Huo @ 2006-03-16 20:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v64mebxsu.fsf@assigned-by-dhcp.cox.net>
On Thu, Mar 16, 2006 at 12:26:09AM -0800, Junio C Hamano wrote:
>
> We could probably define a shell function that looks like:
>
> git_exec () {
> cmd="$1"
> shift
> case "${GIT_EXEC_PATH+set}" in
> set) ;;
> *) GIT_EXEC_PATH='@@GIT_EXEC_PATH@@' ;;
> esac
> "$GIT_EXEC_PATH/git-$cmd" "$@"
> }
>
> in git-sh-setup [*1*], and then rewrite the above to something
> like this instead:
>
> diff --git a/git-commit.sh b/git-commit.sh
> index 330a434..8a73420 100755
> --- a/git-commit.sh
> +++ b/git-commit.sh
> ...
> @@ -115,7 +115,7 @@ run_status () {
> echo '#
> # Initial commit
> #'
> - git-ls-files |
> + git_exec ls-files |
> sed -e '
> s/\\/\\\\/g
> s/ /\\ /g
> @@ -126,7 +126,7 @@ run_status () {
> committable="$?"
> fi
>
> - git-diff-files --name-status |
> + git_exec diff-files --name-status |
> sed -e '
> s/\\/\\\\/g
> s/ /\\ /g
> ...
>
> But that does not cover Perl nor Python scripts, and does not
> address the ugliness either.
This is similiar to what I had in mind when I recommended the full path
approach. Perl or Python should be able to do the similiar. I have no
comment on the ugliness. The functionality and effeciency of the
program is more important to me. But I do recognize the difficulties of
changing all scripts overnight.
Anyway, there are at least other two ways to solve my problem. (a)
setup PATH in git-sh-setup, or (b) consistently use git-command form in
scripts. Even before their implementation, I can still use "git push".
Qingning
^ permalink raw reply
* Re: First dumb question to the list :)
From: Alex Riesen @ 2006-03-16 22:11 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: git
In-Reply-To: <4d8e3fd30603160949l655c4f9blb1e202eaf22fbfe@mail.gmail.com>
Paolo Ciarrocchi, Thu, Mar 16, 2006 18:49:16 +0100:
> What I want to do is to simply keep my repository aligned with Linus
> so I simply have to do:
> cd linus2.6
> cg-fetch
Or "git pull"
> How can I confg git in order to, by default, use git instead of rsync ?
By editing .git/remotes/origin and replacing "rsync://rsync." with
"git://git." (I think the rest is identical, but you better check).
> Now my dumb question is... since I want to build that kernel do I have
> to locally clone/copy it in order to don't modify any file on my local
> tree?
No. As long you don't modify anything under .git you can always get to
any state of your kernel tree you ever had (assuming you _use_ git, of
course).
Or you can just revert your changes after you've played enough with
them: "git reset --hard".
^ permalink raw reply
* Re: git-reset and clones
From: Junio C Hamano @ 2006-03-17 2:10 UTC (permalink / raw)
To: paul; +Cc: git list
In-Reply-To: <Pine.LNX.4.64.0603161424310.5276@sheen.jakma.org>
Paul Jakma <paul@clubi.ie> writes:
> If a git repository has a reset HEAD~X done, then any later pulls in
> clone repositories get /really/ upset, with:
>
> $ git pull
> * refs/heads/origin: does not fast forward to branch 'master' of
> /home/paul/foo-git/;
>
> Type of thing. This seems to be a similar issue to:
>
> http://www.gelato.unsw.edu.au/archives/git/0510/10767.html
>
> The question is has this improved at all since last year? Is there
> anything the origin repository maintainer (the one who did reset) can
> do to recover from this?
You used to have something like this:
o---o---o---A
/ ^ your HEAD used to point at here
---o---o---o
and you forgot other people already have the commit chain up to
commit A. But you rewound and did cleanups:
o---o---o---A
/
---o---o---o---o---o---B
^ your HEAD now points at here
People who track your HEAD have A and your updated head B does
not fast forward. Oops.
The recovery consists of two steps. The first step is more
important. To find what commits you lost that others already
may have. You may be lucky and remember A's commit object name,
but when I did that I had to ask around on the list X-<.
The second step is a single command:
$ git merge -s ours 'Graft the lost side branch back in' \
HEAD A
where A is the object name of that commit. On your current
branch, this creates a merge commit between A and B (your
current HEAD), taking the tree object from B.
o---o---o---A
/ \
---o---o---o---o---o---B---M
You want to keep the contents of the cleaned-up HEAD, so that is
why you are taking the tree from B. With this commit M, you are
telling the outside world that it is OK if they start from a
commit on the now-recovered side branch.
If the tree of A and B exactly match, further merges with people
starting from A branch would not have conflicts. If the
difference between A and B are mostly clean-ups, automerge would
lose dirtiness you cleaned-up when they update to your new HEAD
(because the transition from A to M reverts the dirtiness, which
is what your clean-up was about), which is what you want.
^ permalink raw reply
* Re: [PATCH] Invoke git-repo-config directly.
From: Junio C Hamano @ 2006-03-17 2:10 UTC (permalink / raw)
To: git
In-Reply-To: <44196DE7.8010205@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>> . ${GIT_EXEC_PATH-'@@@GIT_EXEC_PATH@@@'}/git-sh-setup
>> isn't too grim, and shows how the git_exec shell function can be made
>> somewhat terser.
>
> But it breaks the convenience when testing.
I think that's OK. When I test things in the build directory
without installing I would usually do:
$ GIT_EXEC_PATH=`pwd` PATH=`pwd`:/usr/bin:/bin ./git-cmd-to-test
and the above would not break things.
^ permalink raw reply
* git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 2:37 UTC (permalink / raw)
To: git
Starting recently, git-cvsimport has always ended with "you
may need to merge manually". Why? It worked before. What
is it doing now?
$ cd /home/merlyn/Git/stonehenge.git || exit 1
$ git-cvsimport -v -k -o master -d /web/cvs stonehenge
.
.
.
skip patchset 323: 1142297290 before 1142351976
Fetching htdocs/courses.html v 1.4
Update htdocs/courses.html: 8767 bytes
Fetching htdocs/rates.html v 1.2
Update htdocs/rates.html: 2043 bytes
Tree ID 38280334da5eaa4fd80fe1011e63db4b527f1d13
Parent ID e93de754181fe963b8623423f509540021caead0
Committed patch 324 (master 2006-03-16 18:14:31)
Commit ID 985ca72d4e8a07d4189794231f035bac63c9e91d
DONE; you may need to merge manually.
$ git-status
#
# Updated but not checked in:
# (will commit)
#
# modified: htdocs/courses.html
# modified: htdocs/rates.html
#
Right... why didn't it commit those? I'm having to issue "fake"
commits now, so I've lost the cvs-log comments that were formerly
very complete and cool.
--
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: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 2:43 UTC (permalink / raw)
To: git
In-Reply-To: <86veud23v0.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Starting recently, git-cvsimport has always ended with "you
> may need to merge manually". Why? It worked before. What
> is it doing now?
>
> $ cd /home/merlyn/Git/stonehenge.git || exit 1
> $ git-cvsimport -v -k -o master -d /web/cvs stonehenge
> .
> .
> .
> skip patchset 323: 1142297290 before 1142351976
> Fetching htdocs/courses.html v 1.4
> Update htdocs/courses.html: 8767 bytes
> Fetching htdocs/rates.html v 1.2
> Update htdocs/rates.html: 2043 bytes
> Tree ID 38280334da5eaa4fd80fe1011e63db4b527f1d13
> Parent ID e93de754181fe963b8623423f509540021caead0
> Committed patch 324 (master 2006-03-16 18:14:31)
> Commit ID 985ca72d4e8a07d4189794231f035bac63c9e91d
> DONE; you may need to merge manually.
> $ git-status
> #
> # Updated but not checked in:
> # (will commit)
> #
> # modified: htdocs/courses.html
> # modified: htdocs/rates.html
> #
>
> Right... why didn't it commit those? I'm having to issue "fake"
> commits now, so I've lost the cvs-log comments that were formerly
> very complete and cool.
I do not use cvsimport but I wonder what Commit ID 985ca7
contains. Can you try "git show 985ca7" and see if that is the
commit you want?
Also, which branch are you on when you run git-cvsimport, and
which branch did the commit 985ca7 go? I suspect it is storing
the tip commit 985ca7 to a branch that you are _not_ on
currently, but refraining from merging that to your current
branch, or something like that.
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 2:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vu09x7puo.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
>> Right... why didn't it commit those? I'm having to issue "fake"
>> commits now, so I've lost the cvs-log comments that were formerly
>> very complete and cool.
Junio> I do not use cvsimport but I wonder what Commit ID 985ca7
Junio> contains. Can you try "git show 985ca7" and see if that is the
Junio> commit you want?
To bring the tree clean, I issued "git commit -a -m 'cvs sync'", and
"git-whatchanged -p" shows the most recent commit with the diff actually
*backed out* the most recent change in CVS, and the next change down was
actually the good one. Weird. Do I need to start all over again?
Junio> Also, which branch are you on when you run git-cvsimport, and
Junio> which branch did the commit 985ca7 go? I suspect it is storing
Junio> the tip commit 985ca7 to a branch that you are _not_ on
Junio> currently, but refraining from merging that to your current
Junio> branch, or something like that.
Nope. I'm on "master", and it should be writing "master".
--
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: git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 3:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <86r75122yj.fsf@blue.stonehenge.com>
>>>>> "Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> To bring the tree clean, I issued "git commit -a -m 'cvs sync'", and
Randal> "git-whatchanged -p" shows the most recent commit with the diff actually
Randal> *backed out* the most recent change in CVS, and the next change down was
Randal> actually the good one. Weird. Do I need to start all over again?
Junio> Also, which branch are you on when you run git-cvsimport, and
Junio> which branch did the commit 985ca7 go? I suspect it is storing
Junio> the tip commit 985ca7 to a branch that you are _not_ on
Junio> currently, but refraining from merging that to your current
Junio> branch, or something like that.
Randal> Nope. I'm on "master", and it should be writing "master".
And now for grins, I did "git-reset --hard 'HEAD^^^^^^^'", verified
that the data was in a sensible state from a few weeks back, then
did the git-cvsimport, and it replayed the CVS changes to bring it current.
git-status showed that seven files were dirty, and "git-reset --hard"
cleared that, and the files were in the right state.
Huh?
--
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: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 3:23 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git, Matthias Urlichs
In-Reply-To: <86r75122yj.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Junio> I do not use cvsimport but I wonder what Commit ID 985ca7
> Junio> contains. Can you try "git show 985ca7" and see if that is the
> Junio> commit you want?
>
> To bring the tree clean, I issued "git commit -a -m 'cvs sync'", and
> "git-whatchanged -p" shows the most recent commit with the diff actually
> *backed out* the most recent change in CVS, and the next change down was
> actually the good one. Weird. Do I need to start all over again?
So the commit ID reported before the command says Done. was
actually what you wanted, but that latest tree was not checked
out cvsimport, so "git status" reported "you have these changes"
(it should have said "you have these backed-out", but there is
no way for it to know), and obviously your commit on top of that
is to back it out.
I just tried it on a copy of my day-job CVS repository. Indeed
what it does seem quite strange.
...
skip patchset 1019: 1142562992 before 1142562992
skip patchset 1020: 1142563093 before 1142563093
Fetching Makefile v 1.10
Update Makefile: 871 bytes
Tree ID 4c51717e01fb08b6d15bc6e35d48142d2d5b94e7
Parent ID 98d49aa57b93552cea82ce20c880bad4bcc5ebfc
Committed patch 1021 (master 2006-03-17 03:04:31)
Commit ID ad6c4fb908df7057d5564bf22cf9e0f9f3e743f2
DONE
It updated the 'master' branch head, it reported the tip commit
ID before saying DONE, and that commit ID is stored in
refs/heads/master. However, it does not seem to touch index nor
working tree files (I did not get "you may need to do merge"
message, by the way).
Since I know I was just trying things out, I do not care what is
in my index nor in the working tree files, so I could at this
point say:
$ git reset --hard
to sync the master tree, but in general you may be running
cvsimport into a dirty tree, in which case you are screwed.
I think reverting this commit would help, but I do not remember
offhand what the breakage this patch was trying to fix.
commit a541211ef4136eb7464c4466d20b60b8580efc44
Author: Matthias Urlichs <smurf@smurf.noris.de>
Date: Tue Mar 7 10:08:34 2006 +0100
cvsimport: Remove master-updating code
The code which tried to update the master branch was somewhat broken.
=> People should do that manually, with "git merge".
Signed-off-by: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... Ugh, and after I wrote all of the above, the version of git
I have at work predates that commit X-<. So maybe this was
fixed with that commit, and you are expected to say:
$ git pull . origin
assuming that you are on "master" branch and cvsimoprt tracks
CVS head with "origin" branch, that is.
Smurf, help?
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 3:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Matthias Urlichs
In-Reply-To: <7vk6at7o06.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> Since I know I was just trying things out, I do not care what is
Junio> in my index nor in the working tree files, so I could at this
Junio> point say:
Junio> $ git reset --hard
Junio> to sync the master tree, but in general you may be running
Junio> cvsimport into a dirty tree, in which case you are screwed.
Yeah, this doesn't make sense. It used to "Just Work". I can
certainly add "git reset --hard" to my workflow, if that's the real
work around. And if so, the manpage should document that.
Junio> ... Ugh, and after I wrote all of the above, the version of git
Junio> I have at work predates that commit X-<. So maybe this was
Junio> fixed with that commit, and you are expected to say:
Junio> $ git pull . origin
Junio> assuming that you are on "master" branch and cvsimoprt tracks
Junio> CVS head with "origin" branch, that is.
Again, if that's the case, the manpage should say what's really
happening, so as not to confuse dumb people like me. :)
--
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: git-cvsimport "you may need to merge manually"
From: Junio C Hamano @ 2006-03-17 4:16 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: git
In-Reply-To: <86fylh20x6.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
> Yeah, this doesn't make sense. It used to "Just Work". I can
> certainly add "git reset --hard" to my workflow, if that's the real
> work around. And if so, the manpage should document that.
That should _not_ be the solution.
I think the behaviour we are seeing does not make much sense.
I'll take a deeper look at it tonight (or tomorrow if I am
unlucky), if nobody beats me to it.
Sorry about the breakage.
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: Randal L. Schwartz @ 2006-03-17 4:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfylh7lkh.fsf@assigned-by-dhcp.cox.net>
>>>>> "Junio" == Junio C Hamano <junkio@cox.net> writes:
Junio> I think the behaviour we are seeing does not make much sense.
Junio> I'll take a deeper look at it tonight (or tomorrow if I am
Junio> unlucky), if nobody beats me to it.
Junio> Sorry about the breakage.
No, *thanks* for looking at it. Your tireless contributions
are well appreciated.
--
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
* [RFC] exit code from git fetch
From: Junio C Hamano @ 2006-03-17 6:01 UTC (permalink / raw)
To: git
When "git fetch" fails because the remote unexpectedly rewound
its head and fast-forward check triggers, we issued a warning
but kept going anyway. This proposed patch makes the command
exit with non-zero status.
I think this is a sensible change and makes it easier to use
from scripts, but it might have other issues. For example when
you are tracking more than one heads from the remote, and the
first one fast-forwards but the second one doesn't, it updates
the first one and then stops. If we happen to process the
rewound one first, neither is updated because we stop at the
first one. I think this particular discrepancy probably is not
worth worrying about, but there may be other more serious
fallouts we need to fix if we did this.
Comments?
---
diff --git a/git-fetch.sh b/git-fetch.sh
index 0346d4a..6835634 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -179,6 +179,7 @@ fast_forward_local () {
;;
*)
echo >&2 " not updating."
+ exit 1
;;
esac
}
^ permalink raw reply related
* Re: [RFC] exit code from git fetch
From: Andrew Morton @ 2006-03-17 6:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vek116253.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
>
> When "git fetch" fails because the remote unexpectedly rewound
> its head and fast-forward check triggers, we issued a warning
> but kept going anyway. This proposed patch makes the command
> exit with non-zero status.
>
> I think this is a sensible change and makes it easier to use
> from scripts, but it might have other issues. For example when
> you are tracking more than one heads from the remote, and the
> first one fast-forwards but the second one doesn't, it updates
> the first one and then stops. If we happen to process the
> rewound one first, neither is updated because we stop at the
> first one. I think this particular discrepancy probably is not
> worth worrying about, but there may be other more serious
> fallouts we need to fix if we did this.
>
> Comments?
>
> ---
> diff --git a/git-fetch.sh b/git-fetch.sh
> index 0346d4a..6835634 100755
> --- a/git-fetch.sh
> +++ b/git-fetch.sh
> @@ -179,6 +179,7 @@ fast_forward_local () {
> ;;
> *)
> echo >&2 " not updating."
> + exit 1
> ;;
> esac
> }
Thanks ;)
I guess you could exit with different exit codes according to what
went wrong. So if a script writer really cared about the fine details,
appropriate decisions could be made.
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: smurf @ 2006-03-17 6:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Randal L. Schwartz, git
In-Reply-To: <7vk6at7o06.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 782 bytes --]
Hi,
Junio C Hamano:
> ... Ugh, and after I wrote all of the above, the version of git
> I have at work predates that commit X-<. So maybe this was
> fixed with that commit, and you are expected to say:
>
> $ git pull . origin
>
Exactly.
> assuming that you are on "master" branch and cvsimoprt tracks
> CVS head with "origin" branch, that is.
>
> Smurf, help?
>
What for? You got it, after all. *g*
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
Sally sued for support; she was claimin'
Phil had fathered her baby (named Damon).
She said, "I ought to know,"
As she pointed below.
"'Cause this is the box that he came in."
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
* Re: git-cvsimport "you may need to merge manually"
From: smurf @ 2006-03-17 7:26 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Junio C Hamano, git
In-Reply-To: <86fylh20x6.fsf@blue.stonehenge.com>
[-- Attachment #1: Type: text/plain, Size: 910 bytes --]
Hi,
Randal L. Schwartz:
> Yeah, this doesn't make sense. It used to "Just Work". I can
> certainly add "git reset --hard" to my workflow, if that's the real
> work around. And if so, the manpage should document that.
>
The real workaround is not to import into live branches,
which is not a git-cvs-specific problem, so I didn't add that
to its manpage.
I'm not opposed to an appropriate patch if you think its necessary.
If you do, keep in mind that there are other git-*import scripts out
there which presumably have the same problem. ;-)
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
That which is good to be done, cannot be done too soon; and if it is
neglected to be done early, it will frequently happen that it will not be done
at all.
-- Bishop Mant
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox