* Re: [PATCH] push: Learn to set up branch tracking with '--track'
From: Jeff King @ 2009-02-02 13:16 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901301804030.3586@pacific.mpi-cbg.de>
On Fri, Jan 30, 2009 at 06:05:30PM +0100, Johannes Schindelin wrote:
> > I think the right thing to do is:
> >
> > 1. factor out "generic" routines from send-pack, including status
> > output formatting and tracking ref updating
> >
> > 2. refactor http-push to use those routines, bringing it in line with
> > send-pack
> >
> > 3. add --track support in the same generic way, and hook it from both
> > transports
>
> Now we're thinking along the same lines!
OK, good.
> > I can try to work on this, but I'm not excited about major surgery to
> > http-push, which I don't have a working test setup for.
>
> You don't have an apache installed?
No, though "apt-get install apache" is easy enough. I was more concerned
about wading through the mess of apache configuration to turn on webdave
support. But that is just my empty grumbling and complaining; it's not a
real stumbling block to doing this patch.
And when I wrote that, I was fully intending to pick up this topic and
work on the steps outlined above.
_But_.
It looks like the consensus is to add a branch.master config section
even when cloning an empty repo. And that should address my concern in
the 99% of cases where people use the default "master" setup. Which kind
of takes away the main use case for this topic.
So it doesn't make much sense to me to put effort into it now. The
http-push cleanups might be nice for http-push users, but I don't
remember even seeing a single user request or complaint about it. So I
am not too keen to go cleaning up code that _I_ don't care about, and
that I am not sure anyone _else_ even cares about.
-Peff
^ permalink raw reply
* Re: 'git clone' doesn't use alternates automatically?
From: Jeff King @ 2009-02-02 13:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: James Pickens, Git ML
In-Reply-To: <7v7i4b2bto.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 31, 2009 at 05:19:31PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > - without either, copy alternates from origin, but _don't_ use
> > alternates while cloning
>
> Are you talking about a local clone optimization that does hardlink from
> the source repository?
Sorry, I was wrong about what was happening. From reading James' posts
and not doing any experimenting or looking, I had the impression that
doing this:
# plain repo
mkdir repo1 &&
(cd repo1 && git init &&
echo content >file && git add . && git commit -m one)
# repo with alternates, but extra content
git clone -s repo1 repo2 &&
(cd repo2 &&
echo content >>file && git commit -a -m two)
# clone of repo w/ alternates
git clone repo2 repo3
would cause the final clone to set up the alternate to repo1, but still
pull in the objects. But that isn't the case, of course. Either:
1. It is a local hardlink clone, in which case we just pull in the
objects from repo2.
2. It isn't, in which case we don't copy over the alternates.
> I am fairly certain that copying alternates from the source repository was
> not an intended behaviour but was a consequence of lazy coding of how we
> copy (or link) everything from it. The original was literally the simple
> matter of:
>
> find objects ! -type d -print | cpio $cpio_quiet_flag -pumd$l "$GIT_DIR/"
>
> whose intention was to copy objects/?? and objects/pack/. and it wasn't
> even part of the design consideration to worry about what would happen to
> the alternates the source repository might have in objects/info/.
Right, I think that is what is going on. And what I was suggesting in my
other email is that it is actively harmful to have this behavior,
because now repo3 depends on repo1, without the user having explicitly
asked for such a relationship (and they might not even be aware of
repo1).
I was tempted to suggest avoiding copying the alternates from repo2
to repo3. But you can't do that: repo2 is _missing_ objects that repo3
won't have. Without the alternates file pointing to repo1, repo3 is
corrupt. So simply avoiding copying the alternates file doesn't work;
one would have to actually pull the missing objects in from the
alternate before doing so.
But actually, I think there is even more breakage in hardlinking the
alternates file: alternates files can be relative paths. So if repo2
points to "../../../repo1/.git/objects" (which it doesn't in the example
above, as "clone -s" uses absolute paths -- but it is easy enough to
construct a broken case), then repo3 will gain that alternate pointer,
but may be in a totally different directory where that relative path is
broken. And then repo3 is corrupt. So the alternates must be copied and
any relative paths munged for it to work reliably.
The hardlink code operates by default because it was thought to be a
safe optimization that couldn't bite people. But it interacts badly with
the concept of alternates. So I think a sane fix would be to disable
hardlinking if the parent repo is using alternates at all. Then a
vanilla "git clone repo2 repo3" will do the safe but more costly
behavior of actually copying the objects. If the user wants to accept
the risks of alternates, then he can give "-s" explicitly, and git will
track the alternates recursively through repo2 to repo1 at runtime.
-Peff
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Jeff King @ 2009-02-02 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git
In-Reply-To: <7vy6wr0wvi.fsf@gitster.siamese.dyndns.org>
On Sat, Jan 31, 2009 at 05:27:45PM -0800, Junio C Hamano wrote:
> I haven't manged to convince myself about the "git init" change (I have
> the code and also I've looked at the extent of damage the change causes to
I think the "git init" change doesn't make sense. In fact, I don't think
such a proposal ever really makes sense (and I have even proposed it in
the past, but others arguments have changed my way of thinking).
The reason is that you are just moving the breakage to a different point
in their workflow. The claim is that it's not OK for this to break:
cd foo && git init
git push ;# ok
... time passes, git upgrade ...
git push ;# broken
but it somehow _is_ OK for this to break:
cd foo && git init
git push ;# ok
... time passes, git upgrade ...
cd bar && git init
git push ;# broken
In both cases, you have a sequence of commands that does one thing with
one git version, and something else with another git version. The only
difference is whether your sequence includes git init. So while you
don't break people with existing repositories, you are still breaking
anybody who creates a new one and gets confused when there is new
behavior (or even has scripts which involve repository creation).
So in my opinion either the breakage is serious enough not to allow the
change, or minor enough (compared to the benefit) to allow it. But
changing default config in git init is:
- a half-way solution that leaves some workflows broken and some not
- possibly even _worse_, since now we have sacrificed consistency. So
now users wonder why some of their repos show breakage and some
don't. Or why a particular behavior goes away when they try to write
a test case that involves creating a new test repo.
And note that it doesn't matter whether you think the right path is to
make the change or not: I am only arguing here against this sort of
half-way technique.
> -- >8 --
> Subject: [PATCH] receive-pack: explain what to do when push updates the current branch
>
> This makes "git push" issue a more detailed instruction when a user pushes
> into the current branch of a non-bare repository without having an
> explicit configuration set to receive.denycurrentbranch. In such a case,
> it will also tell the user that the default will change to refusal in a
> future version of git.
I think this is a definite improvement over the current behavior. As I
said before, I am not sure what is the right path (though I think I am
leaning towards leaving the warning longer based on the recent
discussion), but if we are to leave the default to warn and not refuse,
I think this should definitely be applied.
A few comments on the specific message:
> }
>
> +static char *warn_unconfigured_deny_msg[] = {
> + "Updating the currently checked out branch may cause confusion,",
> + "as the index and work tree do not reflect changes that are in HEAD."
> + "As a result, you may see the changes you just pushed into it",
Missing comma between lines 2 and 3, which results in an overly long
line in the output.
> + "You can set 'receive.denyCurrentBranch' configuration variable to",
> + "'refuse' in the repository to forbid pushing into the current branch",
> + "of it."
Maybe this should specifically say "remote repository". If you
understand how the feature works, it is obvious that you must do it that
way, but for less advanced users it is not even clear that this text is
being generated by the remote end.
> + "To allow pushing into the current branch, you can set it to 'ignore';",
> + "but this is not recommended unless you really know what you are doing."
I thought somebody (you?) argued against the phrase "unless you really
know what you are doing". And it is better here in context explaining
the general issue. But as a user, now I have to ask: do I know what I am
doing, and if not, how do I find out?
The two obvious solutions for people who "know what they are doing" are
running "git reset --hard", and installing a hook that does something
sensible. I don't know if it is worth mentioning them here (the former
is mentioned earlier in the message, but that doesn't necessarily mean
the user understands all the implications). Since there are so many
subtleties to explain, maybe it make sense to simply put in a pointer to
an expanded discussion in the "git push" manpage?
-Peff
^ permalink raw reply
* Re: [PATCH] builtin-blame.c: Use utf8_strwidth for author's names
From: Jeff King @ 2009-02-02 12:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Geoffrey Thomas, git
In-Reply-To: <7v8wopmizw.fsf@gitster.siamese.dyndns.org>
On Sun, Feb 01, 2009 at 10:48:51PM -0800, Junio C Hamano wrote:
> > I do not know what encoding the author is at that point, but if you cannot
> > be sure that it is UTF-8, using utf8_strwidth() is just as wrong as the
> > current code, IMHO.
>
> That is true, but then we are not losing anything.
>
> This codepath is not about the payload (the contents of the files) but the
> author name part of the commit log message, and UTF-8 would probably be
> the only sensible encoding to standardize on.
>
> If your project uses UTF-8 for everybody, great, we will align them better
> than we did before. If not, sorry, you will get a different misaligned
> names.
>
> That assumes utf8_width() does not barf when fed an invalid byte sequence,
> but I did not think it is that fragile (I didn't actually audit the
> codepath, though).
We should be able to know the encoding (we call reencode_commit_message,
but we don't bother to save the result). It should be trivial to do:
int strwidth(const char *s, const char *encoding)
{
if (!strcmp(encoding, "utf-8"))
return utf8_strwidth(s);
/* ideally, else if (some_other_encoding_family) */
else
return strlen(s);
}
Then utf-8 is fixed, and other encodings keep identical behavior (and
don't even waste cycles on utf-8 decoding). And it should be obvious to
anyone who wants to add a width detector for their pet encoding where it
should go.
-Peff
^ permalink raw reply
* Re: [PATCH] builtin-blame.c: Use utf8_strwidth for author's names
From: Johannes Schindelin @ 2009-02-02 12:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geoffrey Thomas, git
In-Reply-To: <7v8wopmizw.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2540 bytes --]
Hi,
On Sun, 1 Feb 2009, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 30 Jan 2009, Geoffrey Thomas wrote:
> >
> >> Currently, however, printf("%*.*s", width, width, author) is simply
> >> wrong, because printf only cares about bytes, not screen columns. Do
> >> you think I should fall back on the old behavior if
> >> i18n.commitencoding is set, or if at least one of the author names
> >> isn't parseable as UTF-8, or something? Or should I be doing this
> >> with iconv and assuming all commits are encoded in the current
> >> encoding specified via $LANG or $LC_whatever?
> >
> > I do not know what encoding the author is at that point, but if you
> > cannot be sure that it is UTF-8, using utf8_strwidth() is just as
> > wrong as the current code, IMHO.
>
> That is true, but then we are not losing anything.
>
> This codepath is not about the payload (the contents of the files) but
> the author name part of the commit log message, and UTF-8 would probably
> be the only sensible encoding to standardize on.
Almost agree, except for shops where you have an enforced encoding that
you cannot easily change.
And last time I checked, many more encodings used 1 character/byte (or for
that matter, 1 column / byte) than not; utf8_width would be "more wrong"
than strlen() here, because strlen() would "happen to work" here.
> If your project uses UTF-8 for everybody, great, we will align them
> better than we did before. If not, sorry, you will get a different
> misaligned names.
There _has_ to be a way to check if the current author string is encoded
in UTF-8. All I am asking is that the original poster would put just a
_little_ more effort into the issue and make the thing dependent on the
knowledge -- as opposed to the assumption -- that the author is encoded in
UTF-8.
> That assumes utf8_width() does not barf when fed an invalid byte
> sequence, but I did not think it is that fragile (I didn't actually
> audit the codepath, though).
That is the code that barfs in wcwidth:
if (ch < 32 || (ch >= 0x7f && ch < 0xa0))
return -1;
That is not a big problem, but Geoff's code does not handle that case
correctly. For example, in Code-page 437, a name like "£ïñûç" would
result in a negative width.
But hey, it is definitely not my itch, I will never suffer from the
fallout of this patch, as I am safely within US-ASCII. I just thought I
saw a potential problem and a possible way out. That's it.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Sam Vilain @ 2009-02-02 10:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git
In-Reply-To: <7v1vuhkzmp.fsf@gitster.siamese.dyndns.org>
On Mon, 2009-02-02 at 00:32 -0800, Junio C Hamano wrote:
> > The other affects
> > a small number of users who are doing something which is labeled in many
> > places as a bad thing to want to do.
>
> Sorry, but I do not agree with this.
>
> What is bad is to push into a repository that is used for editing. That
> is labelled as a bad thing to want to do.
>
> It is often the easiest to push and then run "reset --hard" (perhaps from
> the post-update script) to propagate your change to a repository that is
> not usually used for editing. E.g. that has always been the way I update
> my private repository at k.org that I use for final testing before pushing
> out the results that I built and tested on my personal machine. People
> who have live web pages served from a checkout do that, too. It is not a
> bad thing to do at all, and you can find many instructions with google
> without spending a lot of time to do exactly that.
>
> http://kerneltrap.org/mailarchive/git/2008/7/1/2315924
> http://utsl.gen.nz/git/post-update
Heh, thanks for referring me to my own script ;-)
I think a "repository that is used for editing" can be practically
defined as one which does not have any dirty local files. Or, if there
are dirty local files then they are none of the files which would be
changed by the push, or none of them would be changed by the push.
Similar to the check that 'git merge' does.
With that definition, if receive.denyCurrentBranch is set to "update" it
could be pretty much automagic, perhaps even good enough behaviour to
consider making it the default. This kind of behaviour is what my
post-update hook tries to achieve, but it really needs a corresponding
piece in the update hook, and I didn't code all of the conditions above
into it.
Sam.
^ permalink raw reply
* Re: [PATCH] builtin-config: add --exec-editor for use in scripts
From: Jakub Narebski @ 2009-02-02 9:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Eric Wong, git
In-Reply-To: <7v4ozdo7yt.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Eric Wong <normalperson@yhbt.net> writes:
>
> > This exposes the launch_editor() library function for use by
> > various scripting languages. This allows the ensure consistent
> > handling of GIT_EDITOR/VISUAL/EDITOR environment variables as
> > well as the handling of special characters such as spaces in the
> > various environment variables.
> >
> > Signed-off-by: Eric Wong <normalperson@yhbt.net>
> > ---
> >
> > I'm not sure if git-config is the best place to stick it. I plan to
> > start using this in git-svn but I don't want to implement Git::Editor
> > in Perl and have to keep track of editor.c. Of course this also makes
> > the logic/rules used in libgit usable to any other scripting language
> > capable of launching other programs.
>
> I agree that git-config is probably a wrong place. A separate command
> "git editor" (or "git user-preference --editor", if you extend it to pager
> and others) perhaps?
>
> I also agree that something like this would make scripting Porcelains a
> much pleasant experience.
I don't think this is something that should be put in 'git rev-parse',
but perhaps a bit obscure 'git var' (print a git logical variable)
would be a good place for that?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/3] git-add -i/-p: Change prompt separater from slash to comma
From: William Pursell @ 2009-02-02 9:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6wpl1mx.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> William Pursell <bill.pursell@gmail.com> writes:
>
>> Not a major complaint, but how about localizing the occurence
>> of the separator. Something like this:
>
> I think that is sensible. I've already queued the resurrected series to
> 'next' and am deep in the process of tonight's pushout preparation (this
> time I've even written What's cooking), so I'd rather not rewind what I
> have already and redo it. Could you send an incremental update on top of
> what's in next (more specifically ace30ba (In add --patch, Handle K,k,J,j
> slightly more gracefully., 2008-11-27) please?
Here's a patch against ace30ba. Minor change from the initial
patch includes adding '?' to the join argument for consistency
with previous prompt string, and adding '/' to the initialization
of $other to accomodate dd971cc.
Localize the command separator.
Signed-off-by: William Pursell <bill.pursell@gmail.com>
---
git-add--interactive.perl | 19 ++++++++++---------
1 files changed, 10 insertions(+), 9 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 30ddab2..4500e62 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -922,7 +922,7 @@ sub patch_update_file {
while (1) {
my ($prev, $next, $other, $undecided, $i);
- $other = '';
+ $other = 'ynad/';
if ($num <= $ix) {
$ix = 0;
@@ -930,25 +930,25 @@ sub patch_update_file {
for ($i = 0; $i < $ix; $i++) {
if (!defined $hunk[$i]{USE}) {
$prev = 1;
- $other .= ',k';
+ $other .= 'k';
last;
}
}
if ($ix) {
- $other .= ',K';
+ $other .= 'K';
}
for ($i = $ix + 1; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$next = 1;
- $other .= ',j';
+ $other .= 'j';
last;
}
}
if ($ix < $num - 1) {
- $other .= ',J';
+ $other .= 'J';
}
if ($num > 1) {
- $other .= '/g';
+ $other .= 'g';
}
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
@@ -959,13 +959,14 @@ sub patch_update_file {
last if (!$undecided);
if (hunk_splittable($hunk[$ix]{TEXT})) {
- $other .= ',s';
+ $other .= 's';
}
- $other .= ',e';
+ $other .= 'e';
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
- print colored $prompt_color, "Stage this hunk [y,n,a,d,/$other,?]? ";
+ print colored $prompt_color, "Stage this hunk [" .
+ join(",", split("", $other . "?")) . "]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
--
1.6.1.265.g9a013.dirty
--
William Pursell
^ permalink raw reply related
* Re: [RFC PATCH] add -p: prompt for single characters
From: Junio C Hamano @ 2009-02-02 8:50 UTC (permalink / raw)
To: Thomas Rast; +Cc: Suraj Kurapati, git, Jeff King
In-Reply-To: <200902020934.06128.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
> Suraj Kurapati wrote:
>> On Sun, Feb 1, 2009 at 12:35 PM, Thomas Rast <trast@student.ethz.ch> wrote:
>> > http://thread.gmane.org/gmane.comp.version-control.git/100146
>> >
>> > I can't find the v4 promised there, so I assume Suraj dropped it.
>>
>> Yes, I lost the motivation to develop the patch any further. Sorry.
>
> Ok.
>
> I see Junio has already merged wp/add-patch-find, so I'll rebuild on
> top of that and see what needs to be changed.
This is not a very high priority request, but I personally find the prompt
sitting there until I type Enter somewhat assuring, because I often think,
type "y", think again, and then finally type "Enter".
I'd appreciate if you can allow this "single stroke" mode to be optionally
turned off by the end user.
^ permalink raw reply
* Re: [PATCH v2 1/4] Add log.mailmap as configurational option for mailmap location
From: Junio C Hamano @ 2009-02-02 8:40 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git
In-Reply-To: <4986AE47.3010305@trolltech.com>
Marius Storm-Olsen <marius@trolltech.com> writes:
> Junio C Hamano said the following on 02.02.2009 08:56:
>> Marius Storm-Olsen <marius@trolltech.com> writes:
>>> Junio C Hamano said the following on 02.02.2009 04:01:
>>>> Should it always be a wholesale override, or should it also
>>>> support augmenting the repository version with a private copy?
>>> Sure, I can rewrite it to be augmenting, rather than overriding. I
>>> assume that the normal .mailmap file should be parsed first,
>>> then the log.mailmap one?
>>
>> Augmenting one would behave that way. I was more wondering if
>> people would want to be able to choose either, perhaps from the
>> command line option or something.
>
> Oh, I see. *ponder* maybe, though you could say that about any option
> in the .git/config file, right?
I was more thinking along the line of how .gitignore works, accumulating
exclude patterns we find from .gitignore files along the way while
descending into the directory hierarchy, and all the while honoring what
the user added in .git/info/excludes.
> I'm not sure of the use case of the command line option. In which case
> would you want to only use the mailmap for that one command? It
> doesn't normally affect your git commands, so it doesn't hurt to just
> set the log.mailmap option. The environment use case would be just
> like setting it in your ~/.gitconfig, other than you can have a
> different one for each console, I guess.
Yeah, that is exactly why I suggested you to say that is overengineered
and is not useful ;-)
> Now, if we extended the mailmap feature even further, to report the
> mappings from the rev-list code ((optional of course)), so that any
> log viewer would show the mapped information; _then_ I would consider
> the command-line and environment variables as mandatory. Since, then
> you might want the feature off by default, and only use the mappings
> when you need to figure out a breakage, thus need a quick way to
> enable it.
Now you mention it, it might be wonderful if "git log --author" honored
the mailmap file, but I do not think command line nor environment do not
have much to do with it.
In any case, it is an independent issue from how mailmap maching and
rewriting should work, which was the main point fo your series.
> So, unless anyone raises their hand that they need
> command-line/environment ways of setting the mailmap file used, I'll
> leave it as is for now. Ok?
My point was that you should drop the second always-NULL parameter if the
plan is not to have any command line filename. And I agree with your
reasoning that a command line filename is not useful, so...
^ permalink raw reply
* Re: [PATCH 1/2] t3412: clean up GIT_EDITOR usage
From: Thomas Rast @ 2009-02-02 8:39 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0902012322490.3586@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
Johannes Schindelin wrote:
> On Fri, 30 Jan 2009, Thomas Rast wrote:
> > +# we always run the interactive rebases unchanged, so just disable the editor
> > +GIT_EDITOR=:
> > +export GIT_EDITOR
> > +
>
> According to my analysis, this is unneeded. Just leave GIT_EDITOR alone
> in the whole test.
You're right, test-lib.sh sets GIT_EDITOR= and EDITOR=:, so the above
is unneeded (but harmless).
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Support various HTTP authentication methods
From: Moriyoshi Koizumi @ 2009-02-02 8:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1233556274-1354-1-git-send-email-gitster@pobox.com>
On Mon, Feb 2, 2009 at 3:31 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Applying style fixes to the existing code is very much appreciated, *but*
> please make such a clean-up patch a separate one. A two-patch series
> whose [1/2] is such a pure clean-up without any feature change, with [2/2]
> that adds code to the cleaned-up state would be much less distracting for
> people who nitpick your changes.
Okay, I'll try to do so next time.
>> @@ -153,11 +159,69 @@ static int http_options(const char *var, const char *value, void *cb)
>> return git_config_string(&curl_http_proxy, var, value);
>> return 0;
>> }
>> +#if LIBCURL_VERSION_NUM >= 0x070a06
>> + if (!strcmp("http.auth", var)) {
>> + if (curl_http_auth == NULL)
>> + return git_config_string(&curl_http_auth, var, value);
>> + return 0;
>> + }
>> +#endif
>> +#if LIBCURL_VERSION_NUM >= 0x070a07
>> + if (!strcmp("http.proxy_auth", var)) {
>> + if (curl_http_proxy_auth == NULL)
>> + return git_config_string(&curl_http_proxy_auth, var, value);
>> + return 0;
>> + }
>> +#endif
>
> If you follow config.c::git_config() you will notice that we read from
> /etc/gitconfig, $HOME/.gitconfig and then finally $GIT_DIR/config. By
> implementing "if we already have read curl_http_auth already, we will
> ignore the later setting" like above code does, you break the general
> expectation that system-wide defaults is overridable by $HOME/.gitconfig
> and that is in turn overridable by per-repository $GIT_DIR/config.
But aren't the globals supposed to be set just here? I guessed you
assume that these are set elsewhere and then it prevents the values
provided later from being applied.
> The preferred order would be:
>
> - Use the value obtained from command line parameters, if any;
>
> - Otherwise, if an environment variable is there, use it;
>
> - Otherwise, the value obtained from git_config(), with "later one wins"
> rule.
>
> I think you are not adding any command line option, so favoring
> environment and then using configuration is fine, but the configuration
> parser must follow the usual "later one wins" rule to avoid dissapointing
> the users.
I just followed the way other options behave. I was just not sure how
I was supposed to deal with them.
>> +#if LIBCURL_VERSION_NUM >= 0x070a06
>> +static long get_curl_auth_bitmask(const char* auth_method)
>
> In git codebase, asterisk that means "a pointer" sticks to the variable
> name not to type name; "const char *auth_method" (I see this file is
> already infested with such style violations, but if you are doing a
> separate clean-up patch it would be appreciated to clean them up).
>
I'm not willing to do it this time ;-)
>> +{
>> + char buf[4096];
>
> Do you need that much space?
I think as long as we use fixed-size buffers, I should get them enough
sized. If this is not preferrable, then it'd be better off using
heap-allocated buffers.
>> + const unsigned char *p = (const unsigned char *)auth_method;
>> + long mask = CURLAUTH_NONE;
>> +
>> + strlcpy(buf, auth_method, sizeof(buf));
>
> A tab is 8-char wide.
Sorry about this. I actually was careful but I just forgot to turn off
the tab expansion for the second time.
> What happens when auth_method is longer than 4kB?
>
>> +
>> + for (;;) {
>> + char *q = buf;
>> + while (*p && isspace(*p))
>> + ++p;
>
> If there is no particular reason to choose one over the other, please use
> postincrement, p++, as other existing parts of the codebase.
>
> I'll try to demonstrate what (I think) this patch should look like as a
> pair of follow-up messages to this one, but I am not sure about my rewrite
> of get_curl_auth_bitmask(). Please consider it as an easter-egg bughunt
> ;-)
I anyway appreciate this kind of knit-picking as I'd do so to newbies.
Thanks very much for the advice.
Regards,
Moriyoshi
^ permalink raw reply
* Re: [RFC PATCH] add -p: prompt for single characters
From: Thomas Rast @ 2009-02-02 8:34 UTC (permalink / raw)
To: Suraj Kurapati; +Cc: git, Jeff King, Junio C Hamano
In-Reply-To: <cfbcd2f00902011931h48ef51a4n9badbed9051879ca@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 497 bytes --]
Suraj Kurapati wrote:
> On Sun, Feb 1, 2009 at 12:35 PM, Thomas Rast <trast@student.ethz.ch> wrote:
> > http://thread.gmane.org/gmane.comp.version-control.git/100146
> >
> > I can't find the v4 promised there, so I assume Suraj dropped it.
>
> Yes, I lost the motivation to develop the patch any further. Sorry.
Ok.
I see Junio has already merged wp/add-patch-find, so I'll rebuild on
top of that and see what needs to be changed.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] Switch receive.denyCurrentBranch to "refuse"
From: Junio C Hamano @ 2009-02-02 8:32 UTC (permalink / raw)
To: Sam Vilain; +Cc: Nanako Shiraishi, Johannes Schindelin, Jay Soffian, git
In-Reply-To: <1233558035.20131.72.camel@maia.lan>
Sam Vilain <sam@vilain.net> writes:
> The other affects
> a small number of users who are doing something which is labeled in many
> places as a bad thing to want to do.
Sorry, but I do not agree with this.
What is bad is to push into a repository that is used for editing. That
is labelled as a bad thing to want to do.
It is often the easiest to push and then run "reset --hard" (perhaps from
the post-update script) to propagate your change to a repository that is
not usually used for editing. E.g. that has always been the way I update
my private repository at k.org that I use for final testing before pushing
out the results that I built and tested on my personal machine. People
who have live web pages served from a checkout do that, too. It is not a
bad thing to do at all, and you can find many instructions with google
without spending a lot of time to do exactly that.
http://kerneltrap.org/mailarchive/git/2008/7/1/2315924
http://utsl.gen.nz/git/post-update
http://groups.google.com/group/sl-ugr/browse_thread/thread/04e4c4bd6ce174af
^ permalink raw reply
* Re: [PATCH v2 1/4] Add log.mailmap as configurational option for mailmap location
From: Marius Storm-Olsen @ 2009-02-02 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr62hl1a3.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]
Junio C Hamano said the following on 02.02.2009 08:56:
> Marius Storm-Olsen <marius@trolltech.com> writes:
>> Junio C Hamano said the following on 02.02.2009 04:01:
>>> Should it always be a wholesale override, or should it also
>>> support augmenting the repository version with a private copy?
>> Sure, I can rewrite it to be augmenting, rather than overriding.
>> I assume that the normal .mailmap file should be parsed first,
>> then the log.mailmap one?
>
> Augmenting one would behave that way. I was more wondering if
> people would want to be able to choose either, perhaps from the
> command line option or something.
Oh, I see. *ponder* maybe, though you could say that about any option
in the .git/config file, right?
>> Sure, but I left it in to allow "old-style" usage. Just in case
>> the were use-cases for not using the log.mailmap one. I can nuke
>> the arguments if you don't want them anymore.
>
> What I think would be sensible, if we really want to make this
> feature flexible, would be to introduce a command line option (and
> perhaps environment variable) that takes the usual precidence (the
> command line that specifies the mailmap file, then the environment
> and then finally the log.mailmap config variable). And if we go
> that route, that "usuall NULL" parameter would be where the callers
> pass the filename they got from their command line.
>
> But if you feel it is overengineering, I would not disagree. In
> such a case, however, I do not think there is a reason for one
> particular caller to pass some custom value there, just to be
> inconsistent from others.
I'm not sure of the use case of the command line option. In which case
would you want to only use the mailmap for that one command? It
doesn't normally affect your git commands, so it doesn't hurt to just
set the log.mailmap option. The environment use case would be just
like setting it in your ~/.gitconfig, other than you can have a
different one for each console, I guess.
Now, if we extended the mailmap feature even further, to report the
mappings from the rev-list code ((optional of course)), so that any
log viewer would show the mapped information; _then_ I would consider
the command-line and environment variables as mandatory. Since, then
you might want the feature off by default, and only use the mappings
when you need to figure out a breakage, thus need a quick way to
enable it.
So, unless anyone raises their hand that they need
command-line/environment ways of setting the mailmap file used, I'll
leave it as is for now. Ok?
--
.marius [@trolltech.com]
'if you know what you're doing, it's not research'
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/4] Extend mailmap functionality
From: Marius Storm-Olsen @ 2009-02-02 8:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpri1o801.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2183 bytes --]
Junio C Hamano said the following on 02.02.2009 04:03:
>> This extended mapping is necessary when a company wants to have
>> their repositories open to the public, but needs to protect the
>> identities of the developers. It enables you to only show nicks
>> and standardized emails, like 'Dev123 <bugs@company.xx>' in the
>> public repo, but by using an private mailmap file, map the name
>> back to 'John Doe <john.doe@company.xx>' inside the company.
>
> I do not find the "necessary" argument very convincing nor I find
> the particular use case sane. You may want to do things that way,
> but I do not know if it is the best way to go about it.
Well, this is the use-case for my company. We have open-source repos,
which are the exact same repos which the company's developers work on,
not a modified mirror repo.
However, laws in some countries requires that employees information be
kept away from the public, should they so wish. So, for our developers
to work on the exact same repo as the open-source community, we need a
way to map both Names and Emails back to the original author, inside
the company without using a different repo.
Also, the company commit policy might be such that the email on the
commit is always the companys <bugs@company.xx>. This might be so that
if someone finds a bug to your commit, they send the bug report to the
companys bug-tracker instead of the individual email address.
However, that breaks the old mailmap system, since it requires unique
email addresses to map to a name.
> The new mapping however brings in more flexibility, and there may
> be other use cases where people benefit from that flexibility. I
> am slightly in favor than neutral to this new feature.
You could use this feature in git.git itself, where for example
Junio C Hamano <gitster@pobox.com>
Junio C Hamano <gitster@pobox.com> <junio@twinsun.com>
(or any of the others in the .mailmap file with X number of different
email addresses), to ensure that you are always associated with one
specific email address.
--
.marius [@trolltech.com]
'if you know what you're doing, it's not research'
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* What's in git.git (Feb 2009, #01; Sun, 01)
From: Junio C Hamano @ 2009-02-02 8:05 UTC (permalink / raw)
To: git
There are yet more fixes that have been cooking in next and then master
that have been merged to 'maint' in preparation for the next 1.6.1.X
maintenance release.
On the 'master' front, I think we are ready to plan for 1.6.2 release.
Tonight's "What's cooking" should be a pretty good guide for estimating
what will be in -rc0, in addition to what we already have in 'master'.
* The 'maint' branch has these fixes since the last announcement.
Björn Steinbrink (1):
Rename detection: Avoid repeated filespec population
Jeff King (1):
avoid 31-bit truncation in write_loose_object
Junio C Hamano (3):
ls-tree: add --full-tree option
Teach format-patch to handle output directory relative to cwd
GIT 1.6.1.2
Marcel M. Cary (1):
git-sh-setup: Fix scripts whose PWD is a symlink to a work-dir on OS X
Markus Heidelberg (2):
git-commit: color status output when color.ui is set
git-status -v: color diff output when color.ui is set
Nanako Shiraishi (1):
Document git-ls-tree --full-tree
Nguyễn Thái Ngọc Duy (2):
grep: support --no-ext-grep to test builtin grep
grep: grep cache entries if they are "assume unchanged"
Nicolas Pitre (1):
objects to be pruned immediately don't have to be loosened
René Scharfe (1):
merge: fix out-of-bounds memory access
* The 'master' branch has these since the last announcement
in addition to the above.
Anders Melchiorsen (2):
Documentation: more git push examples
Documentation: rework src/dst description in git push
David Aguilar (1):
contrib/difftool: Don't repeat merge tool candidates
Giuseppe Bilotta (3):
gitweb: make static files accessible with PATH_INFO
gitweb: webserver config for PATH_INFO
gitweb: align comments to code
Jake Goulding (3):
Make opt_parse_with_commit() non-static
Make has_commit() non-static
git-tag: Add --contains option
Jakub Narebski (1):
gitweb: Update README that gitweb works better with PATH_INFO
Jeff King (5):
diff: refactor tempfile cleanup handling
chain kill signals for cleanup functions
refactor signal handling for cleanup functions
pager: do wait_for_pager on signal death
t0005: use SIGTERM for sigchain test
Johannes Gilger (1):
mergetool: Don't repeat merge tool candidates
Johannes Schindelin (8):
Fix submodule squashing into unrelated commit
t3404 & t3411: undo copy&paste
lib-rebase.sh: Document what set_fake_editor() does
test-lib.sh: introduce test_commit() and test_merge() helpers
Simplify t3410
Simplify t3411
Simplify t3412
Fix 'git diff --no-index' with a non-existing symlink target
Johannes Sixt (1):
Windows: Fix signal numbers
Junio C Hamano (6):
Documentation: simplify refspec format description
diff.c: output correct index lines for a split diff
revision traversal: allow UNINTERESTING objects to be missing
rebase -i squashes submodule changes into unrelated commit
builtin-apply.c: do not set bogus mode in check_preimage() for deleted
path
Update draft release notes to 1.6.2
Kirill Smelkov (5):
mailinfo: correctly handle multiline 'Subject:' header
mailinfo: 'From:' header should be unfold as well
mailinfo: add explicit test for mails like '<a.u.thor@example.com> (A U
Thor)'
mailinfo: tests for RFC2047 examples
mailinfo: cleanup extra spaces for complex 'From:'
Markus Heidelberg (1):
contrib/difftool: add support for Kompare
Michele Ballabio (1):
git-shortlog.txt: fix example about .mailmap
Stefan Karpinski (2):
git-cvsserver: handle CVS 'noop' command.
git-cvsserver: run post-update hook *after* update.
Steffen Prohaska (6):
Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX)
git_extract_argv0_path(): Move check for valid argv0 from caller to
callee
Add calls to git_extract_argv0_path() in programs that call git_config_*
Modify setup_path() to only add git_exec_path() to PATH
Compute prefix at runtime if RUNTIME_PREFIX is set
Windows: Revert to default paths and convert them by RUNTIME_PREFIX
Steve Haslam (1):
Refactor git_set_argv0_path() to git_extract_argv0_path()
Thomas Rast (2):
t3412: clean up GIT_EDITOR usage
t3412: use log|name-rev instead of log --graph
^ permalink raw reply
* What's cooking in git.git (Feb 2009, #01; Sun, 01)
From: Junio C Hamano @ 2009-02-02 7:59 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* gt/utf8-width (Fri Jan 30 04:41:29 2009 -0500) 2 commits
- builtin-blame.c: Use utf8_strwidth for author's names
- utf8: add utf8_strwidth()
I am not sure if utf8_strwidth() behaves sensibly when fed a non-UTF8
string (a possible failure mode is utf8_width() says "no" and it returns
0, resulting in width of all zero and causing division by zero somewhere
downstream, or something silly like that), but other than that, I do not
think it would hurt, and will actively improve the current code.
* jc/refuse-push-to-current (Sat Jan 31 17:34:05 2009 -0800) 2 commits
- Set receive.denyCurrentBranch to true in a new non-bare repository
- receive-pack: explain what to do when push updates the current
branch
This prepares to finally switch the default for receive.denyCurrentBranch
to "refuse". The idea is to issue a big warning to people who push into
currently checked out branch when the configuration is unset and we
default to "warn", and explain in detail (1) why it is not likely to be
what they want to do (to help new people), (2) if it is what they want,
how to squelch that annoyingly long message, and (3) the default will be
changed to "refuse" in a future release of git. The tip commit also sets
the configuration to refuse in a newly created repository, but with a
twist. People who get the "refusal" configuration this way may be
expecting the recipe they picked up to push into a live repository,
perhaps a website, and let its post-update hook to "reset --hard" the
deployment, and we will explain that (1) it will no longer work (because
we default to "refuse" in a newly created repository), (2) how to
configure it to work again, and (3) how to squelch the annoying message.
I personally do not think anything short of an approach like this would
work without a huge fallout like we had when yanked git-foo commands from
people's $PATH in 1.6.0, but I can still be pursuaded by a better
alternative, and that is why they are not in 'next' yet. Saying "old
timers can flip a single switch just once" is not a better alternative, as
I explained already.
* jc/fsck (Fri Jan 30 02:44:13 2009 -0800) 7 commits
- fsck: revert --quick to the default and introduce --medium
- fsck: three levels of validation
- verify-pack: add --quick
- verify_pack(): allow a quicker verification for a pack with
version 2 idx
- pack-check.c: minor formatting fix to match coding style
+ fsck: check loose objects from alternate object stores by default
+ fsck: HEAD is part of refs
I haven't heard anything positive nor negative about this series. I
consider the bottom two changes are pure bugfixes and should probably be
in 1.6.2.
I think the tip two commits should be squashed (and perhaps the option
parser cleaned up as suggested on the list) if we were to take the
remainder.
* rc/http-push (Sat Jan 31 07:51:55 2009 +0800) 1 commit
+ http-push: refactor request url creation
Looked fine for 1.6.2.
* jk/head-symref (Thu Jan 29 03:33:02 2009 -0500) 2 commits
+ symbolic ref: refuse non-ref targets in HEAD
+ validate_headref: tighten ref-matching to just branches
Looked fine for 1.6.2.
* kb/checkout-optim (Sun Feb 1 21:23:39 2009 +0100) 7 commits
- unpack-trees.c: introduce schedule_dir_for_removal()
- lstat_cache(): print a warning if doing ping-pong between cache
types
- combine-diff.c: remove a call to fstat() inside show_patch_diff()
- write_entry(): use fstat() instead of lstat() when file is open
- cleanup of write_entry() in entry.c
- remove some memcpy() and strchr() calls inside
create_directories()
- symlinks.c: small cleanup and optimisation
Love to have in 1.6.2
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
This is a feature waiting for a user. I do not need it in 1.6.2
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
* cc/replace (Mon Feb 2 06:13:06 2009 +0100) 11 commits
- builtin-replace: use "usage_msg_opt" to give better error messages
- parse-options: add new function "usage_msg_opt"
- builtin-replace: teach "git replace" to actually replace
- Add new "git replace" command
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
I think the code is much cleaner than the first round, but I am not
convinced it is doing the right thing in the connectivity traverser.
I'd like to keep this out of 1.6.2.
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 6 commits
- archive.c: add support for --submodules[=(all|checkedout)]
- tree.c: allow read_tree_recursive() to traverse gitlink entries
+ Revert round #1 of the series
+ builtin-ls-tree: enable traversal of submodules
+ archive.c: enable traversal of submodules
+ tree.c: add support for traversal of submodules
Sorry, but what's the status of this one? I am not particularly
interested in this new feature myself, so unless I hear otherwise from
people, I'd like to keep this out of 1.6.2. That would have the added
benefit of being able to discard the first four that is already in 'next'
to get a fresh start post 1.6.2 ;-)
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
Design discussion between Jakub and Sebastien seems to have stalled.
----------------------------------------------------------------
[Reverted]
* mh/unify-color (Fri Jan 23 01:25:23 2009 -0800) 3 commits
? Revert previous two commits
? move the color variables to color.c
? handle color.ui at a central place
This broke git-format-patch badly.
----------------------------------------------------------------
[Actively cooking]
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
+ In add --patch, Handle K,k,J,j slightly more gracefully.
+ Add / command in add --patch
+ git-add -i/-p: Change prompt separater from slash to comma
I think this is Ok to have in 1.6.2
* cb/mergetool (Fri Jan 30 23:20:11 2009 +0000) 3 commits
- mergetool: fix running mergetool in sub-directories
- mergetool: Add a test for running mergetool in a sub-directory
+ mergetool: respect autocrlf by using checkout-index
The fix to its subdirectory behaviour looked somewhat iffy and may have a
potential for cleaning up. But we should have it in 1.6.2.
* js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits
- valgrind: ignore ldso errors
- Add valgrind support in test scripts
Dscho and Peff had further exchanges on the list; I am sort of waiting for
the conclusion before picking any intermediate version up.
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
It would be nice to hear a real world success story using the notes
mechanism; Dscho says he also wants to make sure the current choice
of the structure scales well before casting it in stone.
----------------------------------------------------------------
[Graduated to "master"]
* jc/maint-1.6.0-split-diff-metainfo (Mon Jan 26 00:08:24 2009 -0800) 1 commit
+ diff.c: output correct index lines for a split diff
This is slated for maintenance series 1.6.0.X.
* jc/maint-split-diff-metainfo (Tue Jan 27 01:08:02 2009 -0800) 2 commits
+ Merge branch 'jc/maint-1.6.0-split-diff-metainfo' into jc/maint-
split-diff-metainfo
+ diff.c: output correct index lines for a split diff
Early conflict resolution branch for the above to carry it to 1.6.1.X
series.
* js/maint-rebase-i-submodule (Tue Jan 27 12:42:31 2009 +0100) 2 commits
+ Fix submodule squashing into unrelated commit
+ rebase -i squashes submodule changes into unrelated commit
* jg/tag-contains (Mon Jan 26 09:13:25 2009 -0500) 3 commits
+ git-tag: Add --contains option
+ Make has_commit() non-static
+ Make opt_parse_with_commit() non-static
* jc/maint-allow-uninteresting-missing (Tue Jan 27 23:19:30 2009 -0800) 1 commit
+ revision traversal: allow UNINTERESTING objects to be missing
This is a small follow-up to the fix to send-pack in 1.6.1; meant to go in
1.6.1.X maintenance series and newer.
* am/maint-push-doc (Mon Jan 26 00:45:33 2009 +0100) 3 commits
+ Documentation: rework src/dst description in git push
+ Documentation: more git push examples
+ Documentation: simplify refspec format description
* jc/maint-apply-fix (Sun Jan 25 23:41:26 2009 -0800) 1 commit
+ builtin-apply.c: do not set bogus mode in check_preimage() for
deleted path
* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 4 commits
+ mailinfo: tests for RFC2047 examples
+ mailinfo: add explicit test for mails like '<a.u.thor@example.com>
(A U Thor)'
+ mailinfo: 'From:' header should be unfold as well
+ mailinfo: correctly handle multiline 'Subject:' header
Graduated with a follow-up patch from the original author.
* jg/mergetool (Sat Jan 24 00:12:45 2009 +0100) 1 commit
+ mergetool: Don't repeat merge tool candidates
* jk/signal-cleanup (Thu Jan 22 01:03:28 2009 -0500) 5 commits
+ pager: do wait_for_pager on signal death
+ refactor signal handling for cleanup functions
+ chain kill signals for cleanup functions
+ diff: refactor tempfile cleanup handling
+ Windows: Fix signal numbers
* sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 7 commits
+ Windows: Revert to default paths and convert them by
RUNTIME_PREFIX
+ Compute prefix at runtime if RUNTIME_PREFIX is set
+ Modify setup_path() to only add git_exec_path() to PATH
+ Add calls to git_extract_argv0_path() in programs that call
git_config_*
+ git_extract_argv0_path(): Move check for valid argv0 from caller
to callee
+ Refactor git_set_argv0_path() to git_extract_argv0_path()
+ Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX)
There was a report that this breaks with older GNU Make.
----------------------------------------------------------------
[Will merge to "master" soon]
* jc/maint-add-u-remove-conflicted (Wed Jan 28 14:24:53 2009 -0800) 1 commit
- add -u: do not fail to resolve a path as deleted
This has been updated from the posted version with a correction. We
should have it in 1.6.2
* jk/maint-cleanup-after-exec-failure (Wed Jan 28 02:38:14 2009 -0500) 4 commits
+ git: use run_command() to execute dashed externals
+ run_command(): help callers distinguish errors
+ run_command(): handle missing command errors more gracefully
+ git: s/run_command/run_builtin/
Looked good for 1.6.2.
* ns/am-slacker (Sat Jan 24 10:18:02 2009 +0900) 2 commits
+ git-am: Add --ignore-date option
+ am: Add --committer-date-is-author-date option
It is a (probably) useful new feature with a sort-of cute explanation.
I am not sure if it needs further work (such as hooking it to rebase),
but other than that, I think it is Ok to have in 1.6.2.
----------------------------------------------------------------
[On Hold]
* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
- git commit: pathspec without -i/-o implies -i semantics during a
merge
- builtin-commit: shorten eye-sore overlong lines
- Add "partial commit" tests during a conflicted merge
This is only meant as a weatherballoon to help facilitate discussion.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
. revision --simplify-merges: incremental simplification
. revision --simplify-merges: prepare for incremental simplification
^ permalink raw reply
* Re: [PATCH v2 1/4] Add log.mailmap as configurational option for mailmap location
From: Junio C Hamano @ 2009-02-02 7:56 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: git
In-Reply-To: <4986A539.3080606@trolltech.com>
Marius Storm-Olsen <marius@trolltech.com> writes:
> Junio C Hamano said the following on 02.02.2009 04:01:
>> Marius Storm-Olsen <marius@trolltech.com> writes:
>>> This allows us to override a repo mailmap file, or to use
>>> mailmap files elsewhere than the repository root.
>>
>> I think the new feature is not so well conceived.
>>
>> Should it always be a wholesale override, or should it also support
>> augmenting the repository version with a private copy?
>
> Sure, I can rewrite it to be augmenting, rather than overriding.
> I assume that the normal .mailmap file should be parsed first, then
> the log.mailmap one?
Augmenting one would behave that way. I was more wondering if people
would want to be able to choose either, perhaps from the command line
option or something.
> Sure, but I left it in to allow "old-style" usage. Just in case the
> were use-cases for not using the log.mailmap one. I can nuke the
> arguments if you don't want them anymore.
What I think would be sensible, if we really want to make this feature
flexible, would be to introduce a command line option (and perhaps
environment variable) that takes the usual precidence (the command line
that specifies the mailmap file, then the environment and then finally the
log.mailmap config variable). And if we go that route, that "usuall NULL"
parameter would be where the callers pass the filename they got from their
command line.
But if you feel it is overengineering, I would not disagree. In such a
case, however, I do not think there is a reason for one particular caller
to pass some custom value there, just to be inconsistent from others.
^ permalink raw reply
* Re: [PATCH v2 2/4] Add find_insert_index, insert_at_index and clear_func functions to string_list
From: Marius Storm-Olsen @ 2009-02-02 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viqnto7zo.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
Junio C Hamano said the following on 02.02.2009 04:03:
> Marius Storm-Olsen <marius@trolltech.com> writes:
>
>> string_list_find_insert_index() and string_list_insert_at_index()
>> enables you to see if an item is in the string_list, and to
>> insert at the appropriate index in the list, if not there. This
>> is usefull if you need to manipulate an existing item, if
>> present, and insert a new item if not.
>>
>> Future mailmap code will use this construct to enable complex
>> (old_name, old_email) -> (new_name, new_email) lookups.
>>
>> The string_list_clear_func() allows to call a custom cleanup
>> function on each item in a string_list, which is useful is the
>> util member points to a complex structure.
>
> What's with these overlong lines? You do not have them in your
> other patches.
Sorry, that was my editor which wrapped them visibly at column 70, and
I forgot to insert manual line-breaks before saving.
I'll correct it for the next version.
--
.marius [@trolltech.com]
'if you know what you're doing, it's not research'
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] git-add -i/-p: Change prompt separater from slash to comma
From: Junio C Hamano @ 2009-02-02 7:49 UTC (permalink / raw)
To: William Pursell; +Cc: git
In-Reply-To: <4986A334.6070903@gmail.com>
William Pursell <bill.pursell@gmail.com> writes:
> Not a major complaint, but how about localizing the occurence
> of the separator. Something like this:
I think that is sensible. I've already queued the resurrected series to
'next' and am deep in the process of tonight's pushout preparation (this
time I've even written What's cooking), so I'd rather not rewind what I
have already and redo it. Could you send an incremental update on top of
what's in next (more specifically ace30ba (In add --patch, Handle K,k,J,j
slightly more gracefully., 2008-11-27) please?
^ permalink raw reply
* Re: [PATCH v2 1/4] Add log.mailmap as configurational option for mailmap location
From: Marius Storm-Olsen @ 2009-02-02 7:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwsc9o82r.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1331 bytes --]
Junio C Hamano said the following on 02.02.2009 04:01:
> Marius Storm-Olsen <marius@trolltech.com> writes:
>> This allows us to override a repo mailmap file, or to use
>> mailmap files elsewhere than the repository root.
>
> I think the new feature is not so well conceived.
>
> Should it always be a wholesale override, or should it also support
> augmenting the repository version with a private copy?
Sure, I can rewrite it to be augmenting, rather than overriding.
I assume that the normal .mailmap file should be parsed first, then
the log.mailmap one?
>> diff --git a/builtin-blame.c b/builtin-blame.c
>> index aae14ef..4b63775 100644
>> --- a/builtin-blame.c
>> +++ b/builtin-blame.c
>> @@ -2394,7 +2394,7 @@ parse_done:
>> die("reading graft file %s failed: %s",
>> revs_file, strerror(errno));
>>
>> - read_mailmap(&mailmap, ".mailmap", NULL);
>> + read_mailmap(&mailmap, NULL, NULL);
>
> Your callers always seem to pass NULL for the second argument. Doesn't it
> make a lot more sense to get rid of it?
Sure, but I left it in to allow "old-style" usage. Just in case the
were use-cases for not using the log.mailmap one. I can nuke the
arguments if you don't want them anymore.
--
.marius [@trolltech.com]
'if you know what you're doing, it's not research'
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 187 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] git-add -i/-p: Change prompt separater from slash to comma
From: William Pursell @ 2009-02-02 7:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1233546159-30347-2-git-send-email-gitster@pobox.com>
Junio C Hamano wrote:
> From: William Pursell <bill.pursell@gmail.com>
>
> Otherwise the find command '/' soon to be introduced will be hard to see.
>
> Signed-off-by: William Pursell <bill.pursell@gmail.com>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> git-add--interactive.perl | 14 +++++++-------
> 1 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index ca60356..ca50363 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -929,22 +929,22 @@ sub patch_update_file {
> for ($i = 0; $i < $ix; $i++) {
> if (!defined $hunk[$i]{USE}) {
> $prev = 1;
> - $other .= '/k';
> + $other .= ',k';
> last;
> }
> }
> if ($ix) {
> - $other .= '/K';
> + $other .= ',K';
> }
> for ($i = $ix + 1; $i < $num; $i++) {
> if (!defined $hunk[$i]{USE}) {
> $next = 1;
> - $other .= '/j';
> + $other .= ',j';
> last;
> }
> }
> if ($ix < $num - 1) {
> - $other .= '/J';
> + $other .= ',J';
> }
> if ($num > 1) {
> $other .= '/g';
> @@ -958,13 +958,13 @@ sub patch_update_file {
> last if (!$undecided);
>
> if (hunk_splittable($hunk[$ix]{TEXT})) {
> - $other .= '/s';
> + $other .= ',s';
> }
> - $other .= '/e';
> + $other .= ',e';
> for (@{$hunk[$ix]{DISPLAY}}) {
> print;
> }
> - print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
> + print colored $prompt_color, "Stage this hunk [y,n,a,d$other,?]? ";
> my $line = <STDIN>;
> if ($line) {
> if ($line =~ /^y/i) {
Not a major complaint, but how about localizing the occurence
of the separator. Something like this:
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index ca60356..bd8326d 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -921,7 +921,7 @@ sub patch_update_file {
while (1) {
my ($prev, $next, $other, $undecided, $i);
- $other = '';
+ $other = 'ynad';
if ($num <= $ix) {
$ix = 0;
@@ -929,25 +929,25 @@ sub patch_update_file {
for ($i = 0; $i < $ix; $i++) {
if (!defined $hunk[$i]{USE}) {
$prev = 1;
- $other .= '/k';
+ $other .= 'k';
last;
}
}
if ($ix) {
- $other .= '/K';
+ $other .= 'K';
}
for ($i = $ix + 1; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
$next = 1;
- $other .= '/j';
+ $other .= 'j';
last;
}
}
if ($ix < $num - 1) {
- $other .= '/J';
+ $other .= 'J';
}
if ($num > 1) {
- $other .= '/g';
+ $other .= 'g';
}
for ($i = 0; $i < $num; $i++) {
if (!defined $hunk[$i]{USE}) {
@@ -958,13 +958,14 @@ sub patch_update_file {
last if (!$undecided);
if (hunk_splittable($hunk[$ix]{TEXT})) {
- $other .= '/s';
+ $other .= 's';
}
- $other .= '/e';
+ $other .= 'e';
for (@{$hunk[$ix]{DISPLAY}}) {
print;
}
- print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
+ print colored $prompt_color, "Stage this hunk [" .
+ join(',', split("", $other)) . "]? ";
my $line = <STDIN>;
if ($line) {
if ($line =~ /^y/i) {
--
William Pursell
^ permalink raw reply related
* Re: Git setup for kernel in-house development + mainstream submissions?
From: Johannes Gilger @ 2009-02-02 7:26 UTC (permalink / raw)
To: git
In-Reply-To: <49861363.1000104@aster.pl>
On 2009-02-01, PaV <pav@aster.pl> wrote:
> I would like to kindly ask for suggestions how to setup and use git in a
> company that performs in-house kernel development (drivers mostly) for
> its own devices and would like to occasionaly submit patches for mainstream.
> [...]
> So the proposed setup might be:
> (1) - in-house devel could be done on separate branches for each driver
Do you really want to have separate drivers in the same git repository?
Do these drivers share so much code and depend on each other that this
would be necessary? If not I'd suggest you think about separate git
projects for each driver, unless there is a compelling reason against
it.
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ permalink raw reply
* Re: Linus and whitespace
From: Johannes Gilger @ 2009-02-02 7:22 UTC (permalink / raw)
To: git
In-Reply-To: <87fxix3hub.fsf@jidanni.org>
On 2009-02-01, jidanni@jidanni.org <jidanni@jidanni.org> wrote:
> Gentlemen, I couldn't help but notice a certain Linus B. Torvalds is
> producing mail with trailing whitespace.
Boy, do you have too much free time on your hands...
Greetings,
Jojo
--
Johannes Gilger <heipei@hackvalue.de>
http://hackvalue.de/heipei/
GPG-Key: 0x42F6DE81
GPG-Fingerprint: BB49 F967 775E BB52 3A81 882C 58EE B178 42F6 DE81
^ 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