* 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
* [PATCH] git-clean: Fix error message if clean.requireForce is not set.
From: Johannes Sixt @ 2007-11-12 8:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
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.
While we are here, we also divert the error messages to stderr.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-clean.sh | 24 +++++++++++++++---------
1 files changed, 15 insertions(+), 9 deletions(-)
diff --git a/git-clean.sh b/git-clean.sh
index f4965b8..7138fae 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -25,10 +25,7 @@ rmrf="rm -rf --"
rm_refuse="echo Not removing"
echo1="echo"
-# requireForce used to default to false but now it defaults to true.
-# IOW, lack of explicit "clean.requireForce = false" is taken as
-# "clean.requireForce = true".
-disabled=$(git config --bool clean.requireForce || echo true)
+disabled=$(git config --bool clean.requireForce)
while test $# != 0
do
@@ -37,10 +34,10 @@ do
cleandir=1
;;
-f)
- disabled=
+ disabled=false
;;
-n)
- disabled=
+ disabled=false
rmf="echo Would remove"
rmrf="echo Would remove"
rm_refuse="echo Would not remove"
@@ -68,10 +65,19 @@ do
shift
done
-if [ "$disabled" = true ]; then
- echo "clean.requireForce set and -n or -f not given; refusing to clean"
+# requireForce used to default to false but now it defaults to true.
+# IOW, lack of explicit "clean.requireForce = false" is taken as
+# "clean.requireForce = true".
+case "$disabled" in
+"")
+ echo >&2 "clean.requireForce not set and -n or -f not given; refusing to clean"
exit 1
-fi
+ ;;
+"true")
+ echo >&2 "clean.requireForce set and -n or -f not given; refusing to clean"
+ exit 1
+ ;;
+esac
case "$ignored,$ignoredonly" in
1,1) usage;;
--
1.5.3.5.1368.g3cabf
^ permalink raw reply related
* Re: [PATCH] Documentation: Fix references to deprecated commands
From: Junio C Hamano @ 2007-11-12 8:22 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Andreas Ericsson, Johannes Schindelin, git
In-Reply-To: <20071112003251.GB21970@diku.dk>
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.
^ permalink raw reply
* Re: cogito remote branch
From: MichaelTiloDressel @ 2007-11-12 8:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711111520260.4362@racer.site>
(I forgot to put the subject previously)
> Johannes Schindelin wrote:
>Hi,
>On Sun, 11 Nov 2007, Michael Dressel wrote:
>>
>> >Michael Dressel wrote:
>> >Ok nice. Another thing is that git-push will push all the tracking
>> >branches in refs/remotes/origin.
>>
>> I learned that I only have to edit the .git/config file to avoid that
>> git-push pushes everything.
>It is documented that you can use "git push origin ".
>> [remote "origin1"]
>> url = /home/repo/src
>> fetch = +refs/heads/master:refs/remotes/origin/master
>> push = +refs/heads/master:refs/heads/master
>With "push", it is not necessary to specify the ":".
So just a line like
push = master
A push is needed somewhere in order to prevent every remote to be pushed
by default,
right?
>Also, if "master" is unambiguous, you can write just "master" instead
of
>"refs/heads/master".
>Furthermore, I suggest not forcing (that's what "+" does) the push,
since
>it is quite possible that you push something old in the wrong
direction.
O.k. I will reconsider this.
Cheers,
Michael
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Ask Bjørn Hansen @ 2007-11-12 7:57 UTC (permalink / raw)
To: Theodore Tso; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20071112062222.GA17462@thunk.org>
On Nov 11, 2007, at 10:22 PM, 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....
Maybe split it into sections? I'm all for making it appear simpler,
but not for hiding the power features of git too much. :-)
"These are basic local commands"
"This is what you need to interact with a remote repository"
"This is what you need for branching and merging"
"This is what you need to make, manage and apply patches"
- ask
--
http://develooper.com/ - http://askask.com/
^ permalink raw reply
* [PATCH] git-svn: support for funky branch and project names over HTTP(S)
From: Eric Wong @ 2007-11-12 7:37 UTC (permalink / raw)
To: Michael J. Cohen; +Cc: Git Mailing List
In-Reply-To: <654A4D1D-712F-4978-9812-E8FA411FAE0D@mac.com>
SVN requires that paths be URI-escaped for HTTP(S) repositories.
file:// and svn:// repositories do not need these rules.
Additionally, accessing individual paths inside repositories
(check_path() and get_log() do NOT require escapes to function
and in fact it breaks things).
Noticed-by: Michael J. Cohen <mjc@cruiseplanners.com>
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 24 ++++++++++++++++++-
t/t9118-git-svn-funky-branch-names.sh | 40 +++++++++++++++++++++++++++++++++
2 files changed, 62 insertions(+), 2 deletions(-)
create mode 100755 t/t9118-git-svn-funky-branch-names.sh
"Michael J. Cohen" <michaeljosephcohen@mac.com> wrote:
> mini:TextMateBundles mjc$ git-svn fetch
> Found possible branch point:
> http://macromates.com/svn/Bundles/trunk/Tools/Dialog PlugIn =>
> http://macromates.com/svn/Bundles/branches/Dialog PlugIn Completion Menu,
> 8089
> Initializing parent: Dialog PlugIn Completion Menu@8089
> Bad URL passed to RA layer: Malformed URL for repository at /opt/local/
> bin/git-svn line 1607
>
> looks like that might need to be %20 ?
>
> -mjc
diff --git a/git-svn.perl b/git-svn.perl
index 7589276..9ffda3e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3223,6 +3223,25 @@ sub _auth_providers () {
]
}
+sub escape_uri_only {
+ my ($uri) = @_;
+ my @tmp;
+ foreach (split m{/}, $uri) {
+ s/([^\w.-])/sprintf("%%%02X",ord($1))/eg;
+ push @tmp, $_;
+ }
+ join('/', @tmp);
+}
+
+sub escape_url {
+ my ($url) = @_;
+ if ($url =~ m#^(https?)://([^/]+)(.*)$#) {
+ my ($scheme, $domain, $uri) = ($1, $2, escape_uri_only($3));
+ $url = "$scheme://$domain$uri";
+ }
+ $url;
+}
+
sub new {
my ($class, $url) = @_;
$url =~ s!/+$!!;
@@ -3255,10 +3274,11 @@ sub new {
$Git::SVN::Prompt::_no_auth_cache = 1;
}
} # no warnings 'once'
- my $self = SVN::Ra->new(url => $url, auth => $baton,
+ my $self = SVN::Ra->new(url => escape_url($url), auth => $baton,
config => $config,
pool => SVN::Pool->new,
auth_provider_callbacks => $callbacks);
+ $self->{url} = $url;
$self->{svn_path} = $url;
$self->{repos_root} = $self->get_repos_root;
$self->{svn_path} =~ s#^\Q$self->{repos_root}\E(/|$)##;
@@ -3384,7 +3404,7 @@ sub gs_do_switch {
my $full_url = $self->{url};
my $old_url = $full_url;
- $full_url .= "/$path" if length $path;
+ $full_url .= '/' . escape_uri_only($path) if length $path;
my ($ra, $reparented);
if ($old_url ne $full_url) {
if ($old_url !~ m#^svn(\+ssh)?://#) {
diff --git a/t/t9118-git-svn-funky-branch-names.sh b/t/t9118-git-svn-funky-branch-names.sh
new file mode 100755
index 0000000..640bb06
--- /dev/null
+++ b/t/t9118-git-svn-funky-branch-names.sh
@@ -0,0 +1,40 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 Eric Wong
+#
+
+test_description='git-svn funky branch names'
+. ./lib-git-svn.sh
+
+test_expect_success 'setup svnrepo' "
+ mkdir project project/trunk project/branches project/tags &&
+ echo foo > project/trunk/foo &&
+ svn import -m '$test_description' project \"$svnrepo/pr ject\" &&
+ rm -rf project &&
+ svn cp -m 'fun' \"$svnrepo/pr ject/trunk\" \
+ \"$svnrepo/pr ject/branches/fun plugin\" &&
+ svn cp -m 'more fun!' \"$svnrepo/pr ject/branches/fun plugin\" \
+ \"$svnrepo/pr ject/branches/more fun plugin!\" &&
+ start_httpd
+ "
+
+test_expect_success 'test clone with funky branch names' "
+ git svn clone -s \"$svnrepo/pr ject\" project &&
+ cd project &&
+ git rev-parse 'refs/remotes/fun%20plugin' &&
+ git rev-parse 'refs/remotes/more%20fun%20plugin!' &&
+ cd ..
+ "
+
+test_expect_success 'test dcommit to funky branch' "
+ cd project &&
+ git reset --hard 'refs/remotes/more%20fun%20plugin!' &&
+ echo hello >> foo &&
+ git commit -m 'hello' -- foo &&
+ git svn dcommit &&
+ cd ..
+ "
+
+stop_httpd
+
+test_done
--
Eric Wong
^ permalink raw reply related
* Re: [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Johannes Sixt @ 2007-11-12 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yin Ping, git
In-Reply-To: <7vhcjscyhu.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> "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?
Because the a monolithic project is just too large? Think of KDE!
> 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.
-- Hannes
^ permalink raw reply
* Re: [PATCH,RFC 1/2] Make the list of common commands more exclusive
From: Junio C Hamano @ 2007-11-12 7:26 UTC (permalink / raw)
To: Theodore Tso; +Cc: Git Mailing List
In-Reply-To: <20071112062222.GA17462@thunk.org>
Theodore Tso <tytso@mit.edu> writes:
> On Sun, Nov 11, 2007 at 06:21:44PM -0800, Junio C Hamano wrote:
> ...
>> I am fine with this list, perhaps except apply.
>
> I was borderline on apply, but given that people are familiar with
> patch -p1, the only real advantage git-apply has is that automatically
> deals with new files (which "git commit -a" or "git add -u" won't
> automatically get).
Although more importantly git-apply is much more strict and
safer than patch by default, that distinction will probably not
register with total newbies; not much would be lost if we do not
list git-apply, I'd guess.
> What did you think about cherry-pick? Was that omitted by accident?
As "git show | git apply --index" would be good enough for
simple projects, omission of git-cherry-pick is not as serious
compared to ommission of git-revert, whose alternatives would be
"commit --amend" and "rebase" which are not suitable for
published history.
> 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.
> 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....
I'd half agree with that. People coming from CVS workflow will
be pushing and pulling from their central repositories, without
format-patch and send-email. For them revert would matter more
together with fetch, rebase and push.
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-11-12 7:09 UTC (permalink / raw)
To: git
In-Reply-To: <7vir4d40sw.fsf@gitster.siamese.dyndns.org>
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
----------------------------------------------------------------
[Will cook further in 'next' and then merge to 'master' soon]
* rs/pretty (Sat Nov 10 12:55:48 2007 +0100) 6 commits
+ Simplify strchrnul() compat code
+ --format=pretty: avoid calculating expensive expansions twice
+ add strbuf_adddup()
+ --pretty=format: parse commit message only once
+ --pretty=format: on-demand format expansion
+ Add strchrnul()
* np/progress (Thu Nov 8 15:45:41 2007 -0500) 7 commits
+ nicer display of thin pack completion
+ make display of total transferred fully accurate
+ remove dead code from the csum-file interface
+ git-fetch: be even quieter.
+ make display of total transferred more accurate
+ sideband.c: ESC is spelled '\033' not '\e' for portability.
+ fix display overlap between remote and local progress
* bg/format-patch-N (Tue Nov 6 10:04:24 2007 +1100) 3 commits
+ Rearrange git-format-patch synopsis to improve clarity.
+ format-patch: Test --[no-]numbered and format.numbered
+ format-patch: Add configuration and off switch for --numbered
* lt/rev-list-interactive (Mon Nov 5 13:22:34 2007 -0800) 4 commits
+ revision walker: mini clean-up
+ Enhance --early-output format
+ Add "--early-output" log flag for interactive GUI use
+ Simplify topo-sort logic
* db/remote-builtin (Tue Nov 6 20:29:20 2007 -0500) 6 commits
+ Reteach builtin-ls-remote to understand remotes
+ Build in ls-remote
+ Use built-in send-pack.
+ Build-in send-pack, with an API for other programs to call.
+ Build-in peek-remote, using transport infrastructure.
+ Miscellaneous const changes and utilities
With the "ls-remote origin" fix at its tip, this should be
ready.
* jk/terse-push (Thu Nov 8 01:38:12 2007 -0800) 7 commits
+ send-pack: segfault fix on forced push
+ send-pack: require --verbose to show update of tracking refs
+ receive-pack: don't mention successful updates
+ more terse push output
With the segfault fix at its tip, I think this is ready. This
depends on the early parts of db/remote-builtin series.
* jc/stash-create (Wed Nov 7 15:10:27 2007 -0600) 5 commits
+ git-stash: Fix listing stashes
+ git-merge: no reason to use cpio anymore
+ Revert "rebase: allow starting from a dirty tree."
+ rebase: allow starting from a dirty tree.
+ stash: implement "stash create"
The end result of this series is just to remove one use of cpio
in our scripts; this should be ready.
* gh/cvsimport-user (Thu Nov 8 13:15:20 2007 -0700) 1 commit
+ git-cvsimport: fix handling of user name when it is not set in
CVSROOT
* rr/cvsexportcommit-w (Wed Oct 31 23:12:20 2007 +0100) 1 commit
+ cvsexportcommit: Add switch to specify CVS workdir
* ds/checkout-upper (Fri Nov 9 20:12:28 2007 +1100) 2 commits
+ git-checkout: Test for relative path use.
+ git-checkout: Support relative paths containing "..".
This will allow you to stay in a subdirectory and checking out
paths in directories outside. With Dscho's "git status" that
shows relatives paths (in kh/commit series), this would make
cutting and pasting easier.
* mh/retag (Sun Nov 4 01:11:15 2007 +0100) 2 commits
+ Add tests for git tag
+ Reuse previous annotation when overwriting a tag
* jc/maint-add-sync-stat (Sun Nov 11 18:44:16 2007 -0800) 3 commits
+ t2200: test more cases of "add -u"
+ git-add: make the entry stat-clean after re-adding the same
contents
+ ce_match_stat, run_diff_files: use symbolic constants for
readability
Meant to eventually go to 'maint'. I added tests so now this
series can go to 'next'.
* bs/maint-t7005 (Sun Nov 11 18:38:11 2007 +0100) 1 commit
+ t7005-editor.sh: Don't invoke real vi when it is in GIT_EXEC_PATH
Meant to eventually go to 'maint'.
* sp/maint-plug-traverse-commit-list-leak (Fri Nov 9 06:06:10 2007 -0500) 1 commit
+ Fix memory leak in traverse_commit_list
Meant to eventually go to 'maint'.
* rv/maint-index-commit (Sun Nov 11 13:28:08 2007 +0100) 1 commit
+ Make GIT_INDEX_FILE apply to git-commit
Meant to eventually go to 'maint'. The test needs to be run
with Kristian's rewrite in C to catch any regression.
----------------------------------------------------------------
[Still actively cooking]
* ph/parseopt-sh (Thu Nov 8 23:04:31 2007 -0800) 16 commits
+ git-am: -i does not take a string parameter.
+ sh-setup: don't let eval output to be shell-expanded.
+ git-sh-setup: fix parseopt `eval` string underquoting
+ Give git-am back the ability to add Signed-off-by lines.
+ git-rev-parse --parseopt
+ scripts: Add placeholders for OPTIONS_SPEC
+ Migrate git-repack.sh to use git-rev-parse --parseopt
+ Migrate git-quiltimport.sh to use git-rev-parse --parseopt
+ Migrate git-checkout.sh to use git-rev-parse --parseopt --keep-
dashdash
+ Migrate git-instaweb.sh to use git-rev-parse --parseopt
+ Migrate git-merge.sh to use git-rev-parse --parseopt
+ Migrate git-am.sh to use git-rev-parse --parseopt
+ Migrate git-clone to use git-rev-parse --parseopt
+ Migrate git-clean.sh to use git-rev-parse --parseopt.
+ Update git-sh-setup(1) to allow transparent use of git-rev-parse -
-parseopt
+ Add a parseopt mode to git-rev-parse to bring parse-options to
shell scripts.
The rate of incoming changes to fix breakage with this topic has
slowed down, which is a good indication that this is getting
ready.
* sp/fetch-fix (Sun Nov 11 02:29:47 2007 -0500) 6 commits
+ git-fetch: avoid local fetching from alternate (again)
+ rev-list: Introduce --quiet to avoid /dev/null redirects
+ run-command: Support sending stderr to /dev/null
+ git-fetch: Always fetch tags if the object they reference exists
+ Merge branch 'sp/maint-plug-traverse-commit-list-leak' into
sp/fetch-fix
This should restore the traditional behaviour of git-fetch in
the C rewrite series.
* js/rebase-detached (Thu Nov 8 18:19:08 2007 +0000) 1 commit
+ rebase: operate on a detached HEAD
----------------------------------------------------------------
[Approaching 'next']
* kh/commit (Sun Nov 11 17:36:52 2007 +0000) 12 commits
- builtin-commit: Add newline when showing which commit was created
- builtin-commit: resurrect behavior for multiple -m options
- builtin-commit --s: add a newline if the last line was not a S-o-b
- builtin-commit: fix --signoff
- git status: show relative paths when run in a subdirectory
- builtin-commit: fix author date with --amend --author=<author>
- builtin-commit: Refresh cache after adding files.
- builtin-commit: fix reflog message generation
- launch_editor(): read the file, even when EDITOR=:
- Port git commit to C.
- Export launch_editor() and make it accept ':' as a no-op editor.
- Add testcase for ammending and fixing author in git commit.
Dscho fixed a handful obvious glitches. I am hoping that this
series should be in "testable" shape now. Will merge to "next"
after giving it a final round of eyeballing.
* sp/refspec-match (Sun Nov 11 15:01:48 2007 +0100) 4 commits
- refactor fetch's ref matching to use refname_match()
- push: use same rules as git-rev-parse to resolve refspecs
- add refname_match()
- push: support pushing HEAD to real branch name
This changes the semantics slightly but I think it is a move in
the right direction.
* dz/color-addi (Sat Nov 10 18:03:44 2007 -0600) 3 commits
- Added diff hunk coloring to git-add--interactive
- Let git-add--interactive read colors from .gitconfig
- Added basic color support to git add --interactive
* aw/mirror-push (Fri Nov 9 23:32:57 2007 +0000) 16 commits
- git-push: add documentation for the newly added --mirror mode
- Add tests for git push'es mirror mode
- git-push: plumb in --mirror mode
- Teach send-pack a mirror mode
Looking good.
This depends on Jeff's "even terser push output" series which in
turn depends on Daniel's "rewrite ls-remote and send-pack to
build them in" series, both of which should graduate to 'master'
hopefully shortly.
* ph/diffopts (Wed Nov 7 11:20:32 2007 +0100) 6 commits
- Reorder diff_opt_parse options more logically per topics.
- Make the diff_options bitfields be an unsigned with explicit
masks.
+ Use OPT_BIT in builtin-pack-refs
+ Use OPT_BIT in builtin-for-each-ref
+ Use OPT_SET_INT and OPT_BIT in builtin-branch
+ parse-options new features.
Although I found the whole series reasonable, I parked the later
parts of the series in 'pu' because diff is one of the more
important parts of the system.
* cr/tag-options (Fri Nov 9 14:42:56 2007 +0100) 1 commit
- Make builtin-tag.c use parse_options.
This changes the handling of multiple -m option without much
good reason. It should be a simple fix, once we know what we
want. I think the existing behaviour of refusing multiple -m
is probably the most sane at this point.
* sb/clean (Tue Nov 6 23:18:51 2007 -0600) 1 commit
- Make git-clean a builtin
----------------------------------------------------------------
[Stalled]
* bs/maint-commit-options (Mon Nov 5 20:36:33 2007 +0100) 1 commit
- git-commit.sh: Fix usage checks regarding paths given when they do
not make sense
This is meant to go to 'maint' but needs test script to exhibit
the existing breakage and demonstrate the fix.
The test will help catching future regression even after we
replace git-commit with Kristian's rewrite in C.
* nd/maint-work-tree-fix (Sat Nov 3 20:18:06 2007 +0700) 1 commit
+ Add missing inside_work_tree setting in setup_git_directory_gently
This is meant to go to 'maint' but needs test script to exhibit
the existing breakage and demonstrate the fix.
* jc/spht (Fri Nov 2 17:46:55 2007 -0700) 3 commits
+ core.whitespace: add test for diff whitespace error highlighting
+ git-diff: complain about >=8 consecutive spaces in initial indent
+ War on whitespace: first, a bit of retreat.
Teaching "git apply --whitespace=[warn|strip]" to honor the same
configuration would be a good addition, but this could go to
'master' as is.
----------------------------------------------------------------
[Others]
* mh/rebase-skip-hard (Thu Nov 8 08:03:06 2007 +0100) 1 commit
- Do git reset --hard HEAD when using git rebase --skip
Some people on the list may find this debatable.
* jc/branch-contains (Wed Nov 7 14:58:09 2007 -0800) 1 commit
- git-branch --with=commit
I did this just for my own fun.
* jc/maint-format-patch-encoding (Fri Nov 2 17:55:31 2007 -0700) 2 commits
- test format-patch -s: make sure MIME content type is shown as
needed
- format-patch -s: add MIME encoding header if signer's name
requires so
This is to apply to 'maint' later; the equivalent fix is already
in 'master'.
* ss/dirty-rebase (Thu Nov 1 22:30:24 2007 +0100) 3 commits
- Make git-svn rebase --dirty pass along --dirty to git-rebase.
- Implement --dirty for git-rebase--interactive.
- Introduce --dirty option to git-rebase, allowing you to start from
a dirty state.
This seems to be optimized for the --dirty case too much. I'd
prefer an implementation that make rebases without --dirty to
pay no penalty (if that is possible, otherwise "as little as
possible").
* js/reflog-delete (Wed Oct 17 02:50:45 2007 +0100) 1 commit
+ Teach "git reflog" a subcommand to delete single entries
* jc/nu (Sun Oct 14 22:07:34 2007 -0700) 3 commits
- merge-nu: a new merge backend without using unpack_trees()
- read_tree: take an explicit index structure
- gcc 4.2.1 -Werror -Wall -ansi -pedantic -std=c99: minimum fix
* jc/pathspec (Thu Sep 13 13:38:19 2007 -0700) 3 commits
- pathspec_can_match(): move it from builtin-ls-tree.c to tree.c
- ls-tree.c: refactor show_recursive() and rename it.
- tree-diff.c: split out a function to match a single pattern.
* jk/rename (Tue Oct 30 00:24:42 2007 -0400) 3 commits
- handle renames using similarity engine
- introduce generic similarity library
- change hash table calling conventions
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-11-12 7:06 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5ot40w9.fsf@gitster.siamese.dyndns.org>
* The 'maint' branch has these fixes since the last announcement.
Alex Riesen (1):
stop t1400 hiding errors in tests
Benoit Sigoure (1):
git-send-email: Change the prompt for the subject of the initial
message.
Gerrit Pape (1):
git-mailsplit: with maildirs not only process cur/, but also new/
Jonas Fonseca (1):
instaweb: Minor cleanups and fixes for potential problems
Junio C Hamano (3):
refresh_index_quietly(): express "optional" nature of index writing
better
Makefile: add missing dependency on wt-status.h
Start preparing for 1.5.3.6
Nicolas Pitre (3):
print warning/error/fatal messages in one shot
git-hash-object should honor config variables
fix index-pack with packs >4GB containing deltas on 32-bit machines
Ralf Wildenhues (2):
Avoid a few unportable, needlessly nested "...`...".
Fix sed string regex escaping in module_name.
Sergei Organov (1):
SubmittingPatches: improve the 'Patch:' section of the checklist
Vincent Zanotti (1):
gitweb: correct month in date display for atom feeds
* The 'master' branch has these since the last announcement
in addition to the above.
Gerrit Pape (3):
hooks--update: fix test for properly set up project description
file
hooks--update: decline deleting tags or branches by default, add
config options
contrib/hooks/post-receive-email: remove cruft, $committer is not
used
Johannes Schindelin (4):
parse-options: abbreviation engine fix.
builtin-reset: do not call "ls-files --unmerged"
builtin-reset: avoid forking "update-index --refresh"
builtin-blame: set up the work_tree before the first file access
Johannes Sixt (1):
upload-pack: Use finish_{command,async}() instead of waitpid().
Junio C Hamano (6):
Style: place opening brace of a function definition at column 1
Update draft release notes for 1.5.4
Documentation: lost-found is now deprecated.
Make check-docs target detect removed commands
Documentation: remove documentation for removed tools.
git-commit: a bit more tests
Lars Hjemli (1):
for-each-ref: fix setup of option-parsing for --sort
Michele Ballabio (1):
test-lib.sh: move error line after error() declaration
Nicolas Pitre (1):
add a howto document about corrupted blob recovery
Ralf Wildenhues (1):
git-bisect.sh: Fix sed script to work with AIX and BSD sed.
Sergei Organov (1):
core-tutorial.txt: Fix git-show-branch example and its description
Steffen Prohaska (2):
push: mention --verbose option in documentation
push: teach push to pass --verbose option to transport layer
^ 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