* Re: [PATCH] Improved and extended t5404
From: Alex Riesen @ 2007-11-14 20:34 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <20071114194522.GA3973@steel.home>
Alex Riesen, Wed, Nov 14, 2007 20:45:22 +0100:
> Johannes Schindelin, Wed, Nov 14, 2007 18:10:25 +0100:
> > On Wed, 14 Nov 2007, Alex Riesen wrote:
> > > Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
> > > > Alex Riesen <raa.lkml@gmail.com> writes:
> > > >
> > > > > Ignore exit code of git push in t5404, as it is not relevant for the
> > > > > test
> > > >
> > > > This proposed log message solicits a "Huh? -- Since when ignoring exit
> > > > code is an improvement?" reaction. If this push is expected to error
> > > > out, then wouldn't you want to make sure it errors out as expected?
> > > > If the problem is that the exit status is unreliable, maybe we need to
> > > > make it reliable instead?
> > >
> > > Well, it is kind of undefined. git push just updated some remote
> > > references and failed on the others. It has had some failures, so it
> > > returns non-0. And as I said, it really is not about the operation, but
> > > about if the tracking and remote branches are set as we want them.
> >
> > If you know it should fail, why not make the test dependent on that
> > failure? I mean, should git-push have a bug and not fail, it would be
> > nice to catch this early...
> >
>
> Well, I do not know it _should_ fail. Personally, I would not even
> care: I see no way to cover with just one exit code multiple
> failures. Some references were updated and I don't even know which.
> So I'd better check whatever exit code.
"I'd better check whatever was updated and damn the exit code"
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Wincent Colaiuta @ 2007-11-14 20:30 UTC (permalink / raw)
To: Bill Lear
Cc: Junio C Hamano, Sergei Organov, Matthieu Moy, Johannes Schindelin,
Jan Wielemaker, git
In-Reply-To: <18235.22445.16228.535898@lisa.zopyra.com>
El 14/11/2007, a las 21:16, Bill Lear escribió:
> % mkdir new_repo
> % cd new_repo
> [add content]
> % git commit -a -m "Initial stuff"
> % git config remote.origin.url git://host/new_repo
> % git push
> [ach! fails! what's up??]
> [poke, read, poke some more, try other things..]
> [try setting the remote.origin.fetch? No, that doesn't work]
> [try setting branch.master.remote? Just edit by hand??]
> % git push master
> [fails again; read some more; think, think, think...]
> % git push origin master
> [aha! finally it works]
Instead of using git-config I think the following would have worked:
git remote add origin git.example.com:/pub/git/path_repositories/
repo.git
git push --all
I guess it is not necessarily obvious the first time, which more than
anything makes this a documentation issue. I now can't remember how I
learnt this; probably by reading this list.
Cheers,
Wincent
^ permalink raw reply
* [PATCH] Fix Solaris Workshop Compiler issues
From: Guido Ostkamp @ 2007-11-14 20:31 UTC (permalink / raw)
To: git
Hello,
please find below a patch that solves an error when compiling with the
original Sun Solaris Compiler. When compiling out of the box, the
following happens:
CC diff-delta.o
"diff-delta.c", line 314: identifier redeclared: create_delta
current : function(pointer to const struct delta_index {unsigned long memsize, pointer to const void src_buf, unsigned long src_size, unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash}, pointer to const void, unsigned long, pointer to unsigned long, unsigned long) returning pointer to void
previous: function(pointer to const struct delta_index {unsigned long memsize, pointer to const void src_buf, unsigned long src_size, unsigned int hash_mask, array[-1] of pointer to struct index_entry {..} hash}, pointer to const void, unsigned long, pointer to unsigned long, unsigned long) returning pointer to void : "delta.h", line 44
cc: acomp failed for diff-delta.c
make: *** [diff-delta.o] Error 2
This is because 'struct delta_index' is declared with no size in delta.h
and with size in diff-delta.c which does not fit.
When the struct definition is done in the header file as one would
normally expect, everything compiles ok with exception of a
mkdtemp()-issue which somebody else already took care of on this list.
Best regards
Guido
diff --git a/delta.h b/delta.h
index 40ccf5a..06af9a7 100644
--- a/delta.h
+++ b/delta.h
@@ -1,8 +1,23 @@
#ifndef DELTA_H
#define DELTA_H
-/* opaque object for delta index */
-struct delta_index;
+struct index_entry {
+ const unsigned char *ptr;
+ unsigned int val;
+};
+
+struct unpacked_index_entry {
+ struct index_entry entry;
+ struct unpacked_index_entry *next;
+};
+
+struct delta_index {
+ unsigned long memsize;
+ const void *src_buf;
+ unsigned long src_size;
+ unsigned int hash_mask;
+ struct index_entry *hash[FLEX_ARRAY];
+};
/*
* create_delta_index: compute index data from given buffer
diff --git a/diff-delta.c b/diff-delta.c
index 9e440a9..2023e40 100644
--- a/diff-delta.c
+++ b/diff-delta.c
@@ -112,24 +112,6 @@ static const unsigned int U[256] = {
0x133eb0ac, 0x6d8b90a1, 0x450d4467, 0x3bb8646a
};
-struct index_entry {
- const unsigned char *ptr;
- unsigned int val;
-};
-
-struct unpacked_index_entry {
- struct index_entry entry;
- struct unpacked_index_entry *next;
-};
-
-struct delta_index {
- unsigned long memsize;
- const void *src_buf;
- unsigned long src_size;
- unsigned int hash_mask;
- struct index_entry *hash[FLEX_ARRAY];
-};
-
struct delta_index * create_delta_index(const void *buf, unsigned long bufsize)
{
unsigned int i, hsize, hmask, entries, prev_val, *hash_count;
^ permalink raw reply related
* Re: How to change a submodue as a subdirectory?
From: Alex Riesen @ 2007-11-14 20:26 UTC (permalink / raw)
To: Ping Yin; +Cc: Git Mailing List
In-Reply-To: <46dff0320711140637s51e1368fv3f632b6f04d093d5@mail.gmail.com>
Ping Yin, Wed, Nov 14, 2007 15:37:57 +0100:
> I have a super project superA, and a submodue subB. Now i decide to
> switch subB from submodule to sub directory. Any good way to do that
> and not losing any history?
$ mv subB sub
$ git add sub
$ git update-index --force-remove subB
$ git commit
Which history were you afraid of losing?
^ permalink raw reply
* Re: [PATCH v3] Add line-wrapping guidelines to the coding style documentation
From: Wincent Colaiuta @ 2007-11-14 20:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v4pfoh9vu.fsf@gitster.siamese.dyndns.org>
El 14/11/2007, a las 21:04, Junio C Hamano escribió:
> Wincent Colaiuta <win@wincent.com> writes:
>
>> El 14/11/2007, a las 18:19, Johannes Schindelin escribió:
>>
>>> Besides, is it really necessary to be as explicit as you word it?
>>> IOW is
>>> this patch needed?
>>
>> I was basically just trying to help new people from making the same
>> mistake that I did; ie. not knowing if there was an official limit,
>> looking at the maximum line length in a file, making sure my patch
>> didn't exceed that length (and re-wrapping to avoid exceeding it),
>> and
>> then getting reprimanded for gratuitous re-wrapping.
>
> Sorry about that "reprimanded" part. I should have been more
> careful -- I did not really mean it that way. It was more like
> "it would have been nicer ... so please try to next time".
Don't worry about it, Junio. I've been subscribed to the list for
several months now, so I'm already aware of the perfectionism inherent
in the process; I didn't take anything personally, and much less
coming from you who is always diplomatic. I just thought, "this is
good advice that Junio has posted to the list, I found it helpful, so
I think it should go in the style doc".
And I'm no stranger to Johannes' scything sarcasm either, it's his
personal style; luckily, along with the sarcasm he makes so many high-
quality contributions to the community as well.
> I agree that "80 columns" sits better in that new "Line
> wrapping" section. I wonder if "tabs are 8 spaces wide" also
> belong there.
You're probably right; I understand that the 8-wide tabs convention
holds in shell and perl scripts too, not just in C source.
Cheers,
Wincent
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Bill Lear @ 2007-11-14 20:22 UTC (permalink / raw)
To: Junio C Hamano, Sergei Organov, Matthieu Moy, Johannes Schindelin,
Jan Wielemaker
In-Reply-To: <18235.22445.16228.535898@lisa.zopyra.com>
[I sent a few mistakes --- edited below.]
On Wednesday, November 14, 2007 at 14:16:45 (-0600) Bill Lear writes:
>...
>Well, here's what we'd like:
>
>% mkdir new_repo
>% cd new_repo
>% git --bare init
>
>[on another machine:]
>% git clone git://host/new_repo
>% cd new_repo
>% git init
[No git init would be needed here, obviously.]
>[add content]
>% git commit -a -m "Initial stuff"
>% git push
>
>So, this is hard work, and other priorities intrude. Ok.
>
>Instead, we have to 1) figure out how to do this right, because it's
>difficult to remember and not intuitive, and 2) once we have "figured
>it out", really figure it out, because there are a few gotchas:
>
>% mkdir new_repo
>% cd new_repo
>% git --bare init
>
>% mkdir new_repo
>% cd new_repo
[git init is needed here...]
>[add content]
>% git commit -a -m "Initial stuff"
>% git config remote.origin.url git://host/new_repo
>% git push
>[ach! fails! what's up??]
>[poke, read, poke some more, try other things..]
>[try setting the remote.origin.fetch? No, that doesn't work]
>[try setting branch.master.remote? Just edit by hand??]
>% git push master
>[fails again; read some more; think, think, think...]
>% git push origin master
>[aha! finally it works]
>...
Sorry for the sloppiness.
Bill
^ permalink raw reply
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Bill Lear @ 2007-11-14 20:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sergei Organov, Matthieu Moy, Johannes Schindelin, Jan Wielemaker,
git
In-Reply-To: <7vfxz8hbcf.fsf@gitster.siamese.dyndns.org>
On Wednesday, November 14, 2007 at 11:32:32 (-0800) Junio C Hamano writes:
>Sergei Organov <osv@javad.com> writes:
>
>> Junio C Hamano <gitster@pobox.com> writes:
>>
>>> His second point is also a real issue. If you allowed cloning
>>> an empty repo (either bare or non-bare), then you and Bill can
>>> both clone from it, come up with an initial commit each. Bill
>>> pushes his initial commit first. Your later attempt to push
>>> will hopefully fail with "non fast forward", if you know better
>>> than forcing such a push, but then what? You need to fetch, and
>>> merge (or rebase) your change on top of Bill's initial commit,
>>> and at that point the history you are trying to merge does not
>>> have any common ancestor with his history.
>>
>> Just a wild idea. Doesn't it make sense to introduce perfect ultimate
>> common ancestor of the universe, probably calling it "the NULL commit"?
>> At first glance it seems that it can help to avoid corner cases
>> automagically.
>...
>But cloning void to start the same project by multiple people
>and pushing their initial commits as roots to start a project
>indicates the lack of developer communication (besides, it just
>feels like a bad style, a hangover from centralized SCM
>mentality, but that is fine). ...
We have several users who have been using git for the past 9 months
and they each find this unreasonably complicated. We realize it is
work, perhaps not of the highest importance, but it's also easy for
more experienced users to simply pooh-pooh the ideas that newer users
have as "silly" because instead of the two steps they would like, they
can "just" do the five "easy" steps.
Well, here's what we'd like:
% mkdir new_repo
% cd new_repo
% git --bare init
[on another machine:]
% git clone git://host/new_repo
% cd new_repo
% git init
[add content]
% git commit -a -m "Initial stuff"
% git push
So, this is hard work, and other priorities intrude. Ok.
Instead, we have to 1) figure out how to do this right, because it's
difficult to remember and not intuitive, and 2) once we have "figured
it out", really figure it out, because there are a few gotchas:
% mkdir new_repo
% cd new_repo
% git --bare init
% mkdir new_repo
% cd new_repo
[add content]
% git commit -a -m "Initial stuff"
% git config remote.origin.url git://host/new_repo
% git push
[ach! fails! what's up??]
[poke, read, poke some more, try other things..]
[try setting the remote.origin.fetch? No, that doesn't work]
[try setting branch.master.remote? Just edit by hand??]
% git push master
[fails again; read some more; think, think, think...]
% git push origin master
[aha! finally it works]
But now, I have a repo in which I cannot just say "git push" to update
my remote repo.
So, if we can't have clone "do the right thing", then it would be nice
if we had something to allow us to do this, perhaps an argument to git
init:
% mkdir new_repo
% cd new_repo
% git --bare init
[on another machine:]
% mkdir new_repo
% cd new_repo
% git init --mirror git://host/new_repo
[add content]
% git commit -a -m "Initial stuff"
% git push
Where 'git init --mirror <blah>' just sets up the config file
properly.
Something to think about ...
Bill
^ permalink raw reply
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Junio C Hamano @ 2007-11-14 20:13 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, git
In-Reply-To: <Pine.LNX.4.64.0711141441530.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Wed, 14 Nov 2007, Junio C Hamano wrote:
>
>> Johannes Sixt <johannes.sixt@telecom.at> writes:
>>
>> > This is a series of smallish, unrelated changes that were necessary
>> > for the MinGW port.
>>
>> I was _VERY_ afraid of reviewing this series.
>
> Why? Because we get closer to MinGW integration into git.git for real?
> ;-)
I know you know me better than that.
Conversion from "Too UNIXy" stuff into another form that "claims
to" run on a different platform that I do not have a good way of
testing myself? I should feel scared, even if I can always punt
and say "I'll only make sure UNIX side does not regress,
Windose, who cares" ;-).
^ permalink raw reply
* Re: [PATCH v3] Add line-wrapping guidelines to the coding style documentation
From: Junio C Hamano @ 2007-11-14 20:04 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <622166FD-0727-47D4-B26C-8A01788FD1EA@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> El 14/11/2007, a las 18:19, Johannes Schindelin escribió:
>
>> Besides, is it really necessary to be as explicit as you word it?
>> IOW is
>> this patch needed?
>
> I was basically just trying to help new people from making the same
> mistake that I did; ie. not knowing if there was an official limit,
> looking at the maximum line length in a file, making sure my patch
> didn't exceed that length (and re-wrapping to avoid exceeding it), and
> then getting reprimanded for gratuitous re-wrapping.
Sorry about that "reprimanded" part. I should have been more
careful -- I did not really mean it that way. It was more like
"it would have been nicer ... so please try to next time".
I know how stressful a life is for a contributor new to a
project. You not only need to make sure the meat of your change
is good, but worry about the technicalities, such as the
presentation and style, the tone of the proposed log message
that addresses other peoples efforts you are building on; in
short, finding out the lay of the land, making yourself blend
well in the comminity.
We have a great way to quickly tell if somebody is new to the
project (i.e. "git shortlog --author=Wincent master"). I should
use it more often and adjust my tone accordingly. It's only
fair for me to do so when the new person surely is trying hard
to do his part.
> diff --git a/Documentation/CodingGuidelines b/Documentation/
> CodingGuidelines
> index 3b042db..d2d1f32 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -58,8 +58,6 @@ For C programs:
> - We use tabs to indent, and interpret tabs as taking up to
> 8 spaces.
>
> - - We try to keep to at most 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 code
I agree that "80 columns" sits better in that new "Line
wrapping" section. I wonder if "tabs are 8 spaces wide" also
belong there.
> @@ -110,3 +108,14 @@ For C programs:
> 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).
> +
> +Line wrapping:
> +
> + - We generally try to keep scripts, C source files and AsciiDoc
> + documentation within the range of "80 columns minus some slop"
> + to accommodate diff change marks [-+ ] and quoting ">> " in
> + emails.
> +
> + - When submitting patches use common sense to decide whether to
> + rewrap (or reindent), avoiding gratuitous changes.
> +
^ permalink raw reply
* Re: git 1.5.3.5 error over NFS (pack data corruption)
From: Alex Riesen @ 2007-11-14 19:54 UTC (permalink / raw)
To: Bill Lear; +Cc: git
In-Reply-To: <18234.15666.711624.443184@lisa.zopyra.com>
Bill Lear, Wed, Nov 14, 2007 01:11:30 +0100:
> >oh, you should be looking for usage.c, the function report (it is
> >called by default die handler). The old code used to fputs("fatal:"),
> >the new just vfprintf's everything, so the write should look like:
> >
> > write(2, "fatal: cannot pread pack file: No such "...
>
> Are you sure?
>
> % ls -l git-1.5.3.5.tar.bz2
> -rw-r--r-- 1 blear software 1351433 2007-10-31 15:04 git-1.5.3.5.tar.bz2
> % bunzip2 -c !$ | tar xf -
> % cd git-1.5.3.5
> % grep -A 5 'void report' usage.c
> static void report(const char *prefix, const char *err, va_list params)
> {
> fputs(prefix, stderr);
> vfprintf(stderr, err, params);
> fputs("\n", stderr);
Ach, right. I just checked Junio's master. BTW, maybe you could check
that as well? There were 64bit fixes lately, and had an impression you
were using git compiled for 64bit (mmap2 return address from your
first strace was shown 64bit).
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Alex Riesen @ 2007-11-14 19:45 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <Pine.LNX.4.64.0711141709410.4362@racer.site>
Johannes Schindelin, Wed, Nov 14, 2007 18:10:25 +0100:
> On Wed, 14 Nov 2007, Alex Riesen wrote:
> > Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
> > > Alex Riesen <raa.lkml@gmail.com> writes:
> > >
> > > > Ignore exit code of git push in t5404, as it is not relevant for the
> > > > test
> > >
> > > This proposed log message solicits a "Huh? -- Since when ignoring exit
> > > code is an improvement?" reaction. If this push is expected to error
> > > out, then wouldn't you want to make sure it errors out as expected?
> > > If the problem is that the exit status is unreliable, maybe we need to
> > > make it reliable instead?
> >
> > Well, it is kind of undefined. git push just updated some remote
> > references and failed on the others. It has had some failures, so it
> > returns non-0. And as I said, it really is not about the operation, but
> > about if the tracking and remote branches are set as we want them.
>
> If you know it should fail, why not make the test dependent on that
> failure? I mean, should git-push have a bug and not fail, it would be
> nice to catch this early...
>
Well, I do not know it _should_ fail. Personally, I would not even
care: I see no way to cover with just one exit code multiple
failures. Some references were updated and I don't even know which.
So I'd better check whatever exit code.
^ permalink raw reply
* Re: [PATCH] user-manual.txt: fix a few mistakes
From: J. Bruce Fields @ 2007-11-14 19:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sergei Organov, git
In-Reply-To: <7v8x50hawk.fsf@gitster.siamese.dyndns.org>
On Wed, Nov 14, 2007 at 11:42:03AM -0800, Junio C Hamano wrote:
> "J. Bruce Fields" <bfields@fieldses.org> writes:
>
> > I actually prefer "head" here. On something like:
> >
> > A--B--C
> > /
> > o--o--o
> > \
> > o--o--o
> >
> >
> > The term "branch" could be used to refer to the whole line of
> > development consisting of A, B, and C. The term "head", on the other
> > hand, refers to either C or a ref that points to it. We also use the
> > terms "branch head" or just "branch" for that case, but I think "head"
> > is more precise.
> >
> >> +This lists the commits reachable from the previous version of the branch.
> >> +This syntax can be used with any git command that accepts a commit,
> >> not just with git log. Some other examples:
> >
> > (Otherwise looks fine, thanks!)
>
> Oops, I think I skipped the hunk #2 and applied hunk #3. Will
> fix-up with:
OK, thanks Junio!
--b.
^ permalink raw reply
* Re: [PATCH] user-manual.txt: fix a few mistakes
From: Junio C Hamano @ 2007-11-14 19:42 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Sergei Organov, git, gitster
In-Reply-To: <20071114181858.GH14254@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> I actually prefer "head" here. On something like:
>
> A--B--C
> /
> o--o--o
> \
> o--o--o
>
>
> The term "branch" could be used to refer to the whole line of
> development consisting of A, B, and C. The term "head", on the other
> hand, refers to either C or a ref that points to it. We also use the
> terms "branch head" or just "branch" for that case, but I think "head"
> is more precise.
>
>> +This lists the commits reachable from the previous version of the branch.
>> +This syntax can be used with any git command that accepts a commit,
>> not just with git log. Some other examples:
>
> (Otherwise looks fine, thanks!)
Oops, I think I skipped the hunk #2 and applied hunk #3. Will
fix-up with:
-- >8 --
From: Sergei Organov <osv@javad.com>
Subject: user-manual: minor rewording for clarity.
Junio screwed up when applying the previous round of the patch;
rewording from "previous" to "old" does make the description
clearer.
Also revert the rewording from head to branch. The description
is talking about the branch's tip commit and using the word head
is clearer.
Based on input from Sergei and Bruce.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/user-manual.txt | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 60e1385..c7cfbbc 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
fundamentally different ways to fix the problem:
1. You can create a new commit that undoes whatever was done
- by the previous commit. This is the correct thing if your
+ by the old commit. This is the correct thing if your
mistake has already been made public.
2. You can go back and modify the old commit. You should
@@ -1567,7 +1567,7 @@ old history using, for example,
$ git log master@{1}
-------------------------------------------------
-This lists the commits reachable from the previous version of the branch.
+This lists the commits reachable from the previous version of the head.
This syntax can be used with any git command that accepts a commit,
not just with git log. Some other examples:
--
1.5.3.5.1746.g62954
^ permalink raw reply related
* Re: Cloning empty repositories, was Re: What is the idea for bare repositories?
From: Junio C Hamano @ 2007-11-14 19:32 UTC (permalink / raw)
To: Sergei Organov
Cc: Matthieu Moy, Johannes Schindelin, Bill Lear, Jan Wielemaker, git
In-Reply-To: <87myth58r5.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> His second point is also a real issue. If you allowed cloning
>> an empty repo (either bare or non-bare), then you and Bill can
>> both clone from it, come up with an initial commit each. Bill
>> pushes his initial commit first. Your later attempt to push
>> will hopefully fail with "non fast forward", if you know better
>> than forcing such a push, but then what? You need to fetch, and
>> merge (or rebase) your change on top of Bill's initial commit,
>> and at that point the history you are trying to merge does not
>> have any common ancestor with his history.
>
> Just a wild idea. Doesn't it make sense to introduce perfect ultimate
> common ancestor of the universe, probably calling it "the NULL commit"?
> At first glance it seems that it can help to avoid corner cases
> automagically.
The tools do not have problem with the multiple-root issue; we
can merge without common ancestor just fine. So in that area,
we do not need to kludge like that at the physical level (you
can think of root commits having "the NULL" as their parents).
But cloning void to start the same project by multiple people
and pushing their initial commits as roots to start a project
indicates the lack of developer communication (besides, it just
feels like a bad style, a hangover from centralized SCM
mentality, but that is fine).
If the "feature" can be supported with zero cost, I do not have
a problem. If that feature does something one does not agree
with (be it promoting a bad workflow or whatever), one does not
have to use it. All one has to do is try not to recommend using
that feature to others.
But this time, the "feature" is not a zero cost thing. As
Matthieu said in the thread, we do not let you do so right now.
Which means that it would involve new development, the code
changes would risk regressing behaviour existing users rely on,
and we would need testing for that. These all take resources.
We already spent quite a lot of time on this thread, and at
least to me I feel that my time would have been better spent if
instead I were looking at patches on some other topics, or
working on cleaning up cherry-pick/revert implementation.
^ permalink raw reply
* Re: [PATCH v3] Add line-wrapping guidelines to the coding style documentation
From: Andreas Ericsson @ 2007-11-14 19:08 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Johannes Schindelin, Git Mailing List, Junio Hamano
In-Reply-To: <622166FD-0727-47D4-B26C-8A01788FD1EA@wincent.com>
Wincent Colaiuta wrote:
> Help new contributors by providing some advice about line-wrapping; the
> advice basically boils down to "use 80 columns minus some slop as a
> rule of thumb", but also "use common sense", and "avoid gratuitous
> rewrapping".
>
> Signed-off-by: Wincent Colaiuta <win@wincent.com>
> ---
>
> El 14/11/2007, a las 18:19, Johannes Schindelin escribió:
>
>> On Wed, 14 Nov 2007, Wincent Colaiuta wrote:
>>
>>> Help new contributors by providing some advice about line-wrapping; the
>>> advice basically boils down to "use 80-characters minus some slop as a
>>> rule of thumb", but also "use common sense", and "avoid gratuitous
>>> rewrapping".
>>
>> We already have this:
>>
>> - We try to keep to at most 80 characters per line.
>
> Ah, didn't see that. It's in the "C programs" section and I was trying
> to provide a guideline that applied to all source types (given that this
> all started with a doc patch to an AsciiDoc source file).
>
>> Besides, is it really necessary to be as explicit as you word it? IOW is
>> this patch needed?
>
> I was basically just trying to help new people from making the same
> mistake that I did; ie. not knowing if there was an official limit,
> looking at the maximum line length in a file, making sure my patch
> didn't exceed that length (and re-wrapping to avoid exceeding it), and
> then getting reprimanded for gratuitous re-wrapping.
>
> As for the explicitness, I was just paraphrasing the guidelines as Junio
> expressed them.
>
>> Because if we go down that road, we might very well end up with a
>> CodingGuidelines document that is larger than git's source code.
>
> 134 lines down (the current length of CodingGuidelines with that patch),
> about 100,000 lines to go (the rest of the codebase). So if we try very
> hard, we could indeed get there.
>
> Here follows a revised patch which is more concise, and keeps all
> wrapping references at a single place. I lose your "at most 80
> characters" in favor of Junio's "80-characters minus some slop", and in
> fact state "80 columns" rather than "80 characters", because that's what
> we're really talking about, isn't it?
>
> Cheers,
> Wincent
>
> Documentation/CodingGuidelines | 13 +++++++++++--
> 1 files changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/CodingGuidelines
> b/Documentation/CodingGuidelines
> index 3b042db..d2d1f32 100644
> --- a/Documentation/CodingGuidelines
> +++ b/Documentation/CodingGuidelines
> @@ -58,8 +58,6 @@ For C programs:
> - We use tabs to indent, and interpret tabs as taking up to
> 8 spaces.
>
> - - We try to keep to at most 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 code
> @@ -110,3 +108,14 @@ For C programs:
> 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).
> +
> +Line wrapping:
> +
> + - We generally try to keep scripts, C source files and AsciiDoc
> + documentation
"We generally try to keep source and documentation" ... ?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH v3] Add line-wrapping guidelines to the coding style documentation
From: Wincent Colaiuta @ 2007-11-14 19:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List, Junio Hamano
In-Reply-To: <Pine.LNX.4.64.0711141717570.4362@racer.site>
Help new contributors by providing some advice about line-wrapping; the
advice basically boils down to "use 80 columns minus some slop as a
rule of thumb", but also "use common sense", and "avoid gratuitous
rewrapping".
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
El 14/11/2007, a las 18:19, Johannes Schindelin escribió:
> On Wed, 14 Nov 2007, Wincent Colaiuta wrote:
>
>> Help new contributors by providing some advice about line-wrapping;
>> the
>> advice basically boils down to "use 80-characters minus some slop
>> as a
>> rule of thumb", but also "use common sense", and "avoid gratuitous
>> rewrapping".
>
> We already have this:
>
> - We try to keep to at most 80 characters per line.
Ah, didn't see that. It's in the "C programs" section and I was trying
to provide a guideline that applied to all source types (given that
this all started with a doc patch to an AsciiDoc source file).
> Besides, is it really necessary to be as explicit as you word it?
> IOW is
> this patch needed?
I was basically just trying to help new people from making the same
mistake that I did; ie. not knowing if there was an official limit,
looking at the maximum line length in a file, making sure my patch
didn't exceed that length (and re-wrapping to avoid exceeding it), and
then getting reprimanded for gratuitous re-wrapping.
As for the explicitness, I was just paraphrasing the guidelines as
Junio expressed them.
> Because if we go down that road, we might very well end up with a
> CodingGuidelines document that is larger than git's source code.
134 lines down (the current length of CodingGuidelines with that
patch), about 100,000 lines to go (the rest of the codebase). So if we
try very hard, we could indeed get there.
Here follows a revised patch which is more concise, and keeps all
wrapping references at a single place. I lose your "at most 80
characters" in favor of Junio's "80-characters minus some slop", and
in fact state "80 columns" rather than "80 characters", because that's
what we're really talking about, isn't it?
Cheers,
Wincent
Documentation/CodingGuidelines | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/Documentation/CodingGuidelines b/Documentation/
CodingGuidelines
index 3b042db..d2d1f32 100644
--- a/Documentation/CodingGuidelines
+++ b/Documentation/CodingGuidelines
@@ -58,8 +58,6 @@ For C programs:
- We use tabs to indent, and interpret tabs as taking up to
8 spaces.
- - We try to keep to at most 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 code
@@ -110,3 +108,14 @@ For C programs:
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).
+
+Line wrapping:
+
+ - We generally try to keep scripts, C source files and AsciiDoc
+ documentation within the range of "80 columns minus some slop"
+ to accommodate diff change marks [-+ ] and quoting ">> " in
+ emails.
+
+ - When submitting patches use common sense to decide whether to
+ rewrap (or reindent), avoiding gratuitous changes.
+
--
1.5.3.5
^ permalink raw reply related
* Re: tracking remotes with Git
From: Ivan Shmakov @ 2007-11-14 18:26 UTC (permalink / raw)
To: git; +Cc: Ivan Shmakov
In-Reply-To: <b1e3a35f0711090444g3c31e862g4ef4ef8139927840@mail.gmail.com>
>>>>> "IS" == Ivan Shmakov <oneingray@gmail.com> writes:
[...]
IS> * it looks like `git-cvsimport' uses its own CVS protocol
IS> implementation which doesn't support compression; I've tried to
IS> clone a repository of a project hosted in CVS since circa 1998 and
IS> it 20 MiB or so to obtain revisions until 2000 or so; any ways to
IS> minimize traffic?
I've switched to tailor instead. It uses native cvs(1), which
supports compression.
IS> * how many revisions will `git-svn fetch' obtain from the SVN
IS> repository? I had to run it for several times to get the full
IS> history; I've tried to use (undocumented) `--fetch-all' option,
BTW, how about documenting that one?
IS> but it appears to help (may be but for a little.)
s/to/not to/.
[...]
^ permalink raw reply
* Re: [PATCH] user-manual.txt: fix a few mistakes
From: J. Bruce Fields @ 2007-11-14 18:18 UTC (permalink / raw)
To: Sergei Organov; +Cc: git, gitster
In-Reply-To: <87bq9x7w4d.fsf@osv.gnss.ru>
On Tue, Nov 13, 2007 at 09:19:39PM +0300, Sergei Organov wrote:
>
> Signed-off-by: Sergei Organov <osv@javad.com>
> ---
> Documentation/user-manual.txt | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index d99adc6..a169ef0 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
> If you run "git branch" at this point, you'll see that git has
> temporarily moved you to a new branch named "bisect". This branch
> points to a commit (with commit id 65934...) that is reachable from
> -v2.6.19 but not from v2.6.18. Compile and test it, and see whether
> +"master" but not from v2.6.18. Compile and test it, and see whether
> it crashes. Assume it does crash. Then:
>
> -------------------------------------------------
> @@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
> fundamentally different ways to fix the problem:
>
> 1. You can create a new commit that undoes whatever was done
> - by the previous commit. This is the correct thing if your
> + by the old commit. This is the correct thing if your
> mistake has already been made public.
>
> 2. You can go back and modify the old commit. You should
> @@ -1567,8 +1567,8 @@ old history using, for example,
> $ git log master@{1}
> -------------------------------------------------
>
> -This lists the commits reachable from the previous version of the head.
> -This syntax can be used to with any git command that accepts a commit,
I actually prefer "head" here. On something like:
A--B--C
/
o--o--o
\
o--o--o
The term "branch" could be used to refer to the whole line of
development consisting of A, B, and C. The term "head", on the other
hand, refers to either C or a ref that points to it. We also use the
terms "branch head" or just "branch" for that case, but I think "head"
is more precise.
> +This lists the commits reachable from the previous version of the branch.
> +This syntax can be used with any git command that accepts a commit,
> not just with git log. Some other examples:
(Otherwise looks fine, thanks!)
--b.
^ permalink raw reply
* Re: [PATCH] user-manual.txt: fix a few mistakes
From: J. Bruce Fields @ 2007-11-14 18:13 UTC (permalink / raw)
To: Sergei Organov; +Cc: Junio C Hamano, git
In-Reply-To: <87ir455713.fsf@osv.gnss.ru>
On Wed, Nov 14, 2007 at 03:46:32PM +0300, Sergei Organov wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > Sergei Organov <osv@javad.com> writes:
> >
> >> Signed-off-by: Sergei Organov <osv@javad.com>
> >> ---
> >> Documentation/user-manual.txt | 8 ++++----
> >> 1 files changed, 4 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> >> index d99adc6..a169ef0 100644
> >> --- a/Documentation/user-manual.txt
> >> +++ b/Documentation/user-manual.txt
> >> @@ -475,7 +475,7 @@ Bisecting: 3537 revisions left to test after this
> >> If you run "git branch" at this point, you'll see that git has
> >> temporarily moved you to a new branch named "bisect". This branch
> >> points to a commit (with commit id 65934...) that is reachable from
> >> -v2.6.19 but not from v2.6.18. Compile and test it, and see whether
> >> +"master" but not from v2.6.18. Compile and test it, and see whether
> >> it crashes. Assume it does crash. Then:
> >>
> >> -------------------------------------------------
> >
> > Thanks.
> >
> > This hunk and the last hunk I do not have any problem with.
> >
> >> @@ -1367,7 +1367,7 @@ If you make a commit that you later wish you hadn't, there are two
> >> fundamentally different ways to fix the problem:
> >>
> >> 1. You can create a new commit that undoes whatever was done
> >> - by the previous commit. This is the correct thing if your
> >> + by the old commit. This is the correct thing if your
> >> mistake has already been made public.
> >>
> >> 2. You can go back and modify the old commit. You should
> >
> > But is this an improvement or just a churn?
>
> I believe this is an improvement. It's more precise. With this change
> it's crystal clear that both (1) and (2) above mean the same commit by
> calling it "the old commit". Before the change, when I read this the
> first time, I've got the term "previous" here literally, i.e., as the
> last commit made, and I thought that if the commit in question is the
> last one, I should do (1), otherwise -- (2). This confusion admittedly
> vanished rather quickly, but it did happen.
I think it's a good fix, yes, thanks.--b.
^ permalink raw reply
* [PATCH] Documentation: customize diff-options depending on particular command
From: Sergei Organov @ 2007-11-14 18:00 UTC (permalink / raw)
To: git; +Cc: gitster
Customize diff-options depending on particular command as follows,
mostly to make git-diff and git-format-patch manuals less confusing:
* git-format-patch:
- Mark --patch-with-stat as being the default.
- Change -p description so that it matches what it actually does and
so that it doesn't refer to absent "section on generating
patches".
* git-diff: mark -p as being the default.
* git-diff-index/git-diff-files/git-diff-tree: mark --raw as being
the default.
Signed-off-by: Sergei Organov <osv@javad.com>
---
Documentation/diff-options.txt | 18 +++++++++++++++++-
Documentation/git-diff.txt | 1 +
Documentation/git-format-patch.txt | 1 +
3 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt
index b1f528a..87f7ec1 100644
--- a/Documentation/diff-options.txt
+++ b/Documentation/diff-options.txt
@@ -1,5 +1,19 @@
+ifndef::git-format-patch[]
+ifndef::git-diff[]
+:git-diff-core: 1
+endif::git-diff[]
+endif::git-format-patch[]
+
+ifdef::git-format-patch[]
+-p::
+ Generate patches without diffstat.
+endif::git-format-patch[]
+
+ifndef::git-format-patch[]
-p::
- Generate patch (see section on generating patches)
+ Generate patch (see section on generating patches).
+ {git-diff? This is the default.}
+endif::git-format-patch[]
-u::
Synonym for "-p".
@@ -13,6 +27,7 @@
--raw::
Generate the raw format.
+ {git-diff-core? This is the default.}
--patch-with-raw::
Synonym for "-p --raw".
@@ -41,6 +56,7 @@
--patch-with-stat::
Synonym for "-p --stat".
+ {git-format-patch? This is the default.}
-z::
NUL-line termination on output. This affects the --raw
diff --git a/Documentation/git-diff.txt b/Documentation/git-diff.txt
index 11c4216..2808a5e 100644
--- a/Documentation/git-diff.txt
+++ b/Documentation/git-diff.txt
@@ -75,6 +75,7 @@ and the range notations ("<commit>..<commit>" and
OPTIONS
-------
+:git-diff: 1
include::diff-options.txt[]
<path>...::
diff --git a/Documentation/git-format-patch.txt b/Documentation/git-format-patch.txt
index f0617ef..268f227 100644
--- a/Documentation/git-format-patch.txt
+++ b/Documentation/git-format-patch.txt
@@ -65,6 +65,7 @@ reference.
OPTIONS
-------
+:git-format-patch: 1
include::diff-options.txt[]
-<n>::
--
1.5.3.4
^ permalink raw reply related
* Re: git-clean won't read global ignore
From: Johannes Schindelin @ 2007-11-14 17:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, shunichi fuji, git
In-Reply-To: <7vsl39l0b7.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 14 Nov 2007, Junio C Hamano wrote:
> To untangle this mess, I think the first step would be something like
> this (this is against 'maint', as I was in the middle of something else
> that is based on 'maint' when I started reading this thread).
>
> The next step would be to teach read-tree, merge-recursive and clean (in
> C) to use setup_standard_excludes().
I like it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Add line-wrapping guidelines to the coding style documentation
From: Johannes Schindelin @ 2007-11-14 17:19 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List, Junio Hamano
In-Reply-To: <56A87A65-3C2E-4E10-84D4-4470879EE466@wincent.com>
Hi,
On Wed, 14 Nov 2007, Wincent Colaiuta wrote:
> Help new contributors by providing some advice about line-wrapping; the
> advice basically boils down to "use 80-characters minus some slop as a
> rule of thumb", but also "use common sense", and "avoid gratuitous
> rewrapping".
We already have this:
- We try to keep to at most 80 characters per line.
Besides, is it really necessary to be as explicit as you word it? IOW is
this patch needed?
Because if we go down that road, we might very well end up with a
CodingGuidelines document that is larger than git's source code.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Improved and extended t5404
From: Johannes Schindelin @ 2007-11-14 17:10 UTC (permalink / raw)
To: Alex Riesen; +Cc: Junio C Hamano, git, Jeff King
In-Reply-To: <20071114071929.GA2942@steel.home>
Hi,
On Wed, 14 Nov 2007, Alex Riesen wrote:
> Junio C Hamano, Wed, Nov 14, 2007 01:02:20 +0100:
> > Alex Riesen <raa.lkml@gmail.com> writes:
> >
> > > Ignore exit code of git push in t5404, as it is not relevant for the
> > > test
> >
> > This proposed log message solicits a "Huh? -- Since when ignoring exit
> > code is an improvement?" reaction. If this push is expected to error
> > out, then wouldn't you want to make sure it errors out as expected?
> > If the problem is that the exit status is unreliable, maybe we need to
> > make it reliable instead?
>
> Well, it is kind of undefined. git push just updated some remote
> references and failed on the others. It has had some failures, so it
> returns non-0. And as I said, it really is not about the operation, but
> about if the tracking and remote branches are set as we want them.
If you know it should fail, why not make the test dependent on that
failure? I mean, should git-push have a bug and not fail, it would be
nice to catch this early...
Ciao,
Dscho
^ permalink raw reply
* [PATCH] builtin-commit: Clean up an unused variable and a debug fprintf().
From: Kristian Høgsberg @ 2007-11-14 15:31 UTC (permalink / raw)
To: gitster; +Cc: git, Kristian Høgsberg
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
---
builtin-commit.c | 8 +++-----
1 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 7a8cb57..7841310 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -514,7 +514,7 @@ static const char commit_utf8_warn[] =
int cmd_commit(int argc, const char **argv, const char *prefix)
{
- int header_len, parent_count = 0;
+ int header_len;
struct strbuf sb;
const char *index_file, *reflog_msg;
char *nl;
@@ -550,7 +550,6 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
/* Determine parents */
if (initial_commit) {
reflog_msg = "commit (initial)";
- parent_count = 0;
} else if (amend) {
struct commit_list *c;
struct commit *commit;
@@ -591,10 +590,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
/* Get the commit message and validate it */
header_len = sb.len;
- if (!no_edit) {
- fprintf(stderr, "launching editor, log %s\n", logfile);
+ if (!no_edit)
launch_editor(git_path(commit_editmsg), &sb);
- } else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0)
+ else if (strbuf_read_file(&sb, git_path(commit_editmsg), 0) < 0)
die("could not read commit message\n");
if (run_hook(index_file, "commit-msg", commit_editmsg))
exit(1);
--
1.5.3.5.1822.g11971-dirty
^ permalink raw reply related
* Re: [PATCH 0/11] Miscellaneous MinGW port fallout
From: Johannes Schindelin @ 2007-11-14 14:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vir45hyyn.fsf@gitster.siamese.dyndns.org>
Hi,
On Wed, 14 Nov 2007, Junio C Hamano wrote:
> Johannes Sixt <johannes.sixt@telecom.at> writes:
>
> > This is a series of smallish, unrelated changes that were necessary
> > for the MinGW port.
>
> I was _VERY_ afraid of reviewing this series.
Why? Because we get closer to MinGW integration into git.git for real?
;-)
> > [PATCH 05/11] Use is_absolute_path() in sha1_file.c.
> > [PATCH 06/11] Move #include <sys/select.h> and <sys/ioctl.h> to
> > git-compat-util.h.
> >
> > These two are certainly undisputed.
>
> Except on esoteric/broken systems there might be some dependency
> on the order the system include files are included, so 06/11
> needs some testing. But it is a change in the right direction.
The safe thing, of course, would be to move them at the end of the include
list in git-compat-util.h, since they are now included after cache.h,
(which includes git-compat-util.h and only strbuf.h, the sha1 header and
zlib.h).
This way it should be really certainly undisputed.
> > [PATCH 08/11] Close files opened by lock_file() before unlinking.
> >
> > This one was authored by Dscho. It is a definite MUST on Windows.
>
> This was something we've talked about doing a few times on the
> list but did not. It is good that this saw some testing in the
> field, as it is easy to get wrong while moving the call site of
> close(2) around.
Note that we are not strictly _moving_ it around. In fact, we are _adding_
more close() calls... And even ignoring the errors when close() was
already called, so it feels a tad hacky. But it does the job.
> > [PATCH 09/11] Allow a relative builtin template directory.
> > [PATCH 10/11] Introduce git_etc_gitconfig() that encapsulates access
> > of ETC_GITCONFIG.
> > [PATCH 11/11] Allow ETC_GITCONFIG to be a relative path.
> >
> > These need probably some discussion. They avoid that $(prefix) is
> > hardcoded and so allows that an arbitrary installation directory.
>
> I had to worry a bit about bootstrapping issues in 11/11. We
> need to ensure that anybody who wants to read the configuration
> data first does setup_path() because git_exec_path() reads from
> argv_exec_path and setup_path() is what assigns to that
> variable.
Just to be safe in the future, we could check for that condition (by
introducing a static variable setup_path_called) and die() should anybody
introduce a code path where the order of calls is not maintained.
> But other than that and 08/11, I found everything is trivially correct
> and it was a pleasant read.
Me, too.
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