* Re: Recording merges after repo conversion
From: Lars Hjemli @ 2007-10-30 21:46 UTC (permalink / raw)
To: Peter Karlsson; +Cc: Benoit SIGOURE, git
In-Reply-To: <Pine.LNX.4.62.0710302204590.6976@perkele.intern.softwolves.pp.se>
On Oct 30, 2007 10:06 PM, Peter Karlsson <peter@softwolves.pp.se> wrote:
> Lars Hjemli:
>
> > No, the grafts file is purely local.
>
> Hmm, any chance that will change in a future version?
Not likely
>
> > To achieve your goal, you'd have to 'git filter-branch' before
> > pushing/cloning. But beware: this _will_ rewrite your current branch(es).
>
> Ouch. I'll have to think about whether I want to do that, then...
Well, it isn't dangerous, but if someone has already cloned your repo
_and_ commited local changes they'll need to rebase their work onto
the new branch(es). Basically, you'll want to inform these people that
you're going to rewrite the branches.
--
larsh
^ permalink raw reply
* Re: remote#branch
From: Pascal Obry @ 2007-10-30 19:18 UTC (permalink / raw)
To: Linus Torvalds
Cc: Matthieu Moy, 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>
Linus Torvalds a écrit :
> I keep talking about a web browser, because THE ONLY POINT of following a
> standard is to interoperate.
Yes, and since URLs are not used for web browser only I do not see the
point to concentrate all this discussion about a single possible usage.
> Why is that so hard to understand?
I'm thinking alike :)
Pascal;
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Robin Rosenberg @ 2007-10-30 21:44 UTC (permalink / raw)
To: Mike Snitzer
Cc: Michael Haggerty, Eyvind Bernhardsen, Thomas Pasch, git,
Jan Wielemaker, Gerald (Jerry) Carter, dev
In-Reply-To: <170fa0d20710301306o6b3798f9k72615eb811d871f2@mail.gmail.com>
tisdag 30 oktober 2007 skrev Mike Snitzer:
> On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:
> ...
> >
> > Thanks for making cvs2svn the best CVS-to-git conversion tool :) Now
> > if it would only support incremental importing...
>
> Michael,
>
> I second this question: is there any chance incremental importing will
> be implemented in cvs2svn?
>
> I've not used cvs2svn much and when I did it was for svn not git; but
> given that git-cvsimport is known to mess up your git repo (as Eyvind
> pointed out earlier) there doesn't appear to be any reliable tools to
> allow for incrementally importing from cvs to git.
>
> Are others using a tool for reliably importing from cvs to git?
I use fromcvs which is *very* fast, and quite memory conservative compared to
the others and seems reliable so far (six months). It probably breaks on
exotic variants of branches though, but I don't have those / don't care about
them.
Do not push into the same repo fromcvs works on. I don't understand why, but I
pushed once and *poof* the conversion went bad.
Drawbacks, more dependencies and access to the rcs files is required and tags
are not converted.
-- robin
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Mike Snitzer @ 2007-10-30 21:15 UTC (permalink / raw)
To: Michael Haggerty
Cc: Eyvind Bernhardsen, Thomas Pasch, git, Jan Wielemaker,
Gerald (Jerry) Carter, dev
In-Reply-To: <170fa0d20710301306o6b3798f9k72615eb811d871f2@mail.gmail.com>
On 10/30/07, Mike Snitzer <snitzer@gmail.com> wrote:
> On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:
> ...
> >
> > Thanks for making cvs2svn the best CVS-to-git conversion tool :) Now
> > if it would only support incremental importing...
>
> Michael,
>
> I second this question: is there any chance incremental importing will
> be implemented in cvs2svn?
>
> I've not used cvs2svn much and when I did it was for svn not git; but
> given that git-cvsimport is known to mess up your git repo (as Eyvind
> pointed out earlier) there doesn't appear to be any reliable tools to
> allow for incrementally importing from cvs to git.
>
> Are others using a tool for reliably importing from cvs to git?
After reading the fairly recent "cvs2svn conversion directly to git
ready for experimentation" thread it is clear that its doable but
hasn't been done (seeing as you were looking for volunteers to do it).
Sorry for the noise,
Mike
^ permalink raw reply
* Re: Recording merges after repo conversion
From: Peter Karlsson @ 2007-10-30 21:06 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Benoit SIGOURE, git
In-Reply-To: <8c5c35580710300729t4a7b375dud01253d9b4ef7196@mail.gmail.com>
Lars Hjemli:
> No, the grafts file is purely local.
Hmm, any chance that will change in a future version?
> To achieve your goal, you'd have to 'git filter-branch' before
> pushing/cloning. But beware: this _will_ rewrite your current branch(es).
Ouch. I'll have to think about whether I want to do that, then...
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* [PATCH 7/5] add throughput display to git-push
From: Nicolas Pitre @ 2007-10-30 21:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.LFD.0.9999.0710301535160.21255@xanadu.home>
This one triggers only when git-pack-objects is called with
--all-progress and --stdout which is the combination used by
git-push.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
builtin-pack-objects.c | 2 +-
csum-file.c | 8 ++++++++
csum-file.h | 4 ++++
3 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 52a26a2..25ec65d 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -606,7 +606,7 @@ static void write_pack_file(void)
char *pack_tmp_name = NULL;
if (pack_to_stdout) {
- f = sha1fd(1, "<stdout>");
+ f = sha1fd_throughput(1, "<stdout>", progress_state);
} else {
char tmpname[PATH_MAX];
int fd;
diff --git a/csum-file.c b/csum-file.c
index 9929991..3729e73 100644
--- a/csum-file.c
+++ b/csum-file.c
@@ -8,6 +8,7 @@
* able to verify hasn't been messed with afterwards.
*/
#include "cache.h"
+#include "progress.h"
#include "csum-file.h"
static void sha1flush(struct sha1file *f, unsigned int count)
@@ -17,6 +18,7 @@ static void sha1flush(struct sha1file *f, unsigned int count)
for (;;) {
int ret = xwrite(f->fd, buf, count);
if (ret > 0) {
+ display_throughput(f->tp, ret);
buf = (char *) buf + ret;
count -= ret;
if (count)
@@ -80,6 +82,11 @@ int sha1write(struct sha1file *f, void *buf, unsigned int count)
struct sha1file *sha1fd(int fd, const char *name)
{
+ return sha1fd_throughput(fd, name, NULL);
+}
+
+struct sha1file *sha1fd_throughput(int fd, const char *name, struct progress *tp)
+{
struct sha1file *f;
unsigned len;
@@ -94,6 +101,7 @@ struct sha1file *sha1fd(int fd, const char *name)
f->fd = fd;
f->error = 0;
f->offset = 0;
+ f->tp = tp;
f->do_crc = 0;
SHA1_Init(&f->ctx);
return f;
diff --git a/csum-file.h b/csum-file.h
index c3c792f..4d1b231 100644
--- a/csum-file.h
+++ b/csum-file.h
@@ -1,11 +1,14 @@
#ifndef CSUM_FILE_H
#define CSUM_FILE_H
+struct progress;
+
/* A SHA1-protected file */
struct sha1file {
int fd, error;
unsigned int offset, namelen;
SHA_CTX ctx;
+ struct progress *tp;
char name[PATH_MAX];
int do_crc;
uint32_t crc32;
@@ -13,6 +16,7 @@ struct sha1file {
};
extern struct sha1file *sha1fd(int fd, const char *name);
+extern struct sha1file *sha1fd_throughput(int fd, const char *name, struct progress *tp);
extern int sha1close(struct sha1file *, unsigned char *, int);
extern int sha1write(struct sha1file *, void *, unsigned int);
extern void crc32_begin(struct sha1file *);
^ permalink raw reply related
* Re: [GIT-GUI PATCH 2/3] po2msg: ignore untranslated messages
From: Christian Stimming @ 2007-10-30 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, spearce, git
In-Reply-To: <7vabq0l7wn.fsf@gitster.siamese.dyndns.org>
Am Dienstag, 30. Oktober 2007 20:27 schrieb Junio C Hamano:
> > Do not generate translations when the translated message is empty.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> > ---
> > po/po2msg.sh | 3 +++
> > 1 files changed, 3 insertions(+), 0 deletions(-)
> >
> > diff --git a/po/po2msg.sh b/po/po2msg.sh
> > index 48a2669..91d420b 100644
> > --- a/po/po2msg.sh
> > +++ b/po/po2msg.sh
> > @@ -62,6 +62,9 @@ proc flush_msg {} {
> > if {$msgid == ""} {
> > set prefix "set ::msgcat::header"
> > } else {
> > + if {$msgstr == ""} {
> > + return
> > + }
> > set prefix "::msgcat::mcset $lang \"[u2a $msgid]\""
> > }
>
> Is this change to fix some real issues?
I don't think to - it just makes the resulting foo.msg file smaller.
> Sometimes it is handy to be able to translate a non-empty string
> into an empty one in one target language.
Err... no, this is not the case. The semantics of an msgstr == "" is identical
to saying "No translation exists to this source string". Nothing more,
nothing less. You can't specify a translation that should map a given string
to an empty string. (If you make up a case when that would make some sense,
usually the source string is rather weirdly chosen and should be reworded.)
Christian
^ permalink raw reply
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Linus Torvalds @ 2007-10-30 20:39 UTC (permalink / raw)
To: Jeff King; +Cc: git, Andy C, Junio C Hamano
In-Reply-To: <20071030202014.GA22733@coredump.intra.peff.net>
On Tue, 30 Oct 2007, Jeff King wrote:
>
> Well, the problem is that instead of just "dropping" boilerplate text,
> we fail to count it as a similarity, but it still counts towards the
> file size. It may be that just dropping it totally is the right thing
> (in which case those renames _will_ turn up, because they will be filled
> with identical non-boilerplate goodness).
Yeah, you may well be right, and the normalization of the scores will just
solve things.
Linus
^ permalink raw reply
* Re: remote#branch
From: Nicolas Pitre @ 2007-10-30 20:36 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Linus Torvalds, Pascal Obry, Matthieu Moy, Tom Prince,
Theodore Tso, Junio C Hamano, Jan Hudec, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <86tzo81hrd.fsf@blue.stonehenge.com>
On Tue, 30 Oct 2007, Randal L. Schwartz wrote:
> >>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> Linus> So the only argument really is:
>
> Linus> - Nobody has pointed to *any* reason to follow 1738.
>
> Linus> - I have pointed to reasons *not* to do it.
>
> I can support non-compliance with 1738. However, I'd also suggest
> that outside of this cozy group of developers, URL already has a heavily
> defined meaning associated with 1738.
>
> Therefore, I propose that the git docs refrain from calling these things
> "URLs" because they're not, and instead adopt something like "GRL" (git
> resources locator) or whatever.
And what do you do with the remote.<name>.url config option?
Add some backward compatibility cruft for some... well... issue that
turns out not to be one in practice?
Again, can someone point to a real usage scenario where all this
discussion is solving something?
Nicolas
^ permalink raw reply
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 20:30 UTC (permalink / raw)
To: Randal L. Schwartz
Cc: Pascal Obry, Matthieu Moy, Tom Prince, Theodore Tso,
Junio C Hamano, Jan Hudec, Johannes Schindelin, Petr Baudis,
Paolo Ciarrocchi, git
In-Reply-To: <86tzo81hrd.fsf@blue.stonehenge.com>
On Tue, 30 Oct 2007, Randal L. Schwartz wrote:
>
> Therefore, I propose that the git docs refrain from calling these things
> "URLs" because they're not, and instead adopt something like "GRL" (git
> resources locator) or whatever.
They're called "GIT URLS" right now. I'd have hoped that was descriptive
enough. But maybe not.
I think it's stupid to make up a new name, it's not like it's really
ambiguous *or* as if people really think in terms of RFC's.
Let's face it: people talk and use email, even when they don't have a clue
about SMTP. And in practice, you'll never see any difference, apart from
the obvious extension of using the ssh format and the direct local path
thing.
Linus
^ permalink raw reply
* Re: [PATCH] Fixed a command line option type for builtin-fsck.c
From: Pierre Habouzit @ 2007-10-30 20:20 UTC (permalink / raw)
To: Emil Medve; +Cc: spearce, gitster, git
In-Reply-To: <1193771721-2880-1-git-send-email-Emilian.Medve@Freescale.com>
[-- Attachment #1: Type: text/plain, Size: 1359 bytes --]
On Tue, Oct 30, 2007 at 07:15:21PM +0000, Emil Medve wrote:
> The typo was introduced by this commit: 5ac0a2063e8f824f6e8ffb4d18de74c55aae7131
>
> Signed-off-by: Emil Medve <Emilian.Medve@Freescale.com>
Acked-By: Pierre Habouzit <madcoder@debian.org>
good catch.
> ---
>
> This patch applies to the 'next' branch
>
> builtin-fsck.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-fsck.c b/builtin-fsck.c
> index 64da3bd..e4874f6 100644
> --- a/builtin-fsck.c
> +++ b/builtin-fsck.c
> @@ -680,7 +680,7 @@ static struct option fsck_opts[] = {
> OPT_BOOLEAN(0, "cache", &keep_cache_objects, "make index objects head nodes"),
> OPT_BOOLEAN(0, "reflogs", &include_reflogs, "make reflogs head nodes (default)"),
> OPT_BOOLEAN(0, "full", &check_full, "also consider alternate objects"),
> - OPT_BOOLEAN(0, "struct", &check_strict, "enable more strict checking"),
> + OPT_BOOLEAN(0, "strict", &check_strict, "enable more strict checking"),
> OPT_BOOLEAN(0, "lost-found", &write_lost_and_found,
> "write dangling objects in .git/lost-found"),
> OPT_END(),
> --
> 1.5.3.4.1458.g3e72e-dirty
>
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC 0/3] faster inexact rename handling
From: Jeff King @ 2007-10-30 20:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git, Andy C, Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710300818390.30120@woody.linux-foundation.org>
On Tue, Oct 30, 2007 at 08:38:24AM -0700, Linus Torvalds wrote:
> > 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".
Well, the problem is that instead of just "dropping" boilerplate text,
we fail to count it as a similarity, but it still counts towards the
file size. It may be that just dropping it totally is the right thing
(in which case those renames _will_ turn up, because they will be filled
with identical non-boilerplate goodness).
> 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).
Yes, that part bothers me a little, so I think a "too common, ignore"
overflow flag would at least be better.
But I think the best thing to do now is for me to shut up and see what
the results look like with the tweaks I have mentioned.
-Peff
^ permalink raw reply
* Re: remote#branch
From: Randal L. Schwartz @ 2007-10-30 20:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Pascal Obry, Matthieu Moy, Tom Prince, Theodore Tso,
Junio C Hamano, Jan Hudec, Johannes Schindelin, Petr Baudis,
Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710301232000.30120@woody.linux-foundation.org>
>>>>> "Linus" == Linus Torvalds <torvalds@linux-foundation.org> writes:
Linus> So the only argument really is:
Linus> - Nobody has pointed to *any* reason to follow 1738.
Linus> - I have pointed to reasons *not* to do it.
I can support non-compliance with 1738. However, I'd also suggest
that outside of this cozy group of developers, URL already has a heavily
defined meaning associated with 1738.
Therefore, I propose that the git docs refrain from calling these things
"URLs" because they're not, and instead adopt something like "GRL" (git
resources locator) or whatever.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Re: Problem with git-cvsimport
From: Mike Snitzer @ 2007-10-30 20:06 UTC (permalink / raw)
To: Michael Haggerty
Cc: Eyvind Bernhardsen, Thomas Pasch, git, Jan Wielemaker,
Gerald (Jerry) Carter, dev
In-Reply-To: <F1176033-1C6E-43F3-9F47-3BDD5EC88A14@orakel.ntnu.no>
On 10/10/07, Eyvind Bernhardsen <eyvind-git-list@orakel.ntnu.no> wrote:
...
>
> Thanks for making cvs2svn the best CVS-to-git conversion tool :) Now
> if it would only support incremental importing...
Michael,
I second this question: is there any chance incremental importing will
be implemented in cvs2svn?
I've not used cvs2svn much and when I did it was for svn not git; but
given that git-cvsimport is known to mess up your git repo (as Eyvind
pointed out earlier) there doesn't appear to be any reliable tools to
allow for incrementally importing from cvs to git.
Are others using a tool for reliably importing from cvs to git?
^ permalink raw reply
* Re: [PATCH] core-tutorial: Use new syntax for git-merge.
From: Junio C Hamano @ 2007-10-30 20:05 UTC (permalink / raw)
To: Sergei Organov; +Cc: git
In-Reply-To: <87lk9k4bvp.fsf@osv.gnss.ru>
Sergei Organov <osv@javad.com> writes:
> The patch below turns core-tutorial to use new syntax for
> git-merge. Please take close look at the last diff chunk, -- I'm not sure I
> got it right as it didn't have HEAD in the original version, -- was it already
> wrong before the patch?
You do not want the extra 'master' there.
> @@ -1607,8 +1607,8 @@ in both of them. You could merge in 'diff-fix' first and then
> 'commit-fix' next, like this:
>
> ------------
> -$ git merge 'Merge fix in diff-fix' master diff-fix
> -$ git merge 'Merge fix in commit-fix' master commit-fix
> +$ git merge -m 'Merge fix in diff-fix' master diff-fix
> +$ git merge -m 'Merge fix in commit-fix' master commit-fix
> ------------
The example is working on 'master' branch at this point and HEAD
and 'master' are equivalent there.
^ permalink raw reply
* [PATCH] more compact user direction message
From: Nicolas Pitre @ 2007-10-30 19:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
A failed cherry-pick (and friend) currently says:
|Automatic cherry-pick failed. After resolving the conflicts,
|mark the corrected paths with 'git-add <paths>'
|and commit the result.
This can obviously be displayed on two lines only.
While at it, change "git-add" to "git add".
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/builtin-revert.c b/builtin-revert.c
index 2cd9ca5..50c2e18 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -364,7 +364,7 @@ static int revert_or_cherry_pick(int argc, const char **argv)
die ("Error wrapping up %s", defmsg);
fprintf(stderr, "Automatic %s failed. "
"After resolving the conflicts,\n"
- "mark the corrected paths with 'git-add <paths>'\n"
+ "mark the corrected paths with 'git add <paths>' "
"and commit the result.\n", me);
if (action == CHERRY_PICK) {
fprintf(stderr, "When commiting, use the option "
^ permalink raw reply related
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 19:53 UTC (permalink / raw)
To: Jan Hudec
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <20071030193610.GA4442@efreet.light.src>
On Tue, 30 Oct 2007, Jan Hudec wrote:
> >
> > 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!
>
> Yes. But the server will unquote it. ' ' should not have been there, but it's
> just passed through if it was. '+' is quoting for ' ' and '%20' is quoting
> for ' ' as well. Therefore all these three addresses are the *SAME*.
Ok, you have some reading comprehension skills.
Read the above again.
I'd certainly hope that *curl* does the proper quoting. That's a transport
issue.
Linus
^ permalink raw reply
* [PATCH] core-tutorial: Use new syntax for git-merge.
From: Sergei Organov @ 2007-10-30 19:54 UTC (permalink / raw)
To: git
The patch below turns core-tutorial to use new syntax for
git-merge. Please take close look at the last diff chunk, -- I'm not sure I
got it right as it didn't have HEAD in the original version, -- was it already
wrong before the patch?
---
Documentation/core-tutorial.txt | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/core-tutorial.txt b/Documentation/core-tutorial.txt
index d8e78ac..02255d8 100644
--- a/Documentation/core-tutorial.txt
+++ b/Documentation/core-tutorial.txt
@@ -878,7 +878,7 @@ script called `git merge`, which wants to know which branches you want
to resolve and what the merge is all about:
------------
-$ git merge "Merge work in mybranch" HEAD mybranch
+$ git merge -m "Merge work in mybranch" mybranch
------------
where the first argument is going to be used as the commit message if
@@ -965,7 +965,7 @@ to the `master` branch. Let's go back to `mybranch`, and run
------------
$ git checkout mybranch
-$ git merge "Merge upstream changes." HEAD master
+$ git merge -m "Merge upstream changes." master
------------
This outputs something like this (the actual commit object names
@@ -1607,8 +1607,8 @@ in both of them. You could merge in 'diff-fix' first and then
'commit-fix' next, like this:
------------
-$ git merge 'Merge fix in diff-fix' master diff-fix
-$ git merge 'Merge fix in commit-fix' master commit-fix
+$ git merge -m 'Merge fix in diff-fix' master diff-fix
+$ git merge -m 'Merge fix in commit-fix' master commit-fix
------------
Which would result in:
--
1.5.3.4
^ permalink raw reply related
* Re: git-merge: inconsistent manual page.
From: Sergei Organov @ 2007-10-30 19:32 UTC (permalink / raw)
To: git
In-Reply-To: <7vk5p4l9gs.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 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.
OK, your patch is better than what I've suggested. The only thing that
your patch seems to be missing is prepending -m to <msg>:: in the
OPTIONS section. Yeah, it could be more strict to just describe <msg>,
but if there were no historical syntax, then you'd put '-m <msg>'
description in, right? So the latter might be better anyway.
--
Sergei.
^ permalink raw reply
* Re: remote#branch
From: Jan Hudec @ 2007-10-30 19:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Tom Prince, Theodore Tso, Junio C Hamano, Johannes Schindelin,
Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <alpine.LFD.0.999.0710300738550.30120@woody.linux-foundation.org>
[-- Attachment #1: Type: text/plain, Size: 2826 bytes --]
On Tue, Oct 30, 2007 at 07:59:45 -0700, Linus Torvalds wrote:
> > 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.
So the three addresses will all be different, right?
> > 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.
Yes. But the server will unquote it. ' ' should not have been there, but it's
just passed through if it was. '+' is quoting for ' ' and '%20' is quoting
for ' ' as well. Therefore all these three addresses are the *SAME*.
Now the user expectation will be that when these are the same, the git://
ones above will be as well. But they are not. This is not about following any
RFC for sake of it, but about being consistent with ourselves.
> 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.
Sure. There is no abiguity in decoding this, so why refuse it.
> [...]
> - <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".
The first three don't look like URL ("URL" always means the thing defined by
RFC 2396, at least to me), so I don't expect any quoting there. But for the
last case http:// (and for that matter, sftp://) do use quoting, so I would
expect the quoting of something that differs only by starting with git:// to
work the same.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH 6/5] add some copyright notice to the progress display code
From: Nicolas Pitre @ 2007-10-30 19:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1193770655-20492-6-git-send-email-nico@cam.org>
Some self patting on the back to keep my ego alive.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/progress.c b/progress.c
index 23ee9f3..2c4057a 100644
--- a/progress.c
+++ b/progress.c
@@ -1,3 +1,13 @@
+/*
+ * Simple text-based progress display module for GIT
+ *
+ * Copyright (c) 2007 by Nicolas Pitre <nico@cam.org>
+ *
+ * This code is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
#include "git-compat-util.h"
#include "progress.h"
^ permalink raw reply related
* Re: remote#branch
From: Linus Torvalds @ 2007-10-30 19:38 UTC (permalink / raw)
To: Pascal Obry
Cc: Matthieu Moy, Tom Prince, Theodore Tso, Junio C Hamano, Jan Hudec,
Johannes Schindelin, Petr Baudis, Paolo Ciarrocchi, git
In-Reply-To: <4727839B.9070205@obry.net>
On Tue, 30 Oct 2007, Pascal Obry wrote:
> Linus Torvalds a écrit :
> > I keep talking about a web browser, because THE ONLY POINT of following a
> > standard is to interoperate.
>
> Yes, and since URLs are not used for web browser only I do not see the
> point to concentrate all this discussion about a single possible usage.
Hey, it's find if you can come up with some *other* case why we should
care about RFC 1738.
I certainly didn't mean to bring up browsers as the _only_ case of
possible interoperability issues, but when it comes to URL's it's
certainly the obvious one...
So the only argument really is:
- Nobody has pointed to *any* reason to follow 1738.
- I have pointed to reasons *not* to do it.
So if you want to follow the RFC, you'd better give a real reason. And no,
the existence of an RFC, and the fact that people use the same name for
things that superficially _look_ the same is not a reason in itself.
So hands up, people. Anybody who asked for RFC quoting. Give a damn
*reason* already!
Linus
^ permalink raw reply
* Re: remote#branch
From: Pascal Obry @ 2007-10-30 19:15 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 a écrit :
> Nobody cares about git being consistent with a web browser. There is
> nothing in common.
I don't understand why you keep talking about web browser. URL is not a
web browser thing. It is the case that web browser are using URL, but
that's just one usage.
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
^ permalink raw reply
* Re: [GIT-GUI PATCH 2/3] po2msg: ignore untranslated messages
From: Junio C Hamano @ 2007-10-30 19:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: stimming, spearce, git
In-Reply-To: <Pine.LNX.4.64.0710301124450.4362@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Do not generate translations when the translated message is empty.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
> po/po2msg.sh | 3 +++
> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/po/po2msg.sh b/po/po2msg.sh
> index 48a2669..91d420b 100644
> --- a/po/po2msg.sh
> +++ b/po/po2msg.sh
> @@ -62,6 +62,9 @@ proc flush_msg {} {
> if {$msgid == ""} {
> set prefix "set ::msgcat::header"
> } else {
> + if {$msgstr == ""} {
> + return
> + }
> set prefix "::msgcat::mcset $lang \"[u2a $msgid]\""
> }
Is this change to fix some real issues?
Sometimes it is handy to be able to translate a non-empty string
into an empty one in one target language.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-10-30 19:19 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <52171BF7-50E2-473E-A0BD-CB64D38FD502@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> On Oct 30, 2007, at 9:29 AM, Junio C Hamano wrote:
>
>> It simply is insane to make this strange rule 10/10 introduces
>> the default behaviour. It is too specific to a particular
>> workflow (that is, working with a shared central repository,
>> having many locally tracking branches that are not often used
>> and become stale, and working on only things to completion
>> between pushes).
>
> I don't think its very strange behaviour if you see it in the
> light of what the user wants to achieve. We are talking about
> the case were only fast forward pushes are allowed. So, we
> only talk about a push that has the goal of adding new local
> changes to the remote. The user says "git push" and means
> push my new local changes to the remote.
If you want to push a specific subset of branches, you should
not be invoking the "matching refs" to begin with. And breaking
the "matching refs" behaviour is not the way to fix it.
You can rewind a wrong branch by mistake locally and run push.
With your change you would not notice that mistake.
$ git checkout bar
$ work work work; commit commit commit
$ git checkout test
$ git merge bar
... integrate, build, test
... notice that the tip commit of bar is not ready
$ git checkout foo ;# oops, mistake
$ git reset --hard HEAD^
$ git push
If you checked out foo instead of bar by mistake at the last
"git checkout" step like this, your change will make 'foo' an
ancestor of the other side of the connection, and push silently
ignores it instead of failing.
Also, the behaviour is too specific to your workflow of working
on things only to completion between pushes. If you work a bit
on branch 'foo' (but not complete), and work much on branch
'bar', 'baz', and 'boo' making all of them ready to be
published, you cannot say "git push" anyway. Instead you have
to say "git push $remote bar baz boo".
This discourages people from making commits that are not ready
to be published, which is a very wrong thing to do, as a major
selling point of distributed revision control is the
dissociation between committing and publishing.
You work and commit freely, and at any point some of your
branches are ready to be published while some others
aren't. Inconvenience of "matching refs" may need to be worked
around. I liked your "current branch only", with "git push
$remote HEAD" (I presume that "remote.$remote.push = HEAD" and
"branch.$current.remote = $remote" would let you do that with
"git push"), exactly because the way it specifies which branch
is to be published is very clearly defined and easy to
understand. This "matching but only ff" does not have that
attractive clarity.
^ 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