* Re: [PATCH] Enable git rev-list to parse --quiet
From: Junio C Hamano @ 2008-07-20 18:31 UTC (permalink / raw)
To: Nick Andrew; +Cc: git
In-Reply-To: <20080720120437.GC15586@mail.local.tull.net>
Nick Andrew <nick@nick-andrew.net> writes:
> Exiting a process from within a callback function seems to me to violate
> the principle of least surprise.
Huh? Who is surprised?
I do not know who taught you that "do not exit in a callback" dogma, but I
suspect it was misrepresented when it was taught to you.
A library that calls your function back could be structured this way:
lib() {
perform some set-up that affects external world;
call your callback function;
clean-up the effect of previous set-up action;
}
and exiting from your callback function is not a good idea as it prevents
the library from doing the necessary clean-up in such a case.
But that is true just in a(n extremely) general case. Your generalization
is not particularly useful, methinks, and use of exit(0) in the patch is
very well justified (rather, I do not think they even need justifying).
- The callback you are looking at is not a general purpose callback for
other program's use, but written for a specific use of rev-list;
- The purpose of that exit(0) is to signal "there is something" as
quickly as possible, which was what you wanted out of rev-list;
- Revision traversal is a read-only operation and we know that there is
no externally visible set-up done in the function you are calling to
get your callback called, that needs cleaning up later --- this is not
expected to change, as there are longstanding existing callback
functions supplied to traverse_commit_list() that die() upon seeing
errors already.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-20 18:33 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: Keith Packard, git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <1216576183.3673.2.camel@pc7.dolda2000.com>
Hi,
On Sun, 20 Jul 2008, Fredrik Tolf wrote:
> On Sun, 2008-07-20 at 12:27 +0200, Johannes Schindelin wrote:
>
> > Well, this was to be expected, after what I wrote in response to 3. in
> > http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
> >
> > Reality always catches up with you, and here again we see that plink
> > and other siblings of OpenSSH should be best handled with scripts,
> > preferably ones that strip out options they do not recognize.
>
> Otherwise, an alternative may be to always install a script, say
> `git-ssh', that would invoke the real SSH in a manner specific for the
> platform. The exact script installed could even be parametrized by the
> Makefile. For systems using OpenSSH, it would probably just consist of
> `ssh -xT "$@"'.
>
> What do you think?
Umm, why? I fully expect OpenSSH to be the most common ssh helper. I
fail to see why we should optimize for something else.
The GIT_SSH solution works. Why not just leave things like they are?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach 'git merge' that 'recur' merge strategy no longer exists
From: Junio C Hamano @ 2008-07-20 18:33 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Nanako Shiraishi, git
In-Reply-To: <1216555968-31406-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> It co-existed with 'recursive' when rewriting it in C, but it no longer
> available.
>
> Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
> ---
>
> On Sun, Jul 20, 2008 at 07:21:25PM +0900, Nanako Shiraishi <nanako3@lavabit.com> wrote:
>> - { "stupid", 0 },
>
> If we are at it, recur is also something unnecessary here.
Good eyes, both of you. Will roll a die and commit one squashed,
creditting one of you at random ;-)
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-20 18:42 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Keith Packard, git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807202029310.3305@eeepc-johanness>
On Sun, 2008-07-20 at 20:33 +0200, Johannes Schindelin wrote:
> > Otherwise, an alternative may be to always install a script, say
> > `git-ssh', that would invoke the real SSH in a manner specific for the
> > platform. The exact script installed could even be parametrized by the
> > Makefile. For systems using OpenSSH, it would probably just consist of
> > `ssh -xT "$@"'.
> >
> > What do you think?
>
> Umm, why? I fully expect OpenSSH to be the most common ssh helper. I
> fail to see why we should optimize for something else.
I guess I just thought the guys trying to port Git to Windows might find
it helpful as well. I don't really care myself.
> The GIT_SSH solution works. Why not just leave things like they are?
I don't think it is a good idea to leave it like it is, because I think
it is unreasonable to run Git traffic with Minimize-Delay TOS by
default. If for no other reason, changing the TOS would at least make
many networks happier.
Fredrik Tolf
^ permalink raw reply
* Re: [PATCH] Teach 'git merge' that 'recur' merge strategy no longer exists
From: Miklos Vajna @ 2008-07-20 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7vmykc76dn.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 260 bytes --]
On Sun, Jul 20, 2008 at 11:33:24AM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Good eyes, both of you. Will roll a die and commit one squashed,
> creditting one of you at random ;-)
I thought commit messages can have multiple Signed-off-by lines. ;-)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-20 18:57 UTC (permalink / raw)
To: Junio C Hamano
Cc: Fredrik Tolf, Keith Packard, git, Edward Z. Yang,
Steffen Prohaska
In-Reply-To: <7v63r0bejy.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> >> Ah, right. Would it be OK to add the `-x' flag to ssh instead?
> >
> > I think this would be the correct way, together with "-T".
> >
> >> I imagine that that might make git less portable to SSH implementations
> >> other than OpenSSH, but I don't know if that is considered a problem.
> >
> > Well, this was to be expected, after what I wrote in response to 3. in
> > http://thread.gmane.org/gmane.comp.version-control.git/76650/focus=2598
> >
> > Reality always catches up with you, and here again we see that plink and
> > other siblings of OpenSSH should be best handled with scripts, preferably
> > ones that strip out options they do not recognize.
> >
> > IOW something like
> >
> > -- snip --
> > #!/bin/bash
> >
> > plinkopt=
> > while test $# != 0
> > do
> > case "$1" in
> > -p)
> > plinkopt="$plinkopt -P $2"
> > shift
> > ;;
> > -*)
> > # unrecognized; strip out
> > ;;
> > *)
> > break
> > ;;
> > esac
> > shift
> > done
> >
> > exec plink $plinkopt "$@"
> > -- snap --
>
> I think that is a very sensible approach, but just like we have a few
> "built-in" function-header regexps with customization possibilities for
> the user, we might want to:
>
> * Have that "-x", "-T" in the command line we generate for OpenSSH;
>
> * Allow users to specify OpenSSH substitute via a configuration and/or
> environment variable, and have them use your script; and
>
> * Have a built-in logic for selected and common "OpenSSH substitute",
> e.g. plink.
>
> There is no reason to make users suffer an extra redirection for common
> enough alternatives.
>
> Here is to get it started...
How about this instead?
-- snipsnap --
diff --git a/connect.c b/connect.c
index 574f42f..7e7f4d3 100644
--- a/connect.c
+++ b/connect.c
@@ -603,7 +603,8 @@ struct child_process *git_connect(int fd[2], const char *url
*arg++ = ssh;
if (port) {
- *arg++ = "-p";
+ const char *opt = getenv("GIT_SSH_PORT_OPTION");
+ *arg++ = opt ? opt : "-p";
*arg++ = port;
}
*arg++ = host;
^ permalink raw reply related
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-20 19:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, Nanako Shiraishi, git
In-Reply-To: <7vd4l88l77.fsf@gitster.siamese.dyndns.org>
Hi,
On Sun, 20 Jul 2008, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > Third, it would be nice to allow passing extra parameter(s) to the
> > backends, but I do not know what concept is the best here. The
> > strategy1=foo,stategy2=bar limits the input to a single string. Is that
> > enough? Given that recursive=theirs was considered harmful, we don't
> > have too much examples;...
>
> I personally think -sstrategy=string1,string2,... is simply a bad taste.
>
> Why force yourself to parse things by having the users to concatenate
> something that the user could give us separated? If you care about the
> order and association between strategy and their options, you can always
> do:
>
> -s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
> -s strategy2 -X option-1-for-strategy-2 ...
You mean something like
$ git merge -s subtree -X --path -X git-gui/ git-gui/master
Wow. :-)
Speechless,
Dscho
^ permalink raw reply
* [PATCH] git-shell needs $(COMPAT_OBJS)
From: Johannes Sixt @ 2008-07-20 19:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
Discovered by an accidental NO_MMAP=1 in config.mak.
-- Hannes
Makefile | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index c676d97..2be40eb 100644
--- a/Makefile
+++ b/Makefile
@@ -1203,7 +1203,7 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-shell$X: compat/strlcpy.o abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o
+git-shell$X: abspath.o ctype.o exec_cmd.o quote.o strbuf.o usage.o wrapper.o shell.o $(COMPAT_OBJS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^)
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
--
1.5.6.3.443.g5f70e
^ permalink raw reply related
* [PATCH] fix usage string for git grep
From: Jonathan Nieder @ 2008-07-20 19:13 UTC (permalink / raw)
To: git
Without this patch, git-grep gives confusing usage information:
$ git grep --confused
usage: git grep <option>* <rev>* [-e] <pattern> [<path>...]
$ git grep HEAD pattern
fatal: ambiguous argument 'pattern': unknown revision or path no
t in the working tree.
Use '--' to separate paths from revisions
So put <pattern> before the <rev>s, in accordance with actual correct
usage. While we're changing the usage string, we might as well include
the "--" separating revisions and paths, too.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Thanks!
builtin-grep.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 7bf6a71..631129d 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -498,7 +498,7 @@ static int grep_object(struct grep_opt *opt, const char **paths,
}
static const char builtin_grep_usage[] =
-"git grep <option>* <rev>* [-e] <pattern> [<path>...]";
+"git grep <option>* [-e] <pattern> <rev>* [[--] <path>...]";
static const char emsg_invalid_context_len[] =
"%s: invalid context length argument";
--
1.5.6.4.441.g4b4e9
^ permalink raw reply related
* Re: [RFC variant 2 of 2] "needs update" considered harmful
From: Junio C Hamano @ 2008-07-20 19:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, git
In-Reply-To: <alpine.DEB.1.00.0807201435450.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 20 Jul 2008, Petr Baudis wrote:
>
>> Scripts need to be modified for the reorganization anyway,
>
> No. They do not, if the 1st variant is applied.
I think Pasky's point is that people who did not bother updating their
scripts with PATH=$(git --exec-path):$PATH as described in the deprecation
notice when we went 1.5.4 now have to do so.
But if they did, they have to update again. The more elaborate variant
avoids that, at the expense of different wordings between Porcelain and
plumbing.
I personally think there is nothing wrong if Porcelain and plumbing use
different languages, by the way. It seems that the general concensus will
be to split the Porcelain and the plumbing manuals into separate volumes
targetted for different audiences, and it is more important to keep the
plumbing output stable as part of an established API than making the same
thing called using the same wording in different languages.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Junio C Hamano @ 2008-07-20 19:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Fredrik Tolf, Keith Packard, git, Edward Z. Yang,
Steffen Prohaska
In-Reply-To: <alpine.DEB.1.00.0807202035090.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> How about this instead?
>
> -- snipsnap --
> diff --git a/connect.c b/connect.c
> index 574f42f..7e7f4d3 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -603,7 +603,8 @@ struct child_process *git_connect(int fd[2], const char *url
>
> *arg++ = ssh;
> if (port) {
> - *arg++ = "-p";
> + const char *opt = getenv("GIT_SSH_PORT_OPTION");
> + *arg++ = opt ? opt : "-p";
> *arg++ = port;
> }
> *arg++ = host;
If you only care only about the ones we currently want to support, I do
not htink it makes any difference either way, but if we are shooting for
having a minimum-but-reasonable framework to make it easy to support other
ones that we haven't seen, it feels very much like an inadequate hack to
waste an envirnoment variable for such a narrow special case. With this,
what you really mean is "Plink uses -P instead of -p", right?
I do not know if "plink" is used widely enough to be special cased, but if
so, I think we would better have an explicit support for it. Will we add
GIT_SSH_FORBID_X11_FORWARDING_OPTION environment variable and friends,
too?
The extra environment would not help dealing with an implementation that
wants --port=90222 (i.e. not as two separate arguments but a single one),
for example. You would need the extra wrapper support for that kind of
thing anyway. That extra environment _solution_ will need to make an
assuption that any reasonable implementation would have an option string
to specify port which may not be "-p" and that is to be followed by a
separate argument that is a decimal port number, which probably is
reasonable for this particular "port" thing, but as a general design
principle I do not think it is a good direction to go.
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-20 19:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Nanako Shiraishi, git
In-Reply-To: <alpine.DEB.1.00.0807202102370.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> I personally think -sstrategy=string1,string2,... is simply a bad taste.
>>
>> Why force yourself to parse things by having the users to concatenate
>> something that the user could give us separated? If you care about the
>> order and association between strategy and their options, you can always
>> do:
>>
>> -s strategy1 -X option-1-for-strategy-1 -X option-2-for-strategy-1 \
>> -s strategy2 -X option-1-for-strategy-2 ...
>
> You mean something like
>
> $ git merge -s subtree -X --path -X git-gui/ git-gui/master
>
> Wow. :-)
I would envision it to be more like:
$ git merge -s subtree -Xpath=git-gui git-gui/master
which git-merge internally would turn into:
$ git-merge-subtree --path=git-gui HEAD -- OURS THEIRS
That way both the external command line (that the end users do care about)
and the internal one (that the strategy programmer would care about) look
a lot more sensible than your command line, don't they?
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Sverre Rabbelier @ 2008-07-20 20:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Miklos Vajna, Nanako Shiraishi, git
In-Reply-To: <7vd4l85nv5.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>> You mean something like
>>
>> $ git merge -s subtree -X --path -X git-gui/ git-gui/master
>>
>> Wow. :-)
>
> I would envision it to be more like:
>
> $ git merge -s subtree -Xpath=git-gui git-gui/master
Whatever happened to quotes?
$ git merge -s subtree -Xpath="git-gui git-gui/master"
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Dmitry Potapov @ 2008-07-20 20:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Eric Wong
In-Reply-To: <7vbq0tibuf.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 19, 2008 at 06:27:36PM -0700, Junio C Hamano wrote:
>
> So what's the conclusion of this issue?
>
> I'll just revert 2fe403e (git-svn.perl: workaround assertions in svn
> library 1.5.0, 2008-07-06) for 1.6.0-rc0 unless I hear better
> suggestions.
I have tested the change that I proposed, and it seems to solve the
problem and, as far as I can tell, no other correction is necessary.
Yet, I don't really understand git-svn well, so I could be wrong.
Reverting 2fe403e will only help users of svn library 1.4, while all
new linux distributives, which will include Git 1.6.0, are going to
install svn library 1.5.0, and if you use svn library 1.5.0, reverting
2fe403e does not fix anything but only add one more bug. Thus, unless
we are going to require to install git-svn only with svn library 1.4,
reverting this change does not seem to be very helpful for most users.
So, I hope my patch is better solution...
Dmitry
-- 8< --
From: Dmitry Potapov <dpotapov@gmail.com>
Date: Thu, 17 Jul 2008 22:32:02 +0400
Subject: [PATCH] git-svn: fix git svn info to work without arguments
commit 2fe403e7452bd6e1e8232445cf5434ce8f1af973 broke "git-svn info ."
due to replacing '.' with '' in canonicalize_path for the top directory,
while find_file_type_and_diff_status was not corrected.
Bug reports:
http://thread.gmane.org/gmane.comp.version-control.git/87822/
http://bugs.debian.org/490400
Signed-off-by: Dmitry Potapov <dpotapov@gmail.com>
---
git-svn.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index a366c89..b00a91a 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -1226,7 +1226,7 @@ sub linearize_history {
sub find_file_type_and_diff_status {
my ($path) = @_;
- return ('dir', '') if $path eq '.';
+ return ('dir', '') if $path eq '';
my $diff_output =
command_oneline(qw(diff --cached --name-status --), $path) || "";
--
1.5.6.3
^ permalink raw reply related
* git blame --porcelain
From: Sverre Rabbelier @ 2008-07-20 20:28 UTC (permalink / raw)
To: Git Mailinglist
Heya,
Contrary to what one would expect, the '--porcelain' switch to 'git
blame' makes the output suitable for... plumbing use? As far as 'git
blame builtin-blame.c' tells me (gotta love the recursion there) it
has been this way since cee7f245 when the option was introduced. What
is the rationale behind this? Is it called '--porcelain' because it is
meant to be used by the plumbing to create new porcelain? That seems a
bit far-fetched though...
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Miklos Vajna @ 2008-07-20 20:33 UTC (permalink / raw)
To: sverre; +Cc: Junio C Hamano, Johannes Schindelin, Nanako Shiraishi, git
In-Reply-To: <bd6139dc0807201303u406484e2x127b2391a9920425@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
> On Sun, Jul 20, 2008 at 9:58 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> >> You mean something like
> >>
> >> $ git merge -s subtree -X --path -X git-gui/ git-gui/master
> >>
> >> Wow. :-)
> >
> > I would envision it to be more like:
> >
> > $ git merge -s subtree -Xpath=git-gui git-gui/master
>
> Whatever happened to quotes?
>
> $ git merge -s subtree -Xpath="git-gui git-gui/master"
Read again what did you wrote. ;-)
The current form is
git merge -s subtree git-gui/master, so at most it could be
$ git merge -s subtree -Xpath="git-gui" git-gui/master
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Junio C Hamano @ 2008-07-20 20:33 UTC (permalink / raw)
To: sverre
Cc: Junio C Hamano, Johannes Schindelin, Miklos Vajna,
Nanako Shiraishi, git
In-Reply-To: <bd6139dc0807201303u406484e2x127b2391a9920425@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> Whatever happened to quotes?
>
> $ git merge -s subtree -Xpath="git-gui git-gui/master"
Nothing special needs to happen. That would naturally be passed to the
underlying strategy as the equivalent of:
$ git merge-subtree --path="git-gui git-gui/master"
but now "git-merge" is in C, it does not have to quote nor unquote
explicitly itself. Unquoting will be done by the shell when you call
"git-merge", and quoting is unneeded when you give each argument as a
separate string in **argv to call execv().
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Sverre Rabbelier @ 2008-07-20 20:34 UTC (permalink / raw)
To: Jay Soffian
Cc: Johannes Schindelin, Tarmigan, Junio C Hamano, git,
Michael J Gruber
In-Reply-To: <76718490807200545l653bbda1l4d13f1e1e698c855@mail.gmail.com>
On Sun, Jul 20, 2008 at 2:45 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> Lastly, I point out that when I started with git, it became much
> clearer when I began reading "git add" as "git stage". I think my
> first alias was "staged => diff --cached". But I am someone who likes
> to learn how the things I use work early on.
I love it, and the great thing is that auto-complete works on it too!
"git diff --cached" 17 keystrokes
"git stag" 8 keystrokes
That's a 9 keystrokes improvement!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: git blame --porcelain
From: Junio C Hamano @ 2008-07-20 20:34 UTC (permalink / raw)
To: sverre; +Cc: Git Mailinglist
In-Reply-To: <bd6139dc0807201328i41aa7d09jf9a1c4dc6f60a367@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> Is it called '--porcelain' because it is
to help porcelain writers.
^ permalink raw reply
* [RFC] Stopping those fat "What's cooking in git.git" threads
From: Miklos Vajna @ 2008-07-20 20:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 882 bytes --]
Hi,
As far as I remember, it was Petr Baudis who first asked on IRC if
these threads (being so big and deep) are annoying for other people as
well or not.
I think it's just hard to follow the discussion as the subject is
usually not changed, so for example when the subject contains "merge", I
carefully read that mail, but I can easily miss such a mail if it's
still "What's cooking in".
An other problem with deep threads is that it just doesn't fit in one's
screen, so I had to use tricks for example to see if a mail was a reply
to my mail or to some other mail.
So here is what I thought about: What about if everyone (except Junio,
of course) would change the subject _and_ remove the In-Reply-To: header
when replying to those mails?
If those large threads just annoys a few people and most people are
happy with the current situation then sorry for the noise.
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] git-add -a: add all files
From: Lars Noschinski @ 2008-07-20 20:46 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jay Soffian, Johannes Schindelin, Tarmigan, git, Michael J Gruber
In-Reply-To: <7v4p6k8l36.fsf@gitster.siamese.dyndns.org>
* Junio C Hamano <gitster@pobox.com> [08-07-20 20:30]:
>So for such people who would find "add -A" useful, "commit -a" will not be
>"unrelated changes in the same commit". And for such people, I would even
>say "commit -A" would be even more useful, too.
There is one occasion I could use a "add -A": To shorten
git add -u; git add .; git commit -m "wip"; git checkout $stuff
So in my opinion, if one wants a "stage my whole workdir" option, it
would be suited best as an option to commit (and maybe stash).
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Stephan Beyer @ 2008-07-20 20:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080720205125.GP10347@genesis.frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 1350 bytes --]
Hi,
Miklos Vajna wrote:
> I think it's just hard to follow the discussion as the subject is
> usually not changed, so for example when the subject contains "merge", I
> carefully read that mail, but I can easily miss such a mail if it's
> still "What's cooking in".
I agree that changing a subject (with "(was: <oldsubject>)") is nicer to
find specific mails later.
> So here is what I thought about: What about if everyone (except Junio,
> of course) would change the subject _and_ remove the In-Reply-To: header
> when replying to those mails?
"Everyone should" bla usually does not work in open communities.
And why not vice versa?
A new "What's cooking in " mail with new cookings could start a new
thread instead of replying to old "What's cooking in" mails...
> If those large threads just annoys a few people and most people are
> happy with the current situation then sorry for the noise.
Hm, I don't really care.
Mutt is able to link and break threads with
# break-thread break the thread in two
& link-threads link tagged message to the current one
so I am able to design the threads as I like it ;)
(And I am also able to change subjects as I like, so I don't have a
problem.)
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Junio C Hamano @ 2008-07-20 21:05 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080720205125.GP10347@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> So here is what I thought about: What about if everyone (except Junio,
> of course) would change the subject _and_ remove the In-Reply-To: header
> when replying to those mails?
>
> If those large threads just annoys a few people and most people are
> happy with the current situation then sorry for the noise.
I could make "What's cooking" not a follow-up to the previous issue, or
perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
But I think it is a good idea to change the subject when responding to one
part of the message to say which topic your response is about.
I do not know if stripping "In-reply-to" is a great idea, though. They
are responses, aren't they?
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Miklos Vajna @ 2008-07-20 21:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsku44679.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 660 bytes --]
On Sun, Jul 20, 2008 at 02:05:30PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> But I think it is a good idea to change the subject when responding to one
> part of the message to say which topic your response is about.
It was me as well, who did not change the subject; I'll try to pay
attention to do so.
> I do not know if stripping "In-reply-to" is a great idea, though. They
> are responses, aren't they?
Personally I'm fine with mutt's "break thread" feature, I just proposed
it because I saw it was mentioned multiple times that gmane does not
handle huge threads nicely. But yes, you have reason about keeping the
header makes sense as well.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git Branding Overview, Re: Git.or.cz Experimental Design
From: Matt Graham @ 2008-07-20 21:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: David Baldwin, git
In-Reply-To: <20080718103918.GO10151@machine.or.cz>
I like the existing icons with
---
+++
Please don't get rid of the minuses and pluses.
On Fri, Jul 18, 2008 at 6:39 AM, Petr Baudis <pasky@suse.cz> wrote:
> Hi,
>
> On Wed, Jul 02, 2008 at 11:11:02PM -0400, David Baldwin wrote:
>> Hello Petr:
>> I hope you are doing well. I was looking at the git.or.cz site tonight and
>> thought it could perhaps use a little freshening up from a design
>> standpoint. Therefore, I messed around with the default stylesheet and the
>> home page a bit and made a logo. You can take a look at the experimental
>> design at this address...
>> http://baldwindev.com/git.or.cz/
>>
>> It's really just a few little changes. If you're interested in implementing
>> any of this into the current site, feel free to grab the changes from my
>> github git repository. You can see the few text changes in the diff...
>> http://github.com/bilson/gitorcz_redesign/tree/master
>
> I'm not sure if this is really an improvement on the current state,
> but then again, the current state pretty much matches my idea and maybe
> others will agree that your proposal is better. Thus, it's better to
> show this to the Git community at large. :-)
>
> If you or anyone is shooting for a re-design, I would suggest to
> somehow relate to the current "Git brandings" in use:
>
> http://git.or.cz/git-logo.png
> http://henrik.nyh.se/uploads/git-logo.png
>
> If you think you have a cooler logo, that's fine too, but then it's
> again better to present it explicitly, I believe. The latter is used
> especially within mSysGit, the former is used more widely - at the
> current homepage, as Gitweb logo, and in various modifications like
>
> http://git.nyh.se/git-favicon.png
> http://members.cox.net/junkio/git.png
> http://unfuddle.com/images/screens/source.big.jpg
> (top left ;)
>
> --
> Petr "Pasky" Baudis
> GNU, n. An animal of South Africa, which in its domesticated state
> resembles a horse, a buffalo and a stag. In its wild condition it is
> something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ 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