* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Jeff King @ 2007-10-30 13:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git, Andy C
In-Reply-To: <7vlk9lm2e5.fsf@gitster.siamese.dyndns.org>
On Tue, Oct 30, 2007 at 01:29:22AM -0700, Junio C Hamano wrote:
> If it always gives the same results in practice, obviously
> nobody can even notice.
>
> However, merging this series to 'pu' breaks rebase-merge test
> t3402 among other things.
Yes, sorry, I meant to mention the test breakage in the cover letter
(which I think is just related to the size/score normalization). This is
not really meant for applying, but more for "this is taking me a lot
longer than I hoped, so here is what is happening and you might be
interested to comment." I'm not even sure it's pu material. :)
I will continue to refine it as I mentioned in the mail to Linus, but I
am open to suggestions.
-Peff
^ permalink raw reply
* [PATCH] Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example
From: Michael W. Olson @ 2007-10-30 13:53 UTC (permalink / raw)
To: git; +Cc: Michael W. Olson
---
Documentation/git-cvsexportcommit.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 4c8d1e6..c3922f9 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -73,7 +73,7 @@ Merge one patch into CVS::
$ export GIT_DIR=~/project/.git
$ cd ~/project_cvs_checkout
$ git-cvsexportcommit -v <commit-sha1>
-$ cvs commit -F .mgs <files>
+$ cvs commit -F .msg <files>
------------
Merge pending patches into CVS automatically -- only if you really know what you are doing::
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH 1/2] add throughput to progress display
From: Nicolas Pitre @ 2007-10-30 13:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0710300935330.21255@xanadu.home>
On Tue, 30 Oct 2007, Nicolas Pitre wrote:
> On Tue, 30 Oct 2007, Junio C Hamano wrote:
>
> > Very nice.
> >
> > I however wonder why this breaks t1004 when applied on top of
> > lt/rename topic.
>
> Well... sh*t happens.
>
> Could you please simply amend [PATCH 1/2] with the patch below:
Well that isn't enough. Please just scrap the whole thing as more
fundamental changes are needed. I'll send a new patch set when ready.
Nicolas
^ permalink raw reply
* Re: Missing MIME-headers in git-email-tool ..
From: Jeff King @ 2007-10-30 14:06 UTC (permalink / raw)
To: Matti Aarnio; +Cc: git
In-Reply-To: <20071030095338.GZ6372@mea-ext.zmailer.org>
On Tue, Oct 30, 2007 at 11:53:38AM +0200, Matti Aarnio wrote:
> The git-send-email does send posts without any sort of MIME labeling:
>
> From: / To: removed
>
> Subject: [PATCH 0/2] Blackfin I2C/TWI driver updates
> Date: Tue, 30 Oct 2007 17:33:15 +0800
> Message-Id: <1193736797-9005-1-git-send-email-bryan.wu@analog.com>
> X-Mailer: git-send-email 1.5.3.4
> Precedence: bulk
>
>
> which per MIME rules means that the message in question is equivalent
> to one with header labels:
>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=US-ASCII
> Content-Transfer-Encoding: 7bit
As Johannes explained, this happens only when there are no >7bit
characters in the email, so that interpretation is correct. Though I am
not opposed to sending those headers all the time, for clarity's sake.
> What would be a problem ? Some of us have names that are encoded
> in 8-bit form, and some receiving systems get all mighty upset when
> they receive unlabelled email carry 8-bit encoded texts.
> (Thanks to chinese and russian spammers..)
Then git-send-email should be generating the MIME headers if there are
8-bit characters. Can you produce a test case where the most recent
version of git-send-email it does not?
> Now if the git-send-email would add following three lines in all
> outgoing email headers, things would be 99% correct for a long time..
>
> MIME-Version: 1.0
> Content-Type: text/plain; charset=ISO-8859-15
> Content-Transfer-Encoding: 8BIT
No, this is just wrong. If git-send-email isn't adding headers when it
should to 8-bit output, then it's a bug. But papering over it with a
randomly chosen, possibly incorrect charset is not the right answer.
-Peff
^ permalink raw reply
* Re: Missing MIME-headers in git-email-tool ..
From: Jeff King @ 2007-10-30 14:09 UTC (permalink / raw)
To: Matti Aarnio; +Cc: git
In-Reply-To: <20071030140630.GC21342@coredump.intra.peff.net>
On Tue, Oct 30, 2007 at 10:06:30AM -0400, Jeff King wrote:
> > What would be a problem ? Some of us have names that are encoded
> > in 8-bit form, and some receiving systems get all mighty upset when
> > they receive unlabelled email carry 8-bit encoded texts.
> > (Thanks to chinese and russian spammers..)
>
> Then git-send-email should be generating the MIME headers if there are
> 8-bit characters. Can you produce a test case where the most recent
> version of git-send-email it does not?
Actually, btw, the code in question is from git-format-patch (it's just
that git-send-email doesn't add _any_ mime headers, as it assumes
git-format-patch either did it already, or none are needed).
-Peff
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Peter Karlsson @ 2007-10-30 13:34 UTC (permalink / raw)
To: Benoit SIGOURE; +Cc: git
In-Reply-To: <13D1D3DD-9652-4097-8364-DEF4F26540D3@lrde.epita.fr>
Benoit SIGOURE:
> I think you can use grafts do achieve this.
That seems to work, but the grafts list doesn't seem to propagate when I
push/pull/clone. Is it possible to get that to work?
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH] no longer install git-svnimport, move to contrib/examples
From: Gerrit Pape @ 2007-10-30 14:24 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <7vy7dpy8qf.fsf@gitster.siamese.dyndns.org>
On Fri, Oct 26, 2007 at 12:30:16PM -0700, Junio C Hamano wrote:
> Steven Grimm <koreth@midwinter.com> writes:
> > Johannes Schindelin wrote:
> >>> I'm not sure these are worth fixing, I'd rather suggest to drop
> >>> git-svnimport in favor of git-svn, and not installing it in future
> >>> versions.
> >>>
> >> I already proposed this. The outcome was... silent.
> >
> > Me too, and same reaction.
> >
> > So I vote we interpret that as, "No objections from anyone."
>
> Likewise.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
.gitignore | 1 -
Documentation/cmd-list.perl | 1 -
Makefile | 3 +--
contrib/completion/git-completion.bash | 1 -
.../examples/git-svnimport.perl | 0
.../examples}/git-svnimport.txt | 0
6 files changed, 1 insertions(+), 5 deletions(-)
rename git-svnimport.perl => contrib/examples/git-svnimport.perl (100%)
rename {Documentation => contrib/examples}/git-svnimport.txt (100%)
diff --git a/.gitignore b/.gitignore
index 62afef2..8670081 100644
--- a/.gitignore
+++ b/.gitignore
@@ -128,7 +128,6 @@ git-status
git-stripspace
git-submodule
git-svn
-git-svnimport
git-symbolic-ref
git-tag
git-tar-tree
diff --git a/Documentation/cmd-list.perl b/Documentation/cmd-list.perl
index 1061fd8..8d21d42 100755
--- a/Documentation/cmd-list.perl
+++ b/Documentation/cmd-list.perl
@@ -185,7 +185,6 @@ git-status mainporcelain
git-stripspace purehelpers
git-submodule mainporcelain
git-svn foreignscminterface
-git-svnimport foreignscminterface
git-symbolic-ref plumbingmanipulators
git-tag mainporcelain
git-tar-tree plumbinginterrogators
diff --git a/Makefile b/Makefile
index 72f5ef4..eb98d91 100644
--- a/Makefile
+++ b/Makefile
@@ -225,8 +225,7 @@ SCRIPT_SH = \
SCRIPT_PERL = \
git-add--interactive.perl \
git-archimport.perl git-cvsimport.perl git-relink.perl \
- git-cvsserver.perl git-remote.perl \
- git-svnimport.perl git-cvsexportcommit.perl \
+ git-cvsserver.perl git-remote.perl git-cvsexportcommit.perl \
git-send-email.perl git-svn.perl
SCRIPTS = $(patsubst %.sh,%,$(SCRIPT_SH)) \
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index e760930..599b2fc 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -346,7 +346,6 @@ __git_commands ()
ssh-*) : transport;;
stripspace) : plumbing;;
svn) : import export;;
- svnimport) : import;;
symbolic-ref) : plumbing;;
tar-tree) : deprecated;;
unpack-file) : plumbing;;
diff --git a/git-svnimport.perl b/contrib/examples/git-svnimport.perl
similarity index 100%
rename from git-svnimport.perl
rename to contrib/examples/git-svnimport.perl
diff --git a/Documentation/git-svnimport.txt b/contrib/examples/git-svnimport.txt
similarity index 100%
rename from Documentation/git-svnimport.txt
rename to contrib/examples/git-svnimport.txt
--
1.5.3.4
^ permalink raw reply related
* Re: Recording merges after repo conversion
From: Lars Hjemli @ 2007-10-30 14:29 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.62.0710301433150.652@perkele.intern.softwolves.pp.se>
On 10/30/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
> Benoit SIGOURE:
>
> > I think you can use grafts do achieve this.
>
> That seems to work, but the grafts list doesn't seem to propagate when I
> push/pull/clone. Is it possible to get that to work?
>
No, the grafts file is purely local. To achieve your goal, you'd have
to 'git filter-branch' before pushing/cloning. But beware: this _will_
rewrite your current branch(es).
--
larsh
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 14:59 UTC (permalink / raw)
To: Tom Prince
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071030053732.GA16963@hermes.priv>
On Tue, 30 Oct 2007, Tom Prince wrote:
> > The push url is generally written as
> >
> > repo.or.cz:/srv/git/linux-2.6/linux-acpi-2.6/ibm-acpi-2.6.git
> >
> > Tough.
>
> But gitweb (on git.kernel.org and repo.or.cz) both give git:// locators.
Yes, for anonymous pulling.
The thing is, git takes something much more extended than a "RFC url".
We use pathnames. Not a "quoted mess". Regular, bog-standard, normal unix
pathnames.
On Windows, I assume (and hope) that git uses the native-style Windows
pathnames, and you can do "git pull d:\system\ugh" if you want to.
And I think we should care a whole lot about interacting with the *user*
and actual programs that git shares code with, than interacting with some
idiotic RFC that has absolutely zero to do with us, regardless of whether
we use the name "url" or not.
For example, the reason we use "host:/path" for pushing over ssh (and
pulling, for that matter), is that that's the same syntax that scp uses.
It's a natural fit. And I hope to God nobody seriously argues that we
shouldn't use regular pathnames on the local disk?
> > Quick! WHO THE F*CK CARES?
[ Btw, sorry for the french. I blame being tired and ina bad mood, but I
also blame the fact that I absolutely *detest* arguments based on
standards. If you cannot back it up with a real usage scenario, you
shouldn't even mention the standard ]
> So, how should git deal with
>
> git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
The way it has always cared. Git itself does no quoting what-so-ever
(except for the *argument* quoting etc that it needs).
Now, the *transport* back-end may end up quoting it, of course, the same
way it may end up using some random protocol. The user shouldn't care
about the implementation details!
In the case of the git transport, there is no quoting even by the
transport protocol. In the case of http, libcurl would hopefully quote for
us.
> compared to
>
> http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
No difference, what-so-ever, that I can see. Git doesn't quote it.
Notice how the fact that we use http:// doesn't actually mean that you can
feed the result to a web browser anyway? It's not like you get a "link"
that git follows. You get a name.
Yes, you can try to "co-locate" things so that something smart
disambiguates (maybe have an "index.html" file, so a web browser gets a
gitweb page, and git gets the raw data). But even then, notice how even
web browser will do the quoting for you: try
firefox "http://www.google.com/search?q=Html spaces"
just for fun.
Notice? The thing is, "strict RFC following" makes no sense:
- the git syntax is (and HAS TO BE to be user friendly) a real extension
on any "strict RFC URL" anyway, since it is a lot more important to
interact well with normal unix tools (ie use regular filenames, and use
the same syntax as "cp", "mv" and "find" etc uses!)
Ergo: we cannot and MUST NOT care about the "URL RFC" too deeply
anyway.
-
> Not that I care, but git should probably handle things consistently.
Git has been, and *is* entirely consistent. It uses convenient repo names.
If you don't want to call them url's, then call them "repository name".
Call them whatever. But they are 100% obvious, even if there are multiple
forms of them (and *none* of the forms do any quoting at all):
- <remote shorthand> ("origin")
- <path> ("../git.git")
- <host>:<path> ("master.kernel.org:/pub/scm/...")
- <protocol>://<host>/<path> ("git://repo.or.cz/...")
See? We may not follow RFC's, but we follow "easy to use".
And btw, that's really much much MUCH more important. It's why the git
config file is in a "ini"-like format. It's readable. It's not the insane
RFC crap that would result if somebody had decided that standards are more
important than being sane.
Linus
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Johannes Schindelin @ 2007-10-30 15:05 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.62.0710301433150.652@perkele.intern.softwolves.pp.se>
Hi,
On Tue, 30 Oct 2007, Peter Karlsson wrote:
> Benoit SIGOURE:
>
> > I think you can use grafts do achieve this.
>
> That seems to work, but the grafts list doesn't seem to propagate when I
> push/pull/clone. Is it possible to get that to work?
No. Use filter-branch, and publish the cleaned up history (possibly as a
new branch/repo).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Linus Torvalds @ 2007-10-30 15:38 UTC (permalink / raw)
To: Jeff King; +Cc: git, Andy C, Junio C Hamano
In-Reply-To: <20071030134355.GA21342@coredump.intra.peff.net>
On Tue, 30 Oct 2007, Jeff King wrote:
>
> On Mon, Oct 29, 2007 at 10:06:11PM -0700, Linus Torvalds wrote:
>
> > Have you compared the results? IOW, does it find the *same* renames?
>
> From my limited testing, it generally finds the same pairs. However,
> there are a number of renames that it _doesn't_ find, because they are
> composed of "uninteresting" lines, dropping them below the minimum
> score. Try (in git.git):
>
> git-show --raw -M -l0 :/'Big tool rename'
>
> with the old and new code. Pairs like Documentation/git-add-script.txt
> -> Documentation/git-add.txt are not found, because the file is composed
> almost entirely of boilerplate.
Ok, that does imply to me that we cannot just drop boilerplate text,
because the fact is, lots of files contain boilerplate, but people still
think they are "similar".
We do actually depend on the similarity analysis being "good" - because it
matters a lot for things like merging. The old code was actually very
careful indeed, and while it didn't care about things like the exact
*ordering* of lines (ie moving functions around in the same file resulted
in the *exact* same fingerprint for the file!) it cared about everything
else.
> Moving the size normalization into the similarity engine should probably
> fix that, and will let us compare old and new results more accurately.
> I'll try to work on that.
Hmm. I hope that is sufficient. But I suspect it may well not be.
Especially since you ignore boiler-plate lines for *some* files but not
others (ie it depends on which file you happen to find it in first).
Linus
^ permalink raw reply
* Re: remote#branch
From: Tom Prince @ 2007-10-30 16:02 UTC (permalink / raw)
To: Linus Torvalds
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710300738550.30120@woody.linux-foundation.org>
On Tue, Oct 30, 2007 at 07:59:45AM -0700, Linus Torvalds wrote:
> > Not that I care, but git should probably handle things consistently.
>
> Git has been, and *is* entirely consistent. It uses convenient repo names.
> If you don't want to call them url's, then call them "repository name".
> Call them whatever. But they are 100% obvious, even if there are multiple
> forms of them (and *none* of the forms do any quoting at all):
>
> - <remote shorthand> ("origin")
> - <path> ("../git.git")
> - <host>:<path> ("master.kernel.org:/pub/scm/...")
> - <protocol>://<host>/<path> ("git://repo.or.cz/...")
>
> See? We may not follow RFC's, but we follow "easy to use".
Well, only the last one actually looks like a URL, so that is the only this
discussion is about. I don't think anyone is suggesting that the first three
be changed at all. So, to use your terminology, git has a variety of ways to
specify a repo name, one of which happens to be a URL (or looks like one). The
suggestion is that we should make that way (and only that way) behave like a
RFC URL.
And git should be consistent with web browsers, automatically quoting things
it gets passed. I think the only point of contention is probably how to deal
with URLs that git receives that are already quoted.
1. We ignore the quoting and re-encode everything for the http transport.
2. We honour the encoding and decode everything for the git transport.
3. We handle git:// and http:// different, so that the three git:// URLs below
refer to different repositories, while the three http:// URLs give refer to
the same repository.
> > git://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > git://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
>
> > http://repo.or.cz/linux-2.6/linux acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux+acpi-2.6/ibm-acpi-2.6.git
> > http://repo.or.cz/linux-2.6/linux%20acpi-2.6/ibm-acpi-2.6.git
The third possibility is probably what we do now, which is why I am suggesting
git is inconsistent. The first will fall down when using a repository that is
colocated, and somebody copies a URL from the web browsers location bar (which
will be properly encoded). Which leaves the second.
Tom
^ permalink raw reply
* Re: [PATCH 0/4] Build in some more things
From: Daniel Barkalow @ 2007-10-30 16:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzly1nhmn.fsf@gitster.siamese.dyndns.org>
On Tue, 30 Oct 2007, Junio C Hamano wrote:
> I've merged this to 'pu', but honestly speaking, the conflicts
> are geting a bit more "interesting" than I care to keep
> repeating even with help from rerere, with four people
> simultaneously touching the neighbouring code in their topics.
I mostly actually care about [PATCH 1/4] which is also probably the
easiest to validate (since it really shouldn't change anything that
matters except to make things work in more cases). If I could get that in
early, I'd be fine with pushing the rest off until other people are out of
that code. The reason I care about 1/4 is that it also sets up an
extensive patch to make the fetch side of transport use the same git
connection for getting the initial list of remote refs and for fetching
their content (still with a second connection for auto-following tags,
since I couldn't figure out how to request more content after examining
some fetched content); this patch miraculously doesn't seem to
significantly conflict with anything currently in pu, and actually
provides a user-visible benefit (ssh transport with no special
infrastructure doesn't require typing the password multiple times for a
single logical operation most of the time).
On the other hand, [PATCH 2/4] might be worth floating earlier in pu,
since its conflicts are to simply remove all of the code that the other
patches update (since that code duplicates code in transport.c that can be
used instead).
For the builtin-send-pack stuff, I might as well redo the same logical
changes to the code once it settles down, since the edit sequence for 3/4
is really not all that well represented by diff, being very nearly "rename
a bunch of static globals; mark a bunch of things const; move a
function call down; split a function in half", and I can just redo that
after all the other changes.
> Topics involved are:
>
> ** db/remote-builtin (Mon Oct 29 22:03:42 2007 -0400) 4 commits
> . Use built-in send-pack.
> . Build-in send-pack, with an API for other programs to call.
> . Build-in peek-remote, using transport infrastructure.
> . Miscellaneous const changes and utilities
>
> * jk/send-pack (Thu Oct 18 02:17:46 2007 -0400) 2 commits
> + t5516: test update of local refs on push
> + send-pack: don't update tracking refs on error
>
> * js/forkexec (Fri Oct 19 21:48:06 2007 +0200)
> + Use start_command() in git_connect() instead of explicit
> fork/exec.
> + Change git_connect() to return a struct child_process instead of a
> pid_t.
>
> ** sp/push-refspec (Sun Oct 28 18:46:21 2007 +0100)
> . push: teach push to pass --verbose option to transport layer
> . push: use same rules as git-rev-parse to resolve refspecs
> . add ref_abbrev_matches_full_with_rev_parse_rules() comparing
> abbrev with full ref name
> . rename ref_matches_abbrev() to
> ref_abbrev_matches_full_with_fetch_rules()
>
> Could you please check the result after I push it out?
I agree with all of the conflict resolutions, although I didn't make sure
that parts that didn't get conflicts merged correctly (but, if it builds,
it's almost certainly right).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 0/4] Build in some more things
From: Daniel Barkalow @ 2007-10-30 16:49 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, git
In-Reply-To: <4726DC3D.2030202@viscovery.net>
On Tue, 30 Oct 2007, Johannes Sixt wrote:
> Daniel Barkalow schrieb:
> > The main effect of this series is removing the fork/exec from pushing via
> > the git protocol (aside from the later fork/exec in connect.c of course).
> >
> > It also heads off some tempting transport-related fetch bugs, which I will
> > not introduce in a later patch.
> >
> > * Miscellaneous const changes and utilities
> > Adds two small utility functions, and marks a bunch of stuff as const; the
> > const stuff is to keep builtin-fetch from getting messed up without a
> > warning, because it wants some lists not to change.
> >
> > * Build-in peek-remote, using transport infrastructure.
> > * Build-in send-pack, with an API for other programs to call.
> > * Use built-in send-pack.
>
> I assume this goes on top of current master or db/fetch-pack. The patches have
> some conflicts with js/forkexec (nothing serious, though). Maybe it makes
> sense to rebase on top of that.
Current master. As I said to Junio a moment ago (and forgot to cc you,
oops), I think 1/4 should go before js/forkexec, being trivial, and 2/4
should also, since it simply removes duplicate code that js/forkexec
updates; I should redo 3/4 after the code settles down, and 4/4 is trivial
but depends on 3/4.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 17:39 UTC (permalink / raw)
To: Tom Prince
Cc: Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071030160232.GB2640@hermes.priv>
On Tue, 30 Oct 2007, Tom Prince wrote:
> >
> > - <remote shorthand> ("origin")
> > - <path> ("../git.git")
> > - <host>:<path> ("master.kernel.org:/pub/scm/...")
> > - <protocol>://<host>/<path> ("git://repo.or.cz/...")
> >
> > See? We may not follow RFC's, but we follow "easy to use".
>
> Well, only the last one actually looks like a URL, so that is the only this
> discussion is about.
NO.
The thing is, we'd be much better off being consistent with OURSELVES than
with something else!
Nobody cares about git being consistent with a web browser. There is
nothing in common.
But I *do* care about git being consistent with itself. If I do
git clone /some/directory
and then decide that I want to generate a new pack and change it into
git clone file:///some/directory
I don't want to have to re-write the thing to quote differently!
The same very much goes for a path like
git://git.kernel.org/<path>
vs
master.kernel.org:<path>
because I will use the two interchangably. They *are* the same address,
except:
- the "git://" protocol is a bit faster, since the ssh connection
overhead is actually big enough to be quite noticeable.
- but I often use the master.kernel.org:<path> thing because there's a
mirroring delay that means that accessing it directly is sometimes
preferable.
See? THAT is where we need to be consistent: with our own paths!
[ And yes, I literally really do switch things around exactly like that
between ssh accesses and the git:// protocol. That was not a made-up
example, but real usage! ]
In contrast, nobody has _ever_ given a real technical reason to care about
the Web URL RFC at all.
Really. It's that simple: if you cannot argue for something without
pointing to an irrelevant standard, you really shouldn't argue for it in
the first place.
People who make decisions based on "it's a standard" make *sub*standard
decisions. The fact is, most standards are not worth even using as toilet
paper, because they were designed by some committee that wanted to reach
"consensus". That's just crap.
Linus
^ permalink raw reply
* Re: remote#branch
From: Matthieu Moy @ 2007-10-30 17:49 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710301037120.30120@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> Nobody cares about git being consistent with a web browser.
Why do you keep talking about web browser?
URLs are _not_ a web-browser thing. A web browser is just _one_
example of program which uses URLs.
--
Matthieu
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 17:58 UTC (permalink / raw)
To: Matthieu Moy
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <vpq8x5kh4rr.fsf@bauges.imag.fr>
On Tue, 30 Oct 2007, Matthieu Moy wrote:
>
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > Nobody cares about git being consistent with a web browser.
>
> Why do you keep talking about web browser?
>
> URLs are _not_ a web-browser thing. A web browser is just _one_
> example of program which uses URLs.
I keep talking about a web browser, because THE ONLY POINT of following a
standard is to interoperate.
So if you cannot find something to interoperate with, why the hell would
you care about the standard?
So here's a question: why do people bother to quote irrelevant RFC's?
Following those RFC's would make git not interoperate WITH ITSELF, and use
illogically different formats for the same things.
So if you want to make that RFC have any relevance what-so-ever, then show
some interoperability issue. Which is why I'm bringing up a web browser:
that interop issue simply *does*not*exist*.
Why is that so hard to understand?
Linus
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Daniel Barkalow @ 2007-10-30 18:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git
In-Reply-To: <7vfxztm2dx.fsf@gitster.siamese.dyndns.org>
On Tue, 30 Oct 2007, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
> > git push now allows you pushing a couple of branches that have
> > advanced, while ignoring all branches that have no local changes,
> > but are lagging behind their matching remote refs. This is done
> > without reporting errors.
> >
> > Thanks to Junio C. Hamano <gitster@pobox.com> for suggesting to
> > report in the summary that refs have been ignored.
>
> I do not think this is a good idea at all. Furthermore, I never
> suggested anything about summary. You are robbing the
> information from the pusher which ones are pushed and which ones
> are left behind.
I think this case should be a warning rather than an error, though. It is
certainly true that the user isn't intending to update those remote refs,
because there is no local change to update them with. And it is also true
that those local refs being stale is no impediment to updating the refs
which are not stale, which is what the user does intend to do. I can't see
a workflow which would be hurt by this change, because we know that, if
the user follows the instructions and then tries the push again, it will
have no effect.
If the concern is robbing the user of information, we should simply
provide the information, rather than interrupting the user's work to make
them act on the information before completing the essentially independant
operation they're attempting.
In any case, it's misleading to suggest that the user "pull first",
because we know that there would be no effect to pushing again after
merging. In this case, it would be more accurate to suggest that the user
"pull instead". Perhaps the message should be
"%s: nothing to push to %s, but you are not up-to-date and may want to
pull"
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] gitweb : disambiguate heads and tags withs the same name
From: Junio C Hamano @ 2007-10-30 18:19 UTC (permalink / raw)
To: Guillaume Seguin; +Cc: pasky, git
In-Reply-To: <e877c31c0710280612l5d783ab0o50ce00c70b3311db@mail.gmail.com>
"Guillaume Seguin" <guillaume@segu.in> writes:
> Avoid wrong disambiguation that would link logs/trees of tags and heads which
> share the same name to the same page, leading to a disambiguation that would
> prefer the tag, thus making it impossible to access the corresponding
> head log and
> tree without hacking the url by hand.
>
> ---
> gitweb/gitweb.perl | 14 ++++++++------
> 1 files changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 48e21da..f918c00 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -3534,6 +3534,7 @@ sub git_tags_body {
> for (my $i = $from; $i <= $to; $i++) {
> my $entry = $taglist->[$i];
> my %tag = %$entry;
> + my $name = "refs/tags/$tag{'name'}";
> my $comment = $tag{'subject'};
> my $comment_short;
> if (defined $comment) {
> @@ -3570,8 +3571,8 @@ sub git_tags_body {
> "<td class=\"link\">" . " | " .
> $cgi->a({-href => href(action=>$tag{'reftype'},
> hash=>$tag{'refid'})}, $tag{'reftype'});
> if ($tag{'reftype'} eq "commit") {
> - print " | " . $cgi->a({-href => href(action=>"shortlog",
> hash=>$tag{'name'})}, "shortlog") .
> - " | " . $cgi->a({-href => href(action=>"log",
> hash=>$tag{'name'})}, "log");
> + print " | " . $cgi->a({-href => href(action=>"shortlog",
> hash=>$name)}, "shortlog") .
> ...
Just in case anybody is wondering, the patch is whitespace
mangled and lacks a sign-off.
I suspect what the patch does may be a good idea, although I
haven't followed the existing code closely to verify it.
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 18:19 UTC (permalink / raw)
To: Matthieu Moy
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710301056070.30120@woody.linux-foundation.org>
On Tue, 30 Oct 2007, Linus Torvalds wrote:
>
> So if you want to make that RFC have any relevance what-so-ever, then show
> some interoperability issue. Which is why I'm bringing up a web browser:
> that interop issue simply *does*not*exist*.
Btw, the reason I care is that the whole ".. but it's a standard" thinking
really is dangerous. It's how you create absolute and utter crap.
It's why I have also brought up XML in this discussion, because XML is a
classic example of something where this ".. but it's a standard" thinking
has resulted in really bad solutions. It's pushed as a way to
"interoperate", but then, since everybody does different things, the only
thing you can actually interoperate with is by having a common parsing
library for a REALLY HORRIBLY BAD FORMAT!
The same is true of a URL. What is there to interoperate with? The whole
(and only) point of the git remote URL is to point git to a different git
repository. There's no other reason to use it. So the only possible case
we care about interoperability is with other git uses.
And those other git uses are not RFC1738-quoted, are they?
Linus
^ permalink raw reply
* Re: [BUG] remote.c/match_explicit() ... NULL pointer dereferenciation (git 1.5.3.4)
From: Junio C Hamano @ 2007-10-30 18:30 UTC (permalink / raw)
To: Melchior FRANZ; +Cc: git, spearce
In-Reply-To: <200710301144.32528@rk-nord.at>
Subject: Prevent send-pack from segfaulting (backport from 'master')
4491e62ae932d5774f628d1bd3be663c11058a73 (Prevent send-pack from
segfaulting when a branch doesn't match)
If we can't find a source match, and we have no destination, we
need to abort the match function early before we try to match
the destination against the remote.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Thanks. Shawn fixed it on the 'master' side but 'maint' is
still using the old code.
remote.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/remote.c b/remote.c
index cdbbdcb..9a88917 100644
--- a/remote.c
+++ b/remote.c
@@ -504,8 +504,11 @@ static int match_explicit(struct ref *src, struct ref *dst,
if (!matched_src)
errs = 1;
- if (dst_value == NULL)
+ if (!dst_value) {
+ if (!matched_src)
+ return errs;
dst_value = matched_src->name;
+ }
switch (count_refspec_match(dst_value, dst, &matched_dst)) {
case 1:
^ permalink raw reply related
* Re: git-merge: inconsistent manual page.
From: Junio C Hamano @ 2007-10-30 18:39 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <fg7b6o$k1f$1@ger.gmane.org>
Sergei Organov <osv@javad.com> writes:
> git-merge has inconsistent manual page:
>
> 1. In the SYNOPSIS, there is [-m <msg>], but OPTIONS section lacks it.
> The latter has just description of <msg>, suggesting it could be
> used without -m, but SYNOPSIS doesn't reflect this.
This is not quite right, I am afraid. "git merge" used to take
its parameters in quite an exotic order, and we still do support
it as we do not break people's existing setups:
git-merge "$message" HEAD $list_of_merged_refs
where the second parameter is always HEAD. This is the only
form that accepts the message without -m (see ll.230- in the
git-merge script).
But we do not _want_ to advertise this funny syntax. Humans and
newly written scripts should express the above as:
git merge -m "$message" $list_of_merged_refs
> BTW, git-merge options are described in
> Documentation/merge-options.txt that is also used fot git-pull
> options, and it's not clear for me if git-pull supports [-m
> <msg>]. Does it?
It shouldn't; the merge message is prepared by git-pull to
describe what got merged from where for you (see the last few
lines in the git-pull script).
> 2. In the SYNOPSIS, there is no <head> that is described in the
> OPTIONS.
See above. We do not want to advertise the crazy syntax.
^ permalink raw reply
* Re: [PATCH] Documentation/git-cvsexportcommit.txt: s/mgs/msg/ in example
From: Junio C Hamano @ 2007-10-30 18:39 UTC (permalink / raw)
To: Michael W. Olson; +Cc: git
In-Reply-To: <1193752427-21280-1-git-send-email-mwolson@gnu.org>
Thanks.
^ permalink raw reply
* Re: git-merge: inconsistent manual page.
From: Junio C Hamano @ 2007-10-30 18:54 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <7vsl3sla5q.fsf@gitster.siamese.dyndns.org>
Subject: git-merge: document but discourage the historical syntax
Historically "git merge" took its command line arguments in a
rather strange order. Document the historical syntax, and also
document clearly that it is not encouraged in new scripts.
There is no reason to deprecate the historical syntax, as the
current code can sanely tell which syntax the caller is using,
and existing scripts by people do use the historical syntax.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> See above. We do not want to advertise the crazy syntax.
By the way, I kept saying "crazy" above, but the thing is that
when Linus did that "crazy" syntax, it was not crazy at all.
Simply it did not matter, as nobody was supposed to use "git
merge" from the command line.
Instead, when merging a local branch, you would just have said:
$ git pull . $my_other_branch
It became a "crazy historical syntax" only after people started
talking about using it from the command line, giving it other
command line options. And at that point, we introduced -m flag
and stopped requiring the second token 'HEAD'.
With that in mind, this might be a better alternative.
Documentation/git-merge.txt | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index bca4212..a056b40 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -11,6 +11,7 @@ SYNOPSIS
[verse]
'git-merge' [-n] [--summary] [--no-commit] [--squash] [-s <strategy>]...
[-m <msg>] <remote> <remote>...
+'git-merge' <msg> HEAD <remote>...
DESCRIPTION
-----------
@@ -43,6 +44,11 @@ If you tried a merge which resulted in a complex conflicts and
would want to start over, you can recover with
gitlink:git-reset[1].
+The second syntax (<msg> `HEAD` <remote>) is supported for
+historical reasons. Do not use it from the command line or in
+new scripts.
+
+
CONFIGURATION
-------------
^ permalink raw reply related
* [PATCH 0/5] more progress display stuff
From: Nicolas Pitre @ 2007-10-30 18:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This is the result of some changes and cleanup I did to nicely support
progress with throughput display, and avoid those random crashes the
previous patches introduced. All tests are OK now after every patch.
This is meant to replace my latest 2 patches currently in pu.
Nicolas
^ 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