* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Junio C Hamano @ 2009-08-25 22:42 UTC (permalink / raw)
To: Jeff King; +Cc: Kirill A. Korinskiy, git
In-Reply-To: <20090825215726.GA30981@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Aug 25, 2009 at 11:27:47PM +0400, Kirill A. Korinskiy wrote:
>
>> +test_expect_success 'clone' '
>> +
>> + git clone parent clone &&
>> + (cd clone && git rev-parse --verify refs/remotes/origin/master)
>> +
>> +'
>> +
>> +test_expect_success 'clone -b' '
>> +
>> + git clone -b two parent clone-b &&
>> + (cd clone-b && test $(git rev-parse --verify HEAD) = $(git rev-parse --verify refs/remotes/origin/two))
>> +
>> +'
>
> OK, I think that second test makes sense (though please wrap the very
> long line), but now what is the first one doing? Shouldn't it be:
>
> (cd clone &&
> test $(git rev-parse --verify HEAD) = \
> $(git rev-parse --verify refs/remotes/origin/master)
> )
>
> also?
Are you checking that the HEAD (whichever branch it points at) points at
the same commit, or are you also interested in the _current branch_ to be
a particular name as well? The suggested check only compares commits and
HEAD can be pointing at a local branch whose name is xyzzy.
What is the semantics of this new -b option? When the remote repository
has 'next' as its default branch (i.e. HEAD points at it), and if you run
clone with "-b maint" against it, I expect that the checked out commit
will be the 'maint' of remote repository, but what is the name of the
current branch in the resulting clone on our end?
- Would we use 'master' as the name of our current branch, because that
is the default?
- Would we use 'next' as the name of our current branch, because that is
what the remote side uses?
- Would we use 'maint', because that is what -b gave us?
I am _hoping_ it is the last one, as otherwise you would also need to make
sure that the branch that is different from 'maint' we set as the current
branch must track 'maint' from the remote.
Oh, with -b, would we set up our 'maint' to track their 'maint'? Is it
something you may want to verify as well?
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Björn Steinbrink @ 2009-08-25 22:36 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: gitster, git
In-Reply-To: <1251228467-29638-1-git-send-email-catap@catap.ru>
On 2009.08.25 23:27:47 +0400, Kirill A. Korinskiy wrote:
> Sometimes (especially on production systems) we need to use only one
> remote branch for building software. It's really annoying to clone
> origin and then switch branch by hand everytime. So this patch
> provides functionality to clone a remote branch with one command
> without using checkout after clone.
>
> Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
> ---
> Documentation/git-clone.txt | 4 ++++
> builtin-clone.c | 23 ++++++++++++++++++++---
> t/t5706-clone-branch.sh | 31 +++++++++++++++++++++++++++++++
> 3 files changed, 55 insertions(+), 3 deletions(-)
> create mode 100755 t/t5706-clone-branch.sh
>
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index 2c63a0f..50446d2 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -127,6 +127,10 @@ objects from the source repository into a pack in the cloned repository.
> Instead of using the remote name 'origin' to keep track
> of the upstream repository, use <name>.
>
> +--branch <name>::
> +-b <name>::
> + Instead of using the remote HEAD as master, use <name> branch.
Hm, that's no good. The branch won't be called master, nor is HEAD used
as "master" anyway. If the remote repo's HEAD references refs/heads/foo,
you'll get refs/heads/foo locally as well, not "master", but see below.
Maybe: Create a local branch head for <name> instead of the branch
referenced by the remote repo's HEAD.
> @@ -65,6 +66,8 @@ static struct option builtin_clone_options[] = {
> "reference repository"),
> OPT_STRING('o', "origin", &option_origin, "branch",
> "use <branch> instead of 'origin' to track upstream"),
> + OPT_STRING('b', "branch", &option_branch, "branch",
> + "use <branch> from 'origin' as HEAD"),
Using 'origin' there is unfortunate, as using "--origin foo" would make
clone call the remote "foo" instead of "origin". And it's not really
used "as" HEAD, but instead of the remote repo's HEAD to determine which
local branch head to create. Though I guess this affect the
refs/remotes/<remote>/HEAD symref as well?
> @@ -518,7 +521,21 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
>
> mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
>
> - remote_head = find_ref_by_name(refs, "HEAD");
> + if (option_branch) {
> + strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
> +
> + remote_head = find_ref_by_name(refs, branch_head.buf);
> + }
> +
> + if (!remote_head) {
> + if (option_branch)
> + warning("Remote branch %s not found in upstream %s"
> + ", using HEAD instead",
> + option_branch, option_origin);
> +
> + remote_head = find_ref_by_name(refs, "HEAD");
> + }
> +
> head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
This would still pick refs/heads/master if refs/heads/master and
refs/heads/<branch> reference the same commit. That's due to the check
in guess_remote_head() which prefers refs/heads/master over all other
refs. While this is acceptable for the HEAD lookup, I'd treat that as a
bug for this new option.
> }
> else {
> diff --git a/t/t5706-clone-branch.sh b/t/t5706-clone-branch.sh
> new file mode 100755
> index 0000000..8d83ac8
> --- /dev/null
> +++ b/t/t5706-clone-branch.sh
> @@ -0,0 +1,31 @@
> +#!/bin/sh
> +
> +test_description='branch clone options'
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> +
> + mkdir parent &&
> + (cd parent && git init &&
> + echo one >file && git add file &&
> + git commit -m one && git checkout -b two &&
> + echo two >f && git add f && git commit -m two &&
> + git checkout master)
> +
> +'
> +
> +test_expect_success 'clone' '
> +
> + git clone parent clone &&
> + (cd clone && git rev-parse --verify refs/remotes/origin/master)
> +
> +'
> +
> +test_expect_success 'clone -b' '
> +
> + git clone -b two parent clone-b &&
> + (cd clone-b && test $(git rev-parse --verify HEAD) = $(git rev-parse --verify refs/remotes/origin/two))
This should probably check not just that HEAD resolves to the same
commit as refs/remotes/origin/two, but that HEAD references
refs/heads/two as well, even if the remote's refs/heads/master
references the same commit as refs/heads/two (see above).
Björn
^ permalink raw reply
* git svn messages
From: John Tapsell @ 2009-08-25 22:31 UTC (permalink / raw)
To: Git List
Hi all,
When doing git svn dcommit, the messages that it gives are, well,
frightening :-)
It's full of things like:
> No changes between current HEAD and refs/remotes/git-svn
No changes? What's gone wrong? Why can't it find any changes?..
> Resetting to the latest refs/remotes/git-svn
That doesn't sound good. Why did it have reset? Were the errors to
great for it to continue, so it had to reset?
John
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Jeff King @ 2009-08-25 21:57 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: gitster, git
In-Reply-To: <1251228467-29638-1-git-send-email-catap@catap.ru>
On Tue, Aug 25, 2009 at 11:27:47PM +0400, Kirill A. Korinskiy wrote:
> +test_expect_success 'clone' '
> +
> + git clone parent clone &&
> + (cd clone && git rev-parse --verify refs/remotes/origin/master)
> +
> +'
> +
> +test_expect_success 'clone -b' '
> +
> + git clone -b two parent clone-b &&
> + (cd clone-b && test $(git rev-parse --verify HEAD) = $(git rev-parse --verify refs/remotes/origin/two))
> +
> +'
OK, I think that second test makes sense (though please wrap the very
long line), but now what is the first one doing? Shouldn't it be:
(cd clone &&
test $(git rev-parse --verify HEAD) = \
$(git rev-parse --verify refs/remotes/origin/master)
)
also?
-Peff
^ permalink raw reply
* Re: git only one file
From: Giuseppe Bilotta @ 2009-08-25 21:29 UTC (permalink / raw)
To: git; +Cc: synhedionn
In-Reply-To: <synhedionn <synhedionn@gmail.com>
synhedionn <synhedionn@gmail.com> wrote:
> with git add . Â , a directory is expected, but I don't need all my files to
> be recorded, only one of my thousands, so how can I record just 1 file?
Generally, if you want to track a single file in a directory you just
add that file, as per Matthias' suggestion, and possibly create a
.gitignore with the single '*' pattern in it..
<shameless plug>
However, if you want to track more than one _independent_ files in the
same directory (RCS-style), then I would recommend you look into zit,
the Git-based single-file content tracker I've developed. You can find
it at git://git.oblomov.eu/zit ( gitweb at http://git.oblomov.eu/zit )
</shameless plug>
^ permalink raw reply
* Re: [PATCH v2] Add script for importing bits-and-pieces to Git.
From: Junio C Hamano @ 2009-08-25 20:42 UTC (permalink / raw)
To: Peter Krefting; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0908251953480.19406@ds9.cixit.se>
Peter Krefting <peter@softwolves.pp.se> writes:
>> You might want to mention that this format is different from what
>> git uses for its .git/config and .gitmodules files, and none of the
>> rules apply to them (namely, two/three-level names, case
>> sensitivity, allowed letters in variable names, stripping of
>> whitespaces around values, and value quoting) described in 'git help
>> config' apply to this file.
>
> A quick question on that: Is it possible to use the git-config parser
> stand-alone from a script like this? Then that note wouldn't need to
> apply.
Yes, but then you have to update your data language, because some of the
section names and variables names you would want to use in your script are
illegal in "git config" configuration language. Values and the second
level name in two level section names are more-or-less free form (they
need to be quoted as appropriately), but the first-level section names and
the variable names are case insensitive, do not allow SPs and funnies, and
there is no escaping. You cannot have "source.c" as the variable name,
for example.
I'd recommend against re-using the git config format for that reason.
Another possibility would be to use something that does not even resemble
the git config format, say, YAML as your data language. There is no risk
of confusion from the end users if you did so, and we wouldn't need the
note either.
>> As you seem to be supporting merges, you might want to say
>> topologically instead of chronologically---this is minor, as you
>> give more precise definition "all parents must come before a child"
>> in that sentence later.
>
> I'm not sure I get the distinction here. Could you be a bit more
> specific (or point me to what I have missed in the Git manual)?
Your history could be in this shape (numbers are timestamps recorded in
commit):
1--4
/ \
0--3--6---9--12
when somebody with a skewed clock forked the project at commit 3, worked
on a side branch to create two commits 1 and 4, which are pulled back to
the mainline at commit 9.
Chronological listing would mean 0 1 3 4 6 9 12. Topological listing
would be either 0 3 1 4 6 9 12 or 0 3 6 1 4 9 12 or 0 3 1 6 4 9 12.
^ permalink raw reply
* Re: [PATCH] git-tag(1): Refer to git-check-ref-format(1) for <name>
From: Junio C Hamano @ 2009-08-25 20:37 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Jari Aalto
In-Reply-To: <20090825172100.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting myself...
>
>> Subject: Documentation: consistently refer to check-ref-format
>>
>> Change the <name> placeholder to <tagname> in the SYNOPSIS section of
>> git-tag documentation, and describe it in the OPTIONS section in a way
>> similar to how documentation for git-branch does.
>>
>> Add SEE ALSO section to list the other documentation pages these two pages
>> refer to.
>>
>> Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
>
> Should I further polish this patch?
No, it just fell through the cracks of my mailbox. I tend to agree that
it is better to mention only the presense of rules, and refer to the rules
described in the definitive document.
Safe names are designed to be what most sane people would naturally choose
to use anyway and they would not need to see the clutter that describes
only the half of the rules there. And more importantly, the people who do
get errors by choosing illegal names by accident would _want_ to see the
full set of rules before choosing another name to avoid getting the same
error again.
Spelling only the half of the rules in the tag/branch manual page would
not help neither audience.
^ permalink raw reply
* Re: git only one file
From: Matthias Kestenholz @ 2009-08-25 19:38 UTC (permalink / raw)
To: synhedionn; +Cc: git
In-Reply-To: <25140456.post@talk.nabble.com>
On Tue, Aug 25, 2009 at 9:12 PM, synhedionn<synhedionn@gmail.com> wrote:
>
> with git add . , a directory is expected, but I don't need all my files to
> be recorded, only one of my thousands, so how can I record just 1 file?
By only adding this file to the index. Use "git add $yourfile" instead
of "git add ."
If you do not want to see your thousands of files in the directory
when running git status, you can simply create a .gitignore file with
* as content. Git will still notify you about files which it already
knows about, even though the .gitignore entry tells it to ignore
everything.
Matthias
^ permalink raw reply
* [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Kirill A. Korinskiy @ 2009-08-25 19:27 UTC (permalink / raw)
To: gitster; +Cc: git, Kirill A. Korinskiy
In-Reply-To: <1251228341-29434-1-git-send-email-catap@catap.ru>
Sometimes (especially on production systems) we need to use only one
remote branch for building software. It's really annoying to clone
origin and then switch branch by hand everytime. So this patch
provides functionality to clone a remote branch with one command
without using checkout after clone.
Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
---
Documentation/git-clone.txt | 4 ++++
builtin-clone.c | 23 ++++++++++++++++++++---
t/t5706-clone-branch.sh | 31 +++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
create mode 100755 t/t5706-clone-branch.sh
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 2c63a0f..50446d2 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -127,6 +127,10 @@ objects from the source repository into a pack in the cloned repository.
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name>.
+--branch <name>::
+-b <name>::
+ Instead of using the remote HEAD as master, use <name> branch.
+
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
diff --git a/builtin-clone.c b/builtin-clone.c
index 32dea74..9cea056 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -41,6 +41,7 @@ static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
+static char *option_branch = NULL;
static char *option_upload_pack = "git-upload-pack";
static int option_verbose;
@@ -65,6 +66,8 @@ static struct option builtin_clone_options[] = {
"reference repository"),
OPT_STRING('o', "origin", &option_origin, "branch",
"use <branch> instead of 'origin' to track upstream"),
+ OPT_STRING('b', "branch", &option_branch, "branch",
+ "use <branch> from 'origin' as HEAD"),
OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
@@ -347,8 +350,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const char *repo_name, *repo, *work_tree, *git_dir;
char *path, *dir;
int dest_exists;
- const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
- struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
+ const struct ref *refs, *head_points_at, *remote_head = NULL, *mapped_refs;
+ struct strbuf key = STRBUF_INIT, value = STRBUF_INIT, branch_head = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
char *src_ref_prefix = "refs/heads/";
@@ -518,7 +521,21 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
- remote_head = find_ref_by_name(refs, "HEAD");
+ if (option_branch) {
+ strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
+
+ remote_head = find_ref_by_name(refs, branch_head.buf);
+ }
+
+ if (!remote_head) {
+ if (option_branch)
+ warning("Remote branch %s not found in upstream %s"
+ ", using HEAD instead",
+ option_branch, option_origin);
+
+ remote_head = find_ref_by_name(refs, "HEAD");
+ }
+
head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
}
else {
diff --git a/t/t5706-clone-branch.sh b/t/t5706-clone-branch.sh
new file mode 100755
index 0000000..8d83ac8
--- /dev/null
+++ b/t/t5706-clone-branch.sh
@@ -0,0 +1,31 @@
+#!/bin/sh
+
+test_description='branch clone options'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one && git checkout -b two &&
+ echo two >f && git add f && git commit -m two &&
+ git checkout master)
+
+'
+
+test_expect_success 'clone' '
+
+ git clone parent clone &&
+ (cd clone && git rev-parse --verify refs/remotes/origin/master)
+
+'
+
+test_expect_success 'clone -b' '
+
+ git clone -b two parent clone-b &&
+ (cd clone-b && test $(git rev-parse --verify HEAD) = $(git rev-parse --verify refs/remotes/origin/two))
+
+'
+
+test_done
--
1.6.2
^ permalink raw reply related
* [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Kirill A. Korinskiy @ 2009-08-25 19:25 UTC (permalink / raw)
To: gitster; +Cc: git, Kirill A. Korinskiy
In-Reply-To: <87praj90n8.wl%catap@catap.ru>
Sometimes (especially on production systems) we need to use only one
remote branch for building software. It really annoying to clone
origin and then swith branch by hand everytime. So this patch provide
functionality to clone remote branch with one command without using
checkout after clone.
Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
---
Documentation/git-clone.txt | 4 ++++
builtin-clone.c | 23 ++++++++++++++++++++---
t/t5706-clone-branch.sh | 31 +++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
create mode 100755 t/t5706-clone-branch.sh
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 2c63a0f..50446d2 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -127,6 +127,10 @@ objects from the source repository into a pack in the cloned repository.
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name>.
+--branch <name>::
+-b <name>::
+ Instead of using the remote HEAD as master, use <name> branch.
+
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
diff --git a/builtin-clone.c b/builtin-clone.c
index 32dea74..9cea056 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -41,6 +41,7 @@ static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
+static char *option_branch = NULL;
static char *option_upload_pack = "git-upload-pack";
static int option_verbose;
@@ -65,6 +66,8 @@ static struct option builtin_clone_options[] = {
"reference repository"),
OPT_STRING('o', "origin", &option_origin, "branch",
"use <branch> instead of 'origin' to track upstream"),
+ OPT_STRING('b', "branch", &option_branch, "branch",
+ "use <branch> from 'origin' as HEAD"),
OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
@@ -347,8 +350,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const char *repo_name, *repo, *work_tree, *git_dir;
char *path, *dir;
int dest_exists;
- const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
- struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
+ const struct ref *refs, *head_points_at, *remote_head = NULL, *mapped_refs;
+ struct strbuf key = STRBUF_INIT, value = STRBUF_INIT, branch_head = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
char *src_ref_prefix = "refs/heads/";
@@ -518,7 +521,21 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
- remote_head = find_ref_by_name(refs, "HEAD");
+ if (option_branch) {
+ strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
+
+ remote_head = find_ref_by_name(refs, branch_head.buf);
+ }
+
+ if (!remote_head) {
+ if (option_branch)
+ warning("Remote branch %s not found in upstream %s"
+ ", using HEAD instead",
+ option_branch, option_origin);
+
+ remote_head = find_ref_by_name(refs, "HEAD");
+ }
+
head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
}
else {
diff --git a/t/t5706-clone-branch.sh b/t/t5706-clone-branch.sh
new file mode 100755
index 0000000..8d83ac8
--- /dev/null
+++ b/t/t5706-clone-branch.sh
@@ -0,0 +1,31 @@
+#!/bin/sh
+
+test_description='branch clone options'
+. ./test-lib.sh
+
+test_expect_success 'setup' '
+
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one && git checkout -b two &&
+ echo two >f && git add f && git commit -m two &&
+ git checkout master)
+
+'
+
+test_expect_success 'clone' '
+
+ git clone parent clone &&
+ (cd clone && git rev-parse --verify refs/remotes/origin/master)
+
+'
+
+test_expect_success 'clone -b' '
+
+ git clone -b two parent clone-b &&
+ (cd clone-b && test $(git rev-parse --verify HEAD) = $(git rev-parse --verify refs/remotes/origin/two))
+
+'
+
+test_done
--
1.6.2
^ permalink raw reply related
* Re: [PATCH] import-tars: Allow per-tar author and commit message.
From: Junio C Hamano @ 2009-08-25 19:21 UTC (permalink / raw)
To: Peter Krefting; +Cc: Nanako Shiraishi, Sam Vilain, git
In-Reply-To: <alpine.DEB.2.00.0908251950010.19406@ds9.cixit.se>
Peter Krefting <peter@softwolves.pp.se> writes:
> Junio C Hamano:
>
>> Unlike your "import-directories" that is a brand new program without
>> any existing users, you are touching code that other people have
>> already used, and you do not want to change the behaviour for them
>> only because they happen to have unrelated files in the same
>> directory.
>
> Indeed. Not that it is likely that one have stray filetar.gz.msg files
> just laying around, but I'll add a command line switch to enable the
> new functinality. That sounds like the most reasonable way to go,
> leaving the old usage completely unaffected by the change.
And the switch could be "--metainfo=<ext>", so that people can choose to
use other extensions, e.g. with "--metainfo=info" file.tar.info would be
read for descriptions.
^ permalink raw reply
* git only one file
From: synhedionn @ 2009-08-25 19:12 UTC (permalink / raw)
To: git
with git add . , a directory is expected, but I don't need all my files to
be recorded, only one of my thousands, so how can I record just 1 file?
--
View this message in context: http://www.nabble.com/git-only-one-file-tp25140456p25140456.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Jeff King @ 2009-08-25 19:00 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: gitster, git
In-Reply-To: <1251220806-17607-1-git-send-email-catap@catap.ru>
Thanks for revising, it is looking a bit better. A few comments still,
though:
On Tue, Aug 25, 2009 at 09:20:06PM +0400, Kirill A. Korinskiy wrote:
> Sometimes (especially on production systems) we need to use only one
> remote branch for building software. It really annoying to clone
> origin and then swith branch by hand everytime. So this patch provide
> functionality to clone remote branch with one command without using
> checkout after clone.
Typos:
s/It/It's/
s/swith/switch/
s/provide/provides/
s/clone remote/clone a remote/
> t/t5706-clone-brnach.sh | 31 +++++++++++++++++++++++++++++++
Typo: s/brnach/branch/ :)
> +test_expect_success 'clone' '
> +
> + git clone parent clone &&
> + (cd clone && git rev-parse --verify refs/remotes/origin/master)
> +
> +'
> +
> +test_expect_success 'clone -b' '
> +
> + git clone -b two parent clone-b &&
> + (cd clone && git rev-parse --verify refs/remotes/origin/two)
> +
> +'
Is this really testing the right thing? Shouldn't you always have
refs/remotes/origin/*, no matter what "-b" says? The difference should
be that HEAD in the first test will point to 'master', and to 'two' in
the second test.
-Peff
^ permalink raw reply
* Re: [PATCH v2] Add script for importing bits-and-pieces to Git.
From: Peter Krefting @ 2009-08-25 18:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6p9do4k.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Nice write-up.
Thank you.
As to your questions, they are very good, and I'll try to update the
documentation a bit to clarify the points you made. This is the first time
someone who is not myself have read it, so I expected some rough edges...
Follow-ups on some of the points (I will address the rest as well):
> You might want to mention that this format is different from what git uses
> for its .git/config and .gitmodules files, and none of the rules apply to
> them (namely, two/three-level names, case sensitivity, allowed letters in
> variable names, stripping of whitespaces around values, and value quoting)
> described in 'git help config' apply to this file.
A quick question on that: Is it possible to use the git-config parser
stand-alone from a script like this? Then that note wouldn't need to apply.
> As you seem to be supporting merges, you might want to say topologically
> instead of chronologically---this is minor, as you give more precise
> definition "all parents must come before a child" in that sentence later.
I'm not sure I get the distinction here. Could you be a bit more specific
(or point me to what I have missed in the Git manual)?
> How are problematic characters in pathnames (say, SP, '=' or worse LF)
> handled? Do they need to be quoted, and if so how?
In the current version: Not at all. :-) I didn't need to, at the time.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] import-tars: Allow per-tar author and commit message.
From: Peter Krefting @ 2009-08-25 18:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Sam Vilain, git
In-Reply-To: <7vab1pf3fj.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Unlike your "import-directories" that is a brand new program without any
> existing users, you are touching code that other people have already used,
> and you do not want to change the behaviour for them only because they
> happen to have unrelated files in the same directory.
Indeed. Not that it is likely that one have stray filetar.gz.msg files just
laying around, but I'll add a command line switch to enable the new
functinality. That sounds like the most reasonable way to go, leaving the
old usage completely unaffected by the change.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Jeff King @ 2009-08-25 18:45 UTC (permalink / raw)
To: Tom Werner; +Cc: Tom Preston-Werner, git
In-Reply-To: <12c267e40908251043g4f3e36aya05d9c705f5afee2@mail.gmail.com>
On Tue, Aug 25, 2009 at 10:43:57AM -0700, Tom Werner wrote:
> On Tue, Aug 18, 2009 at 12:04 AM, Tom Preston-Werner<tom@mojombo.com> wrote:
> > A post-upload-pack hook is desirable for Git hosts that need to
> > collect statistics on how many clones and/or fetches are made
> > on each repository.
> >
> > The hook is called with either "clone" or "fetch" as the only
> > argument, depending on whether a full pack file was sent to the
> > client or not.
>
> I was hoping to get some feedback on this patch, either positive or
> negative. Since we'll be applying this patch for our use of the Git
> Daemon on GitHub, it would be great to see it in core, so we don't
> have to maintain custom debian builds forever. I'd imagine that other
> Git hosting sites would find this hook useful as well. Thanks!
I expect it didn't get any response because nobody here cared one way or
the other. Not too surprising, since I think not many people are running
a GitHub-sized hosting site that cares about such statistics. ;) So I
think following up as you are doing is the right thing.
As for the hook itself, the concept certainly seems sane to me. It
passes the "hook" test defined here:
http://thread.gmane.org/gmane.comp.version-control.git/70781/focus=71069
because it is a remote trigger.
But a few comments on the patch:
> ---
> upload-pack.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
It needs at least a mention in Documentation/githooks.txt.
> +static void run_post_upload_pack_hook(int create_full_pack)
> +{
> + const char *fetch_type;
> + fetch_type = (create_full_pack) ? "clone" : "fetch";
> + run_hook(get_index_file(), "post-upload-pack", fetch_type);
> +}
Does it really need an index file? This operation in question seems to
be totally disconnected from the index (and indeed, most bare
repositories won't even have one). Probably it should pass NULL as the
initial argument to run_hook.
Is there any other information that might be useful to other non-GitHub
users of the hook? The only thing I can think of is the list of refs
that were fetched. I don't want to over-engineer it, but nor do I want
to be left with the mess of retro-fitting more information onto an
existing hook later. Maybe others can comment on whether they would find
more information useful.
-Peff
^ permalink raw reply
* Re: Confused about push/pull of a branch
From: Jeff King @ 2009-08-25 18:32 UTC (permalink / raw)
To: Fritz Anderson; +Cc: git
In-Reply-To: <8E2E19AE-DFA6-4000-AD73-35739F1E6642@uchicago.edu>
On Tue, Aug 25, 2009 at 12:58:25PM -0500, Fritz Anderson wrote:
> >I can't get a second machine to pull in a branch that's in my
> >remote repository. I'm confused.
>
> And just from half-wittedly fooling around, I tried:
>
> machine_2$ git pull origin webservices
That will merge the 'webservices' branch from your origin with your
current branch (which looks like 'master' in this case).
Remember that "pull" in git is really just "fetch" and "merge". What you
want is "fetch" and "create a new local branch":
$ git fetch
$ git checkout -b webservices origin/webservices
except that the "fetch" step has probably already been done as a
side-effect of the pull you did earlier.
> This seems to mean that master on machine_2 is now congruent to
> webservices on machine_1. That's not what I meant. Is there a way to
> undo this? git-pull origin-master doesn't seem to do anything.
Sort of. It contains all the changes of 'master' _and_ all the changes
of 'webservices'. However in this case there were no changes in 'master'
that were not already in 'webservices', so we were able to "fast
forward" to where webservices is. If the two branches had diverged at
all, you would have had a merge (potentially with conflicts).
To undo it, you probably want:
$ git checkout master ;# make sure we are on master branch
$ git reset --hard origin/master ;# go back to where remote master is
-Peff
^ permalink raw reply
* Re: Confused about push/pull of a branch
From: Jeff King @ 2009-08-25 18:27 UTC (permalink / raw)
To: Fritz Anderson; +Cc: git
In-Reply-To: <BA2E0DDB-3DE0-4D49-BFA6-72CFEDEBA5AE@uchicago.edu>
On Tue, Aug 25, 2009 at 12:40:47PM -0500, Fritz Anderson wrote:
> Branch webservices was created after the working copy on machine_2
> was cloned.
>
> In my working copy on machine_2:
>
> machine_2$ git pull
> Password:
> # Progress messages, no protests.
> machine_2$ git checkout webservices
> error: pathspec 'webservices' did not match any file(s) known to git.
> machine_2$ git branch
> * master
> machine_2$
Try "git branch -a", which will list remote branches. You likely have a
remote tracking branch "origin/webservices". You can check that out to
examine it, or if you want to start working on it locally, try "git
checkout -b webservices origin/webservices".
> git-config shows the two repository URLs are identical, net of
> machine_2 having to specify a user name and host. The machine_2 .git/
> config shows a section for [branch "master"], but not for
> webservices. Is that the problem? What's the approved way of adding
> [branch "webservices"], and what do I put into it?
The branch.webservices config is not necessary for a branch; it just
says "by the way, when you do a pull without arguments and we are on
this branch, here is where to pull from". Doing the "checkout -b" above
will create such a config section on recent versions of git.
> I've obviously forgotten something. Or never understood something
> (there's a lot in Git not to understand). How do I get the
> webservices branch onto machine_2, so I can check it out?
The branching model in git is a little different than other systems.
Just because the remote has a branch does not mean _you_ have a branch.
When you fetch from them (or pull, which does a fetch behind the
scenes), you will have a "remote tracking branch" which is your local
copy of where their remote branches are. You still need to create your
own local branch if you want to do work on it (and bear in mind your
branch doesn't need the same name or to be related in any long term way;
you are merely using their remote branch as a starting point for your
branch).
-Peff
^ permalink raw reply
* Re: Confused about push/pull of a branch
From: Fritz Anderson @ 2009-08-25 18:00 UTC (permalink / raw)
To: git
In-Reply-To: <8E2E19AE-DFA6-4000-AD73-35739F1E6642@uchicago.edu>
On Aug 25, 2009, at 12:58 PM, Fritz Anderson wrote:
> This seems to mean that master on machine_2 is now congruent to
> webservices on machine_1. That's not what I meant. Is there a way to
> undo this? git-pull origin-master doesn't seem to do anything.
Sigh. "git pull origin master". Sorry.
— F
^ permalink raw reply
* Re: Confused about push/pull of a branch
From: Fritz Anderson @ 2009-08-25 17:58 UTC (permalink / raw)
To: git
In-Reply-To: <BA2E0DDB-3DE0-4D49-BFA6-72CFEDEBA5AE@uchicago.edu>
On Aug 25, 2009, at 12:40 PM, Fritz Anderson wrote:
> I can't get a second machine to pull in a branch that's in my remote
> repository. I'm confused.
And just from half-wittedly fooling around, I tried:
machine_2$ git pull origin webservices
Password:
From fritza@fritzanderson.uchicago.edu:/Users/fritza/scientia/scientia
* branch webservices -> FETCH_HEAD
Updating 3c86901..6b09f9f
Fast forward
Calendar/Classes/CalendarWebController.m | 2 ++
# etc.
dirserver/lib/ldaputils.rb | 15 +++++----------
6 files changed, 34 insertions(+), 17 deletions(-)
machine_2$ sudo /usr/local/bin/git branch
* master
machine_2$
This seems to mean that master on machine_2 is now congruent to
webservices on machine_1. That's not what I meant. Is there a way to
undo this? git-pull origin-master doesn't seem to do anything.
— F
^ permalink raw reply
* Confused about push/pull of a branch
From: Fritz Anderson @ 2009-08-25 17:40 UTC (permalink / raw)
To: git
I can't get a second machine to pull in a branch that's in my remote
repository. I'm confused.
The remote is a bare repository on machine_1.
In my working copy on machine_1:
machine_1$ git branch
master
search-controller
use-tiles
* webservices
# The following should not be necessary, as gitk already
# identifies a remotes/origin/webservices, but just to be sporting:
machine_1$ git push origin webservices
Everything up-to-date
Branch webservices was created after the working copy on machine_2 was
cloned.
In my working copy on machine_2:
machine_2$ git pull
Password:
# Progress messages, no protests.
machine_2$ git checkout webservices
error: pathspec 'webservices' did not match any file(s) known to git.
machine_2$ git branch
* master
machine_2$
git-config shows the two repository URLs are identical, net of
machine_2 having to specify a user name and host. The machine_2 .git/
config shows a section for [branch "master"], but not for webservices.
Is that the problem? What's the approved way of adding [branch
"webservices"], and what do I put into it?
I've obviously forgotten something. Or never understood something
(there's a lot in Git not to understand). How do I get the webservices
branch onto machine_2, so I can check it out?
— F
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Tom Werner @ 2009-08-25 17:43 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git
In-Reply-To: <1250579093-40706-1-git-send-email-tom@mojombo.com>
On Tue, Aug 18, 2009 at 12:04 AM, Tom Preston-Werner<tom@mojombo.com> wrote:
> A post-upload-pack hook is desirable for Git hosts that need to
> collect statistics on how many clones and/or fetches are made
> on each repository.
>
> The hook is called with either "clone" or "fetch" as the only
> argument, depending on whether a full pack file was sent to the
> client or not.
I was hoping to get some feedback on this patch, either positive or
negative. Since we'll be applying this patch for our use of the Git
Daemon on GitHub, it would be great to see it in core, so we don't
have to maintain custom debian builds forever. I'd imagine that other
Git hosting sites would find this hook useful as well. Thanks!
Tom
--
Tom Preston-Werner
GitHub Cofounder
http://tom.preston-werner.com
github.com/mojombo
^ permalink raw reply
* Re: [PATCH] send-email: confirm on empty mail subjects
From: Junio C Hamano @ 2009-08-25 17:35 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0908251825150.21065@fbirervta.pbzchgretzou.qr>
Jan Engelhardt <jengelh@medozas.de> writes:
>>Near the tip of the 'pu' branch I
>>have a iffy workaround to "unbreak" the issue, but it is a rather
>>sledgehammer approach I do not feel comfortable enough to squash into your
>>patch yet.
>
> I see. Perhaps
>
> echo -en 'y\ny\n' | ...
>
> would be more gentle? (Noting that, how else should it be,
> many a shell do not have -e/-n again.)
You can solve it with printf "y\ny\n", but the reason I said it feels
wrong was because your added tests are the _only_ ones that expect more
than one "yes".
If some _other_ tests that currently need only one "yes" are broken in the
future and starts asking for more than one, we would like to know about
the breakage, but we won't notice it if we unconditionally fed "yes | ..."
or your "two y's | ..." to them. That is what I am unhappy about the
"iffy workaround".
^ permalink raw reply
* Re: [PATCH/RFC] make the new block-sha1 the default
From: Nicolas Pitre @ 2009-08-25 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vprakpett.fsf@alter.siamese.dyndns.org>
On Mon, 24 Aug 2009, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Mon, Aug 24, 2009 at 11:04:37PM -0400, Nicolas Pitre wrote:
> >
> >> ... and remove support for linking against the openssl SHA1 code.
> >>
> >> The block-sha1 implementation is not significantly worse and sometimes
> >> even faster than the openssl SHA1 implementation. This allows for
> >
> > Is there a reason not to leave the option of linking against openssl?
>
> I think it is a valid question. Why remove the _option_?
Indeed, there is no value in limiting the choice.
> I would certainly understand it if you made BLK_SHA1 the _default_, though.
Since this is a RFC, and because this is not a clear choice, I'll simply
let others play with it and see for themselves. Suffice to compile git
with or without NO_OPENSSL defined. Some people (such as Jeff) are
finding the openssl SHA1 faster (irrespective of the -O0 issue), whereas
Linus simply hammered on the block-sha1 version until it was faster than
openssl for him (this is faster for me as well, on X86 and ARM). Also
those who initially found openssl to put a significant overhead on the
dynamic linking should probably perform more measurements with and
without NO_OPENSSL again. If more positive results are presented then
changing the default might make sense.
Nicolas
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Thiago Farina @ 2009-08-25 17:24 UTC (permalink / raw)
To: Frank Li
Cc: Marius Storm-Olsen, Reece Dunn, Johannes.Schindelin, msysgit, git
In-Reply-To: <1976ea660908250732q1e1fc153g663f3a9c13f1c902@mail.gmail.com>
Hi,
On Tue, Aug 25, 2009 at 11:32 AM, Frank Li<lznuaa@gmail.com> wrote:
>> that it's generated by generate-cmdlist.sh, so the VS user will need
>> to generate this file first (before compiling)?
>
> I update http://repo.or.cz/w/gitbuild.git.
> Add create_command.bat to create common-cmds.h.
>
This is great, thank you for adding this tool.
Today I ran 'git submodule update --init' and I recieved this error:
No submodule mapping found in .gitmodules for path 'ext/zlib'
The entry I have for zlib in .gitmodules is:
[submodule "ext\\zlib"]
path = ext\\zlib
url = git://repo.or.cz/zlib.git
Is this correct? All the others entries are configured like this:
[submodule ext/git]
path = ext/git
url = git://repo.or.cz/tgit.git
Another question: Is not better to put the README inside gitbuild with
the other files instead of compat/vcbuild/?
^ 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