* Re: [StGit PATCH 0/5] A few small fixes
From: Catalin Marinas @ 2007-11-12 11:02 UTC (permalink / raw)
To: Karl Hasselström; +Cc: git, David Kågedal
In-Reply-To: <20071111193545.18868.62490.stgit@yoghurt>
On 11/11/2007, Karl Hasselström <kha@treskal.com> wrote:
> These are available from
>
> git://repo.or.cz/stgit/kha.git safe
Thanks. Merged.
> Let some commands work with detached HEAD
[...]
> stgit/commands/add.py | 2
My plan after 0.14 is to remove the implementation of add/rm etc.
commands. I'd like to keep them as just synonyms to the equivalent git
commands which stgit would invoke (this is mainly for convenience as I
usually type "stg" rather than "git").
BTW, I'll review this week the bugs already logged and clean as many
as possible (help appreciated :-)) and try to release 0.14 in 1-2
weeks.
--
Catalin
^ permalink raw reply
* Re: git push mirror mode V4 (replacement stack)
From: Andy Whitcroft @ 2007-11-12 11:00 UTC (permalink / raw)
To: git, Junio C Hamano; +Cc: Johannes Schindelin
In-Reply-To: <20071109233041.GC301@shadowen.org>
On Fri, Nov 09, 2007 at 11:30:41PM +0000, Andy Whitcroft wrote:
> Following this mail is a complete replacement git push mirror mode
> stack (V4). It folds down all the various patches into a logical
> sequence (thanks Dscho). This stack passes the entire test suite,
> and I have been using the same code for real work here.
Ok, I have spotted one oddity with this feature. The symbolic refs are
getting converted to real refs in the mirror. Generally speaking this
is the <remote>/HEAD refs but I guess it may be possible to have others.
I have had a looked about and I am actually confused as to whether we
maintain remote symbolic refs at all? Cirtainly git-clone.sh seems to
do some hoop jumping, comparing the sha1's of all of the fetched branches
and replacing the HEAD reference with a symbolic reference should it find
a match.
I am unsure if this a huge problem or not. Its not preventing me using
it as an effective mirror, but if we assume one is making the mirror as
a backup, then there would be slightly more than an rsync to convert the
the repo back into your original, though I guess there already is as you
would want to insert your config into the remote also.
Perhaps someone with a better understanding could point me to where we
we maintain these refs, if we indeed do?
-apw
^ permalink raw reply
* Re: git diff woes
From: Johannes Schindelin @ 2007-11-12 10:50 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <47382C84.50408@op5.se>
Hi,
On Mon, 12 Nov 2007, Andreas Ericsson wrote:
> Johannes Schindelin wrote:
>
> > And sure you can trust the hunk header. Like most of the things, the
> > relate to the _original_ version, since the diff is meant to be
> > applied as a forward patch.
> >
> > So for all practical matters, the diff shows the correct thing: "in
> > this hunk, which (still) belongs to that function, change this and
> > this."
> >
> > Of course, that is only the case if you accept that the diff should be
> > applied _in total_, not piecewise. IOW if you are a fan of GNU patch
> > which happily clobbers your file until it fails with the last hunk,
> > you will not be happy.
> >
>
> You're right. GNU patch will apply one hunk and then happily churn on
> even if it fails. git-apply will apply all hunks or none, so all hunks
> can assume that all previous hunks were successfully applied. So what
> was your point again?
My point was that this diff is not to be read as if the previous hunks had
been applied. Just look at the context: it is also the original file.
It seems I am singularly unable to explain plain concepts as this: a diff
assumes that the file is yet unchanged.
So I'll stop.
Ciao,
Dscho
^ permalink raw reply
* Re: cogito remote branch
From: MichaelTiloDressel @ 2007-11-12 10:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711120954460.4362@racer.site>
Johannes Schindelin wrote:
>> A push is needed somewhere in order to prevent every remote to be
pushed
>> by default, right?
>You mean a "push" config variable? No. I think I mentioned in my
first
>reply that
> git push <remote> <branch>...
>works quite wonderfully.
I mean a push = .. line in the [remote <name>] block.
And if there is such a line than git-push without arguments will push
only
the current branch. For me that is nice, because if I forgot to give
an argument to git-push it will not push other branches.
If there is no such line all the remotes (that don't have a push line?)
get pushed.
Cheers,
Michael
^ permalink raw reply
* Re: git diff woes
From: Andreas Ericsson @ 2007-11-12 10:35 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0711120958500.4362@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 12 Nov 2007, Andreas Ericsson wrote:
>
>> I recently ran into an oddity with the excellent git diff output
>> format. When a function declaration changes in the same patch as
>> something else in a function, the old declaration is used with the
>> diff hunk-headers.
>>
>> [...]
>>
>> It definitely looks like a bug, but really isn't, since an earlier hunk
>> (pasted below) changes the declaration.
>>
>> [...]
>>
>> This makes it impossible to trust the hunk-header info if the declaration
>> changes.
>
> Huh? You admit yourself that it is not a bug.
In the check_ntpd.c program, there is no bug. I found the git diff output
surprising, so I reported it.
> And sure you can trust the
> hunk header. Like most of the things, the relate to the _original_
> version, since the diff is meant to be applied as a forward patch.
>
> So for all practical matters, the diff shows the correct thing: "in this
> hunk, which (still) belongs to that function, change this and this."
>
> Of course, that is only the case if you accept that the diff should be
> applied _in total_, not piecewise. IOW if you are a fan of GNU patch
> which happily clobbers your file until it fails with the last hunk, you
> will not be happy.
>
You're right. GNU patch will apply one hunk and then happily churn on even
if it fails. git-apply will apply all hunks or none, so all hunks can assume
that all previous hunks were successfully applied. So what was your point
again?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Mike Hommey @ 2007-11-12 10:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Theodore Tso, Git Mailing List
In-Reply-To: <7vhcjr53hp.fsf@gitster.siamese.dyndns.org>
On Sun, Nov 11, 2007 at 11:26:10PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > My mental model for git newbies is that they would probably be pulling
> > from upstream repositories (so I was tempted to remove git-init from
> > the common commands list), but they would rarely be cherry-picking or
> > reverting other people's changes.
>
> I'd agree with that, but reverting and cherry-picking would also
> be done on the commits the user builds on top of other people's
> changes.
On the other hand, cherry-picking and reverting are just the same thing,
except one applies a reversed patch. Wouldn't it make sense to merge these
two in one command ?
Mike
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Andreas Ericsson @ 2007-11-12 10:21 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20071112062222.GA17462@thunk.org>
Theodore Tso wrote:
>
> They probably would be submitting changes back upstream using e-mail
> before they learn how to publish their own repository, so commands I'd
> be tempted to add would include git-format-patch, git-send-email, and
> git-cherry. But these commands are pretty complicated for beginners....
>
git format-patch could probably go in, but skip the others. I've never
used git cherry in my entire life and it's not, strictly speaking,
necessary for users to have it. There are other and easier ways to
find the same information.
I'd keep cherry-pick though. It's incredibly useful, and especially
when a commit ends up on the wrong branch which is something newbies
are likely to do when they start trying out the topic-branch workflow.
I still do it sometimes, but hardly ever stop thinking about it since
it's so easy to fix thanks to cherry-pick.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Deprecate git-fetch-pack?
From: Andreas Ericsson @ 2007-11-12 10:15 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Schindelin, Junio C Hamano, Ask Bjørn Hansen,
Daniel Barkalow, git
In-Reply-To: <20071111235819.GB7392@thunk.org>
Theodore Tso wrote:
> On Sun, Nov 11, 2007 at 10:50:26PM +0000, Johannes Schindelin wrote:
>> I beg to differ. The biggest problem with a new user seeing all those
>> completions is that this user is scared.
>
> Well, if we introduce the new user only to "git subcomand", and the
> documentation is relatively gentle, I would suspect would solve most
> of the problem. Note BTW, that if your thesis is true, "git help -a"
> (which is recommended in the last line of output by "git help") should
> cause the typical new user to faint dead away. :-)
>
> Some other areas that would be worth fixing, in terms of user usability.
>
> 1) The references to the tutorial, everyday git, etc., don't actually
> have working references in the git man page. (i.e., what you see when
> you run the command "man git"). It would be nice if that were fixed.
>
> 2) The command which are displayed by "git help" should use some
> serious rethinking. Ideally, it would be nice if the output fit in a
> single 24-line terminal window. Some candidates for removal:
>
> a) prune: "git prune" definitely doesn't deserve to be on the
> front and center as displayed by "git help". Maybe replace it
> with "gc", but now that we have gc.auto, I'm not sure it's
> worth it at all.
>
prune is definitely scary, and users don't need to know about it until
they've worked with git for quite some time.
> b) revert: Is that really that common of a command?
>
I think I've used it once ;-)
> c) show-branch: The output is terrifying without explanation
>
Indeed. I still don't grok it fully. I tend to use gitk/qgit and some
brainpower to obtain the same result.
> There are other commands I'm not so sure about, but it is worth
> flagging them. One way that might be helpful is to group the commands
> into subcommands, much like gdb does, so you could do something like
> "git help other-repos" (where all commands that involve interacting
> with other repositories are summarized), and so on.
>
Ack on that. I suggested it a while back and it appears many liked the
idea. I'm really bad at writing docs though, so it's one of those things
I've been putting off for "some other day".
>> But yes, I was only proposing to deprecate all usage of git-<bla> in the
>> documentation.
>
> I agree that de-emphasizing git-<blah> isn't a bad thing. But I think
> we need to look at the big picture here, since "git help" is often one
> of the first things a new user might try (and obviously very few git
> developers look at it, or "prune" probably would have been removed
> from git help a long time ago :-), and the last thing that git help
> suggests (and so therefore it will very visible to the newbie user),
> is "git help -a" --- and that displays every single git command under
> creation, porcelain or plumbing, in one gigantic sorted list.
>
> Oops, so much for first impressions. :-)
>
I agree. Culling the list output by "git help -a" to only show the
porcelain commands would definitely be worthwhile. I'm not sure if it's
worth having a way of showing every installed git command at all (I
know I've never used it anyway).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Fix preprocessor logic that determines the availablity of strchrnul().
From: Johannes Sixt @ 2007-11-12 10:09 UTC (permalink / raw)
To: David Symonds, Junio C Hamano
Cc: Andreas Ericsson, René Scharfe, Pierre Habouzit,
Git Mailing List, Johannes Schindelin, Jakub Narebski
In-Reply-To: <ee77f5c20711120152i4955ed3bh484c9ac76a7f1f5c@mail.gmail.com>
Apart from the error in the condition (&& should actually be ||), the
construct
#if !defined(A) || !A
leads to a syntax error in the C preprocessor if A is indeed not defined.
Tested-by: David Symonds <dsymonds@gmail.com>
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-compat-util.h | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index 3d147b6..276a437 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -184,7 +184,13 @@ void *gitmemmem(const void *haystack, size_t haystacklen,
const void *needle, size_t needlelen);
#endif
-#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
+#ifdef __GLIBC_PREREQ
+#if __GLIBC_PREREQ(2, 1)
+#define HAVE_STRCHRNUL
+#endif
+#endif
+
+#ifndef HAVE_STRCHRNUL
#define strchrnul gitstrchrnul
static inline char *gitstrchrnul(const char *s, int c)
{
--
1.5.3.5.578.g1f8ec
^ permalink raw reply related
* Re: [PATCH] Simplify strchrnul() compat code
From: Jakub Narebski @ 2007-11-12 10:07 UTC (permalink / raw)
To: git
In-Reply-To: <ee77f5c20711120152i4955ed3bh484c9ac76a7f1f5c@mail.gmail.com>
David Symonds wrote:
> On Nov 12, 2007 8:50 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> -#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
>> +#ifdef __GLIBC_PREREQ
>> +#if __GLIBC_PREREQ(2, 1)
>> +#define HAVE_STRCHRNUL
>> +#endif
>> +#endif
>> +
>> +#ifndef HAVE_STRCHRNUL
>>
>> #define strchrnul gitstrchrnul
>> static inline char *gitstrchrnul(const char *s, int c)
>> {
>
> Yep, that works just fine. Ack.
This version has also the following advantage that you can set
HAVE_STRCHRNULL if above test does not detect it in your library.
Althought you'd better write then:
+#if __GLIBC_PREREQ(2, 1) && !defined(HAVE_STRCHRNUL)
Ack.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Johannes Sixt @ 2007-11-12 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ping Yin, git
In-Reply-To: <7vabpliz13.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> I also find "<<< lines then >>> other lines" format very hard to
> read. Maybe formatting it like this would make it a bit more
> readable and more space efficient?
>
> # * sm1 354cd45...3f751e5:
> # - one line message for C
> # - one line message for B
> # + one line message for D
> # + one line message for E
> # * sm2 5c8bfb5...ac46d84:
> # - msg
How about the equivalent of
git log --left-right --pretty=oneline --topo-order 354cd45...3f751e5
which would be
# * sm1 354cd45...3f751e5:
# <one line message for C
# <one line message for B
# >one line message for D
# >one line message for E
-- Hannes
^ permalink raw reply
* Re: git diff woes
From: Johannes Schindelin @ 2007-11-12 10:01 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Git Mailing List
In-Reply-To: <4738208D.1080003@op5.se>
Hi,
On Mon, 12 Nov 2007, Andreas Ericsson wrote:
> I recently ran into an oddity with the excellent git diff output
> format. When a function declaration changes in the same patch as
> something else in a function, the old declaration is used with the
> diff hunk-headers.
>
> [...]
>
> It definitely looks like a bug, but really isn't, since an earlier hunk
> (pasted below) changes the declaration.
>
> [...]
>
> This makes it impossible to trust the hunk-header info if the declaration
> changes.
Huh? You admit yourself that it is not a bug. And sure you can trust the
hunk header. Like most of the things, the relate to the _original_
version, since the diff is meant to be applied as a forward patch.
So for all practical matters, the diff shows the correct thing: "in this
hunk, which (still) belongs to that function, change this and this."
Of course, that is only the case if you accept that the diff should be
applied _in total_, not piecewise. IOW if you are a fan of GNU patch
which happily clobbers your file until it fails with the last hunk, you
will not be happy.
Ciao,
Dscho
^ permalink raw reply
* Re: cogito remote branch
From: Johannes Schindelin @ 2007-11-12 9:55 UTC (permalink / raw)
To: MichaelTiloDressel@t-online.de; +Cc: git
In-Reply-To: <1IrUDz-01jF4a0@fwd29.aul.t-online.de>
Hi,
On Mon, 12 Nov 2007, MichaelTiloDressel@t-online.de wrote:
> So just a line like
> push = master
Exactly.
> A push is needed somewhere in order to prevent every remote to be pushed
> by default, right?
You mean a "push" config variable? No. I think I mentioned in my first
reply that
git push <remote> <branch>...
works quite wonderfully.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Simplify strchrnul() compat code
From: David Symonds @ 2007-11-12 9:52 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Andreas Ericsson, René Scharfe,
Pierre Habouzit, Git Mailing List, Johannes Schindelin,
Jakub Narebski
In-Reply-To: <473821CE.8050907@viscovery.net>
On Nov 12, 2007 8:50 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> David Symonds schrieb:
> > On Nov 12, 2007 8:12 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> >> David Symonds schrieb:
> >>> I don't think I have __GLIBC_PREREQ defined anywhere I can find.
> >> Turn the && in that line into || and it should work.
> >
> > Nope, no dice. Plus, that'd change the logic. I also tried turning the
> > (!X && !Y) into (X || Y) to no avail.
>
> Ok, then how about this?
>
> ---
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 3d147b6..276a437 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -184,7 +184,13 @@ void *gitmemmem(const void *haystack,
> const void *needle, size_t needlelen);
> #endif
>
> -#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
> +#ifdef __GLIBC_PREREQ
> +#if __GLIBC_PREREQ(2, 1)
> +#define HAVE_STRCHRNUL
> +#endif
> +#endif
> +
> +#ifndef HAVE_STRCHRNUL
>
> #define strchrnul gitstrchrnul
> static inline char *gitstrchrnul(const char *s, int c)
> {
Yep, that works just fine. Ack.
Dave.
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Johannes Schindelin @ 2007-11-12 9:51 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Yin Ping, git
In-Reply-To: <47380019.1000704@viscovery.net>
Hi,
On Mon, 12 Nov 2007, Johannes Sixt wrote:
> Junio C Hamano schrieb:
>
> > I am not saying that it is wrong to use submodule to track such groups
> > of source trees whose versions are very closely tied together. At
> > least not yet.
>
> In KDE, the supermodule will actually just be a container that binds the
> submodules together. The essential development will happen in the
> submodules, and the supermodule will receive a commit quite frequently.
> In this case, there will often be only a few or a few dozen commits
> listed, and I anticipate that the integrator who is going to make the
> commit (to the supermodule) will probably like the summary. So I'm all
> for it.
I like it, too. And we can make the number of shown commits configurable,
just like for the merge summary. But I'd rather see the code in
wt-status.c than in git-submodule.sh.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Simplify strchrnul() compat code
From: Johannes Sixt @ 2007-11-12 9:50 UTC (permalink / raw)
To: David Symonds
Cc: Junio C Hamano, Andreas Ericsson, René Scharfe,
Pierre Habouzit, Git Mailing List, Johannes Schindelin,
Jakub Narebski
In-Reply-To: <ee77f5c20711120124m6281fddfs9403a46cf354b993@mail.gmail.com>
David Symonds schrieb:
> On Nov 12, 2007 8:12 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
>> David Symonds schrieb:
>>> I don't think I have __GLIBC_PREREQ defined anywhere I can find.
>> Turn the && in that line into || and it should work.
>
> Nope, no dice. Plus, that'd change the logic. I also tried turning the
> (!X && !Y) into (X || Y) to no avail.
Ok, then how about this?
---
diff --git a/git-compat-util.h b/git-compat-util.h
index 3d147b6..276a437 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -184,7 +184,13 @@ void *gitmemmem(const void *haystack,
const void *needle, size_t needlelen);
#endif
-#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
+#ifdef __GLIBC_PREREQ
+#if __GLIBC_PREREQ(2, 1)
+#define HAVE_STRCHRNUL
+#endif
+#endif
+
+#ifndef HAVE_STRCHRNUL
#define strchrnul gitstrchrnul
static inline char *gitstrchrnul(const char *s, int c)
{
^ permalink raw reply related
* git diff woes
From: Andreas Ericsson @ 2007-11-12 9:44 UTC (permalink / raw)
To: Git Mailing List
I recently ran into an oddity with the excellent git diff output
format. When a function declaration changes in the same patch as
something else in a function, the old declaration is used with the
diff hunk-headers.
Consider this hunk:
---%<---%<---%<---
@@ -583,75 +346,100 @@ double jitter_request(const char *host, int *status){
if(verbose) printf("%d candiate peers available\n", num_candidates);
if(verbose && syncsource_found) printf("synchronization source found\n")
if(! syncsource_found){
- *status = STATE_UNKNOWN;
+ status = STATE_WARNING;
if(verbose) printf("warning: no synchronization source found\n")
}
---%<---%<---%<---
It definitely looks like a bug, but really isn't, since an earlier hunk
(pasted below) changes the declaration. There were several hunks between
these two, so it was far from obvious when I saw it first.
---%<---%<---%<---
@@ -517,19 +276,22 @@ setup_control_request(ntp_control_message *p, uint8_t opco
}
/* XXX handle responses with the error bit set */
-double jitter_request(const char *host, int *status){
- int conn=-1, i, npeers=0, num_candidates=0, syncsource_found=0;
- int run=0, min_peer_sel=PEER_INCLUDED, num_selected=0, num_valid=0;
+int ntp_request(const char *host, double *offset, int *offset_result, double *j
+ int conn=-1, i, npeers=0, num_candidates=0;
+ int min_peer_sel=PEER_INCLUDED;
int peers_size=0, peer_offset=0;
+ int status;
---%<---%<---%<---
This makes it impossible to trust the hunk-header info if the declaration
changes. It might be better to not write it out when the header-line is
also part of the patch. That would at least force one to go back and find
the real declaration. Best would probably be to write the new declaration,
but I'm unsure if that could cause some other confusion.
I haven't started looking into it yet, and as I'm sure there are others
who are much more familiar with the xdiff code I'm shamelessly hoping
someone will beat me to a fix.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Documentation: Fix references to deprecated commands
From: Jonas Fonseca @ 2007-11-12 9:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <7vbq9z50vj.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote Mon, Nov 12, 2007:
> Jonas Fonseca <fonseca@diku.dk> writes:
>
> > diff --git a/Documentation/git-get-tar-commit-id.txt b/Documentation/git-get-tar-commit-id.txt
> > index 9b5f86f..ef1b19c 100644
> > --- a/Documentation/git-get-tar-commit-id.txt
> > +++ b/Documentation/git-get-tar-commit-id.txt
> > @@ -14,12 +14,12 @@ SYNOPSIS
> > DESCRIPTION
> > -----------
> > Acts as a filter, extracting the commit ID stored in archives created by
> > -git-tar-tree. It reads only the first 1024 bytes of input, thus its
> > +gitlink:git-archive[1]. It reads only the first 1024 bytes of input, thus its
> > runtime is not influenced by the size of <tarfile> very much.
> >
> > If no commit ID is found, git-get-tar-commit-id quietly exists with a
> > return code of 1. This can happen if <tarfile> had not been created
> > -using git-tar-tree or if the first parameter of git-tar-tree had been
> > +using git-archive or if the <treeish> parameter of git-archive had been
> > a tree ID instead of a commit ID or tag.
> >
> > --
> > Jonas Fonseca
>
> How did you prepare this hunk? I count 10 lines preimage and
> postimage, followed by a blank line and the signature separator
> "-- " you added in your MUA, but the header claims to have 12
> lines.
I am sorry to cause you this kind of problems. Usually I keep the patch
ending inserted by format-patch, but yesterday I deleted it for some
unknown reason. Maybe I should learn to use git-send-email.
--
Jonas Fonseca
^ permalink raw reply
* Re: [PATCH] Simplify strchrnul() compat code
From: David Symonds @ 2007-11-12 9:24 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, Andreas Ericsson, René Scharfe,
Pierre Habouzit, Git Mailing List, Johannes Schindelin,
Jakub Narebski
In-Reply-To: <473818FA.1060400@viscovery.net>
On Nov 12, 2007 8:12 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> David Symonds schrieb:
> > On Nov 11, 2007 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> >> @@ -183,7 +183,7 @@ void *gitmemmem(const void *haystack, size_t haystacklen,
> >> const void *needle, size_t needlelen);
> >> #endif
> >>
> >> -#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
> >> +#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
> >> #define strchrnul gitstrchrnul
> >> static inline char *gitstrchrnul(const char *s, int c)
> >> {
> >
> > I just tested it on my machine (OS X Tiger) now that it's in 'next',
> > and this breaks the build:
> >
> > CC git.o
> > In file included from builtin.h:4,
> > from git.c:1:
> > git-compat-util.h:187:48: error: missing binary operator before token "("
> > make: *** [git.o] Error 1
> >
> >
> > I don't think I have __GLIBC_PREREQ defined anywhere I can find.
>
> Turn the && in that line into || and it should work.
Nope, no dice. Plus, that'd change the logic. I also tried turning the
(!X && !Y) into (X || Y) to no avail.
Dave.
^ permalink raw reply
* Re: [PATCH] Simplify strchrnul() compat code
From: Johannes Sixt @ 2007-11-12 9:12 UTC (permalink / raw)
To: David Symonds
Cc: Junio C Hamano, Andreas Ericsson, René Scharfe,
Pierre Habouzit, Git Mailing List, Johannes Schindelin,
Jakub Narebski
In-Reply-To: <ee77f5c20711120103s478e26cdib85f38293423d90c@mail.gmail.com>
David Symonds schrieb:
> On Nov 11, 2007 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> @@ -183,7 +183,7 @@ void *gitmemmem(const void *haystack, size_t haystacklen,
>> const void *needle, size_t needlelen);
>> #endif
>>
>> -#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
>> +#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
>> #define strchrnul gitstrchrnul
>> static inline char *gitstrchrnul(const char *s, int c)
>> {
>
> I just tested it on my machine (OS X Tiger) now that it's in 'next',
> and this breaks the build:
>
> CC git.o
> In file included from builtin.h:4,
> from git.c:1:
> git-compat-util.h:187:48: error: missing binary operator before token "("
> make: *** [git.o] Error 1
>
>
> I don't think I have __GLIBC_PREREQ defined anywhere I can find.
Turn the && in that line into || and it should work.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git-svn: prevent dcommitting if the index is dirty.
From: Benoit Sigoure @ 2007-11-12 9:11 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20071112022851.GA25675@mayonaise>
[-- Attachment #1: Type: text/plain, Size: 1509 bytes --]
On Nov 12, 2007, at 3:28 AM, Eric Wong wrote:
> Benoit Sigoure <tsuna@lrde.epita.fr> wrote:
>> dcommit uses rebase `sync' the history with what has just been
>> pushed to
>> SVN. Trying to dcommit with a dirty index is troublesome for
>> rebase, so now
>> the user will get an error message if he attempts to dcommit with
>> a dirty
>> index.
>>
>> Signed-off-by: Benoit Sigoure <tsuna@lrde.epita.fr>
>
> Thanks,
>
> Minor nit below about indentation (which Junio can fix when applying),
> but nevertheless:
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
>
>> ---
>> git-svn.perl | 3 +++
>> t/t9106-git-svn-dcommit-clobber-series.sh | 6 ++++++
>> 2 files changed, 9 insertions(+), 0 deletions(-)
>>
>> diff --git a/git-svn.perl b/git-svn.perl
>> index dd93e32..a15df4f 100755
>> --- a/git-svn.perl
>> +++ b/git-svn.perl
>> @@ -390,6 +390,9 @@ sub cmd_set_tree {
>>
>> sub cmd_dcommit {
>> my $head = shift;
>> + git_cmd_try { command_oneline(qw/diff-index --quiet HEAD/) }
>> + 'Cannot dcommit with a dirty index. Commit your
>> changes first'
>> + . "or stash them with `git stash'.\n";
>
> We use tabs for indentation, and spaces for alignment.
Yes, sorry again, would you consider to add `# vi: set noexpandtab:'
at the end of the file so that ViM users (like me) don't have to
think about it? (it tells ViM to NOT expand tabs to series of spaces)
--
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: [PATCH] Simplify strchrnul() compat code
From: David Symonds @ 2007-11-12 9:03 UTC (permalink / raw)
To: Junio C Hamano
Cc: Andreas Ericsson, René Scharfe, Pierre Habouzit,
Git Mailing List, Johannes Schindelin, Jakub Narebski
In-Reply-To: <7v6409f4eh.fsf@gitster.siamese.dyndns.org>
On Nov 11, 2007 9:44 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Andreas Ericsson <ae@op5.se> writes:
>
> > René Scharfe wrote:
> >> -#ifdef NO_STRCHRNUL
> >> +#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
> >
> > This will break things for users of glibc-2.1.1 (the first release still
> > available from ftp://sources.redhat.com/pub/glibc/old-releases that
> > includes the strchrnul() function), since __GLIBC_PREREQ() was invented
> > after strchrnul() was introduced.
> >
> > Replacing __GLIBC__ with __GLIBC_PREREQ (as in the original patch) will
> > solve it nicely. Users of glibc-2.1.1 will be the odd minority where
> > strchrnul() is available in their libc but not used.
>
> Do you mean this on top of René's patch? Although I do not
> think I saw "the original patch" that did it this way, I think
> it makes sense.
>
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 11e6df6..dd96f7a 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -183,7 +183,7 @@ void *gitmemmem(const void *haystack, size_t haystacklen,
> const void *needle, size_t needlelen);
> #endif
>
> -#if !defined(__GLIBC__) && !__GLIBC_PREREQ(2, 1)
> +#if !defined(__GLIBC_PREREQ) && !__GLIBC_PREREQ(2, 1)
> #define strchrnul gitstrchrnul
> static inline char *gitstrchrnul(const char *s, int c)
> {
I just tested it on my machine (OS X Tiger) now that it's in 'next',
and this breaks the build:
CC git.o
In file included from builtin.h:4,
from git.c:1:
git-compat-util.h:187:48: error: missing binary operator before token "("
make: *** [git.o] Error 1
I don't think I have __GLIBC_PREREQ defined anywhere I can find.
Dave.
^ permalink raw reply
* Re: [PATCH] git-clean: Fix error message if clean.requireForce is not set.
From: Johannes Sixt @ 2007-11-12 8:41 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Junio C Hamano, Git Mailing List, Shawn Bohrer
In-Reply-To: <20071112083352.GA20482@artemis.corp>
Pierre Habouzit schrieb:
> On Mon, Nov 12, 2007 at 08:27:35AM +0000, Johannes Sixt wrote:
>> It was distracting to see this error message:
>>
>> clean.requireForce set and -n or -f not given; refusing to clean
>>
>> even though clean.requireForce was not set at all. This patch
>> distinguishes
>> the cases and gives a different message depending on whether the
>> configuration variable is not set or set to true.
>
> Note that your patch won't apply to next as is :)
You mean because of the builtinification of git-clean? I was hoping that
Shawn (Bohrer) is listening and will update his patch. ;) It has the same
problem.
-- Hannes
^ permalink raw reply
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Johan Herland @ 2007-11-12 8:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Yin Ping
In-Reply-To: <7vhcjscyhu.fsf@gitster.siamese.dyndns.org>
On Sunday 11 November 2007, Junio C Hamano wrote:
> "Yin Ping" <pkufranky@gmail.com> writes:
>
> > I think it's this kind of case in most open-source project. However,
> > in a company environment, superprojects may be not so super.
>
> Let's not say "most open-source" nor "company", because I think
> nobody said anything that substantiates that the commit density
> characteristics I described is typical for most open-source, nor
> what you said is typical for corporate development projects, in
> this thread so far.
>
> If "superprojects is not so super", why are you using submodule
> to bind these, instead of using a single project that tracks
> developments of such closely tied parts?
>
> I am not saying that it is wrong to use submodule to track such
> groups of source trees whose versions are very closely tied
> together. At least not yet.
>
> I am just trying to find out what benefit you are getting out of
> the submodule support, after rejecting one of the most visible
> and advertised benefit of submodule support, which is to enable
> binding "related but not that closely tied together" projects.
At $dayjob, we are working on a codebase roughly the same size as current
linux-kernel with about 8 years of history in CVS. I'm currently looking at
how suitable git would be for our revision control purposes (and so far I'm
lovin' it).
The codebase is divided into CVS modules; most modules (aka. "core" modules)
each have their own in-house maintainer and have internal releases with
variable frequency. The other modules (aka. "platform/product" modules)
each pull together a carefully chosen set of "core" modules as submodules,
and add platform code to create - in the end - a complete product (with its
own release frequency). Specifically:
- All the modules required by the product must be present in the checkout
before a build can be made
- All the modules are independently developed, with different
development/release timelines
- The "core" people only focus on 1-2 modules at a time, but
the "platform/product" people might make changes in _many_ modules during a
workday.
When investigating how to mesh this workflow with git, I naturally ended up
with converting each CVS module to a git repository, and making
the "platform/product" repos include the required "core" repos as
submodules. This decision has the following effect from git's POV:
- "superproject is not so super" in that _all_ required modules must be
checked out before a build can be made. In other words: all the submodules
in a repo are "interesting"
- The modules are "related but not that closely tied together" since they
follow separate development schedules, with separate releases, etc.
- The "platform/product" people will most certainly want to have commands
like "git diff", "git status", and maybe even "git log" and "git-commit"
recurse into submodules.
- The "core" people will probably not want "recurse-into-submodules"
behaviour, although I can see places where it could be useful for them as
well.
A possible solution to the above problem is to add
a '--recurse-into-submodules' option to all relevant git commands. At the
same time, the actual implementation of submodule recursion should probably
be kept in the vicinity of "git-submodule" (instead of spreading it across
the other git commands).
Probably unrealistic: Maybe we could solve the problem by adding
"--recurse-into-submodules" to the toplevel 'git' command itself, and make
it re-invoke itself recursively in each submodule.
Hope this gives you insight into how _some_ people would like to use git's
submodule support.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [PATCH] git-clean: Fix error message if clean.requireForce is not set.
From: Pierre Habouzit @ 2007-11-12 8:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <47380E77.9040205@viscovery.net>
[-- Attachment #1: Type: text/plain, Size: 631 bytes --]
On Mon, Nov 12, 2007 at 08:27:35AM +0000, Johannes Sixt wrote:
> It was distracting to see this error message:
>
> clean.requireForce set and -n or -f not given; refusing to clean
>
> even though clean.requireForce was not set at all. This patch
> distinguishes
> the cases and gives a different message depending on whether the
> configuration variable is not set or set to true.
Note that your patch won't apply to next as is :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ 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