* Re: [PATCH] Implement git commit as a builtin command.
From: Karl Hasselström @ 2007-11-02 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vsl3p3s48.fsf@gitster.siamese.dyndns.org>
On 2007-11-02 02:37:43 -0700, Junio C Hamano wrote:
> Karl Hasselström <kha@treskal.com> writes:
>
> > I wonder if it would be such a bad idea to make this the default.
> > It seems like _everyone_ who should be using it forget it. And the
> > number of patches made for human or git consumption is probably
> > vastly larger than the number of patches made for consumption by
> > other tools.
>
> On this mailing list, we can pretty much assume that renaming diff
> can be applied by people. But outside world is a different story.
So I guess a prerequisite for this is to get git patch format support
into GNU patch, then? :-)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Benoit SIGOURE @ 2007-11-02 9:39 UTC (permalink / raw)
To: Mike Hommey; +Cc: git list
In-Reply-To: <20071102093028.GA29699@glandium.org>
[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]
On Nov 2, 2007, at 10:30 AM, Mike Hommey wrote:
> On Fri, Nov 02, 2007 at 02:03:52AM -0700, Junio C Hamano
> <gitster@pobox.com> wrote:
>> Blake Ramsdell <blaker@gmail.com> writes:
>>
>>> Signed-off-by: Blake Ramsdell <blaker@gmail.com>
>>> ---
>>> Makefile | 4 +++-
>>> 1 files changed, 3 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/Makefile b/Makefile
>>> index 71479a2..5d83756 100644
>>> --- a/Makefile
>>> +++ b/Makefile
>>> @@ -401,7 +401,9 @@ endif
>>> ifeq ($(uname_S),Darwin)
>>> NEEDS_SSL_WITH_CRYPTO = YesPlease
>>> NEEDS_LIBICONV = YesPlease
>>> - OLD_ICONV = UnfortunatelyYes
>>> + ifneq ($(uname_R),9.0.0)
>>> + OLD_ICONV = UnfortunatelyYes
>>> + endif
>>> NO_STRLCPY = YesPlease
>>> NO_MEMMEM = YesPlease
>>> endif
>>
>> I do not have an access to a Darwin box, but do you mean 10.5
>> gives 9.0.0 as uname_R?
>
> Be it that or not, it looks wrong to me to check the Darwin version to
> know what to use. Do you rely on the Linux kernel version to know
> whether
> iconv is present ?
It's very different, on OSX you don't change your own kernel as you
want, the kernel isn't a standalone component, it comes packaged with
the entire system of MacOSX. When you do an update to 10.5 (aka
Leopard) you will have a new version of iconv so you're guaranteed
that someone with 10.5 has a system-wide iconv that is not OLD_ICONV.
--
Benoit Sigoure aka Tsuna
EPITA Research and Development Laboratory
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-11-02 9:39 UTC (permalink / raw)
To: Pierre Habouzit, Junio C Hamano, Geert Bosch, Linus Torvalds, git
In-Reply-To: <20071101214257.GB7161@artemis.corp>
Pierre Habouzit wrote:
> On Thu, Nov 01, 2007 at 08:27:55PM +0000, Junio C Hamano wrote:
>> Geert Bosch <bosch@adacore.com> writes:
>>
>>> I often type "make clean" as well many "git xyz" commands
>>> during development, and so it happens that at times, I type
>>> "git clean" by accident.
>> Happened to me once. I hate that command.
>>
>>> So, I propose *not* converting git clean to a C builtin,
>>> but instead adding --untracked and --ignored options to
>>> git-rm.
>> I think what you are trying to do is to deprecate or remove "git
>> clean".
>>
>> I do not know where "git clean" came from. I am suspecting that
>> it was to give counterparts to some other SCMs, but do not know
>> which ones. Some people wanted to have it --- so you need to
>> convince them that it is a bad idea first. Adding an equivalent
>> options to "git rm" alone does not solve that issue.
>
> FWIW I do use git clean a _lot_. I don't mind if it's doable from
> another kind of command, but I do use git clean and even git clean -x a
> lot, because it achives cleansing my repository faster (and sometimes
> faster) than a `make distclean` would do.
>
I'm of two minds about this. On the one hand, it's incredibly useful to
clear out an imported repository where distlcean doesn't quite distclean.
We also use it for our autobuild tools (although that's just us being lazy).
On the other hand, I've been bit by the brain-bug once and done a git clean
when I really meant make clean.
Changing it to the wimpy 'rm -i' equivalent would reduce risk substantially
while maintaining its usefulness, so +1 to Junio's patch, I guess.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Andreas Ericsson @ 2007-11-02 9:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org>
Linus Torvalds wrote:
>
> On Wed, 31 Oct 2007, Junio C Hamano wrote:
>> * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
>> + ...
>>
>> It appears 1.5.4 will be, to a certain extent, a "Let's clean up
>> the internal implementation" release. This series should become
>> part of it. Hopefully will merge to 'master' soon, but I
>> haven't looked this series very closely yet.
>
> I certainly think this should go in, but it does make one deficiency
> painfully clear: the remaining shell scripts end up having all the old
> flags behaviour.
>
> So while you can combine flags for *most* programs, you still won't
> be able to say things like
>
> git clean -qdx
>
> just because that's still a shellscript, and doing any fancy argument
> parsing in shell is just painful.
>
> Is somebody still working on doing the shell->C conversion?
>
Me, although my git work is happening with the speed of continental drift
at the moment.
git-merge and git-pull are (slowly) being converted. It's more in the
nature of a learning experience for me than "oh shit I need this fast"
though. Hence the blazing speed with which I work ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Implement git commit as a builtin command.
From: Junio C Hamano @ 2007-11-02 9:37 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Jakub Narebski, git
In-Reply-To: <20071102092720.GA30468@diana.vm.bytemark.co.uk>
Karl Hasselström <kha@treskal.com> writes:
> On 2007-11-01 21:14:45 +0100, Jakub Narebski wrote:
>
>> Kristian H?gsberg wrote:
>>
>> > Move git-commit.sh to contrib/examples.
>>
>> Just a note: you might want to use "git format-patch -M".
>
> I wonder if it would be such a bad idea to make this the default. It
> seems like _everyone_ who should be using it forget it. And the number
> of patches made for human or git consumption is probably vastly larger
> than the number of patches made for consumption by other tools.
On this mailing list, we can pretty much assume that renaming
diff can be applied by people. But outside world is a different
story.
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Mike Hommey @ 2007-11-02 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Blake Ramsdell, git
In-Reply-To: <7v4pg55893.fsf@gitster.siamese.dyndns.org>
On Fri, Nov 02, 2007 at 02:03:52AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Blake Ramsdell <blaker@gmail.com> writes:
>
> > Signed-off-by: Blake Ramsdell <blaker@gmail.com>
> > ---
> > Makefile | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 71479a2..5d83756 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -401,7 +401,9 @@ endif
> > ifeq ($(uname_S),Darwin)
> > NEEDS_SSL_WITH_CRYPTO = YesPlease
> > NEEDS_LIBICONV = YesPlease
> > - OLD_ICONV = UnfortunatelyYes
> > + ifneq ($(uname_R),9.0.0)
> > + OLD_ICONV = UnfortunatelyYes
> > + endif
> > NO_STRLCPY = YesPlease
> > NO_MEMMEM = YesPlease
> > endif
>
> I do not have an access to a Darwin box, but do you mean 10.5
> gives 9.0.0 as uname_R?
Be it that or not, it looks wrong to me to check the Darwin version to
know what to use. Do you rely on the Linux kernel version to know whether
iconv is present ?
Mike
^ permalink raw reply
* Re: [PATCH] Implement git commit as a builtin command.
From: Karl Hasselström @ 2007-11-02 9:27 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fgdc3m$miq$1@ger.gmane.org>
On 2007-11-01 21:14:45 +0100, Jakub Narebski wrote:
> Kristian H?gsberg wrote:
>
> > Move git-commit.sh to contrib/examples.
>
> Just a note: you might want to use "git format-patch -M".
I wonder if it would be such a bad idea to make this the default. It
seems like _everyone_ who should be using it forget it. And the number
of patches made for human or git consumption is probably vastly larger
than the number of patches made for consumption by other tools.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: stg branch --create test v2.6.24-rc1 doesn't work
From: Catalin Marinas @ 2007-11-02 9:24 UTC (permalink / raw)
To: Aneesh Kumar; +Cc: kha, Git Mailing List
In-Reply-To: <cc723f590710260342t5fd0bdc3nc1ea5198cea1a604@mail.gmail.com>
On 26/10/2007, Aneesh Kumar <aneesh.kumar@gmail.com> wrote:
> $ stg branch --create test v2.6.24-rc1
> Checking for changes in the working directory ... done
> Don't know how to determine parent branch from "v2.6.24-rc1"
> Branch "test" created
[...]
> [test@linux-review-ext]$ stg import
> /home/opensource/patches/ext4-patch-queue/ext4_mballoc_freespace_accounting_fix.patch
> Checking for changes in the working directory ... done
> fatal: cebdeed27b068dcc3e7c311d7ec0d9c33b5138c2 is not a valid 'commit' object
> stg import: git-commit-tree failed with code 128
The problem is that a tag id is used as the head of the stack rather
than the corresponding commit id. I modified StGIT to get the commit
id (and, as I said, you can work around this in the meantime by
passing "v2.6.24-rc1^{commit}" to the branch command).
I'll push the changes tonight but I have to solve the branch deletion
as it is left in an inconsistent state after import (and --force
should be able to deal with it but it doesn't).
--
Catalin
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Blake Ramsdell @ 2007-11-02 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4pg55893.fsf@gitster.siamese.dyndns.org>
On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> I do not have an access to a Darwin box, but do you mean 10.5
> gives 9.0.0 as uname_R?
Yeah, apparently that's how they roll.
~/Source/OpenSource/git$ uname -r
9.0.0
~/Source/OpenSource/git$ system_profiler SPSoftwareDataType
Software:
System Software Overview:
System Version: Mac OS X 10.5 (9A581)
Kernel Version: Darwin 9.0.0
Blake
--
Blake Ramsdell | http://www.blakeramsdell.com
^ permalink raw reply
* [PATCH] Mention that git-branch -M can cause problems for tracking branches
From: Jonas Fonseca @ 2007-11-02 9:17 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-branch.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
I made a patch to discard the overwritten branch's configuration
section, which Spearce felt was too lossy a behaviour. However, since
it confused me, I think it should at least be mentioned in the manpage.
Maybe the warning message from git should also be added to improve its
"googlability".
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 5e81aa4..def4e85 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -165,6 +165,11 @@ If you are creating a branch that you want to immediately checkout, it's
easier to use the git checkout command with its `-b` option to create
a branch and check it out with a single command.
+When a branch is renamed so that it overwrites an existing branch unintended
+problems can arise. This is because git refuses to discard the configuration
+section of the overwritten branch. As a result git can become confused if, for
+example, the branches involved were used for tracking two different remote
+branches. The only way to fix this is to edit the configuration file manually.
Author
------
--
1.5.3.4.1481.g854da-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Remove escaping of '|' in manpage option sections
From: Jonas Fonseca @ 2007-11-02 9:10 UTC (permalink / raw)
To: git, Junio C Hamano
The escaped were ending up verbatim in the generated documentation.
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
Documentation/git-filter-branch.txt | 2 +-
Documentation/git-stripspace.txt | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-branch.txt
index ba9b4fb..37b6fb8 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -152,7 +152,7 @@ definition impossible to preserve signatures at any rate.)
does this in the '.git-rewrite/' directory but you can override
that choice by this parameter.
--f\|--force::
+-f|--force::
`git filter-branch` refuses to start with an existing temporary
directory or when there are already refs starting with
'refs/original/', unless forced.
diff --git a/Documentation/git-stripspace.txt b/Documentation/git-stripspace.txt
index 5212358..f80526b 100644
--- a/Documentation/git-stripspace.txt
+++ b/Documentation/git-stripspace.txt
@@ -16,7 +16,7 @@ Remove multiple empty lines, and empty lines at beginning and end.
OPTIONS
-------
--s\|--strip-comments::
+-s|--strip-comments::
In addition to empty lines, also strip lines starting with '#'.
<stream>::
--
1.5.3.4.1481.g854da-dirty
--
Jonas Fonseca
^ permalink raw reply related
* [PATCH] Allow git-instaweb to be run from bare repositories
From: Jonas Fonseca @ 2007-11-02 9:09 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
---
git-instaweb.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
On IRC yesterday, two were asking for this and it seems simply enough.
Apparently, git-instaweb is a great way to see if you've set up a
remote repository correctly.
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 95c3e5a..14917ac 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -6,6 +6,7 @@ USAGE='[--start] [--stop] [--restart]
[--local] [--httpd=<httpd>] [--port=<port>] [--browser=<browser>]
[--module-path=<path> (for Apache2 only)]'
+SUBDIRECTORY_OK=Yes
. git-sh-setup
fqgitdir="$GIT_DIR"
--
1.5.3.4.1481.g854da-dirty
--
Jonas Fonseca
^ permalink raw reply related
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Junio C Hamano @ 2007-11-02 9:03 UTC (permalink / raw)
To: Blake Ramsdell; +Cc: gitster, git
In-Reply-To: <1193971102-61907-1-git-send-email-blaker@gmail.com>
Blake Ramsdell <blaker@gmail.com> writes:
> Signed-off-by: Blake Ramsdell <blaker@gmail.com>
> ---
> Makefile | 4 +++-
> 1 files changed, 3 insertions(+), 1 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 71479a2..5d83756 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -401,7 +401,9 @@ endif
> ifeq ($(uname_S),Darwin)
> NEEDS_SSL_WITH_CRYPTO = YesPlease
> NEEDS_LIBICONV = YesPlease
> - OLD_ICONV = UnfortunatelyYes
> + ifneq ($(uname_R),9.0.0)
> + OLD_ICONV = UnfortunatelyYes
> + endif
> NO_STRLCPY = YesPlease
> NO_MEMMEM = YesPlease
> endif
I do not have an access to a Darwin box, but do you mean 10.5
gives 9.0.0 as uname_R?
^ permalink raw reply
* Re: [PATCH] Make git-mailinfo strip whitespace from the start of the mail file.
From: Junio C Hamano @ 2007-11-02 8:53 UTC (permalink / raw)
To: Simon Sasburg; +Cc: git, gitster
In-Reply-To: <1193951139-2312-1-git-send-email-Simon.Sasburg@gmail.com>
Simon Sasburg <simon.sasburg@gmail.com> writes:
> @@ -935,6 +936,11 @@ static int mailinfo(FILE *in, FILE *out, int ks, const char *encoding,
> p_hdr_data = xcalloc(MAX_HDR_PARSED, sizeof(char *));
> s_hdr_data = xcalloc(MAX_HDR_PARSED, sizeof(char *));
>
> + do {
> + peek = fgetc(in);
> + } while (peek == ' ' || peek == '\r' || peek == '\n');
> + ungetc(peek, in);
> +
I wonder why this is not using isspace(peek).
^ permalink raw reply
* Re: [PATCH] post-update hook: update working copy
From: Junio C Hamano @ 2007-11-02 8:49 UTC (permalink / raw)
To: Sam Vilain; +Cc: Sam Vilain, git
In-Reply-To: <472A9B26.2020608@vilain.net>
Sam Vilain <sam@vilain.net> writes:
> changes as you suggested are below;
I squashed these and looked the result over, but I see it is
contradicting with itself. You do not want to "publish" a live
git repository so running git-update-server-info in a repository
that is served by this script feels very wrong.
How about having this in contrib/hooks/post-update-worktre?
By the way, there are quite a few careless places that use shell
variables without quoting.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Pierre Habouzit @ 2007-11-02 8:42 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Petr Baudis, git
In-Reply-To: <200711020828.30969.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1421 bytes --]
On Fri, Nov 02, 2007 at 07:28:30AM +0000, Jakub Narebski wrote:
> Jakub Narebski wrote:
> > Petr Baudis wrote:
> > > On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:
> >
> > >> Is 'getopts' bash-ism, or is it in POSIX?
> > >
> > > http://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html
> > >
> > > (Also, most modern distributions have manpage section 1p (3p, ...) with
> > > the same contents, so you can check for this stuff pretty easily.)
> >
> > Thanks.
> >
> > I have just realized however that it doesn't help any (option parser
> > not only for C builtin, but also for shell scripts, Perl scripts and
> > Python scripts). First, we (the git development community) do not
> > consider fact that something is in POSIX as indicator that we can use
> > the construct. Second, getopts delas IIRC only with _short_ options.
>
> Just a thought:
> http://www.systhread.net/texts/200704optparse.php
Well, I'm sure we could probably do the same with our own `git-parseopt`
tool, couldn't we ?
I'll try to give it a shot, and it'll have all the features shell-script
currently have at great costs of code length (like the lazy way to type
long options: -q|--q|--qu|--qui|...)
--
·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: [PATCH] gc: use parse_options
From: Pierre Habouzit @ 2007-11-02 8:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James Bowes, git
In-Reply-To: <7vhck579pm.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1497 bytes --]
On Fri, Nov 02, 2007 at 12:49:25AM +0000, Junio C Hamano wrote:
> James Bowes <jbowes@dangerouslyinc.com> writes:
>
> > + struct option builtin_gc_options[] = {
> > + OPT_BOOLEAN(0, "prune", &prune, "prune unused objects"),
>
> I would write "unreferenced loose" instead of "unused" here...
>
> > + OPT_BOOLEAN(0, "aggressive", &aggressive, "be more thorough (increased runtime)"),
> > + OPT_BOOLEAN(0, "auto", &auto_gc, "enable auto-gc mode"),
> > + OPT_END()
> > + };
> > +
> > git_config(gc_config);
> >
> > if (pack_refs < 0)
> > pack_refs = !is_bare_repository();
> >
> > + parse_options(argc, argv, builtin_gc_options, builtin_gc_usage, 0);
> > +
> > + if (aggressive) {
> > + append_option(argv_repack, "-f", MAX_ADD);
> > + if (aggressive_window > 0) {
> > + sprintf(buf, "--window=%d", aggressive_window);
> > + append_option(argv_repack, buf, MAX_ADD);
> > }
> > }
> > - if (i != argc)
> > - usage(builtin_gc_usage);
>
> Now, what makes the command report error when the user says:
>
> $ git gc unwanted parameter
the commands works fine, because no additionnal checks were made. To
"fix" this, that should be done:
argc = parse_options(argc, argv, builtin_gc_options, builtin_gc_usage, 0);
if (argc)
usage_with_options(......);
--
·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: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Wincent Colaiuta @ 2007-11-02 8:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git
In-Reply-To: <7vlk9jgeee.fsf@gitster.siamese.dyndns.org>
El 31/10/2007, a las 22:31, Junio C Hamano escribió:
> Wrong. push is a mirror of fetch and does not do _any_
> integration. It is just a safe (because it insists on
> fast-forward) propagation mechanism. Your integration still
> happens with pull (actually, shared repository people seem to
> prefer "fetch + rebase" over "pull" which is "fetch + merge").
Of course, it's too late too change now, but it would be nice if the
mirror of "fetch" were "send". (I know it's been commented in the past
that the fact that "push" and "pull" aren't mirror operations has
surprised quite a few people.)
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-11-02 7:52 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Andreas Ericsson, git
In-Reply-To: <63FCD695-B952-4624-854C-0F1C662D94D1@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Nov 1, 2007, at 9:18 PM, Junio C Hamano wrote:
>
>> The context of this "forced" is that you say (in the following
>> paragraph) the user's main objective was to "push", but I do not
>> think "to push" is ever the main objective.
>
> Right. I should probably describe a bit more of the context.
Boring ;-)
> We have a shared branch for a group of developer who are located
> ...
> In this setting a user really want to push. Because only then
> the code will be tested and available for all others. ...
Pretty much expected, sane, and unsurprising. Then you are in
the first category I quoted, and...
>> - If it is to give integrated result for others to work further
>> on, then you need to resolve before being able to achieve
>> that goal. There is no escaping from it.
... it still holds that what the developer wants to do is not
just "to push", but "to push after making sure what he is going
to push is in a good enough shape to be pushed". Your _workflow_
is forcing to integrate right away before pushing; don't blame
git for this.
>> - On the other hand, if it is to show what you did as early as
>> possible in a working shape, and if the updated shared
>> repository has changes from somebody else that conflicts you,
>> in a CVS/SVN style shared workflow, there is no way for you
>> to show what you did in isolation. If you try to follow that
>> model in git and insist pushing to the same branch, then you
>> are forced to resolve first.
>>
>> But you do not have to. You could push out to another new
>> branch, and say "Here is how you could do it, although this
>> is based on an older codebase and conflicts with what
>> recently happened to the tip". You could even ask other
>> party whose changes conflict with yours to help with the
>> merge by saying "I pushed it out, you are more familiar with
>> that area of the code and with your changes near the tip of
>> the trunk, so could you merge it and push out the result?"
>
> ... I know we could use git to establish a more complex workflow
> that would give better guarantees on the published branches.
Don't get me wrong. You do not always have to use the "push to
a side branch and ask for help from others", but git opens the
door for you to do so more conveniently, rather than strictly
sticking to the CVS workflow. I re-quoted the whole "On the
other hand" part because I think this is something not often
done by people with CVS background --- with CVS you can do
exactly the same thing but it is too cumbersome and people don't
do so in practice. With git, such an interaction is not just
possible but is a very natural thing to do.
Your more advanced people can be the first ones to employ this
"new communication medium" to help work better among them. You
do not have to force the "side communication" as an official
part of workflow to the whole group.
SCM is just a tool to help developer communication. Use it
wisely.
> We haven't figured out much more of our workflow. The first
> milestone is to migrate from CVS to git continuing to use a
> CVS-style workflow.
I think that is an interesting admission. As somebody else on
the thread already said, if you are sticking to CVS workflow,
there are things that can and cannot be naturally done with
git. Don't break git when you hit the situation in the latter
category without understanding how the world works.
> error: remote 'refs/heads/master' is ahead of local 'refs/heads/
> master'. Use --verbose for more details.
I'd rather have "Read section XXX of the user's guide".
^ permalink raw reply
* [PATCH 2/2] git-diff: complain about >=8 consecutive spaces in initial indent
From: Junio C Hamano @ 2007-11-02 7:38 UTC (permalink / raw)
To: git; +Cc: Brian Downing
In-Reply-To: <7vwst15ceq.fsf@gitster.siamese.dyndns.org>
This introduces a new whitespace error type, "indent-with-non-tab".
The error is about starting a line with 8 or more SP, instead of
indenting it with a HT.
This is not enabled by default, as some projects employ an
indenting policy to use only SPs and no HTs.
The kernel folks and git contributors may want to enable this
detection with:
[core]
whitespace = indent-with-non-tab
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* Obviously, it is too late at night for me to do the same for
git-apply, but it's Ok as I know there are capable interested
parties on the list. Hint, hint...
cache.h | 1 +
config.c | 1 +
diff.c | 14 ++++++++++++--
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/cache.h b/cache.h
index a6e5988..3f42827 100644
--- a/cache.h
+++ b/cache.h
@@ -608,6 +608,7 @@ void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, i
*/
#define WS_TRAILING_SPACE 01
#define WS_SPACE_BEFORE_TAB 02
+#define WS_INDENT_WITH_NON_TAB 04
#define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB)
extern unsigned whitespace_rule;
diff --git a/config.c b/config.c
index ffb418c..d5b9766 100644
--- a/config.c
+++ b/config.c
@@ -252,6 +252,7 @@ static struct whitespace_rule {
} whitespace_rule_names[] = {
{ "trailing-space", WS_TRAILING_SPACE },
{ "space-before-tab", WS_SPACE_BEFORE_TAB },
+ { "indent-with-non-tab", WS_INDENT_WITH_NON_TAB },
};
static unsigned parse_whitespace_rule(const char *string)
diff --git a/diff.c b/diff.c
index 2112353..6bb902f 100644
--- a/diff.c
+++ b/diff.c
@@ -502,8 +502,11 @@ static void emit_line_with_ws(int nparents,
int i;
int tail = len;
int need_highlight_leading_space = 0;
- /* The line is a newly added line. Does it have funny leading
- * whitespaces? In indent, SP should never precede a TAB.
+ /*
+ * The line is a newly added line. Does it have funny leading
+ * whitespaces? In indent, SP should never precede a TAB. In
+ * addition, under "indent with non tab" rule, there should not
+ * be more than 8 consecutive spaces.
*/
for (i = col0; i < len; i++) {
if (line[i] == '\t') {
@@ -517,6 +520,13 @@ static void emit_line_with_ws(int nparents,
else
break;
}
+ if ((whitespace_rule & WS_INDENT_WITH_NON_TAB) &&
+ 0 <= last_space_in_indent &&
+ last_tab_in_indent < 0 &&
+ 8 <= (i - col0)) {
+ last_tab_in_indent = i;
+ need_highlight_leading_space = 1;
+ }
fputs(set, stdout);
fwrite(line, col0, 1, stdout);
fputs(reset, stdout);
--
1.5.3.5.1452.ga93d
^ permalink raw reply related
* [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: Junio C Hamano @ 2007-11-02 7:34 UTC (permalink / raw)
To: git; +Cc: Brian Downing
This introduces core.whitespace configuration variable that lets
you specify the definition of "whitespace error".
Currently there are two kinds of whitespace errors defined:
* trailing-space: trailing whitespaces at the end of the line.
* space-before-tab: a SP appears immediately before HT in the
indent part of the line.
You can specify the desired types of errors to be detected by
listing their names (unique abbreviations are accepted)
separated by comma. By default, these two errors are always
detected, as that is the traditional behaviour. You can disable
detection of a particular type of error by prefixing a '-' in
front of the name of the error, like this:
[core]
whitespace = -trailing-space
This patch teaches the code to output colored diff with
DIFF_WHITESPACE color to highlight the detected whitespace
errors to honor the new configuration.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
cache.h | 9 +++++++++
config.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++
diff.c | 13 ++++++++-----
environment.c | 1 +
4 files changed, 70 insertions(+), 5 deletions(-)
diff --git a/cache.h b/cache.h
index bfffa05..a6e5988 100644
--- a/cache.h
+++ b/cache.h
@@ -602,4 +602,13 @@ extern int diff_auto_refresh_index;
/* match-trees.c */
void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
+/*
+ * whitespace rules.
+ * used by both diff and apply
+ */
+#define WS_TRAILING_SPACE 01
+#define WS_SPACE_BEFORE_TAB 02
+#define WS_DEFAULT_RULE (WS_TRAILING_SPACE|WS_SPACE_BEFORE_TAB)
+extern unsigned whitespace_rule;
+
#endif /* CACHE_H */
diff --git a/config.c b/config.c
index dc3148d..ffb418c 100644
--- a/config.c
+++ b/config.c
@@ -246,6 +246,53 @@ static unsigned long get_unit_factor(const char *end)
die("unknown unit: '%s'", end);
}
+static struct whitespace_rule {
+ const char *rule_name;
+ unsigned rule_bits;
+} whitespace_rule_names[] = {
+ { "trailing-space", WS_TRAILING_SPACE },
+ { "space-before-tab", WS_SPACE_BEFORE_TAB },
+};
+
+static unsigned parse_whitespace_rule(const char *string)
+{
+ unsigned rule = WS_DEFAULT_RULE;
+
+ while (string) {
+ int i;
+ size_t len;
+ const char *ep;
+ int negated = 0;
+
+ string = string + strspn(string, ", \t\n\r");
+ ep = strchr(string, ',');
+ if (!ep)
+ len = strlen(string);
+ else
+ len = ep - string;
+
+ if (*string == '-') {
+ negated = 1;
+ string++;
+ len--;
+ }
+ if (!len)
+ break;
+ for (i = 0; i < ARRAY_SIZE(whitespace_rule_names); i++) {
+ if (strncmp(whitespace_rule_names[i].rule_name,
+ string, len))
+ continue;
+ if (negated)
+ rule &= ~whitespace_rule_names[i].rule_bits;
+ else
+ rule |= whitespace_rule_names[i].rule_bits;
+ break;
+ }
+ string = ep;
+ }
+ return rule;
+}
+
int git_parse_long(const char *value, long *ret)
{
if (value && *value) {
@@ -431,6 +478,11 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.whitespace")) {
+ whitespace_rule = parse_whitespace_rule(value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/diff.c b/diff.c
index a6aaaf7..2112353 100644
--- a/diff.c
+++ b/diff.c
@@ -508,7 +508,8 @@ static void emit_line_with_ws(int nparents,
for (i = col0; i < len; i++) {
if (line[i] == '\t') {
last_tab_in_indent = i;
- if (0 <= last_space_in_indent)
+ if ((whitespace_rule & WS_SPACE_BEFORE_TAB) &&
+ 0 <= last_space_in_indent)
need_highlight_leading_space = 1;
}
else if (line[i] == ' ')
@@ -540,10 +541,12 @@ static void emit_line_with_ws(int nparents,
tail = len - 1;
if (line[tail] == '\n' && i < tail)
tail--;
- while (i < tail) {
- if (!isspace(line[tail]))
- break;
- tail--;
+ if (whitespace_rule & WS_TRAILING_SPACE) {
+ while (i < tail) {
+ if (!isspace(line[tail]))
+ break;
+ tail--;
+ }
}
if ((i < tail && line[tail + 1] != '\n')) {
/* This has whitespace between tail+1..len */
diff --git a/environment.c b/environment.c
index b5a6c69..624dd96 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,7 @@ int pager_in_use;
int pager_use_color = 1;
char *editor_program;
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
+unsigned whitespace_rule = WS_DEFAULT_RULE;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
--
1.5.3.5.1452.ga93d
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-02 7:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <200711020825.23464.jnareb@gmail.com>
Jakub Narebski wrote:
> Petr Baudis wrote:
> > On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:
>
> >> Is 'getopts' bash-ism, or is it in POSIX?
> >
> > http://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html
> >
> > (Also, most modern distributions have manpage section 1p (3p, ...) with
> > the same contents, so you can check for this stuff pretty easily.)
>
> Thanks.
>
> I have just realized however that it doesn't help any (option parser
> not only for C builtin, but also for shell scripts, Perl scripts and
> Python scripts). First, we (the git development community) do not
> consider fact that something is in POSIX as indicator that we can use
> the construct. Second, getopts delas IIRC only with _short_ options.
Just a thought:
http://www.systhread.net/texts/200704optparse.php
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2007-11-02 7:25 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20071102022335.GU18279@machine.or.cz>
Petr Baudis napisał:
> On Fri, Nov 02, 2007 at 01:04:03AM +0100, Jakub Narebski wrote:
>> Is 'getopts' bash-ism, or is it in POSIX?
>
> http://www.opengroup.org/onlinepubs/009695399/utilities/getopts.html
>
> (Also, most modern distributions have manpage section 1p (3p, ...) with
> the same contents, so you can check for this stuff pretty easily.)
Thanks.
I have just realized however that it doesn't help any (option parser
not only for C builtin, but also for shell scripts, Perl scripts and
Python scripts). First, we (the git development community) do not
consider fact that something is in POSIX as indicator that we can use
the construct. Second, getopts delas IIRC only with _short_ options.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-02 7:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7vfxzpbtxv.fsf@gitster.siamese.dyndns.org>
On Nov 1, 2007, at 9:18 PM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>>
>>> Steffen Prohaska wrote:
>>>
>>>> You're forced to do the integration immediately.
>
> The context of this "forced" is that you say (in the following
> paragraph) the user's main objective was to "push", but I do not
> think "to push" is ever the main objective.
Right. I should probably describe a bit more of the context.
We have a shared branch for a group of developer who are located
in the same building. We are allowed to commit reasonably stable
code to this branch. Changes should compile and the commiter
should be convinced that it does something useful without
breaking other code. But failing to meet these requirements
is acceptable. For example it is sufficient to compile on
only one architecture and have good reason to believe that
the other architectures will work, too.
A nightly job builds the shared branch on all of our
architectures and creates a report that is available the next
day. If problems happen you should fix them asap. If someone
spots problems causes by others that need to be addressed
right away, he can walk over to the office of the one who
caused the problem.
In this setting a user really want to push. Because only then
the code will be tested and available for all others. ...
> - If it is to give integrated result for others to work further
> on, then you need to resolve before being able to achieve
> that goal. There is no escaping from it.
>
> - On the other hand, if it is to show what you did as early as
> possible in a working shape, and if the updated shared
> repository has changes from somebody else that conflicts you,
> in a CVS/SVN style shared workflow, there is no way for you
> to show what you did in isolation. If you try to follow that
> model in git and insist pushing to the same branch, then you
> are forced to resolve first.
>
> But you do not have to. You could push out to another new
> branch, and say "Here is how you could do it, although this
> is based on an older codebase and conflicts with what
> recently happened to the tip". You could even ask other
> party whose changes conflict with yours to help with the
> merge by saying "I pushed it out, you are more familiar with
> that area of the code and with your changes near the tip of
> the trunk, so could you merge it and push out the result?"
... I know we could use git to establish a more complex workflow
that would give better guarantees on the published branches.
But it's a judgement how much complexity you want to
add. Pushing to a different branch instead of solving
conflicts right away may be a good model to postpone conflict
resolution. But it requires more knowledge of git and more
commands. Right now, the users are trained on a CVS workflow
and they expect that conflicts may occur and if so need to
be addressed right away. The next step is probably to learn
how git could help them to do this. (index vs. work tree,
mergetool, ...)
Btw, I have another 'stable' branch, which I have full control
over. This branch is built and tested prior to pushing to the
public repository. So, if the shared branch completely breaks
down, we can fall-back to the stable branch.
We haven't figured out much more of our workflow. The first
milestone is to migrate from CVS to git continuing to use a
CVS-style workflow.
>>> Yes, but you get to choose how. Perhaps git-push should list more
>>> options than just git-pull, such as the three commands required to
>>> rebase the currently checked out branch onto its remote counterpart.
>>> That would support more workflows.
>>
>> I agree. Providing better hints would be good.
>
> I am not so sure about that. If there are three different
> workflows, should git-push give hints suitable for all of them?
>
> The current hint was added in response to users' requests, and I
> think it could be generalized. What we would want the end user
> to realize is:
>
> What I tried to push out is stale, I do not want to push out
> something that does not contain what the other side has
> done, so I need to integrate my work with what the other
> side have before pushing to that branch at the remote.
>
> In my workflow, that means doing rebase of the branch I
> tried to push out on top of the remote branch I was trying
> to push to.
>
> The second paragraph depends on the workflow. Do we want to
> (can we afford the space to) give a laundry list here? Probably
> not.
I agree.
But how many different ways of integrating do we have? I only know
of merge or rebase. So, we may just mention both.
Or we only print an extended message if '--verbose' is given. The
short message could be even shorter and refer to '--verbose':
error: remote 'refs/heads/master' is ahead of local 'refs/heads/
master'. Use --verbose for more details.
If the user passes --verbose he gets the full story:
- A more detailed description of 'ahead'. For example,
local could be a strict subset of remote, or local could have
new commits that are not already at remote.
- We could give all sorts of hints, for example how to list the
commits that are new on the local side. Recommendations how to
solve the issue (merge, rebase). The message shouldn't get
too verbose, though.
>>>> Your main objective was to push, but the shared workflow forces
>>>> you to do the integration _now_ (by using pull). In a pull-only
>>>> workflow, you can just push and defer the integration for later.
>>>
>>> No, you can also fetch + rebase.
>>
>> Right. My point was than one cannot defer the integration. It
>> must be addressed immediately.
>
> See above.
See above.
>>>> Some people claim fetch + rebase is superior to fetch + merge.
>>>> The only point I can see is that fetch + rebase gives a linear
>>>> history without loops, which is nicer to visualize. I recently
>>>> asked on the list if there are any benefits of fetch + rebase
>>>> over fetch + merge, besides a nicer visualization.
>>>
>>>
>>> It's easier to bisect...
>>> With a mostly linear history, this problem goes away.
>>
>> This is really an interesting point. I did not start to use
>> git bisect regularly. But I certainly plan to do so in the future.
>>
>> Couldn't bisect learn to better cope with non-linear history?
>
> It copes with it as best as it can.
I should try out git bisect to understand the details.
> Another thing to think about is how "everybody fetches, merges
> and pushes out" would interact with the concept of "mainline".
> Strictly speaking, the point of distributed development is that
> there is no mainline, but workflows based on "fetch + rebase"
> allows --first-parent to give a reasonable approximation of what
> people would naively expect how the mainline would look like.
> If everybody fetches, merges and pushes out, there is no
> "mainline" and --first-parent would give totally useless
> history.
Building a main line needs more control and more knowledge
about git.
Here is what I think can be done. It's only a sketch so
far. It's not yet reality. Therefore it might turn out to be
infeasible. I'd adjust my plans then.
We actually have at least three groups of developers that work
at three different locations. They'll work on different shared
branches. We also will create shared topic branches if a smaller
group of developers needs to work together on a prototype.
At some point shared branches need to become stable. They
need to be tested and maybe some of the changes need to be
reverted if they turn out to be useless. Finally we'll have a
tip of a shared branch that is stable. Stable depends on the
quality criteria, which may vary depending on where we are
in the release cycle. But at least some minimal requirements,
like "compiles on all platforms" or "passes all tests" will be
verified. Such a stable tip will now be merged with '--no-ff'
to the mainline. The merge will be thoroughly tested.
The chain of commits along first parent establishes a mainline
that matches certain quality criteria. The criteria are not
necessarily met by commits on the side branches. Therefore
fast-forward must not be used for the merge.
If we feel comfortable with git, we may consider creating
better topic branches in the first place. But for now I want
to start with shared branches containing a mixed bag of
commits.
Do all this make sense?
Steffen
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Miles Bader @ 2007-11-02 6:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.999.0711011129460.3342@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> So while you can combine flags for *most* programs, you still won't
> be able to say things like
>
> git clean -qdx
>
> just because that's still a shellscript, and doing any fancy argument
> parsing in shell is just painful.
Indeed... but for my personal shell scripts I like to use a construct
like the following for parsing args:
while :; do
case "$1" in
... lots of cases to handle normal args ...
-[!-]?*)
# split concatenated single-letter options apart
FIRST="$1"; shift
set -- `echo $FIRST | $SED 's/-\(.\)\(.*\)/-\1 -\2/'` "$@"
;;
-*)
# unrecognized option
unrec_opt "$1"; exit 1;;
*)
# non-option
break;
esac
done
I'm sure there are problems with it, but it generally seems to work
pretty reasonably for short options.
-Miles
--
97% of everything is grunge
^ 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