* Re: [PATCH] Always reset the color _before_ printing out the newline
From: Jeff King @ 2006-07-24 13:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0607241440340.29667@wbgn013.biozentrum.uni-wuerzburg.de>
On Mon, Jul 24, 2006 at 02:41:41PM +0200, Johannes Schindelin wrote:
> This patch brings the benefits of part of v1.4.1-rc2~37
> to the "commit" colorizing patch.
Oops, yes, I should have thought of that. Patch looks good to me.
-Peff
^ permalink raw reply
* Re: [RFC/PATCH] Per branch properties for pull
From: Santi @ 2006-07-24 12:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmzaze9xj.fsf@assigned-by-dhcp.cox.net>
2006/7/24, Junio C Hamano <junkio@cox.net>:
> Santi Béjar <sbejar@gmail.com> writes:
>
> > It extracts all the information for pull from the config file.
> >
> > If you have a config file as:
> >
> > [branch "master"]
> > remote=origin
> > merge=next #the remote name
> > octopus=octopus
> > twohead=recursive
> >
[...]
> I am in general in agreement with this line of thought and had
> an impression that many on the list wanted to have per-branch
> configuration. I am a bit too tired now so I'd just let you
> know I am interested but would not apply it tonight.
>
> Opinions? Comments? Anything missing or objectionable on
> Santi's patch from the list?
Actually my patch is a RFC to agree on the config semantics, (although
I do not mind if committed to "pu" :) :
.- are remote/merge good names?
.- the merge key is the name of the remote branch.
.- are the octopus and twohead OK?
.- for a local merge, is remote=. OK?
.- "git pull ." to mean: do not fetch anything but merge the default branch?
.- for the integrator case:
* is the "merge= rembranch from remote" OK?
* "git pull remotename" should read the branch properties if
branch.$curr_branch.remote=remotename?
* It could be usefull to have a git-merge-seq that performs a
twohead merge sequentially instead of an octopus.
The patch as is works for me and it currently depends on the remote
config being in .git/config.
It only touchs git-pull, just to have a working prototype of the
semantics and to minimize the breakage, but it could be that it should
be integrated in the git-parse-remote.
Santi
^ permalink raw reply
* [PATCH] Always reset the color _before_ printing out the newline
From: Johannes Schindelin @ 2006-07-24 12:41 UTC (permalink / raw)
To: git, junkio
This patch brings the benefits of part of v1.4.1-rc2~37
to the "commit" colorizing patch.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
log-tree.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 608f3ec..b67b8dd 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -144,9 +144,9 @@ void show_log(struct rev_info *opt, cons
printf(" (from %s)",
diff_unique_abbrev(parent->object.sha1,
abbrev_commit));
- putchar(opt->commit_format == CMIT_FMT_ONELINE ? ' ' : '\n');
printf("%s",
diff_get_color(opt->diffopt.color_diff, DIFF_RESET));
+ putchar(opt->commit_format == CMIT_FMT_ONELINE ? ' ' : '\n');
}
/*
--
1.4.2.rc1.g41e1-dirty
^ permalink raw reply related
* [PATCH] Allow an alias to start with "-p"
From: Johannes Schindelin @ 2006-07-24 12:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v8xmjh5sv.fsf@assigned-by-dhcp.cox.net>
Now, something like
[alias]
pd = -p diff
works as expected.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
On Sun, 23 Jul 2006, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Now, something like
> >
> > [alias]
> > pd = -p diff
> >
> > works as expected.
>
> I like what it wants to do but I am afraid this leads to an
> unmaintainable code (a micronit that already shows what I mean
> is that you can say "git --paginate diff", but you cannot say
> "pd = --paginate diff" in the configuration file).
>
> Is there a cleaner way to do it without duplicating the argument
> loop of git.c::main()?
This patch uses a better approach: instead of duplicating the option
parsing of the git wrapper, it refactors the code into the new function
handle_options().
In related news, this function would be the perfect candidate to set
GIT_DIR without environment variables...
git.c | 37 +++++++++++++++++++++++++++++++------
1 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/git.c b/git.c
index ee5a0e8..8d7c644 100644
--- a/git.c
+++ b/git.c
@@ -35,6 +35,27 @@ static void prepend_to_path(const char *
setenv("PATH", path, 1);
}
+static int handle_options(const char*** argv, int* argc)
+{
+ int handled = 0;
+
+ while (*argc > 0) {
+ const char *cmd = (*argv)[0];
+ if (cmd[0] != '-')
+ break;
+
+ if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
+ setup_pager();
+ } else
+ die ("Unknown option: %s", cmd);
+
+ (*argv)++;
+ (*argc)--;
+ handled++;
+ }
+ return handled;
+}
+
static const char *alias_command;
static char *alias_string = NULL;
@@ -106,7 +127,7 @@ static int handle_alias(int *argcp, cons
subdir = setup_git_directory_gently(&nongit);
if (!nongit) {
- int count;
+ int count, option_count;
const char** new_argv;
alias_command = (*argv)[0];
@@ -114,6 +135,10 @@ static int handle_alias(int *argcp, cons
if (alias_string) {
count = split_cmdline(alias_string, &new_argv);
+ option_count = handle_options(&new_argv, &count);
+ memmove(new_argv - option_count, new_argv,
+ count * sizeof(char *));
+ new_argv -= option_count;
if (count < 1)
die("empty alias for %s", alias_command);
@@ -264,6 +289,7 @@ int main(int argc, const char **argv, ch
if (!strncmp(cmd, "git-", 4)) {
cmd += 4;
argv[0] = cmd;
+ handle_alias(&argc, &argv);
handle_internal_command(argc, argv, envp);
die("cannot handle %s internally", cmd);
}
@@ -273,13 +299,12 @@ int main(int argc, const char **argv, ch
/* Look for flags.. */
while (argc > 1) {
- cmd = *++argv;
+ argv++;
argc--;
- if (!strcmp(cmd, "-p") || !strcmp(cmd, "--paginate")) {
- setup_pager();
- continue;
- }
+ handle_options(&argv, &argc);
+
+ cmd = *argv;
if (strncmp(cmd, "--", 2))
break;
^ permalink raw reply related
* Re: Git BOF notes
From: Nguyễn Thái Ngọc Duy @ 2006-07-24 12:08 UTC (permalink / raw)
To: Petr Baudis; +Cc: Catalin Marinas, git
In-Reply-To: <20060724114753.GT13776@pasky.or.cz>
On 7/24/06, Petr Baudis <pasky@suse.cz> wrote:
> Actually, with recent (well, at least half a year ago the situation was
> like that) quality of Sf.net's CVS hosting that might in fact give Git
> some share of negative reputation if they provided a service of similar
> quality. I think some people from Savannah were actually interested in
> Git hosting, though.
I don't think so. Quotes from [1]:
What about support for git / cogito?
No. Savannah can not support every versioning system. That's merely ludicrous.
[1] http://savannah.gnu.org/forum/forum.php?printer=1&forum_id=3944
^ permalink raw reply
* Re: Git BOF notes
From: Petr Baudis @ 2006-07-24 11:47 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <tnxmzaz5q3v.fsf@arm.com>
Dear diary, on Mon, Jul 24, 2006 at 11:06:28AM CEST, I got a letter
where Catalin Marinas <catalin.marinas@arm.com> said that...
> Petr Baudis <pasky@suse.cz> wrote:
> > a short summary of the Git BOF on OLS which finished just a short
> > while ago. We got to hear how Len Brown is doing things and where Git
> > gets in the way for him as well as interesting questions and comments
> > from several other people. The main highlights as I feel them (mixed
> > randomly with my personal blabbering) are that:
>
> What I forgot to mention at the OLS - it would be useful for a more
> wide-spread adoption of GIT to convince some of the source code
> hosting sites (like sourceforge.net) to provide GIT support. For StGIT
> I currently use an HTTP server but that's not the most efficient way.
Actually, with recent (well, at least half a year ago the situation was
like that) quality of Sf.net's CVS hosting that might in fact give Git
some share of negative reputation if they provided a service of similar
quality. I think some people from Savannah were actually interested in
Git hosting, though.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* Re: Can't clone Linus tree
From: Rene Scharfe @ 2006-07-24 10:36 UTC (permalink / raw)
To: Tomasz Torcz; +Cc: linux-kernel, git, Junio C Hamano, Linus Torvalds
In-Reply-To: <44C4992E.3070706@lsrfire.ath.cx>
> Tomasz Torcz schrieb:
>> % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
>> fatal: packfile '/home/zdzichu/linux-git/.git/objects/pack/tmp-1jI4AH' SHA1 mismatch
>> error: git-fetch-pack: unable to read from git-index-pack
>> error: git-index-pack died with error code 128
>> fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
Ah, I just saw this is a known problem and there's a patch by
Matthias Lederhofer, which Junio just accepted, I think (the
mail with subject "[PATCH] upload-pack: fix timeout in
create_pack_file)" on the git mailing list.
The problem is apparently that the server expects you (wrongly)
to finish your download session within ten minutes. Until the
server is fixed you can use rsync:// for the initial clone and
git:// for smaller updates.
René
^ permalink raw reply
* Re: Random Git Issues/Wishlist
From: Catalin Marinas @ 2006-07-24 10:19 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Petr Baudis, git
In-Reply-To: <20060723042725.GA12306@spearce.org>
Shawn Pearce <spearce@spearce.org> wrote:
> Petr Baudis <pasky@suse.cz> wrote:
>> (viii) Patches versioning in StGit - many people I've told about StGit
>> complained that it doesn't version patches (and possibly moved to mq?).
>> We should have some scheme for doing meta-history (especially
>> interesting when/if we aim to make altering history easy).
>
> Doesn't StGit now have a single ref for every patch commit?
Yes, it does and the history is lost.
> What about turning on reflog support on those refs and reading the
> reflog for the ``history'' of that patch? Granted the reflog isn't
> prune proof but it is a history of that ref's values over time.
That's a good idea indeed (I haven't noticed this feature). Anyway, I
don't see any problem with not being prune-safe. I wouldn't want to
preserve the refresh history of a patch forever. If I have a stable
series I want to keep, I either clone it or simply tag it.
I think that people willing to keep the patch history for a number of
years (and be prune-safe) should use topic branches rather than
StGIT. Patches are meant to be more lightweight than topic branches
and might have a shorter life-time. There were some people at the OLS
BOF session even mentioning that they don't care about long-term
history.
The StGIT feature wish-list after the OLS is:
- patch history (I'll probably use reflogs as you suggested)
- configurable pull command (currently uses git-pull only)
- commit directly to a patch which is not top
- patch synchronisation between between branches (as some people,
including me have the same patches based on different branches and
they have scripts for moving the changes in one to the others)
- document the workflow on the StGIT wiki
- maybe a separate undo command rather than passing a --undo option to
push and refresh
--
Catalin
^ permalink raw reply
* Re: Can't clone Linus tree
From: Rene Scharfe @ 2006-07-24 9:55 UTC (permalink / raw)
To: Tomasz Torcz; +Cc: linux-kernel, git, Junio C Hamano, Linus Torvalds
In-Reply-To: <20060724080752.GA8716@irc.pl>
Tomasz Torcz schrieb:
> Hi,
>
> yesterdat I wanted to bisect my kernel problem, but failed at first step:
> cloning Linus' tree. Today I tried it on other system and also failed.
>
> This is git-1.4.0 on Slackware, i586:
>
> % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
> fatal: packfile '/home/zdzichu/linux-git/.git/objects/pack/tmp-1jI4AH' SHA1 mismatch
> error: git-fetch-pack: unable to read from git-index-pack
> error: git-index-pack died with error code 128
> fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
>
> And this is 1.4.0-1.fc5 on FC5, x86_64:
> % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git linux-git
> fatal: packfile '/home/tomek/linux-git/.git/objects/pack/tmp-BxIcIC' SHA1 mismatch
> error: git-fetch-pack: unable to read from git-index-pack
> error: git-index-pack died with error code 128
> fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git' failed.
>
> Errors occur constantly since yesterday. They of course appear after
> downloading several megabytes of data, which is unpleasant on my 128kbps
> connection.
Same here with both the master and next branch of git. rsync as
suggested by Johannes Weiner works. You can change the protocol
back to git in .git/remotes/origin after cloning; pulling small
changes seems to work fine.
strace tells me that safe_read at pkt-line.c:111 gets only 305 of
the expected 996 bytes and then dies. I have no idea how that
might happen. :-/
Pulling the git repository works using the git protocol, btw.
René
^ permalink raw reply
* Re: [PATCH] support cover letter before commit log, using "+++"
From: Jakub Narebski @ 2006-07-24 9:53 UTC (permalink / raw)
To: git
In-Reply-To: <20060724070438.GD20068@admingilde.org>
Martin Waitz wrote:
> I haven't seen the "+++" before here. People have used their own
> "cut here" markers somethimes but I don't think their is an
> established convention already.
Most common I think is the variation of "scissors" separator, i.e.
-- >8 --
> The "+++" just felt good in combination with the "---" end marker.
True.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Git BOF notes
From: Catalin Marinas @ 2006-07-24 9:06 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060719230155.GJ13776@pasky.or.cz>
Petr Baudis <pasky@suse.cz> wrote:
> a short summary of the Git BOF on OLS which finished just a short
> while ago. We got to hear how Len Brown is doing things and where Git
> gets in the way for him as well as interesting questions and comments
> from several other people. The main highlights as I feel them (mixed
> randomly with my personal blabbering) are that:
What I forgot to mention at the OLS - it would be useful for a more
wide-spread adoption of GIT to convince some of the source code
hosting sites (like sourceforge.net) to provide GIT support. For StGIT
I currently use an HTTP server but that's not the most efficient way.
--
Catalin
^ permalink raw reply
* Re: [PATCH] upload-pack: fix timeout in create_pack_file
From: Junio C Hamano @ 2006-07-24 7:55 UTC (permalink / raw)
To: Matthias Lederhofer; +Cc: git
In-Reply-To: <E1G4uZw-0006vZ-VO@moooo.ath.cx>
Matthias Lederhofer <matled@gmx.net> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>
>> My gut feeling is that your patch would be fine as is (have you
>> tried and confirmed that it helps cases other than slow
>> clients?)
> ... I tried a server with --timeout=600 and a client
> that cannot download the whole pack file in 10 minutes. Without the
> patch the server closes the connection, with this patch it works.
> Additionally I tried it with a client reading so slow that the server
> was blocked for more than --timeout seconds, then the server closes
> the connection too (this is more or less the DoS case).
Thanks, that's all I wanted to know. Let's have it.
^ permalink raw reply
* Re: Defaulting fetch to origin when set in the repo-config
From: Junio C Hamano @ 2006-07-24 7:31 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <87mzb1s11r.fsf@gmail.com>
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] Per branch properties for pull
From: Junio C Hamano @ 2006-07-24 7:31 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <87hd1b9fjq.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> writes:
> It extracts all the information for pull from the config file.
>
> If you have a config file as:
>
> [branch "master"]
> remote=origin
> merge=next #the remote name
> octopus=octopus
> twohead=recursive
>
> When doing a "git pull" without extra parameters in the master branch
> it will fetch the origin remote repository and will merge the next
> branch (the remote name).
>
> And you can also put the equivalent of the pull.{octopus,twohead}
> options for each branch.
>
> This only changes the behavour when these keys exist and when
> git-pull is used without extra parameters.
>
> Signed-off-by: Santi Béjar <sbejar@gmail.com>
I am in general in agreement with this line of thought and had
an impression that many on the list wanted to have per-branch
configuration. I am a bit too tired now so I'd just let you
know I am interested but would not apply it tonight.
Opinions? Comments? Anything missing or objectionable on
Santi's patch from the list?
^ permalink raw reply
* Re: [PATCH] upload-pack: fix timeout in create_pack_file
From: Matthias Lederhofer @ 2006-07-24 7:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5bvh67p.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> > This does not help for low timeouts with slow clients. If a client is
> > slow enough so the server is blocked for more time than specified by
> > timeout the connection will be closed too (e.g. 15kb/s with a timeout
> > of 30 (git adds 10 extra) is not enough).
>
> Where do we add 10 extra?
Oops, never mind, I misread the source.
> > We should either add a
> > warning to the man page or try to fix this. I don't know if this can
> > be fixed not using non-blocking sockets.
>
> I think the intent of "timeout" was to protect us from funny
> clients by avoiding talking with the ones that take too much
> time doing something that should not take too long. When we are
> in create_pack_file(), we are already committed to the heaviest
> operation anyway, so one possibility might be to stop doing
> timeout at that point. I am not sure if that is acceptable,
> though -- it opens up the daemon to even easier DoS than it
> currently is.
>
> My gut feeling is that your patch would be fine as is (have you
> tried and confirmed that it helps cases other than slow
> clients?)
What else? The problem solved by this patch is the missing
reset_timeout while downloading pack files and this affects all
clients that are too slow (cannot download the packfile within
--timeout seconds). I tried a server with --timeout=600 and a client
that cannot download the whole pack file in 10 minutes. Without the
patch the server closes the connection, with this patch it works.
Additionally I tried it with a client reading so slow that the server
was blocked for more than --timeout seconds, then the server closes
the connection too (this is more or less the DoS case).
> > Perhaps support for resume would be quite useful too but I've no idea
> > how hard this is to implement.
>
> That would be _very_ hard.
I don't know how much demand there is for resuming but there is always rsync
(at least on kernel.org and other repositories that need it can install it too)
to get the new objects with support for resuming.
^ permalink raw reply
* Re: [RFC] Colorize 'commit' lines in log ui
From: Junio C Hamano @ 2006-07-24 7:06 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060723092417.GA7547@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I think the visual cue makes the git-whatchanged -p output much easier
> to read.
Although I personally do not do much colors (instead I do
"/^commit [0-9a-f]*" under less), I think this makes sense and I
do not think of any obvious downside.
^ permalink raw reply
* Re: [PATCH] support cover letter before commit log, using "+++"
From: Martin Waitz @ 2006-07-24 7:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wsbfq75.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1921 bytes --]
hoi :)
On Sun, Jul 23, 2006 at 11:54:22PM -0700, Junio C Hamano wrote:
> Martin Waitz <tali@admingilde.org> writes:
>
> > We already have a "---" separator to end the commit log.
> > But writing the cover letter after this separator looks strange.
> > Now it is possible to put the cover letter and comments both before
> > or after the commit log, as the author sees fit.
> >
> > Just put the commit log between lines starting with "+++" and "---".
> >
> > Signed-off-by: Martin Waitz <tali@admingilde.org>
>
> I do not have problem with the implementation itself, but
>
> * I always had an impression that cover letters are tolerated
> not encouraged. In other words, as a good practice it would
> be nice if necessary information is described in the commit
> log messages themselves. Do we want to start encouraging the
> cover letter with this patch?
that's right, but:
* before using automatic tools to generate mails from patches people
started their mails with "hello" or something similiar.
As these lines are frowned upon in the changelog people just stop
being polite.
* I have often seen patches evolving in an email thread.
With such an separator it is possible to keep the thread history
in one part and a clean change message in another part.
I don't really know if this +++ thing will be used much. It's just
something that I thought might be missing and it was easy to do ;-)
> * Has anybody ever used that "+++" as an auxiliary separator?
> In other words, is it an established convention? If not,
> would it be a good convention that we would want to establish
> here?
I haven't seen the "+++" before here. People have used their own
"cut here" markers somethimes but I don't think their is an
established convention already.
The "+++" just felt good in combination with the "---" end marker.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] support cover letter before commit log, using "+++"
From: Junio C Hamano @ 2006-07-24 6:54 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060723214524.GC20068@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> We already have a "---" separator to end the commit log.
> But writing the cover letter after this separator looks strange.
> Now it is possible to put the cover letter and comments both before
> or after the commit log, as the author sees fit.
>
> Just put the commit log between lines starting with "+++" and "---".
>
> Signed-off-by: Martin Waitz <tali@admingilde.org>
I do not have problem with the implementation itself, but
* I always had an impression that cover letters are tolerated
not encouraged. In other words, as a good practice it would
be nice if necessary information is described in the commit
log messages themselves. Do we want to start encouraging the
cover letter with this patch?
* Has anybody ever used that "+++" as an auxiliary separator?
In other words, is it an established convention? If not,
would it be a good convention that we would want to establish
here?
^ permalink raw reply
* Re: [PATCH] show-branch: Fix another performance problem.
From: Junio C Hamano @ 2006-07-24 6:46 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87mzb0fbw7.fsf@wine.dyndns.org>
Thanks.
^ permalink raw reply
* Re: [PATCH] pack-objects: check pack.window for default window size
From: Junio C Hamano @ 2006-07-24 6:43 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20060723055030.GA25790@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> For some repositories, deltas simply don't make sense. One can disable
> them for git-repack by adding --window, but git-push insists on making
> the deltas which can be very CPU-intensive for little benefit.
Makes sense. Will apply but with the above three lines as part
of the commit message.
^ permalink raw reply
* Re: Makefile checks for DarwinPorts / Fink
From: Junio C Hamano @ 2006-07-24 6:43 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Jakub Narebski, git
In-Reply-To: <20060724042828.GB9066@spearce.org>
Thanks for the fix and doc.
^ permalink raw reply
* Re: [PATCH 4/4] git.el: Put the git customize group in the 'tools' parent group.
From: Junio C Hamano @ 2006-07-24 6:42 UTC (permalink / raw)
To: Alexandre Julliard; +Cc: git
In-Reply-To: <87u059g3lu.fsf@wine.dyndns.org>
Thanks for all four patches.
^ permalink raw reply
* Re: [PATCH] git-svn: fix fetching new directories copies when using SVN:: libs
From: Junio C Hamano @ 2006-07-24 6:42 UTC (permalink / raw)
To: Eric Wong; +Cc: Ben Williamson, git
In-Reply-To: <20060720084301.GA29440@localdomain>
Thanks.
^ permalink raw reply
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Junio C Hamano @ 2006-07-24 6:42 UTC (permalink / raw)
To: Willy Tarreau, Rene Scharfe; +Cc: git
In-Reply-To: <44BF3B4A.5040109@lsrfire.ath.cx>
Thanks.
^ permalink raw reply
* Re: [PATCH] Fix t4114 on cygwin
From: Junio C Hamano @ 2006-07-24 6:41 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0607181946090.29667@wbgn013.biozentrum.uni-wuerzburg.de>
Thanks.
^ 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