* Re: [ALTERNATE PATCH] Add a simple option parser.
From: Mike Hommey @ 2007-10-05 14:30 UTC (permalink / raw)
To: Pierre Habouzit, Kristian Høgsberg, git, Junio C Hamano
In-Reply-To: <20071005142507.GL19879@artemis.corp>
On Fri, Oct 05, 2007 at 04:25:07PM +0200, Pierre Habouzit <madcoder@debian.org> wrote:
> The option parser takes argc, argv, an array of struct option
> and a usage string. Each of the struct option elements in the array
> describes a valid option, its type and a pointer to the location where the
> value is written. The entry point is parse_options(), which scans through
> the given argv, and matches each option there against the list of valid
> options. During the scan, argv is rewritten to only contain the
> non-option command line arguments and the number of these is returned.
>
> Aggregation of single switches is allowed:
> -rC0 is the same as -r -C 0 (supposing that -C wants an arg).
I like options aggregation, but I'm not sure aggregating option arguments
is a good idea... I can't even think of an application that does it.
Mike
^ permalink raw reply
* Re: [PATCH] git-shell and git-cvsserver
From: Miklos Vajna @ 2007-10-05 14:31 UTC (permalink / raw)
To: Jan Wielemaker; +Cc: Git Mailing List
In-Reply-To: <200710051453.47622.wielemak@science.uva.nl>
[-- Attachment #1: Type: text/plain, Size: 187 bytes --]
On Fri, Oct 05, 2007 at 02:53:47PM +0200, Jan Wielemaker <wielemak@science.uva.nl> wrote:
> +#define EXEC_PATH "/usr/local/bin"
why don't you use $(prefix) from the Makefile?
- VMiklos
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Correction for post-receive-email
From: Andy Parkins @ 2007-10-05 14:29 UTC (permalink / raw)
To: git; +Cc: Bill Lear, Eric Mertens
In-Reply-To: <18182.12163.311826.242309@lisa.zopyra.com>
On Friday 2007 October 05, Bill Lear wrote:
> I have a few changes I would like to see in this script, ones that I think
> would make it generally more useful. I don't have a clean patch, though,
> so should I just submit suggestions to you directly, Andy?
Me; or the list. Or both.
I'm happy to try to accommodate any suggestions. I'm happy if it is useful to
anyone other than just me :-)
--- SNIP THIS BIT IF YOU'RE NOT INTERESTED IN ITS BUGS ---
The big fault in it as it stands is that it doesn't try to reorder the refs
being updated to the most logical form. For example:
O --- * --- A (ref2)
\
B (ref1)
Let's say that both ref1 and ref2 were originally at O and this push has moved
them to these new locations. The email hook gets sent this information like
this:
refs/heads/ref1 O B
refs/heads/ref2 O A
The hook iterates through this list, for each ref update it shows only the
commits introduced by the change that aren't already included in an existing
ref. This is the problem, ref2 introduced "*" and "A" and ref1
introduced "B", ideally then the two emails would show
ref2 updated from O to A
new revs: *, A
ref1 updated from O to B
new revs: B
But because ref1 is alphabetically before ref1, what you get is:
ref1 updated from O to B
new revs: *, A, B
ref2 updated from O to A
new revs: <none>
I can't say I know what the answer is; nor even what the correct output should
be. If anyone has opinions on this, I'll be glad to hear them.
Andy
--
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com
^ permalink raw reply
* [ALTERNATE PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-05 14:25 UTC (permalink / raw)
To: Kristian Høgsberg, git; +Cc: Junio C Hamano
In-Reply-To: <20071005142140.GK19879@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 6456 bytes --]
The option parser takes argc, argv, an array of struct option
and a usage string. Each of the struct option elements in the array
describes a valid option, its type and a pointer to the location where the
value is written. The entry point is parse_options(), which scans through
the given argv, and matches each option there against the list of valid
options. During the scan, argv is rewritten to only contain the
non-option command line arguments and the number of these is returned.
Aggregation of single switches is allowed:
-rC0 is the same as -r -C 0 (supposing that -C wants an arg).
Boolean switches automatically support the option with the same name,
prefixed with 'no-' to disable the switch:
--no-color / --color only need to have an entry for "color".
Long options are supported either with '=' or without:
--some-option=foo is the same as --some-option foo
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
I'm sorry about the "From" I don't intend to "steal" the patch in any
sense, it's just an alternate proposal.
oh and I don't grok what OPTION_LAST is for, so I left it apart, but
it seems unused ?
Makefile | 2 +-
parse-options.c | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
parse-options.h | 29 ++++++++++
3 files changed, 184 insertions(+), 1 deletions(-)
create mode 100644 parse-options.c
create mode 100644 parse-options.h
diff --git a/Makefile b/Makefile
index 62bdac6..d90e959 100644
--- a/Makefile
+++ b/Makefile
@@ -310,7 +310,7 @@ LIB_OBJS = \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \
convert.o attr.o decorate.o progress.o mailmap.o symlinks.o remote.o \
- transport.o bundle.o
+ transport.o bundle.o parse-options.o
BUILTIN_OBJS = \
builtin-add.o \
diff --git a/parse-options.c b/parse-options.c
new file mode 100644
index 0000000..eb3ff40
--- /dev/null
+++ b/parse-options.c
@@ -0,0 +1,154 @@
+#include "git-compat-util.h"
+#include "parse-options.h"
+
+struct optparse_t {
+ const char **argv;
+ int argc;
+ const char *opt;
+};
+
+static inline const char *skippfx(const char *str, const char *prefix)
+{
+ size_t len = strlen(prefix);
+ return strncmp(str, prefix, len) ? NULL : str + len;
+}
+
+static int opterror(struct option *opt, const char *reason, int shorterr)
+{
+ if (shorterr) {
+ return error("switch `%c' %s", opt->short_name, reason);
+ } else {
+ return error("option `%s' %s", opt->long_name, reason);
+ }
+}
+
+static int get_value(struct optparse_t *p, struct option *opt,
+ int boolean, int shorterr)
+{
+ switch (opt->type) {
+ const char *s;
+ int v;
+
+ case OPTION_BOOLEAN:
+ *(int *)opt->value = boolean;
+ return 0;
+
+ case OPTION_STRING:
+ if (p->opt && *p->opt) {
+ *(const char **)opt->value = p->opt;
+ p->opt = NULL;
+ } else {
+ if (p->argc < 1)
+ return opterror(opt, "requires a value", shorterr);
+ *(const char **)opt->value = *++p->argv;
+ p->argc--;
+ }
+ return 0;
+
+ case OPTION_INTEGER:
+ if (p->opt && *p->opt) {
+ v = strtol(p->opt, (char **)&s, 10);
+ p->opt = NULL;
+ } else {
+ if (p->argc < 1)
+ return opterror(opt, "requires a value", shorterr);
+ v = strtol(*++p->argv, (char **)&s, 10);
+ p->argc--;
+ }
+ if (*s)
+ return opterror(opt, "expects a numerical value", shorterr);
+ *(int *)opt->value = v;
+ return 0;
+ }
+
+ abort();
+}
+
+static int parse_short_opt(struct optparse_t *p, struct option *options, int count)
+{
+ int i;
+
+ for (i = 0; i < count; i++) {
+ if (options[i].short_name == *p->opt) {
+ p->opt++;
+ return get_value(p, options + i, 1, 1);
+ }
+ }
+ return error("unknown switch `%c'", *p->opt);
+}
+
+static int parse_long_opt(struct optparse_t *p, const char *arg,
+ struct option *options, int count)
+{
+ int boolean = 1;
+ int i;
+
+ for (i = 0; i < count; i++) {
+ const char *rest;
+
+ if (!options[i].long_name)
+ continue;
+
+ rest = skippfx(arg, options[i].long_name);
+ if (!rest && options[i].type == OPTION_BOOLEAN) {
+ if (!rest && skippfx(arg, "no-")) {
+ rest = skippfx(arg + 3, options[i].long_name);
+ boolean = 0;
+ }
+ if (rest && *rest == '=')
+ return opterror(options + i, "takes no value", 0);
+ }
+ if (!rest || (*rest && *rest != '='))
+ continue;
+ if (*rest) {
+ p->opt = rest;
+ }
+ return get_value(p, options + i, boolean, 0);
+ }
+ return error("unknown option `%s'", arg);
+}
+
+int parse_options(int argc, const char **argv,
+ struct option *options, int count,
+ const char *usage_string)
+{
+ struct optparse_t optp = { argv + 1, argc - 1, NULL };
+ int j = 0;
+
+ while (optp.argc) {
+ const char *arg = optp.argv[0];
+
+ if (*arg != '-' || !arg[1]) {
+ argv[j++] = *optp.argv++;
+ optp.argc--;
+ continue;
+ }
+
+ if (arg[1] != '-') {
+ optp.opt = arg + 1;
+ while (*optp.opt) {
+ if (parse_short_opt(&optp, options, count) < 0) {
+ usage(usage_string);
+ return -1;
+ }
+ }
+ optp.argc--;
+ optp.argv++;
+ continue;
+ }
+
+ if (!arg[2]) /* "--" */
+ break;
+
+ if (parse_long_opt(&optp, arg + 2, options, count)) {
+ usage(usage_string);
+ return -1;
+ }
+ optp.argc--;
+ optp.argv++;
+ }
+
+ memmove(argv + j, optp.argv, optp.argc * sizeof(argv));
+ argv[j + optp.argc] = NULL;
+ return j + optp.argc;
+}
diff --git a/parse-options.h b/parse-options.h
new file mode 100644
index 0000000..e4749d0
--- /dev/null
+++ b/parse-options.h
@@ -0,0 +1,29 @@
+#ifndef PARSE_OPTIONS_H
+#define PARSE_OPTIONS_H
+
+enum option_type {
+ OPTION_BOOLEAN,
+ OPTION_STRING,
+ OPTION_INTEGER,
+#if 0
+ OPTION_LAST,
+#endif
+};
+
+struct option {
+ enum option_type type;
+ const char *long_name;
+ char short_name;
+ void *value;
+};
+
+/* parse_options() will filter out the processed options and leave the
+ * non-option argments in argv[]. The return value is the number of
+ * arguments left in argv[].
+ */
+
+extern int parse_options(int argc, const char **argv,
+ struct option *options, int count,
+ const char *usage_string);
+
+#endif
--
1.5.3.4.1156.ga72f9d-dirty
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply related
* Re: [PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-05 14:21 UTC (permalink / raw)
To: Kristian Høgsberg; +Cc: git, gitster
In-Reply-To: <1191447902-27326-1-git-send-email-krh@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
> +/* Parse the given options against the list of known options. The
> + * order of the option structs matters, in that ambiguous
> + * abbreviations (eg, --in could be short for --include or
> + * --interactive) are matched by the first option that share the
> + * prefix.
Do we really want that ?
I do believe that it's a very bad idea, as it silently breaks. Most of
the command line switches people need to use have a short form, or their
shell will complete it properly.
A very interesting feature though, would be to finally be able to
parse aggregated switches (`git rm -rf` anyone ?).
I also believe that it's a pity that parse_options isn't able to
generate the usage by itself. But we can add that later.
I've though an alternate proposal, based on your work, for the first
patch.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Problems using StGit and -rt kernel patchset
From: Catalin Marinas @ 2007-10-05 13:45 UTC (permalink / raw)
To: Clark Williams; +Cc: git
In-Reply-To: <4703A4EE.3000002@gmail.com>
Clark,
What version of StGIT are you using? You might use a too new GIT with an
older StGIT or maybe there are just some bugs in StGIT.
On Wed, 2007-10-03 at 09:19 -0500, Clark Williams wrote:
> I've been working on the -rt patch series for the kernel and would like to to use
> StGit to manage the patches. Unfortunately I've had limited success, so I thought I'd
> ask the git/stgit community if what I'm doing is wrong.
>
> I clone Linus's tree to a common directory, then clone it locally to work:
>
> $ git clone -s -l /home/src/linux-2.6.git scratch.git
> $ cd scratch.git
> $ stg init
> $ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc8
> $ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc8-rt1/series
> <fix the things quilt lets through and stg barfs on, like malformed email addresses>
If git-quiltimport behaves better with malformed patches, use it and run
'stg uncommit -n 368' afterwards (the 'uncommit' takes some other useful
options as well, see --help).
> <watch 368 patches be applied and committed>
> <work work work>
Do you modify any of the -rt patches or you create new ones?
> <get a new patch queue>
> $ (cd /home/src/linux-2.6.git && git pull)
> $ stg pull
> $ stg branch --create rt-2.6.23-rc8-rt1 v2.6.23-rc9
> $ stg import --series --ignore --replace ../sources/patch-queue-2.6.23-rc9-rt1/series
> Checking for changes in the working directory ... done
> stg import: env git-commit-tree 520b9d0db6a1142271a68b2b38cca002be40f6cb -p
> da0a81e98c06aa0d1e05b9012c2b2facb1807e12 failed (fatal:
> da0a81e98c06aa0d1e05b9012c2b2facb1807e12 is not a valid 'commit' object)
I'm not sure why the first import worked. It seems that StGIT uses the
tag id (da0a81e9) rather than the corresponding commit id (3146b39c). I
remember having this problem in the past when creating branches and I
fixed StGIT to always get the corresponding commit id. Using
'v2.6.23-rc9^{commit}' as the 'branch' argument rather than just the tag
should fix the problem.
> At this point I'm clueless as to:
>
> 1. What I've done wrong
Probably nothing (just hidden features of StGIT :-))
> 2. How to recover/debug this
You can recreate the branch with the commit rather than tag id. With a
sufficiently new StGIT, you could use 'stg rebase <id>' on the branch. I
assume that no patch was pushed because import failed (though the first
imported patch might be in an undefined state and can be removed).
Catalin
^ permalink raw reply
* Re: Many gits are offline this week
From: Randal L. Schwartz @ 2007-10-05 13:12 UTC (permalink / raw)
To: Paolo Ciarrocchi; +Cc: Shawn O. Pearce, git
In-Reply-To: <4d8e3fd30710050214j135260cn842ee7396a3d63c7@mail.gmail.com>
>>>>> "Paolo" == Paolo Ciarrocchi <paolo.ciarrocchi@gmail.com> writes:
Paolo> is there any material (slides, docs) you can share before the talks?
I've had the slides reviewed by Smarter People Than Me on #git already, so
hopefully most of it is accurate. :) They're temporarily at
http://www.stonehenge.com/pic/Git-2.0.3-to-be.pdf
I still hope to have a few hours to go in and add a few sadly missing
graphics, particularly on the rebase vs merge section.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Bernt Hansen @ 2007-10-05 13:07 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git
In-Reply-To: <20071005085522.32EFF1E16E@madism.org>
This fixes it for me. Thanks!!
Bernt
^ permalink raw reply
* [PATCH] git-shell and git-cvsserver
From: Jan Wielemaker @ 2007-10-05 12:53 UTC (permalink / raw)
To: Git Mailing List
Hi,
I know, I shouldn't be using git-cvsserver :-( Anyway, I patched
git-shell to start git-cvsserver if it is started interactively and the
one and only line given to it is "cvs server".
The patch to shell.c is below. The trick with the EXEC_PATH is needed
because git-cvsserver doesn't appear to be working if you do not include
the git bindir in $PATH. I think that should be fixed in git-cvsserver
and otherwise we should at least make the value come from the prefix
make variable. With this patch I was able to use both Unix and Windows
cvs clients using git-shell as login shell.
Note that you must provide ~/.gitconfig with user and email in the
restricted environment.
Enjoy --- Jan
--- shell.c.org 2007-10-05 13:08:47.000000000 +0200
+++ shell.c 2007-10-05 14:24:11.000000000 +0200
@@ -18,27 +18,80 @@
return execv_git_cmd(my_argv);
}
+#define EXEC_PATH "/usr/local/bin"
+
+static int do_cvs_cmd(const char *me, char *arg)
+{
+ const char *my_argv[4];
+ const char *oldpath;
+
+ if ( !arg )
+ die("no argument");
+ if ( strcmp(arg, "server") )
+ die("only allows git-cvsserver server: %s", arg);
+
+ my_argv[0] = "cvsserver";
+ my_argv[1] = "server";
+ my_argv[2] = NULL;
+
+ if ( (oldpath=getenv("PATH")) ) {
+ char *newpath = malloc(strlen(oldpath)+strlen(EXEC_PATH)+5+1+1);
+
+ sprintf(newpath, "PATH=%s:%s", EXEC_PATH, oldpath);
+ putenv(newpath);
+ } else {
+ char *newpath = malloc(strlen(EXEC_PATH)+5+1);
+
+ sprintf(newpath, "PATH=%s", EXEC_PATH);
+ putenv(newpath);
+ }
+
+ return execv_git_cmd(my_argv);
+}
+
+
static struct commands {
const char *name;
int (*exec)(const char *me, char *arg);
} cmd_list[] = {
{ "git-receive-pack", do_generic_cmd },
{ "git-upload-pack", do_generic_cmd },
+ { "cvs", do_cvs_cmd },
{ NULL },
};
int main(int argc, char **argv)
{
char *prog;
+ char buf[256];
struct commands *cmd;
/* We want to see "-c cmd args", and nothing else */
- if (argc != 3 || strcmp(argv[1], "-c"))
- die("What do you think I am? A shell?");
+ if (argc == 1) {
+ if (fgets(buf, sizeof(buf)-1, stdin)) {
+ char *end;
+
+ if ( (end=strchr(buf, '\n')) )
+ { while(end>buf && end[-1] <= ' ')
+ end--;
+ *end = '\0';
+ } else {
+ die("Bad command");
+ }
+
+ prog = buf;
+ } else {
+ die("No command");
+ }
+ } else {
+ if (argc != 3 || strcmp(argv[1], "-c"))
+ die("What do you think I am? A shell?");
+
+ prog = argv[2];
+ argv += 2;
+ argc -= 2;
+ }
- prog = argv[2];
- argv += 2;
- argc -= 2;
for (cmd = cmd_list ; cmd->name ; cmd++) {
int len = strlen(cmd->name);
char *arg;
^ permalink raw reply
* Re: Correction for post-receive-email
From: Bill Lear @ 2007-10-05 12:35 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Eric Mertens
In-Reply-To: <200710050913.58835.andyparkins@gmail.com>
On Friday, October 5, 2007 at 09:13:57 (+0100) Andy Parkins writes:
>On Friday 2007 October 05, Eric Mertens wrote:
>
>> I noticed that my mutt wasn't correctly detecting the signature block
>> on the end of the automated emails I was receiving from the script in
>> contrib. I've made this trivial change in my local copy of the script,
>> but I figured that if I was going to be modifying the source code I
>> should share my changes.
>
>That change has been in my pending queue for a while. It's technically
>correct, but I've never submitted it. The reason I haven't is that it adds
>trailing whitespace.
>
>Perhaps one of the shell gurus can offer a nicer way of having a trailing
>space be output in a heredoc that doesn't add a trailing space in the source
>script?
I have a few changes I would like to see in this script, ones that I think
would make it generally more useful. I don't have a clean patch, though,
so should I just submit suggestions to you directly, Andy?
Bill
^ permalink raw reply
* Re: Question about "git commit -a"
From: Matthieu Moy @ 2007-10-05 12:45 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <47062CD7.70400@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> He. It's like comparing a duracell battery to the sun, but yes, that's
> one of the operations where the index is involved. But after doing your
> git-add thing above, you could also have continued hacking on A B C D,
> and git would only have committed the state where you did "git add".
> When you stop to think about this, you'll realize that it's a really
> powerful thing, as it lets you keep on hacking even when you don't
> really know where you'll end up.
That usage is indeed very close to a micro-micro-throwable branch.
Instead of doing:
<hack>
<diff>
<commit>
<hack>
<diff>
<commit>
# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want
$ git reset --hard HEAD^^ | $ git checkout HEAD^^
| $ git merge --squash HEAD@{1}
(untested)
You'd do:
<hack>
<diff>
<add>
<hack>
<diff>
<add>
# Oh, gosh, I didn't want that! | # Yes, _this_ is what I want
$ git reset --hard | $ git commit
The two flows are both similar and different. In the first case, you
can't come back to an arbitrary step within your development, but
since you didn't actually commit, and just ran "add", it's precisely
because you thought this state was not one you wanted to come back to
later. And at the time you commit, you don't have to tell git to
forget about the temporary branch, the succession of "git add" was
just for you, not to keep in history.
Actually, most of the time, I commit only when my index matches the
working tree (i.e. when status shows me only green, with color.status
= auto), so "commit" or "commit -a" don't change the result, but I
validate my own changes with "add", and give the whole thing a
descriptive message with "commit".
--
Matthieu
^ permalink raw reply
* Re: Post-update hook problems
From: Mike Ralphson @ 2007-10-05 12:27 UTC (permalink / raw)
To: Frank Lichtenheld; +Cc: Geoffrey Ferrari, git
In-Reply-To: <20071005120850.GM31659@planck.djpig.de>
On 10/5/07, Frank Lichtenheld <frank@lichtenheld.de> wrote:
> On Fri, Oct 05, 2007 at 12:27:22PM +0100, Geoffrey Ferrari wrote:
> > --
> > fatal: Not a git repository: '.'
> > Failed to find a valid git directory.
> > --
> >
> > Can anyone explain why this happens? And how can I make the script
> > work properly?
>
> I'm no hook expert, but it may have something to do with some
> environment variables that are set in hooks, you might need to change
> variables like GIT_DIR.
Ack.
The hooks seem to assume repositories pushed into are bare, so the
GIT_DIR isn't set to a .git subdirectory (even if it exists).
Mike
^ permalink raw reply
* Re: Question about "git commit -a"
From: Andreas Ericsson @ 2007-10-05 12:23 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List
In-Reply-To: <4d8e3fd30710050519k7a3db02dk5ba9750fd8e9705f@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
> [...]
>> As for the "git commit should default to -a" discussion, I think it's pretty
>> clear where I stand ;-)
>
> Fair enough.
>
> Another try to have an easy explanation of how the staging area works:
>
> paolo@paolo-desktop:~/HowIndexWorks$ ls
> A B C D E F G
>
> Now I edit A,B,C,D and E:
>
> $ echo A >> A
> $ echo B >> B
> $ echo C >> C
> $ echo D >> D
> $ echo E >> E
>
> I now realize want to only commit the changes I did to A,B,C,D.
> First step is to place A,B,C and D into the staging area:
> $ git add A B C D
>
> Now I can commit:
> $ git commitpaolo@paolo-desktop:~/HowIndexWorks$ git commit
> Created commit 16032dc: I modified A,B,C and D
> 4 files changed, 4 insertions(+), 0 deletions(-)
>
> It's now time to work on F and G:
> $ echo F >> F
> $ echo G >> G
>
> Current status is:
> paolo@paolo-desktop:~/HowIndexWorks$ git status
> # On branch master
> # Changed but not updated:
> # (use "git add <file>..." to update what will be committed)
> #
> # modified: E
> # modified: F
> # modified: G
>
> Instead of adding E,F and G to the staging are and then commit them in
> two steps I can using a single command:
> $ git commit E F G (in this case it's equivalent to git commit -a)
>
He. It's like comparing a duracell battery to the sun, but yes, that's
one of the operations where the index is involved. But after doing your
git-add thing above, you could also have continued hacking on A B C D,
and git would only have committed the state where you did "git add".
When you stop to think about this, you'll realize that it's a really
powerful thing, as it lets you keep on hacking even when you don't
really know where you'll end up.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Question about "git commit -a"
From: Paolo Ciarrocchi @ 2007-10-05 12:19 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List
In-Reply-To: <47060BB3.3030208@op5.se>
On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
[...]
> As for the "git commit should default to -a" discussion, I think it's pretty
> clear where I stand ;-)
Fair enough.
Another try to have an easy explanation of how the staging area works:
paolo@paolo-desktop:~/HowIndexWorks$ ls
A B C D E F G
Now I edit A,B,C,D and E:
$ echo A >> A
$ echo B >> B
$ echo C >> C
$ echo D >> D
$ echo E >> E
I now realize want to only commit the changes I did to A,B,C,D.
First step is to place A,B,C and D into the staging area:
$ git add A B C D
Now I can commit:
$ git commitpaolo@paolo-desktop:~/HowIndexWorks$ git commit
Created commit 16032dc: I modified A,B,C and D
4 files changed, 4 insertions(+), 0 deletions(-)
It's now time to work on F and G:
$ echo F >> F
$ echo G >> G
Current status is:
paolo@paolo-desktop:~/HowIndexWorks$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
#
# modified: E
# modified: F
# modified: G
Instead of adding E,F and G to the staging are and then commit them in
two steps I can using a single command:
$ git commit E F G (in this case it's equivalent to git commit -a)
paolo@paolo-desktop:~/HowIndexWorks$ git commit E F G
Created commit 69ec8be: I modified E, F and G
3 files changed, 3 insertions(+), 0 deletions(-)
status now is:
paolo@paolo-desktop:~/HowIndexWorks$ git status
# On branch master
nothing to commit (working directory clean)
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
^ permalink raw reply
* Re: Question about "git commit -a"
From: Andreas Ericsson @ 2007-10-05 12:17 UTC (permalink / raw)
To: Matthieu Moy
Cc: Paolo Ciarrocchi, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Wincent Colaiuta, Git Mailing List
In-Reply-To: <vpqsl4piykb.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>>>> or check which merge- conflicts you've already resolved,
>>> At least bzr and baz have this kind of conflict management. It's just
>>> a separate file, containing the list of unresolved conflicts.
>> Can you check them against any revision you want? If so, I'm
>> impressed :)
>
> If you mean s/check/diff/, not in a simple way, no. Otherwise, I don't
> understand what you mean by "check merge-conflicts you've already
> resolved against any revision".
>
Actually, I meant "diff the staged area against any random commit". It's
really nice to do after a bisect, where you know what the bad commit looks
like, and how the code changed to introduce the bug.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Teach core.autocrlf to 'git blame'
From: Marius Storm-Olsen @ 2007-10-05 12:13 UTC (permalink / raw)
To: git, junkio; +Cc: Marius Storm-Olsen
Pass the fake commit through convert_to_git, so that the
file is adjusted for local line-ending convention.
Signed-off-by: Marius Storm-Olsen <marius@trolltech.com>
---
Added missing signoff in the previous mail.
builtin-blame.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/builtin-blame.c b/builtin-blame.c
index e3112a2..8432b82 100644
--- a/builtin-blame.c
+++ b/builtin-blame.c
@@ -2059,6 +2059,7 @@ static struct commit *fake_working_tree_commit(const char *path, const char *con
if (strbuf_read(&buf, 0, 0) < 0)
die("read error %s from stdin", strerror(errno));
}
+ convert_to_git(path, buf.buf, buf.len, &buf);
origin->file.ptr = buf.buf;
origin->file.size = buf.len;
pretend_sha1_file(buf.buf, buf.len, OBJ_BLOB, origin->blob_sha1);
--
1.5.3.4.1155.gfe96ee-dirty
^ permalink raw reply related
* Re: Post-update hook problems
From: Frank Lichtenheld @ 2007-10-05 12:08 UTC (permalink / raw)
To: Geoffrey Ferrari; +Cc: git
In-Reply-To: <930d91430710050427o79395023nffe3bd842a87cddb@mail.gmail.com>
On Fri, Oct 05, 2007 at 12:27:22PM +0100, Geoffrey Ferrari wrote:
> --
> fatal: Not a git repository: '.'
> Failed to find a valid git directory.
> --
>
> Can anyone explain why this happens? And how can I make the script
> work properly?
I'm no hook expert, but it may have something to do with some
environment variables that are set in hooks, you might need to change
variables like GIT_DIR.
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: Question about "git commit -a"
From: Matthieu Moy @ 2007-10-05 11:35 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Paolo Ciarrocchi, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Wincent Colaiuta, Git Mailing List
In-Reply-To: <47060E98.2090601@op5.se>
Andreas Ericsson <ae@op5.se> writes:
>>> or check which merge- conflicts you've already resolved,
>>
>> At least bzr and baz have this kind of conflict management. It's just
>> a separate file, containing the list of unresolved conflicts.
>
> Can you check them against any revision you want? If so, I'm
> impressed :)
If you mean s/check/diff/, not in a simple way, no. Otherwise, I don't
understand what you mean by "check merge-conflicts you've already
resolved against any revision".
--
Matthieu
^ permalink raw reply
* Post-update hook problems
From: Geoffrey Ferrari @ 2007-10-05 11:27 UTC (permalink / raw)
To: git
I have a public and a private git repository on the same machine, in
the same user's home directory. I want to ensure that when the public
repos is updated, the private repos automatically receives those
updates. Let's just assume that this is a good idea.
So, I've created a post-update hook script and made it executable. The
script is very simple. It 'cd's to the private repos and then does a
git pull. It looks, in essence, like this:
--
#!/bin/sh
cd /user/home/private/repos
git pull
exit 0
--
When I run this script directly, it works fine. (It also works fine
when I run it directly over ssh). However, when I do a git push to the
public repos, (either locally or remotely over ssh) the script is
called but reports back the following error:
--
fatal: Not a git repository: '.'
Failed to find a valid git directory.
--
Can anyone explain why this happens? And how can I make the script
work properly?
With sincere thanks for your help,
Geoffrey Ferrari
^ permalink raw reply
* Re: Question about "git commit -a"
From: Wincent Colaiuta @ 2007-10-05 10:48 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Git Mailing List
In-Reply-To: <4d8e3fd30710050139j45a5a924t5c048994e3457c5f@mail.gmail.com>
El 5/10/2007, a las 10:39, Paolo Ciarrocchi escribió:
> So you are used to do something like (please correct me if I'm wrong):
> - modify A
> - modify B
> - modify C
> - modify D
> - modify E
>
> $ git A B E
> $ git add A B E (A, B and E are now in the staging area)
> $ git commit -m "I just modified A,B and E"
> $ git C D
> $ git add C D (C and D are now in the staging area)
> $ git commit -m "I just modified C and D"
The conceptual shift is that in Git your index and not your working
directory is your staging area, unlike (most/all?) other SCMs. If you
fire up gitk and look at the development history of Git itself you'll
see that it's one of the "cleanest" out there, and as you learn Git
you learn about the various tools and tricks that it provides that
makes it easier for a developer community to produce such a clean
history; the index as a staging area is one of the key factors.
The basic workflow is:
# work on a single change
edit A
git add A
edit B
git add B
# see unrelated thing that needs to be fixed, but don't add
(stage) it yet
edit C
# commit first change, then second one
git commit -s
git commit -s C
This is just one example of how having a staging area that you can
control independently of your working tree can help you. There are
other possible workflows and you discover them through use, but they
all share the basic idea that you use the staging area to provide you
with better control.
Sometimes you're trying to work on a single thing and you see a
change within a single file that isn't related. In that case you have
an even finer level of granularity available and can use "git add --
interactive" to add only specific hunks.
Finally, closely related to this idea of maintaining a clean history
is the newly-added and wonderful "git stash". If you have a
relatively complicated work in progress already half-staged in the
index and you see something else relatively complicated that you want
to attend to straight away then you can easily switch to the second
task, commit it, and go back to the first task, thus keeping your
development history nice and clean. This is a beautiful example of
your SCM facilitating your work and making it easy rather than
forcing you to jump through hoops. See the git-stash man page for
more details.
I think all of this is incredibly powerful useful stuff, and all of
it comes at a very low cost; it's easy to learn and doesn't require
you to do any magical and complex history rewriting in order to get a
nice clean history.
And on the subject of staging areas, thanks to "git commit --amend"
you can even use the last commit as a kind of secondary, addditional
staging area, providing you haven't published that commit yet. In
other words, I frequently do:
git show HEAD
Immediately after committing and if I don't like what I see I make
modifications as necessary and do:
git commit --amend
Cheers,
Wincent
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Miles Bader @ 2007-10-05 10:41 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <0A7AA9C3-6D9E-4B14-822D-05232F0EAF99@wincent.com>
On 10/5/07, Wincent Colaiuta <win@wincent.com> wrote:
> > Personally all I want is a short-option alias for --cached!
> >
> > Hopefully something easily type-able (not uppercase)...
>
> Did you see the aliases I posted earlier in the thread? I can't think
> of anything shorter or semantically clearer than "staged" and
> "unstaged".
The words are ok, I guess, but aliases are not a replacement for short
options.... really all frequently used, non-dangerous, options should
have a short variant (and diff --cached meets both criteria handily)!
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: A few usability question about git diff --cached
From: Wincent Colaiuta @ 2007-10-05 10:27 UTC (permalink / raw)
To: Miles Bader; +Cc: Paolo Ciarrocchi, Git Mailing List
In-Reply-To: <buoejga14qg.fsf@dhapc248.dev.necel.com>
El 5/10/2007, a las 7:59, Miles Bader escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>> You're probably right that the option name is confusing, I guess
>> changing it to "--index" would be a good idea, continuing to support
>> "--cached" but marking it as deprecated before finally removing it at
>> some point in the future.
>
> Personally all I want is a short-option alias for --cached!
>
> Hopefully something easily type-able (not uppercase)...
Did you see the aliases I posted earlier in the thread? I can't think
of anything shorter or semantically clearer than "staged" and
"unstaged".
Cheers,
Wincent
^ permalink raw reply
* Re: Question about "git commit -a"
From: Andreas Ericsson @ 2007-10-05 10:14 UTC (permalink / raw)
To: Matthieu Moy
Cc: Paolo Ciarrocchi, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Wincent Colaiuta, Git Mailing List
In-Reply-To: <vpqy7ehj2g8.fsf@bauges.imag.fr>
Matthieu Moy wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
>> Yes, but it's so enormously powerful once you get a grip on it that I can't
>> for the life of me imagine an scm system without it. You just can't do
>> "scm commit --interactive" without it in a sane way,
>
> darcs|hg record do a very similar job. The real difference between
> darcs and others here is not "scm commit --interactive", but the fact
> that you can split the work among multiple commands, the index
> maintains a persistant state.
>
>> or check which merge- conflicts you've already resolved,
>
> At least bzr and baz have this kind of conflict management. It's just
> a separate file, containing the list of unresolved conflicts.
>
Can you check them against any revision you want? If so, I'm impressed :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* git-cvsserver (absent) interaction with --shared=
From: Jan Wielemaker @ 2007-10-05 10:08 UTC (permalink / raw)
To: Git Mailing List
Hi,
Before I forget. The notion of --shared=all/group is very useful for
avoiding permission issues in git. GIT repos used for CVS will often be
shared. Unfortunately git-cvsserver doesn't make the SQLite databases
group-writable if core.sharedrepository = 1.
--- Jan
^ permalink raw reply
* Re: Question about "git commit -a"
From: Matthieu Moy @ 2007-10-05 10:11 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Paolo Ciarrocchi, Johannes Schindelin, Nguyen Thai Ngoc Duy,
Wincent Colaiuta, Git Mailing List
In-Reply-To: <47060BB3.3030208@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Yes, but it's so enormously powerful once you get a grip on it that I can't
> for the life of me imagine an scm system without it. You just can't do
> "scm commit --interactive" without it in a sane way,
darcs|hg record do a very similar job. The real difference between
darcs and others here is not "scm commit --interactive", but the fact
that you can split the work among multiple commands, the index
maintains a persistant state.
> or check which merge- conflicts you've already resolved,
At least bzr and baz have this kind of conflict management. It's just
a separate file, containing the list of unresolved conflicts.
> or compare working tree with what the next commit *will* look like,
To me, *that* is the point.
--
Matthieu
^ 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