* 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
* [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Kirill A. Korinskiy @ 2009-08-25 17:20 UTC (permalink / raw)
To: gitster; +Cc: git, Kirill A. Korinskiy
In-Reply-To: <7vfxbgvdx8.fsf@alter.siamese.dyndns.org>
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-brnach.sh | 31 +++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
create mode 100755 t/t5706-clone-brnach.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-brnach.sh b/t/t5706-clone-brnach.sh
new file mode 100755
index 0000000..1f2704b
--- /dev/null
+++ b/t/t5706-clone-brnach.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 && git rev-parse --verify refs/remotes/origin/two)
+
+'
+
+test_done
--
1.6.2
^ permalink raw reply related
* Re: [PATCH] send-email: confirm on empty mail subjects
From: Jan Engelhardt @ 2009-08-25 16:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vn1gjlp.fsf@alter.siamese.dyndns.org>
On Montag 2009-08-24 20:19, Junio C Hamano wrote:
>>>
>>>> When the user forgot to enter a subject in a compose session,
>>>> send-email will now inquire whether this is really intended, similar
>>>> to what the Alpine MUA does when a subject is absent.
>>>
>>>This seems to break t9001...
>>
>> Did I miss something in building?
>>
>> 19:26 sovereign:../git/git-1.6.4.1 > quilt pu
>> Applying patch patches/send-email-empty-subject.diff
>> patching file git-send-email.perl
>
>Is this using 'pu' with your patch?
Ah no, `quilt pu` is an autoalias for `quilt push`.
>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.)
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Nicolas Sebrecht @ 2009-08-25 16:18 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Sebrecht, Nanako Shiraishi, Thell Fowler, git,
Johannes.Schindelin
In-Reply-To: <7v3a7g501e.fsf@alter.siamese.dyndns.org>
The 24/08/09, Junio C Hamano wrote:
> perhaps
> we should tighten the rules a bit,
<...>
> 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/?
Anyway, here's what I wrote based on your last round in pu. I've change the
rules to something because I think we'd rather simple ― and "easy" to
explain to the end-user ― rules over "obfuscated" ones.
-- >8 -- squashable to 8683eeb (ogirin/pu) -- >8 --
Subject: Teach mailinfo to ignore everything before a scissors line
This teaches mailinfo the scissors mark (e.g. "-- >8 --");
the command ignores everything before it in the message body.
For lefties among us, we also support -- 8< -- ;-)
We can skip this check using the "--ignore-scissors" option on both
the git-mailinfo and the git-am command line. This is necessary
because the stripped message may be either
interesting from the eyes of the maintainer, regardless what the
author think;
or
the scissors line check is a false positive.
Basically, the rules are:
(1) a scissors mark:
- must be 8 characters long;
- must have a dash;
- must have either ">8" or "<8";
- may contain spaces.
(2) a scissors line:
- must have only one scissors mark;
or
- must have any comment between two identical scissors marks;
- always ignore spaces outside the scissors marks.
Signed-off-by: Nicolas Sebrecht <nicolas.s.dev@gmx.fr>
---
Documentation/git-am.txt | 14 +++++-
Documentation/git-mailinfo.txt | 7 ++-
builtin-mailinfo.c | 103 +++++++++++++++++++++++----------------
git-am.sh | 14 ++++-
4 files changed, 90 insertions(+), 48 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index fcacc94..2773a3e 100644
--- a/Documentation/git-am.txt
+++ b/Documentation/git-am.txt
@@ -13,7 +13,7 @@ SYNOPSIS
[--3way] [--interactive] [--committer-date-is-author-date]
[--ignore-date] [--ignore-space-change | --ignore-whitespace]
[--whitespace=<option>] [-C<n>] [-p<n>] [--directory=<dir>]
- [--reject] [-q | --quiet]
+ [--reject] [-q | --quiet] [--ignore-scissors]
[<mbox> | <Maildir>...]
'git am' (--skip | --resolved | --abort)
@@ -118,6 +118,14 @@ default. You can use `--no-utf8` to override this.
--abort::
Restore the original branch and abort the patching operation.
+--ignore-scissors::
+ Do not check for scissors line in the commit message. A scissors
+ line consists of a scissors mark which must be at least 8
+ characters long and which must contain dashes '-' and a scissors
+ (either ">8" or "<8"). Spaces are also permited inside the mark.
+ To add a comment on this line, it must be embedded between two
+ identical marks (e.g. "-- >8 -- squashme to <commit> -- >8 --").
+
DISCUSSION
----------
@@ -131,7 +139,9 @@ commit is about in one line of text.
"From: " and "Subject: " lines starting the body (the rest of the
message after the blank line terminating the RFC2822 headers)
override the respective commit author name and title values taken
-from the headers.
+from the headers. These lines immediatly following a scissors line
+override the respective fields regardless what could stand at the
+beginning of the body.
The commit message is formed by the title taken from the
"Subject: ", a blank line and the body of the message up to
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 8d95aaa..e16a577 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -8,7 +8,8 @@ git-mailinfo - Extracts patch and authorship from a single e-mail message
SYNOPSIS
--------
-'git mailinfo' [-k] [-u | --encoding=<encoding> | -n] <msg> <patch>
+'git mailinfo' [-k] [-u | --encoding=<encoding> | -n] [--ignore-scissors]
+<msg> <patch>
DESCRIPTION
@@ -49,6 +50,10 @@ conversion, even with this flag.
-n::
Disable all charset re-coding of the metadata.
+--ignore-scissors::
+ Do not check for a scissors line (see linkgit:git-am[1]
+ for more information on scissors lines).
+
<msg>::
The commit log message extracted from e-mail, usually
except the title line which comes from e-mail Subject.
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"
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;
#define MAX_HDR_PARSED 10
#define MAX_BOUNDARIES 5
@@ -715,51 +717,63 @@ static inline int patchbreak(const struct strbuf *line)
static int is_scissors_line(const struct strbuf *line)
{
size_t i, len = line->len;
- int scissors = 0, gap = 0;
- int first_nonblank = -1;
- int last_nonblank = 0, visible, perforation, in_perforation = 0;
const char *buf = line->buf;
+ size_t mark_start = 0, mark_end = 0, mark_len;
+ int scissors_dashes_seen = 0;
for (i = 0; i < len; i++) {
if (isspace(buf[i])) {
- if (in_perforation) {
- perforation++;
- gap++;
- }
+ if (scissors_dashes_seen)
+ mark_end = i;
continue;
}
- last_nonblank = i;
- if (first_nonblank < 0)
- first_nonblank = i;
+ if (!scissors_dashes_seen)
+ mark_start = i;
if (buf[i] == '-') {
- in_perforation = 1;
- perforation++;
+ mark_end = i;
+ scissors_dashes_seen |= 01;
continue;
}
if (i + 1 < len &&
(!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2))) {
- in_perforation = 1;
- perforation += 2;
- scissors += 2;
i++;
+ mark_end = i;
+ scissors_dashes_seen |= 02;
continue;
}
- in_perforation = 0;
+ break;
}
- /*
- * The mark must be at least 8 bytes long (e.g. "-- >8 --").
- * Even though there can be arbitrary cruft on the same line
- * (e.g. "cut here"), in order to avoid misidentification, the
- * perforation must occupy more than a third of the visible
- * width of the line, and dashes and scissors must occupy more
- * than half of the perforation.
- */
+ if (scissors_dashes_seen == 03) {
+ /* strip trailing spaces at the end of the mark */
+ for (i = mark_end; i >= mark_start && i <= mark_end; i--) {
+ if (isspace(buf[i]))
+ mark_end--;
+ else
+ break;
+ }
- visible = last_nonblank - first_nonblank + 1;
- return (scissors && 8 <= visible &&
- visible < perforation * 3 &&
- gap * 2 < perforation);
+ mark_len = mark_end - mark_start + 1;
+ if (mark_len >= 8) {
+ /* ignore trailing spaces at the end of the line */
+ len--;
+ for (i = len - 1; i >= 0; i--) {
+ if (isspace(buf[i]))
+ len--;
+ else
+ break;
+ }
+ /*
+ * 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.
+ */
+ return (!memcmp(buf + mark_start, buf + len - mark_len, mark_len));
+ }
+ }
+
+ return 0;
}
static int handle_commit_msg(struct strbuf *line)
@@ -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");
+ int i;
+ rewind(cmitmsg);
+ ftruncate(fileno(cmitmsg), 0);
+ still_looking = 1;
- /*
- * We may have already read "secondary headers"; purge
- * them to give ourselves a clean restart.
- */
- for (i = 0; header[i]; i++) {
- if (s_hdr_data[i])
- strbuf_release(s_hdr_data[i]);
- s_hdr_data[i] = NULL;
+ /*
+ * We may have already read "secondary headers"; purge
+ * them to give ourselves a clean restart.
+ */
+ for (i = 0; header[i]; i++) {
+ if (s_hdr_data[i])
+ strbuf_release(s_hdr_data[i]);
+ s_hdr_data[i] = NULL;
+ }
+ return 0;
}
- return 0;
}
if (patchbreak(line)) {
@@ -1011,6 +1028,8 @@ int cmd_mailinfo(int argc, const char **argv, const char *prefix)
while (1 < argc && argv[1][0] == '-') {
if (!strcmp(argv[1], "-k"))
keep_subject = 1;
+ else if (!strcmp(argv[1], "--ignore-scissors"))
+ ignore_scissors = 1;
else if (!strcmp(argv[1], "-u"))
metainfo_charset = def_charset;
else if (!strcmp(argv[1], "-n"))
diff --git a/git-am.sh b/git-am.sh
index 3c03f3e..17c883f 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -15,6 +15,7 @@ q,quiet be quiet
s,signoff add a Signed-off-by line to the commit message
u,utf8 recode into utf8 (default)
k,keep pass -k flag to git-mailinfo
+ignore-scissors pass --ignore-scissors flag to git-mailinfo
whitespace= pass it through git-apply
ignore-space-change pass it through git-apply
ignore-whitespace pass it through git-apply
@@ -288,7 +289,7 @@ split_patches () {
prec=4
dotest="$GIT_DIR/rebase-apply"
sign= utf8=t keep= skip= interactive= resolved= rebasing= abort=
-resolvemsg= resume=
+resolvemsg= resume= ignore_scissors=
git_apply_opt=
committer_date_is_author_date=
ignore_date=
@@ -310,6 +311,8 @@ do
utf8= ;;
-k|--keep)
keep=t ;;
+ --ignore-scissors)
+ ignore_scissors=t ;;
-r|--resolved)
resolved=t ;;
--skip)
@@ -435,7 +438,7 @@ else
split_patches "$@"
- # -s, -u, -k, --whitespace, -3, -C, -q and -p flags are kept
+ # Following flags are kept
# for the resuming session after a patch failure.
# -i can and must be given when resuming.
echo " $git_apply_opt" >"$dotest/apply-opt"
@@ -443,6 +446,7 @@ else
echo "$sign" >"$dotest/sign"
echo "$utf8" >"$dotest/utf8"
echo "$keep" >"$dotest/keep"
+ echo "$ignore_scissors" >"$dotest/ignore-scissors"
echo "$GIT_QUIET" >"$dotest/quiet"
echo 1 >"$dotest/next"
if test -n "$rebasing"
@@ -484,6 +488,10 @@ if test "$(cat "$dotest/keep")" = t
then
keep=-k
fi
+if test "$(cat "$dotest/ignore-scissors")" = t
+then
+ ignore_scissors='--ignore-scissors'
+fi
if test "$(cat "$dotest/quiet")" = t
then
GIT_QUIET=t
@@ -538,7 +546,7 @@ do
# by the user, or the user can tell us to do so by --resolved flag.
case "$resume" in
'')
- git mailinfo $keep $utf8 "$dotest/msg" "$dotest/patch" \
+ git mailinfo $keep $ignore_scissors $utf8 "$dotest/msg" "$dotest/patch" \
<"$dotest/$msgnum" >"$dotest/info" ||
stop_here $this
--
1.6.4.1.334.gf42e22
^ permalink raw reply related
* Re: [PATCH] fix simple deepening of a repo
From: Shawn O. Pearce @ 2009-08-25 15:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <7vy6p8pfm1.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > The client knows the *name* of the ref, but not the SHA-1 the ref is
> > currently valued at. Thus when the client knows it wants a certain
> > ref by name, it needs to send a "want " line to the server that would
> > give it whatever that ref currently points at. Unfortunately since we
> > have not obtained that value yet, we are stuck.
>
> That could be something you can fix in the out-of-band procedure Gerrit
> uses (you let the client learn both name and value offline, and then the
> client uses that value on "want" line).
Well, we're trying to reduce out-of-band things with Gerrit.
Its bad enough that Gerrit doesn't use git am and git send-email
to slug around changes for discussion. As it is we're an island
among the git world, *despite* the fact that Gerrit speaks the git
protocol natively and you can push directly to it, avoiding the
send-email SMTP nonsense many folks run into.
> However, even if we limit the discussion to Gerrit, you would need an
> updated client that can be called with the out-of-band information
> (i.e. "we know that changes/88/4488/2 points at X, so use X when
> requesting") when talking with such an updated server.
Yes, exactly. Existing clients wouldn't send an arbitrary want
request, even if the server had a whitelist of objects it would
allow to be requested.
One reason why Gerrit publishes pending changes with ref names is to
make it easier for any user to obtain the proposed change locally.
Its hard to beat `git fetch URL blah`, that's even easier than
"save to mbox, git am mbox".
> 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. Given 20/20 hindsight, its the way the protocol
should have been implemented:
C: 0014expand refs/heads/*
C: 0013expand refs/tags/*
C: 0000
S: ...refs/heads/master
S: ...refs/heads/next
S: ...refs/tags/v1.0
S: 0000
This would have permitted clients doing `git pull URL for-linus` to say:
C: 0011expand for-linus
C: 0000
S: ...refs/heads/for-linus
S: ...refs/remotes/k26/for-linus
S: 0000
and thus significantly narrow the scope of what they are shown when
they connect for a given ref.
> > The problem with this is servers which are sending this expand-refs
> > tag have hidden certain namespaces from older clients. Those names
> > can't be seen by older git clients, unless the user does an upgrade.
>
> I do not think "generally hidden, but if you need to know you are allowed
> to peek" is much of a problem. You do not do that for regular refs, only
> for "on-demand-as-needed" type things. If we are going to make extensive
> use of notes on commits to give richer annotations, I suspect notes
> hierarchy could be hidden by default in a similar way.
After sleeping on it, I'm OK with hiding some refs from older clients.
Sometimes things evolve, and you should just update your software
to keep up with them. If you really want the "hidden refs" that
Gerrit advertises, you should install a newer client.
We could consider supporting a legacy option through upload-pack,
such as:
git fetch --upload-pack='git-upload-pack --expand refs/changes/' URL
which tells the remote side to additionally expand those refs during
the initial advertisement. Then users have an escape hatch if:
* They know the remote is new enough to hide refs;
* They suspect the remote is hiding refs;
* They received an out-of-band notification telling this;
* They have an older client which doesn't support expanding refs;
* They cannot upgrade said client yet;
I'm thinking about writing an RFC patch for this today for git.git.
I think the expand refs feature neatly solves a number of problems
for me in Gerrit. But I'm really hoping its not the only set of
repositories that would benefit from such a feature, because if so,
its not worth the headache of the protocol change.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Frank Li @ 2009-08-25 14:32 UTC (permalink / raw)
To: Thiago Farina
Cc: Marius Storm-Olsen, Reece Dunn, Johannes.Schindelin, msysgit, git
In-Reply-To: <a4c8a6d00908231229v56eceeddue1b927a4e4e49ee3@mail.gmail.com>
> 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.
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Jakub Narebski @ 2009-08-25 14:18 UTC (permalink / raw)
To: Frank Münnich; +Cc: git
In-Reply-To: <000001ca257d$b60326c0$22097440$@com>
Frank Münnich <git@frank-muennich.com> writes:
> 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 ;)
I personally use GNU Emacs when working with git-controlled projects.
See also question 20. What editor, IDE or RAD you use working with Git?
in Git User's Survey 2009 (http://git.or.cz/gitwiki/GitSurvey2008)
Among text editors (although with plugins, addons, modes one can
make those into something resembling IDE) Vim with 51% wins over
TextMate with 33%, which in turn wins over Emacs with 21%. Next in
turn is Eclipse with 13% (assuming that editors in 'other' won't
change it; this would a bit unlikely, though); it is most popular
among Java IDE listed (from those NetBeans is more popular than
IntelliJ IDEA). XCode, MS Visual Studio and KDevelop IDE have
similar popularity, surpassing Anjuta.
--
Jakub Narebski
Git User's Survey 2009: http://tinyurl.com/GitSurvey2009
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Thell Fowler @ 2009-08-25 14:06 UTC (permalink / raw)
To: Frank Münnich; +Cc: git
In-Reply-To: <000001ca257d$b60326c0$22097440$@com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 438 bytes --]
Frank Münnich (git@frank-muennich.com) wrote on Aug 25, 2009:
> One thing I would like to ask you: what, if any, IDEs are you working with?
I'm using Eclipse CDT on Ubuntu. The only thing that has been a pain is
the debugging application output console is not a true xterm or console
and doesn't show diff output (which is what I've been focused on)
properly, so for that Data Display Debugger has been useful.
--
Thell
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Boaz Harrosh @ 2009-08-25 12:56 UTC (permalink / raw)
To: Frank Münnich; +Cc: git
In-Reply-To: <000001ca257d$b60326c0$22097440$@com>
On 08/25/2009 03:15 PM, Frank Münnich 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
>
kdevelop rocks. Debugging perfect. Just configure a C external-make project
and off you go.
Cheers
Boaz
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Andreas Ericsson @ 2009-08-25 12:49 UTC (permalink / raw)
To: Frank Münnich; +Cc: git
In-Reply-To: <000001ca257d$b60326c0$22097440$@com>
Frank Münnich 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?
No IDE. Just jed (a lightweight emacs-ish editor).
I've tried to learn Geany, but my fingers are too trained to the emacs
shortcuts and I'm far too used to the behaviour of my current editor to
be able to switch without a month or so of idling, and that's not really
an option at $dayjob.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: John Tapsell @ 2009-08-25 12:47 UTC (permalink / raw)
To: Frank Münnich; +Cc: git
In-Reply-To: <000001ca257d$b60326c0$22097440$@com>
2009/8/25 Frank Münnich <git@frank-muennich.com>:
> One thing I would like to ask you: what, if any, IDEs are you working with?
I think everyone just uses vim/emacs :-)
John
^ permalink raw reply
* What IDEs are you using to develop git?
From: Frank Münnich @ 2009-08-25 12:15 UTC (permalink / raw)
To: git
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
^ permalink raw reply
* [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Kirill A. Korinskiy @ 2009-08-25 12:30 UTC (permalink / raw)
To: gitster; +Cc: git, Kirill A. Korinskiy
In-Reply-To: <20090825015726.GB7655@coredump.intra.peff.net>
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.
---
Documentation/git-clone.txt | 4 ++++
builtin-clone.c | 23 ++++++++++++++++++++---
t/t5706-clone-brnach.sh | 31 +++++++++++++++++++++++++++++++
3 files changed, 55 insertions(+), 3 deletions(-)
create mode 100755 t/t5706-clone-brnach.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-brnach.sh b/t/t5706-clone-brnach.sh
new file mode 100755
index 0000000..1f2704b
--- /dev/null
+++ b/t/t5706-clone-brnach.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 && git rev-parse --verify refs/remotes/origin/two)
+
+'
+
+test_done
--
1.6.2
^ permalink raw reply related
* Re: gitosis-lite
From: Jakub Narebski @ 2009-08-25 12:05 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <2e24e5b90908242253v411ad5f3t8a2802079914d0bf@mail.gmail.com>
Sitaram Chamarty wrote:
> On Tue, Aug 25, 2009 at 12:14 AM, Jakub Narebski<jnareb@gmail.com> wrote:
>
> > A few comments about the code, taking gl-auth-command as example.
>
> > Wouldn't it be better to use "use warnings" instead of 'perl -w'?
>
> I'm not sure what is the minimum perl required for git
> itself. Has it needed perl > 5.6.0 for more than a year at
> least? The only real difference between these two is scope,
> which is a non-issue here, so I played safe.
I think that git requires Perl at least version 5.6
> > It would be, I think, better if you have used POD for such
> > documentation. One would be able to generate manpage using pod2man,
> > and it is no less readable in source code. See e.g. perl/Git.pm or
> > contrib/hooks/update-paranoid.
>
> Hmm... I've been spoiled by Markdown's sane bullet list
> handling. Visually, POD forces everything other than code
> to be flush left -- any sort of list is definitely less
> readable in source code as a result. IMHO of course.
How it is relevant to the issue at hand? I was talking about replacing
documentation comments in the header with POD markup.
Also you usually document top-level structures with POD.
> > > # first, fix the biggest gripe I have with gitosis, a 1-line change
> > > my $user=$ENV{GL_USER}=shift; # there; now that's available everywhere!
> >
> > Eh? This is standalone script, isn't it? Shouldn't it be
> >
> > my $user = $ENV{GL_USER} = $ARGV[0]; # there; now that's available everywhere!
>
> Hmm... I didn't know there was a difference, other than
> depleting @ARGV, if you're outside a subroutine. I'll take
> a relook at it.
It is, I think, the matter of taste. IMHO using @ARGV to get _program_
parameters is better than use 'shift' which is used to get subroutine
arguments.
BTW. have you tried using Perl::Critic or http://perlcritic.com on your
code (but remember that those best practice recommendations do not need
to be followed blindly)?
> > > open(LOG, ">>", "$GL_ADMINDIR/log");
> > > print LOG "\n", scalar(localtime), " $ENV{SSH_ORIGINAL_COMMAND} $user\n";
> > > close(LOG);
> >
> > It is better practice to use lexical variables instead of barewords
> > for filehandles:
>
> Good catch; thanks! I guess I'm showing my age :) Fixed
> all of them!
>
> > Don't forget to check for error.
>
> Hmm.. well I'm still debating if a log file write error
> should block git access / push, but there were two more
> important closes (again in gl-compile-conf) that were
> unguarded. Fixed, thanks.
I was thinking about not writing to log file if you can't open it.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Johannes Schindelin @ 2009-08-25 11:34 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090825030316.GA8098@coredump.intra.peff.net>
Hi,
On Mon, 24 Aug 2009, Jeff King wrote:
> Subject: [PATCH] checkout: do not imply "-f" on unborn branches
>
> [...]
Thanks!
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-tag(1): Refer to git-check-ref-format(1) for <name>
From: Nanako Shiraishi @ 2009-08-25 8:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jari Aalto
In-Reply-To: <20090822094518.6117@nanako3.lavabit.com>
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?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: rebase hint unmerged file removed
From: Miklos Vajna @ 2009-08-25 8:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: bill lam, git
In-Reply-To: <4A939455.5030908@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]
On Tue, Aug 25, 2009 at 09:35:49AM +0200, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Ok, I bisected it to 6eb1b437 (cherry-pick/revert: make direct internal
> call to merge_tree(), 2008-09-02), which is part of a series around
> merge-recursive: 1ad6d46..ed520a8
>
> The commit message says: "One regression is that the status message is
> lost as there is no way to flush them from outside the refactored library
> code yet." But is it intentional that these messages were never recovered?
>
> BTW, I miss the messages a lot, too, but I'm unfamiliar with the code in
> question to try to do something about it.
I do not remember too much about this. The point of the commit was to
avoid fork()ing a new merge-recursive process, that's for sure. I tried
to search back the archive to see what was the interdiff between my
patch and Junio's fixup, but I haven't found my patch.
I think it's possible that I was not aware of this limitation at all and
just Junio added it as a note to the commit message, but I'm not 100%
sure.
I also think that it's possible to modify the library code to be able to
flush the status message outside the library, but I can't really send a
patch that implements this right now, due to lack of time.
Sorry,
Miklos
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: rebase hint unmerged file removed
From: Johannes Sixt @ 2009-08-25 7:35 UTC (permalink / raw)
To: Miklos Vajna; +Cc: bill lam, git
In-Reply-To: <4A92A6E6.5060702@viscovery.net>
Johannes Sixt schrieb:
> Rebase -i emitted used to write merge-recursive's conflict hints that said
> "modify/delete", "modify/rename", "content", etc. I think that's what you
> were looking for. But these hints have vanished since quite some time now.
> I haven't taken the time, yet, to track down when this happened and why.
Ok, I bisected it to 6eb1b437 (cherry-pick/revert: make direct internal
call to merge_tree(), 2008-09-02), which is part of a series around
merge-recursive: 1ad6d46..ed520a8
The commit message says: "One regression is that the status message is
lost as there is no way to flush them from outside the refactored library
code yet." But is it intentional that these messages were never recovered?
BTW, I miss the messages a lot, too, but I'm unfamiliar with the code in
question to try to do something about it.
-- Hannes
^ permalink raw reply
* Re: Git workflow: Managing topic branches.
From: Johannes Sixt @ 2009-08-25 7:07 UTC (permalink / raw)
To: Thomas Adam; +Cc: git list
In-Reply-To: <18071eea0908240744g359f8b1ey622259e89ac7592a@mail.gmail.com>
Thomas Adam schrieb:
> We have a work-flow such as this:
>
>
> o---o---o---o--o--o (stable)
> /
> o---o---o---o---o---o---o (master)
> \
> o---o--o---o---o---o (featureA)
>
>
> Master is where all our stable code lives after a release -- and also where
> bug-fixes for released code is put. When we're working on a new feature,
> almost all developers here will push (in this case) to "featureA" ---
> eventually this branch will get merged into master, tagged and the code
> released. Then a new branch, "featureB" is created off it, and process
> continues. (Yes, we're using Git in a very CVS-like way, alas.)
>
> Periodically though we need to release updates for our product. This the
> area which is where my question lies about whether the workflow is good or
> not. Here's how we do that:
>
> We have a branch called "stable" which contains all of our released code
> plus any updates release. When we wish to create a new update, we create a
> new branch off the tip of stable:
>
>
> o---o---o---o (updateN)
> /
> o---o---o---o--o--o (stable)
> /
> o---o---o---o---o---o---o (master)
> \
> o---o--o---o---o---o (featureA)
>
>
> Because bug-fixes happen on Master, we now want those fixes to appear on the
> updateN branch so we can create a tarball from them (to release to our
> customers). We're using "git cherry" to get a list of SHA1s that are
> relevant between updateN and master, as in:
>
> git cherry updateN master
>
> ... and then manually deciding (based on it's "+"/"-" output whether that
> SHA1 needs to be used and then:
>
> git cherry-pick SHA1
>
> ... onto updateN as appropriate.
Your workflow looks quite reasonable except for this last part. You should
make your history look like this:
o--o--o--o--o stable
/ \ \
--o--B--o--o--o---o--o--o--o master
\
o--o--o--o--o--o featureA
Instead of cherry-picking commits onto updateN (or stable), your
developers should think which branches need the change that they are about
to commit. If it is a serious bug-fix, then it should be enter the picture
on stable, not on master or feature branches. The important part is that
branch stable is merged into branch master (at least after each release,
but perhaps even more often).
Now assume that your developer discovers a bug while she was developing on
featureA that must go into stable. Previously you would have done it this
way (I presume):
--o--B--o--o--o---o--o--o--o--o master
| \ / / /
| o--o--o--o--o-----F' stable
\
o--o--o--o--o--o--F featureA
That is, the fix F was committed on the feature branch and later was
cherry-picked onto stable as F' and then merged into master. But she
should have done this instead:
--o--B--o--o--o---o--o--o--o--o master
| \ / / /
| o--o--o--o--o-----o stable
|\ /
| F------------------< fixF
\ \
o--o--o--o--o--o-----o featureA
That is, fix F should go on its own bugfix-branch and that branch is
merged into stable as well as into featureA (but only if the fix is really
needed there); stable is in turn merged into master again. The new branch
grows from a commit that is in common to all the branches that need the
fix. Since the fix is needed on featureA as well as on stable, the lastest
possible branch point is B (where feature A was branch off of master/stable).
Side note: An even better branch point would be the commit that introduced
the bug, which must have been B or a commit before it; otherwise the bug
would not have shown up during the development of featureA. This way you
could make the decision anytime later whether you want to merge the fix
into older releases as well.
-- Hannes
^ permalink raw reply
* Re: [PATCH/RFC] make the new block-sha1 the default
From: Junio C Hamano @ 2009-08-25 6:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Jeff King, git
In-Reply-To: <20090825041859.GA10033@coredump.intra.peff.net>
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_?
I would certainly understand it if you made BLK_SHA1 the _default_, though.
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Junio C Hamano @ 2009-08-25 6:33 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <20090825061248.GG1033@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> The client knows the *name* of the ref, but not the SHA-1 the ref is
> currently valued at. Thus when the client knows it wants a certain
> ref by name, it needs to send a "want " line to the server that would
> give it whatever that ref currently points at. Unfortunately since we
> have not obtained that value yet, we are stuck.
That could be something you can fix in the out-of-band procedure Gerrit
uses (you let the client learn both name and value offline, and then the
client uses that value on "want" line).
However, even if we limit the discussion to Gerrit, you would need an
updated client that can be called with the out-of-band information
(i.e. "we know that changes/88/4488/2 points at X, so use X when
requesting") when talking with such an updated server.
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.
And again,
> The problem with this is servers which are sending this expand-refs
> tag have hidden certain namespaces from older clients. Those names
> can't be seen by older git clients, unless the user does an upgrade.
I do not think "generally hidden, but if you need to know you are allowed
to peek" is much of a problem. You do not do that for regular refs, only
for "on-demand-as-needed" type things. If we are going to make extensive
use of notes on commits to give richer annotations, I suspect notes
hierarchy could be hidden by default in a similar way.
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Shawn O. Pearce @ 2009-08-25 6:12 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Julian Phillips, Daniel Barkalow,
Johannes Schindelin, git
In-Reply-To: <7vab1osc2m.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
> > We aren't quite at the 50k ref stage yet, but we're starting to
> > consider that some of our repositories have a ton of refs, and
> > that the initial advertisement for either fetch or push is horrid.
> >
> > Since the refs are immutable I could actually teach the JGit
> > daemon to hide them from JGit's receive-pack, thus cutting down the
> > advertisement on push, but the refs exist so you can literally say:
>
> What do you mean "refs are immutable"?
>
> Do you mean "In the particular application, Gerrit, the server knows that
> certain refs will never move nor get deleted, once they are created"? If
> so, then I would understand, but otherwise what you are describing is not
> git anymore ;-)
The former. :-)
I mean that this particular server implementation will deny any
update made to refs/changes/, as if one had the following as the
update hook on that repository:
#!/bin/sh
case "$1" in
refs/changes/*) exit 1;;
*) exit 0;
esac
This of course is completely legal, and since the server knows the
ref cannot be moved, there is no need to advertise it to the client.
But this is a very specialized thing, its rare that the thing that
formats the advertisement knows what the update hook will permit
to be modified.
> > git fetch --uploadpack='git upload-pack --ref refs/changes/88/4488/2' URL refs/changes/88/4488/2
> >
> > Personally I'd prefer extending the protocol, because making the
> > end user supply information twice is stupid.
>
> In the upload-pack protocol, the server talks first, so it is rather hard
> to shoehorn a request from a client to ask "I know about refs/changes/*
> hiearchy, so don't talk about them".
Actually, that assumption is still a problem.
The client knows the *name* of the ref, but not the SHA-1 the ref is
currently valued at. Thus when the client knows it wants a certain
ref by name, it needs to send a "want " line to the server that would
give it whatever that ref currently points at. Unfortunately since we
have not obtained that value yet, we are stuck.
However, we do have one name we want to know about, but the server may
have 50k other names in the same namespace we do not know about.
I was thinking instead that we have a new protocol extension:
S: ... HEAD\0side-band ... expand-refs
S: ... refs/heads/master
S: 0000
C: ... expand refs/changes/88/4488/2
C: 0000
S: ... refs/changes/88/4488/2
S: 0000
C: ... want XXXXXX\0side-band-64k ...
> Of course, the client side cannot grab everything with refs/*:refs/remotes/*
> wildcard refspecs from such a server, but I think that can be considered a
> feature.
If expand accepted globs like fetch does, then fetch can ask for
expand of refs/changes/* if it does not see any refs/changes/*
on advertisement. Or just expand a particular ref, or handful of
refs, that the user has asked for on the fetch line.
The problem with this is servers which are sending this expand-refs
tag have hidden certain namespaces from older clients. Those names
can't be seen by older git clients, unless the user does an upgrade.
This might be OK for Gerrit Code Review's refs/changes/ namespace,
but it may not be good for others.
--
Shawn.
^ permalink raw reply
* Re: [PATCH-v2/RFC 3/6] xutils: fix ignore-all-space on incomplete line
From: Thell Fowler @ 2009-08-25 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <alpine.DEB.2.00.0908240910120.29625@GWPortableVCS>
Thell Fowler (git@tbfowler.name) wrote on Aug 24, 2009:
> Junio C Hamano (gitster@pobox.com) wrote on Aug 24, 2009:
>
> > Thell Fowler <git@tbfowler.name> writes:
> >
> > > It passed every test I threw at it, although it seemed to be a tad bit
> > > slower than the previous revision on my sample data so I ran the following
> > > command several times for both the previous and current version:
> > >
> >
> > Do you mean by "previous version" the one that was broken, or the one I
> > sent as a "how about" patch?
> >
>
> A quick test shows the version merged to pu is the one that had the
> fastest times. I'll be away from a connection most of today, but will
> test the different versions against the tests and some sample data and
> post back.
>
More extensive testing also shows the version currently in pu is the
fastest on my sample data when applied to master. I'm not sure why pu
shows slower times than those same commits applied to master, but they
are close enough together that I'm guessing no-one would really be
concerned.
I was sitting in a waiting room and decided to have a little fun figuring
out how to average the sys times...
for arg in "" -w -b --ignore-space-at-eol;do sum=0 && for i in {1..50}; \
do n="$(/usr/bin/time -f "%S" -o /dev/stdout sh -c 'git diff $arg dirty_first>/dev/null;')"; \
sum=$sum+$n; done; echo "scale=2; ($sum)/$i"|echo "$(bc) avg for diff $arg"; done;
pu
.28 avg for diff
.29 avg for diff -w
.33 avg for diff -b
.29 avg for diff --ignore-space-at-eol
pu commits applied to master <=== FASTEST
9c0d402 xutils: Fix xdl_recmatch() on incomplete lines
21245fd xutils: Fix hashing an incomplete line with whitespaces at the end
.26 avg for diff
.25 avg for diff -w
.29 avg for diff -b
.31 avg for diff --ignore-space-at-eol
'how about' patch applied to master
.26 avg for diff
.32 avg for diff -w
.29 avg for diff -b
.32 avg for diff --ignore-space-at-eol
current master (in order to see the difference in the basic git diff
-ignoring the fact that incomplete lines where broke since it only affects
2 files in the test data)
.30 avg for diff
.30 avg for diff -w
.29 avg for diff -b
.29 avg for diff --ignore-space-at-eol
-- Thell
^ permalink raw reply
* Re: gitosis-lite
From: Sitaram Chamarty @ 2009-08-25 5:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <m363cdm4pm.fsf@localhost.localdomain>
[took Tommi out of cc; he must be getting enough mail as is...]
On Tue, Aug 25, 2009 at 12:14 AM, Jakub Narebski<jnareb@gmail.com> wrote:
> A few comments about the code, taking gl-auth-command as example.
> Wouldn't it be better to use "use warnings" instead of 'perl -w'?
I'm not sure what is the minimum perl required for git
itself. Has it needed perl > 5.6.0 for more than a year at
least? The only real difference between these two is scope,
which is a non-issue here, so I played safe.
> It would be, I think, better if you have used POD for such
> documentation. One would be able to generate manpage using pod2man,
> and it is no less readable in source code. See e.g. perl/Git.pm or
> contrib/hooks/update-paranoid.
Hmm... I've been spoiled by Markdown's sane bullet list
handling. Visually, POD forces everything other than code
to be flush left -- any sort of list is definitely less
readable in source code as a result. IMHO of course.
>> our $GL_ADMINDIR;
>> our $GL_CONF;
>> our $GL_KEYDIR;
>> our $GL_CONF_COMPILED;
>> our $REPO_BASE;
>> our %repos;
>
> Why is the reason behind using 'our' instead of 'my' here?
They are assigned values in some file being "do"-ed, so they
can't be lexical scoped. However, I found a few others that
were holdovers from an earlier version. Fixed; thanks for
catching that.
>> # first, fix the biggest gripe I have with gitosis, a 1-line change
>> my $user=$ENV{GL_USER}=shift; # there; now that's available everywhere!
>
> Eh? This is standalone script, isn't it? Shouldn't it be
>
> my $user = $ENV{GL_USER} = $ARGV[0]; # there; now that's available everywhere!
Hmm... I didn't know there was a difference, other than
depleting @ARGV, if you're outside a subroutine. I'll take
a relook at it.
>> my $perm = 'W'; $perm = 'R' if $verb =~ $R_COMMANDS;
>
> Either split it into two lines, or use ?: confitional operator:
>
> my $perm = ($verb =~ $R_COMMANDS ? 'R' : 'W');
much nicer... Fixed, thanks.
>> open(LOG, ">>", "$GL_ADMINDIR/log");
>> print LOG "\n", scalar(localtime), " $ENV{SSH_ORIGINAL_COMMAND} $user\n";
>> close(LOG);
>
> It is better practice to use lexical variables instead of barewords
> for filehandles:
Good catch; thanks! I guess I'm showing my age :) Fixed
all of them!
> Don't forget to check for error.
Hmm.. well I'm still debating if a log file write error
should block git access / push, but there were two more
important closes (again in gl-compile-conf) that were
unguarded. Fixed, thanks.
>> $repo = "'$REPO_BASE/$repo.git'";
>> exec("git", "shell", "-c", "$verb $repo");
>
> That's not enough. You have to shell-quote $repo, like in gitweb or
> using String::ShellQuote module, or somehow use list form to pass
> arguments to git-shell. You protect here againts spaces in filename,
> but not againts "'" (single quote) and for show shells "!"
> (exclamation mark).
It'll never get here. It'll die much earlier if the
reponame does not match a much stricter pattern. Maybe too
strict, actually: ^[0-9a-zA-Z][0-9a-zA-Z._/-]*$
However, I then realised I should tighten up the R_COMMANDS
and W_COMMANDS patterns a wee bit; as it stands, if someone
could create a file called, say "git-upload-pack.pwned", and
put it in the PATH, he could get the "git" user to execute
it! Sure if he managed to put something in the PATH that's
already game over in some sense but we have to stop what we
can :-) Thanks for catching this.
And once again, I really appreciate the extra eyeballs on
the code!
--
Sitaram
^ permalink raw reply
* Re: checkout to a reflog entry
From: bill lam @ 2009-08-25 5:37 UTC (permalink / raw)
To: git
In-Reply-To: <20090825052200.GA15880@coredump.intra.peff.net>
On Tue, 25 Aug 2009, Jeff King wrote:
> A reflog entry is not a branch; it is just a pointer to the commit where
> a branch was at some point. Using "git checkout" on it will let you
> explore the contents, just as you might with a tag. If you want to build
Thank you for explanation on the difference between checkout and
reset.
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ 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