* Re: [PATCH] t9500: skip gitweb tests if perl version is too old
From: Sven Verdoolaege @ 2007-06-23 10:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps3n3rm7.fsf@assigned-by-dhcp.pobox.com>
On Sat, Jun 23, 2007 at 03:14:08AM -0700, Junio C Hamano wrote:
> Well, "Encode::FB_CLUCK" is a bogus symbol even in recent Perl.
> IOW, the tested function does not seem to care if I give
> whatever garbage as the second parameter.
>
> But I guess you are only interested if the perl used to run
> gitweb barfs with that two parameter, so the original check
> would be the right way.
Indeed. gitweb doesn't use FB_CLUCK and if it did, we would
want to know about it (and not skip the tests).
skimo
^ permalink raw reply
* Re: 100%
From: René Scharfe @ 2007-06-23 10:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: David Kastrup, git
In-Reply-To: <Pine.LNX.4.64.0706230222330.4059@racer.site>
Johannes Schindelin schrieb:
> On Fri, 22 Jun 2007, David Kastrup wrote:
>> The people I know will expect "100% identical" or even "100.0%
>> identical" to mean identical, period. They will be quite surprised to
>> hear that "99.95%" is supposed to be included.
>
> Granted, 100.0% means as close as you can get to "completely" with 4
> digits. But if you have an integer, you better use the complete range,
> rather than arbitrarily make one number more important than others.
>
> For if you see an integer, you usually assume a rounded value. If you
> don't, you're hopeless.
Why hopeless? It's a useful convention to define "100%" as "complete
(not rounded)". See it this way: 50% of the time, a given percent value
will be shown as one point less than it's "true" value, but you gain the
ability to indicate full completeness. And that's an interesting piece
of information. The price is small given that the needed accuracy is
more in the range of 10 percent points (I assume).
It's more a question of how to make sure everybody knows what the
numbers mean -- but that's why we have a directory named
"Documentation". :-D And even a person that hasn't read the docs is
unlikely to really get harmed by inexact percentages, right?
René
^ permalink raw reply
* Re: [PATCH] t9500: skip gitweb tests if perl version is too old
From: Junio C Hamano @ 2007-06-23 10:14 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20070623085751.GX955MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> On Fri, Jun 22, 2007 at 11:31:40PM -0700, Junio C Hamano wrote:
>> Sven Verdoolaege <skimo@kotnet.org> writes:
>> > +perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
>> > + test_expect_success 'skipping gitweb tests, perl version is too old' :
>> > + test_done
>> > + exit
>> > +}
>> > +
>>
>> Hmph. Even something silly like:
>>
>> perl -MEncode -e 'decode_utf8("", Encode::FB_CLUCK)'
>>
>> seem to succeed for me with 5.8.8.
>>
>
> Maybe I'm missing something, but it's supposed to succeed
> for perl versions that are recent enough.
Well, "Encode::FB_CLUCK" is a bogus symbol even in recent Perl.
IOW, the tested function does not seem to care if I give
whatever garbage as the second parameter.
But I guess you are only interested if the perl used to run
gitweb barfs with that two parameter, so the original check
would be the right way.
Will apply, but I am about to go to bed, so it will be
tomorrow.
Thanks.
^ permalink raw reply
* Re: problem pushing repository
From: Raimund Bauer @ 2007-06-23 10:12 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, Andrew Ruder, git
In-Reply-To: <20070622224712.GI17393@spearce.org>
Hi,
On Fri, 2007-06-22 at 18:47 -0400, Shawn O. Pearce wrote:
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks a lot, your patch makes my life easier.
Since you obviously know what you're doing here, maybe I can wish for
something too?
It would be really cool if completion also worked when I started the
branchname with a '+' to force the push ...
--
best regards
Ray
^ permalink raw reply
* help with cvsimport
From: Raimund Bauer @ 2007-06-23 9:11 UTC (permalink / raw)
To: git
Hi,
I unfortunately have to work with several cvs-repositories and was
wondering if there was a way to have the files processed on import:
- strip trailing whitespace
- convert to newline-only line endings
Knowing git there probably is already a way to do that - I'd appreciate
any rtfm-pointers ...
Many thanks in advance
--
best regards
Ray
^ permalink raw reply
* Re: [PATCH] t9500: skip gitweb tests if perl version is too old
From: Sven Verdoolaege @ 2007-06-23 8:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vps3n89mb.fsf@assigned-by-dhcp.pobox.com>
On Fri, Jun 22, 2007 at 11:31:40PM -0700, Junio C Hamano wrote:
> Sven Verdoolaege <skimo@kotnet.org> writes:
> > +perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
> > + test_expect_success 'skipping gitweb tests, perl version is too old' :
> > + test_done
> > + exit
> > +}
> > +
>
> Hmph. Even something silly like:
>
> perl -MEncode -e 'decode_utf8("", Encode::FB_CLUCK)'
>
> seem to succeed for me with 5.8.8.
>
Maybe I'm missing something, but it's supposed to succeed
for perl versions that are recent enough.
I get
bash-3.00$ perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)'
Too many arguments for Encode::decode_utf8 at -e line 1, at end of line
Execution of -e aborted due to compilation errors.
bash-3.00$ perl --version
This is perl, v5.8.0 built for i686-linux-thread-multi
Copyright 1987-2002, Larry Wall
Perl may be copied only under the terms of either the Artistic License or the
GNU General Public License, which may be found in the Perl 5 source kit.
Complete documentation for Perl, including FAQ lists, should be found on
this system using `man perl' or `perldoc perl'. If you have access to the
Internet, point your browser at http://www.perl.com/, the Perl Home Page.
(See also http://article.gmane.org/gmane.comp.version-control.git/50354)
skimo
^ permalink raw reply
* Re: [PATCH] t9500: skip gitweb tests if perl version is too old
From: Junio C Hamano @ 2007-06-23 6:31 UTC (permalink / raw)
To: skimo; +Cc: git
In-Reply-To: <20070622154908.GA7946MdfPADPa@greensroom.kotnet.org>
Sven Verdoolaege <skimo@kotnet.org> writes:
> gitweb calls Encode::decode_utf8 with two arguments,
> but old versions of perl only allow this function to be called
> with one argument. Even older versions of perl do not even
> have an Encode module.
>
> Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
> ---
> t/t9500-gitweb-standalone-no-errors.sh | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
>
> diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
> index 44ae503..d948724 100755
> --- a/t/t9500-gitweb-standalone-no-errors.sh
> +++ b/t/t9500-gitweb-standalone-no-errors.sh
> @@ -60,6 +60,12 @@ gitweb_run () {
>
> . ./test-lib.sh
>
> +perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
> + test_expect_success 'skipping gitweb tests, perl version is too old' :
> + test_done
> + exit
> +}
> +
Hmph. Even something silly like:
perl -MEncode -e 'decode_utf8("", Encode::FB_CLUCK)'
seem to succeed for me with 5.8.8.
Maybe you would want "perl -w" there instead?
^ permalink raw reply
* Re: [PATCH] filter-branch: add example to move everything into a subdirectory
From: Junio C Hamano @ 2007-06-23 6:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, git, gitster
In-Reply-To: <Pine.LNX.4.64.0706211805010.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index ffb31d6..297e09e 100644
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -181,6 +181,14 @@
Keeping your private repository out of sync with me is Ok, but
can you fix the filemode when you have chance? The warning I
get every time I apply a patch from you to this file about mode
mismatch somewhat annoys me.
Thanks.
^ permalink raw reply
* Re: [PATCH]: tree-walk.h: Warning fix
From: Junio C Hamano @ 2007-06-23 6:19 UTC (permalink / raw)
To: Luiz Fernando N. Capitulino; +Cc: git
In-Reply-To: <20070619231127.7ffe273b@gnut>
"Luiz Fernando N. Capitulino" <lcapitulino@mandriva.com.br>
writes:
> diff --git a/tree-walk.h b/tree-walk.h
> index ee747ab..625198f 100644
> --- a/tree-walk.h
> +++ b/tree-walk.h
> @@ -22,7 +22,7 @@ static inline const unsigned char *tree_entry_extract(struct tree_desc *desc, co
>
> static inline int tree_entry_len(const char *name, const unsigned char *sha1)
> {
> - return (char *)sha1 - (char *)name - 1;
> + return (const char *)sha1 - (const char *)name - 1;
> }
>
> void update_tree_entry(struct tree_desc *);
Grumble. Incoming "name" is already (const char*), isn't it?
I'd cast only the sha1 side and apply.
However, I think -Wcast-qual is a pretty useless option.
The nastiest one, if you care, is exec_cmd.c::execv_git_cmd()
where we never muck with "const char **argv" ourselves, but we
have to call execve(), which takes (char**) as its second
parameter. We cast away constness for that call; otherwise you
would then get prototype mismatch.
^ permalink raw reply
* Re: Possible BUG in 'git log -z' last commit is not '\0' terminated
From: Marco Costalba @ 2007-06-23 5:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.0.98.0706221451570.3593@woody.linux-foundation.org>
On 6/22/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> So you should think of the "\0" as being a delimeter that goes between
> commits, not something that "ends" the commit. It's not a "end of record"
> thing, it's a "between records" thing.
>
Thanks for explanation.
Interesting enough git-dif-tree with -z, documented as
"-z \0 line termination on output"
has a different behaviour, with and without -p option:
git diff-tree -z HEAD ---> a '\0' is printed at the end
git diff-tree -z -p HEAD --> No '\0' is printed.
I suppose 'git log' passes '-z' to 'git diff-tree' because no
documentation exsists in 'git log' man page.
Thanks
Marco
BTW git-rev-list --header uses '\0' differently (appends to each
record), but that's another story.
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Junio C Hamano @ 2007-06-23 5:44 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Shawn O. Pearce, git, govindsalinas, gitster
In-Reply-To: <Pine.LNX.4.64.0706211248420.4059@racer.site>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> When there are several candidates for a rename source, and one of them
> has an identical basename to the rename target, take that one.
>
> Noticed by Govind Salinas, posted by Shawn O. Pearce, partial patch
> by Linus Torvalds.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> On Wed, 20 Jun 2007, Linus Torvalds wrote:
>
> > I think we should just consider the basename as an "added
> > similarity bonus".
Thanks, I obviously agree with both of you.
^ permalink raw reply
* egit (eclipse plugin) now knows how to make commits
From: David Watson @ 2007-06-23 1:58 UTC (permalink / raw)
To: git; +Cc: Shawn O. Pearce, Robin Rosenberg
Egit, the eclipse git plugin now has the ability to make commits. 99%
of the credit belongs to spearce and robin, as most of my work has
been on hooking it into the GUI.
Please note that at this point any commits made will have a fake name/
email, because we don't read the git config files at present. Also,
this is not extensively tested, but appears to work with what I've
used it on so far. Currently, it will only commit changes that are
already in the index.
Pull from pu at git://dwatson.mimvista.com/egit.git
--
David Watson
QuercusMax on #git
^ permalink raw reply
* Re: 100%
From: Johannes Schindelin @ 2007-06-23 1:31 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86abusi1fw.fsf@lola.quinscape.zz>
Hi,
On Fri, 22 Jun 2007, David Kastrup wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 22 Jun 2007, David Kastrup wrote:
> >
> >> As a note aside: would it be possible to always round downwards when
> >> computing similarities or converting between them?
> >
> > I'd rather not. This would be counterintuitive. People expect rounded
> > values.
>
> Which people?
Me, for one. Thank you very much.
> The people I know will expect "100% identical" or even "100.0%
> identical" to mean identical, period. They will be quite surprised to
> hear that "99.95%" is supposed to be included.
Granted, 100.0% means as close as you can get to "completely" with 4
digits. But if you have an integer, you better use the complete range,
rather than arbitrarily make one number more important than others.
For if you see an integer, you usually assume a rounded value. If you
don't, you're hopeless.
> Also, for any kind of decision made upon percentages, it is much more
> relevant to be able to draw a line at 50% rather than at 49.5%.
I do see too many people in my day job who take the numbers they see for
absolute truths, so I cannot take that statement seriously, sorry.
> Could you name a _single_ use case where rounding down could cause an
> actual problem or even inconvenience for people?
Could you name a _single_ use case where it does not?
I mean, honestly, really. Really, really, really. A number is only a weak
_indicator_, and an integer even more so, for what is _really_ going on.
> >> I very much would like to see the 100% figure reserved for identity.
> >> This is particularly relevant when interpreting the output of
> >> git-diff --name-status with regard to R100, C100 and similar flags.
> >
> > You should never depend on the output of --name-status if you're
> > interested in identifying identical files, but on the object names.
>
> Which is rather inconvenient.
Frankly, I am getting bored.
This argument crops up ever so often. "If you did that, _I_ could be more
lazy, and the _hell_ with other people who expect otherwise!".
No, really.
> I _know_ that one can't rely on the output of --name-status right now.
And I _know_ that you can't rely on integer numbers. Or _any_ number which
is not _completely_ precise.
Really, I am getting bored with this discussion.
Ciao,
Dscho
^ permalink raw reply
* Re: merging git-p4 into git/fastimport.git (second try)
From: Shawn O. Pearce @ 2007-06-22 23:20 UTC (permalink / raw)
To: Simon Hausmann; +Cc: git
In-Reply-To: <200706190842.13175.simon@lst.de>
Simon Hausmann <simon@lst.de> wrote:
> Why not just leave out the entire lot of git-p4 logs in "What's in git.git"
> this one time? I'm not sure of how much value it is at this point anyway. I'm
> just interested in preserving the history to ease debugging.
Yeah, maybe a good idea. That's now up to Junio. I just pulled
your git-p4 branch into my fastimport, and republished it.
--
Shawn.
^ permalink raw reply
* Re: installation instruction
From: Jakub Narebski @ 2007-06-22 22:35 UTC (permalink / raw)
To: git
In-Reply-To: <B4C61E6A632A7F4D8A414B71954E963105498C64@taz.delosps.com>
[Cc: git@vger.kernel.org]
Sujatha Divi wrote:
> I want to install and evaluate git. Can anyone please direct me as to where
> I can get proper set of instructions for installation.
If you want to use newer version of git than in your distribution, and
RPMS and DEBs won't install because of dependencies (I for example --rebuild
RPM from SRPM, and install (re)build RPMs), there is [almost] always file
named INSTALL in the main directory.
See it also at:
http://repo.or.cz/w/git.git?a=blob;f=INSTALL
http://git.kernel.org/?p=git/git.git;a=blob;f=INSTALL
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: problem pushing repository
From: Shawn O. Pearce @ 2007-06-22 22:47 UTC (permalink / raw)
To: Raimund Bauer; +Cc: Johannes Schindelin, Andrew Ruder, git
In-Reply-To: <1182519484.6207.38.camel@localhost>
Raimund Bauer <ray007@gmx.net> wrote:
> On Fri, 2007-06-22 at 12:26 +0100, Johannes Schindelin wrote:
> > On Fri, 22 Jun 2007, Raimund Bauer wrote:
> >
> > > $ git push slcom test:test
> > > error: dst refspec test does not match any existing ref on the remote
> > > and does not start with refs/.
> >
> > It says that there is no branch named "test" on the remote side, and since
> > you could also want to push a tag, you have to say
> >
> > test:refs/heads/test
> >
> > here. However, I do not understand why you bother to use the :dst syntax
> > here, since your target name is _exactly_ the same as the source name. Why
> > not just
> >
> > git push slcom test
>
> because I had gotten the command line from bash-completion
I just patched the bash completion package to offer `git push slcom
test` as the completion, instead of `git push slcom test:test`.
The patch was pretty trivial, and is now also in my fastimport.git
tree on repo.or.cz.
-->8--
Avoid src:dst syntax as default bash completion for git push
Raimund Bauer just discovered that the default bash completion for
a local branch name in a git-push line is not the best choice when
the branch does not exist on the remote system.
In the past we have always completed the local name 'test' as
"test:test", indicating that the destination name is the same as
the local name. But this fails when "test" does not yet exist on
the remote system, as there is no "test" branch for it to match
the name against.
Fortunately git-push does the right thing when given just the
local branch, as it assumes you want to use the same name in the
destination repository. So we now offer "test" as the completion
in a git-push line, and let git-push assume that is also the remote
branch name.
We also still support the remote branch completion after the :,
but only if the user manually adds the colon before trying to get
a completion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 9e72f0f..c7c9963 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -683,7 +683,7 @@ _git_push ()
__gitcomp "$(__git_refs "$remote")" "" "${cur#*:}"
;;
*)
- __gitcomp "$(__git_refs2)"
+ __gitcomp "$(__git_refs)"
;;
esac
;;
--
1.5.2.2.1050.g51a8b
--
Shawn.
^ permalink raw reply related
* Re: [StGIT RFC] Changing patch@branch syntax
From: Catalin Marinas @ 2007-06-22 22:29 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20070622200037.GE7730@nan92-1-81-57-214-146.fbx.proxad.net>
On 22/06/07, Yann Dirson <ydirson@altern.org> wrote:
> On Fri, Jun 22, 2007 at 04:59:05PM +0100, Catalin Marinas wrote:
> > I also don't think we need to make this distinction in the names as
> > different commands or options take different type of arguments:
> >
> > stg show <patch>
> > stg series --branch <stack>
>
> Currently, "stg show HEAD" or any other git ref does work, except when
> there are name clashes.
But the argument to 'show' here is either a patch or a git ref (not a
stack or a pool). It first tries to find a patch and fall back to a
git ref. You don't specify a stack to 'show'. 'git show' is also able
to take a commit or a tag object without clearly specifying the
difference.
What might be easier with a complete spec is bash completion. I find
this mandatory precise description similar to the Hungarian notation.
Since most of the time I work with push/pop commands, I don't like
always putting a ":" for every patch (BTW, what about patch ranges, I
don't think they can go across multiple stacks).
> And since we're going to have all of patches, stacks, and pools in the
> same "stackable" family, we're going to use them interchangeably in
> more and more places. But there are also places where we can use at
> will stack names and generic git heads (eg. "stg branch X").
Currently, stack names and git branches are the same. Would this
change with hydra? I use StGIT to maintain my branches on
http://www.linux-arm.org/git?p=linux-2.6.git;a=heads and I find the
stack name == git branch simplification pretty useful.
What commands/options would we have where we need to distinguish
between stack and patch names?
> I'd rather having a single name-resolution mechanism, instead of one
> for patches and one for branches.
I don't see why we couldn't have a single name resolution but without
the mandatory ":". An example (but in reverse order) is internet
names. I only type "intranet" rather than "intranet." in a browser. To
fully qualify, I type "intranet.arm.com".
> > I would introduce a <repo> in front of all the above (for which we
> > don't have any support)
>
> Yes - URLs could do the work, with a '#' to use the stackable as URL
> fragment.
OK, you mentioned this in the past.
> Now for technical details. I have a prototype hydra mechanism that
> demonstrates that we can create such a beast without having everything
> breaking all around. However, it does not use the model described in
> this thread, but rather links to stacks which exist independantly - I
> want to keep that as a possibility, by using some symlink-like
> mechanism, but the current prototype will not live, although I may
> experiment a bit more with it. BTW, we should probably name the final
> beast "pool" and not "hydra", so users have a better idea of how to
> use it :)
Yes, "pool" sounds better (though I didn't get the full idea of how
things work).
> However, the various refactorings and fixes I have done should be
> quite ready for inclusion (modulo dispatching recent fixes down to the
> relevant patch). Here I need to know your plans for 0.13: if the
> refactoring would go in, I just have to polish things as they are; if
> you prefer to keep this for 0.14, I'll sink the bugfixes down my stack
> so they can be in 0.13 at least.
I plan to do a 0.13 release pretty soon. I want to clear some of the
logged bugs and release it as it seems to be pretty stable. It's
better to keep this refactoring for 0.14.
If it is easier for you, you could create a branch (for-upstream etc.)
and just send me an email to merge it.
> Did you have time to look at the various refactorings at
> http://repo.or.cz/w/stgit/ydirson.git ?
I had a quick look (not much though, moving house and a lot of FYI).
They look OK, but just a few comments:
- concreteCommand, I would write classes with capital first letter
(unwritten convention in StGIT)
- why the Repository class definition in stgit/__init__.py? Can it not
be in a different file? Also, shourt stgit/git.py be aware of the
repository?
Regards.
--
Catalin
^ permalink raw reply
* installation instruction
From: Sujatha Divi @ 2007-06-22 21:49 UTC (permalink / raw)
To: 'git@vger.kernel.org'
Hi,
I want to install and evaluate git. Can anyone please direct me as to where
I can get proper set of instructions for installation.
Thanks,
sujatha
^ permalink raw reply
* Re: Possible BUG in 'git log -z' last commit is not '\0' terminated
From: Linus Torvalds @ 2007-06-22 21:56 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550706221227x4b785698taabfa7572bf8204b@mail.gmail.com>
On Fri, 22 Jun 2007, Marco Costalba wrote:
>
> It seems '-z' option is not honoured by the last revision printed that
> is just '\n' terminated.
It's not a bug - it's by design.
What the -z option does is to replace the normal "\n" that delineates
commits from each other with a "\0".
And we only put that delimeter in *between* commits, not *after* commits.
The reason? It's prettier. Do a
git log -1
to get a single commit, and notice how we do *not* add an empty line at
the end (or beginning), and compare that to
git log -2
that shows two commits, and has an empty line in *between*.
Now, add the "-z" flag, and notice how that empty line is now replaced by
a "\0" character instead.
So you should think of the "\0" as being a delimeter that goes between
commits, not something that "ends" the commit. It's not a "end of record"
thing, it's a "between records" thing.
Linus
^ permalink raw reply
* Re: Possible BUG in 'git log -z' last commit is not '\0' terminated
From: Junio C Hamano @ 2007-06-22 21:29 UTC (permalink / raw)
To: Marco Costalba; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <e5bfff550706221227x4b785698taabfa7572bf8204b@mail.gmail.com>
I am a bit busy right now and do not have time to dig into this,
but I suspect the LF you are seeing at the end belongs to the
commit log of the last entry, as I think -z is not about
termination but separation.
^ permalink raw reply
* Re: [StGIT RFC] Changing patch@branch syntax
From: Yann Dirson @ 2007-06-22 20:00 UTC (permalink / raw)
To: Catalin Marinas; +Cc: GIT list
In-Reply-To: <b0943d9e0706220859n2c2962ffy21464526a5ebd6cd@mail.gmail.com>
On Fri, Jun 22, 2007 at 04:59:05PM +0100, Catalin Marinas wrote:
> >So here is a new proposal, which I believe would address all current
> >issues, at the expense of changing stgit syntax. The idea is to use a
> >single separator for all levels of Stackable objects, with an optional
> >"patch id" (eg. //top) at the end when meaningful. Only names would
> >be possible to omit, separators would be mandatory to specify the
> >nesting level. That gives a syntax of:
> >
> > [patchset]([:stackable]+(//id)?)*
>
> I don't think I can write a regexp for it but I don't like the
> mandatory ":" before the patch name (or stackable object). The main
> reason is that one usually works on a branch with patch names, there
> might be scripts+xargs involved and forcing the use of ":" would make
> it more complicated.
That's probably not much of a problem: patch lists could be generated
for script use with a flag similar to "series --showbranch".
> I also don't think we need to make this distinction in the names as
> different commands or options take different type of arguments:
>
> stg show <patch>
> stg series --branch <stack>
Currently, "stg show HEAD" or any other git ref does work, except when
there are name clashes.
And since we're going to have all of patches, stacks, and pools in the
same "stackable" family, we're going to use them interchangeably in
more and more places. But there are also places where we can use at
will stack names and generic git heads (eg. "stg branch X").
I'd rather having a single name-resolution mechanism, instead of one
for patches and one for branches.
> I'll try to express this with BNF (though I'm not an expert in this
> notation):
>
> <name> ::= "" | [^\w.-]+
> <attr> ::= top | top.old | bottom | bottom.old | log | ...
> <nameattr> ::= <name> | <name>//<attr>
>
> <stackable> ::= <nameattr> | <stackable>:<stackable>
>
> If empty name (""), the current object for the level is used.
>
> The above <stackable> is more generic. A patchset might have other
> attributes or none at all (could have a "old" attribute if we decide
> to keep older versions of a stack for example).
Right, good idea.
> I would introduce a <repo> in front of all the above (for which we
> don't have any support)
Yes - URLs could do the work, with a '#' to use the stackable as URL
fragment.
> but this is somehow at a similar level to <pool> in case we don't
> use a hydra. Or the <pool> can also be a repository?
I think they are different enough: a pool/hydra typically has several
members applied, whereas a repo has only a current branch.
Now for technical details. I have a prototype hydra mechanism that
demonstrates that we can create such a beast without having everything
breaking all around. However, it does not use the model described in
this thread, but rather links to stacks which exist independantly - I
want to keep that as a possibility, by using some symlink-like
mechanism, but the current prototype will not live, although I may
experiment a bit more with it. BTW, we should probably name the final
beast "pool" and not "hydra", so users have a better idea of how to
use it :)
However, the various refactorings and fixes I have done should be
quite ready for inclusion (modulo dispatching recent fixes down to the
relevant patch). Here I need to know your plans for 0.13: if the
refactoring would go in, I just have to polish things as they are; if
you prefer to keep this for 0.14, I'll sink the bugfixes down my stack
so they can be in 0.13 at least.
Did you have time to look at the various refactorings at
http://repo.or.cz/w/stgit/ydirson.git ?
Best regards,
--
Yann
^ permalink raw reply
* Possible BUG in 'git log -z' last commit is not '\0' terminated
From: Marco Costalba @ 2007-06-22 19:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
It seems '-z' option is not honoured by the last revision printed that
is just '\n' terminated.
Thanks
Marco
^ permalink raw reply
* Re: [PATCH] diffcore-rename: favour identical basenames
From: Aidan Van Dyk @ 2007-06-22 17:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Andy Parkins, git, Linus Torvalds, Jeff King, Shawn O. Pearce,
govindsalinas, gitster
In-Reply-To: <Pine.LNX.4.64.0706221626450.4059@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1984 bytes --]
* Johannes Schindelin <Johannes.Schindelin@gmx.de> [070622 13:34]:
> Hi,
>
> On Fri, 22 Jun 2007, Andy Parkins wrote:
>
> > What if two files with different filenames and content converge at some
> > point in history, then diverge again? If git is tracking renames merely
> > by content and picks the wrong one, then the history of fileA suddenly
> > becomes the history of fileB.
>
> This is becoming highly ethereal. Like "I could imagine that some day in
> future, some person could devise a device, that might allow you to do
> something that I can not explain, because I have not even thought of it".
>
> IOW show me a reasonable example, and we'll talk business.
The one time the "content-only" rename tracking bit me was the
after a merge, resulting in conflicts that were un-nessesary:
-*-*-*-*-A-B-C-D
\
*-E-*
At A, there were 2 files:
dir1/foo
dir2/foo
They were template files that happened to be the same in 2 themes.
In E, "foo" was renamed to "foo-bar" in all the template directories.
Git detected this not as 2 renames, but as:
dir1/foo-bar renamed from dir1/foo
dir2/foo-bar copied from dir1/foo
dir2/foo deleted
Meanwhile, work was happening in B, C, and D, changing foo in both
templates identically.
When the branch with E was merged back into ABCD, there was a merge
conflict with dir2/foo being deleted in one branch, and editit in the
other.
In this case, the simple "basename" comparison wouldn't have even been
enough.
But the merge was easy enough (because no edits were made in the E
branch to those files, just the renames) that I could resolve it easily.
I don't know if preventing this easy-to-fix merge conflict is worth the
necessary "likeness of names" necessary to avoid it...
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [StGIT RFC] Changing patch@branch syntax
From: Catalin Marinas @ 2007-06-22 15:59 UTC (permalink / raw)
To: Yann Dirson; +Cc: GIT list
In-Reply-To: <20070621230207.GD7730@nan92-1-81-57-214-146.fbx.proxad.net>
On 22/06/07, Yann Dirson <ydirson@altern.org> wrote:
> First, as a foreword, a bit if refactoring: I think we should use some
> sort of Stackable (maybe pick a better name) class as a parent for
> Patch and PatchSet. Instances of a Stackable would be candidates to
> be members of a PatchSet. That means we can have stacks within a
> stack, as well as stacks members of a pool. But we also need a syntax
> to name stacks-(in-a-stack)*, and patches within them.
I'm OK with refactoring the code this way (the current code is based
on the initial prototype but it evolved a lot since then).
> So here is a new proposal, which I believe would address all current
> issues, at the expense of changing stgit syntax. The idea is to use a
> single separator for all levels of Stackable objects, with an optional
> "patch id" (eg. //top) at the end when meaningful. Only names would
> be possible to omit, separators would be mandatory to specify the
> nesting level. That gives a syntax of:
>
> [patchset]([:stackable]+(//id)?)*
I don't think I can write a regexp for it but I don't like the
mandatory ":" before the patch name (or stackable object). The main
reason is that one usually works on a branch with patch names, there
might be scripts+xargs involved and forcing the use of ":" would make
it more complicated.
I also don't think we need to make this distinction in the names as
different commands or options take different type of arguments:
stg show <patch>
stg series --branch <stack>
I'll try to express this with BNF (though I'm not an expert in this notation):
<name> ::= "" | [^\w.-]+
<attr> ::= top | top.old | bottom | bottom.old | log | ...
<nameattr> ::= <name> | <name>//<attr>
<stackable> ::= <nameattr> | <stackable>:<stackable>
If empty name (""), the current object for the level is used.
The above <stackable> is more generic. A patchset might have other
attributes or none at all (could have a "old" attribute if we decide
to keep older versions of a stack for example).
In terms of our patches, stacks etc.:
<pool> ::= <name>
<stack> ::= <name> | <pool>:<name>
<patch> ::= <nameattr> | <stack>:<nameattr>
I would introduce a <repo> in front of all the above (for which we
don't have any support) but this is somehow at a similar level to
<pool> in case we don't use a hydra. Or the <pool> can also be a
repository?
> Examples:
>
> <stack> the named branch (git-compatible)
<patch> - named patch in the current patchset
> <stack>:<patch> named patch in named stack
OK
> :<patch> named patch in current patchset (currently just "<patch>")
OK, the same as <patch>
> <stack>: current (top) patch in named patchset
OK (maybe use should use "current" rather than "top" in the
description as it applies better to other stackable objects)
> <pool>:<stack>:<patch> fully-qualified patch in a named hydra
OK
> :: top patch of the current stack of an hydra
OK (current patch of the current stack)
> :<stack>://bottom.old previous bottom of the top patch in the named stack of current pool
OK
--
Catalin
^ permalink raw reply
* [PATCH] t9500: skip gitweb tests if perl version is too old
From: Sven Verdoolaege @ 2007-06-22 15:49 UTC (permalink / raw)
To: git, Junio C Hamano
gitweb calls Encode::decode_utf8 with two arguments,
but old versions of perl only allow this function to be called
with one argument. Even older versions of perl do not even
have an Encode module.
Signed-off-by: Sven Verdoolaege <skimo@kotnet.org>
---
t/t9500-gitweb-standalone-no-errors.sh | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/t/t9500-gitweb-standalone-no-errors.sh b/t/t9500-gitweb-standalone-no-errors.sh
index 44ae503..d948724 100755
--- a/t/t9500-gitweb-standalone-no-errors.sh
+++ b/t/t9500-gitweb-standalone-no-errors.sh
@@ -60,6 +60,12 @@ gitweb_run () {
. ./test-lib.sh
+perl -MEncode -e 'decode_utf8("", Encode::FB_CROAK)' >/dev/null 2>&1 || {
+ test_expect_success 'skipping gitweb tests, perl version is too old' :
+ test_done
+ exit
+}
+
gitweb_init
# ----------------------------------------------------------------------
--
1.5.2.2.249.g45fd
^ permalink raw reply related
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