* Re: [PATCH] import-tars: Allow per-tar author and commit message.
From: Peter Krefting @ 2009-08-25 18:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Sam Vilain, git
In-Reply-To: <7vab1pf3fj.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Unlike your "import-directories" that is a brand new program without any
> existing users, you are touching code that other people have already used,
> and you do not want to change the behaviour for them only because they
> happen to have unrelated files in the same directory.
Indeed. Not that it is likely that one have stray filetar.gz.msg files just
laying around, but I'll add a command line switch to enable the new
functinality. That sounds like the most reasonable way to go, leaving the
old usage completely unaffected by the change.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Jeff King @ 2009-08-25 18:45 UTC (permalink / raw)
To: Tom Werner; +Cc: Tom Preston-Werner, git
In-Reply-To: <12c267e40908251043g4f3e36aya05d9c705f5afee2@mail.gmail.com>
On Tue, Aug 25, 2009 at 10:43:57AM -0700, Tom Werner wrote:
> On Tue, Aug 18, 2009 at 12:04 AM, Tom Preston-Werner<tom@mojombo.com> wrote:
> > A post-upload-pack hook is desirable for Git hosts that need to
> > collect statistics on how many clones and/or fetches are made
> > on each repository.
> >
> > The hook is called with either "clone" or "fetch" as the only
> > argument, depending on whether a full pack file was sent to the
> > client or not.
>
> I was hoping to get some feedback on this patch, either positive or
> negative. Since we'll be applying this patch for our use of the Git
> Daemon on GitHub, it would be great to see it in core, so we don't
> have to maintain custom debian builds forever. I'd imagine that other
> Git hosting sites would find this hook useful as well. Thanks!
I expect it didn't get any response because nobody here cared one way or
the other. Not too surprising, since I think not many people are running
a GitHub-sized hosting site that cares about such statistics. ;) So I
think following up as you are doing is the right thing.
As for the hook itself, the concept certainly seems sane to me. It
passes the "hook" test defined here:
http://thread.gmane.org/gmane.comp.version-control.git/70781/focus=71069
because it is a remote trigger.
But a few comments on the patch:
> ---
> upload-pack.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
It needs at least a mention in Documentation/githooks.txt.
> +static void run_post_upload_pack_hook(int create_full_pack)
> +{
> + const char *fetch_type;
> + fetch_type = (create_full_pack) ? "clone" : "fetch";
> + run_hook(get_index_file(), "post-upload-pack", fetch_type);
> +}
Does it really need an index file? This operation in question seems to
be totally disconnected from the index (and indeed, most bare
repositories won't even have one). Probably it should pass NULL as the
initial argument to run_hook.
Is there any other information that might be useful to other non-GitHub
users of the hook? The only thing I can think of is the list of refs
that were fetched. I don't want to over-engineer it, but nor do I want
to be left with the mess of retro-fitting more information onto an
existing hook later. Maybe others can comment on whether they would find
more information useful.
-Peff
^ permalink raw reply
* Re: Confused about push/pull of a branch
From: Jeff King @ 2009-08-25 18:32 UTC (permalink / raw)
To: Fritz Anderson; +Cc: git
In-Reply-To: <8E2E19AE-DFA6-4000-AD73-35739F1E6642@uchicago.edu>
On Tue, Aug 25, 2009 at 12:58:25PM -0500, Fritz Anderson wrote:
> >I can't get a second machine to pull in a branch that's in my
> >remote repository. I'm confused.
>
> And just from half-wittedly fooling around, I tried:
>
> machine_2$ git pull origin webservices
That will merge the 'webservices' branch from your origin with your
current branch (which looks like 'master' in this case).
Remember that "pull" in git is really just "fetch" and "merge". What you
want is "fetch" and "create a new local branch":
$ git fetch
$ git checkout -b webservices origin/webservices
except that the "fetch" step has probably already been done as a
side-effect of the pull you did earlier.
> This seems to mean that master on machine_2 is now congruent to
> webservices on machine_1. That's not what I meant. Is there a way to
> undo this? git-pull origin-master doesn't seem to do anything.
Sort of. It contains all the changes of 'master' _and_ all the changes
of 'webservices'. However in this case there were no changes in 'master'
that were not already in 'webservices', so we were able to "fast
forward" to where webservices is. If the two branches had diverged at
all, you would have had a merge (potentially with conflicts).
To undo it, you probably want:
$ git checkout master ;# make sure we are on master branch
$ git reset --hard origin/master ;# go back to where remote master is
-Peff
^ permalink raw reply
* Re: Confused about push/pull of a branch
From: Jeff King @ 2009-08-25 18:27 UTC (permalink / raw)
To: Fritz Anderson; +Cc: git
In-Reply-To: <BA2E0DDB-3DE0-4D49-BFA6-72CFEDEBA5AE@uchicago.edu>
On Tue, Aug 25, 2009 at 12:40:47PM -0500, Fritz Anderson wrote:
> Branch webservices was created after the working copy on machine_2
> was cloned.
>
> In my working copy on machine_2:
>
> machine_2$ git pull
> Password:
> # Progress messages, no protests.
> machine_2$ git checkout webservices
> error: pathspec 'webservices' did not match any file(s) known to git.
> machine_2$ git branch
> * master
> machine_2$
Try "git branch -a", which will list remote branches. You likely have a
remote tracking branch "origin/webservices". You can check that out to
examine it, or if you want to start working on it locally, try "git
checkout -b webservices origin/webservices".
> git-config shows the two repository URLs are identical, net of
> machine_2 having to specify a user name and host. The machine_2 .git/
> config shows a section for [branch "master"], but not for
> webservices. Is that the problem? What's the approved way of adding
> [branch "webservices"], and what do I put into it?
The branch.webservices config is not necessary for a branch; it just
says "by the way, when you do a pull without arguments and we are on
this branch, here is where to pull from". Doing the "checkout -b" above
will create such a config section on recent versions of git.
> I've obviously forgotten something. Or never understood something
> (there's a lot in Git not to understand). How do I get the
> webservices branch onto machine_2, so I can check it out?
The branching model in git is a little different than other systems.
Just because the remote has a branch does not mean _you_ have a branch.
When you fetch from them (or pull, which does a fetch behind the
scenes), you will have a "remote tracking branch" which is your local
copy of where their remote branches are. You still need to create your
own local branch if you want to do work on it (and bear in mind your
branch doesn't need the same name or to be related in any long term way;
you are merely using their remote branch as a starting point for your
branch).
-Peff
^ permalink raw reply
* Re: Confused about push/pull of a branch
From: Fritz Anderson @ 2009-08-25 18:00 UTC (permalink / raw)
To: git
In-Reply-To: <8E2E19AE-DFA6-4000-AD73-35739F1E6642@uchicago.edu>
On Aug 25, 2009, at 12:58 PM, Fritz Anderson wrote:
> This seems to mean that master on machine_2 is now congruent to
> webservices on machine_1. That's not what I meant. Is there a way to
> undo this? git-pull origin-master doesn't seem to do anything.
Sigh. "git pull origin master". Sorry.
— F
^ permalink raw reply
* Re: Confused about push/pull of a branch
From: Fritz Anderson @ 2009-08-25 17:58 UTC (permalink / raw)
To: git
In-Reply-To: <BA2E0DDB-3DE0-4D49-BFA6-72CFEDEBA5AE@uchicago.edu>
On Aug 25, 2009, at 12:40 PM, Fritz Anderson wrote:
> I can't get a second machine to pull in a branch that's in my remote
> repository. I'm confused.
And just from half-wittedly fooling around, I tried:
machine_2$ git pull origin webservices
Password:
From fritza@fritzanderson.uchicago.edu:/Users/fritza/scientia/scientia
* branch webservices -> FETCH_HEAD
Updating 3c86901..6b09f9f
Fast forward
Calendar/Classes/CalendarWebController.m | 2 ++
# etc.
dirserver/lib/ldaputils.rb | 15 +++++----------
6 files changed, 34 insertions(+), 17 deletions(-)
machine_2$ sudo /usr/local/bin/git branch
* master
machine_2$
This seems to mean that master on machine_2 is now congruent to
webservices on machine_1. That's not what I meant. Is there a way to
undo this? git-pull origin-master doesn't seem to do anything.
— F
^ permalink raw reply
* Confused about push/pull of a branch
From: Fritz Anderson @ 2009-08-25 17:40 UTC (permalink / raw)
To: git
I can't get a second machine to pull in a branch that's in my remote
repository. I'm confused.
The remote is a bare repository on machine_1.
In my working copy on machine_1:
machine_1$ git branch
master
search-controller
use-tiles
* webservices
# The following should not be necessary, as gitk already
# identifies a remotes/origin/webservices, but just to be sporting:
machine_1$ git push origin webservices
Everything up-to-date
Branch webservices was created after the working copy on machine_2 was
cloned.
In my working copy on machine_2:
machine_2$ git pull
Password:
# Progress messages, no protests.
machine_2$ git checkout webservices
error: pathspec 'webservices' did not match any file(s) known to git.
machine_2$ git branch
* master
machine_2$
git-config shows the two repository URLs are identical, net of
machine_2 having to specify a user name and host. The machine_2 .git/
config shows a section for [branch "master"], but not for webservices.
Is that the problem? What's the approved way of adding [branch
"webservices"], and what do I put into it?
I've obviously forgotten something. Or never understood something
(there's a lot in Git not to understand). How do I get the webservices
branch onto machine_2, so I can check it out?
— F
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Tom Werner @ 2009-08-25 17:43 UTC (permalink / raw)
To: Tom Preston-Werner; +Cc: git
In-Reply-To: <1250579093-40706-1-git-send-email-tom@mojombo.com>
On Tue, Aug 18, 2009 at 12:04 AM, Tom Preston-Werner<tom@mojombo.com> wrote:
> A post-upload-pack hook is desirable for Git hosts that need to
> collect statistics on how many clones and/or fetches are made
> on each repository.
>
> The hook is called with either "clone" or "fetch" as the only
> argument, depending on whether a full pack file was sent to the
> client or not.
I was hoping to get some feedback on this patch, either positive or
negative. Since we'll be applying this patch for our use of the Git
Daemon on GitHub, it would be great to see it in core, so we don't
have to maintain custom debian builds forever. I'd imagine that other
Git hosting sites would find this hook useful as well. Thanks!
Tom
--
Tom Preston-Werner
GitHub Cofounder
http://tom.preston-werner.com
github.com/mojombo
^ permalink raw reply
* Re: [PATCH] send-email: confirm on empty mail subjects
From: Junio C Hamano @ 2009-08-25 17:35 UTC (permalink / raw)
To: Jan Engelhardt; +Cc: git
In-Reply-To: <alpine.LSU.2.00.0908251825150.21065@fbirervta.pbzchgretzou.qr>
Jan Engelhardt <jengelh@medozas.de> writes:
>>Near the tip of the 'pu' branch I
>>have a iffy workaround to "unbreak" the issue, but it is a rather
>>sledgehammer approach I do not feel comfortable enough to squash into your
>>patch yet.
>
> I see. Perhaps
>
> echo -en 'y\ny\n' | ...
>
> would be more gentle? (Noting that, how else should it be,
> many a shell do not have -e/-n again.)
You can solve it with printf "y\ny\n", but the reason I said it feels
wrong was because your added tests are the _only_ ones that expect more
than one "yes".
If some _other_ tests that currently need only one "yes" are broken in the
future and starts asking for more than one, we would like to know about
the breakage, but we won't notice it if we unconditionally fed "yes | ..."
or your "two y's | ..." to them. That is what I am unhappy about the
"iffy workaround".
^ permalink raw reply
* Re: [PATCH/RFC] make the new block-sha1 the default
From: Nicolas Pitre @ 2009-08-25 17:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7vprakpett.fsf@alter.siamese.dyndns.org>
On Mon, 24 Aug 2009, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > On Mon, Aug 24, 2009 at 11:04:37PM -0400, Nicolas Pitre wrote:
> >
> >> ... and remove support for linking against the openssl SHA1 code.
> >>
> >> The block-sha1 implementation is not significantly worse and sometimes
> >> even faster than the openssl SHA1 implementation. This allows for
> >
> > Is there a reason not to leave the option of linking against openssl?
>
> I think it is a valid question. Why remove the _option_?
Indeed, there is no value in limiting the choice.
> I would certainly understand it if you made BLK_SHA1 the _default_, though.
Since this is a RFC, and because this is not a clear choice, I'll simply
let others play with it and see for themselves. Suffice to compile git
with or without NO_OPENSSL defined. Some people (such as Jeff) are
finding the openssl SHA1 faster (irrespective of the -O0 issue), whereas
Linus simply hammered on the block-sha1 version until it was faster than
openssl for him (this is faster for me as well, on X86 and ARM). Also
those who initially found openssl to put a significant overhead on the
dynamic linking should probably perform more measurements with and
without NO_OPENSSL again. If more positive results are presented then
changing the default might make sense.
Nicolas
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Thiago Farina @ 2009-08-25 17:24 UTC (permalink / raw)
To: Frank Li
Cc: Marius Storm-Olsen, Reece Dunn, Johannes.Schindelin, msysgit, git
In-Reply-To: <1976ea660908250732q1e1fc153g663f3a9c13f1c902@mail.gmail.com>
Hi,
On Tue, Aug 25, 2009 at 11:32 AM, Frank Li<lznuaa@gmail.com> wrote:
>> that it's generated by generate-cmdlist.sh, so the VS user will need
>> to generate this file first (before compiling)?
>
> I update http://repo.or.cz/w/gitbuild.git.
> Add create_command.bat to create common-cmds.h.
>
This is great, thank you for adding this tool.
Today I ran 'git submodule update --init' and I recieved this error:
No submodule mapping found in .gitmodules for path 'ext/zlib'
The entry I have for zlib in .gitmodules is:
[submodule "ext\\zlib"]
path = ext\\zlib
url = git://repo.or.cz/zlib.git
Is this correct? All the others entries are configured like this:
[submodule ext/git]
path = ext/git
url = git://repo.or.cz/tgit.git
Another question: Is not better to put the README inside gitbuild with
the other files instead of compat/vcbuild/?
^ permalink raw reply
* [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
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