* Re: git only one file
From: Giuseppe Bilotta @ 2009-08-26 4:30 UTC (permalink / raw)
To: syn hedionn; +Cc: git
In-Reply-To: <a7c6f4d60908251605l5fb771a5t79b27cf688fab205@mail.gmail.com>
On Wed, Aug 26, 2009 at 1:05 AM, syn hedionn<synhedionn@gmail.com> wrote:
> ok , but if I put,
> git add index.htm
> I have:
> fatal: Not a git repository
You need to initialize the repository before you can add files to it, so:
git init
git add index.htm
git commit -m "Initial commit"
The zit way would be:
zit track index.htm
zit commit -m "Initial commit" index.htm
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Jeremy O'Brien @ 2009-08-26 4:24 UTC (permalink / raw)
To: Frank Münnich; +Cc: <git@vger.kernel.org>
In-Reply-To: <000001ca257d$b60326c0$22097440$@com>
Vim (or gvim if I want better colors), and cscope. Cscope + vim is a
killer combination that enables you to fly around projects of any size
very efficiently. I swear by it. I use it at my job to navigate a
project consisting of over 14000 lines of code. It makes tracing
execution and navigating a project child's play.
Hope that helps,
Jeremy
On Aug 25, 2009, at 8:15, Frank Münnich <git@frank-muennich.com> wrote:
> Hi there,
>
> I am interested in helping out and improving git, though I haven't
> programmed in C for quite a while now and thus have to relearn quite
> some
> things.
> I understand the different branches (master, next, pu) and so on,
> and were
> successful in compiling git with my Ubuntu 9.04. [yeea] ;)
>
> One thing I would like to ask you: what, if any, IDEs are you
> working with?
> I tried Anjuta but were unsuccessful in importing the git folder
> from any
> branch into Anjuta. Eclipse worked a bit better, though I am still
> batteling
> with the debugger a bit.
>
> Any recommendations, manuals or how-to tips are greatly welcome.
> And one thing: thank you for your effort! Git really caught my
> attention and
> I was so much amused by the Google-Techtalk that Linus gave about
> Git, that
> it sparked my interest in relearning how to program again ;)
>
> Best regards from lovely Dresden in Germany
> Frank Münnich
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-26 3:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Sebrecht, Nanako Shiraishi, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <7vvdkbl4ul.fsf@alter.siamese.dyndns.org>
The 25/08/09, Junio C Hamano wrote:
> What I meant was that I would not want to spend any more of _my_ time on
> the definition of the scissors for now. That means spending or wasting
> time on improving the 'pu' patch myself, or looking at others patch to
> find flaws in them.
>
> Of course, as the maintainer, I would need to look at proposals to improve
> or fix bugs in the code before the series hits the master, but I would
> give zero priority to the patches that change the definition at least for
> now to give myself time to work on more useful things.
Ok, thank you.
> I think --ignore-scissors is a good thing to add, regardless of what the
> definition of scissors should be. So your patch should definitely be
> separated into two parts.
Could find it at the end of the mails.
> > #include "builtin.h"
> > #include "utf8.h"
> > #include "strbuf.h"
> > +#include "git-compat-util.h"
>
> Inclusion of builtin.h is designed to be enough. What do you need this
> for?
It is for the warning() call
warning("scissors line found, will skip text above");
I've added. That said, moving this declaration to builtin.h could be a
good idea. Hint?
> > @@ -715,51 +717,63 @@ static inline int patchbreak(const struct strbuf *line)
> > if (isspace(buf[i])) {
> > + if (scissors_dashes_seen)
> > + mark_end = i;
>
> I think you do not want this part, and then you won't have to trim
> trailing whitespaces from mark_end later.
Good eyes.
> > + /*
> > + * The mark is 8 charaters long and contains at least one dash and
> > + * either a ">8" or "<8". Check if the last mark in the line
> > + * matches the first mark found without worrying about what could
> > + * be between them. Only one mark in the whole line is permitted.
> > + */
>
> This definition makes "- 8<" a scissors.
Yes. Instead of looking for dashes alone, I will give a try to something
like
if (!scissors_dashes_seen)
mark_start = i;
if (i + 1 < len) {
if (!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2))) {
scissors_dashes_seen |= 02;
i++;
mark_end = i;
continue;
else if (!memcmp(buf + i "--", 2) {
scissors_dashes_seen |= 04;
i++;
mark_end = i;
continue;
}
}
if (i + 2 < len)
if (!memcmp(buf + i + 1, "- -", 3) {
scissors_dashes_seen |= 04;
i += 2;
mark_end = i;
continue;
}
if (buf[i] == '-') {
mark_end = i;
scissors_dashes_seen |= 01;
continue;
}
break;
}
if (scissors_dashes_seen == 07) {
...
> it does not allow
>
> "-- 8< -- please cut here -- 8< -- --"
Actually, I believe this one should really not be a scissors line. If we
accept some random dashes around markers it will break the definition of
the mark itself.
As I said, I'd rather rules easy to define over others because if the
end-user scissors line doesn't work, he can refer to the documentation...
> nor
>
> "-- 8< -- -- please cut here -- -- 8< --"
>
> nor
>
> "-- 8< -- -- please cut here -- -- >8 --"
...and symmetrical markers make sense to the user. Will add this.
> > + if (!ignore_scissors) {
> > + if (is_scissors_line(line)) {
> > + warning("scissors line found, will skip text above");
> > ...
> > + return 0;
>
> Don't re-indent like this. Just do:
>
> if (!ignore_scissors && is_scissors_line(line)) {
> ...
> }
Does the compilers (or a standard) assure that the members are evaluated
in the left-right order?
Otherwise, we may call is_scissors_line() where not needed.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-26 3:03 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Nanako Shiraishi, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <7vvdkbl4ul.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> I think --ignore-scissors is a good thing to add, regardless of what the
> definition of scissors should be. So your patch should definitely be
> separated into two parts.
Having thought about this a bit more, I do not think --ignore-scissors
makes much sense, for several reasons.
Traditionally, a few lines of "background material" that accompanies a
patch, without being a part of discussion thread that quotes large chunks
of original message with ">" (like you see above), are given below the
three-dash line, not above "scissors". This is a good practice not only
because we did not have "scissors" support in mailinfo, but because it
forced the author to be concise and to the point, and also immediately
below the three-dash lines is where the diffstat comes, and it is a place
designed to be used for memory refreshers (e.g. "I changed this and that
from the previous round based on comments by ...").
The scissors feature shouldn't be used as the replacement for this, not
from technical but from human efficiency reasons, as you have to first
read above scissors and then jump your eyes down to diffstat, before
deciding if it is worth your time to read the commit log message and the
patch.
When there is a long discussion, a message in the thread, after following
the usual discussion style, may give a (counter)proposal as a "how about
this" patch. Such a patch is still _primarily_ for discussion, but it
sometimes turn out to be a good solution to the problem discussed in the
thread. The maintainer (or participant) then deliberately picks that
message and feeds it to "am", and it would be nice if things above
scissors are removed automatically. This is the _only_ intended use case
of the "scissors" line.
I therefore conclude that using the "remove above scissors" should be a
conscious decision, and should not be enabled by default. --obey-scissors
would be a good option for this reason.
Besides, if you _lost_ information because the scissors that is on by
default gave a false positive, you have to reset HEAD^ and re-apply. If
on the other hand we mistakenly kept cruft above a scissors, we can edit
it away using "rebase -i". So the failure recovery is much nicer if the
feature is not on by default.
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-26 2:20 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Nicolas Sebrecht, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090826110332.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> What I meant was that I would not want to spend any more of _my_ time on
>> the definition of the scissors for now. That means spending or wasting
>> time on improving the 'pu' patch myself, or looking at others patch to
>> find flaws in them.
>>
>> Of course, as the maintainer, I would need to look at proposals to improve
>> or fix bugs in the code before the series hits the master, but I would
>> give zero priority to the patches that change the definition at least for
>> now to give myself time to work on more useful things.
>
> I am hoping that you didn't mean to say that other people on the list
> mustn't look at such patches and help improve them either?
>
> Perhaps you can rephrase your message in a more positive way, just like
> you request other people to do in their proposed commit log messages?
Ok, I agree that the way I worded the message was suboptimal, so let's try
again.
I would appreciate if the members of the list come up with an alternative
definition with a good implementation that they can agree on, and present
the result as a list consensus, with a solid justification to replace the
crap I have queued in 'pu', in the form of an applicable patch. Because I
consider that the exact definition of what a scissors line looks like is
an insignificant detail, I would prefer to see that process happen without
involving me.
By the way, I already queued your documentation patch, as adding the part
that describes what a "scissors" line is good for is a very good idea.
The "community" patch to replace the definition of scissors line may have
to update the part that describes what a "scissors" line looks like in
your patch.
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Shawn O. Pearce @ 2009-08-26 2:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <20090825151424.GJ1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
> > So I think that expand-refs is a much nicer general solution than just
> > "server side is configured to hide but still allow certain refs", and
> > client updates cannot be avoided.
>
> Yes, I agree.
...
> I'm thinking about writing an RFC patch for this today for git.git.
RFC patch below. This is only the upload-pack side, and lacks
test, etc, so its posted *ONLY* for discussion. I'll try to flesh
it out further tomorrow into something that could be considered
more seriously.
--8<--
[RFC] upload-pack: expand capability advertises additional refs
The expand capability and associated command permits the client
to ask for information about refs which were not in the initial
advertisement sent when the connection was first opened.
In the below exchange the server initially only advertises its
current HEAD, refs/heads and refs/tags namespaces. However,
the client has been instructed to fetch anything which matches
refs/remotes/jc/*.
Since no matching refs appeared in the initial advertisement,
the client requests the server to expand the desired pattern,
and terminates its expand request list with a flush.
Upon receiving a flush from the client, the server displays any
local refs which match any of the expand patterns requested,
and then closes this secondary advertisement list with a flush.
If no refs matched, the server immediately returns a flush.
If multiple expand patterns match the same ref, the ref is returned
only once in the secondary advertisement, avoid confusing the client
with duplicate results.
S: 008f... HEAD\0...include-tag expand
S: 0043... refs/heads/build-next
S: 0040... refs/tags/v1.6.4.1
S: 0043... refs/tags/v1.6.4.1^{}
S: 0000
C: 001dexpand refs/remotes/jc/*
C: 0000
S: 0043... refs/remotes/jc/maint
S: 0044... refs/remotes/jc/master
S: 0000
C: 0031want ...
C: 0000
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Shawn O. Pearce <sop@google.com>
---
upload-pack.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 91 insertions(+), 6 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 4d8be83..e1ec608 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -10,6 +10,8 @@
#include "revision.h"
#include "list-objects.h"
#include "run-command.h"
+#include "remote.h"
+#include "string-list.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=nn] <dir>";
@@ -30,6 +32,18 @@ static int multi_ack, nr_our_refs;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
static int shallow_nr;
+
+struct adv_ref {
+ struct adv_ref *next;
+ char *name;
+ unsigned pattern:1;
+};
+static struct adv_ref *to_advertise;
+static struct adv_ref **advertise_tail = &to_advertise;
+
+static struct ref *local_refs;
+static struct ref **refs_tail = &local_refs;
+
static struct object_array have_obj;
static struct object_array want_obj;
static unsigned int timeout;
@@ -470,6 +484,17 @@ static int get_common_commits(void)
}
}
+static void push_advertise(const char *name)
+{
+ struct adv_ref *adv = xcalloc(1, sizeof(*adv));
+ adv->name = xstrdup(name);
+ adv->pattern = !!strchr(adv->name, '*');
+ *advertise_tail = adv;
+ advertise_tail = &adv->next;
+}
+
+static void send_refs(void);
+
static void receive_needs(void)
{
struct object_array shallows = {0, 0, NULL};
@@ -484,11 +509,22 @@ static void receive_needs(void)
unsigned char sha1_buf[20];
len = packet_read_line(0, line, sizeof(line));
reset_timeout();
- if (!len)
+ if (!len) {
+ if (to_advertise) {
+ send_refs();
+ continue;
+ }
break;
+ }
if (debug_fd)
write_in_full(debug_fd, line, len);
+ if (!prefixcmp(line, "expand ")) {
+ if (line[len - 1] == '\n')
+ line[len - 1] = 0;
+ push_advertise(line + 7);
+ continue;
+ }
if (!prefixcmp(line, "shallow ")) {
unsigned char sha1[20];
struct object *object;
@@ -603,11 +639,14 @@ static void receive_needs(void)
free(shallows.objects);
}
-static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+static int send_ref(struct string_list_item *item, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
- " include-tag";
+ " include-tag expand";
+ const struct ref *ref = item->util;
+ const char *refname = ref->name;
+ const unsigned char *sha1 = ref->new_sha1;
struct object *o = parse_object(sha1);
if (!o)
@@ -631,12 +670,58 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static void send_refs(void)
+{
+ struct ref *to_send = NULL, **tail = &to_send;
+ struct ref *ref;
+ struct adv_ref *adv, *next_adv;
+ struct string_list sorted_names;
+
+ for (adv = to_advertise; adv; adv = next_adv) {
+ struct refspec spec;
+
+ memset(&spec, 0, sizeof(spec));
+ spec.pattern = adv->pattern;
+ spec.src = adv->name;
+ spec.dst = adv->name;
+ next_adv = adv->next;
+ get_fetch_map(local_refs, &spec, &tail, 1);
+
+ free(adv->name);
+ free(adv);
+ }
+ to_advertise = NULL;
+ advertise_tail = &to_advertise;
+
+ memset(&sorted_names, 0, sizeof(sorted_names));
+ for (ref = to_send; ref; ref = ref->next)
+ string_list_insert(ref->name, &sorted_names)->util = ref;
+ for_each_string_list(send_ref, &sorted_names, NULL);
+ string_list_clear(&sorted_names, 0);
+ free_refs(to_send);
+ packet_flush(1);
+}
+
+static int scan_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct ref *r = alloc_ref(refname);
+ hashcpy(r->new_sha1, sha1);
+ *refs_tail = r;
+ refs_tail = &r->next;
+ return 0;
+}
+
static void upload_pack(void)
{
reset_timeout();
- head_ref(send_ref, NULL);
- for_each_ref(send_ref, NULL);
- packet_flush(1);
+ head_ref(scan_ref, NULL);
+ for_each_ref(scan_ref, NULL);
+
+ push_advertise("HEAD");
+ push_advertise("refs/heads/*");
+ push_advertise("refs/tags/*");
+ send_refs();
+
receive_needs();
if (want_obj.nr) {
get_common_commits();
--
1.6.4.1.331.gda1d56
--
Shawn.
^ permalink raw reply related
* Re: gitosis-lite -- now renamed to "gitolite"
From: Sitaram Chamarty @ 2009-08-26 1:54 UTC (permalink / raw)
To: Git Mailing List; +Cc: Tommi Virtanen, Jakub Narebski
On Mon, Aug 24, 2009 at 5:58 PM, Sitaram Chamarty<sitaramc@gmail.com> wrote:
> I created a new project called gitosis-lite, which combines
I have now renamed it to gitolite. Seemed a good choice, keeping only
one letter from the main inspiration project; and the hyphen was
bothering me anyway.
For those who already downloaded it, please change the name of the
repo from "gitosis-lite" to "gitolite" in your .git/config.
There is one bug that was fixed; you'll know what it is when you fetch
and see the commit log :-(
> http://github.com/sitaramc/gitosis-lite
...and for completeness, this is now http://github.com/sitaramc/gitolite
--
sitaram
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-26 1:51 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Nanako Shiraishi, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <fc2ecb5cf28cabb7d183e2835ce46aa9afb2a322.1251215299.git.nicolas.s.dev@gmx.fr>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>> I think we have bikeshedded long enough, so I won't be touching this code
>> any further only to change the definition of what a scissors mark looks
>> like,
>
> I'm not sure I understand. Are you still open to a patch touching this code
> /too/?
What I meant was that I would not want to spend any more of _my_ time on
the definition of the scissors for now. That means spending or wasting
time on improving the 'pu' patch myself, or looking at others patch to
find flaws in them.
Of course, as the maintainer, I would need to look at proposals to improve
or fix bugs in the code before the series hits the master, but I would
give zero priority to the patches that change the definition at least for
now to give myself time to work on more useful things.
I think --ignore-scissors is a good thing to add, regardless of what the
definition of scissors should be. So your patch should definitely be
separated into two parts.
> diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
> index 7e09b51..92319f6 100644
> --- a/builtin-mailinfo.c
> +++ b/builtin-mailinfo.c
> @@ -6,6 +6,7 @@
> #include "builtin.h"
> #include "utf8.h"
> #include "strbuf.h"
> +#include "git-compat-util.h"
Inclusion of builtin.h is designed to be enough. What do you need this
for?
> static FILE *cmitmsg, *patchfile, *fin, *fout;
>
> @@ -25,6 +26,7 @@ static enum {
> static struct strbuf charset = STRBUF_INIT;
> static int patch_lines;
> static struct strbuf **p_hdr_data, **s_hdr_data;
> +static int ignore_scissors = 0;
Don't initialize a static to 0.
> @@ -715,51 +717,63 @@ static inline int patchbreak(const struct strbuf *line)
> if (isspace(buf[i])) {
> + if (scissors_dashes_seen)
> + mark_end = i;
I think you do not want this part, and then you won't have to trim
trailing whitespaces from mark_end later.
> + /*
> + * The mark is 8 charaters long and contains at least one dash and
> + * either a ">8" or "<8". Check if the last mark in the line
> + * matches the first mark found without worrying about what could
> + * be between them. Only one mark in the whole line is permitted.
> + */
This definition makes "- 8<" a scissors.
Even though
"-- 8< -- please cut here -- -- 8< --"
is allowed, so is
"-- 8< -- -- please cut here -- 8< -- --"
it does not allow
"-- 8< -- please cut here -- 8< -- --"
nor
"-- 8< -- -- please cut here -- -- 8< --"
nor
"-- 8< -- -- please cut here -- -- >8 --"
Oh, did I say I won't waste my time on the definition? I should have just
discarded this hunk ;-)
> @@ -782,22 +796,25 @@ static int handle_commit_msg(struct strbuf *line)
> if (metainfo_charset)
> convert_to_utf8(line, charset.buf);
>
> - if (is_scissors_line(line)) {
> - int i;
> - rewind(cmitmsg);
> - ftruncate(fileno(cmitmsg), 0);
> - still_looking = 1;
> + if (!ignore_scissors) {
> + if (is_scissors_line(line)) {
> + warning("scissors line found, will skip text above");
> ...
> + return 0;
Don't re-indent like this. Just do:
if (!ignore_scissors && is_scissors_line(line)) {
...
}
> - # -s, -u, -k, --whitespace, -3, -C, -q and -p flags are kept
> + # Following flags are kept
We seem to have lost the description of what the "Following" are.
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Junio C Hamano @ 2009-08-25 23:50 UTC (permalink / raw)
To: Jeff King; +Cc: Tom Werner, Tom Preston-Werner, git
In-Reply-To: <20090825184525.GC23731@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
>> +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.
Very good point; a bare repository does not have to have (and typically
shouldn't have) the index, and a bare repository is what upload-pack
typically serves.
A short-and-sweet:
run_hook(NULL, "post-upload-pack",
create_full_pack ? "clone" : "fetch,
NULL);
would be sufficient. Notice that run_hook() is variadic and its argument
list needs to be terminated with NULL (iow, the original patch is buggy
and risks reading random places on the stack---I would recommend against
using it on your production site yet).
> 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 do not think that information is available. "want" will tell you what
object they want, but that does not necessarily uniquey translate to a
ref.
If we are allowed to talk about asking for the moon, and if one of the
primary reason for this new hook is statistics, it would be useful to see
the number of bytes given, where the fetch-pack came from, and if we are
using git-daemon virtual hosting which of our domain served the request.
^ permalink raw reply
* Re: git svn messages
From: Peter Harris @ 2009-08-25 22:49 UTC (permalink / raw)
To: John Tapsell; +Cc: Git List
In-Reply-To: <43d8ce650908251531n397ba6e1xe71e80d7b8a08344@mail.gmail.com>
On Tue, Aug 25, 2009 at 6:31 PM, John Tapsell wrote:
> Hi all,
>
> When doing git svn dcommit, the messages that it gives are, well,
> frightening :-)
Some moreso than others, depending on your level of familiarity with git. :-)
> 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?..
Because you aren't working from a branch-point older than your current
refs/remotes/git-svn. I suppose one could misinterpret that as a
bidirectional "no changes". Still, the message doesn't contain a scary
prefix like "Error:" or even "Warning:". It's just informational.
>> Resetting to the latest refs/remotes/git-svn
>
> That doesn't sound good. Why did it have reset?
Because the newly created svn commits are a different DAG from your
former DAG (which contained git commits that weren't in svn yet), even
though the tree contents are the same. The way git-svn tells the rest
of git about this change is by running the "git reset" command.
You can run "gitk" before you run "git svn dcommit", then hit refresh
(F5, I believe) after "git svn dcommit" is done to get a more visual
idea of what is going on.
Peter Harris
^ permalink raw reply
* 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
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