* Re: stgit: cleaning up after using git branch delete commands
From: Jon Smirl @ 2007-11-07 16:11 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Git Mailing List
In-Reply-To: <tnxwssuyug1.fsf@pc1117.cambridge.arm.com>
On 11/7/07, Catalin Marinas <catalin.marinas@arm.com> wrote:
> "Jon Smirl" <jonsmirl@gmail.com> wrote:
> > I've used git commands to delete several branches that had stgit
> > active on it. Doing that has left a bunch of clutter in the .git
> > directory. Is there a stgit command to remove all the clutter from
> > branches that no longer exist? I'd like to use the branch names again
> > but the clutter is interfering.
>
> You can create the branch back with GIT and run "stg branch --delete
> --force", though I don't guarantee it will work (BTW, I only recently
> relaxed the branch deletion rules in StGIT so that it doesn't complain
> of missing files and completes the operation, so you should use the
> latest HEAD).
how about a 'stg gc' command that gets rid of all the inaccessible clutter?
>
> --
> Catalin
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Nguyen Thai Ngoc Duy @ 2007-11-07 16:05 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Wildenhues, git
In-Reply-To: <fcaeb9bf0711070758w5832ab83ic16e8fb4edb80972@mail.gmail.com>
On 11/7/07, Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> On 11/7/07, Junio C Hamano <gitster@pobox.com> wrote:
> > [2/5] Gaah, AIX sed X-<. I am not opposed to this patch but
> > would want to get Yays from people with non GNU sed. Is
> > busybox sed good enough to grok our scripts these days?
> > Please ask help and collect Acks at least from folks on
> > Solaris, MacOS, FBSD, and OBSD.
>
> I haven't extensively used all the scripts. There seems to be no
> sed-related failure from git testsuite results in my git-box branch.
> So I would say for now it's good enough.
Argh, should have made it clear, busybox sed is good enough.
--
Duy
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Nguyen Thai Ngoc Duy @ 2007-11-07 15:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Wildenhues, git
In-Reply-To: <7v8x5bgl04.fsf@gitster.siamese.dyndns.org>
On 11/7/07, Junio C Hamano <gitster@pobox.com> wrote:
> [2/5] Gaah, AIX sed X-<. I am not opposed to this patch but
> would want to get Yays from people with non GNU sed. Is
> busybox sed good enough to grok our scripts these days?
> Please ask help and collect Acks at least from folks on
> Solaris, MacOS, FBSD, and OBSD.
I haven't extensively used all the scripts. There seems to be no
sed-related failure from git testsuite results in my git-box branch.
So I would say for now it's good enough.
--
Duy
^ permalink raw reply
* Re: git push refspec problem
From: Johannes Schindelin @ 2007-11-07 15:39 UTC (permalink / raw)
To: Johannes Gilger; +Cc: James, git
In-Reply-To: <4731D852.2080500@hackvalue.de>
Hi,
On Wed, 7 Nov 2007, Johannes Gilger wrote:
> Johannes Schindelin wrote:
>
> > On Wed, 7 Nov 2007, James wrote:
> >
> >> fetch = +refs/heads/*:refs/remotes/origin/*
> >
> > This is a refspec.
> >
> >> push = ssh://james@my.server.com/home/james/scm/git/project.git/
> >
> > This is a URL. It does not specify any refs. But "push =" expects a
> > URL.
>
> I think Johannes meant to say "But 'push =' expects a refspec." (the
> manpage even says so).
Of course. Thanks.
Ciao,
Dscho
^ permalink raw reply
* Re: git push refspec problem
From: Pierre Habouzit @ 2007-11-07 15:38 UTC (permalink / raw)
To: Johannes Gilger; +Cc: James, Johannes Schindelin, git
In-Reply-To: <4731D918.6040106@hackvalue.de>
[-- Attachment #1: Type: text/plain, Size: 751 bytes --]
On Wed, Nov 07, 2007 at 03:26:16PM +0000, Johannes Gilger wrote:
> James wrote:
> > There has to be *some* way of pulling through git and pushing through
> > ssh with a simple "git push". :-P I'm doing it manually, after all. I
> > could have sworn I've read how to do its somewhere but have since
> > forgotten.
>
> Would two remotes do the trick? One remote only has a fetch entry
> while the other one has a push entry.
Yes you can do that, but that means you have to spell out the remote
name either for fetching or pushing which somehow sucks :)
--
·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 0/5] some shell portability fixes
From: Johannes Schindelin @ 2007-11-07 15:37 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Ralf Wildenhues, Mike Hommey, Junio C Hamano, git
In-Reply-To: <e2b179460711070730w4ca95989y14872665ddc8bfca@mail.gmail.com>
Hi,
On Wed, 7 Nov 2007, Mike Ralphson wrote:
> On Nov 7, 2007 2:47 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > I am not sure if the GNU tools are installed in the same place on all
> > AIX boxen...
>
> Well let's say the patch would arrive earlier if it was based on the
> shipped Makefile rather than the unholy abomination that is
> autoconf... If the GNU tools have been installed via the IBM AIX
> Toolbox for Linux Applications[1] then they'll be installed in
> /opt/freeware/bin and /usr/linux/bin will be a set of symlinks to
> them.
I guess Makefile is the better place, then. You are the expert on AIX.
Ciao,
Dscho
^ permalink raw reply
* Re: git push refspec problem
From: James @ 2007-11-07 15:30 UTC (permalink / raw)
To: Johannes Gilger; +Cc: Johannes Schindelin, git
In-Reply-To: <4731D852.2080500@hackvalue.de>
On Nov 7, 2007, at 10:22 AM, Johannes Gilger wrote:
> Johannes Schindelin wrote:
>> Hi,
>>
>> On Wed, 7 Nov 2007, James wrote:
>>
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>
>> This is a refspec.
>>
>>> push = ssh://james@my.server.com/home/james/scm/git/project.git/
>>
>> This is a URL. It does not specify any refs. But "push =" expects
>> a URL.
>
> I think Johannes meant to say "But 'push =' expects a refspec." (the
> manpage even says so).
>
> About your problem: If you want to pull from a git:// repository and
> push to another with ssh:// (or in general when having two different
> repositories for pushing and fetching) in my novice understanding
> you would need two remotes. In your case, can't you just use your
> ssh-url for fetching as well?
>
> Regards,
> Jojo
I guess I could use my ssh url for pulling, as well. I simply figured
it would be easier to add an ssh URL for push (like I was doing
manually) and be done with it. But it doesn't seem there's a super
simple solution (i.e., my syntax was wrong in the config file) to
using git for pull and ssh for push.
.james
> --
> Johannes Gilger <heipei@hackvalue.de>
> http://hackvalue.de/heipei/
> GPG-Key: 0x42F6DE81
> GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Mike Ralphson @ 2007-11-07 15:30 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ralf Wildenhues, Mike Hommey, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711071446190.4362@racer.site>
On Nov 7, 2007 2:47 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > Equally GNU sed is available as a drop-in rpm for AIX. I wonder if it
> > would be worth adding Makefile support for a PATH prefix for the git
> > scripts, so they could prepend (in this case) something like
> > /opt/freeware/bin or /usr/linux/bin ?
> >
> > In our AIX environment many GNU tools are installed but I can't
> > guarantee they come first in the paths of the git users.
> >
> > I'm willing to work up a patch if there's any interest.
>
> Would that be a task for configure? Because I am not sure if the GNU
> tools are installed in the same place on all AIX boxen...
Well let's say the patch would arrive earlier if it was based on the
shipped Makefile rather than the unholy abomination that is
autoconf... If the GNU tools have been installed via the IBM AIX
Toolbox for Linux Applications[1] then they'll be installed in
/opt/freeware/bin and /usr/linux/bin will be a set of symlinks to
them.
That said, there may be 32/64bit differences and of course anyone
could have rolled their own sed, awk, diff, patch, grep, sort etc in
/usr/local/bin or anywhere else, and I'd guess this might be useful
for Solaris / HPUX users etc.
I was thinking along the lines of the existing $SHELL_PATH, i.e. a
build-time manually-set Makefile/environment variable. I'd also like
to be able to override gitexecdir in the same way without having my
builds marked dirty.
Cheers, Mike
[1] http://www-03.ibm.com/systems/p/os/aix/linux/download.html
^ permalink raw reply
* Re: git push refspec problem
From: Johannes Gilger @ 2007-11-07 15:26 UTC (permalink / raw)
To: James; +Cc: Pierre Habouzit, Johannes Schindelin, git
In-Reply-To: <EA230407-45F1-4F7E-8415-A43ECF940856@nc.rr.com>
James wrote:
> There has to be *some* way of pulling through git and pushing through
> ssh with a simple "git push". :-P I'm doing it manually, after all. I
> could have sworn I've read how to do its somewhere but have since
> forgotten.
Would two remotes do the trick? One remote only has a fetch entry
while the other one has a push entry.
Regards,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: git push refspec problem
From: James @ 2007-11-07 15:23 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Johannes Schindelin, git
In-Reply-To: <20071107152003.GL18057@artemis.corp>
On Nov 7, 2007, at 10:20 AM, Pierre Habouzit wrote:
> On Wed, Nov 07, 2007 at 03:11:46PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Wed, 7 Nov 2007, James wrote:
>>
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>
>> This is a refspec.
>>
>>> push = ssh://james@my.server.com/home/james/scm/git/project.git/
>>
>> This is a URL. It does not specify any refs. But "push =" expects
>> a URL.
>>
>> You probably want to setup a different remote if you want to push
>> to a
>> different URL than you are fetching from.
>
> Oh, there is no way to pull through git:// and push to ssh://
> perfectly knowint it's the same physical repository so that the fetch
> doesn't have the ssh-handhshake-overhead ?
There has to be *some* way of pulling through git and pushing through
ssh with a simple "git push". :-P I'm doing it manually, after all.
I could have sworn I've read how to do its somewhere but have since
forgotten.
> --
> ·O· Pierre Habouzit
> ··O madcoder@debian.org
> OOO http://www.madism.org
^ permalink raw reply
* Re: git push refspec problem
From: Johannes Gilger @ 2007-11-07 15:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: James, git
In-Reply-To: <Pine.LNX.4.64.0711071510480.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Wed, 7 Nov 2007, James wrote:
>
>> fetch = +refs/heads/*:refs/remotes/origin/*
>
> This is a refspec.
>
>> push = ssh://james@my.server.com/home/james/scm/git/project.git/
>
> This is a URL. It does not specify any refs. But "push =" expects a URL.
I think Johannes meant to say "But 'push =' expects a refspec." (the
manpage even says so).
About your problem: If you want to pull from a git:// repository and
push to another with ssh:// (or in general when having two different
repositories for pushing and fetching) in my novice understanding
you would need two remotes. In your case, can't you just use your
ssh-url for fetching as well?
Regards,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Yin Ping @ 2007-11-07 15:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsswjeom.fsf@gitster.siamese.dyndns.org>
On 11/6/07, Junio C Hamano <gitster@pobox.com> wrote:
> "Yin Ping" <pkufranky@gmail.com> writes:
>
> > However, in some cases these messages are helpful. And a third kind of
> > cases is that people care about only part of all submodules.
> >
> > So, maybe some an switch can be used to turn this on or off (default
> > off)?
>
> I personally think that is overengineering. Isn't having/not
> having the submodule directory cloned a good enough indicator
> of which submodules are interested in by the user?
>
Good suggestion. I'll give my new patch later.
--
franky
^ permalink raw reply
* Re: git push refspec problem
From: Pierre Habouzit @ 2007-11-07 15:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: James, git
In-Reply-To: <Pine.LNX.4.64.0711071510480.4362@racer.site>
[-- Attachment #1: Type: text/plain, Size: 853 bytes --]
On Wed, Nov 07, 2007 at 03:11:46PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 7 Nov 2007, James wrote:
>
> > fetch = +refs/heads/*:refs/remotes/origin/*
>
> This is a refspec.
>
> > push = ssh://james@my.server.com/home/james/scm/git/project.git/
>
> This is a URL. It does not specify any refs. But "push =" expects a URL.
>
> You probably want to setup a different remote if you want to push to a
> different URL than you are fetching from.
Oh, there is no way to pull through git:// and push to ssh://
perfectly knowint it's the same physical repository so that the fetch
doesn't have the ssh-handhshake-overhead ?
--
·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: [bug in next ?] git-fetch/git-push issue
From: Pierre Habouzit @ 2007-11-07 15:11 UTC (permalink / raw)
To: Nicolas Pitre, Daniel Barkalow, Jeff King, Git ML
In-Reply-To: <20071105175654.GD6205@artemis.corp>
[-- Attachment #1: Type: text/plain, Size: 872 bytes --]
oh and while we're at it, someone reminded me on IRC that when you:
git push origin :somebranch
it does not removes origin/somebranch from your branches. Now that git
push updates our knowledge of the remote branch, I believe that it
should also try to perform the equivalent of a:
git branch -r -d origin/somebranch
And to be fair, I'd also say that git fetch <some-remote> should
complain about remote heads that match <some-remote> refspec that have
no corresponding reference _on_ the remote so that the user knows that
the branches have been removed.
I wanted to write a patch about that long time ago, but my plate is
already full with the diff option things.
--
·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: git push refspec problem
From: Johannes Schindelin @ 2007-11-07 15:11 UTC (permalink / raw)
To: James; +Cc: git
In-Reply-To: <7B37E361-9606-447C-B853-001182688AFA@nc.rr.com>
Hi,
On Wed, 7 Nov 2007, James wrote:
> fetch = +refs/heads/*:refs/remotes/origin/*
This is a refspec.
> push = ssh://james@my.server.com/home/james/scm/git/project.git/
This is a URL. It does not specify any refs. But "push =" expects a URL.
You probably want to setup a different remote if you want to push to a
different URL than you are fetching from.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Johannes Schindelin @ 2007-11-07 15:04 UTC (permalink / raw)
To: Shawn Bohrer; +Cc: gitster, git
In-Reply-To: <20071107145434.GB6768@mediacenter.austin.rr.com>
Hi,
On Wed, 7 Nov 2007, Shawn Bohrer wrote:
> On Wed, Nov 07, 2007 at 11:10:45AM +0000, Johannes Schindelin wrote:
> >
> > you still have quite a number of instances where you wrap just one line
> > into curly brackets:
> >
> > if (bla) {
> > [just one line]
> > }
>
> Crap. OK I count one instance unless you count:
>
> if (foo) {
> one_line();
> } else if (bar) {
> one_line();
> two_lines();
> } else {
> something_else();
> }
I do count them. Personally, I find it highly distracting and ugly.
Besides, we have the convention of putting the "}" not into the same line
as "else". (See keyword "uncuddling" in the list archives.)
While it may be true that some parts of the code follow these rules less
strictly, it does not mean that we should introduce more of that kind.
BTW there are plenty of examples in the existing code which illustrate our
implicit coding conventions.
> Now I suppose I can get rid of the curly braces here as well but I
> personally find that strange and ugly. So is there an official
> guideline on if else statements?
Not yet ;-) I can add it to the tentative v3 of Documentation/CodingStyle
or CodingConventions or however the list would like to name it.
Ciao,
Dscho
^ permalink raw reply
* git push refspec problem
From: James @ 2007-11-07 15:01 UTC (permalink / raw)
To: git
Hi,
I'm trying to set up my git configuration file in one of my projects
so that I can do a simple "git push" to update my project on the git
server.
Currently, I run the following command to push my updates (and it
works just fine):
git push james@my.server.com:~/scm/git/project.git/
In my .git/config file, I've added a line for push, as follows:
[remote "origin"]
url = git://my.server.com/project.git
fetch = +refs/heads/*:refs/remotes/origin/*
push = ssh://james@my.server.com/home/james/scm/git/
project.git/
When I run a "git push", it comes back with this error:
fatal: remote part of refspec is not a valid name in ssh://james@my.server.com/home/james/scm/git/project.git/
I've looked at this git push documentation:
http://www.kernel.org/pub/software/scm/git/docs/git-push.html
and it seems like my refspec is indeed correct. (or so I thought ;))
Any ideas on what I'm doing wrong?
Thanks!
.james
^ permalink raw reply
* [PATCH v2] Add Documentation/CodingStyle
From: Johannes Schindelin @ 2007-11-07 14:59 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Ralf Wildenhues, git
In-Reply-To: <47317CD7.5040506@op5.se>
Even if our code is quite a good documentation for our coding style,
some people seem to prefer a document describing it.
The part about the shell scripts is clearly just copied from one of
Junio's helpful mails, and some parts were added from comments by
Junio and Andreas Ericsson.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
On Wed, 7 Nov 2007, Andreas Ericsson wrote:
> Perhaps with this addendum?
>
> - Think very, very hard before introducing a new dependency into git. This
> means you should stay away from scripting languages not already used in
> the git core command set unless your command is clearly separate from it,
> such as an importer to convert random-scm-X repositories to git.
I edited it minimally.
Documentation/CodingStyle | 103 +++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 103 insertions(+), 0 deletions(-)
create mode 100644 Documentation/CodingStyle
diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
new file mode 100644
index 0000000..38a3d9f
--- /dev/null
+++ b/Documentation/CodingStyle
@@ -0,0 +1,103 @@
+As a popular project, we also have some guidelines to keep to the
+code. For git in general, two rough rules are:
+
+ - Most importantly, we never say "It's in POSIX; we'll happily
+ screw your system that does not conform." We live in the
+ real world.
+
+ - However, we often say "Let's stay away from that construct,
+ it's not even in POSIX".
+
+ - In spite of the above two rules, we sometimes say "Although
+ this is not in POSIX, it (is so convenient | makes the code
+ much more readable | has other good characteristics) and
+ practically all the platforms we care about support it, so
+ let's use it". Again, we live in the real world, and it is
+ sometimes a judgement call, decided based more on real world
+ constraints people face than what the paper standard says.
+
+
+As for more concrete guidelines, just imitate the existing code
+(this is a good guideline, no matter which project you are contributing
+to...). But if you must have some list of rules, here they are.
+
+For shell scripts specifically (not exhaustive):
+
+ - We prefer $( ... ) for command substitution; unlike ``, it
+ properly nests. It should have been the way Bourne spelled
+ it from day one, but unfortunately isn't.
+
+ - We use ${parameter-word} and its [-=?+] siblings, and their
+ colon'ed "unset or null" form.
+
+ - We use ${parameter#word} and its [#%] siblings, and their
+ doubled "longest matching" form.
+
+ - We use Arithmetic Expansion $(( ... )).
+
+ - No "Substring Expansion" ${parameter:offset:length}.
+
+ - No shell arrays.
+
+ - No strlen ${#parameter}.
+
+ - No regexp ${parameter/pattern/string}.
+
+ - We do not use Process Substitution <(list) or >(list).
+
+ - We prefer "test" over "[ ... ]".
+
+ - We do not write noiseword "function" in front of shell
+ functions.
+
+For C programs:
+
+ - Use tabs to indent, and interpret tabs as taking up to 8 spaces
+
+ - Try to keep to 80 characters per line
+
+ - When declaring pointers, the star sides with the variable name, i.e.
+ "char *string", not "char* string" or "char * string". This makes
+ it easier to understand "char *string, c;"
+
+ - Do not use curly brackets unnecessarily. I.e.
+
+ if (bla) {
+ x = 1;
+ }
+
+ is frowned upon. A gray area is when the statement extends over a
+ few lines, and/or you have a lengthy comment atop of it.
+
+ - Try to make your code understandable. You may put comments in, but
+ comments invariably tend to stale out when the code they were
+ describing changes. Often splitting a function into two makes the
+ intention of the code much clearer.
+
+ Double negation is often harder to understand than no negation at
+ all.
+
+ Some clever tricks, like using the !! operator with arithmetic
+ constructs, can be extremely confusing to others. Avoid them,
+ unless there is a compelling reason to use them.
+
+ - Use the API. No, really. We have a strbuf (variable length string),
+ several arrays with the ALLOC_GROW() macro, a path_list for sorted
+ string lists, a hash map (mapping struct objects) named
+ "struct decorate", amongst other things.
+
+ - When you come up with an API, document it.
+
+ - #include system headers in git-compat-util.h. Some headers on some
+ systems show subtle breakages when you change the order, so it is
+ best to keep them in one place.
+
+ - if you are planning a new command, consider writing it in shell or
+ perl first, so that changes in semantics can be easily changed and
+ discussed. Many git commands started out like that, and a few are
+ still scripts.
+
+ - Avoid introducing a new dependency into git. This means you usually
+ should stay away from scripting languages not already used in the git
+ core command set (unless your command is clearly separate from it,
+ such as an importer to convert random-scm-X repositories to git).
--
1.5.3.5.1597.g7191
^ permalink raw reply related
* Re: stgit: cleaning up after using git branch delete commands
From: Catalin Marinas @ 2007-11-07 14:57 UTC (permalink / raw)
To: Jon Smirl; +Cc: Git Mailing List
In-Reply-To: <9e4733910711070606t2c558ac9ob4c729d5baca8fb9@mail.gmail.com>
"Jon Smirl" <jonsmirl@gmail.com> wrote:
> I've used git commands to delete several branches that had stgit
> active on it. Doing that has left a bunch of clutter in the .git
> directory. Is there a stgit command to remove all the clutter from
> branches that no longer exist? I'd like to use the branch names again
> but the clutter is interfering.
You can create the branch back with GIT and run "stg branch --delete
--force", though I don't guarantee it will work (BTW, I only recently
relaxed the branch deletion rules in StGIT so that it doesn't complain
of missing files and completes the operation, so you should use the
latest HEAD).
--
Catalin
^ permalink raw reply
* Re: [PATCH] Add Documentation/CodingStyle
From: Johannes Schindelin @ 2007-11-07 14:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ralf Wildenhues, git
In-Reply-To: <7v640ega5q.fsf@gitster.siamese.dyndns.org>
Hi,
On Tue, 6 Nov 2007, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle
> > new file mode 100644
> > index 0000000..622b80b
> > --- /dev/null
> > +++ b/Documentation/CodingStyle
> > @@ -0,0 +1,87 @@
> > +As a popular project, we also have some guidelines to keep to the
> > +code. For git in general, two rough rules are:
> > +
> > + - Most importantly, we never say "It's in POSIX; we'll happily
> > + screw your system that does not conform." We live in the
> > + real world.
> > +
> > + - However, we often say "Let's stay away from that construct,
> > + it's not even in POSIX".
> > +
>
> I am not sure if we want to have CodingStyle document, but the
> above are not CodingStyle issues.
Would you like to call it CodingConventions?
> If we are to write this down, I'd like to have the more
> important third rule, which is:
>
> - In spite of the above two rules, we sometimes say "Although
> this is not in POSIX, it (is so convenient | makes the code
> much more readable | has other good characteristics) and
> practically all the platforms we care about support it, so
> let's use it". Again, we live in the real world, and it is
> sometimes a judgement call, decided based more on real world
> constraints people face than what the paper standard says.
Okay, will add.
> > +For C programs:
> > +
> > + - Use tabs to increment, and interpret tabs as taking up to 8 spaces
>
> What's the character for decrement? DEL? ;-)
Hehe. As you undoubtedly guessed, I meant "indent"...
> > + Double negation is often harder to understand than no negation at
> > + all.
> > +
> > + Some clever tricks, like using the !! operator with arithmetic
> > + constructs, can be extremely confusing to others. Avoid them,
> > + unless there is a compelling reason to use them.
>
> I actually think (!!var) idiom is already established in our
> codebase.
Yep, but when there are easier variants, AFAICT they were preferred.
> > + - Use the API. No, really. We have a strbuf (variable length string),
> > + several arrays with the ALLOC_GROW() macro, a path_list for sorted
> > + string lists, a hash map (mapping struct objects) named
> > + "struct decorate", amongst other things.
>
> - When you come up with an API, document it.
Okay.
> > + - if you are planning a new command, consider writing it in shell or
> > + perl first, so that changes in semantics can be easily changed and
> > + discussed. Many git commands started out like that, and a few are
> > + still scripts.
>
> No Python allowed?
Well, maybe we should allow that again. Although I hoped we are over that
now, as it would complicate the msysGit efforts tremendously.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Shawn Bohrer @ 2007-11-07 14:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: gitster, git
In-Reply-To: <Pine.LNX.4.64.0711071110040.4362@racer.site>
On Wed, Nov 07, 2007 at 11:10:45AM +0000, Johannes Schindelin wrote:
>
> you still have quite a number of instances where you wrap just one line
> into curly brackets:
>
> if (bla) {
> [just one line]
> }
Crap. OK I count one instance unless you count:
if (foo) {
one_line();
} else if (bar) {
one_line();
two_lines();
} else {
something_else();
}
Now I suppose I can get rid of the curly braces here as well but I
personally find that strange and ugly. So is there an official guideline
on if else statements?
Of course I'll fix the other one I missed and send a new patch.
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Johannes Schindelin @ 2007-11-07 14:47 UTC (permalink / raw)
To: Mike Ralphson; +Cc: Ralf Wildenhues, Mike Hommey, Junio C Hamano, git
In-Reply-To: <e2b179460711070617h7e9af64egcde5122808a4d924@mail.gmail.com>
Hi,
On Wed, 7 Nov 2007, Mike Ralphson wrote:
> Junio C Hamano wrote on Tue, Nov 06, 2007 at 09:46:35PM CET:
> > [2/5] Gaah, AIX sed X-<. I am not opposed to this patch but
> > would want to get Yays from people with non GNU sed. Is
> > busybox sed good enough to grok our scripts these days?
> > Please ask help and collect Acks at least from folks on
> > Solaris, MacOS, FBSD, and OBSD.
>
> On Nov 6, 2007 11:25 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > As Junio commented in the part you did not quote, there are better shells
> > in Solaris. Use those.
>
> Equally GNU sed is available as a drop-in rpm for AIX. I wonder if it
> would be worth adding
> Makefile support for a PATH prefix for the git scripts, so they could
> prepend (in this case)
> something like /opt/freeware/bin or /usr/linux/bin ?
>
> In our AIX environment many GNU tools are installed but I can't
> guarantee they come first
> in the paths of the git users.
>
> I'm willing to work up a patch if there's any interest.
Would that be a task for configure? Because I am not sure if the GNU
tools are installed in the same place on all AIX boxen...
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Matthieu Moy @ 2007-11-07 14:45 UTC (permalink / raw)
To: Bill Lear; +Cc: Johannes Schindelin, Shawn Bohrer, gitster, git
In-Reply-To: <18225.48553.44088.269677@lisa.zopyra.com>
Bill Lear <rael@zopyra.com> writes:
> I've always found this a thoughtful practice. It helps ensure nobody writes:
>
> if (bla)
> just_one_line();
> /* perhaps a comment, other stuff ... */
> just_another_line();
It also simplify patches for cases like
if (bla) {
just_one_line();
+ another_added_line();
}
instead of
- if (bla)
+ if (bla) {
just_one_line();
+ another_added_line();
+ }
But it seems people here prefer not putting the braces in this case.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 0/5] some shell portability fixes
From: Mike Ralphson @ 2007-11-07 14:17 UTC (permalink / raw)
To: Johannes Schindelin, Ralf Wildenhues; +Cc: Mike Hommey, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711062324590.4362@racer.site>
Junio C Hamano wrote on Tue, Nov 06, 2007 at 09:46:35PM CET:
> [2/5] Gaah, AIX sed X-<. I am not opposed to this patch but
> would want to get Yays from people with non GNU sed. Is
> busybox sed good enough to grok our scripts these days?
> Please ask help and collect Acks at least from folks on
> Solaris, MacOS, FBSD, and OBSD.
On Nov 6, 2007 11:25 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> As Junio commented in the part you did not quote, there are better shells
> in Solaris. Use those.
Equally GNU sed is available as a drop-in rpm for AIX. I wonder if it
would be worth adding
Makefile support for a PATH prefix for the git scripts, so they could
prepend (in this case)
something like /opt/freeware/bin or /usr/linux/bin ?
In our AIX environment many GNU tools are installed but I can't
guarantee they come first
in the paths of the git users.
I'm willing to work up a patch if there's any interest.
Mike
^ permalink raw reply
* Re: [PATCH] Make git-clean a builtin
From: Johannes Schindelin @ 2007-11-07 14:17 UTC (permalink / raw)
To: Bill Lear; +Cc: Shawn Bohrer, gitster, git
In-Reply-To: <18225.48553.44088.269677@lisa.zopyra.com>
Hi,
On Wed, 7 Nov 2007, Bill Lear wrote:
> On Wednesday, November 7, 2007 at 11:10:45 (+0000) Johannes Schindelin writes:
>
> > you still have quite a number of instances where you wrap just one
> > line into curly brackets:
> >
> > if (bla) {
> > [just one line]
> > }
>
> I've always found this a thoughtful practice. It helps ensure nobody
> writes:
>
> if (bla)
> just_one_line();
> /* perhaps a comment, other stuff ... */
> just_another_line();
But if there is only one line and you fail to add curly brackets when
adding a second line, well, uhm, then I cannot help you with anything.
BTW I was talking about _one_ line, not a line and another one with a
comment.
> It also is nice for others who come along and extend the branch from
> just one line to multiple ones, as the brackets are already in place.
The fact is: these lines will stay single lines most likely for eternity.
> Why do you find it objectionable?
It distracts. It's ugly. It's unnecessary.
Ciao,
Dscho
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox