* [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
* Re: [PATCH] Add a simple option parser.
From: Pierre Habouzit @ 2007-10-05 10:08 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: 844 bytes --]
On Wed, Oct 03, 2007 at 09:45:01PM +0000, Kristian Høgsberg wrote:
> +static int parse_one(const char **argv,
> + struct option *options, int count,
> + const char *usage_string)
> +{
> + const char *eq, *arg, *value;
> + int i, processed;
gcc complains processed could be returned without being initialized
first, so should be processed = 0; Even if it cannot occurs, it avoid
raising eyebrows.
> + case OPTION_INTEGER:
> + if (value == NULL) {
> + error("option %s requires a value.", argv);
^^^
should probably be arg.
--
·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: Question about "git commit -a"
From: Andreas Ericsson @ 2007-10-05 10:02 UTC (permalink / raw)
To: Paolo Ciarrocchi
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List
In-Reply-To: <4d8e3fd30710050206h7a177472x7c92f91204b15aa4@mail.gmail.com>
Paolo Ciarrocchi wrote:
> On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
>> Paolo Ciarrocchi wrote:
>>> On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>>>> Hi,
>>>>
>>>> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
>>>>
>>>>> On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
>>>>>>> Am I wrong?
>>>>>> About it being a majority, yes, I suspect so.
>>>>>>
>>>>> Maybe in the next survey we should include question "do you usually do
>>>>> 'git commit' or 'git commit -a'" :-)
>>>> Not meaning to discourage you, but it is a known fact that Linus does "git
>>>> commit" without "-a" quite often.
>>>>
>>>> And if that were not bad enough for your plan, I myself omit "-a"
>>>> regularly. So you would get a veto from me, too.
>>> 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 add A B E (A, B and E are now in the staging area)
>>> $ git commit -m "I just modified A,B and E"
>> I do something like that, except that for full-file commits I'd rather
>> say
>>
>> git commit -s A B E
>>
>> I never pass -m to git commit. It's too easy to get into habit of being
>> sloppy with historic documentation that way.
>
> Right.
> But in the scenario you described isn't enough to type "git commit -s".
> Why did you write "git commit -s A B E".
>
Because that way I don't have to do "git add A B E" first.
>
>>> $ git add C D (C and D are now in the staging area)
>>> $ git commit -m "I just modified C and D"
>>>
>> See above :)
>>
>> There's also the times when I hack on some feature and find some small
>> bug/easy-to-write-feature, so I make the change for that other thing,
>> swap to a different branch and do 'git commit -s --interactive' to
>> just break out that small fix.
>>
>> Or if I have to add some logic to some other function in a file I've
>> modified for other purposes and want it to be two separate commits,
>> I just make the change and then run 'git commit --interactive' to
>> make it two separate commits.
>
> Very interesting!
>
>> I just don't do 'git commit -a' for the same reason I don't do
>> 'git commit -m', really. It tends to be habit-forming, and bisect
>> has saved my arse enough times for me to *want* my changes to be
>> small and isolated. Debugging a 5-line patch is so much more pleasant
>> than debugging a 30k-lines one that spans over several different files.
>
> Yeah, I see.
> Thanks for your comments Andreas, very appreciated.
>
> Just to clarify my goal, since I had that interesting discussion with
> an hg user I started looking for simple examples of the usage of the
> "staging area" to be added to the introduction to git documentation.
> The role of the index/staging area seems to be something complex for a
> git newbie.
>
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, or check which merge-
conflicts you've already resolved, or compare working tree with what the
next commit *will* look like, or... The list goes on. Like I said, it's so
immensely powerful that all the things you can do when you have one is, all
by itself, reason enough to switch from any other scm to git.
As for the "git commit should default to -a" discussion, I think it's pretty
clear where I stand ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: stgit: editing description of patch
From: Catalin Marinas @ 2007-10-05 9:16 UTC (permalink / raw)
To: git
In-Reply-To: <20071004173929.GD21717@diana.vm.bytemark.co.uk>
(for whatever reason, gnus decided that it no longer likes the
authenticated SMTP server, so I'm trying to post via gmane).
On Thu, 04 Oct 2007 19:39:29 +0200, Karl Hasselström wrote:
> On 2007-10-04 12:45:17 -0400, Jon Smirl wrote:
>
>> Why are the patch name and the short description independent
>> variables? Wouldn't it make more sense to treat these as a single
>> unified item? If I rename the patch it would automatically edit the
>> first line of the description, etc...
>
> I guess Catalin would have to answer that -- it's "always" been like
> that. But one obvious problem are patches with identical messages --
> just today I created a series of seven patches that all had "debug"
> for a message. Another is that you usually want descriptive commit
> messages, but may want short and easy-to-type patch names.
That's pretty much the case. There are also the historical reasons (quilt
does the same) plus the fact the exporting should really generate shorter
and simpler file names rather than name with capitals and spaces. I've
also seen people writing a single paragraph over several lines without a
short description. You wouldn't really want a patch name that long.
Anyway, 'stg series -d' would show the patch name together with the short
description.
>> When importing a patch from a saved email, stg should strip all the
>> email headers out of the description. I have to manually fix that
>> up.
>
> Do you do "stg import -M"? That's for importing one or more patches
> contained in an mbox. Without the -M, I think the default is to expect
> plain diff input.
There is also 'stg import -m' for single e-mails rather than mbox. StGIT
should be able to cope with attachments as well.
Catalin
^ permalink raw reply
* Re: [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Johannes Sixt @ 2007-10-05 9:24 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, git, Bernt Hansen
In-Reply-To: <20071005085522.32EFF1E16E@madism.org>
Pierre Habouzit schrieb:
> @@ -281,20 +283,19 @@ static int apply_filter(const char *path, const char *src, size_t len,
> ret = 0;
> }
> if (close(pipe_feed[0])) {
> - ret = error("read from external filter %s failed", cmd);
> + error("read from external filter %s failed", cmd);
> ret = 0;
> }
> status = finish_command(&child_process);
> if (status) {
> - ret = error("external filter %s failed %d", cmd, -status);
> + error("external filter %s failed %d", cmd, -status);
> ret = 0;
> }
If you want to, you can leave away these cosmetical corrections since I'm
working on a patch that replaces this entire passus. (Will be needed for the
MinGW port).
-- Hannes
^ permalink raw reply
* Re: Many gits are offline this week
From: Paolo Ciarrocchi @ 2007-10-05 9:14 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Shawn O. Pearce, git
In-Reply-To: <863awq5p1y.fsf@blue.stonehenge.com>
On 10/5/07, Randal L. Schwartz <merlyn@stonehenge.com> wrote:
> >>>>> "Shawn" == Shawn O Pearce <spearce@spearce.org> writes:
>
> Shawn> Dscho and I will be (at least mostly) offline for the next four
> Shawn> days as we travel to San Jose for the 2007 Google Summer of Code
> Shawn> Mentor Summit.
>
> Oddly enough, I'm giving my "Intro to Git" talk at Google HQ on
> 12 october. Too bad you're just going to miss that. :)
Hi Randal,
is there any material (slides, docs) you can share before the talks?
Thanks!
Regards,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* Re: Question about "git commit -a"
From: Paolo Ciarrocchi @ 2007-10-05 9:06 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Johannes Schindelin, Nguyen Thai Ngoc Duy, Wincent Colaiuta,
Git Mailing List
In-Reply-To: <4705FB52.3030208@op5.se>
On 10/5/07, Andreas Ericsson <ae@op5.se> wrote:
> Paolo Ciarrocchi wrote:
> > On 10/4/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> >> Hi,
> >>
> >> On Fri, 5 Oct 2007, Nguyen Thai Ngoc Duy wrote:
> >>
> >>> On 10/4/07, Wincent Colaiuta <win@wincent.com> wrote:
> >>>>> Am I wrong?
> >>>> About it being a majority, yes, I suspect so.
> >>>>
> >>> Maybe in the next survey we should include question "do you usually do
> >>> 'git commit' or 'git commit -a'" :-)
> >> Not meaning to discourage you, but it is a known fact that Linus does "git
> >> commit" without "-a" quite often.
> >>
> >> And if that were not bad enough for your plan, I myself omit "-a"
> >> regularly. So you would get a veto from me, too.
> >
> > 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
>
>
> This isn't really a valid command. I'm not sure where you got it from.
Doh! Don't consider it, it's just a silly copy and paste error! It has
no meaning!
> > $ 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"
>
> I do something like that, except that for full-file commits I'd rather
> say
>
> git commit -s A B E
>
> I never pass -m to git commit. It's too easy to get into habit of being
> sloppy with historic documentation that way.
Right.
But in the scenario you described isn't enough to type "git commit -s".
Why did you write "git commit -s A B E".
> > $ git C D
>
> Again not a valid command, but...
See above, just a very silly copy and paste error.
> > $ git add C D (C and D are now in the staging area)
> > $ git commit -m "I just modified C and D"
> >
>
> See above :)
>
> There's also the times when I hack on some feature and find some small
> bug/easy-to-write-feature, so I make the change for that other thing,
> swap to a different branch and do 'git commit -s --interactive' to
> just break out that small fix.
>
> Or if I have to add some logic to some other function in a file I've
> modified for other purposes and want it to be two separate commits,
> I just make the change and then run 'git commit --interactive' to
> make it two separate commits.
Very interesting!
> I just don't do 'git commit -a' for the same reason I don't do
> 'git commit -m', really. It tends to be habit-forming, and bisect
> has saved my arse enough times for me to *want* my changes to be
> small and isolated. Debugging a 5-line patch is so much more pleasant
> than debugging a 30k-lines one that spans over several different files.
Yeah, I see.
Thanks for your comments Andreas, very appreciated.
Just to clarify my goal, since I had that interesting discussion with
an hg user I started looking for simple examples of the usage of the
"staging area" to be added to the introduction to git documentation.
The role of the index/staging area seems to be something complex for a
git newbie.
Regards
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://ubuntista.blogspot.com
^ permalink raw reply
* [AGGREGATED PATCH] Fix in-place editing functions in convert.c
From: Pierre Habouzit @ 2007-10-05 8:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Bernt Hansen
In-Reply-To: <20071005082026.GE19879@artemis.corp>
* crlf_to_git and ident_to_git:
Don't grow the buffer if there is enough space in the first place.
As a side effect, when the editing is done "in place", we don't grow, so
the buffer pointer doesn't changes, and `src' isn't invalidated anymore.
Thanks to Bernt Hansen for the bug report.
* apply_filter:
Fix memory leak due to fake in-place editing that didn't collected the
old buffer when the filter succeeds. Also a cosmetic fix.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
This patch is on top of master, and supersedes both patch I sent before.
Following dscho's remark, I only grow the buffer if they aren't big enough
in the first place, which ensures that buffers are not touched if edited in
place.
convert.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/convert.c b/convert.c
index 0d5e909..aa95834 100644
--- a/convert.c
+++ b/convert.c
@@ -110,7 +110,9 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
return 0;
}
- strbuf_grow(buf, len);
+ /* only grow if not in place */
+ if (strbuf_avail(buf) + buf->len < len)
+ strbuf_grow(buf, len - buf->len);
dst = buf->buf;
if (action == CRLF_GUESS) {
/*
@@ -281,20 +283,19 @@ static int apply_filter(const char *path, const char *src, size_t len,
ret = 0;
}
if (close(pipe_feed[0])) {
- ret = error("read from external filter %s failed", cmd);
+ error("read from external filter %s failed", cmd);
ret = 0;
}
status = finish_command(&child_process);
if (status) {
- ret = error("external filter %s failed %d", cmd, -status);
+ error("external filter %s failed %d", cmd, -status);
ret = 0;
}
if (ret) {
- *dst = nbuf;
- } else {
- strbuf_release(&nbuf);
+ strbuf_swap(dst, &nbuf);
}
+ strbuf_release(&nbuf);
return ret;
}
@@ -422,7 +423,9 @@ static int ident_to_git(const char *path, const char *src, size_t len,
if (!ident || !count_ident(src, len))
return 0;
- strbuf_grow(buf, len);
+ /* only grow if not in place */
+ if (strbuf_avail(buf) + buf->len < len)
+ strbuf_grow(buf, len - buf->len);
dst = buf->buf;
for (;;) {
dollar = memchr(src, '$', len);
--
1.5.3.4.207.gb504-dirty
^ permalink raw reply related
* Re: Correction for post-receive-email
From: Andreas Ericsson @ 2007-10-05 8:54 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Eric Mertens
In-Reply-To: <200710050913.58835.andyparkins@gmail.com>
Andy Parkins wrote:
> 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?
>
space=' '
cat << EOF
--$space
EOF
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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