* [PATCH v2 0/2] http fixes
From: Tay Ray Chuan @ 2009-11-24 1:48 UTC (permalink / raw)
To: git; +Cc: Martin Storsjö, Shawn O. Pearce, Junio C Hamano
In-Reply-To: <20091123110347.d47728f8.rctay89@gmail.com>
This series is a re-roll and is based on 'master'.
Patch 1 ("Do curl option disabling before enabling new options"):
No changes from the previous version.
Patch 2 ("remote-curl.c: fix rpc_out()"):
Focus solely on the extraneous semicolon.
http-push.c | 2 +-
remote-curl.c | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH v2 1/2] Do curl option disabling before enabling new options
From: Tay Ray Chuan @ 2009-11-24 1:50 UTC (permalink / raw)
To: git; +Cc: Martin Storsjö
In-Reply-To: <20091124094810.797341d4.rctay89@gmail.com>
From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@martin.st>
This works around a bug in curl versions up to 7.19.4, where
disabling the CURLOPT_NOBODY option sets the internal state
incorrectly considering that CURLOPT_PUT was enabled earlier.
The bug is discussed at http://curl.haxx.se/bug/view.cgi?id=2727981
and is corrected in the latest version of curl in CVS.
This bug usually has no impact on git, but may surface if using
multi-pass authentication methods.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
No changes from the previous version.
http-push.c | 2 +-
remote-curl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-push.c b/http-push.c
index 0e040f8..432b20f 100644
--- a/http-push.c
+++ b/http-push.c
@@ -408,10 +408,10 @@ static void start_put(struct transfer_request *request)
curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &request->buffer);
#endif
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
+ curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
curl_easy_setopt(slot->curl, CURLOPT_PUT, 1);
- curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
if (start_active_slot(slot)) {
diff --git a/remote-curl.c b/remote-curl.c
index 4f28c22..69eaf58 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -356,8 +356,8 @@ static int post_rpc(struct rpc_state *rpc)
slot = get_active_slot();
slot->results = &results;
- curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
+ curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
curl_easy_setopt(slot->curl, CURLOPT_URL, rpc->service_url);
curl_easy_setopt(slot->curl, CURLOPT_ENCODING, "");
--
1.6.4.4
^ permalink raw reply related
* [PATCH v2 2/2] remote-curl.c: fix rpc_out()
From: Tay Ray Chuan @ 2009-11-24 1:55 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano, Sverre Rabbelier,
Johannes Schindelin
In-Reply-To: <20091124095021.93942a56.rctay89@gmail.com>
Remove the extraneous semicolon (';') at the end of the if statement,
that prevented code in its block from executing.
This fixes pushing to a smart http backend with chunked encoding.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
remote-curl.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 69eaf58..a331bae 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -307,7 +307,7 @@ static size_t rpc_out(void *ptr, size_t eltsize,
rpc->len = avail;
}
- if (max < avail);
+ if (max < avail)
avail = max;
memcpy(ptr, rpc->buf + rpc->pos, avail);
rpc->pos += avail;
--
1.6.4.4
^ permalink raw reply related
* [PATCH v3] remote-curl.c: fix rpc_out()
From: Tay Ray Chuan @ 2009-11-24 2:31 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Junio C Hamano, Sverre Rabbelier,
Johannes Schindelin, paulfred
In-Reply-To: <20091124095508.d6312ab0.rctay89@gmail.com>
Remove the extraneous semicolon (';') at the end of the if statement
that allowed the code in its block to execute regardless of the
condition.
This fixes pushing to a smart http backend with chunked encoding.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Reworded the part on code execution, so that it doesn't say "the code
doesn't execute", but rather "the code always executes".
Thanks to Paul for spotting that.
remote-curl.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 69eaf58..a331bae 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -307,7 +307,7 @@ static size_t rpc_out(void *ptr, size_t eltsize,
rpc->len = avail;
}
- if (max < avail);
+ if (max < avail)
avail = max;
memcpy(ptr, rpc->buf + rpc->pos, avail);
rpc->pos += avail;
--
1.6.4.4
^ permalink raw reply related
* Re: how to suppress progress percentage in git-push
From: Jeff King @ 2009-11-24 3:07 UTC (permalink / raw)
To: bill lam; +Cc: Junio C Hamano, Nicolas Pitre, git
In-Reply-To: <20091124011339.GA18003@debian.b2j>
On Tue, Nov 24, 2009 at 09:13:39AM +0800, bill lam wrote:
> On Mon, 23 Nov 2009, Nicolas Pitre wrote:
> > Then, during the pack-objects process, there are 3 phases: counting
> > objects, compressing objects, and writing objects. However in the fetch
>
> during git-gc it shows yet another progress
>
> Removing duplicate objects: 100% (256/256), done.
Thanks, this doesn't seem to have been guarded at all (but since it is
on a 2-second delay, you have to have quite a lot of loose objects or a
slow disk to trigger it).
We should apply the patch below to keep things consistent.
I also checked every other call to start_progress; everything else seems
to be guarded. Most of them were easy to trace to an isatty check,
though the one in unpack-trees is influenced by o->verbose_update. That
in turn usually corresponds to a quiet option, though merge does seem to
use it unconditionally. Maybe that should be tweaked, too?
-- >8 --
Subject: [PATCH] prune-packed: only show progress when stderr is a tty
This matches the behavior of other git programs, and helps
keep cruft out of things like cron job output.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-prune-packed.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-prune-packed.c b/builtin-prune-packed.c
index be99eb0..f9463de 100644
--- a/builtin-prune-packed.c
+++ b/builtin-prune-packed.c
@@ -71,7 +71,7 @@ void prune_packed_objects(int opts)
int cmd_prune_packed(int argc, const char **argv, const char *prefix)
{
- int opts = VERBOSE;
+ int opts = isatty(2) ? VERBOSE : 0;
const struct option prune_packed_options[] = {
OPT_BIT('n', "dry-run", &opts, "dry run", DRY_RUN),
OPT_NEGBIT('q', "quiet", &opts, "be quiet", VERBOSE),
--
1.6.6.rc0.249.g9b4cf.dirty
^ permalink raw reply related
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Adrian May @ 2009-11-24 3:48 UTC (permalink / raw)
To: tytso; +Cc: git, chromium-discuss
In-Reply-To: <20091123135817.GB2532@thunk.org>
> If you don't have bolt-on scripts, and you move that into the the core
> SCM, then you force *all* projects to use whatever workflow was
> decided as being the One True Way of doing things as seen by the SCM
> designer. So the question is whether the SCM *should* regiment all
> projects into following the SCM's designers idea of the One True
> Workflow.
Of course I'd want the workflow configurable by whoever controls the
main repository. I couldn't possibly suggest that all git projects
need the same workflow. The number of developers can vary by five
orders of magnitude - that calls for different workflow models.
> Git's approach is to say that it will be fairly flexible about
> dictating workflow --- who pushs to whom; whether there is a single
> "star" repository topology, or something that is more flexible, etc.
> You seem to hate this flexibility, because it makes life harder until
> you set up these bolt-on scripts. But that's what many of us like
> about git; that it doesn't force us (the project lead) into a single
> way of doing things.
Leaving aside topology, I suppose we can agree that the subject
divides into two aspects: offering the developer some optional tools,
and asserting control over what gets commited to the official repo.
Perhaps we can also agree that the former belongs under the control of
the developer and the latter should be in the PM's hands. You seem to
have opinions about which of these two aspects is more or less
important, and to what extent git suffices, but I don't. I assume that
the project manager has his own opinions about both aspects and I'm
observing two big projects that independantly have augmented git's
features with their own scripts. Their docs talk about both aspects,
especially repo's, but they are entirely implemented in
developer-overridable scripts. So any repo functions to do with the
second aspect are either features that git needs to grow, or bits of
the git manual that the repo designer didn't read. I'd kinda like to
know which.
Returning to topology, I think that also divides up similarly. The PM
can't forbid you and me from casually swapping diffs back and forth,
but he can dictate who we are supposed to submit our final candidate
to for review. The very existence of a PM, who controls a subset of
the repositories in the world, already implies a star topology, and I
think pretty much everybody is using distributed source control in
this way, at least when it comes down to *controlling* anything.
People may also be causally bouncing diffs around, but that's not
control, it's communication. I've got a one-man project on github
which I edit from two locations, and even on that scale I find myself
working star-fashion because either computer might have junk
experiments in progress, but I only push to github if it's meaningful
and tidy.
That reminds me of a slightly different question: if a longer
experiment that I have committed several stages of turns out to be a
blind alley, I'd like to go back a few steps on main, declare
everything after that to be a side branch that I'll probably never use
again, and continue on main with my next attempt. Is that possible? I
know that I can just start a new branch from the before the bad
experiment, but if that happens a lot, the name of my current main
branch would be changing all the time, and I think that's bad. I
suspect what I want is possible, but I'm not sure how to do it.
> As far as my wanting to impose a particular regimen on my project's
> developers, I've never been a big fan of the Bondage and Discpline
> school of software engineering. They can use whatever workflow they
> like; they just have to deliver patches that are clean. If they are,
> I'll pull from their repository. If they aren't, I won't.
Repo talks a lot about automating the workflow that leads to precisely
that decision. They evidently want something more evolved than
somebody simply having a look at the code. I'm not sure what they
want, but I'm pretty sure it's none of the developer's business.
Adrian.
^ permalink raw reply
* commit --quiet option
From: bill lam @ 2009-11-24 5:16 UTC (permalink / raw)
To: git
In git version 1.6.6.rc0.15.g4fa8a0 using the --quiet option it still show some
output. Is that intended? Specifically I would like to exclude message about
the untracked files when using --quite option.
$ git commit -q -m commit
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: .git-completion.bash
# modified: bin/mirrorgit
#
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# a123
no changes added to commit (use "git add" and/or "git commit -a")
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: gitk does not show path file list
From: Mark Blakeney @ 2009-11-24 5:36 UTC (permalink / raw)
To: git
In-Reply-To: <33e2b2760911170409q4cbdad8ay83ae5c941bc5ff95@mail.gmail.com>
This seems to me to be a straight out bug but given I've had no response here
and given this is such a simple issue then I guess it's not a bug and I'm just
missing something? Please somebody, why does gitk (usually) not show the subset
list of files affected when you give it a path?
E.g. If I am in a src dir then "gitk ." does not list files. Neither does "gitk
$PWD" nor "gitk ../src". However "cd ..; git src" does list files!?
Is there a more appropriate forum/list for git newcomers?
^ permalink raw reply
* [PATCH] Documentation: update descriptions of revision options related to '--bisect'
From: Christian Couder @ 2009-11-24 6:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In commit ad3f9a7 (Add '--bisect' revision machinery argument) the
'--bisect' option was added to easily pass bisection refs to commands
using the revision machinery.
This patch updates the documentation of the related options to describe
the new behavior.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
Documentation/rev-list-options.txt | 39 ++++++++++++++++++++++++-----------
1 files changed, 27 insertions(+), 12 deletions(-)
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b44fdd9..1f57aed 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -243,6 +243,15 @@ endif::git-rev-list[]
Pretend as if all the refs in `$GIT_DIR/refs/remotes` are listed
on the command line as '<commit>'.
+ifndef::git-rev-list[]
+--bisect::
+
+ Pretend as if the bad bisection ref `$GIT_DIR/refs/bisect/bad`
+ was listed and as if it was followed by `--not` and the good
+ bisection refs `$GIT_DIR/refs/bisect/good-*` on the command
+ line.
+endif::git-rev-list[]
+
--stdin::
In addition to the '<commit>' listed on the command
@@ -538,7 +547,11 @@ Bisection Helpers
--bisect::
Limit output to the one commit object which is roughly halfway between
-the included and excluded commits. Thus, if
+included and excluded commits. Note that the bad bisection ref
+`$GIT_DIR/refs/bisect/bad` is added to the included commits (if it
+exists) and the good bisection refs `$GIT_DIR/refs/bisect/good-*` are
+added to the excluded commits (if they exist). Thus, supposing there
+are no refs in `$GIT_DIR/refs/bisect/`, if
-----------------------------------------------------------------------
$ git rev-list --bisect foo ^bar ^baz
@@ -558,22 +571,24 @@ one.
--bisect-vars::
-This calculates the same as `--bisect`, but outputs text ready
-to be eval'ed by the shell. These lines will assign the name of
-the midpoint revision to the variable `bisect_rev`, and the
-expected number of commits to be tested after `bisect_rev` is
-tested to `bisect_nr`, the expected number of commits to be
-tested if `bisect_rev` turns out to be good to `bisect_good`,
-the expected number of commits to be tested if `bisect_rev`
-turns out to be bad to `bisect_bad`, and the number of commits
-we are bisecting right now to `bisect_all`.
+This calculates the same as `--bisect`, except that refs in
+`$GIT_DIR/refs/bisect/` are not used, and except that this outputs
+text ready to be eval'ed by the shell. These lines will assign the
+name of the midpoint revision to the variable `bisect_rev`, and the
+expected number of commits to be tested after `bisect_rev` is tested
+to `bisect_nr`, the expected number of commits to be tested if
+`bisect_rev` turns out to be good to `bisect_good`, the expected
+number of commits to be tested if `bisect_rev` turns out to be bad to
+`bisect_bad`, and the number of commits we are bisecting right now to
+`bisect_all`.
--bisect-all::
This outputs all the commit objects between the included and excluded
commits, ordered by their distance to the included and excluded
-commits. The farthest from them is displayed first. (This is the only
-one displayed by `--bisect`.)
+commits. Refs in `$GIT_DIR/refs/bisect/` are not used. The farthest
+from them is displayed first. (This is the only one displayed by
+`--bisect`.)
+
This is useful because it makes it easy to choose a good commit to
test when you want to avoid to test some of them for some reason (they
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Karl Wiberg @ 2009-11-24 7:12 UTC (permalink / raw)
To: Alex Chiang, Catalin Marinas; +Cc: Junio C Hamano, git
In-Reply-To: <20091124004554.GA27643@ldl.fc.hp.com>
On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
> * Junio C Hamano <gitster@pobox.com>:
>
> > If you are changing StGit to call git-send-email anyway, why not
> > arrange stgit to call git-send-email to send the message out
> > instead, instead of sending messages on its own?
>
> Yeah, I thought about that as I was poking around further in StGit
> to figure out how it would be calling git-send-email. ;)
>
> > I imagine the internal implementation of stg mail would work
> > something like:
> >
> > prepare messages to send out
> > call git-send-email and have it send them
> >
> > What am I missing?
>
> My lack of familiarity with StGit internals. ;)
>
> Your suggestion is much better. I'll take a closer look at StGit and
> see how feasible it is.
>
> Unless Catalin has strong objections?
I think that sounds like a splendid idea. It would be interesting to
see just how thin a wrapper around git send-email (and format-patch)
stg mail could become, without sacrificing features anyone actually
uses. The main complication could be stg mail's templates.
Catalin, how wedded are you to those? ;-)
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: gitk does not show path file list
From: Junio C Hamano @ 2009-11-24 7:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Mark Blakeney
In-Reply-To: <loom.20091124T060334-836@post.gmane.org>
Mark Blakeney <markb@berlios.de> writes:
> ... why does gitk (usually) not show the subset list of files affected
> when you give it a path?
>
> E.g. If I am in a src dir then "gitk ." does not list files. Neither does "gitk
> $PWD" nor "gitk ../src". However "cd ..; git src" does list files!?
Paul, I do not read Tcl very well, but it appears that path_filter
procedure is at fault.
The call chain involved in this seems to be:
gettreediffs
- arranges gettreediffline to be fed output from "diff-tree $commit ."
->
gettreediffline
- finds the path (note that diff output is _always_ relative to the
top of the work tree) from the patch;
- calls path_filter with $vfilelimit($curview) and each filename
In this case, the $vfilelimit($curview) is "." (dot)
->
path_filter
- compares strings in $filter and the $name; in this case, $filter is
a dot "." and $name begins with "src/"
I see at least two problems in path_filter used this way:
- A dot "." never would match anything from "diff-tree" (or any "diff"
variant) after stripping a/ and b/ prefix. gitk should prefix the
current directory to each of the pathspec from command line (run
"rev-parse --show-prefix" to learn where you are).
- There is another callsite to path_filter for filtering output from
"ls-files -u". But the output from "ls-files" is relative to the cwd
by default. gitk should probably run it with --full-name option, so
that it would get the same semantics as "diff" output.
It _might_ be the easiest to do an equivalent of (sorry, I do not talk Tcl
so this is in shell):
prefix=$(git rev-parse --show-prefix)
if test -n "$prefix"
then
cd $(git rev-parse --show-cdup)
fi
and then prepend prefix to all the pathspecs you would use from the
command line before doing anything else. This "prepending" obviously need
to be aware of the ".", ".." and friends.
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Junio C Hamano @ 2009-11-24 7:25 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Alex Chiang, Catalin Marinas, git
In-Reply-To: <b8197bcb0911232312l251dfbc9va671388cfb7fe57b@mail.gmail.com>
Karl Wiberg <kha@treskal.com> writes:
> I think that sounds like a splendid idea. It would be interesting to
> see just how thin a wrapper around git send-email (and format-patch)
> stg mail could become, without sacrificing features anyone actually
> uses. The main complication could be stg mail's templates.
Why do you even need to run format-patch? If stg mail supports a good
templates to prepare message files, it would be natural to keep using that
to prepare message files.
^ permalink raw reply
* Re: [PATCH 1/2] Refactor winsock initialization into a separate function
From: Johannes Sixt @ 2009-11-24 7:36 UTC (permalink / raw)
To: Martin Storsjö; +Cc: git, gitster
In-Reply-To: <alpine.DEB.2.00.0911240054420.14228@cone.home.martin.st>
Martin Storsjö schrieb:
> Signed-off-by: Martin Storsjo <martin@martin.st>
I have used this series in my tree for 6 weeks without negative
sideffects. I haven't tested IPv6, though.
Here's an updated commit message with my ACK:
--- >8 ---
Refactor winsock initialization into a separate function
The winsock library must be initialized. Since gethostbyname() is the
first function that calls into winsock, it was overridden to do the
initialization. This refactoring helps the next patch, where other
functions can be called earlier.
Signed-off-by: Martin Storsjo <martin@martin.st>
Acked-by: Johannes Sixt <j6t@kdbg.org>
--- >8 ---
> ---
> compat/mingw.c | 15 ++++++++++++---
> 1 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/compat/mingw.c b/compat/mingw.c
> index 15fe33e..f9d82ff 100644
> --- a/compat/mingw.c
> +++ b/compat/mingw.c
> @@ -903,16 +903,25 @@ char **make_augmented_environ(const char *const *vars)
> return env;
> }
>
> -/* this is the first function to call into WS_32; initialize it */
> -#undef gethostbyname
> -struct hostent *mingw_gethostbyname(const char *host)
> +static void ensure_socket_initialization(void)
> {
> WSADATA wsa;
> + static int initialized = 0;
> +
> + if (initialized)
> + return;
>
> if (WSAStartup(MAKEWORD(2,2), &wsa))
> die("unable to initialize winsock subsystem, error %d",
> WSAGetLastError());
> atexit((void(*)(void)) WSACleanup);
> + initialized = 1;
> +}
> +
> +#undef gethostbyname
> +struct hostent *mingw_gethostbyname(const char *host)
> +{
> + ensure_socket_initialization();
> return gethostbyname(host);
> }
>
^ permalink raw reply
* Re: [PATCH 2/2] Enable support for IPv6 on MinGW
From: Johannes Sixt @ 2009-11-24 7:41 UTC (permalink / raw)
To: Martin Storsjö; +Cc: git, gitster
In-Reply-To: <alpine.DEB.2.00.0911240055170.14228@cone.home.martin.st>
Martin Storsjö schrieb:
> The IPv6 support functions are loaded dynamically, to maintain backwards
> compatibility with versions of Windows prior to XP, and fallback wrappers
> are provided, implemented in terms of gethostbyname and gethostbyaddr.
>
> Signed-off-by: Martin Storsjo <martin@martin.st>
Acked-by: Johannes Sixt <j6t@kdbg.org>
-- Hannes
^ permalink raw reply
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Karl Wiberg @ 2009-11-24 7:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Chiang, Catalin Marinas, git
In-Reply-To: <7vfx84jsef.fsf@alter.siamese.dyndns.org>
On Tue, Nov 24, 2009 at 8:25 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Karl Wiberg <kha@treskal.com> writes:
>
>> I think that sounds like a splendid idea. It would be interesting to
>> see just how thin a wrapper around git send-email (and format-patch)
>> stg mail could become, without sacrificing features anyone actually
>> uses. The main complication could be stg mail's templates.
>
> Why do you even need to run format-patch? If stg mail supports a good
> templates to prepare message files, it would be natural to keep using that
> to prepare message files.
The only thing stg mail _really_ needs to do, strictly speaking, is to
be git send-email with an easy way to specify a patch, or a range of
patches, to send. Anything above and beyond that is functionality that
we have to write and maintain without the help of the larger git
community, and which won't be of use to said community for no good
reason. Take the template system for cover letters and patches, for
example: there's no reason why it couldn't be part of the git tools,
and if it had been, it would have had many more users and much more
developer love.
It's a question of deciding in which areas the benefits of doing it
ourselves are worth the cost, and where it's better to let git do the
job for us. And of recognizing that StGit is old enough that tradeoffs
that were worth it when git was not as mature and featureful as today
might be worth reconsidering from time to time.
(Alex: Sorry if I'm making a big deal out of this. Just because
rewriting stg mail entirely in terms of the git tools might be
_possible_ doesn't mean that just a few steps in that direction
wouldn't be worthwhile. But I thought I should raise the possibility.)
--
Karl Wiberg, kha@treskal.com
subrabbit.wordpress.com
www.treskal.com/kalle
^ permalink raw reply
* Re: gitk does not show path file list
From: Johannes Sixt @ 2009-11-24 7:57 UTC (permalink / raw)
To: Mark Blakeney; +Cc: git
In-Reply-To: <loom.20091124T060334-836@post.gmane.org>
Mark Blakeney schrieb:
> This seems to me to be a straight out bug but given I've had no response here
> and given this is such a simple issue then I guess it's not a bug and I'm just
> missing something? Please somebody, why does gitk (usually) not show the subset
> list of files affected when you give it a path?
>
> E.g. If I am in a src dir then "gitk ." does not list files. Neither does "gitk
> $PWD" nor "gitk ../src". However "cd ..; git src" does list files!?
gitk doesn't list the files in your examples because the patterns you gave
are not initial substrings of any files in the list.
-- Hannes
^ permalink raw reply
* Re: gitk does not show path file list
From: Junio C Hamano @ 2009-11-24 8:11 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Mark Blakeney, git
In-Reply-To: <4B0B91DC.1020902@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Mark Blakeney schrieb:
>> This seems to me to be a straight out bug but given I've had no response here
>> and given this is such a simple issue then I guess it's not a bug and I'm just
>> missing something? Please somebody, why does gitk (usually) not show the subset
>> list of files affected when you give it a path?
>>
>> E.g. If I am in a src dir then "gitk ." does not list files. Neither does "gitk
>> $PWD" nor "gitk ../src". However "cd ..; git src" does list files!?
>
> gitk doesn't list the files in your examples because the patterns you gave
> are not initial substrings of any files in the list.
Yes, but if you are in src/ and run "gitk .", then...
- clicking on a commit runs "diff-tree $commit .", that lists
src/hello.c, src/goodbye.c, etc.
- gitk tries to filter paths read from diff-tree with the "." given from
the command line as the filter---it removes paths that do not match.
So the only case that would produce any output would be for you to have:
src/src/hello.c
src/frotz.c
and run
cd src && gitk src
whose invocation of "diff-tree src" will show _only_ src/src/hello.c and
then the filter procedure will limit it to whatever begins with src/
(which would be everything).
That does not sound very useful to me...
^ permalink raw reply
* [PATCH] grep: --full-tree
From: Junio C Hamano @ 2009-11-24 8:56 UTC (permalink / raw)
To: git
While working inside a deep subdirectory, it sometimes is necessary to
find a string you see in a file you are working on from the files in the
entire project. This is especially true when you are dipping your toe
into an unfamiliar project.
By default, "git grep" limits its search space to the current directory
and below (i.e. as if "-r ." is specified), and it is rather cumbersome to
repeat ../ as many times as necessary. This new option tells "git grep"
not to limit the search space to the current directory.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* In http://article.gmane.org/gmane.comp.version-control.git/111717, I
once argued in the opposite way, but I think it is Ok to aim for making
the default --full-tree in the longer run (cf. $gmane/127885). This is
the first step in that direction.
I am not sure if there can be a sane way to flip the default without
hurting existing scripts and users. Backward compatibility always is
a pain.
builtin-grep.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 761799d..5787f35 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -693,6 +693,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
{
int hit = 0;
int cached = 0;
+ int full_tree = 0;
int external_grep_allowed = 1;
int seen_dashdash = 0;
struct grep_opt opt;
@@ -732,6 +733,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
OPT_BIT('H', NULL, &opt.pathname, "show filenames", 1),
OPT_NEGBIT(0, "full-name", &opt.relative,
"show filenames relative to top directory", 1),
+ OPT_BIT(0, "full-tree", &full_tree,
+ "search from the top of the tree", 1),
OPT_BOOLEAN('l', "files-with-matches", &opt.name_only,
"show only filenames instead of matching lines"),
OPT_BOOLEAN(0, "name-only", &opt.name_only,
@@ -862,7 +865,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
if (i < argc)
paths = get_pathspec(prefix, argv + i);
- else if (prefix) {
+ else if (prefix && !full_tree) {
paths = xcalloc(2, sizeof(const char *));
paths[0] = prefix;
paths[1] = NULL;
--
1.6.6.rc0.47.g1fdffa.dirty
^ permalink raw reply related
* Re: [PATCH RFC] git-send-email --expand-aliases
From: Catalin Marinas @ 2009-11-24 10:43 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Alex Chiang, Junio C Hamano, git
In-Reply-To: <b8197bcb0911232312l251dfbc9va671388cfb7fe57b@mail.gmail.com>
2009/11/24 Karl Wiberg <kha@treskal.com>:
> On Tue, Nov 24, 2009 at 1:45 AM, Alex Chiang <achiang@hp.com> wrote:
>
>> * Junio C Hamano <gitster@pobox.com>:
>>
>> > If you are changing StGit to call git-send-email anyway, why not
>> > arrange stgit to call git-send-email to send the message out
>> > instead, instead of sending messages on its own?
>>
>> Yeah, I thought about that as I was poking around further in StGit
>> to figure out how it would be calling git-send-email. ;)
>>
>> > I imagine the internal implementation of stg mail would work
>> > something like:
>> >
>> > prepare messages to send out
>> > call git-send-email and have it send them
>> >
>> > What am I missing?
>>
>> My lack of familiarity with StGit internals. ;)
>>
>> Your suggestion is much better. I'll take a closer look at StGit and
>> see how feasible it is.
>>
>> Unless Catalin has strong objections?
>
> I think that sounds like a splendid idea. It would be interesting to
> see just how thin a wrapper around git send-email (and format-patch)
> stg mail could become, without sacrificing features anyone actually
> uses. The main complication could be stg mail's templates.
>
> Catalin, how wedded are you to those? ;-)
Historically, I think "stg mail" was implemented before git-send-email
existed. It was also a good way to check who's using stgit for sending
patches :-) (the message-id).
I use templates to send patches to the ARM Linux gatekeeper via a
patch management system which only accepts patches formatted in a
certain way (things improved a bit recently and the format was
relaxed). But I find myself mostly sending pull requests these days,
so that's not a critical feature for me.
If there are no other users of the stg mail templates, I'm happy to
let them go. Otherwise, we can replace the sendmail with
git-send-email in stgit.
It seems that git-format-patch and git-send-email have all the
features stgit has. We would need to keep some of the interactive
options like --edit-cover and --edit-patches since we use
git-format-patch and git-send-email in one go.
--
Catalin
^ permalink raw reply
* Re: What's cooking in git.git (Nov 2009, #05; Sun, 22)
From: Jakub Narebski @ 2009-11-24 10:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbsl935q.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * jn/gitweb-blame (2009-11-19) 6 commits.
> - gitweb.js: fix null object exception in initials calculation
> - gitweb: Minify gitweb.js if JSMIN is defined
> - gitweb: Create links leading to 'blame_incremental' using JavaScript
> (merged to 'next' on 2009-10-11 at 73c4a83)
> + gitweb: Colorize 'blame_incremental' view during processing
> + gitweb: Incremental blame (using JavaScript)
> + gitweb: Add optional "time to generate page" info in footer
>
> Ajax-y blame, with a few recent fixes.
Unfortunately current version does not work with IE8 (reported by
Stephen Boyd); it stops at the very beginning of JavaScript blaming
with the two JavaScript errors:
- "firstChild is null or not an object", caused by the fact that
'<a href=""> </a>' element doesn't have firstChild which is text
node with space as contents in DOM. This can be easily worked
around.
- "Unspecified error" (twice (sic!) for the same line), which
I have currently no idea how to fix; it points to the following
line:
if (xhr.readyState === 3 && xhr.status !== 200) {
> * pb/gitweb-no-project-list (2009-11-06) 3 commits.
> . gitweb: Polish the content tags support
> . gitweb: Support for no project list on gitweb front page
> . gitweb: Refactor project list routines
>
> I picked these up but didn't queue as Warthog9's comments made certain
> amount of sense to me.
I'd like to see at least refactoring project list subroutine:
currently printing list of projects is entangled with filtering
said list; IMHO filtering list of projects should be done upfront.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] mailinfo: remove [PATCH...] prefix from Subject regardless of length
From: Jim Meyering @ 2009-11-24 10:58 UTC (permalink / raw)
To: git list
Before this change, a [...] prefix would be removed only as long as
its length did not exceed 2/3 of the subject length. Now, when the
bracketed quantity starts with PATCH, it is removed unconditionally.
Otherwise, the existing behavior remains unchanged.
While with a bare "PATCH M/N" prefix, this inconsistency shows up only
on a subject of length 2 or 1 (assuming one-digit M and N), if you set
format.subjectprefix to the name of a project or sub-project, the
minimum affected length may be substantially larger.
Contrast the behavior before:
for i in 1234 123 12 1 ''; do echo 'Subject: [PATCH 1/1] '$i \
| git mailinfo m p | head -1; done
Subject: 1234
Subject: 123
Subject: [PATCH 1/1] 12
Subject: [PATCH 1/1] 1
Subject: [PATCH 1/1]
and after this change:
for i in 1234 123 12 1 ''; do echo 'Subject: [PATCH 1/1] '$i \
| ./git mailinfo m p | head -1; done
Subject: 1234
Subject: 123
Subject: 12
Subject: 1
Subject:
Along the way, I added a "const" to indicate that the "header"
array itself is constant.
Signed-off-by: Jim Meyering <meyering@redhat.com>
---
builtin-mailinfo.c | 10 ++++++++--
t/t5100-mailinfo.sh | 9 +++++++++
2 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 3c4f075..f07bca6 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -237,9 +237,15 @@ static void cleanup_subject(struct strbuf *subject)
strbuf_remove(subject, 0, 1);
continue;
case '[':
+ /* If there's a [...] enclosed prefix, always remove
+ it when it starts with "PATCH". If it does not
+ start with PATCH, remove the bracketed quantity
+ only as long as that removes no more than 2/3 of
+ the length. */
if ((pos = strchr(subject->buf, ']'))) {
remove = pos - subject->buf;
- if (remove <= (subject->len - remove) * 2) {
+ if (remove <= (subject->len - remove) * 2
+ || !prefixcmp (subject->buf + 1, "PATCH")) {
strbuf_remove(subject, 0, remove + 1);
continue;
}
@@ -265,7 +271,7 @@ static void cleanup_space(struct strbuf *sb)
}
static void decode_header(struct strbuf *line);
-static const char *header[MAX_HDR_PARSED] = {
+static const char *const header[MAX_HDR_PARSED] = {
"From","Subject","Date",
};
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index ebc36c1..86fb116 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -89,4 +89,13 @@ test_expect_success 'mailinfo on from header without name works' '
'
+test_expect_success 'mailinfo strips [PATCH... even on very short Subject' '
+
+ printf "Subject: [PATCH 1/1] ..\n" > in &&
+ printf "Subject: ..\n\n" > expect &&
+ git mailinfo /dev/null /dev/null < in > out &&
+ test_cmp expect out
+
+'
+
test_done
--
1.6.6.rc0.236.ge0b94
^ permalink raw reply related
* Re: Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Bob Hazard @ 2009-11-24 11:29 UTC (permalink / raw)
To: adrian.alexander.may; +Cc: tytso, git, chromium-discuss
In-Reply-To: <65e170e70911231948l3b032dbeu7c99b65ce3ec97ff@mail.gmail.com>
Git's raison d'etre was to make merging cheaper. You are encouraged
to make as many local branches as you want to experiment on features
"if a longer experiment that I have committed several stages of turns
out to be a
blind alley, I'd like to go back a few steps on main, declare
everything after that to be a side branch that I'll probably never use
again, and continue on main with my next attempt. Is that possible?"
Yes.
This google tech talk by Randal Schwartz is a little old but it might help
http://www.youtube.com/watch?v=8dhZ9BXQgc4
2009/11/24 Adrian May <adrian.alexander.may@gmail.com>:
>> If you don't have bolt-on scripts, and you move that into the the core
>> SCM, then you force *all* projects to use whatever workflow was
>> decided as being the One True Way of doing things as seen by the SCM
>> designer. So the question is whether the SCM *should* regiment all
>> projects into following the SCM's designers idea of the One True
>> Workflow.
>
> Of course I'd want the workflow configurable by whoever controls the
> main repository. I couldn't possibly suggest that all git projects
> need the same workflow. The number of developers can vary by five
> orders of magnitude - that calls for different workflow models.
>
>> Git's approach is to say that it will be fairly flexible about
>> dictating workflow --- who pushs to whom; whether there is a single
>> "star" repository topology, or something that is more flexible, etc.
>> You seem to hate this flexibility, because it makes life harder until
>> you set up these bolt-on scripts. But that's what many of us like
>> about git; that it doesn't force us (the project lead) into a single
>> way of doing things.
>
> Leaving aside topology, I suppose we can agree that the subject
> divides into two aspects: offering the developer some optional tools,
> and asserting control over what gets commited to the official repo.
> Perhaps we can also agree that the former belongs under the control of
> the developer and the latter should be in the PM's hands. You seem to
> have opinions about which of these two aspects is more or less
> important, and to what extent git suffices, but I don't. I assume that
> the project manager has his own opinions about both aspects and I'm
> observing two big projects that independantly have augmented git's
> features with their own scripts. Their docs talk about both aspects,
> especially repo's, but they are entirely implemented in
> developer-overridable scripts. So any repo functions to do with the
> second aspect are either features that git needs to grow, or bits of
> the git manual that the repo designer didn't read. I'd kinda like to
> know which.
>
> Returning to topology, I think that also divides up similarly. The PM
> can't forbid you and me from casually swapping diffs back and forth,
> but he can dictate who we are supposed to submit our final candidate
> to for review. The very existence of a PM, who controls a subset of
> the repositories in the world, already implies a star topology, and I
> think pretty much everybody is using distributed source control in
> this way, at least when it comes down to *controlling* anything.
> People may also be causally bouncing diffs around, but that's not
> control, it's communication. I've got a one-man project on github
> which I edit from two locations, and even on that scale I find myself
> working star-fashion because either computer might have junk
> experiments in progress, but I only push to github if it's meaningful
> and tidy.
>
> That reminds me of a slightly different question: if a longer
> experiment that I have committed several stages of turns out to be a
> blind alley, I'd like to go back a few steps on main, declare
> everything after that to be a side branch that I'll probably never use
> again, and continue on main with my next attempt. Is that possible? I
> know that I can just start a new branch from the before the bad
> experiment, but if that happens a lot, the name of my current main
> branch would be changing all the time, and I think that's bad. I
> suspect what I want is possible, but I'm not sure how to do it.
>
>> As far as my wanting to impose a particular regimen on my project's
>> developers, I've never been a big fan of the Bondage and Discpline
>> school of software engineering. They can use whatever workflow they
>> like; they just have to deliver patches that are clean. If they are,
>> I'll pull from their repository. If they aren't, I won't.
>
> Repo talks a lot about automating the workflow that leads to precisely
> that decision. They evidently want something more evolved than
> somebody simply having a look at the code. I'm not sure what they
> want, but I'm pretty sure it's none of the developer's business.
>
> Adrian.
>
> --
> Chromium Discussion mailing list: chromium-discuss@googlegroups.com
> View archives, change email options, or unsubscribe:
> http://groups.google.com/group/chromium-discuss
--
Chromium Discussion mailing list: chromium-discuss@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-discuss
^ permalink raw reply
* Re: [PATCH 0/2] Add support for IPv6 on MinGW
From: Martin Storsjö @ 2009-11-24 11:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6lwrb5p.fsf@alter.siamese.dyndns.org>
On Mon, 23 Nov 2009, Junio C Hamano wrote:
> I am aware of the exchange between you and J6t on msysgit@googlegroups
> where he suggested you to send them here. Giving better visibility to
> these patches for public review is good.
>
> But you didn't have to Cc: me; in Windows API issues I have no clue so I
> won't be a good reviewer. I do not even compile git on Windows myself,
> let alone testing nor using.
Ah, sorry for notifying you prematurely there.
> As hinted by J6t, he will be saying Ack or something else, so I'll act on
> these patches when it happens.
And thanks for handling this!
// Martin
^ permalink raw reply
* git init --bare --shared=group
From: Eric Schaefer @ 2009-11-24 13:05 UTC (permalink / raw)
To: Git Mailing List
Hello List,
according to 'git help init' would --shared=group "Make the repository
group-writable".
I extracted a bare repo out of my local repo and scp'ed it to the
server. There I did a 'git init --bare --shared=group'. It created the
branches dir (there were no branches yet) and the config file and set
the correct permissions. But it did not do so with the existsing files
and dirs. Is it suffient to 'chmod -R g+ws .' or is there anything
else to do to make the repo writeable for my group?
Thanks,
Eric
^ permalink raw reply
* Re: git init --bare --shared=group
From: Johannes Schindelin @ 2009-11-24 13:25 UTC (permalink / raw)
To: Eric Schaefer; +Cc: Git Mailing List
In-Reply-To: <34f8975d0911240505k4727fef2n8ef0efd3533aef1e@mail.gmail.com>
Hi,
On Tue, 24 Nov 2009, Eric Schaefer wrote:
> according to 'git help init' would --shared=group "Make the repository
> group-writable".
> I extracted a bare repo out of my local repo and scp'ed it to the
> server. There I did a 'git init --bare --shared=group'. It created the
> branches dir (there were no branches yet) and the config file and set
> the correct permissions. But it did not do so with the existsing files
> and dirs. Is it suffient to 'chmod -R g+ws .' or is there anything
> else to do to make the repo writeable for my group?
That should be enough, if all files and directories belong to the correct
group. Otherwise, you should 'chown -R .group .', 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