* Re: Unable to checkout a branch after cloning
From: Matthew Lear @ 2009-08-11 14:54 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4A818119.6000302@drmicha.warpmail.net>
Michael J Gruber wrote:
> Matthew Lear venit, vidit, dixit 11.08.2009 16:24:
>> Michael J Gruber wrote:
>>> Matthew Lear venit, vidit, dixit 11.08.2009 14:17:
>>>> Hi Michael - thanks for your reply.
>>>> Michael J Gruber wrote:
>>>>> Matthew Lear venit, vidit, dixit 11.08.2009 12:10:
>>>>>> Hi all,
>>>>>>
>>>>>> Apologies for perhaps a silly question, but I'd very much appreciate a
>>>>>> little bit of assistance.
>>>>>>
>>>>>> I've set up a git repository on a machine accessible from the internet
>>>>>> with the intention to share code with another developer. We clone the
>>>>>> repository, commit changes then push back as you'd expect. The server
>>>>>> runs gitweb for repository browsing. Clients are running git v1.6.0.6.
>>>>>>
>>>>>> When I created the initial repository I also created two additional
>>>>>> branches - 'upstream' and 'custom'. The former is to act as a 'vendor
>>>>>> branch' and the latter contains code specific to the custom platform
>>>>>> that we're working on. The master branch contains merges from the
>>>>>> upstream branch and also changes that we've made. The custom branch
>>>>>> contains merges from master with custom platform specific changes.
>>>>>>
>>>>>> I've committed changes and on both upstream and custom branches as work
>>>>>> progressed, merged them where appropriate, added tags etc and pushed
>>>>>> everything to the remote repository. No problem. I can view the
>>>>>> branches, tags etc in gitweb and everything looks fine.
>>>>>>
>>>>>> However, I can clone a new repository just fine but I'm unable to
>>>>>> checkout the upstream or custom branches. After cloning, only the master
>>>>>> branch is available, ie:
>>>>>>
>>>>>>> git checkout upstream
>>>>>> error: pathspec 'upstream' did not match any file(s) known to git.
>>>>>>
>>>>>>> git branch -a
>>>>>> * master
>>>>>> origin/HEAD
>>>>>> origin/master
>>>>>>
>>>>>> .git/config:
>>>>>>
>>>>>> [core]
>>>>>> repositoryformatversion = 0
>>>>>> filemode = true
>>>>>> bare = false
>>>>>> logallrefupdates = true
>>>>>> [remote "origin"]
>>>>>> url = https://mysite/git/project.git
>>>>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>>>>> [branch "master"]
>>>>>> remote = origin
>>>>>> merge = refs/heads/master
>>>>>>
>>>>>> But the initial local repository where I work (ie created the branches,
>>>>>> committed changes, tag, push etc) seems to be fine, ie
>>>>>>
>>>>>>> git checkout upstream
>>>>>> Switched to branch "upstream"
>>>>>>
>>>>>>> git branch -a
>>>>>> custom
>>>>>> * master
>>>>>> upstream
>>>>>>
>>>>>> .git/config:
>>>>>>
>>>>>> [core]
>>>>>> repositoryformatversion = 0
>>>>>> filemode = true
>>>>>> bare = false
>>>>>> logallrefupdates = true
>>>>>> [remote "origin"]
>>>>>> url = https://mysite/git/project.git
>>>>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>>>>>
>>>>>>
>>>>>> Developers need to be able to clone the repository and then switch to
>>>>>> the appropriate branch in order to work. However it seems that after a
>>>>>> clone, only the master branch is available.
>>>>>>
>>>>>> Why is this?
>>>>>>
>>>>>> Any help would be much appreciated indeed.
>>>>> If I understand you correctly you have 3 repos: the "initial" one on
>>>>> which everything is as expected, the "server" one and the "new clone"
>>>>> which is missing branches.
>>>> Yes, that's correct.
>>>>
>>>>> Now: How's the server one doing, i.e. what does "git ls-remote
>>>>> https://mysite/git/project.git" say? I suspect that one either does not
>>>>> have the branches (you haven't told us how you pushed) or in the wrong
>>>>> place (remotes/).
>>>>> git ls-remote https://mysite/git/project.git
>>>> 065f5f13d5f8e786729db1623cc53767c963e959 HEAD
>>>> 065f5f13d5f8e786729db1623cc53767c963e959 refs/heads/master
>>>>
>>>> Hmm. So it seems that the branches are not actually on the server
>>>> repository. So how come I can see them with gitweb..?
>>>>
>>>> I've been pushing from the 'initial' repository with git push --all and
>>>> git push --tags.
>>>>
>>>> However, when I try a git push from the initial repository I get the
>>>> following:
>>>>
>>>>> git push --all
>>>> Fetching remote heads...
>>>> refs/
>>>> refs/heads/
>>>> refs/tags/
>>>> 'refs/heads/custom': up-to-date
>>>> 'refs/heads/master': up-to-date
>>>> 'refs/heads/upstream': up-to-date
>>>>
>>>> -- Matt
>>> Does the situation improve if, on the server, you run git
>>> update-server-info? Do you have a post-update hook there?
>>>
>>> Michael
>> I ran git update-server-info on the server machine. I read about this
>> and thought I had made the necessary change to add it as a post commit
>> hook. I guess not (so will double check). However, something is still
>> not quite right upon cloning:
>>
>>> git clone https://mysite/git/project.git
>> Initialized empty Git repository in /home/matt/git-repos/project/.git/
>> Checking out files: 100% (26747/26747), done.
>>
>>> git branch -a
>> * master
>> origin/HEAD
>> origin/custom
>> origin/master
>> origin/upstream
>
> We're making progress, that's good ;)
> Re. the hook: Make sure it's executable and the extension .sample is
> removed.
>
> (gitweb and http access are two different things, which is a common
> source of confusion)
>
>>> git checkout upstream
>> error: pathspec 'upstream' did not match any file(s) known to git.
>>
>> So it seems that the cloned repository is now aware of the branches
>> (improvement) but I'm still unable to switch to a branch.
>>
>> This is probably now a case of me reading the manual but I'd appreciate
>> your thoughts nonetheless.
>
> Well, there is no branch names upstream. There's only one named
> origin/upstream, and it's a remote branch. Meaning: checking it out will
> produce a detached head, which may or may not be what you want. If you
> want to create a branch to work on upstream, do something like
>
> git checkout -b myupstream origin/upstream
>
> (git does something like git checkout -b master origin/master
> automatically when cloning, which I think is a common source of confusion)
I've fixed the server hook scripts (embarrassingly, they were executable
but still had the .sample suffix - that's really not going to work!).
I've actually just read through the manual about detached heads. This is
not what I want but your solution to create a branch to track the remote
branch is exactly what I need.
Where ever you are in the world, many thanks for your continued help and
assistance. Very much appreciated indeed.
Cheers,
-- Matt
^ permalink raw reply
* [PATCH] Re: [TRIVIAL] Documentation: add: <filepattern>... is optional
From: Nicolas Sebrecht @ 2009-08-11 14:50 UTC (permalink / raw)
To: Paul Bolle; +Cc: Junio C Hamano, git
In-Reply-To: <1249995790.1589.2.camel@localhost.localdomain>
The 11/08/09, Paul Bolle wrote:
> <filepattern>... is optional (e.g. when the --all or --update
> options are used) so use square brackets in the synopsis.
So <filepattern> is needed in all other cases. The '-u' description
already has
" If no paths are specified, all tracked files in the current
directory and its subdirectories are updated. "
and '-a' refers to '-u'
"(same as --update)"
.
--
Nicolas Sebrecht
^ permalink raw reply
* [PATCH] Re: [TRIVIAL] Documentation: merge: one <remote> is required
From: Nicolas Sebrecht @ 2009-08-11 14:42 UTC (permalink / raw)
To: Paul Bolle; +Cc: Junio C Hamano, git
In-Reply-To: <1249995838.1589.3.camel@localhost.localdomain>
The 11/08/09, Paul Bolle wrote:
> merge only requires one <remote>, so "<remote>..." should be used in the
> synopsis (and not "<remote> <remote>...").
>
<...>
> 'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
> - [-m <msg>] <remote> <remote>...
> + [-m <msg>] <remote>...
> 'git merge' <msg> HEAD <remote>...
Shoudn't be
[-m <msg>] <remote> [<remote>...]
or
[-m <msg>] <remote>[...]
instead?
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Unable to checkout a branch after cloning
From: Michael J Gruber @ 2009-08-11 14:32 UTC (permalink / raw)
To: Matthew Lear; +Cc: git
In-Reply-To: <4A817F3B.7070308@bubblegen.co.uk>
Matthew Lear venit, vidit, dixit 11.08.2009 16:24:
> Michael J Gruber wrote:
>> Matthew Lear venit, vidit, dixit 11.08.2009 14:17:
>>> Hi Michael - thanks for your reply.
>>> Michael J Gruber wrote:
>>>> Matthew Lear venit, vidit, dixit 11.08.2009 12:10:
>>>>> Hi all,
>>>>>
>>>>> Apologies for perhaps a silly question, but I'd very much appreciate a
>>>>> little bit of assistance.
>>>>>
>>>>> I've set up a git repository on a machine accessible from the internet
>>>>> with the intention to share code with another developer. We clone the
>>>>> repository, commit changes then push back as you'd expect. The server
>>>>> runs gitweb for repository browsing. Clients are running git v1.6.0.6.
>>>>>
>>>>> When I created the initial repository I also created two additional
>>>>> branches - 'upstream' and 'custom'. The former is to act as a 'vendor
>>>>> branch' and the latter contains code specific to the custom platform
>>>>> that we're working on. The master branch contains merges from the
>>>>> upstream branch and also changes that we've made. The custom branch
>>>>> contains merges from master with custom platform specific changes.
>>>>>
>>>>> I've committed changes and on both upstream and custom branches as work
>>>>> progressed, merged them where appropriate, added tags etc and pushed
>>>>> everything to the remote repository. No problem. I can view the
>>>>> branches, tags etc in gitweb and everything looks fine.
>>>>>
>>>>> However, I can clone a new repository just fine but I'm unable to
>>>>> checkout the upstream or custom branches. After cloning, only the master
>>>>> branch is available, ie:
>>>>>
>>>>>> git checkout upstream
>>>>> error: pathspec 'upstream' did not match any file(s) known to git.
>>>>>
>>>>>> git branch -a
>>>>> * master
>>>>> origin/HEAD
>>>>> origin/master
>>>>>
>>>>> .git/config:
>>>>>
>>>>> [core]
>>>>> repositoryformatversion = 0
>>>>> filemode = true
>>>>> bare = false
>>>>> logallrefupdates = true
>>>>> [remote "origin"]
>>>>> url = https://mysite/git/project.git
>>>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>>>> [branch "master"]
>>>>> remote = origin
>>>>> merge = refs/heads/master
>>>>>
>>>>> But the initial local repository where I work (ie created the branches,
>>>>> committed changes, tag, push etc) seems to be fine, ie
>>>>>
>>>>>> git checkout upstream
>>>>> Switched to branch "upstream"
>>>>>
>>>>>> git branch -a
>>>>> custom
>>>>> * master
>>>>> upstream
>>>>>
>>>>> .git/config:
>>>>>
>>>>> [core]
>>>>> repositoryformatversion = 0
>>>>> filemode = true
>>>>> bare = false
>>>>> logallrefupdates = true
>>>>> [remote "origin"]
>>>>> url = https://mysite/git/project.git
>>>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>>>>
>>>>>
>>>>> Developers need to be able to clone the repository and then switch to
>>>>> the appropriate branch in order to work. However it seems that after a
>>>>> clone, only the master branch is available.
>>>>>
>>>>> Why is this?
>>>>>
>>>>> Any help would be much appreciated indeed.
>>>> If I understand you correctly you have 3 repos: the "initial" one on
>>>> which everything is as expected, the "server" one and the "new clone"
>>>> which is missing branches.
>>> Yes, that's correct.
>>>
>>>> Now: How's the server one doing, i.e. what does "git ls-remote
>>>> https://mysite/git/project.git" say? I suspect that one either does not
>>>> have the branches (you haven't told us how you pushed) or in the wrong
>>>> place (remotes/).
>>>> git ls-remote https://mysite/git/project.git
>>> 065f5f13d5f8e786729db1623cc53767c963e959 HEAD
>>> 065f5f13d5f8e786729db1623cc53767c963e959 refs/heads/master
>>>
>>> Hmm. So it seems that the branches are not actually on the server
>>> repository. So how come I can see them with gitweb..?
>>>
>>> I've been pushing from the 'initial' repository with git push --all and
>>> git push --tags.
>>>
>>> However, when I try a git push from the initial repository I get the
>>> following:
>>>
>>>> git push --all
>>> Fetching remote heads...
>>> refs/
>>> refs/heads/
>>> refs/tags/
>>> 'refs/heads/custom': up-to-date
>>> 'refs/heads/master': up-to-date
>>> 'refs/heads/upstream': up-to-date
>>>
>>> -- Matt
>>
>> Does the situation improve if, on the server, you run git
>> update-server-info? Do you have a post-update hook there?
>>
>> Michael
>
> I ran git update-server-info on the server machine. I read about this
> and thought I had made the necessary change to add it as a post commit
> hook. I guess not (so will double check). However, something is still
> not quite right upon cloning:
>
>> git clone https://mysite/git/project.git
> Initialized empty Git repository in /home/matt/git-repos/project/.git/
> Checking out files: 100% (26747/26747), done.
>
>> git branch -a
> * master
> origin/HEAD
> origin/custom
> origin/master
> origin/upstream
We're making progress, that's good ;)
Re. the hook: Make sure it's executable and the extension .sample is
removed.
(gitweb and http access are two different things, which is a common
source of confusion)
>
>> git checkout upstream
> error: pathspec 'upstream' did not match any file(s) known to git.
>
> So it seems that the cloned repository is now aware of the branches
> (improvement) but I'm still unable to switch to a branch.
>
> This is probably now a case of me reading the manual but I'd appreciate
> your thoughts nonetheless.
Well, there is no branch names upstream. There's only one named
origin/upstream, and it's a remote branch. Meaning: checking it out will
produce a detached head, which may or may not be what you want. If you
want to create a branch to work on upstream, do something like
git checkout -b myupstream origin/upstream
(git does something like git checkout -b master origin/master
automatically when cloning, which I think is a common source of confusion)
> Thanks for your continued feedback,
> -- Matt
Cheers,
Michael
^ permalink raw reply
* Re: Unable to checkout a branch after cloning
From: Matthew Lear @ 2009-08-11 14:24 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4A817840.9000405@drmicha.warpmail.net>
Michael J Gruber wrote:
> Matthew Lear venit, vidit, dixit 11.08.2009 14:17:
>> Hi Michael - thanks for your reply.
>> Michael J Gruber wrote:
>>> Matthew Lear venit, vidit, dixit 11.08.2009 12:10:
>>>> Hi all,
>>>>
>>>> Apologies for perhaps a silly question, but I'd very much appreciate a
>>>> little bit of assistance.
>>>>
>>>> I've set up a git repository on a machine accessible from the internet
>>>> with the intention to share code with another developer. We clone the
>>>> repository, commit changes then push back as you'd expect. The server
>>>> runs gitweb for repository browsing. Clients are running git v1.6.0.6.
>>>>
>>>> When I created the initial repository I also created two additional
>>>> branches - 'upstream' and 'custom'. The former is to act as a 'vendor
>>>> branch' and the latter contains code specific to the custom platform
>>>> that we're working on. The master branch contains merges from the
>>>> upstream branch and also changes that we've made. The custom branch
>>>> contains merges from master with custom platform specific changes.
>>>>
>>>> I've committed changes and on both upstream and custom branches as work
>>>> progressed, merged them where appropriate, added tags etc and pushed
>>>> everything to the remote repository. No problem. I can view the
>>>> branches, tags etc in gitweb and everything looks fine.
>>>>
>>>> However, I can clone a new repository just fine but I'm unable to
>>>> checkout the upstream or custom branches. After cloning, only the master
>>>> branch is available, ie:
>>>>
>>>>> git checkout upstream
>>>> error: pathspec 'upstream' did not match any file(s) known to git.
>>>>
>>>>> git branch -a
>>>> * master
>>>> origin/HEAD
>>>> origin/master
>>>>
>>>> .git/config:
>>>>
>>>> [core]
>>>> repositoryformatversion = 0
>>>> filemode = true
>>>> bare = false
>>>> logallrefupdates = true
>>>> [remote "origin"]
>>>> url = https://mysite/git/project.git
>>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>>> [branch "master"]
>>>> remote = origin
>>>> merge = refs/heads/master
>>>>
>>>> But the initial local repository where I work (ie created the branches,
>>>> committed changes, tag, push etc) seems to be fine, ie
>>>>
>>>>> git checkout upstream
>>>> Switched to branch "upstream"
>>>>
>>>>> git branch -a
>>>> custom
>>>> * master
>>>> upstream
>>>>
>>>> .git/config:
>>>>
>>>> [core]
>>>> repositoryformatversion = 0
>>>> filemode = true
>>>> bare = false
>>>> logallrefupdates = true
>>>> [remote "origin"]
>>>> url = https://mysite/git/project.git
>>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>>>
>>>>
>>>> Developers need to be able to clone the repository and then switch to
>>>> the appropriate branch in order to work. However it seems that after a
>>>> clone, only the master branch is available.
>>>>
>>>> Why is this?
>>>>
>>>> Any help would be much appreciated indeed.
>>> If I understand you correctly you have 3 repos: the "initial" one on
>>> which everything is as expected, the "server" one and the "new clone"
>>> which is missing branches.
>> Yes, that's correct.
>>
>>> Now: How's the server one doing, i.e. what does "git ls-remote
>>> https://mysite/git/project.git" say? I suspect that one either does not
>>> have the branches (you haven't told us how you pushed) or in the wrong
>>> place (remotes/).
>>> git ls-remote https://mysite/git/project.git
>> 065f5f13d5f8e786729db1623cc53767c963e959 HEAD
>> 065f5f13d5f8e786729db1623cc53767c963e959 refs/heads/master
>>
>> Hmm. So it seems that the branches are not actually on the server
>> repository. So how come I can see them with gitweb..?
>>
>> I've been pushing from the 'initial' repository with git push --all and
>> git push --tags.
>>
>> However, when I try a git push from the initial repository I get the
>> following:
>>
>>> git push --all
>> Fetching remote heads...
>> refs/
>> refs/heads/
>> refs/tags/
>> 'refs/heads/custom': up-to-date
>> 'refs/heads/master': up-to-date
>> 'refs/heads/upstream': up-to-date
>>
>> -- Matt
>
> Does the situation improve if, on the server, you run git
> update-server-info? Do you have a post-update hook there?
>
> Michael
I ran git update-server-info on the server machine. I read about this
and thought I had made the necessary change to add it as a post commit
hook. I guess not (so will double check). However, something is still
not quite right upon cloning:
> git clone https://mysite/git/project.git
Initialized empty Git repository in /home/matt/git-repos/project/.git/
Checking out files: 100% (26747/26747), done.
> git branch -a
* master
origin/HEAD
origin/custom
origin/master
origin/upstream
> git checkout upstream
error: pathspec 'upstream' did not match any file(s) known to git.
So it seems that the cloned repository is now aware of the branches
(improvement) but I'm still unable to switch to a branch.
This is probably now a case of me reading the manual but I'd appreciate
your thoughts nonetheless.
Thanks for your continued feedback,
-- Matt
^ permalink raw reply
* [JGIT PATCH] Improve error handling for writing FETCH_HEAD
From: Robin Rosenberg @ 2009-08-11 5:48 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
PrintWriter hides error handling from us and we want it. We
also want \n as line terminator so Writer is just as simple. Try-
finally blocks added for cleanup on failure.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
.../spearce/jgit/transport/FetchHeadRecord.java | 25 +++++++++---------
.../org/spearce/jgit/transport/FetchProcess.java | 27 ++++++++++---------
2 files changed, 27 insertions(+), 25 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchHeadRecord.java b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchHeadRecord.java
index d957028..62ec38a 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchHeadRecord.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchHeadRecord.java
@@ -41,7 +41,8 @@
import static org.spearce.jgit.lib.Constants.R_REMOTES;
import static org.spearce.jgit.lib.Constants.R_TAGS;
-import java.io.PrintWriter;
+import java.io.IOException;
+import java.io.Writer;
import org.spearce.jgit.lib.ObjectId;
@@ -54,7 +55,7 @@
URIish sourceURI;
- void write(final PrintWriter pw) {
+ void write(final Writer pw) throws IOException {
final String type;
final String name;
if (sourceName.startsWith(R_HEADS)) {
@@ -71,16 +72,16 @@ void write(final PrintWriter pw) {
name = sourceName;
}
- pw.print(newValue.name());
- pw.print('\t');
+ pw.write(newValue.name());
+ pw.write('\t');
if (notForMerge)
- pw.print("not-for-merge");
- pw.print('\t');
- pw.print(type);
- pw.print(" '");
- pw.print(name);
- pw.print("' of ");
- pw.print(sourceURI);
- pw.println();
+ pw.write("not-for-merge");
+ pw.write('\t');
+ pw.write(type);
+ pw.write(" '");
+ pw.write(name);
+ pw.write("' of ");
+ pw.write(sourceURI.toString());
+ pw.write("\n");
}
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
index 08d7d65..c899c8c 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/FetchProcess.java
@@ -41,7 +41,7 @@
import java.io.File;
import java.io.IOException;
import java.io.OutputStreamWriter;
-import java.io.PrintWriter;
+import java.io.Writer;
import java.util.ArrayList;
import java.util.Collection;
import java.util.Collections;
@@ -264,20 +264,21 @@ private void removeFetchHeadRecord(final ObjectId want) {
private void updateFETCH_HEAD(final FetchResult result) throws IOException {
final LockFile lock = new LockFile(new File(transport.local
.getDirectory(), "FETCH_HEAD"));
- if (lock.lock()) {
- final PrintWriter pw = new PrintWriter(new OutputStreamWriter(lock
- .getOutputStream())) {
- @Override
- public void println() {
- print('\n');
+ try {
+ if (lock.lock()) {
+ final Writer w = new OutputStreamWriter(lock.getOutputStream());
+ try {
+ for (final FetchHeadRecord h : fetchHeadUpdates) {
+ h.write(w);
+ result.add(h);
+ }
+ } finally {
+ w.close();
}
- };
- for (final FetchHeadRecord h : fetchHeadUpdates) {
- h.write(pw);
- result.add(h);
+ lock.commit();
}
- pw.close();
- lock.commit();
+ } finally {
+ lock.unlock();
}
}
--
1.6.3.2.199.g7340d
^ permalink raw reply related
* Re: rename/copy detection not working for git-log?
From: Kevin Green @ 2009-08-11 13:57 UTC (permalink / raw)
To: Bruce Stephens; +Cc: git@vger.kernel.org
In-Reply-To: <807hxasbz4.fsf@tiny.isode.net>
On 08/11/09 09:42:55, Bruce Stephens wrote:
> Kevin Green <Kevin.T.Green@morganstanley.com> writes:
>
> [...]
>
> > What am I missing?
>
> I'd guess --follow
Ah, yep... didn't see that earlier. Exactly what I need, thanks.
--Kevin
^ permalink raw reply
* [PATCH] git stash: Give friendlier errors when there is nothing to apply
From: Ori Avtalion @ 2009-08-11 11:12 UTC (permalink / raw)
To: git
In-Reply-To: <200908111409.04506.trast@student.ethz.ch>
The change makes sure a stash (given or default) exists before
checking if the working tree is dirty.
If the default stash is requested, the old message was scary and
included a 'fatal' error from rev-parse:
fatal: Needed a single revision
: no valid stashed state found
It is replaced with a friendlier 'Nothing to apply' error, similar to
'git stash branch'.
If a specific stash is specified, the 'Needed a single revision' errors
from rev-parse are suppressed.
Signed-off-by: Ori Avtalion <ori@avtalion.name>
---
Thomas, I added handling for the 'git stash apply <stash>' case based
on your reminder, and also changed the error messages related to it.
All of the stash tests pass, as before.
git-stash.sh | 27 ++++++++++++++++-----------
1 files changed, 16 insertions(+), 11 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index 03e589f..d61c9d0 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -162,10 +162,6 @@ show_stash () {
}
apply_stash () {
- git update-index -q --refresh &&
- git diff-files --quiet --ignore-submodules ||
- die 'Cannot apply to a dirty working tree, please stage your changes'
-
unstash_index=
while test $# != 0
@@ -184,18 +180,27 @@ apply_stash () {
shift
done
- # current index state
- c_tree=$(git write-tree) ||
- die 'Cannot apply a stash in the middle of a merge'
+ if test $# = 0
+ then
+ have_stash || die 'Nothing to apply'
+ fi
# stash records the work tree, and is a merge between the
# base commit (first parent) and the index tree (second parent).
- s=$(git rev-parse --verify --default $ref_stash "$@") &&
- w_tree=$(git rev-parse --verify "$s:") &&
- b_tree=$(git rev-parse --verify "$s^1:") &&
- i_tree=$(git rev-parse --verify "$s^2:") ||
+ s=$(git rev-parse --quiet --verify --default $ref_stash "$@") &&
+ w_tree=$(git rev-parse --quiet --verify "$s:") &&
+ b_tree=$(git rev-parse --quiet --verify "$s^1:") &&
+ i_tree=$(git rev-parse --quiet --verify "$s^2:") ||
die "$*: no valid stashed state found"
+ git update-index -q --refresh &&
+ git diff-files --quiet --ignore-submodules ||
+ die 'Cannot apply to a dirty working tree, please stage your changes'
+
+ # current index state
+ c_tree=$(git write-tree) ||
+ die 'Cannot apply a stash in the middle of a merge'
+
unstashed_index_tree=
if test -n "$unstash_index" && test "$b_tree" != "$i_tree" &&
test "$c_tree" != "$i_tree"
--
1.6.4.115.g82cf7
^ permalink raw reply related
* Re: Unable to checkout a branch after cloning
From: Michael J Gruber @ 2009-08-11 13:55 UTC (permalink / raw)
To: Matthew Lear; +Cc: git
In-Reply-To: <4A81613F.2080309@bubblegen.co.uk>
Matthew Lear venit, vidit, dixit 11.08.2009 14:17:
> Hi Michael - thanks for your reply.
> Michael J Gruber wrote:
>> Matthew Lear venit, vidit, dixit 11.08.2009 12:10:
>>> Hi all,
>>>
>>> Apologies for perhaps a silly question, but I'd very much appreciate a
>>> little bit of assistance.
>>>
>>> I've set up a git repository on a machine accessible from the internet
>>> with the intention to share code with another developer. We clone the
>>> repository, commit changes then push back as you'd expect. The server
>>> runs gitweb for repository browsing. Clients are running git v1.6.0.6.
>>>
>>> When I created the initial repository I also created two additional
>>> branches - 'upstream' and 'custom'. The former is to act as a 'vendor
>>> branch' and the latter contains code specific to the custom platform
>>> that we're working on. The master branch contains merges from the
>>> upstream branch and also changes that we've made. The custom branch
>>> contains merges from master with custom platform specific changes.
>>>
>>> I've committed changes and on both upstream and custom branches as work
>>> progressed, merged them where appropriate, added tags etc and pushed
>>> everything to the remote repository. No problem. I can view the
>>> branches, tags etc in gitweb and everything looks fine.
>>>
>>> However, I can clone a new repository just fine but I'm unable to
>>> checkout the upstream or custom branches. After cloning, only the master
>>> branch is available, ie:
>>>
>>>> git checkout upstream
>>> error: pathspec 'upstream' did not match any file(s) known to git.
>>>
>>>> git branch -a
>>> * master
>>> origin/HEAD
>>> origin/master
>>>
>>> .git/config:
>>>
>>> [core]
>>> repositoryformatversion = 0
>>> filemode = true
>>> bare = false
>>> logallrefupdates = true
>>> [remote "origin"]
>>> url = https://mysite/git/project.git
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>> [branch "master"]
>>> remote = origin
>>> merge = refs/heads/master
>>>
>>> But the initial local repository where I work (ie created the branches,
>>> committed changes, tag, push etc) seems to be fine, ie
>>>
>>>> git checkout upstream
>>> Switched to branch "upstream"
>>>
>>>> git branch -a
>>> custom
>>> * master
>>> upstream
>>>
>>> .git/config:
>>>
>>> [core]
>>> repositoryformatversion = 0
>>> filemode = true
>>> bare = false
>>> logallrefupdates = true
>>> [remote "origin"]
>>> url = https://mysite/git/project.git
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>>
>>>
>>> Developers need to be able to clone the repository and then switch to
>>> the appropriate branch in order to work. However it seems that after a
>>> clone, only the master branch is available.
>>>
>>> Why is this?
>>>
>>> Any help would be much appreciated indeed.
>>
>> If I understand you correctly you have 3 repos: the "initial" one on
>> which everything is as expected, the "server" one and the "new clone"
>> which is missing branches.
>
> Yes, that's correct.
>
>> Now: How's the server one doing, i.e. what does "git ls-remote
>> https://mysite/git/project.git" say? I suspect that one either does not
>> have the branches (you haven't told us how you pushed) or in the wrong
>> place (remotes/).
>
>> git ls-remote https://mysite/git/project.git
> 065f5f13d5f8e786729db1623cc53767c963e959 HEAD
> 065f5f13d5f8e786729db1623cc53767c963e959 refs/heads/master
>
> Hmm. So it seems that the branches are not actually on the server
> repository. So how come I can see them with gitweb..?
>
> I've been pushing from the 'initial' repository with git push --all and
> git push --tags.
>
> However, when I try a git push from the initial repository I get the
> following:
>
>> git push --all
> Fetching remote heads...
> refs/
> refs/heads/
> refs/tags/
> 'refs/heads/custom': up-to-date
> 'refs/heads/master': up-to-date
> 'refs/heads/upstream': up-to-date
>
> -- Matt
Does the situation improve if, on the server, you run git
update-server-info? Do you have a post-update hook there?
Michael
^ permalink raw reply
* Re: rename/copy detection not working for git-log?
From: Bruce Stephens @ 2009-08-11 13:42 UTC (permalink / raw)
To: git
In-Reply-To: <20090811132144.GJ6327@morganstanley.com>
Kevin Green <Kevin.T.Green@morganstanley.com> writes:
[...]
> What am I missing?
I'd guess --follow
^ permalink raw reply
* rename/copy detection not working for git-log?
From: Kevin Green @ 2009-08-11 13:21 UTC (permalink / raw)
To: git
Hi,
I'm pretty sure I've seen this working as expected at some point in the
past, but I'm now not able to get the full history of a file that's
been moved to another directory and I can't understand why. Here's a
simple way to reproduce:
$ git init
Initialized empty Git repository in /var/tmp/git/.git/
$ mkdir bin
$ cat > bin/test.sh
#!/bin/sh
echo Hello, world!
$ git add .
$ git commit -m 'initial import'
[master (root-commit) b9dc5be] initial import
1 files changed, 3 insertions(+), 0 deletions(-)
create mode 100644 bin/test.sh
$ mkdir scripts
$ git mv bin/test.sh scripts/test.sh
$ git commit -m 'move bin/ to scripts/'
[master b4c6c72] move bin/ to scripts/
1 files changed, 0 insertions(+), 0 deletions(-)
rename {bin => scripts}/test.sh (100%)
$ echo 'echo Goodbye!' >> scripts/test.sh
$ git commit -a -m 'make a change in scripts/'
[master 59830d5] make a change in scripts/
1 files changed, 1 insertions(+), 0 deletions(-)
This now has full history of:
$ git log --pretty=oneline
59830d59f6b4d48b28f2ae8d51e921a9c8842b06 make a change in scripts/
b4c6c72c548a1c17550c01350beede235d481aa4 move bin/ to scripts/
b9dc5be440d2c843554e9b0302435d9a6f78cd65 initial import
and the history of scripts/test.sh is as I expect:
$ git log --pretty=oneline -- scripts/test.sh
59830d59f6b4d48b28f2ae8d51e921a9c8842b06 make a change in scripts/
b4c6c72c548a1c17550c01350beede235d481aa4 move bin/ to scripts/
and the history of bin/test.sh is as I would expect:
$ git log --pretty=oneline -- bin/test.sh
b4c6c72c548a1c17550c01350beede235d481aa4 move bin/ to scripts/
b9dc5be440d2c843554e9b0302435d9a6f78cd65 initial import
But, I would expect that some combination of -M and -C would find me
the full history of the current test.sh script so I could see what
happened to it before it was moved. (Okay, the example above is not so
interesting, but in the real world, bin/test.sh would have had lots of
commits before moving):
$ git log --pretty=oneline -M -C -C -- scripts/test.sh
59830d59f6b4d48b28f2ae8d51e921a9c8842b06 make a change in scripts/
b4c6c72c548a1c17550c01350beede235d481aa4 move bin/ to scripts/
git-blame seems to get this right:
$ git blame scripts/test.sh
^b9dc5be bin/test.sh (Kevin Green 2009-08-11 09:07:06 -0400 1) #!/bin/sh
^b9dc5be bin/test.sh (Kevin Green 2009-08-11 09:07:06 -0400 2)
^b9dc5be bin/test.sh (Kevin Green 2009-08-11 09:07:06 -0400 3) echo Hello, world!
59830d59 scripts/test.sh (Kevin Green 2009-08-11 09:08:29 -0400 4) echo Goodbye!
What am I missing?
Thanks
--Kevin
^ permalink raw reply
* [JGIT PATCH] Silence noise from javadoc when generating.
From: Robin Rosenberg @ 2009-08-11 5:39 UTC (permalink / raw)
To: spearce; +Cc: git, Robin Rosenberg
We do not need javadoc(1) to tell us about every file it is processing. With
the -quiet flag we get to see warnings and errors instead.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
make_jgit.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/make_jgit.sh b/make_jgit.sh
index 9608b70..e3f7ffa 100755
--- a/make_jgit.sh
+++ b/make_jgit.sh
@@ -122,7 +122,7 @@ echo "Created $O_CLI." || die "Build failed."
echo "Building Javadocs ..."
for p in $PLUGINS; do
- javadoc -sourcepath "$p/src/" -d "docs/$p/" \
+ javadoc -quiet -sourcepath "$p/src/" -d "docs/$p/" \
`find "$p/src" -name "*.java"`
done
--
1.6.3.2.199.g7340d
^ permalink raw reply related
* [PATCH] [TRIVIAL] Documentation: add: <filepattern>... is optional
From: Paul Bolle @ 2009-08-11 13:03 UTC (permalink / raw)
To: Junio C Hamano, git
<filepattern>... is optional (e.g. when the --all or --update
options are used) so use square brackets in the synopsis.
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Documentation/git-add.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index ab1943c..e67b7e8 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -10,7 +10,7 @@ SYNOPSIS
[verse]
'git add' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
[--edit | -e] [--all | [--update | -u]] [--intent-to-add | -N]
- [--refresh] [--ignore-errors] [--] <filepattern>...
+ [--refresh] [--ignore-errors] [--] [<filepattern>...]
DESCRIPTION
-----------
--
1.6.4
^ permalink raw reply related
* [PATCH] [TRIVIAL] Documentation: merge: one <remote> is required
From: Paul Bolle @ 2009-08-11 13:03 UTC (permalink / raw)
To: Junio C Hamano, git
merge only requires one <remote>, so "<remote>..." should be used in the
synopsis (and not "<remote> <remote>...").
Signed-off-by: Paul Bolle <pebolle@tiscali.nl>
---
Documentation/git-merge.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index c04ae73..af68d69 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git merge' [-n] [--stat] [--no-commit] [--squash] [-s <strategy>]...
- [-m <msg>] <remote> <remote>...
+ [-m <msg>] <remote>...
'git merge' <msg> HEAD <remote>...
DESCRIPTION
--
1.6.4
^ permalink raw reply related
* [RFC/PATCH 3/6] Move setup of curl remote helper from transport.c to transport-helper.c
From: Johan Herland @ 2009-08-11 10:10 UTC (permalink / raw)
To: git; +Cc: Johan Herland, barkalow, gitster, benji, Johannes.Schindelin
In-Reply-To: <alpine.LNX.2.00.0908101205120.27553@iabervon.org>
Since the curl transport is now launched by the transport-helper mechanism,
it makes sense to move the remaining curl-related code (i.e.
curl_transport_push()) from transport.c into transport-helper.c.
The patch also consolidates the two transport_helper_init() call sites
("foreign" helper and curl helper).
Signed-off-by: Johan Herland <johan@herland.net>
---
transport-helper.c | 39 +++++++++++++++++++++++++++++++++++++++
transport.c | 48 ++++++------------------------------------------
2 files changed, 45 insertions(+), 42 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index a901630..d3ce984 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -249,6 +249,34 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
return ret;
}
+#ifndef NO_CURL
+static int curl_transport_push(struct transport *transport, int refspec_nr, const char **refspec, int flags)
+{
+ const char **argv;
+ int argc;
+
+ if (flags & TRANSPORT_PUSH_MIRROR)
+ return error("http transport does not support mirror mode");
+
+ argv = xmalloc((refspec_nr + 12) * sizeof(char *));
+ argv[0] = "http-push";
+ argc = 1;
+ if (flags & TRANSPORT_PUSH_ALL)
+ argv[argc++] = "--all";
+ if (flags & TRANSPORT_PUSH_FORCE)
+ argv[argc++] = "--force";
+ if (flags & TRANSPORT_PUSH_DRY_RUN)
+ argv[argc++] = "--dry-run";
+ if (flags & TRANSPORT_PUSH_VERBOSE)
+ argv[argc++] = "--verbose";
+ argv[argc++] = transport->url;
+ while (refspec_nr--)
+ argv[argc++] = *refspec++;
+ argv[argc] = NULL;
+ return !!run_command_v_opt(argv, RUN_GIT_CMD);
+}
+#endif
+
int transport_helper_init(struct transport *transport)
{
struct helper_data *data = xcalloc(sizeof(*data), 1);
@@ -269,5 +297,16 @@ int transport_helper_init(struct transport *transport)
transport->get_refs_list = get_refs_list;
transport->fetch = fetch;
transport->disconnect = disconnect_helper;
+
+ if (!strcmp(data->name, "http")
+ || !strcmp(data->name, "https")
+ || !strcmp(data->name, "ftp")) {
+#ifdef NO_CURL
+ error("git was compiled without libcurl support.");
+#else
+ transport->push = curl_transport_push;
+#endif
+ }
+
return 0;
}
diff --git a/transport.c b/transport.c
index 26d9999..81a28bc 100644
--- a/transport.c
+++ b/transport.c
@@ -349,35 +349,6 @@ static int rsync_transport_push(struct transport *transport,
return result;
}
-#ifndef NO_CURL
-static int curl_transport_push(struct transport *transport, int refspec_nr, const char **refspec, int flags)
-{
- const char **argv;
- int argc;
-
- if (flags & TRANSPORT_PUSH_MIRROR)
- return error("http transport does not support mirror mode");
-
- argv = xmalloc((refspec_nr + 12) * sizeof(char *));
- argv[0] = "http-push";
- argc = 1;
- if (flags & TRANSPORT_PUSH_ALL)
- argv[argc++] = "--all";
- if (flags & TRANSPORT_PUSH_FORCE)
- argv[argc++] = "--force";
- if (flags & TRANSPORT_PUSH_DRY_RUN)
- argv[argc++] = "--dry-run";
- if (flags & TRANSPORT_PUSH_VERBOSE)
- argv[argc++] = "--verbose";
- argv[argc++] = transport->url;
- while (refspec_nr--)
- argv[argc++] = *refspec++;
- argv[argc] = NULL;
- return !!run_command_v_opt(argv, RUN_GIT_CMD);
-}
-
-#endif
-
struct bundle_transport_data {
int fd;
struct bundle_header header;
@@ -815,26 +786,19 @@ struct transport *transport_get(struct remote *remote, const char *url)
url = remote->url[0];
ret->url = url;
- if (remote && remote->foreign_vcs) {
- transport_helper_init(ret);
- return ret;
- }
+ if (remote && remote->foreign_vcs)
+ url = NULL;
if (url && !prefixcmp(url, "rsync:")) {
ret->get_refs_list = get_refs_via_rsync;
ret->fetch = fetch_objs_via_rsync;
ret->push = rsync_transport_push;
- } else if (url
- && (!prefixcmp(url, "http://")
- || !prefixcmp(url, "https://")
- || !prefixcmp(url, "ftp://"))) {
+ } else if (!url
+ || !prefixcmp(url, "http://")
+ || !prefixcmp(url, "https://")
+ || !prefixcmp(url, "ftp://")) {
transport_helper_init(ret);
-#ifdef NO_CURL
- error("git was compiled without libcurl support.");
-#else
- ret->push = curl_transport_push;
-#endif
} else if (url && is_local(url) && is_file(url)) {
struct bundle_transport_data *data = xcalloc(1, sizeof(*data));
--
1.6.4.rc3.138.ga6b98.dirty
^ permalink raw reply related
* [RFC/PATCH 5/6] Let transport_helper_init() decide if a remote helper program can be used
From: Johan Herland @ 2009-08-11 10:10 UTC (permalink / raw)
To: git; +Cc: Johan Herland, barkalow, gitster, benji, Johannes.Schindelin
In-Reply-To: <alpine.LNX.2.00.0908101205120.27553@iabervon.org>
Teach the transport-helper mechanism to verify that the remote helper
program is available, before finalizing the transport setup.
If the remote helper is NOT available, transport_helper_init() returns -1,
and transport_get() falls back to trying a native transport.
This patch introduces a subtle, but important change in the handling of
remotes and their URLs:
Before this patch, we only invoke transport_helper_init() _after_ we find
that the transport-helper mechanism is appropriate for this remote
(i.e. the remote is "foreign", or is handled by the curl helper).
This patch moves the decision point into transport_helper_init(): If the
remote is not obviously using a native transport (URL starts with "file:",
"git:" or "ssh:"), then we first call transport_helper_init(), and only if
it returns error (meaning that no appropriate remote helper program was
found) do we fall back to native transport handling.
Signed-off-by: Johan Herland <johan@herland.net>
---
transport-helper.c | 22 ++++++++++++++++++++--
transport.c | 11 ++++++-----
2 files changed, 26 insertions(+), 7 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index d3ce984..de30727 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -5,6 +5,7 @@
#include "commit.h"
#include "diff.h"
#include "revision.h"
+#include "help.h"
struct helper_data
{
@@ -279,11 +280,18 @@ static int curl_transport_push(struct transport *transport, int refspec_nr, cons
int transport_helper_init(struct transport *transport)
{
- struct helper_data *data = xcalloc(sizeof(*data), 1);
+ struct helper_data *data;
+ struct strbuf buf = STRBUF_INIT;
+ char *cmd;
+
+ if (!transport->remote)
+ return -1;
+ data = xcalloc(sizeof(*data), 1);
if (transport->remote->foreign_vcs) {
data->name = xstrdup(transport->remote->foreign_vcs);
- transport->url = transport->remote->foreign_vcs;
+ if (!transport->url)
+ transport->url = transport->remote->foreign_vcs;
} else {
char *eom = strchr(transport->url, ':');
if (!eom) {
@@ -293,6 +301,16 @@ int transport_helper_init(struct transport *transport)
data->name = xstrndup(transport->url, eom - transport->url);
}
+ strbuf_addf(&buf, "remote-%s", data->name);
+ cmd = strbuf_detach(&buf, NULL);
+ if (!is_git_command_or_alias(cmd)) {
+ warning("Could not find remote helper command \"git %s\". Assuming native remote.", cmd);
+ free(cmd);
+ free(data->name);
+ free(data);
+ return -1;
+ }
+
transport->data = data;
transport->get_refs_list = get_refs_list;
transport->fetch = fetch;
diff --git a/transport.c b/transport.c
index 81a28bc..b7033eb 100644
--- a/transport.c
+++ b/transport.c
@@ -794,11 +794,12 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->fetch = fetch_objs_via_rsync;
ret->push = rsync_transport_push;
- } else if (!url
- || !prefixcmp(url, "http://")
- || !prefixcmp(url, "https://")
- || !prefixcmp(url, "ftp://")) {
- transport_helper_init(ret);
+ } else if ((!url
+ || (prefixcmp(url, "git:")
+ && prefixcmp(url, "ssh:")
+ && prefixcmp(url, "file:")))
+ && !transport_helper_init(ret)) {
+ /* no-op, ret is initialized by transport_helper_init() */
} else if (url && is_local(url) && is_file(url)) {
struct bundle_transport_data *data = xcalloc(1, sizeof(*data));
--
1.6.4.rc3.138.ga6b98.dirty
^ permalink raw reply related
* [RFC/PATCH 2/6] transport_get(): Don't SEGFAULT on missing url
From: Johan Herland @ 2009-08-11 10:10 UTC (permalink / raw)
To: git; +Cc: Johan Herland, barkalow, gitster, benji, Johannes.Schindelin
In-Reply-To: <alpine.LNX.2.00.0908101205120.27553@iabervon.org>
Signed-off-by: Johan Herland <johan@herland.net>
---
transport.c | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/transport.c b/transport.c
index 19f330a..26d9999 100644
--- a/transport.c
+++ b/transport.c
@@ -820,14 +820,15 @@ struct transport *transport_get(struct remote *remote, const char *url)
return ret;
}
- if (!prefixcmp(url, "rsync:")) {
+ if (url && !prefixcmp(url, "rsync:")) {
ret->get_refs_list = get_refs_via_rsync;
ret->fetch = fetch_objs_via_rsync;
ret->push = rsync_transport_push;
- } else if (!prefixcmp(url, "http://")
- || !prefixcmp(url, "https://")
- || !prefixcmp(url, "ftp://")) {
+ } else if (url
+ && (!prefixcmp(url, "http://")
+ || !prefixcmp(url, "https://")
+ || !prefixcmp(url, "ftp://"))) {
transport_helper_init(ret);
#ifdef NO_CURL
error("git was compiled without libcurl support.");
@@ -835,7 +836,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->push = curl_transport_push;
#endif
- } else if (is_local(url) && is_file(url)) {
+ } else if (url && is_local(url) && is_file(url)) {
struct bundle_transport_data *data = xcalloc(1, sizeof(*data));
ret->data = data;
ret->get_refs_list = get_refs_from_bundle;
--
1.6.4.rc3.138.ga6b98.dirty
^ permalink raw reply related
* [RFC/PATCH 6/6] Add testcase to verify handling of missing remote helper programs
From: Johan Herland @ 2009-08-11 10:10 UTC (permalink / raw)
To: git; +Cc: Johan Herland, barkalow, gitster, benji, Johannes.Schindelin
In-Reply-To: <alpine.LNX.2.00.0908101205120.27553@iabervon.org>
Signed-off-by: Johan Herland <johan@herland.net>
---
t/t5590-remote-helper-missing.sh | 56 ++++++++++++++++++++++++++++++++++++++
1 files changed, 56 insertions(+), 0 deletions(-)
create mode 100755 t/t5590-remote-helper-missing.sh
diff --git a/t/t5590-remote-helper-missing.sh b/t/t5590-remote-helper-missing.sh
new file mode 100755
index 0000000..3bc2bc2
--- /dev/null
+++ b/t/t5590-remote-helper-missing.sh
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+test_description='test graceful failure when missing remote helper program'
+. ./test-lib.sh
+
+test_expect_success 'setup repository' '
+ echo content >file &&
+ git add file &&
+ git commit -m one &&
+ git config remote.missing.vcs foo &&
+ git remote add missing2 foo:/nonexisting/path
+'
+
+test_expect_success 'fetch changes from "missing" remote' '
+ cat <<EOF >expect &&
+warning: Could not find remote helper command "git remote-foo". Assuming native remote.
+EOF
+ ! git fetch missing >actual 2>&1 &&
+ head -n1 actual >actual.first &&
+ test_cmp expect actual.first
+'
+
+test_expect_success 'fetch changes from "missing2" remote' '
+ cat <<EOF >expect &&
+warning: Could not find remote helper command "git remote-foo". Assuming native remote.
+EOF
+ ! git fetch missing2 >actual 2>&1 &&
+ head -n1 actual >actual.first &&
+ test_cmp expect actual.first
+'
+
+test_expect_success 'push changes to "missing" remote' '
+ echo "more content" >>file &&
+ git add file &&
+ git commit -m two &&
+ cat <<EOF >expect &&
+warning: Could not find remote helper command "git remote-foo". Assuming native remote.
+EOF
+ ! git push --all missing >actual 2>&1 &&
+ head -n1 actual >actual.first &&
+ test_cmp expect actual.first
+'
+
+test_expect_success 'push changes to "missing2" remote' '
+ echo "even more content" >>file &&
+ git add file &&
+ git commit -m three &&
+ cat <<EOF >expect &&
+warning: Could not find remote helper command "git remote-foo". Assuming native remote.
+EOF
+ ! git push --all missing2 >actual 2>&1 &&
+ head -n1 actual >actual.first &&
+ test_cmp expect actual.first
+'
+
+test_done
--
1.6.4.rc3.138.ga6b98.dirty
^ permalink raw reply related
* [RFC/PATCH 4/6] Add is_git_command_or_alias() for checking availability of a given git command
From: Johan Herland @ 2009-08-11 10:10 UTC (permalink / raw)
To: git; +Cc: Johan Herland, barkalow, gitster, benji, Johannes.Schindelin
In-Reply-To: <alpine.LNX.2.00.0908101205120.27553@iabervon.org>
The transport-helper mechanism requires us to gracefully handle the case
where a git command is not available for some reason.
This patch introduces a simple function for querying the availability of a
git command, without attempting to execute said command.
The new function is very similar to the static is_git_command() function in
builtin-help.c, except that this function also accepts a matching alias.
Signed-off-by: Johan Herland <johan@herland.net>
---
help.c | 21 +++++++++++++++++++++
help.h | 2 ++
2 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/help.c b/help.c
index 994561d..a616277 100644
--- a/help.c
+++ b/help.c
@@ -296,6 +296,27 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
old->names = NULL;
}
+int is_git_command_or_alias(const char *cmd)
+{
+ struct cmdnames main_cmds, other_cmds;
+
+ memset(&main_cmds, 0, sizeof(main_cmds));
+ memset(&other_cmds, 0, sizeof(other_cmds));
+ memset(&aliases, 0, sizeof(aliases));
+
+ git_config(git_unknown_cmd_config, NULL);
+
+ load_command_list("git-", &main_cmds, &other_cmds);
+
+ add_cmd_list(&main_cmds, &aliases);
+ add_cmd_list(&main_cmds, &other_cmds);
+ qsort(main_cmds.names, main_cmds.cnt,
+ sizeof(main_cmds.names), cmdname_compare);
+ uniq(&main_cmds);
+
+ return is_in_cmdlist(&main_cmds, cmd);
+}
+
const char *help_unknown_cmd(const char *cmd)
{
int i, n, best_similarity = 0;
diff --git a/help.h b/help.h
index 56bc154..6c43452 100644
--- a/help.h
+++ b/help.h
@@ -26,4 +26,6 @@ int is_in_cmdlist(struct cmdnames *c, const char *s);
void list_commands(const char *title, struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
+int is_git_command_or_alias(const char *cmd);
+
#endif /* HELP_H */
--
1.6.4.rc3.138.ga6b98.dirty
^ permalink raw reply related
* [RFC/PATCH 0/6] Graceful handling of missing remote helpers
From: Johan Herland @ 2009-08-11 10:10 UTC (permalink / raw)
To: git; +Cc: Johan Herland, barkalow, gitster, benji, Johannes.Schindelin
In-Reply-To: <alpine.LNX.2.00.0908101205120.27553@iabervon.org>
On Mon, 10 Aug 2009, Daniel Barkalow wrote:
> > > In order to support this, there just needs to be a call to check whether
> > > "remote-<something>" is an available git command (without running it or
> > > giving an error), and the helper code should be used if it is. This is
> > > actually required so that people with workstations whose domain is
> > > .kernel.org and who have cloned "master:/home/linus/something.git" don't
> > > start getting "remote-master isn't a git command" errors (that is,
> > > misinterpreting ssh-format location hostnames as helper names. Johan,
> > > perhaps you could write that for your CVS helper?
> >
> > Sorry, not following you here. Write exactly what?
> >
> > - The code in the transport layer for checking if "remote-<something>"
> > is an available git command?
>
> That's what I was thinking.
Ok, I've spent way too much time on this, so if this doesn't cut it, I leave it
up to someone else to pick up the pieces.
The following patch series implements what I understand to be the current
consensus (or at least a good compromise) in this thread:
- There are two ways to indicate that a remote helper should be used:
1. remote.foo.vcs = <something>
2. remote.foo.url starts with "<something>:"
If both are present, remote.foo.vcs is preferred.
- Teach transport_helper_init() to check if "remote-<something>" is an
available git command. If so, use it. If not, gracefully abort the
transport-helper setup, and fall back to the "native" transport code.
- Skip the transport-helper code is the remote is obviously "native" (i.e.
URL starts with "git:"/"file:"/"ssh:"/"rsync:")
AFAICS this should make Daniel happy because his P4 setup will still work, and
it should also make Dscho happy, since he can tell people to
"git clone cvs::pserver:anonymous@cool.haxx.se:/cvsroot/curl#curl"
(of course, this depends on the CVS helper supporting remote.foo.url, which it
will, in a future iteration)
The non-trivial part of the series is in patch #5.
Implementing the rsync handling as another remote helper program is left as an
exercise for the reader...
Have fun! :)
...Johan
Johan Herland (6):
Minor unrelated fixes
transport_get(): Don't SEGFAULT on missing url
Move setup of curl remote helper from transport.c to transport-helper.c
Add is_git_command_or_alias() for checking availability of a given git command
Let transport_helper_init() decide if a remote helper program can be used
Add testcase to verify handling of missing remote helper programs
help.c | 23 ++++++++++++-
help.h | 2 +
t/t5590-remote-helper-missing.sh | 56 +++++++++++++++++++++++++++++++
transport-helper.c | 67 +++++++++++++++++++++++++++++++++++--
transport.c | 56 ++++++-------------------------
5 files changed, 154 insertions(+), 50 deletions(-)
create mode 100755 t/t5590-remote-helper-missing.sh
^ permalink raw reply
* [RFC/PATCH 1/6] Minor unrelated fixes
From: Johan Herland @ 2009-08-11 10:10 UTC (permalink / raw)
To: git; +Cc: Johan Herland, barkalow, gitster, benji, Johannes.Schindelin
In-Reply-To: <alpine.LNX.2.00.0908101205120.27553@iabervon.org>
Signed-off-by: Johan Herland <johan@herland.net>
---
help.c | 2 +-
transport-helper.c | 6 ++++--
2 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/help.c b/help.c
index 6c46d8b..994561d 100644
--- a/help.c
+++ b/help.c
@@ -302,7 +302,7 @@ const char *help_unknown_cmd(const char *cmd)
struct cmdnames main_cmds, other_cmds;
memset(&main_cmds, 0, sizeof(main_cmds));
- memset(&other_cmds, 0, sizeof(main_cmds));
+ memset(&other_cmds, 0, sizeof(other_cmds));
memset(&aliases, 0, sizeof(aliases));
git_config(git_unknown_cmd_config, NULL);
diff --git a/transport-helper.c b/transport-helper.c
index cc99368..a901630 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -8,7 +8,7 @@
struct helper_data
{
- const char *name;
+ char *name;
struct child_process *helper;
char *marks_filename;
@@ -258,8 +258,10 @@ int transport_helper_init(struct transport *transport)
transport->url = transport->remote->foreign_vcs;
} else {
char *eom = strchr(transport->url, ':');
- if (!eom)
+ if (!eom) {
+ free(data);
return -1;
+ }
data->name = xstrndup(transport->url, eom - transport->url);
}
--
1.6.4.rc3.138.ga6b98.dirty
^ permalink raw reply related
* [PATCH] Change mentions of "git programs" to "git commands"
From: Nanako Shiraishi @ 2009-08-11 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Ori Avtalion
In-Reply-To: <4a7c3971.170d660a.3caa.20b3@mx.google.com>
From: Ori Avtalion <ori@avtalion.name>
Date: Fri, 7 Aug 2009 17:24:21 +0300
Subject: [PATCH] Change mentions of "git programs" to "git commands"
Most of the docs and printouts refer to "commands" when discussing what
the end users call via the "git" top-level program. We should refer them
as "git programs" when we discuss the fact that the commands are
implemented as separate programs, but in other contexts, it is better to
use the term "git commands" consistently.
Signed-off-by: Ori Avtalion <ori@avtalion.name>
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
---
Junio, it appeard to me that you had some minor issues with Ori's patch but you knew exactly how they should be addressed and you thought it was a good change overall.
I copy-edited Ori's patch for your convenience, and tried to clarify the criteria you used to decide which "program" should become "command" in the updated commit log message, in case you forgot to apply it yourself.
I just didn't want to see the time you and others spent on submitting and reviewing wasted due to lack of resubmission of a revised patch.
Documentation/config.txt | 4 ++--
Documentation/fetch-options.txt | 2 +-
Documentation/git-rev-list.txt | 2 +-
Documentation/git.txt | 4 ++--
Documentation/gitattributes.txt | 2 +-
Documentation/gitcore-tutorial.txt | 4 ++--
Documentation/user-manual.txt | 2 +-
help.c | 2 +-
8 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c6f09f8..e94a8ab 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -605,7 +605,7 @@ color.interactive.<slot>::
Use customized color for 'git-add --interactive'
output. `<slot>` may be `prompt`, `header`, `help` or `error`, for
four distinct types of normal output from interactive
- programs. The values of these variables may be specified as
+ commands. The values of these variables may be specified as
in color.branch.<slot>.
color.pager::
@@ -1113,7 +1113,7 @@ instaweb.port::
linkgit:git-instaweb[1].
interactive.singlekey::
- In interactive programs, allow the user to provide one-letter
+ In interactive commands, allow the user to provide one-letter
input with a single key (i.e., without hitting enter).
Currently this is used only by the `\--patch` mode of
linkgit:git-add[1]. Note that this setting is silently
diff --git a/Documentation/fetch-options.txt b/Documentation/fetch-options.txt
index d313795..20bf512 100644
--- a/Documentation/fetch-options.txt
+++ b/Documentation/fetch-options.txt
@@ -1,7 +1,7 @@
-q::
--quiet::
Pass --quiet to git-fetch-pack and silence any other internally
- used programs.
+ used git commands.
-v::
--verbose::
diff --git a/Documentation/git-rev-list.txt b/Documentation/git-rev-list.txt
index bf98c84..21ccccd 100644
--- a/Documentation/git-rev-list.txt
+++ b/Documentation/git-rev-list.txt
@@ -90,7 +90,7 @@ between the two operands. The following two commands are equivalent:
$ git rev-list A...B
-----------------------------------------------------------------------
-'git-rev-list' is a very essential git program, since it
+'rev-list' is a very essential git command, since it
provides the ability to build and traverse commit ancestry graphs. For
this reason, it has a lot of different options that enables it to be
used by commands as different as 'git-bisect' and
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 5fd5953..fe13e09 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -327,7 +327,7 @@ Synching repositories
include::cmds-synchingrepositories.txt[]
-The following are helper programs used by the above; end users
+The following are helper commands used by the above; end users
typically do not use them directly.
include::cmds-synchelpers.txt[]
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index aaa073e..1195e83 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -404,7 +404,7 @@ Performing a three-way merge
The attribute `merge` affects how three versions of a file is
merged when a file-level merge is necessary during `git merge`,
-and other programs such as `git revert` and `git cherry-pick`.
+and other commands such as `git revert` and `git cherry-pick`.
Set::
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 7ba5e58..b3640c4 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -12,7 +12,7 @@ git *
DESCRIPTION
-----------
-This tutorial explains how to use the "core" git programs to set up and
+This tutorial explains how to use the "core" git commands to set up and
work with a git repository.
If you just need to use git as a revision control system you may prefer
@@ -1328,7 +1328,7 @@ into it later. Obviously, this repository creation needs to be
done only once.
[NOTE]
-'git-push' uses a pair of programs,
+'git-push' uses a pair of commands,
'git-send-pack' on your local machine, and 'git-receive-pack'
on the remote machine. The communication between the two over
the network internally uses an SSH connection.
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 0b88a51..67ebffa 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4131,7 +4131,7 @@ What does this mean?
`git rev-list` is the original version of the revision walker, which
_always_ printed a list of revisions to stdout. It is still functional,
-and needs to, since most new Git programs start out as scripts using
+and needs to, since most new Git commands start out as scripts using
`git rev-list`.
`git rev-parse` is not as important any more; it was only used to filter out
diff --git a/help.c b/help.c
index 6c46d8b..57a0e0e 100644
--- a/help.c
+++ b/help.c
@@ -334,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
const char *assumed = main_cmds.names[0]->name;
main_cmds.names[0] = NULL;
clean_cmdnames(&main_cmds);
- fprintf(stderr, "WARNING: You called a Git program named '%s', "
+ fprintf(stderr, "WARNING: You called a Git command named '%s', "
"which does not exist.\n"
"Continuing under the assumption that you meant '%s'\n",
cmd, assumed);
--
1.6.2.GIT
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: bug with .git file and aliases
From: Johannes Sixt @ 2009-08-11 10:26 UTC (permalink / raw)
To: Michael J Gruber
Cc: Jeff King, Geoffrey Irving, git, Lars Hjemli, Johannes Schindelin
In-Reply-To: <4A814216.20708@drmicha.warpmail.net>
Michael J Gruber schrieb:
> ...because it was up to the brave git-on-win folks to decide whether
> setenv() on win would be rewritten to not use putenv() when the value is
> "". J&J, has anything happened on the front or is it likely to? (I'm
> sorry I can't offer help, only moral support...)
Nothing has changed since. Nothing is likely to happen until there is a
need to touch compat/setenv.c, like, for example, a test in the test suite
that fails only on Windows...
-- Hannes
^ permalink raw reply
* Re: [Feature Request] git export
From: Michael J Gruber @ 2009-08-11 7:50 UTC (permalink / raw)
To: thomas; +Cc: git
In-Reply-To: <200908101822.59940.thomas@koch.ro>
Thomas Koch venit, vidit, dixit 10.08.2009 18:22:
> could you please provide a simple solution to save a tree object into an
> arbitrary location?
> I found some hints, that it would be possible by missusing either git
> checkout-index or git-archive, but I think that it shouldn't require that much
> GIT FU to do such a simple thing.
>
> Thanks,
>
> Thomas Koch, http://www.koch.ro
To serve you with an explicit command line, it's really only
git archive HEAD | tar -C wheretoexport/ -xf-
which you need to issue from within your git repo. Instead of HEAD, you
can use any "treeish", for example the name of a branch, which need not
be checked out. You can add path arguments after the treeish if you want
to export only parts of your repo.
Note that in true unix philosophy, git archive does the (git specific)
exporting only and leaves the importing into the file system (saving) to
the proper tool. I mean, would you rather use cp -r or pipes with tar
-x/tar -c or cpio -i/-o in order to copy a tree? ;)
Cheers,
Michael
^ permalink raw reply
* Re: bug with .git file and aliases
From: Michael J Gruber @ 2009-08-11 10:04 UTC (permalink / raw)
To: Jeff King
Cc: Geoffrey Irving, git, Lars Hjemli, Johannes Sixt,
Johannes Schindelin
In-Reply-To: <20090720152117.GB5347@coredump.intra.peff.net>
Jeff King venit, vidit, dixit 20.07.2009 17:21:
> On Mon, Jul 20, 2009 at 09:54:12AM -0400, Geoffrey Irving wrote:
>
>> git 1.6.3.3 has a bug related to .git file support and aliases.
>> Specifically, if you make an alias for status and call it from a
>> subdirectory, git status chdirs into the true .git dir but then
>> chdir's back to the wrong place in order to run the lstats for status.
>> The result is that git status thinks all files have disappeared.
>
> Yeah, this is a known problem. The problem is that the 'git' wrapper
> sets up the environment only partially when running aliases, and then
> the resulting command ends up confused about where the worktree is. I
> really don't remember the specifics, but you can probably find some
> discussion in the list archives. Fixing it, IIRC, required some
> refactoring of the setup code (which I had hoped to get to at some
> point, but I am way behind on my git todo list).
>
> Hmm. Poking around a bit, this seems related, but I don't know why I
> never followed up:
>
> http://article.gmane.org/gmane.comp.version-control.git/72792
>
> -Peff
...because it was up to the brave git-on-win folks to decide whether
setenv() on win would be rewritten to not use putenv() when the value is
"". J&J, has anything happened on the front or is it likely to? (I'm
sorry I can't offer help, only moral support...)
Jeff's patch from Feb. 08 still applies more or less cleanly (with
obvious adjustments) and makes the relevant tests pass (on Linux).
Michael
^ 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