* Re: rsync deprecated?
From: Mike Hommey @ 2008-12-20 8:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljuei2xw.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 17, 2008 at 07:20:59PM -0800, Junio C Hamano wrote:
> Markus Heidelberg <markus.heidelberg@web.de> writes:
>
> > in the "Merging external work" section of the gitcore-tutorial it is
> > stated that the rsync transport is deprecated. The description was added
> > in commit 914328a (Update tutorial., 2005-08-30) together with the
> > "deprecated" note. Having never heard/read this before and since this
> > commit is quite old, I wonder if it is still the case or there was a
> > solution for this problem.
>
> Sorry, I do not quite understand what you perceive as "this problem".
>
> It has been deprecated for too long a time. Maybe it is time to remove
> the support, instead of carrying the deprecated command forever? Is that
> the problem you are talking about?
>
> I tend to agree that rsync transport way outlived its usefulness, and not
> maintained at all. There may be unnoticed and undiagnosed bugs lurking,
> but nobody knows about it because nobody uses it.
Something that could well make this transport be maintained would be to
make it share code/internal API with the "local file transport".
Ideally, http, rsync and file could all share the same basis, and
ensuring the file transport to be functional would pretty much guarantee
all work.
Anyways, I'm not the right person to say that, as I've been failing to
deliver a beginning of such code for a year, now (damn, time goes too
fast).
Maybe libgit2 could be a good occasion to start some API like this,
though.
Mike
^ permalink raw reply
* Re: [PATCH 1/4] Introduce commit notes
From: Jeff King @ 2008-12-20 8:05 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Johannes Schindelin, Govind Salinas, Git Mailing List
In-Reply-To: <200812200855.14915.robin.rosenberg.lists@dewire.com>
On Sat, Dec 20, 2008 at 08:55:14AM +0100, Robin Rosenberg wrote:
> > Hmm. I wanted to try some performance comparisons based on this
> > implementation, but I can't get your 1/4 to apply. Conflicts in
> > config.txt and cache.h when applying to master, and "sha1 information is
> > lacking or useless" for a 3-way merge. What did you base this on?
>
> patch(1) however can crunch it, with the exception of cache.h. Shouldn't
> git am/appy and patch agree on git generated patches (without binary diffs)?
No. git apply is intentionally much more strict about applying under the
assumption that it is better to force a conflict than to silently apply
something that has a reasonable chance of being completely wrong.
And usually it is not a big deal because falling back to the 3-way merge
is a much nicer way of handling any conflicts _anyway_ (I find .rej
files so much more useless than conflict markers, personally).
In this case I was able to:
1. git am /the/patch
2. patch -p1 <.git/rebase-apply/patch
3. manually inspect the results for sanity, and fix up the cache.h
bit that failed totally
4. git add -u && git add notes.[ch]
5. git am --resolved
-Peff
^ permalink raw reply
* Re: [PATCH 1/4] Introduce commit notes
From: Robin Rosenberg @ 2008-12-20 7:55 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Govind Salinas, Git Mailing List
In-Reply-To: <20081220065337.GA2581@coredump.intra.peff.net>
lördag 20 december 2008 07:53:38 skrev Jeff King:
> On Sat, Dec 20, 2008 at 12:35:06AM +0100, Johannes Schindelin wrote:
>
> > Commit notes are blobs which are shown together with the commit
> > message. These blobs are taken from the notes ref, which you can
> > configure by the config variable core.notesRef, which in turn can
> > be overridden by the environment variable GIT_NOTES_REF.
>
> Hmm. I wanted to try some performance comparisons based on this
> implementation, but I can't get your 1/4 to apply. Conflicts in
> config.txt and cache.h when applying to master, and "sha1 information is
> lacking or useless" for a 3-way merge. What did you base this on?
patch(1) however can crunch it, with the exception of cache.h. Shouldn't
git am/appy and patch agree on git generated patches (without binary diffs)?
-- robin
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Robin Rosenberg @ 2008-12-20 7:08 UTC (permalink / raw)
To: Boyd Stephen Smith Jr., Junio C Hamano; +Cc: git
In-Reply-To: <200812182039.15169.bss@iguanasuicide.net>
fredag 19 december 2008 03:39:15 skrev Boyd Stephen Smith Jr.:
> Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
> ---
> On Thursday 2008 December 18 18:21:25 Linus Torvalds wrote:
> > I suspect we should warn about reverting merges.
>
Or mention the reverted parent in the commit message since it is not obvious.
-- robin
>From e982c8cefcdeefd6e8aabc8c354bed69161f40ee Mon Sep 17 00:00:00 2001
From: Robin Rosenberg <robin.rosenberg@dewire.com>
Date: Sat, 20 Dec 2008 07:22:39 +0100
Subject: [PATCH] Mention reverted parent in commit message for reverted merge.
Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com>
---
builtin-revert.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/builtin-revert.c b/builtin-revert.c
index 4038b41..fc59229 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -352,6 +352,10 @@ static int revert_or_cherry_pick(int argc, const char **argv)
add_to_msg(oneline_body + 1);
add_to_msg("\"\n\nThis reverts commit ");
add_to_msg(sha1_to_hex(commit->object.sha1));
+ if (commit->parents->next) {
+ add_to_msg(" removing\ncontributions from ");
+ add_to_msg(sha1_to_hex(parent->object.sha1));
+ }
add_to_msg(".\n");
} else {
base = parent;
--
1.6.1.rc3.36.g43d5.dirty
^ permalink raw reply related
* Re: [PATCH 1/4] Introduce commit notes
From: Jeff King @ 2008-12-20 6:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Govind Salinas, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0812200034450.30769@pacific.mpi-cbg.de>
On Sat, Dec 20, 2008 at 12:35:06AM +0100, Johannes Schindelin wrote:
> Commit notes are blobs which are shown together with the commit
> message. These blobs are taken from the notes ref, which you can
> configure by the config variable core.notesRef, which in turn can
> be overridden by the environment variable GIT_NOTES_REF.
Hmm. I wanted to try some performance comparisons based on this
implementation, but I can't get your 1/4 to apply. Conflicts in
config.txt and cache.h when applying to master, and "sha1 information is
lacking or useless" for a 3-way merge. What did you base this on?
-Peff
^ permalink raw reply
* Re: [PATCH] Documentation: fix typos, grammar, asciidoc syntax
From: Junio C Hamano @ 2008-12-20 6:48 UTC (permalink / raw)
To: markus.heidelberg; +Cc: git
In-Reply-To: <200812191314.19302.markus.heidelberg@web.de>
Markus Heidelberg <markus.heidelberg@web.de> writes:
> Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
> ---
> Documentation/diff-format.txt | 2 +-
> Documentation/diff-generate-patch.txt | 6 +++---
> Documentation/git-commit.txt | 2 +-
> Documentation/git-diff-tree.txt | 4 ++--
> Documentation/git-mailinfo.txt | 2 +-
> Documentation/git-receive-pack.txt | 4 ++--
> Documentation/git-reflog.txt | 4 ++--
> Documentation/git-show-branch.txt | 4 ++--
> Documentation/git-submodule.txt | 2 +-
> Documentation/git-update-index.txt | 8 ++++----
> Documentation/gitcore-tutorial.txt | 8 ++++----
> Documentation/gitk.txt | 4 ++--
> Documentation/i18n.txt | 4 ++--
> 13 files changed, 27 insertions(+), 27 deletions(-)
Whew, quite a lot of typos there are.
> @@ -172,7 +172,7 @@ only the primary branches. In addition, if you happen to be on
> your topic branch, it is shown as well.
>
> ------------
> -$ git show-branch --reflog='10,1 hour ago' --list master
> +$ git show-branch --reflog="10,1 hour ago" --list master
> ------------
Is this just a personal taste, or a correction to typography?
Other than this one, I did not find anything else in your patch that
looked iffy. Thanks for lending a good set of eyeballs.
^ permalink raw reply
* Re: [PATCH] git-send-email: handle email address with quoted comma
From: Junio C Hamano @ 2008-12-20 6:48 UTC (permalink / raw)
To: Wu Fengguang; +Cc: git@vger.kernel.org, Matt Kraai
In-Reply-To: <20081219081010.GA12494@localhost>
Wu Fengguang <fengguang.wu@intel.com> writes:
> Thank you for the helpful information. The patch is updated and tested
Thanks. I'll apply but it would be nice to have an additional test script
somewhere in t/t9001-send-email.sh to protect this change from regression
by future changes.
^ permalink raw reply
* [Security] gitweb local privilege escalation (fix)
From: Junio C Hamano @ 2008-12-20 6:46 UTC (permalink / raw)
To: git; +Cc: linux-kernel
In-Reply-To: <7vljub1h92.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1050 bytes --]
Current gitweb has a possible local privilege escalation bug that allows a
malicious repository owner to run a command of his choice by specifying
diff.external configuration variable in his repository and running a
crafted gitweb query.
Recent (post 1.4.3) gitweb itself never generates a link that would result
in such a query, and the safest and cleanest fix to this issue is to
simply drop the support for it. Maintenance release v1.6.0.6, v1.5.6.6,
v1.5.5.6 and v1.5.4.7 are already available at k.org (see the announcement
for v1.6.0.6 I sent out a few minutes ago), and the master branch and
others pushed out tonight have the same fix.
This message contains two patches (credits go to Matt McCutchen, Jeff King
and Jakub Narebski) to do the fix yourself:
(1) for Git 1.5.4.X, 1.5.5.X, and 1.5.6.X, and
(2) for Git 1.6.0.X.
Distro packagers and people on the vendor security list have been notified
about this fix earlier this week; people running gitweb from vendor
supplied binaries should be able to get updates from them as well.
[-- Attachment #2: gitweb hotfix for 1.5.[456].X series --]
[-- Type: text/plain, Size: 2313 bytes --]
>From dfff4b7aa42de7e7d58caeebe2c6128449f09b76 Mon Sep 17 00:00:00 2001
From: Junio C Hamano <gitster@pobox.com>
Date: Tue, 16 Dec 2008 19:42:02 -0800
Subject: [PATCH] gitweb: do not run "git diff" that is Porcelain
Jakub says that legacy-style URI to view two blob differences are never
generated since 1.4.3. This codepath runs "git diff" Porcelain from the
gitweb, which is a no-no. It can trigger diff.external command that is
specified in the configuration file of the repository being viewed.
This patch applies to v1.5.4 and later.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
gitweb/gitweb.perl | 38 ++------------------------------------
1 files changed, 2 insertions(+), 36 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index b582332..86a6ced 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4809,43 +4809,9 @@ sub git_blobdiff {
or die_error(undef, "Open git-diff-tree failed");
}
- # old/legacy style URI
- if (!%diffinfo && # if new style URI failed
- defined $hash && defined $hash_parent) {
- # fake git-diff-tree raw output
- $diffinfo{'from_mode'} = $diffinfo{'to_mode'} = "blob";
- $diffinfo{'from_id'} = $hash_parent;
- $diffinfo{'to_id'} = $hash;
- if (defined $file_name) {
- if (defined $file_parent) {
- $diffinfo{'status'} = '2';
- $diffinfo{'from_file'} = $file_parent;
- $diffinfo{'to_file'} = $file_name;
- } else { # assume not renamed
- $diffinfo{'status'} = '1';
- $diffinfo{'from_file'} = $file_name;
- $diffinfo{'to_file'} = $file_name;
- }
- } else { # no filename given
- $diffinfo{'status'} = '2';
- $diffinfo{'from_file'} = $hash_parent;
- $diffinfo{'to_file'} = $hash;
- }
-
- # non-textual hash id's can be cached
- if ($hash =~ m/^[0-9a-fA-F]{40}$/ &&
- $hash_parent =~ m/^[0-9a-fA-F]{40}$/) {
- $expires = '+1d';
- }
-
- # open patch output
- open $fd, "-|", git_cmd(), "diff", @diff_opts,
- '-p', ($format eq 'html' ? "--full-index" : ()),
- $hash_parent, $hash, "--"
- or die_error(undef, "Open git-diff failed");
- } else {
+ # old/legacy style URI -- not generated anymore since 1.4.3.
+ if (!%diffinfo) {
die_error('404 Not Found', "Missing one of the blob diff parameters")
- unless %diffinfo;
}
# header
--
1.6.1.rc3.19.g66a9
[-- Attachment #3: gitweb hotfix for 1.6.0.X series --]
[-- Type: text/plain, Size: 1630 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index ced7bb7..804670c 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -4863,43 +4863,9 @@ sub git_blobdiff {
or die_error(500, "Open git-diff-tree failed");
}
- # old/legacy style URI
- if (!%diffinfo && # if new style URI failed
- defined $hash && defined $hash_parent) {
- # fake git-diff-tree raw output
- $diffinfo{'from_mode'} = $diffinfo{'to_mode'} = "blob";
- $diffinfo{'from_id'} = $hash_parent;
- $diffinfo{'to_id'} = $hash;
- if (defined $file_name) {
- if (defined $file_parent) {
- $diffinfo{'status'} = '2';
- $diffinfo{'from_file'} = $file_parent;
- $diffinfo{'to_file'} = $file_name;
- } else { # assume not renamed
- $diffinfo{'status'} = '1';
- $diffinfo{'from_file'} = $file_name;
- $diffinfo{'to_file'} = $file_name;
- }
- } else { # no filename given
- $diffinfo{'status'} = '2';
- $diffinfo{'from_file'} = $hash_parent;
- $diffinfo{'to_file'} = $hash;
- }
-
- # non-textual hash id's can be cached
- if ($hash =~ m/^[0-9a-fA-F]{40}$/ &&
- $hash_parent =~ m/^[0-9a-fA-F]{40}$/) {
- $expires = '+1d';
- }
-
- # open patch output
- open $fd, "-|", git_cmd(), "diff", @diff_opts,
- '-p', ($format eq 'html' ? "--full-index" : ()),
- $hash_parent, $hash, "--"
- or die_error(500, "Open git-diff failed");
- } else {
- die_error(400, "Missing one of the blob diff parameters")
- unless %diffinfo;
+ # old/legacy style URI -- not generated anymore since 1.4.3.
+ if (!%diffinfo) {
+ die_error('404 Not Found', "Missing one of the blob diff parameters")
}
# header
^ permalink raw reply related
* [ANNOUNCE] GIT 1.6.0.6
From: Junio C Hamano @ 2008-12-20 6:40 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.6.0.6 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.6.0.6.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.0.6.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.0.6.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are also provided
as courtesy.
RPMS/$arch/git-*-1.6.0.6-1.fc9.$arch.rpm (RPM)
Among miscellaneous fixes, this contains a local gitweb security fix.
Maintenance releases for older versions (v1.5.4.7, v1.5.5.6 and v1.5.6.6)
are also available at the same place.
----------------------------------------------------------------
Changes since v1.6.0.5 are as follows:
David Aguilar (1):
git-mergetool: properly handle "git mergetool -- filename"
Deskin Miller (1):
git-svn: Make following parents atomic
Jim Meyering (1):
git-config.txt: fix a typo
Johannes Schindelin (2):
fast-import: close pack before unlinking it
fast-export: deal with tag objects that do not have a tagger
Junio C Hamano (6):
work around Python warnings from AsciiDoc
git-show: do not segfault when showing a bad tag
pager: do not dup2 stderr if it is already redirected
gitweb: do not run "git diff" that is Porcelain
GIT 1.5.4.7
fast-import: make tagger information optional
Linus Torvalds (1):
fsck: reduce stack footprint
Markus Heidelberg (1):
Documentation: fix typos, grammar, asciidoc syntax
Miklos Vajna (1):
SubmittingPatches: mention the usage of real name in Signed-off-by: lines
Nicolas Pitre (1):
make sure packs to be replaced are closed beforehand
Wu Fengguang (1):
git-send-email: handle email address with quoted comma
^ permalink raw reply
* [PATCH] Remove the requirement opaquelocktoken uri scheme
From: Kirill A. Korinskiy @ 2008-12-20 6:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, catap
In-Reply-To: <7vljucbows.fsf@gitster.siamese.dyndns.org>
The program flow of pushing over http is:
- call lock_remote() to issue a DAV_LOCK request to the server to lock
info/refs and branch refs being pushed into; handle_new_lock_ctx() is
used to parse its response to populate "struct remote_lock" that is
returned from lock_remote();
- send objects;
- call unlock_remote() to drop the lock.
The handle_new_lock_ctx() function assumed that the server will use a
lock token in opaquelocktoken URI scheme, which may have been an Ok
assumption under RFC 2518, but under RFC 4918 which obsoletes the older
standard it is not necessarily true.
This resulted in push failure (often resulted in "cannot lock existing
info/refs" error message) when talking to a server that does not use
opaquelocktoken URI scheme.
Signed-off-by: Kirill A. Korinskiy <catap@catap.ru>
---
http-push.c | 14 ++++++--------
1 files changed, 6 insertions(+), 8 deletions(-)
diff --git a/http-push.c b/http-push.c
index 5cecef434a7740a3f853462978c3e071b4da7e74..7c6460919bf3eba10c46cede11ffdd9c53fd2dd2 100644
--- a/http-push.c
+++ b/http-push.c
@@ -595,7 +595,7 @@ static int refresh_lock(struct remote_lock *lock)
lock->refreshing = 1;
if_header = xmalloc(strlen(lock->token) + 25);
- sprintf(if_header, "If: (<opaquelocktoken:%s>)", lock->token);
+ sprintf(if_header, "If: (<%s>)", lock->token);
sprintf(timeout_header, "Timeout: Second-%ld", lock->timeout);
dav_headers = curl_slist_append(dav_headers, if_header);
dav_headers = curl_slist_append(dav_headers, timeout_header);
@@ -1120,10 +1120,8 @@ static void handle_new_lock_ctx(struct xml_ctx *ctx, int tag_closed)
lock->timeout =
strtol(ctx->cdata + 7, NULL, 10);
} else if (!strcmp(ctx->name, DAV_ACTIVELOCK_TOKEN)) {
- if (!prefixcmp(ctx->cdata, "opaquelocktoken:")) {
- lock->token = xmalloc(strlen(ctx->cdata) - 15);
- strcpy(lock->token, ctx->cdata + 16);
- }
+ lock->token = xmalloc(strlen(ctx->cdata) + 1);
+ strcpy(lock->token, ctx->cdata);
}
}
}
@@ -1308,7 +1306,7 @@ static int unlock_remote(struct remote_lock *lock)
int rc = 0;
lock_token_header = xmalloc(strlen(lock->token) + 31);
- sprintf(lock_token_header, "Lock-Token: <opaquelocktoken:%s>",
+ sprintf(lock_token_header, "Lock-Token: <%s>",
lock->token);
dav_headers = curl_slist_append(dav_headers, lock_token_header);
@@ -1722,7 +1720,7 @@ static int update_remote(unsigned char *sha1, struct remote_lock *lock)
struct curl_slist *dav_headers = NULL;
if_header = xmalloc(strlen(lock->token) + 25);
- sprintf(if_header, "If: (<opaquelocktoken:%s>)", lock->token);
+ sprintf(if_header, "If: (<%s>)", lock->token);
dav_headers = curl_slist_append(dav_headers, if_header);
strbuf_addf(&out_buffer.buf, "%s\n", sha1_to_hex(sha1));
@@ -1941,7 +1939,7 @@ static void update_remote_info_refs(struct remote_lock *lock)
add_remote_info_ref, &buffer.buf);
if (!aborted) {
if_header = xmalloc(strlen(lock->token) + 25);
- sprintf(if_header, "If: (<opaquelocktoken:%s>)", lock->token);
+ sprintf(if_header, "If: (<%s>)", lock->token);
dav_headers = curl_slist_append(dav_headers, if_header);
slot = get_active_slot();
--
1.5.6.5
^ permalink raw reply related
* Re: Git Notes idea.
From: Jeff King @ 2008-12-20 4:54 UTC (permalink / raw)
To: Govind Salinas; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <5d46db230812191424m14e82c5fx1c1c12027db901ed@mail.gmail.com>
On Fri, Dec 19, 2008 at 04:24:01PM -0600, Govind Salinas wrote:
> > I think so. Otherwise how will you push and pull notes? You won't even
> > know which one is the more recent tree, let alone handle any merges
> > caused by editing notes in two places.
>
> Couldn't you simply merge your tree and theirs even if there is no
> history. You would have to find a way to handle merges in any event
> since they could just as easily happen if you have a history.
Let's say I have a tree T1 like this:
$COMMIT_A -> $BLOB_A
$COMMIT_B -> $BLOB_B1
and a tree T2 like this:
$COMMIT_B -> $BLOB_B2
$COMMIT_C -> $BLOB_C
what is the correct merge? Was $COMMIT_A added in T1, or deleted in T2?
How about $COMMIT_C? Even if you went with a strategy like "always add
from both" (which I don't think is a good idea, because deleted notes
will keep popping back up) you have a conflict with $COMMIT_B. Should
it be B1 or B2? You can't tell if B1 became B2, vice versa, or if there
is a true merge conflict.
> > If the former, then you haven't solved the cruft accumulation problem.
> > You can get obsolete notes in your note history by rebasing on a branch
> > that is long-running (which is OK as long as you haven't published
> > _those particular_ commits). Or are you proposing to rebase and cleanup
> > the notes history every time you do a destructive operation?
>
> Yes, it does not solve that problem. But it does solve things like
>
> Dev1 and Dev2 both have branches A and topic branch B. and they
> are in refs/notes/public (or refs/notes or something not branch specific).
>
> Dev1 adds 100 notes to topic B, lets say half of them are obsolete due
> to rebases or whatever. Dev2 pulls A and updates their notes
> as well. Now Dev2 has acquired all the notes from Dev1 including the
> obsolete ones. So you have 100 commits, 100 blobs and all the new
> trees that go with them that the user was not interested in.
>
> Run this across 1000 users and you have a lot of cruft.
>
> Now, if instead we have a per-branch notes scheme, then you only get
> the cruft from the branches you were interested in. If you remove the
> history you could end up with no cruft because gc should handle it.
OK. But my point is that this is an incomplete solution. You can _still_
get cruft, and you _still_ have to deal with that cruft some other way.
So we will still end up having to implement something else. And I might
even be fine with a partial solution that helped some if it didn't come
with a cost, but I think the "notes stick to branches" behavior is
strictly worse.
> > If the latter, then I don't see how you've solved the push-pull and
> > merge problem (which you need history for).
>
> What git-fetch would have to do is say. This is a note. The remote
> sha is not the same as mine, i will treat this as a force and fetch the
> objects without checking history and then run a merge on the 2
> commits. The notes merge could have its own strategy that checked
> if an object exists before deciding to add a new item or delete a
> removed one. Then the user would only have to intervene if the
> notes where edited.
I don't like that because:
- the user is going to end up manually resolving merge conflicts for
things that _should_ have been fast forwards. But much worse, it's
going to be on content they may never even have seen before. How
will they decide which is which?
- how do you push notes? There's no opportunity to handle the merge
on the remote side. And you can't just pull, merge locally, and push
what is now a fast-forward, because there is no concept of
fast-forward without history.
- Suddenly pulling and pushing notes isn't just taken care of by the
usual ref transfer mechanisms. We have to implement a whole new
system.
> You are correct of course that it will just be wasted space. But I am
> concerned that it could end up being a lot of wasted space. I mean, what
> if every person who contributed to the kernel contributed note cruft. Users
What if every person who contributed to the kernel contributed history
cruft? It's really the same problem, and it is solved by people keeping
their trees clean (via rebase) and being picky about how data comes into
your tree (i.e., don't pull from people with cruft). I suspect Linus
wouldn't pull notes at all (and they wouldn't make it over patch
transmission anyway). But in a workflow that is pulling the notes, the
right time to clean up history is probably before publishing. That is,
you can rebase and clean up your notes history just before you push it
to somewhere public, just like you might clean up messy history.
> If you *really* don't think its something to be worried about then I
> am OK with that since you have a lot more experience with this, but it
> sounds hairy to me.
It is hairy, and I wish there were a better solution. But I think every
other option is much worse.
-Peff
^ permalink raw reply
* Re: [PATCH][RESEND] guilt: add option guilt.diffstat
From: Josef Jeff Sipek @ 2008-12-20 4:33 UTC (permalink / raw)
To: Wu Fengguang; +Cc: git@vger.kernel.org, Boyd Stephen Smith Jr.
In-Reply-To: <20081218112643.GA15416@localhost>
On Thu, Dec 18, 2008 at 07:26:43PM +0800, Wu Fengguang wrote:
> Introduce option guilt.diffstat so that we don't have to type
> "guilt refresh --diffstat" in its full form every time.
Applied.
Thanks,
Josef 'Jeff' Sipek.
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like
that.
- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] guilt doc: use literal paragraphs for example commands
From: Josef Jeff Sipek @ 2008-12-20 4:33 UTC (permalink / raw)
To: Wu Fengguang; +Cc: git@vger.kernel.org
In-Reply-To: <20081218113934.GA16171@localhost>
On Thu, Dec 18, 2008 at 07:39:34PM +0800, Wu Fengguang wrote:
> Display example commands verbatim by indenting the paragraphs.
Applied.
Thanks,
Josef 'Jeff' Sipek.
--
Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are, by
definition, not smart enough to debug it.
- Brian W. Kernighan
^ permalink raw reply
* Re: [PATCH 4/4] Add an expensive test for git-notes
From: Boyd Stephen Smith Jr. @ 2008-12-19 23:49 UTC (permalink / raw)
To: Git Mailing List; +Cc: Johannes Schindelin, Jeff King, Govind Salinas
In-Reply-To: <alpine.DEB.1.00.0812200035590.30769@pacific.mpi-cbg.de>
[-- Attachment #1: Type: text/plain, Size: 452 bytes --]
On Friday 2008 December 19 17:37:15 Johannes Schindelin wrote:
> + test_expect_success 'notes timing' "time_notes 100"
^^^
Probably should be ${count}.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] git-mergetool: properly handle "git mergetool -- filename"
From: David Aguilar @ 2008-12-20 1:01 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
Like many git commands, git-mergetool allows "--" to signal
the end of option processing. This adds a missing "shift"
statement so that this is correctly handled.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
git-mergetool.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 94187c3..d4078a6 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -296,6 +296,7 @@ do
esac
;;
--)
+ shift
break
;;
-*)
--
1.6.1.rc3.38.gec9f0
^ permalink raw reply related
* Re: [PATCH] fast-import: make tagger information optional
From: Shawn O. Pearce @ 2008-12-20 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Miklos Vajna, git, scott
In-Reply-To: <7vfxkj65y5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Even though newer Porcelain tools always record the tagger information
> when creating new tags, export/import pair should be able to faithfully
> reproduce ancient tag objects that lack tagger information.
>
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Thanks Junio.
Acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: [PATCH] fast-import: make tagger information optional
From: Miklos Vajna @ 2008-12-20 0:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Shawn O. Pearce, Johannes Schindelin, git, scott
In-Reply-To: <7vfxkj65y5.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 477 bytes --]
On Fri, Dec 19, 2008 at 04:33:38PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
> index 91b5ace..5a2aaf2 100755
> --- a/t/t9300-fast-import.sh
> +++ b/t/t9300-fast-import.sh
> @@ -56,6 +56,12 @@ M 644 :2 file2
> M 644 :3 file3
> M 755 :4 file4
>
> +tag series-A
> +from :5
> +data <<EOF
> +An annotated tag without an tagger
Minor nit: isn't this (here and later one more time) 'a tagger'?
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] SubmittingPatches: mention the usage of real name in Signed-off-by: lines
From: Miklos Vajna @ 2008-12-20 0:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, jidanni, git
In-Reply-To: <7vbpv765oc.fsf@gitster.siamese.dyndns.org>
Especially with something that is supposed to hopefully have some legal
value down the line if somebody starts making noises, it really would be
nice to have a real person to associate things with. Suggest this in the
SubmittingPatches document.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Dec 19, 2008 at 04:39:31PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> I would agree with the reasoning, but do we have to say "childish"
> just to
> be derogatory? I think that is counterproductive.
True.
Documentation/SubmittingPatches | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index f0295c6..ba07c8c 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -222,6 +222,9 @@ D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
+Also notice that a real name is used in the Signed-off-by: line. Please
+don't hide your real name.
+
Some people also put extra tags at the end.
"Acked-by:" says that the patch was reviewed by the person who
--
1.6.1.rc1.35.gae26e.dirty
^ permalink raw reply related
* Re: [PATCH] SubmittingPatches: mention the usage of real name in Signed-off-by: lines
From: Junio C Hamano @ 2008-12-20 0:39 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Nanako Shiraishi, jidanni, git
In-Reply-To: <1229732427-14740-1-git-send-email-vmiklos@frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> Especially with something that is supposed to hopefully have some legal
> value down the line if somebody starts making noises, it really would be
> nice to have a real person to associate things with.
I would agree with the reasoning, but do we have to say "childish" just to
be derogatory? I think that is counterproductive.
^ permalink raw reply
* Re: just can't live without a user.name
From: jidanni @ 2008-12-20 0:36 UTC (permalink / raw)
To: vmiklos; +Cc: git
In-Reply-To: <20081220000803.GK21154@genesis.frugalware.org>
MV> I said you can use utf-8 in the user.name field and showed you an example
But I want to use null or (my favorite string of) ASCII.
Anyway no program so far on UNIX broke with just
$ grep $USER /etc/passwd
jidanni:x:1000:1000:,,,:/home/jidanni:/bin/bash
except git.
^ permalink raw reply
* Re: [PATCH 1/2] gitweb: allow access to forks with strict_export
From: Jakub Narebski @ 2008-12-20 0:35 UTC (permalink / raw)
To: Matt McCutchen; +Cc: Junio C Hamano, git, Petr Baudis
In-Reply-To: <1229220398.3360.66.camel@mattlaptop2.local>
On Sun, 14 Dec 2008 03:06, Matt McCutchen napisał:
> On Sat, 2008-12-13 at 23:51 +0100, Jakub Narebski wrote:
> >
> > "no_hide" (currently "include_forks") allows us to _not_ passing this
> > parameter in other places than project_in_list(); undef is falsy.
>
> Right. That's why I made the current parameter $for_strict_export (so
> only project_in_list passes it) rather than the negation.
Still I think $for_strict_export is singularly _bad_ name for
a parameter. $no_hide or $show_all would be much, much better.
> > By the way, doesn't git_project_index and perhaps git_opml also need
> > this parameter passed to git_get_projects_list?
>
> Yes, now that you mention it, I suppose they should show forks, though
> not hidden repositories. Then git_get_projects_list can be called in
> three different modes: include everything (project_in_list), include
> forks but not hidden (git_get_project_index and git_opml), or include
> neither forks nor hidden (git_project_list). Should we have two
> separate parameters to git_get_projects_list or a single three-valued
> one?
By the way, I am not sure if your idea of "hidden projects" and projects
list (projects index) file.
We have two way of specifying list of projects. One is scanning
projectroot directory for something that looks like git repository,
the other is having projects list file with project paths and project
owners.
If you use projects list file, you can have projects which are in not
on project list, but are accessible in filesystem. Those projects
(repositories) are hidden, i.e. they are not visible on projects_list
page, but still you can access a project. If you want to have projects
which are not on list to be not accessible at all, and not only hidden,
you have to use $strict_export... using which makes access to repo
views a tiny bit slower (and _only_ slows down gitweb for when scanning
directories for projects).
But why would one _want_ projects which are not visible, but still
accessible; "hidden" projects? Moreso what you want, the three class
of projects inside $projectroot: visible, hidden, and not exported.
With newly added $export_auth_hook you can limit accessibility of
projects in other ways, for example using .htaccess control files of
Apache web server. Check gitweb/README (or gitweb/INSTALL) for
example.
> That raises another point. I was going to change git_get_projects_list
> so that forks of a hidden project that are not themselves hidden appear
> on the parent project's page but not in the main project list. This
> way, users who know about the parent project can navigate to the fork,
> but the fork does not give away the existence of the parent project by
> appearing in the main list. Then I guess git_project_index and git_opml
> should omit forks of hidden projects, meaning that some fork-checking
> still has to take place with "include forks" on but "include hidden"
> off. This will make git_get_projects_list somewhat more complex but not
> unmanageably so, and I do think it's the behavior we want.
>
> I will send an updated patch.
So you see that having explicitly hidden files have yet another
complication. I wonder if this is really worth it...
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH] fast-import: make tagger information optional
From: Junio C Hamano @ 2008-12-20 0:33 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Miklos Vajna, git, scott
In-Reply-To: <alpine.DEB.1.00.0812200059480.30769@pacific.mpi-cbg.de>
Even though newer Porcelain tools always record the tagger information
when creating new tags, export/import pair should be able to faithfully
reproduce ancient tag objects that lack tagger information.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* ... and corresponding patch to fast-import may look like this.
fast-import.c | 24 ++++++++++++++----------
t/t9300-fast-import.sh | 18 ++++++++++++++++++
2 files changed, 32 insertions(+), 10 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 201d4ff..d107896 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -2265,23 +2265,27 @@ static void parse_new_tag(void)
read_next_command();
/* tagger ... */
- if (prefixcmp(command_buf.buf, "tagger "))
- die("Expected tagger command, got %s", command_buf.buf);
- tagger = parse_ident(command_buf.buf + 7);
+ if (!prefixcmp(command_buf.buf, "tagger ")) {
+ tagger = parse_ident(command_buf.buf + 7);
+ read_next_command();
+ } else
+ tagger = NULL;
/* tag payload/message */
- read_next_command();
parse_data(&msg);
/* build the tag object */
strbuf_reset(&new_data);
+
strbuf_addf(&new_data,
- "object %s\n"
- "type %s\n"
- "tag %s\n"
- "tagger %s\n"
- "\n",
- sha1_to_hex(sha1), commit_type, t->name, tagger);
+ "object %s\n"
+ "type %s\n"
+ "tag %s\n",
+ sha1_to_hex(sha1), commit_type, t->name);
+ if (tagger)
+ strbuf_addf(&new_data,
+ "tagger %s\n", tagger);
+ strbuf_addch(&new_data, '\n');
strbuf_addbuf(&new_data, &msg);
free(tagger);
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 91b5ace..5a2aaf2 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -56,6 +56,12 @@ M 644 :2 file2
M 644 :3 file3
M 755 :4 file4
+tag series-A
+from :5
+data <<EOF
+An annotated tag without an tagger
+EOF
+
INPUT_END
test_expect_success \
'A: create pack from stdin' \
@@ -102,6 +108,18 @@ test_expect_success \
'git cat-file blob master:file4 >actual && test_cmp expect actual'
cat >expect <<EOF
+object $(git rev-parse refs/heads/master)
+type commit
+tag series-A
+
+An annotated tag without an tagger
+EOF
+test_expect_success 'A: verify tag/series-A' '
+ git cat-file tag tags/series-A >actual &&
+ test_cmp expect actual
+'
+
+cat >expect <<EOF
:2 `git rev-parse --verify master:file2`
:3 `git rev-parse --verify master:file3`
:4 `git rev-parse --verify master:file4`
--
1.6.1.rc3.48.g2724
^ permalink raw reply related
* [PATCH] SubmittingPatches: mention the usage of real name in Signed-off-by: lines
From: Miklos Vajna @ 2008-12-20 0:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, jidanni, git
In-Reply-To: <7vhc4z7oia.fsf@gitster.siamese.dyndns.org>
Especially with something that is supposed to hopefully have some legal
value down the line if somebody starts making noises, it really would be
nice to have a real person to associate things with. Suggest this in the
SubmittingPatches document.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
On Fri, Dec 19, 2008 at 03:07:25PM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> An earlier mistake does not justify adding new ones. Besides, I think
> ALASCM once revealed his "real name" on the list.
Ah, true ($gmane/7946). Then maybe something like this would be good to
have? The commit message is mostly copy&paste from Linus' message.
Documentation/SubmittingPatches | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index f0295c6..530aa25 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -222,6 +222,9 @@ D-C-O. Indeed you are encouraged to do so. Do not forget to
place an in-body "From: " line at the beginning to properly attribute
the change to its true author (see (2) above).
+Also notice that a real name is used in the Signed-off-by: line. Please
+don't be childish and don't hide your real name.
+
Some people also put extra tags at the end.
"Acked-by:" says that the patch was reviewed by the person who
--
1.6.1.rc1.35.gae26e.dirty
^ permalink raw reply related
* Re: just can't live without a user.name
From: Junio C Hamano @ 2008-12-20 0:18 UTC (permalink / raw)
To: Miklos Vajna; +Cc: jidanni, git
In-Reply-To: <20081220000803.GK21154@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Sat, Dec 20, 2008 at 07:20:56AM +0800, jidanni@jidanni.org wrote:
>> Actually it's all git's fault for not working if user.name is null or
>> unset.
>
> Please don't turn this thread into a flame.
Just pay attention to messages in which he says something that adds value
to the discussion, and simply ignore the rest.
^ permalink raw reply
* Re: just can't live without a user.name
From: Miklos Vajna @ 2008-12-20 0:08 UTC (permalink / raw)
To: jidanni; +Cc: nanako3, gitster, git
In-Reply-To: <87fxkjbvl3.fsf_-_@jidanni.org>
[-- Attachment #1: Type: text/plain, Size: 615 bytes --]
On Sat, Dec 20, 2008 at 07:20:56AM +0800, jidanni@jidanni.org wrote:
> Actually it's all git's fault for not working if user.name is null or
> unset.
Please don't turn this thread into a flame.
If I understand correctly, you said you hide your name because you can't
use your real name and using some limited ASCII replacement makes you
unhappy.
I said you can use utf-8 in the user.name field and showed you an
example about this.
Instead of replying to this, you just did not quote any parts of my
message, but started to talk about you don't want to show your real name
at all. What's the point of doing so?
[-- 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