* Re: [PATCH 0/2] jn/gitweb-blame fixes
From: Stephen Boyd @ 2009-11-23 4:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200911210132.44649.jnareb@gmail.com>
Jakub Narebski wrote:
> I have tested gitweb with both of your patches applied, serving gitweb
> as CGI script using Apache 2.0.54 on Linux, and viewing from separate
> computer on MS Windows XP, with the following results:
>
> * For the following browsers blame_incremental view on gitweb/gitweb.perl
> file produces correct output, but for progress info which instead of
> ( 1%) -> ( 29%) -> (100%) looks more like ( 1%) -> (29%) -> (100%)
This is due to an off-by-one error in the while loop. This should fix
it. I'll probably squash this into patch 2 and resend.
--->8----
diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
index 30597dd..9214497 100644
--- a/gitweb/gitweb.js
+++ b/gitweb/gitweb.js
@@ -43,7 +43,7 @@ function padLeftStr(input, width, str) {
var prefix = '';
width -= input.toString().length;
- while (width > 1) {
+ while (width > 0) {
prefix += str;
width--;
}
^ permalink raw reply related
* [PATCH] bisect: simplify calling visualizer using '--bisect' option
From: Christian Couder @ 2009-11-23 4:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Linus Torvalds
In commit ad3f9a7 (Add '--bisect' revision machinery argument) the
'--bisect' option was added to easily pass bisection refs to
commands using the revision machinery.
So it is now shorter and safer to use the new '--bisect' revision
machinery option, than to compute the refs that we must pass.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
This patch was previously sent in an RFC series aimed at
using '--bisect-refs' instead of '--bisect' as the revision
machinery bisect option.
diff --git a/git-bisect.sh b/git-bisect.sh
index 8b3c585..a5ea843 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -300,8 +300,7 @@ bisect_visualize() {
esac
fi
- not=$(git for-each-ref --format='%(refname)' "refs/bisect/good-*")
- eval '"$@"' refs/bisect/bad --not $not -- $(cat "$GIT_DIR/BISECT_NAMES")
+ eval '"$@"' --bisect -- $(cat "$GIT_DIR/BISECT_NAMES")
}
bisect_reset() {
--
1.6.5.1.gaf97d
^ permalink raw reply related
* Re: Android needs repo, Chrome needs gclient. Neither work. What does that say about git?
From: Adrian May @ 2009-11-23 4:11 UTC (permalink / raw)
To: git, chromium-discuss
In-Reply-To: <alpine.DEB.1.00.0911201229080.4985@pacific.mpi-cbg.de>
>> Git is just plain wrong, because you can't split or merge repositories
>> or pull subtrees of them.
>
> You are plain wrong, because that is possible. Did you maybe forget to do
> your homework before coming here and shouting around as if you were right?
So it is. Fair enough, I stand corrected. That was my single biggest
gripe about git so it's nice to know it's there.
> To the contrary, these "bolt-on scripts" are superior to other solutions,
> because they give the savvy user freedom to do _anything_ a program can
> do.
> Your complaing have the same sense as complaining that gcc does not
> include functionality of Makefile, because you just can't manage
> larger projects without it (or equivalent).
Well, these scripts, whatever git is written in and pretty much
everything else in sight is a Turing machine, so anything could, in
theory, do anything. But nevertheless, I think everybody agrees that
certain functions belong in certain places, even if they disagree
about where. I'd wager that 'make' belongs outside of gcc because it
also drives other compilers, things like yacc, post-build steps, etc.
OTOH I think producing browse info is a long-standing ommission from
gcc that should never have been done externally in things like ctags
and cscope, because the compiler has to do 90% of the work required
anyway and because it's the compiler's opinion that counts.
As for gclient and repo, without pretending to be an expert on what
they actually do, I'm getting a strong gut feeling that if what I'm
trying to do is pull or push code, then that's about as close as you
can get to a definition of source control's central purpose. In the
days of cvs or svn, I'd expect to use the source control for that. How
come git needs help? Basically, my point is that these scripts should
be the roadmap for git itself, because those are the functions people
had to add to their git-based set-up in the real world. Also because
the implementations would probably be simpler, more robust and more
general if they were in git.
> these "bolt-on scripts" give the savvy user freedom
Actually, I think their purpose is precisely the opposite: to regiment
the ordinary developer into following their process. So having that
code under the developer's control is a weakness.
As for pulling subtrees, I guess it's sensible for the code managers
to declare which subtrees are likely to work on their own by making
them repositories. I believe you can also link lots of repositories
together to make a huge combo-repository, so I don't understand why
android doesn't use that instead of having this script to iterate over
them all. Maybe they started before the split/merge thing got written
(it would have been risky to try and get it right first time if they
couldn't rearrange them later.)
>> It doesn't have the kind of triggers you
>> need to assert change control either, and these bolt-on scripts are
>> just making life messy.
>Can you elaborate?
Well, I believe that repo is largely about asserting their code
integration process. It knows who to send your changes to for review.
But now that I think about it, I guess git does that as a first
principle. If I push to your repo, you get to review it before it goes
in and in the meantime I shouldn't be surprised that our repos look
different. So what the hell do they write those scripts for? Does
anybody around here know if they actually need them or not?
Unfortunately their list doesn't seem to be taking my post.
> If you had problems pulling the code, there are two possible sources of
> problems: the program or a PEBCAK.
Well, the repo thing eventually got fixed: it was committing suicide
at the first sign of server load. I don't know what gclient's problem
is, but my personal opinion is that the *root* problem is the
existence of the scripts at all. In both cases, there's not much room
for pebcak in the instructions.
> You obviously do not understand Open Source. If you have an itch, scratch
> it, or pay somebody to scratch it for you.
I know, but I'm actually supposed to be getting on with my real job
instead of sticking my nose into other peoples' problems like this. I
might also argue that making suggestions is some kind of contribution,
at least if the value of the suggestion outweighs the distraction of
everybody having to read it to find out whether it's any use or not,
which may or may not be the case here. Either way, I also have a
budget for distractions and it doesn't allow for getting my brain
around the git source code.
Adrian.
^ permalink raw reply
* [PATCH 0/2] http fixes
From: Tay Ray Chuan @ 2009-11-23 3:03 UTC (permalink / raw)
To: git; +Cc: Martin Storsjö, Shawn O. Pearce, Junio C Hamano
Patch 1 ("Do curl option disabling before enabling new options"):
This is a workaround for a fairly recent curl issue that affected
versions up to 7.19.4.
Patch 2 ("remote-curl.c: fix rpc_out()"):
Fixes issues that affect chunked encoding.
http-push.c | 2 +-
remote-curl.c | 19 ++++++++++++-------
2 files changed, 13 insertions(+), 8 deletions(-)
--
Cheers,
Ray Chuan
^ permalink raw reply
* [PATCH 2/2] remote-curl.c: fix rpc_out()
From: Tay Ray Chuan @ 2009-11-23 3:03 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Junio C Hamano
Use comparisons between rpc->len and rpc->pos, rather than computing
their difference. This avoids potential errors when this value is
negative and we access it.
Use an int to store the return value from packet_read_line(), instead
of a size_t.
Handle the errorneous condition where rpc->pos exceeds rpc->len by
printing a message and aborting the transfer (return 0).
Remove extraneous semicolon (';') at the end of the if statement, that
prevented code in its block from executing.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Users might experience issues when pushing with chunked encoding when
size_t avail is negative.
remote-curl.c | 17 +++++++++++------
1 files changed, 11 insertions(+), 6 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index 69eaf58..a2b8bbf 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -297,17 +297,22 @@ static size_t rpc_out(void *ptr, size_t eltsize,
{
size_t max = eltsize * nmemb;
struct rpc_state *rpc = buffer_;
- size_t avail = rpc->len - rpc->pos;
+ size_t avail = (size_t) 0;
- if (!avail) {
- avail = packet_read_line(rpc->out, rpc->buf, rpc->alloc);
- if (!avail)
+ if (rpc->pos == rpc->len) {
+ int n = packet_read_line(rpc->out, rpc->buf, rpc->alloc);
+ if (!n)
return 0;
rpc->pos = 0;
- rpc->len = avail;
+ avail = rpc->len = (size_t) n;
+ } else if (rpc->pos > rpc->len) {
+ error("bad condition!");
+ return 0;
+ } else {
+ avail = rpc->len - rpc->pos;
}
- if (max < avail);
+ if (max < avail)
avail = max;
memcpy(ptr, rpc->buf + rpc->pos, avail);
rpc->pos += avail;
--
1.6.5.3.301.gb2eb
^ permalink raw reply related
* [PATCH 1/2] Do curl option disabling before enabling new options
From: Tay Ray Chuan @ 2009-11-23 3:03 UTC (permalink / raw)
To: git; +Cc: Martin Storsjö
In-Reply-To: <Pine.LNX.4.64.0904142200130.7479@localhost.localdomain>
From: =?ISO-8859-15?Q?Martin_Storsj=F6?= <martin@martin.st>
This works around a bug in curl versions up to 7.19.4, where
disabling the CURLOPT_NOBODY option sets the internal state
incorrectly considering that CURLOPT_PUT was enabled earlier.
The bug is discussed at http://curl.haxx.se/bug/view.cgi?id=2727981
and is corrected in the latest version of curl in CVS.
This bug usually has no impact on git, but may surface if using
multi-pass authentication methods.
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Squashed in another potential trigger for this bug in remote-curl.c,
introduced in 'next'.
http-push.c | 2 +-
remote-curl.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-push.c b/http-push.c
index f10803a..295f1fb 100644
--- a/http-push.c
+++ b/http-push.c
@@ -408,10 +408,10 @@ static void start_put(struct transfer_request *request)
curl_easy_setopt(slot->curl, CURLOPT_IOCTLDATA, &request->buffer);
#endif
curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, fwrite_null);
+ curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
curl_easy_setopt(slot->curl, CURLOPT_CUSTOMREQUEST, DAV_PUT);
curl_easy_setopt(slot->curl, CURLOPT_UPLOAD, 1);
curl_easy_setopt(slot->curl, CURLOPT_PUT, 1);
- curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
curl_easy_setopt(slot->curl, CURLOPT_URL, request->url);
if (start_active_slot(slot)) {
diff --git a/remote-curl.c b/remote-curl.c
index 4f28c22..69eaf58 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -356,8 +356,8 @@ static int post_rpc(struct rpc_state *rpc)
slot = get_active_slot();
slot->results = &results;
- curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
+ curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
curl_easy_setopt(slot->curl, CURLOPT_URL, rpc->service_url);
curl_easy_setopt(slot->curl, CURLOPT_ENCODING, "");
--
1.6.4.4
^ permalink raw reply related
* [PATCH] git svn: strip leading path when making empty dirs
From: Eric Wong @ 2009-11-23 2:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Björn Steinbrink
In-Reply-To: <20091122235248.GA17418@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Argh, yeah, I messed that patch up, the test only failed because I also
> messed up this line, adding the trunk prefix there, too. Fixed patch
> below.
>
> SVN Repo layout:
>
> /
> |
> |---trunk
> | |
> ... |---foo/ # Empty
> |
> |---bar/
> |
> somefile
>
> with "git svn clone -s svn://host/path/to/repo you get:
>
> .git
> bar/
> bar/somefile
> trunk/foo # This should be just foo/
>
> i.e. the empty directories have their path relative to the repo root,
> instead of relative to the directory the git branch is associated with.
>
> Sorry for the messed up first patch.
No worries, thanks for the bug report and test case. My brain's been
completely fried lately so I was completely confused :x
Anyways this should fix it:
Also pushed out to git://git.bogomips.org/git-svn:
Eric Wong (2):
git svn: always reuse existing remotes on fetch
git svn: strip leading path when making empty dirs
From 9be30eed61993a6f2d04a1609723e64e7632a64e Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 22 Nov 2009 18:11:32 -0800
Subject: [PATCH] git svn: strip leading path when making empty dirs
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Since unhandled.log stores paths relative to the repository
root, we need to strip out leading path components if the
directories we're tracking are not the repository root.
Reported-by: Björn Steinbrink
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 3 +++
t/t9146-git-svn-empty-dirs.sh | 23 +++++++++++++++++++++++
2 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 7f7a56f..957d44e 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2752,8 +2752,11 @@ sub mkemptydirs {
}
}
close $fh;
+
+ my $strip = qr/\A\Q$self->{path}\E(?:\/|$)/;
foreach my $d (sort keys %empty_dirs) {
$d = uri_decode($d);
+ $d =~ s/$strip//;
next if -d $d;
if (-e _) {
warn "$d exists but is not a directory\n";
diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
index 5948544..70c52c1 100755
--- a/t/t9146-git-svn-empty-dirs.sh
+++ b/t/t9146-git-svn-empty-dirs.sh
@@ -82,4 +82,27 @@ test_expect_success 'git svn mkdirs -r works' '
)
'
+test_expect_success 'initialize trunk' '
+ for i in trunk trunk/a trunk/"weird file name"
+ do
+ svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
+ done
+'
+
+test_expect_success 'clone trunk' 'git svn clone -s "$svnrepo" trunk'
+
+test_expect_success 'empty directories in trunk exist' '
+ (
+ cd trunk &&
+ for i in a "weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
test_done
--
Eric Wong
^ permalink raw reply related
* [PATCH 0/2] Miscellaneous documentation updates
From: Matthew Ogilvie @ 2009-11-23 2:07 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
This is a series of documentation updates. They are independent of
each other.
These are separate from and do not duplicate the core.autocrlf patch
from a week ago.
Matthew Ogilvie (2):
cvsserver doc: database generally can not be reproduced consistently
config documentation: some configs are auto-set by git-init
Documentation/config.txt | 24 ++++++++++++++++++++++--
Documentation/git-cvsserver.txt | 19 +++++++++++++++----
2 files changed, 37 insertions(+), 6 deletions(-)
^ permalink raw reply
* [PATCH 2/2] config documentation: some configs are auto-set by git-init
From: Matthew Ogilvie @ 2009-11-23 2:07 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1258942050-11423-2-git-send-email-mmogilvi_git@miniinfo.net>
Add documentation for core.ignorecase, and mention git-init
in core.filemode and core.symlinks.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/config.txt | 24 ++++++++++++++++++++++--
1 files changed, 22 insertions(+), 2 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 78ee906..b2ee139 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -131,7 +131,11 @@ advice.*::
core.fileMode::
If false, the executable bit differences between the index and
the working copy are ignored; useful on broken filesystems like FAT.
- See linkgit:git-update-index[1]. True by default.
+ See linkgit:git-update-index[1].
++
+The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
+will probe and set core.fileMode false if appropriate when the
+repository is created.
core.ignoreCygwinFSTricks::
This option is only used by Cygwin implementation of Git. If false,
@@ -144,6 +148,18 @@ core.ignoreCygwinFSTricks::
is true, in which case ignoreCygwinFSTricks is ignored as Cygwin's
POSIX emulation is required to support core.filemode.
+core.ignorecase::
+ If true, this option enables various workarounds to enable
+ git to work better on filesystems that are not case sensitive,
+ like FAT. For example, if a directory listing finds
+ "makefile" when git expects "Makefile", git will assume
+ it is really the same file, and continue to remember it as
+ "Makefile".
++
+The default is false, except linkgit:git-clone[1] or linkgit:git-init[1]
+will probe and set core.ignorecase true if appropriate when the repository
+is created.
+
core.trustctime::
If false, the ctime differences between the index and the
working copy are ignored; useful when the inode change time
@@ -223,7 +239,11 @@ core.symlinks::
contain the link text. linkgit:git-update-index[1] and
linkgit:git-add[1] will not change the recorded type to regular
file. Useful on filesystems like FAT that do not support
- symbolic links. True by default.
+ symbolic links.
++
+The default is true, except linkgit:git-clone[1] or linkgit:git-init[1]
+will probe and set core.symlinks false if appropriate when the repository
+is created.
core.gitProxy::
A "proxy command" to execute (as 'command host port') instead
--
1.6.4.GIT
^ permalink raw reply related
* [PATCH 1/2] cvsserver doc: database generally can not be reproduced consistently
From: Matthew Ogilvie @ 2009-11-23 2:07 UTC (permalink / raw)
To: git, gitster; +Cc: Matthew Ogilvie
In-Reply-To: <1258942050-11423-1-git-send-email-mmogilvi_git@miniinfo.net>
A regenerated git-cvsserver database is at risk of having different
CVS revision numbers from an incrementally updated database. Mention
this in the the documentation, and remove an erroneous statement
to the contrary.
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net>
---
Documentation/git-cvsserver.txt | 19 +++++++++++++++----
1 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 785779e..99a7c14 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -182,10 +182,9 @@ Database Backend
----------------
'git-cvsserver' uses one database per git head (i.e. CVS module) to
-store information about the repository for faster access. The
-database doesn't contain any persistent data and can be completely
-regenerated from the git repository at any time. The database
-needs to be updated (i.e. written to) after every commit.
+store information about the repository to maintain consistent
+CVS revision numbers. The database needs to be
+updated (i.e. written to) after every commit.
If the commit is done directly by using `git` (as opposed to
using 'git-cvsserver') the update will need to happen on the
@@ -204,6 +203,18 @@ write so it might not be enough to grant the users using
'git-cvsserver' write access to the database file without granting
them write access to the directory, too.
+The database can not be reliably regenerated in a
+consistent form after the branch it is tracking has changed.
+Example: For merged branches, 'git-cvsserver' only tracks
+one branch of development, and after a 'git-merge' an
+incrementally updated database may track a different branch
+than a database regenerated from scratch, causing inconsistent
+CVS revision numbers. `git-cvsserver` has no way of knowing which
+branch it would have picked if it had been run incrementally
+pre-merge. So if you have to fully or partially (from old
+backup) regenerate the database, you should be suspicious
+of pre-existing CVS sandboxes.
+
You can configure the database backend with the following
configuration variables:
--
1.6.4.GIT
^ permalink raw reply related
* Re: [PATCH RESEND] Explicitly truncate bswap operand to uint32_t
From: Junio C Hamano @ 2009-11-23 0:16 UTC (permalink / raw)
To: Benjamin Kramer; +Cc: git, Nicolas Pitre
In-Reply-To: <4B03FC57.5000506@googlemail.com>
Benjamin Kramer <benny.kra@googlemail.com> writes:
> There are some places in git where a long is passed to htonl/ntohl. llvm
> doesn't support matching operands of different bitwidths intentionally.
> This patch fixes the build with llvm-gcc (and clang) on x86_64.
>
> Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>
> ---
> Any comments on this patch?
My vague recollection is that the response was "we do not mind it per-se,
unless it ends up in an ugly change; but we would prefer if you go fix
your compiler", but maybe I read it on lkml not here?
Also my vague recollection is that the kernel folks took that patch in the
end, so I think it is Ok for us to take this patch, too.
^ permalink raw reply
* Re: [PATCH 2/2 v2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Junio C Hamano @ 2009-11-23 0:08 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <1258928778-32419-2-git-send-email-Matthieu.Moy@imag.fr>
Looks much nicer; thanks.
Will queue.
^ permalink raw reply
* Re: [PATCH] log --format: document %w
From: Junio C Hamano @ 2009-11-23 0:06 UTC (permalink / raw)
To: René Scharfe; +Cc: Git Mailing List
In-Reply-To: <4B09CD5A.4070401@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> I think utf8_width() is too generic for that; we shouldn't teach it terminal
> control details.
I agree that the function whose purpose is to compute display width should
not be called utf8_width().
The outside caller of utf8_width() in diff.c uses it to truncate the
function name hint on the hunk header line at character boundary. The
input shouldn't have color escapes _we_ add (it might contain such
sequences from the user data, though), so I agree that we shouldn't
contaminate this function with color escapes.
> strbuf_add_wrapped_text(); ignoring display mode escape codes in there can be
> justified with its purpose.
Surely, and thanks. The patch looks good.
^ permalink raw reply
* Re: [PATCH 2/2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Junio C Hamano @ 2009-11-22 23:57 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqljhyi4oi.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> "but not the working tree itself" is not incorrect per-se, but misses the
>> point. How about...
>>
>> A merge is made by combining the changes made in "branchname" and
>> the changes made up to the latest commit in your current branch
>> since their histories forke. The work tree is overwritten by the
>> result of the merge when this combining is done cleanly, or
>> overwritten by a half-merged results when this combining results
>> in conflicts. Therefore, ...
>
> Maybe better. OTOH, it reveals another problem: Your "the work tree is
> overwritten by ..." tend to imply that the result is not commited,
> while the normal case is indeed to create a merge commit
> automatically.
Fair enough. How about changing this part
>> since their histories forke. The work tree is overwritten by the
>> result of the merge when this combining is done cleanly, or
>> overwritten by a half-merged results when this combining results
to
The work tree is overwritten by the result of the
merge when this combining is done cleanly, and the result is
committed. Otherwise it is
overwritten by a half-merged results when this combining results
?
^ permalink raw reply
* Re: [PATCH] send-email: new 'add-envelope' option
From: Junio C Hamano @ 2009-11-22 23:54 UTC (permalink / raw)
To: Felipe Contreras; +Cc: Jeff King, git
In-Reply-To: <94a0d4530911220437l5386b36ds4ef06dc66cc11bcc@mail.gmail.com>
Felipe Contreras <felipe.contreras@gmail.com> writes:
> I thought a bit more about this, and in the end what we really want is
> to add the sender envelope. The most typical case would be to use the
> 'from' address, but we should be able to override it (we do both by
> using --envelope-sender).
>
> So here are other options.
>
> a) --add-envelope: add the sender envelope, by default it would be the
> 'from' address, but could be overridden by --envelope-sender.
I do not think the latter half of this description makes much sense, as
the existing --envelope-sender=<this-address> alone already says "add this
envelope sender".
It is unfortunate that we cannot sanely have an option that takes an
optional string argument from the command line. Ideally, if we can
specify --envelope-sender without any argument, we could make it to mean
"pretend as if the 'from' address is given to this option", but that would
make the command line pasing ambiguous, so we would need an extra option
like this one. "--envelope-sender=from" might be a more intuitive way to
say this, though.
> b) --envelope-sender="" or "auto": this would require minimal changes
> but looks a bita strange.
An explicit empty string does look very strange, but I do not think a
magic word like "auto" (or "from") that cannot sanely be your envelope
sender address is a bad idea.
> Any thoughts?
It is much easier to work on the configuration front, by the way, and I
expect people who regularly interact with multiple projects to appreciate
this feature would configure their send-email once and forget about it, so
the command line clunkiness might not be such a big issue.
A user who works with more than one projects with different identity known
to each project would use $HOME/.gitconfig and send-email configuration
identity feature to set "sendemail.<identity>.from" and friends in there,
while setting sendemail.identity configuration in .git/config for each
project, so being able to say "use whatever 'from' as the envelope sender"
once in $HOME/.gitconfig would be convenient.
So I could have in $HOME/.gitconfig:
[sendemail]
; used as a boolean to say "use from"
envelopesender
[sendemail.git]
from = Junio C Hamano <gitster@pobox.com>
to = git mailing list <git@vger.kernel.org>
[sendemail.frotz]
from = Junio C Hamano <frotzster@example.xz>
to = frotz mailing list <frotz@example.xz>
and then in my {git,frotz}.git/.git/config would have
[sendemail] [sendemail]
identity = git identity = frotz
respectively. Without your patch, in $HOME/.gitconfig, I wouldn't have
the global sendemail.envelopesender but have separate individual
configuration variables sendemail.{git,frotz}.envelopesender defined.
^ permalink raw reply
* Re: git-svn: Fails to drop leading path from empty dir name
From: Björn Steinbrink @ 2009-11-22 23:52 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20091122232504.GA28127@dcvr.yhbt.net>
Hi Eric,
On 2009.11.22 15:25:04 -0800, Eric Wong wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> I'm having a bit of trouble figuring out exactly what you mean
> here, can you double check your tests? Annotations below, thanks
>
> > +test_expect_success 'clone trunk' 'git svn clone -s "$svnrepo" trunk'
> ^^ ^^^^^
> Huh?
>
> > +test_expect_success 'empty directories in trunk exist' '
> > + (
> > + cd cloned &&
> ^^^^^^ - ?
>
> > + for i in trunk/a trunk/"weird file name"
Argh, yeah, I messed that patch up, the test only failed because I also
messed up this line, adding the trunk prefix there, too. Fixed patch
below.
SVN Repo layout:
/
|
|---trunk
| |
... |---foo/ # Empty
|
|---bar/
|
somefile
with "git svn clone -s svn://host/path/to/repo you get:
.git
bar/
bar/somefile
trunk/foo # This should be just foo/
i.e. the empty directories have their path relative to the repo root,
instead of relative to the directory the git branch is associated with.
Sorry for the messed up first patch.
Björn
diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
index 5948544..70c52c1 100755
--- a/t/t9146-git-svn-empty-dirs.sh
+++ b/t/t9146-git-svn-empty-dirs.sh
@@ -82,4 +82,27 @@ test_expect_success 'git svn mkdirs -r works' '
)
'
+test_expect_success 'initialize trunk' '
+ for i in trunk trunk/a trunk/"weird file name"
+ do
+ svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
+ done
+'
+
+test_expect_success 'clone trunk' 'git svn clone -s "$svnrepo" trunk'
+
+test_expect_success 'empty directories in trunk exist' '
+ (
+ cd trunk &&
+ for i in a "weird file name"
+ do
+ if ! test -d "$i"
+ then
+ echo >&2 "$i does not exist"
+ exit 1
+ fi
+ done
+ )
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH] log --format: document %w
From: René Scharfe @ 2009-11-22 23:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vzl6eiiyx.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
>
>> I'm not especially proud of the triple negative in that note. How to say it
>> better, yet concise?
>> +- '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
>> + linkgit:git-shortlog[1]. NOTE: Color placeholders (`%C*`) are not
>> + recognized as having no width, so they should not be put into wrapped
>> + sections.
>
> "The code miscounts the width of '%C*' color placeholders"?
>
> Perhaps somebody in the codepath leading to pick_one_utf8_char() in utf8.c
> can be made aware of them?
>
> utf8_width() is called from many places (has one caller outside utf8.c as
> well). It is given a pointer to a pointer that points at the current
> position in a string, and is responsible for picking up one logical letter
> advancing the given pointer to skip over that letter, and returning the
> display width of that one letter. The function wants the string to be
> encoded in utf-8 and signals by putting NULL in the pointer when it
> detects the input string is not.
>
> Picking up one logical letter is done by pick_one_utf8_char(), which is a
> nicely written generic "We are at the character boundary of a potentially
> multi-byte utf-8 string; pick the first character" implementation, and we
> wouldn't want to contaminate that with escape sequence logic---we might
> want to reuse it in other codepaths where we have no reason to expect any
> escape sequences.
>
> So perhaps we can introduce is_esc_sequence(s, r, w) that
>
> - returns true if we are at the beginning of an esc-sequence;
> - skips the sequence just like utf8_width() does with s and r; and
> - counts the width of the sequence and returns it in *w
>
> The implementation of the is_esc_sequence() could be to only detect the
> color sequence (if the sequence has things like cursor-position control
> then we are already lost, as calling "utf8_width()" on such a string does
> not make much sense anyway) and report zero-width.
>
> I dunno.
>
> diff --git a/utf8.c b/utf8.c
> index 5c18f0c..d45e75f 100644
> --- a/utf8.c
> +++ b/utf8.c
> @@ -241,7 +241,12 @@ invalid:
> */
> int utf8_width(const char **start, size_t *remainder_p)
> {
> - ucs_char_t ch = pick_one_utf8_char(start, remainder_p);
> + ucs_char_t ch;
> + int w;
> +
> + if (is_esc_sequence(start, remainder_p, &w))
> + return w;
> + ch = pick_one_utf8_char(start, remainder_p);
> if (!*start)
> return 0;
> return git_wcwidth(ch);
I think utf8_width() is too generic for that; we shouldn't teach it terminal
control details. Something like this? It keeps it all local to
strbuf_add_wrapped_text(); ignoring display mode escape codes in there can be
justified with its purpose.
utf8.c | 23 ++++++++++++++++++++++-
1 files changed, 22 insertions(+), 1 deletions(-)
diff --git a/utf8.c b/utf8.c
index 5c18f0c..fcc0aeb 100644
--- a/utf8.c
+++ b/utf8.c
@@ -298,6 +298,21 @@ static void print_spaces(struct strbuf *buf, int count)
strbuf_write(buf, s, count);
}
+/* XXX: this handles display mode sequences, only. Do we need more? */
+static size_t esc_sequence_len(const char *s)
+{
+ const char *p = s;
+ if (*p++ != '\033')
+ return 0;
+ if (*p++ != '[')
+ return 0;
+ while (isdigit(*p) || *p == ';')
+ p++;
+ if (*p++ != 'm')
+ return 0;
+ return p - s;
+}
+
/*
* Wrap the text, if necessary. The variable indent is the indent for the
* first line, indent2 is the indent for all other lines.
@@ -329,7 +344,13 @@ int strbuf_add_wrapped_text(struct strbuf *buf,
}
for (;;) {
- char c = *text;
+ char c;
+ size_t skip;
+
+ while ((skip = esc_sequence_len(text)))
+ text += skip;
+
+ c = *text;
if (!c || isspace(c)) {
if (w < width || !space) {
const char *start = bol;
^ permalink raw reply related
* [PATCH] git svn: always reuse existing remotes on fetch
From: Eric Wong @ 2009-11-22 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Michael J Gruber, Yaroslav Halchenko
In-Reply-To: <20091120204723.GB30423@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> wrote:
> so there's apparently a bug in our handling of
> svn-remote != "svn" somewhere...
>From 4d0157d6995925ea55ff181ea94d058583333f90 Mon Sep 17 00:00:00 2001
From: Eric Wong <normalperson@yhbt.net>
Date: Sun, 22 Nov 2009 12:37:06 -0800
Subject: [PATCH] git svn: always reuse existing remotes on fetch
The internal no_reuse_existing flag is set to allow initializing
multiple remotes with the same URL, common with SVM users.
Unfortunately, this flag caused misbehavior when used
with the -R command-line flag for fetching.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 2746895..7f7a56f 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -428,6 +428,7 @@ sub cmd_fetch {
if (@_ > 1) {
die "Usage: $0 fetch [--all] [--parent] [svn-remote]\n";
}
+ $Git::SVN::no_reuse_existing = undef;
if ($_fetch_parent) {
my ($url, $rev, $uuid, $gs) = working_head_info('HEAD');
unless ($gs) {
@@ -956,6 +957,7 @@ sub cmd_multi_init {
}
sub cmd_multi_fetch {
+ $Git::SVN::no_reuse_existing = undef;
my $remotes = Git::SVN::read_all_remotes();
foreach my $repo_id (sort keys %$remotes) {
if ($remotes->{$repo_id}->{url}) {
--
Eric Wong
^ permalink raw reply related
* Re: 'error: unable to set permission to './objects/...'
From: Junio C Hamano @ 2009-11-22 23:27 UTC (permalink / raw)
To: Rafal Rusin; +Cc: git
In-Reply-To: <9bbf67fa0911221202r605de38coc2496b1f09123725@mail.gmail.com>
Rafal Rusin <rafal.rusin@gmail.com> writes:
> I'm hosting git repository on filesystem with 'chmod <some-file>'
> causing permission denied error (it's smbfs mounted directory),
> When I was doing push to such repo using file:// protocol, I got
> following error:
> error: unable to set permission to './objects/...'
>
> I did a small fix to sha1_file.c (patch in attachment) and git now
> warns when unable to chmod, and continues push. This resolved problem.
> What do you think about applying it?
Suppose the user wanted to use this as a shared public repository and
configured core.sharedrepository. If we try to set shared-perm and notice
a failure but keep going, what happens to the resulting repository?
For example, the umask of the user who is pushing objects, causing this
codepath to run, might be too tight to be usable for the purpose of making
the file readable for other members of the group. And the chmod() fails
in this codepath. Then what? Wouldn't it make the resulting repository
unusable?
I think a _fix_ needs to first know why chmod is failing for you and
either
(1) make it not to fail; or
(2) Perhaps your filesystem is lying and the result of chmod happens to
be Ok (iow, the resulting file may be readable/writable by people who
are supposed to be able to, accoring to the core.sharedrepository
settings), in which case make the code notice the situation and keep
going _only when_ it is safe to do so.
I do not think your change to _unconditionally_ keep going is a fix.
^ permalink raw reply
* Re: git-svn: Fails to drop leading path from empty dir name
From: Eric Wong @ 2009-11-22 23:25 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20091122134638.GA12233@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> wrote:
> Hi Eric,
>
> the stuff to create empty directories fails to strip leading path
> components, e.g. when using
> "git svn clone -s svn://whatever/project/trunk".
>
> Instead of creating the empty directory "foo" in the repo root, it
> creates "project/trunk/foo".
>
> Ad hoc patch for the test case below.
>
> Björn
>
> diff --git a/t/t9146-git-svn-empty-dirs.sh b/t/t9146-git-svn-empty-dirs.sh
> index 5948544..9e22089 100755
> --- a/t/t9146-git-svn-empty-dirs.sh
> +++ b/t/t9146-git-svn-empty-dirs.sh
> @@ -82,4 +82,27 @@ test_expect_success 'git svn mkdirs -r works' '
> )
> '
>
> +test_expect_success 'initialize trunk' '
> + for i in trunk trunk/a trunk/"weird file name"
> + do
> + svn_cmd mkdir -m "mkdir $i" "$svnrepo"/"$i"
> + done
> +'
> +
Hi Björn,
I'm having a bit of trouble figuring out exactly what you mean
here, can you double check your tests? Annotations below, thanks
> +test_expect_success 'clone trunk' 'git svn clone -s "$svnrepo" trunk'
^^ ^^^^^
Huh?
> +test_expect_success 'empty directories in trunk exist' '
> + (
> + cd cloned &&
^^^^^^ - ?
> + for i in trunk/a trunk/"weird file name"
> + do
> + if ! test -d "$i"
> + then
> + echo >&2 "$i does not exist"
> + exit 1
> + fi
> + done
--
Eric Wong
^ permalink raw reply
* [PATCH 1/2 v2] merge-recursive: point the user to commit when file would be overwritten.
From: Matthieu Moy @ 2009-11-22 22:26 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1258732767-12741-1-git-send-email-Matthieu.Moy@imag.fr>
The commit-before-pull is well accepted in the DVCS community, but is
confusing some new users. This should get them back in the right way when
the problem occurs.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/config.txt | 4 ++++
advice.c | 2 ++
advice.h | 1 +
merge-recursive.c | 8 +++++++-
4 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 13871a6..f481f8d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -126,6 +126,10 @@ advice.*::
Directions on how to stage/unstage/add shown in the
output of linkgit:git-status[1] and the template shown
when writing commit messages. Default: true.
+ commitBeforeMerge::
+ Advice shown when linkgit:git-merge[1] refuses to
+ merge to avoid overwritting local changes.
+ Default: true.
--
core.fileMode::
diff --git a/advice.c b/advice.c
index ae4b1e8..cb666ac 100644
--- a/advice.c
+++ b/advice.c
@@ -2,6 +2,7 @@
int advice_push_nonfastforward = 1;
int advice_status_hints = 1;
+int advice_commit_before_merge = 1;
static struct {
const char *name;
@@ -9,6 +10,7 @@ static struct {
} advice_config[] = {
{ "pushnonfastforward", &advice_push_nonfastforward },
{ "statushints", &advice_status_hints },
+ { "commitbeforemerge", &advice_commit_before_merge },
};
int git_default_advice_config(const char *var, const char *value)
diff --git a/advice.h b/advice.h
index e9df8e0..3de5000 100644
--- a/advice.h
+++ b/advice.h
@@ -3,6 +3,7 @@
extern int advice_push_nonfastforward;
extern int advice_status_hints;
+extern int advice_commit_before_merge;
int git_default_advice_config(const char *var, const char *value);
diff --git a/merge-recursive.c b/merge-recursive.c
index f55b7eb..1870448 100644
--- a/merge-recursive.c
+++ b/merge-recursive.c
@@ -3,6 +3,7 @@
* Fredrik Kuivinen.
* The thieves were Alex Riesen and Johannes Schindelin, in June/July 2006
*/
+#include "advice.h"
#include "cache.h"
#include "cache-tree.h"
#include "commit.h"
@@ -170,7 +171,7 @@ static int git_merge_trees(int index_only,
int rc;
struct tree_desc t[3];
struct unpack_trees_options opts;
- static const struct unpack_trees_error_msgs msgs = {
+ struct unpack_trees_error_msgs msgs = {
/* would_overwrite */
"Your local changes to '%s' would be overwritten by merge. Aborting.",
/* not_uptodate_file */
@@ -182,6 +183,11 @@ static int git_merge_trees(int index_only,
/* bind_overlap -- will not happen here */
NULL,
};
+ if (advice_commit_before_merge) {
+ msgs.would_overwrite = msgs.not_uptodate_file =
+ "Your local changes to '%s' would be overwritten by merge. Aborting.\n"
+ "Please, commit your changes or stash them before you can merge.";
+ }
memset(&opts, 0, sizeof(opts));
if (index_only)
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* [PATCH 2/2 v2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Matthieu Moy @ 2009-11-22 22:26 UTC (permalink / raw)
To: git, gitster; +Cc: Matthieu Moy
In-Reply-To: <1258732767-12741-1-git-send-email-Matthieu.Moy@imag.fr>
We explain the user why uncommited changes can be problematic with merge,
and point to "commit" and "stash" for the solution. While talking about
commited Vs uncommited changes, we also make it clear that the result of
a merge is normally commited.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
---
Documentation/user-manual.txt | 20 ++++++++++++++++++--
1 files changed, 18 insertions(+), 2 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 269ec47..c09f4b2 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -1183,7 +1183,23 @@ $ git merge branchname
-------------------------------------------------
merges the development in the branch "branchname" into the current
-branch. If there are conflicts--for example, if the same file is
+branch.
+
+A merge is made by combining the changes made in "branchname" and the
+changes made up to the latest commit in your current branch since
+their histories forked. The work tree is overwritten by the result of
+the merge when this combining is done cleanly, or overwritten by a
+half-merged results when this combining results in conflicts.
+Therefore, if you have uncommitted changes touching the same files as
+the ones impacted by the merge, Git will refuse to proceed. Most of
+the time, you will want to commit your changes before you can merge,
+and if you don't, then linkgit:git-stash[1] can take these changes
+away while you're doing the merge, and reapply them afterwards.
+
+If the changes are independant enough, Git will automatically complete
+the merge and commit the result (or reuse an existing commit in case
+of <<fast-forwards,fast-forward>>, see below). On the other hand,
+if there are conflicts--for example, if the same file is
modified in two different ways in the remote branch and the local
branch--then you are warned; the output may look something like this:
@@ -1679,7 +1695,7 @@ Sharing development with others
Getting updates with git pull
-----------------------------
-After you clone a repository and make a few changes of your own, you
+After you clone a repository and commit a few changes of your own, you
may wish to check the original repository for updates and merge them
into your own work.
--
1.6.5.3.435.g5f2e3.dirty
^ permalink raw reply related
* Re: [PATCH 2/2] user-manual: Document that "git merge" doesn't like uncommited changes.
From: Matthieu Moy @ 2009-11-22 22:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4xlvtib.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "but not the working tree itself" is not incorrect per-se, but misses the
> point. How about...
>
> A merge is made by combining the changes made in "branchname" and
> the changes made up to the latest commit in your current branch
> since their histories forke. The work tree is overwritten by the
> result of the merge when this combining is done cleanly, or
> overwritten by a half-merged results when this combining results
> in conflicts. Therefore, ...
Maybe better. OTOH, it reveals another problem: Your "the work tree is
overwritten by ..." tend to imply that the result is not commited,
while the normal case is indeed to create a merge commit
automatically.
In its current state, the doc jumps to conflict resolution and how to
commit after resolving them without saying "oh, normally this is over,
Git did the commit for you". And for people comming from SVN, thinking
"merge = update", it's not obvious at all that a merge should result
in a commit.
So, I'll resend with one more paragraph talking about autocommit.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH 1/2] merge-recursive: point the user to commit when file would be overwritten.
From: Matthieu Moy @ 2009-11-22 22:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vskc9vzqg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Matthieu Moy <Matthieu.Moy@imag.fr> writes:
>
>> The commit-before-pull is well accepted in the DVCS community, but is
>> confusing some new users. This should get them back in the right way when
>> the problem occurs.
>>
>> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
>
> Don't these extra lines warrant "advice.*" option?
I was thinking this would be overkill for a one-line advice, but it
doesn't harm to provide the option. I'll resend the patch with it
(it's not _as_ straightforward as it seems to be since the initial
structure is static in the function, but still reasonable).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: 'error: unable to set permission to './objects/...'
From: Miklos Vajna @ 2009-11-22 22:09 UTC (permalink / raw)
To: Rafal Rusin; +Cc: git
In-Reply-To: <9bbf67fa0911221202r605de38coc2496b1f09123725@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 373 bytes --]
On Sun, Nov 22, 2009 at 09:02:12PM +0100, Rafal Rusin <rafal.rusin@gmail.com> wrote:
> I did a small fix to sha1_file.c (patch in attachment) and git now
> warns when unable to chmod, and continues push. This resolved problem.
> What do you think about applying it?
Please read Documentation/SubmittingPatches, patches should be sent
inline and with a Signed-off-by line.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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